Transition from IPv4 to IPv6

A new routing protocol cannot be implemented if there is not a clear transition methodology. The easier the transition procedures, the more likely the new protocol will be implemented. It is imperative that IPv6 interoperate with IPv4. IPv6 nodes need to communicate with IPv4 nodes, at least initially, and more likely, indefinitely. The NGTRANS IETF working group developed a number of different methodologies to facilitate the transition and to ensure compatibility.

Compatibility with IPv4 is possible in a number of different ways. A node running a dual-stack implementation fully implements both IPv4 and IPv6. It may communicate using both IPv4 and IPv6. A node could encapsulate IPv6 packets into an IPv4 header, creating a tunnel over an existing IPv4 network, allowing two IPv6 nodes to communicate. There are two tunneling mechanisms:

• Automatic tunneling

• Configured tunneling

An IPv4-compatible IPv6 address is defined such that the first 96 bits of the IPv6 address are all zero, and the remaining 32 bits compose an IPv4 address. For example, ::172.69.1.1 is an IPv4-compatible address. A node configured with an IPv4-compatible address uses automatic tunneling.

For IPv4 and IPv6 to coexist on the same network, a mechanism must be in place to resolve names to IP addresses correctly. DNS modifications have been defined to enable the DNS servers to correctly return IPv4 or IPv6 addresses (or both). The capability to do this is crucial to the success of protocol coexistence.

Or, a network address translation - protocol translation (NAT-PT) device might be implemented on the network between the IPv6 network and the IPv4 network. Dual stack is discussed first.

Dual Stacks

One way for a node to implement IPv6 and remain compatible with IPv4 nodes is to fully implement both IPv6 and IPv4. A node that fully implements both stacks is called an IPv6/IPv4 node. An IPv6/IPv4 node can communicate with IPv6 nodes using IPv6 packets and with IPv4 nodes using IPv4 packets.

An IPv6/IPv4 node must be configured with both an IPv6 and IPv4 address. The addresses may or may not be related . IPv4-compatible addresses may be viewed as single address that can be used as either an IPv6 address or an IPv4 address. The entire 128 bits represents the IPv6 address, whereas the low-order 32 bits represents the IPv4 address.

You can configure the addresses in many ways:

• You can configure the IPv6 address using stateless or stateful (DHCP for IPv6) autoconfiguration. The address can be either an IPv4-compatible address or an IPv6-only IPv6 address.

• You can use any IPv4 mechanism to acquire the node's IPv4 address.

• You can configure an IPv4-compatible address using an IPv4 configuration mechanism to acquire the IPv4 part of the address. The node then maps the IPv4 address into an IPv4-compatible address by prepending the 96-bit prefix 0:0:0:0:0:0. This method can prove particularly useful when an IPv6/IPv4 node is installed before IPv6 routers or address configuration servers are available.

A node with both an IPv4 and an IPv6 address must have some mechanism in place to determine which address to use. DNS provides this mechanism.

DNS

A new type of resource record is defined for IPv6 ”the AAAA record. This record provides name -to-IPv6 address mapping. A DNS resolver on an IPv6/IPv4 node must be able to handle both IPv4 A resource records and IPv6 AAAA resource records. When a node queries the DNS server for an address, an A record or an AAAA record is returned. The type of address returned determines the protocol that is used. If an A record is returned, the node uses its IPv4 address and the IPv4 protocol for communication with the requested destination. If an AAAA address is returned, IPv6 is used.

When an IPv4-compatible address is assigned to an IPv6/IPv4 host, both an AAAA record and an A record are defined in the DNS. The AAAA record lists the full 128-bit IPv6 address, and the A record lists the low-order 32 bits of the address. Both types are listed so that IPv6-only nodes can query the server and receive an IPv6 address and IPv4-only nodes can receive the IPv4 address.

Now, if both AAAA and A type records are listed for an IPv4-compatible address, the DNS resolver has some choices on what to return, and what it returns affects which protocol is used in the communication:

• Return only the IPv6 address to the application.

• Return only the IPv4 address to the application.

• Return both addresses to the application.

The address or the order of the addresses returned affects the type of IP traffic generated.

IPv6 Tunneled in IPv4

Most IPv6 implementations will be installed alongside IPv4 networks. IPv6 hosts will communicate over mostly IPv4 networks. IPv6 packet encapsulation into IPv4 packets supports this. You can create four types of tunnels:

• Router to router

• Host to router

• Host to host

• Router to host

IPv6/IPv4 routers can encapsulate IPv6 traffic for transmission over an IPv4 infrastructure. You can use this method for IPv6-only nodes that exist on either side of the routers, or for any communication that requires that this one segment of the end-to-end IPv6 path traverse an IPv4 network. The source node sends an IPv6 packet to an IPv6 router. This router acts as the tunnel source point, encapsulates the packet into an IPv4 packet, and sends the IPv4 packet on to the tunnel endpoint. The router at the far end of the tunnel decapsulates the packet and forwards it on toward the IPv6 destination.

IPv6/IPv4 nodes can initiate a tunnel to an IPv6/IPv4 router. This tunnel is created for the first segment of the IPv6 path. The initiating node encapsulates the IPv6 packet into an IPv4 packet and sends the IPv4 packet to the tunnel endpoint router. The endpoint router decapsulates the packet and forwards the IPv6 packet toward its final destination.

An IPv6/IPv4 host can create a tunnel to another IPv6/IPv4 host. This is a complete end-to-end tunnel. The IPv6/IPv4 source node encapsulates the IPv6 packet in an IPv4 packet and forwards the packet over an all-IPv4 network to the destination host. The destination host receives the IPv4 packet, decapsulates it, and processes the IPv6 packet.

