Dual-stack implementations are implementations where internetwork devices and hosts used both protocol stacks, i.e. IPv4 and IPv6, at the same time. Dual-stack implementation allows the hosts to use either IPv4 or IPv6 to establish end-to-end IP sessions with other hosts.
Dual-stack implementation does not automatically mean that the IPv4-only and IPv6-only hosts have the ability to communicate with each other. To do so, additional protocols and mechanisms are needed. Dual-stack simply means that the hosts (and infrastructure) are able to support both the IPv4 protocol stack and the IPv6 protocol stack.
In situations where dual-stack implementations cannot be used, it is possible to tunnel the IPv6 packets over IPv4 networks. In these implementations, tunnels are used to encapsulate IPv6 packets in IPv4 packets, allowing them to be sent across portions of the network that have not or do not yet natively support IPv6. This allows the IPv6 ‘islands’ to communicate over the underlying IPv4 infrastructure.
IPv4 and IPv6 integration and co-existence strategies are divided into three broad classes:
- Dual-Stack Implementations
- Tunneling
- Protocol Translation
Cisco IOS software provides dual-stack support for several applications, tools and protocols, which include, but are not limited to the following:
- Telnet
- SSH
- TFTP
- Traceroute
- HTTP
- Frame Relay
- FHRP
- DNS
- Ping Utility
Cisco IOS software also supports the following tunneling mechanisms, which can be used to transport IPv6 packets over native IPv4 networks:
- Static (Manually Configured) IPv6 Tunneling
- 6to4 Tunneling
- Automatic IPv4-compatible Tunneling
- ISATAP Tunneling
- Generic Routing Encapsulation Tunneling
Static IPv6-in-IPv4 tunneling requires the static configuration of tunnels on dual-stack devices in order to allow IPv6 packets to be tunneled across the IPv4 network. When implementing static or manual tunnels, while the tunnel interface itself is assigned an IPv6 address, both the tunnel source and destination addresses must be IPv4 addresses. And finally, when implementing manual tunnels, IPv6 packets are encapsulated in IPv4 packets by specifying a tunnel mode ofipv6ip under the tunnel interface.
6to4 tunnels are defined in RFC 3056 and are designed to allow IPv6 end sites to access the IPv6 backbone commonly referred to as the 6bone, by tunneling across the IPv4 Internet. 6to4 automatic tunneling provides a dynamic method to deploy tunnels between IPv6 sites over IPv4 networks. Unlike with manually configured tunnels, there is no need to manually configure tunnel source and destination addresses to establish the tunnels. Instead, the tunneling of IPv6 packets between 6to4 sites is performed dynamically based on the destination IPv6 address of the packets originated by IPv6 hosts.
Automatic prefix assignment provides a global aggregatable IPv6 prefix to each 6to4 site. This prefix is based on the 2002::/16 (0x2002) prefix assigned by IANA for 6to4 sites. The tunnel endpoint or destination is determined by the globally unique IPv4 address embedded in a 6to4 address. This address must be an address that is globally routable. In other words, RFC 1918 cannot be used for 6to4 tunnels because they are not unique. This 32-bit IPv4 address is converted to Hexadecimal and the final representation is a 48-bit prefix. For example, if the IP address 1.1.1.1 was embedded into the IPv6 6to4 prefix, the final representation would be the 2002:0101:0101::/48 6to4 address.
Automatic IPv4-compatible tunnels enable IPv6 hosts to automatically enable tunnels to other IPv6 hosts across an IPv4 network infrastructure. Unlike 6to4 tunneling, automatic IPv4-compatible tunneling does use the IPv4-compatible IPv6 addresses. Automatic IPv4-compatible tunnels use the IPv6 prefix ::/96. To complete the 128-bit IPv6 address, the low order 32-bits are derived from the IPv4 address. These low-order 32-bits of the source and destination IPv6 addresses represent the source and destination IPv4 addresses of the tunnel endpoints in the same manner as the 6to4 tunnels which were described in the previous section. Therefore, with automatic IPv4-compatible tunneling, the host or router at each end of an IPv4-compatible tunnel must support both the IPv4 and IPv6 protocol stacks.
Automatic IPv4-compatible tunneling requires the use of either MP-BGP or static routes, with the former method being the more preferred method for scalability reasons. This tunneling mechanism requires the use of IPv4-compatible IPv6 addresses. As was stated earlier in this chapter, these addresses have the first 96 bits set to 0 and are then followed by the 32-bit IPv4 address. An example of an IPv4-compatible IPv6 address would be 0000:0000:0000:0000:0000:0000:172.16.255.1. This same address can then be compressed as 0:0:0:0:0:0:172.16.255.1/128 or simply as ::172.16.255.1/128. Additionally, it is also important to remember that the decimal IPv4 address could be converted to Hexadecimal and used to create the IPv4-compatible IPv6 address 0:0:0:0:0:0: AC10:FF01/128 or simply ::AC10:FF01/128.
Intra-Site Automatic Tunnel Addressing Protocol, or ISATAP, is an automatic overlay tunneling mechanism that uses the underlying IPv4 network as an NBMA Link Layer for IPv6. As the name suggests, ISATAP is designed for transporting IPv6 packets within a site where a native IPv6 infrastructure is not yet available. ISATAP tunnels allow individual IPv4 or IPv6 dual-stack hosts within a site to communicate with other such hosts on the same virtual link, creating a virtual IPv6 network using the IPv4 infrastructure. The main functionalities and components of ISATAP are automatic tunneling; the ISATAP address format, prefixes, the interface ID and ISATAP prefix advertisement.
ISATAP addresses assigned to ISATAP routers and hosts are created using the concatenation of a global Unicast IPv6 address dedicated to the ISATAP operation and the special format of the interface ID. The ISATAP prefix represents the high-order 64-bit of the IPv6 address. A single ISATAP address is enabled on the ISATAP host using the Link-Local prefix FE80::/10 and another global or Site-Local 64-bit prefix is assigned for ISATAP operation within the site. This prefix is then received by ISATAP hosts from router advertisement messages sent by ISATAP routers through the ISATAP tunnels established over the IPv4 infrastructure. The interface ID used in ISATAP represents the low-order 64-bit of the IPv6 address assigned to the ISATAP host. ISATAP embeds IPv4 addresses in IPv6 addresses, in the same manner used in 6to4 tunneling. This interface ID is created by appending the 32-bit IPv4 address to the high-order 32-bit value 0000:5EFE. This value has been reserved by IANA exclusively only for ISATAP use.
And finally, Generic Routing Encapsulation (GRE) is a tunnel encapsulation protocol that is used to tunnel protocols over an internetwork. GRE is the default encapsulation protocol used on tunnel interfaces in Cisco IOS software if one is not explicitly configured. GRE supports multiple protocols and can be used to encapsulate and transport protocols such as IPX, AppleTalk and IPv6 in IPv4 packets. This capability allows GRE to provide greater flexibility than other tunneling mechanisms.
In a manner similar to manually configured IPv6-in-IPv4 tunnels, GRE tunnels are configured statically between two routers to allow for the transport of IPv6 packets over an IPv4 infrastructure. The only notable difference is that while IPv6-in-IPv4 tunnels use a tunnel mode ofipv6ip, GRE tunnels use a tunnel mode of gre ip to tunnel IPv6 packets over the IPv4 infrastructure using GRE encapsulation.
NOTE: Additional detailed information and configuration examples of the tunneling methods described in the previous section can be found in the current ROUTE guide.