Protocol transitions are not easy and the transition from IPv4 to IPv6 is no exception. Protocol transitions are typically deployed by installing and configuring the new protocol on all nodes within the network and verifying that all host and router operations work successfully. Although this might be easily managed in a small or medium-sized organization, the challenge of making a rapid protocol transition in a large organization is very difficult. Additionally, given the scope of the Internet, rapid protocol transition of the total environment becomes an impossible task.
The designers of IPv6 recognize that the transition from IPv4 to IPv6 will take years and that there might be organizations or nodes within organizations that will continue to use IPv4 indefinitely. Therefore, although migration is the long-term goal, equal consideration must be given to the interim coexistence of IPv4 and IPv6 nodes.
The designers of IPv6 in the original "The Recommendation for the IP Next Generation Protocol" specification (RFC 1752) defined the following transition criteria:
The inherent lack of dependencies between IPv4 and IPv6 hosts, IPv4 routing infrastructure, and IPv6 routing infrastructure requires a number of mechanisms that allow seamless coexistence.
RFC 2893 defines the following node types:
An IPv4-only node implements only IPv4 (and is assigned only IPv4 addresses). This node does not support IPv6. Most hosts and routers installed today are IPv4-only nodes.
This node implements only IPv6 (and is assigned only IPv6 addresses). It is able to communicate with IPv6 nodes and applications only. Although this type of node is not common today, it may become more prevalent as smaller devices such as cellular phones and handheld computing devices include IPv6 stacks.
This node has an implementation of both IPv4 and IPv6. It is IPv6-enabled if it has an IPv6 interface configured.
An IPv4 node implements IPv4 (it can send and receive IPv4 packets). It can be an IPv4-only node or an IPv6/IPv4 node.
This node implements IPv6 (it can send and receive IPv6 packets). An IPv6 node can be an IPv6-only node or an IPv6/IPv4 node.
For coexistence to occur, the largest number of nodes (IPv4 or IPv6 nodes) can communicate using an IPv4 infrastructure, an IPv6 infrastructure, or an infrastructure that is a combination of IPv4 and IPv6. True migration is achieved when all IPv4 nodes are converted to IPv6-only nodes. However, for the foreseeable future, practical migration is achieved when as many IPv4-only nodes as possible are converted to IPv6/IPv4 nodes. IPv4-only nodes can communicate with IPv6-only nodes only when using an IPv4-to-IPv6 proxy or translation gateway. For more information about support for IPv4-to-IPv6 proxying using the IPv6 protocol for Windows XP and the Windows .NET Server 2003 family, see "PortProxy" in this chapter.
The following addresses are defined to aid in the coexistence of IPv4 and IPv6 nodes:
The IPv4-compatible address, 0:0:0:0:0:0:w.x.y.z or ::w.x.y.z (where w.x.y.z is the dotted decimal representation of a public IPv4 address), is used by IPv6/IPv4 nodes that are communicating with IPv6 over an IPv4 infrastructure. When the IPv4-compatible address is used as an IPv6 destination, the IPv6 traffic is automatically encapsulated with an IPv4 header and sent to the destination using the IPv4 infrastructure. The IPv6 protocol for Windows XP and the Windows .NET Server 2003 family supports the use of IPv4-compatible addresses but by default does not automatically configure them.
The IPv4-mapped address, 0:0:0:0:0:FFFF:w.x.y.z or ::FFFF:w.x.y.z, is used to represent an IPv4-only node to an IPv6 node. It is used only for internal representation. The IPv4-mapped address is never used as a source or destination address of an IPv6 packet. The IPv6 protocol for Windows XP and the Windows .NET Server 2003 family does not support the use of IPv4-mapped addresses. The IPv4-mapped address is used by some IPv6 implementations when acting as a translator between IPv4-only and IPv6-only nodes.
6over4 addresses are composed of a valid 64-bit unicast address prefix and the interface identifier ::WWXX:YYZZ (where WWXX:YYZZ is the colon hexadecimal representation of w.x.y.z, a unicast IPv4 address assigned to an interface). An example of a link-local 6over4 address based on the IPv4 address of 184.108.40.206 is FE80::836B:45C. When the automatic tunneling mechanism defined in RFC 2529 is used, 6over4 addresses are assigned to IPv6 nodes that are connected to an IPv4 multicast-enabled infrastructure. For more information, see "6over4" in this chapter.
6to4 addresses are based on the prefix 2002:WWXX:YYZZ::/48 (in which WWXX:YYZZ is the colon hexadecimal representation of w.x.y.z, a public IPv4 address). When the automatic tunneling mechanism defined in RFC 3056 is used, 6to4 address prefixes are used to create global address prefixes for sites and global addresses for IPv6 nodes within sites. For more information, see "6to4" in this chapter.
ISATAP addresses are composed of a valid 64-bit unicast address prefix and the interface identifier ::0:5EFE:w.x.y.z (where w.x.y.z is a unicast IPv4 address assigned to an interface). An example of a link-local ISATAP address is FE80::5EFE:220.127.116.11. When the automatic tunneling mechanism defined in the Internet draft titled "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)" is used, addresses using ISATAP-derived interface identifiers are assigned to IPv6/IPv4 nodes. For more information, see "ISATAP" in this chapter.
Despite the similarity in names, 6over4 and 6to4 are very different coexistence technologies.