A router-to-host tunnel is created on the final segment of the IPv6 path. A router receives an IPv6 packet and creates a tunnel so that it can forward the packet toward the destination host over the connected IPv4 network. The destination host receives the IPv4 packet, decapsulates it, and processes the IPv6 packet.

The first two methods , router to router and host to router, are not tunneled all the way to the final destination. The far endpoint of the tunnel differs from the final destination of the packet. The address of the far endpoint of the tunnel differs from the address of the final destination. An IPv4 address for the far end of the tunnel is required, and there is no way to obtain this information from the actual IPv6 destination address. These methods require configured tunnels.

In the second two methods, the far-end tunnel endpoint is the same as the final packet destination. The IPv4 address of the far end of the tunnel is contained in the low-order 32 bits of the IPv4-compatible IPv6 destination address. You can create automatic tunnels in the second two tunneling methods.

Configured Tunnels

A tunnel is created between Cisco routers by creating tunnel interfaces in the routers that border the IPv6 and IPv4 networks. The tunnel's endpoints are defined in both routers. An IPv6 subnet is created for the tunnel, and both routers are assigned IPv6 addresses. If an IPv6 dynamic routing protocol is in use, such as RIPng or BGP, the protocol is enabled on the tunnel interface. Figure 8-26 shows two IPv6 networks connected to an IPv4 network. A tunnel is configured between the IPv6 networks to enable communication.

Figure 8-26. Network Diagram of IPv6 Networks Tunneled Over an IPv4 Network

Tulip and Lily are IPv6-only routers. They communicate with each other via the IPv6-over -IPv4 tunnel between Daisy and Rose.

Example 8-10 shows the configurations of Daisy and Rose.

Example 8-10 Configured Tunnel Router Configurations

  Daisy   ipv6 unicast-routing   !   interface Tunnel0   description tunnel Daisy -> Rose   no ip address   no ip directed-broadcast   ipv6 address FEC0::A:0:0:0:1/124   ipv6 rip flowerpot enable   tunnel source Serial1.503   tunnel destination 172.69.255.250   tunnel mode ipv6ip   !   interface Ethernet0   ipv6 address FEC0::1:0:0:0:0/64 eui-64   ipv6 rip flowerpot enable   !   interface Serial1.503 point-to-point   ip address 172.69.255.254 255.255.255.252  ________________________________________________________________  Rose   ipv6 unicast-routing   !   interface Tunnel0   description tunnel Rose -> Daisy   no ip address   no ip directed-broadcast   ipv6 address FEC0::A:0:0:0:2/124   ipv6 rip flowerpot enable   tunnel source Serial1.703   tunnel destination 172.69.255.254   tunnel mode ipv6ip   !   interface Ethernet1   no ip address   ipv6 address FEC0::2:0:0:0:0/64 eui-64   ipv6 rip flowerpot enable   !   interface Serial1.703 point-to-point   ip address 172.69.255.250 255.255.255.252  

The tunnel interface is a generic tunnel, configured with ipv6ip mode.

The traceroute from Tulip to Lily in Example 8-11 shows the IPv6 packet traversing the tunnel.

Example 8-11 Displaying the IPv6 Packet Traversing the Tunnel from Tulip to Lily

 Tulip#  traceroute ipv6 fec0:0:0:2:210:7bff:fe3a:ce8a  Type escape sequence to abort. Tracing the route to FEC0::2:210:7BFF:FE3A:CE8A   1 FEC0::1:200:CFF:FE0A:2AA9 8 msec *  4 msec   2 FEC0::A:0:0:0:2 24 msec *  16 msec   3 FEC0::2:210:7BFF:FE3A:CE8A 28 msec *  20 msec 

The first address is Daisy's IPv6 Ethernet address. The second address is Rose's tunnel interface address. The third address is Lily's Ethernet address.

Configured tunnels offer a straightforward way to connect two IPv6 networks over an IPv4 network.

Automatic Tunnels

An encapsulating host configured for automatic tunnels extracts the IPv4 address from the destination's IPv4-compatible IPv6 address. This IPv4 address will be the automatic tunnel endpoint. The encapsulating host must have IPv4 connectivity to the address represented in the IPv4-compatible address. The source host encapsulates the packet into an IPv4 header, with the extracted IPv4 address as the destination and the address extracted from its own IPv4-compatible address as the source. Routers between the hosts know nothing of the IPv6 payload.

Network Address Translation - Protocol Translation

Another way to allow IPv6 and IPv4 networks and hosts to coexist is with the use of network address translation - protocol translation (NAT-PT). IPv6/IPv4 routers do the translation for IPv6-only and IPv4-only hosts. When these hosts want to communicate, neither needs to know that they are not running the same version of IP. The NAT-PT-configured router does all the translation. Both source and destination addresses are translated between IPv6 and IPv4.

The same issues that exist with IPv4 NAT also exist with IPv6-to-IPv4 NAT-PT. Inbound and outbound traffic translated between IPv6 and IPv4 domains must traverse the same address translator. The address translator maintains state information about translated sessions. End-to-end security is not possible. IPSec does not work through a network address translator. Applications that carry IP addresses anywhere other than the IP header will not work unless application translation gateways are running on the translating router. DNS queries crossing the protocol domains must have request and response information within the DNS packet translated between IPv4 and IPv6.

One issue particular to translation between IPv4 and IPv6, besides the address, is the header information. IPv6 headers do not contain the same fields as IPv4 headers, as you learned in this chapter. Option handling is very different. Translating between the two domains is nontrivial, and you should use this method of coexistence only when no other method is available.