Deploying IPv6 on a new network or an existing network requires a major planning effort. This chapter contains the planning tasks that are necessary before you can configure IPv6 at your site. For existing networks, IPv6 deployment should be phased in gradually. The topics in this chapter help you phase in IPv6 onto an otherwise IPv4-only network.
The following topics are discussed in this chapter:
For an introduction to IPv6 concepts, refer to Chapter 3, Introducing IPv6 (Overview). For detailed information, refer to Chapter 11, IPv6 in Depth (Reference).
Complete the tasks in the next task map in sequential order to accomplish the planning tasks necessary for IPv6 deployment.
The following table lists different tasks for configuring the IPv6 network. The table includes a description of what each task accomplishes and the section in the current documentation where the specific steps to perform the task are detailed.
Task |
Description |
For Instructions |
---|---|---|
1. Prepare your hardware to support IPv6. |
Ensure that your hardware can be upgraded to IPv6. | |
2. Get an ISP that supports IPv6. |
Ensure that your current ISP supports IPv6. Otherwise, find an ISP who can support IPv6. You can use two ISPs, one ISP for IPv6 and one for ISP IPv4 communications. |
|
3. Ensure that your applications are IPv6 ready. |
Verify that your applications can run in an IPv6 environment. | |
4. Get a site prefix. |
Obtain a 48-bit site prefix for your site from your ISP or from the nearest RIR. | |
5. Create a subnet addressing plan. |
You need to plan the overall IPv6 network topology and addressing scheme before you can configure IPv6 on the various nodes in your network. | |
6. Design a plan for tunnel usage. |
Determine which routers should run tunnels to other subnets or external networks. | |
7. Create an addressing plan for entities on the network. |
Your plan for addressing servers, routers, and hosts should be in place before IPv6 configuration. | |
8. Develop an IPv6 security policy. |
Investigate IP Filter, IP security architecture (IPsec), Internet Key Exchange (IKE), and other Oracle Solaris security features as you develop an IPv6 security policy. | |
9. (Optional) Set up a DMZ. |
For security purposes, you need an addressing plan for the DMZ and its entities before you configure IPv6. | |
10. Enable the nodes to support IPv6. |
Configure IPv6 on all routers and hosts. | |
11. Turn on network services. |
Make sure that existing servers can support IPv6. | |
12. Update name servers for IPv6 support. |
Make sure that DNS, NIS, and LDAP servers are updated with the new IPv6 addresses. |
The tasks throughout this chapter explain how to plan for IPv6 services on a typical enterprise network. The following figure shows the network that is referred to throughout the chapter. Your proposed IPv6 network might include some or all of the network links that are illustrated in this figure.
The enterprise network scenario consists of five subnets with existing IPv4 addresses. The links of the network correspond directly to the administrative subnets. The four internal networks are shown with RFC 1918-style private IPv4 addresses, which is a common solution for the lack of IPv4 addresses. The addressing scheme of these internal networks follows:
Subnet 1 is the internal network backbone 192.168.1.
Subnet 2 is the internal network 192.168.2, with LDAP, sendmail, and DNS servers.
Subnet 3 is the internal network 192.168.3, with the enterprise's NFS servers.
Subnet 4 is the internal network 192.168.4, which contains hosts for the enterprise's employees.
The external, public network 172.16.85 functions as the corporation's DMZ. This network contains web servers, anonymous FTP servers, and other resources that the enterprise offers to the outside world. Router 2 runs a firewall and separates public network 172.16.85 from the internal backbone. On the other end of the DMZ, Router 1 runs a firewall and serves as the enterprise's boundary server.
In Figure 4–1, the public DMZ has the RFC 1918 private address 172.16.85. In the real world, the public DMZ must have a registered IPv4 address. Most IPv4 sites use a combination of public addresses and RFC 1918 private addresses. However, when you introduce IPv6, the concept of public addresses and private addresses changes. Because IPv6 has a much larger address space, you use public IPv6 addresses on both private networks and public networks.
The Oracle Solaris dual protocol stack supports concurrent IPv4 and IPv6 operations. You can successfully run IPv4–related operations during and after deployment of IPv6 on your network.
IPv6 introduces additional features to an existing network. Therefore, when you first deploy IPv6, you must ensure that you do not disrupt any operations that are working with IPv4. The subjects covered in this section describe how to introduce IPv6 to an existing network in a step-by-step fashion.
The first step in IPv6 deployment is to assess which existing entities on your network can support IPv6. In most cases, the network topology-wires, routers, and hosts-can remain unchanged as you implement IPv6. However, you might have to prepare existing hardware and applications for IPv6 before actually configuring IPv6 addresses on network interfaces.
Verify which hardware on your network can be upgraded to IPv6. For example, check the manufacturers' documentation for IPv6 readiness regarding the following classes of hardware:
Routers
Firewalls
Servers
Switches
All procedures in the this Part assume that your equipment, particularly routers, can be upgraded to IPv6.
Some router models cannot be upgraded to IPv6. For more information and a workaround, refer to IPv4 Router Cannot Be Upgraded to IPv6.
The following typical IPv4 network services in the current Oracle Solaris release are IPv6 ready:
sendmail
NFS
HTTP (Apache 2.x or Orion)
DNS
LDAP
The IMAP mail service is for IPv4 only.
Nodes that are configured for IPv6 can run IPv4 services. When you turn on IPv6, not all services accept IPv6 connections. Services that have been ported to IPv6 will accept a connection. Services that have not been ported to IPv6 continue to work with the IPv4 half of the protocol stack.
Some issues can arise after you upgrade services to IPv6. For details, see Problems After Upgrading Services to IPv6.
Because servers are considered IPv6 hosts, by default their IPv6 addresses are automatically configured by the Neighbor Discovery protocol. However, many servers have multiple network interface cards (NICs) that you might want to swap out for maintenance or replacement. When you replace one NIC, Neighbor Discovery automatically generates a new interface ID for that NIC. This behavior might not be acceptable for a particular server.
Therefore, consider manually configuring the interface ID portion of the IPv6 addresses for each interface of the server. For instructions, refer to How to Configure a User-Specified IPv6 Token. Later, when you need to replace an existing NIC, the already configured IPv6 address is applied to the replacement NIC.
Update the following network services to support IPv6:
Mail servers
NIS servers
NFS
LDAP supports IPv6 without requiring IPv6-specific configuration tasks.
Verify that your firewall hardware is IPv6 ready.
Refer to the appropriate firewall-related documentation for instructions.
Verify that other services on your network have been ported to IPv6.
For more information, refer to marketing collateral and associated documentation for the software.
If your site deploys the following services, make sure that you have taken the appropriate measures for these services:
Firewalls
Consider strengthening the policies that are in place for IPv4 to support IPv6. For more security considerations, see Security Considerations for the IPv6 Implementation.
In the MX records for DNS, consider adding the IPv6 address of your mail server.
DNS
For DNS-specific considerations, see How to Prepare DNS for IPv6 Support.
IPQoS
Use the same Diffserv policies on a host that were used for IPv4. For more information, see Classifier Module.
Audit any network services that are offered by a node prior to converting that node to IPv6.
The current Oracle Solaris release supports DNS resolution on both the client side and the server side. Do the following to prepare DNS services for IPv6.
For more information that is related to DNS support for IPv6, refer to System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).
Ensure that the DNS server that performs recursive name resolution is dual-stacked (IPv4 and IPv6) or for IPv4 only.
On the DNS server, populate the DNS database with relevant IPv6 database AAAA records in the forward zone.
Servers that run multiple critical services require special attention. Ensure that the network is working properly. Also ensure that all critical services are ported to IPv6. Then, add the server's IPv6 address to the DNS database.
Add the associated PTR records for the AAAA records into the reverse zone.
Add either IPv4 only data, or both IPv6 and IPv4 data into the NS record that describes zones.
The IPv6 implementation supports a number of tunnel configurations to serve as transition mechanisms as your network migrates to a mix of IPv4 and IPv6. Tunnels enable isolated IPv6 networks to communicate. Because most of the Internet runs IPv4, IPv6 packets from your site need to travel across the Internet through tunnels to destination IPv6 networks.
Here are some major scenarios for using tunnels in the IPv6 network topology:
The ISP from which you purchase IPv6 service allows you to create a tunnel from your site's boundary router to the ISP network. Figure 4–1 shows such a tunnel. In such a case, you would run a manual, IPv6 over IPv4 tunnel.
You manage a large, distributed network with IPv4 connectivity. To connect the distributed sites that use IPv6, you can run an automatic 6to4 tunnel from the edge router of each subnet.
Sometimes, a router in your infrastructure cannot be upgraded to IPv6. In this case, you can create a manual tunnel over the IPv4 router, with two IPv6 routers as endpoints.
For procedures for configuring tunnels, refer to Tasks for Configuring Tunnels for IPv6 Support (Task Map). For conceptual information regarding tunnels, refer to IPv6 Tunnels.
When you introduce IPv6 into an existing network, you must take care not to compromise the security of the site. Be aware of the following security issues as you phase in your IPv6 implementation:
The same amount of filtering is required for both IPv6 packets and IPv4 packets.
IPv6 packets are often tunneled through a firewall. Therefore, you should implement either of the following scenarios:
Have the firewall do content inspection inside the tunnel.
Put an IPv6 firewall with similar rules at the opposite tunnel endpoint.
Some transition mechanisms exist that use IPv6 over UDP over IPv4 tunnels. These mechanisms might prove dangerous by short-circuiting the firewall.
IPv6 nodes are globally reachable from outside the enterprise network. If your security policy prohibits public access, you must establish stricter rules for the firewall. For example, consider configuring a stateful firewall.
This book includes security features that can be used within an IPv6 implementation.
The IP security architecture (IPsec) feature enables you to provide cryptographic protection for IPv6 packets. For more information, refer to Chapter 19, IP Security Architecture (Overview).
The Internet Key Exchange (IKE) feature enables you to use public key authentication for IPv6 packets. For more information, refer to Chapter 22, Internet Key Exchange (Overview).
A major part of the transition from IPv4 to IPv6 includes the development of an addressing plan. This task involves the following preparations:
Before you configure IPv6, you must obtain a site prefix. The site prefix is used to derive IPv6 addresses for all the nodes in your IPv6 implementation. For an introduction to site prefixes, refer to Prefixes in IPv6.
Any ISP that supports IPv6 can provide your organization with a 48-bit IPv6 site prefix. If your current ISP only supports IPv4, you can use another ISP for IPv6 support while retaining your current ISP for IPv4 support. In such an instance, you can use one of several workarounds. For more information, see Current ISP Does Not Support IPv6.
If your organization is an ISP, then you obtain site prefixes for your customers from the appropriate Internet registry. For more information, see the Internet Assigned Numbers Authority (IANA).
Unless your proposed IPv6 network is entirely new, use your existing IPv4 topology as the basis for the IPv6 numbering scheme.
Begin your numbering scheme by mapping your existing IPv4 subnets into equivalent IPv6 subnets. For example, consider the subnets illustrated in Figure 4–1. Subnets 1–4 use the RFC 1918 IPv4 private address designation for the first 16 bits of their addresses, in addition to the digits 1–4 to indicate the subnet. For illustrative purposes, assume that the IPv6 prefix 2001:db8:3c4d/48 has been assigned to the site.
The following table shows how the private IPv4 prefixes map into IPv6 prefixes.
IPv4 Subnet Prefix |
Equivalent IPv6 Subnet Prefix |
---|---|
192.168.1.0/24 |
2001:db8:3c4d:1::/64 |
192.168.2.0/24 |
2001:db8:3c4d:2::/64 |
192.168.3.0/24 |
2001:db8:3c4d:3::/64 |
192.168.4.0/24 |
2001:db8:3c4d:4::/64 |
For most hosts, stateless autoconfiguration of IPv6 addresses for their interfaces is an appropriate, time saving strategy. When the host receives the site prefix from the nearest router, Neighbor Discovery automatically generates IPv6 addresses for each interface on the host.
Servers need to have stable IPv6 addresses. If you do not manually configure a server's IPv6 addresses, a new IPv6 address is autoconfigured whenever a NIC card is replaced on the server. Keep the following tips in mind when you create addresses for servers:
Give servers meaningful and stable interface IDs. One strategy is to use a sequential numbering scheme for interface IDs. For example, the internal interface of the LDAP server in Figure 4–1 might become 2001:db8:3c4d:2::2.
Alternatively, if you do not regularly renumber your IPv4 network, consider using the existing IPv4 addresses of the routers and servers as their interface IDs. In Figure 4–1, suppose Router 1's interface to the DMZ has the IPv4 address 123.456.789.111. You can convert the IPv4 address to hexadecimal and use the result as the interface ID. The new interface ID would be ::7bc8:156F.
Only use this approach if you own the registered IPv4 address, rather than having obtained the address from an ISP. If you use an IPv4 address that was given to you by an ISP, you create a dependency that would create problems if you change ISPs.
Due to the limited number of IPv4 addresses, in the past a network designer had to consider where to use global, registered addresses and private, RFC 1918 addresses. However, the notion of global and private IPv4 addresses does not apply to IPv6 addresses. You can use global unicast addresses, which include the site prefix, on all links of the network, including the public DMZ.