Chapter 16: Making the Transition to IPv6 Networking

Introduction

For the transition to IPv6 to be successful, it must be compatibility with the large installed base of IPv4 hosts and routers. As transitioning the Internet to IPv6 occurs, maintaining compatibility with IPv4 minimize the impact of the change.

This chapter introduces some techniques that IPv6 hosts and routers can use so they can interoperate with IPv4 hosts and use the existing IPv4 routing infrastructures. Most nodes in the Internet will need to maintain IPv4 compatibility for a long time and some perhaps even indefinitely.

IPv6 might also be implemented in some environments where the ability to interoperate with IPv4 is not necessary. In such an environment, IPv6 hosts do not need to use or even implement these techniques.

This chapter briefly:

• Describes the impact of IPv6 and what you should know as you plan for and make your transition to IPv6.
• Summarizes some transition mechanisms for IPv6 hosts and routers. These transition mechanisms are described in greater detail later in this chapter.
• Describes dual IP layer arrangement that provides support for both IPv4 and IPv6 in hosts and routers.
• Discusses IPv6 over IPv4 tunneling that encapsulatesIPv6 packets within IPv4 headers to carry them over IPv4 routing infrastructures.
• Describes Header translation
• Summarizes some upgrade dependencies
• Describes OSI NSAP address mapping
• Introduces a sample sending algorithm that can determine when to send an IPv4 or IPv6 packet and when to perform automatic or configured tunneling.

RFC 1752, "The Recommendation for the IP Next Generation Protocol", describes the important features of IPv6. These features include the requirement of a simple and flexible transition plan that encompasses the following four basic requirements:

• Incremental upgrade that allows existing IPv4 hosts and router to upgrade at any time without any dependencies on other hosts or routes in the network being upgraded.
• Incremental deployment of new hosts and routers as the need arises. Such hosts and routers can be installed at any time without any prerequisites.
• Easy addressing that allows existing IPv4 hosts and routers to continue using their existing IPv4 address the these hosts and routers are upgraded to IPv6.
• Low cost startup that requires little or no preparation to upgrade an IPv4 host or router to IPv6. In addition, there should be little or no startup cost to deploy a new IPv6 system on the network.

It is clear that the transition will take years and that every site will have to decide its own staged transition plan. Only the very smallest sites could envisage a simple single step transition, presumably under pressure from their Internet service providers.

Many user sites will look at the decision to change from IPv4 in the same way as they have looked in the past at changes of programming language or operating system. Their main concern will be to minimize the cost of the change and the risk of lost productivity.

Migrating the applications

Many existing TCP/IP applications assume that the IP host address length is the IPv4 fixed 32-bits and usually store the address in a 32-bit wide application variable. Such an application cannot directly address an IPv6-only host with out some changes.

The IPv4 socket API structures contain a 32-bit field for IP addresses. A 128-bit address identifies an IPv6 interface. The socket interface makes the size of an IP address quite visible to an application. The parts of the API that expose the addresses are changing to accommodate the larger IPv6 address size.

Applications should be able to hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP sockets simultaneously within the same process. Should major modifications to the application source code occur, depends on the way the program handles the addresses and variable syntax used for allocating space for them.

A new, network protocol independent transport layer specification in being written. This will help to prevent massive software modifications in the future.

Moving from IPv4 to IPv6

Many IETF Internet standards and proposed Internet drafts are being revised to incorporate IPv6. Because of these revisions, many software developer are having to change the way they write IP compliant software.

In addition, some non-IETF standards and application programming interfaces might revision to include IPv6 such as Kerberos and the Sockets interface. Routers and routing software are implementing new addressing and security schemes and host software vendors are beginning to change the IP interfaces in their applications to support the new security mechanisms.

As an example, many existing TCP/IP applications assume that the IP host address length is the IPv4 fixed 32-bits and usually store the address in a 32-bit wide application variable. Such an application cannot directly address an IPv6-only host with out some changes.

The IPv4 socket API structures contain a 32-bit field for IP addresses. A 128-bit address identifies an IPv6 interface. The socket interface makes the size of an IP address quite visible to an application. The parts of the API that expose the addresses are changing to accommodate the larger IPv6 address size.

Applications should be able to hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP sockets simultaneously within the same process. Should major modifications to the application source code occur, depends on the way the program handles the addresses and variable syntax used for allocating space for them.

A new, network protocol independent transport layer specification in being written. This will help to prevent massive software modifications in the future.

Transition Plan Objectives

Test implementations of IPv6 have been running for some time. However, Internet Service Providers have a pressing need for extended address and automated routing capabilities; ISPs are probably going to be the first to implement IPv6 in a serious way.

Network administrators need to become familiar with the new IPv6 protocols and begin planing their IPv4 transition strategy for hosts and routers. A good transition plan would have at least three objectives as follows:

• To allow IPv6 and IPv4 hosts to interoperate
• To allow the incremental deployment of IPv6 hosts and routers in the Internet with a minimum of interdependencies
• To make the transition easy as possible for end-users, other network and system administrators, and network operators to understand and carry out.

Transition Plan Issues

The Network administrator faces a number of issues when developing a transition plan including making the decision to implement IPv6 first on routers or first on the hosts.

Issues 1: Initially, every host or router that transitions to IPv6 will also have to implement IPv4. These hosts and routers are referred to as dual nodes or IPv6/IPv4 nodes. An IPv6/IPv4 node will use a special address that incorporates an IPv4 address in the low-order 32 bits. This allows the hosts and routers to interoperate with current IPv4 nodes. Each IPv6 implementation must be capable of being configured with multiple addresses on the same port or interface at the same time.

Issue 2: If a node has both IPv4 and IPv6 addressing how will the network determine which address to use? Both IPv6 and IPv4 use the domain naming system (DNS) to map host names into addresses. During the transition each IPv6 host will be defined both as an IPv6 node and as an IPv4 node.

RFC 1886, "DNS Extensions to support IP version 6" by S. Thomson and C. Huitema defines a new resource record type named "AAAA" for IPv6 addresses. The "AAAA" record type for IPv6 nodes replaces the "A" record type used under IPv4. Each IPv6 node must implement DNS resolver code. Since IPv6/IPv4 nodes must be able to interoperate directly with both IPv4 and IPv6 nodes, they must provide resolver libraries capable of dealing with IPv4 "A" records as well as IPv6 "AAAA" records.

Issue 3: Routing IPv6 traffic can create some issues. For example, what happens when the source and destinations hosts are IPv6 nodes but the underlying router network is still using IPv4? Such communication between and over IPv4 and IPv6 nodes requires tunneling. This can create a higher level of complexity for IP administrators who may be used to dealing with only one type of IP traffic.

The IETF guidelines described in RFC 1933 specify two methods for tunneling IPv6 over IPv4. The first is called automatic tunneling. With automatic tunneling, the IPv6 packet is encapsulated in an IPv4 header that is addressed to an IPv6 destination. The encapsulated packet is transmitted across the IPv4 router network to the IPv6 destination node. The end point of the tunnel can be determined automatically from the IPv6 destination address, without requiring any special configuration information.

The second method of tunneling is called configured tunneling. With configured tunneling, the IPv6 packet is transmitted to an IPv6/IPv4 compliant router. The router translated the IPv6 packet into the IPv4 format and transmits it across the IPv4 router network. An IPv6/IPv4 compliant router at the other end converts the format of the packet back to IPv6 before transmitting it to its final destination, the IPv6 node.

Summary of Transition Mechanisms for IPv6 Hosts and Routers

The mechanisms, operational practices, and transition plans that will be used for transitioning the Internet from IPv4 to IPv6 are collectively termed the Simple Internet Transition (SIT). The Internet must remain completely functional throughout the transition period. In addition, hosts and routers implementing the new protocol must interoperate with the large installed base of systems which continue to use IPv4.

SIT employs a number of mechanisms and operational practices to facilitate the transition. These include standard required mechanisms to be implemented in every host and router. Initially, the transition to IPv6 will use three techniques to maintain interoperability with IPv4 hosts and routers; these include:

• Use of a dual Internet Protocol layer (IPv4 and IPv6) in hosts and routers. This provides for direct interoperability with nodes implementing both protocols.
• Use of IPv6 address formats that embeds IPv4 addresses within IPv6 addresses and encodes other information used by the transition mechanisms.
• Use of a mechanism for tunneling IPv6 packets over IPv4 routing infrastructures by encapsulating the IPv6 packets within IPv4 headers.

Later on in the transition, additional optional mechanisms could be implemented. One such mechanism could be the deployment and use of hosts and routers that implement only IPv6. Even though they do not themselves implement IPv4, these nodes would be able to interoperate with IPv4 nodes by routing their traffic through header translators.

During the years of transition we can have three different types of IP nodes, depending on their capability to support different protocols:

IPv4-only node	A host or router that implements only IPv4. An IPv4-only node does not understand IPv6. The installed base of IPv4 hosts and routers existing before the transition begins are IPv4-only nodes.
IPv6/IPv4 node	A host or router that implements both IPv4 and IPv6.
IPv6-only node	A host or router that implements IPv6 and does not implement IPv4. These are not feasible for general purpose Internet use until the transition has proceeded into a phase where most of the community has upgraded to IPng.

SIT Operational Issues

Transitioning the global Internet to IPv6 also involves a number of operational issues. Some of the issues that must be considered include:

• Procedures for assigning IPv4 and IPv6 addresses.
• Procedures for upgrading hosts and routers and deploying new hosts and routers.
• Procedures for deploying DNS servers that support the IPv6 address record type AAAA.
• Plans for transitioning individual Internet sites to IPv6.
• Plans for transitioning the global Internet to IPv6.

SIT features

SIT provides a number of features, including:

Incremental upgrade: — Existing installed IPv4 hosts and routers can be upgraded to IPv6 at any time without being dependent on any other hosts or routers.

Incremental deployment: — New IPv6 hosts and routers can be installed one by one

Minimal upgrade dependencies: — There is one prerequisite to upgrading hosts to IPv6. You must first upgrade the DNS server to handle IPv6 address records. There are no pre-requisites to upgrading routers.

Easy addressing: — When you upgrade an IPv4 host or router to IPv6, you can re-use the existing IPv4 addressing structure for IPv6. They do not need to be assigned new addresses

Low start-up costs: — There is little or no preparation work needed to upgrade existing IPv4 systems to IPv6, or to deploy new IPv6 systems.

Transition components

Transition component include hosts, routers and routing protocols, and DNS.

Hosts

Transitioning from IPv4 to IPv6 means that for many years the global Internet will contain both hosts restricted to traditional IPv4 operation and hosts equipped with IPv6 capability. To allow seamless interoperation, all hosts running IPv6 must still be able to communicate with the older IP technology.

Application level software designed for IPv4 will continue to use the older application programming interface (API). The new IPv6 applications will use the new API. This means applications actually know which protocol suite it is using. Standard applications and the IPv4 API should be available on IPv6 hosts if you expect interoperation with common tools such as FTP and Telnet with older IPv4 hosts.

Routers and routing protocols

Router must follow the same protocol version rules as individual hosts. New devices with IPv6 capability cannot assume that all other systems they are interacting with are equipped with the latest protocol support. The same rules apply to routing protocols as well. IPv6 routing procedures must allow routing based on traffic source and destination in detail.

Domain Name System

During the transition phase the IPv6 capable hosts have both a 32-bit IPv4 address and a 128-bit IPv6 address. IPv4 system that have not been upgraded to IPv6 have only an IPv4 address. Depending on the transition policy in effect at the site, it is possible that and an IPv6 address may already have been assigned to them.

When DNS receives queries form IPv6 host, it has to reply with both addresses, if available. The communicating host then decides which protocol to use. For standard queries from IPv4-only hosts the response is the IPv4 address only.

There is a special condition called a black hole in the address space that occurs when an IPv6 address has been attributed to a specific host in DNS, but the host is not really IPv6 capable yet. The associated protocol software on communicating hosts must handle such exceptions in an acceptable way.

Component dependencies

DNS servers are the first physical devices to upgrade as you transition to IPv6. Upgrading your network DNS servers occurs after a you determine a suitable IPv6 address allocation and mapping scheme. Upgrading DNS means new IPv6 hosts can perform name service lookups for IPv6 addresses.

The order for migrating host and router software is less critical. The protocol dualism allows IPv4 systems to continue operation without any modifications. Changing routing protocols can also be orderly. Such changes need only occur as the number of IPv6 capable routers increases.

summarizes the operational dependencies that network and system administrators must consider in planning the upgrade of systems to IPv6.

Transition Mechanisms for IPv6 Hosts and Routers

This section provides some guidelines for migrating to IPv6 network addresses and presents some Pv6 transition and coexistence mechanisms. It is expected that most nodes in the Internet will need such compatibility for a long time to come, and perhaps even indefinitely.

These mechanisms include providing complete implementations of both versions of the Internet Protocol, IPv4 and IPv6, and tunneling IPv6 packets over IPv4 routing infrastructures.

Much of the information in this section is based on RFC 1933, "Transition Mechanisms for IPv6 Hosts and Routers," by Robert E. Gilligan and Erik Nordmark.

Addressing

IPv6 has an automatic tunneling mechanism (described later in this chapter). Automatic tunneling uses an "IPv4-compatible" address that identified by an all-zeros 96-bit prefix, and holds an IPv4 address in the low-order 32-bits. shows the structure of an IPv4-compatible addresses.

IPv6/IPv4 nodes that support automatic tunneling receive an IPv4 compatible address. A node that has an IPv4 compatible address can use this address as their IPv6 address. Such a node can use the embedded IPv4 address as their IPv4 address. The rest of the IPv6 address space is referred to as "IPv6-only addresses". An IPv6-only address is one that has 96-bit prefixes other than 0:0:0:0:0:0:.

Dual IP layer

An IPv6 node can remain compatible with an IPv4 node by providing a complete IPv4 implementation in addition to its IPv6 implementation . Such nodes are called IPv6/IPv4 nodes. An Pv6/IPv4 node can send and receive both IPv4 and IPv6 packets. They can directly interoperate with IPv6 nodes using IPv6 packets and can directly interoperate with IPv4 nodes using IPv4 packets. shows a conceptual representation of the protocol layering in IPv6/IPv4 nodes.

You can use the dual IP-layer technique in conjunction with the IPv6-over-IPv4 tunneling techniques described later in this chapter. An IPv6/IPv4 node that supports tunneling can support configured tunneling only or both configured and automatic tunneling. Three configurations are possible for an IPv6/IPv4 node:

• IPv6/IPv4 node that does not perform tunneling;
• IPv6/IPv4 node that performs configured tunneling and automatic tunneling;
• IPv6/IPv4 node that performs configured tunneling only.

Automatic tunnels deliver IPv6 packets all the way to their end destinations. Configured tunnels deliver IPv6 packets to an intermediary IPv6/IPv4 router.

Address Configuration

IPv6/IPv4 nodes support both protocols and can be configured with both IPv4 and IPv6 addresses. It is not required that the two addresses must be related to each other. IPv6/IPv4 nodes can be configured with IPv6 and IPv4 addresses that are unrelated to each other.

The transition mechanisms use two special formats of IPv6 addresses, both of which hold an embedded IPv4 address:

• IPv4-compatible IPv6 address format
• IPv4-mapped IPv6 address format.

IPv6 Addresses with Embedded IPv4 Addresses

The IPv6 transition mechanisms include a technique for hosts and routers to dynamically tunnel IPv6 packets over IPv4 routing infrastructure. This type of node receives an IPv4-compatible IPv6 address. These unicast addresses carry an IPv4 address in the low-order 32-bits and have the format shown in. The node uses the entire 128-bit IPv4-compatible IPv6 address as the node's IPv6 address. The IPv4 address embedded in low-order 32-bits serves as the node's IPv4 address.

The DNS IPv6 "AAAA records and IPv4 "A" records list IPv4-compatible IPv6 addresses. The DNS AAAA record holds the entire 128-bit (16 octets) address, while the "A" record holds the IPv4 address portion (the low-order 32-bits). DNS lists both types of address records so it can make proper responses to queries from both IPv4 and IPv6 hosts.

A second type of embedded address represents the addresses of IPv4-only nodes as anIPv6 addresses. IPv4 only nodes are those that do not support IPv6. This type of address is called an "IPv4-mapped IPv6 address" and has the format shown in.

IPv4-mapped IPv6 addresses are never assigned to IPv6 nodes. These mapped addresses are listed only in the DNS "A" records. Even though the addresses of all IPv4 nodes can be represented as IPv4-mapped IPv6 addresses, they are not listed in "AAAA" records. This practice simplifies DNS administration.

The remainder of the IPv6 address space, all addresses with 96-bit prefixes other than 0:0:0:0:0:0 or 0:0:0:0:0:FFFF) is called the "IPv6-only address space" because it can only be used by IPv6 nodes. DNS "AAAA" records lists these IPv6 only addresses. These addresses are not listed in "A" records because they do not hold an embedded IPv4 address.

Acquiring Addresses

System administrators can use several different methods to acquire the IPv6 and IPv4 addresses for IPv6/IPv4 nodes.

Acquiring IPv6 addresses: A system administrator can use stateless IPv6 address configuration, and DHCP for IPv6 (stateful configuration) to acquire an IPv6 address for an IPv6/IPv4 node. These methods can provide either IPv4-compatible or IPv6-only IPv6 addresses. A system administrator could also, if necessary, use manual configuration.

IPv6 defines both a stateful and stateless address autoconfiguration mechanism. Stateless and stateful autoconfiguration complement each other. For example, a host can use stateless autoconfiguration to configure its own addresses and then stateful autoconfiguration to obtain other information.

The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. The host forms the address by combining the router advertised prefix that identifies the subnet associated with a link and the host generated interface token. The interface token uniquely identifies an interface on the subnet.

You could use stateless autoconfiguration when the you are not particularly concerned with the exact addresses hosts use, so long as they are unique and properly routable. You could use the stateful approach when your site requires tighter control over exact address assignments. And you can use both stateful and stateless address autoconfiguration simultaneously.

RFC 1971. "IPv6 Stateless Address Autoconfiguration" specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6.

Acquiring an IPv4 addresses: IPv6/IPv4 nodes can use any IPv4 mechanisms to acquire their IPv4 addresses. For example, IPv6/IPv4 nodes that perform automatic tunneling can acquire their IPv4-compatible IPv6 addresses from IPv4 address configuration protocols. When the node acquires an IPv4 address it then maps that address into an IPv4-compatible IPv6 address by pre-pending it with the 96-bit prefix 0:0:0:0:0:0.

This means IPv6/IPv4 nodes can use the installed base of IPv4 address configuration servers. This technique can be particularly useful in environments where IPv6 routers and address configuration servers have not yet been deployed.

RFC 1933, "Transition Mechanisms for IPv6 Hosts and Routers" defines the algorithm for acquiring an IPv4-compatible address using IPv4-based address configuration protocols as follows:

1. The IPv6/IPv4 node acquires its own IPv4 address using standard IPv4 mechanisms or protocols. These include:

• The Dynamic Host Configuration Protocol (DHCP) [2]
• The Bootstrap Protocol (BOOTP) [1]
• The Reverse Address Resolution Protocol (RARP) [9]
• Manual configuration
• Any other mechanism which accurately yields the node's own IPv4 address

1. The node uses this address as its IPv4 address.
2. The node prepends the 96-bit prefix 0:0:0:0:0:0 to the 32-bit IPv4 address that it acquired in step 1. This results in an IPv4-compatible IPv6 address with the node's own IPv4-address embedded in the low-order 32-bits. The node uses this address as its own IPv6 address.

lists the three types of IPv6 addresses, the type of node that can be assigned to that address type, and if the address holds an embedded IPv4 address.

shows how the various type of IPv6 node interoperate with the various address types.

IPv4 Loopback Address

The address 127.0.0.1 is the loopback address for many IPv4 implementations. A loopback address is a address to reach services located on the local machine. IPv4 packets addressed from or to the loopback address remain within the node; such packets are not to be sent onto the network.

IPv6/IPv4 implementations can use the IPv4-compatible IPv6 address ::127.0.0.1 as an IPv6 loopback address. Packets using address also remain entirely within the node; such packets are not to be sent onto the network.

DNS and hostname to address mapping

The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map hostnames into addresses. IPv6/IPv4 nodes must be able to interoperate directly with both IPv4 and IPv6 nodes. A new DNS resource record type named AAAA is used for 128-bit IPv6 addresses. For IPv6/IPv4 nodes the name service must also contain the traditional 32-bit IPv4 A record. This means that resolver libraries must be capable of dealing with IPv4 A records as well as IPv6 AAAA records. And IPv6/IPv4 nodes must be capable of handling both AAAA and A records.

An IPv4-compatible IPv6 addresses assigned to an IPv6/IPv4 host that supports automatic tunneling has both A and AAAA records listed in the DNS. The AAAA record holds the full IPv4-compatible IPv6 address. The A record holds the low-order 32-bits of that address. The AAAA record is needed so that queries by IPv6 hosts can be satisfied. The A record is needed so that queries by IPv4-only hosts, whose resolver libraries only support the A record type, can locate the host.

Resolver libraries need to retrieve the address that is actually requested by the application. For IPv4-compatible IPv6 addresses it is not necessary to respond to queries with both "AAAA" and "A" records if the IPv6 resolver library can extract the IPv4 address directly from the 128-bit form. It has three options:

• Return only the IPv6 address to the application.
• Return only the IPv4 address to the application.
• Return both addresses to the application.

The address type that the resolver returns can affect the type of IP traffic that occurs. If the resolver returns the IPv6 address, the node communicates with that destination using IPv6 packets. In most cases these packets are encapsulated in IPv4. If the resolver returns the IPv4 address, the node communicates with that destination using IPv4 packet.

If a DNS resolver implementation does not support automatic tunneling, then it would not return IPv4-compatible IPv6 address to applications. This is because those destinations are generally only reachable through tunneling.

If a DNS resolve implementation supports automatic tunneling, the resolver could choose to return only the IPv4-compatible IPv6 address and not the IPv4 address.

Tunneling

As the Internet transitions to IPv6 the existing IPv4 routing infrastructure can remain functional, and can be used to carry IPv6 traffic. IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over the IPv4 routing topology by encapsulating them within IPv4 packets. Tunneling can be used in a variety of ways:

• Router-to-Router — IPv6/IPv4 routers can tunnel IPv6 packets between themselves over an IPv4 infrastructure. In this case, the tunnel spans one segment of the end-to-end path that the IPv6 packet takes.
• Host-to-Router — IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary IPv6/IPv4 router over an IPv4 infrastructure. In this case, the tunnel spans the first segment of the packet's end-to-end path.
• Host-to-Host — IPv6/IPv4 hosts can tunnel IPv6 packets between themselves over an IPv4 infrastructure. In this case, the tunnel spans the entire end-to-end path that the IPv6 packet takes.
• Router-to-Host — IPv6/IPv4 routers can tunnel IPv6 packets to their final destination IPv6/IPv4 host. In this case, the tunnel spans only the last segment of the end-to-end path.

IPv6 supports two tunneling techniques; configured tunneling and automatic tunneling.

Configured tunneling — Router-to-router and host-to host-router are examples of configured tunneling. In both of these examples the IPv6 packet is being tunneled to a router. The endpoint of configured tunneling is an intermediary IPv6/IPv4 router which must dencapsulate the IPv6 packet and then forward it to its destination.

The endpoint of the tunnel is different from the destination of the packet being tunneled. The tunnel endpoint address is determined from configuration information on the node performing the tunneling. This configuration information could come in the form of a routing table entry on a host, or neighbor configuration information on a router.

Automatic tunneling — Host-to-host and router-to-host are examples of automatic tunneling. In both of these examples the IPv6 packet is tunneled directly to its final destination. The endpoint of automatic tunnel is the destination if the packet. If that address is an IPv4-compatible address, then the address holds the IPv4 address of the destination node which is used as the tunnel endpoint address. No additional configuration information is needed because the destination address is carried in the IPv6 packet being tunneled.

Automatic tunneling is a basic feature of the transition. Hosts and routers will make extensive use of automatic tunneling when there is still a significant amount of IPv4 routing infrastructure. Hosts and routers will probably use configured tunneling less frequently.

Tunneling mechanism common to automatic and configured tunneling

While the endpoints of the two tunneling techniques differ, most of the underlying mechanisms are the same:

• The entry node of the tunnel creates an encapsulating IPv4 header and transmits the encapsulated packet.
• The exit node of the tunnel receives the encapsulated packet, removes the IPv4 header, updates the IPv6 header, and processes the received IPv6 packet.

The entry node, also called the encapsulating node, might need to information for each tunnel such as the maximum transmission unit (MTU) of the tunnel. Because the number of tunnels one host could be using could be quite large this state information can be cached and then discarded when not in use. In order for IPv6-over-IPv4 tunneling to work, both nodes must be assigned IPv4-compatible IPv6 addresses.

In addition to adding an IPv4 header, the encapsulating node also has to determine when to fragment, and when and how to report ICMP error back to the source.

shows the encapsulation and dencapsulation of an IPv6 datagram in IPv4.

Dencapsulating an IPv6-in-IPv4 Packet occurs when an IPv6/IPv4 host or a router receives an IPv4 datagram that is addressed to one of its own IPv4 address and the value of the protocol field is 41. The IPv6/IPv4 host removes the IPv4 header, submits the IPv6 datagram to its IPv6 layer code, and discards the encapsulating IPv4 header. The IPv6 header is not modified. All IPv6 options are preserved even if the encapsulating IPv4 packet is fragmented. If the dencapsulating host then forwards the packet, its hop limit is decremented by one.

The dencapsulating node performs IPv4 reassembly before dencapsulating the IPv6 packet. After the IPv6 packet is dencapsulated the host processes it the same as any IPv6 packet it receives.

When encapsulating an IPv6 packet in an IPv4 datagram, the IPv4 header fields are set as shown in.

Any IPv6 options are preserved in the packet after the IPv6 header.

Tunnel MTU and Fragmentation

Gilligan and Nordmark say in RFC 1933 that the fragmentation inside the tunnel can be reduced to a minimum by having the encapsulating node track the IPv4 Path MTU across the tunnel. To accomplish this the encapsulating node would use the IPv4 Path MTU Discovery Protocol and record the resulting path MTU. The IPv6 layer in the encapsulating node can then view a tunnel as a link layer with an MTU equal to the IPv4 path MTU, minus the size of the encapsulating IPv4 header. Gilligan and Nordmark provide an algorithm to determine when to fragment and when to return an IPv6 ICMP "packet too big" message.

Hop Limit

IPv6-over-IPv4 tunnels are a single-hop. The encapsulating and dencapsulating nodes decrement the IPv6 hop limit by one when an IPv6 packet traverses the tunnel. The originating node and final destination do not decrement the hop limit. One hop hides the existence of a tunnel. The tunnel is not detectable by network diagnostic tools such as traceroute.

Handling IPv4 ICMP errors

An encapsulating node can receive IPv4 ICMP error messages from IPv4 routers inside the tunnel. The encapsulating node receives these messages because it is the IPv4 source of the encapsulated packet.

IPv4 Path MTU Discovery handles ICMP "packet too big" error messages and records the resulting path MTU in the IPv4 layer. The handling of other types of ICMP error messages varies. How the encapsulating node handles a message depends on how much information is included in the "packet in error" field. The "packet in error" field, holds the encapsulated packet that caused the error.

It is important to note that older routers only return 8 bytes of data beyond the IPv4 header of the packet in error. This is insufficient to include the address fields of the IPv6 header. More modern IPv4 routers can return enough data to include the IPv6 header fields and sometimes additional data.

If the "packet in error" has enough data, the encapsulating node can extract the encapsulated IPv6 packet. The encapsulating node can then use this IPv6 packet to generating an IPv6 ICMP message directed back to the originating IPv6 node as shown in.

Configured Tunneling

Tunneling can between two IPv6/IPv4 routers, or by an IPv6/IPv4 host to an IPv6/IPv4 router. In these cases, the tunnel does not extend all the way to the packet's final destination. It runs only as far as an intermediary router and is considered a configured tunnel.

For example, shows Router 1 as the endpoint of a tunnel in a communication between Host Alpha and Host Beta. In this example Host Alpha wants to send an IPv6 packet to Host Beta by tunneling to Router 1.

Host Alpha could encapsulate that packet in an IPv4 packet as shown in. Here the destination address in Host Alpha’s IPv4 header is the same as the low-order 32-bits of Router 1’s address. Router 1 is the tunnel endpoint. Host Alpha’s IPv6 destination address is the same as Host Beta’s address.

When Router 1 receives this packet, it removes the IPv4 header, and then processes the IPv6 header., It then forwards the IPv6 packet based on its IPv6 destination address, and delivers the packet to Host Beta.

Default Configured Tunnel

If you known the IPv4 address, you can have a configured tunnel to an IPv6/IPv4 router bordering an IPv6 backbone. And you can configure this tunnel into the routing table as a default route. Because the mask length of a default route is zero, this route is used only when no other routes with a longer mask match the destination.

The tunnel endpoint address of a default tunnel could be the IPv4 address of an IPv6/IPv4 router at the border of the IPv6 backbone or the endpoint could be an IPv4 anycast address. All of these routers accept IPv6 packets to this address and dencapsulate IPv6 packets tunneled to this address.

When an IPv6/IPv4 node sends an encapsulated packet to this address, it is delivered to only one of the border routers, but the sending node does not know which one. The IPv4 routing system generally carries the traffic to the closest router. A default tunnel to an IPv4 anycast address can provide multiple border routers that will automatically switch to another router when one goes down.

Automatic Tunneling

When automatic IPv6-over-IPv4 tunneling is used between two IPv6/IPv4 hosts, it is end-to-end. Automatic tunneling can also be used router-to-host. In automatic tunneling the destination address in the packet being tunneled must be an IPv4-compatible address. The encapsulating node extracts the IPv4 component of the destination address and uses it as the tunnel endpoint address. You can not use automatic tunneling for IPv6 packets that do not have an IPv4-compatible destination address.

The IPv6/IPv4 nodes determine which IPv6 packets can be sent through automatic tunneling. The IPv6 routing table can be used to direct automatic tunneling. For example you could have a special static routing table entry for a route to the all-zeros prefix with a 96-bit mask. (prefix 0:0:0:0:0:0/96). The host sends any packets matching this a pseudo-interface driver that performs automatic tunneling. Because all IPv4-compatible IPv6 addresses match this prefix, all packets sent to those destinations will be auto-tunneled.

Automatic tunneling is generally used between IPv6/IPv4 hosts that are connected to a common IPv4-routing infrastructure. For example, shows a communication between two IPv6/IPv4 hosts. In this example, Host Beta is the endpoint of a tunnel over the IPv4 routing infrastructure in a communication between Host Alpha and Host Beta. host Alpha.

When Host Alpha sends an IPv6 packet to Host Beta, it encapsulates that packet within and IPv4 packet as shown in. Here the source address of the encapsulating IPv4 packet is the low-order 32-bits of Host Alpha’s IPv4-compatible IPv6 address. The destination address is the low-order 32-bits of H2's IPv4-compatible IPv6 address.

When H2 receives this packet, it dencapsulates it (removes the IPv4 header), and then processes the IPv6 header as it would for any received IPv6 packet.

Tunnel addressing summary

In both types of tunneling, automatic and configured:

• The source address of the IPv4 header of the tunneled packet is the low-order 32-bits of the IPv4-compatible IPv6 address of the node that performs the encapsulation.
• The IPv4 destination address is low-order 32-bits of the IPv4-compatible IPv6 address of the tunnel endpoint.
• The intermediary routers on the path between the encapsulating node and the dencapsulating node do not look at the IPv6 header of the packet. This is true Except for header translating routers.

Intermediary routers route the packet based on its IPv4 header. This is the case even if the routers along the path are IPv6/IPv4 routers. summarizes the two types of tunneling.

Binary compatibility

In hosts equipped with both IPv4 and IPv6 support the preservation of existing IPv4 binaries is expected. In practice this can be implemented by running them over the native IPv4 stack, or by automatically converting the traffic to take place over IPv6. You might encounter some problems, for example, if manual mapping of IPv6 addresses to addresses used by the application is required.

Upgrade dependencies

summarizes the dependencies that network and system administrators must consider in planning the upgrade of systems to IPv6.

Multiprotocol Support

There is wide diversity in the protocols and services found in the network. TCP/IP is the primary protocol suit of the Internet, however other protocols such as OSI, exist natively or encapsulated as data within IP.

The multiprotocol architecture shown in uses the Internet or OSI protocol stacks to do a generic file transfer. The user always has the same interface no matter which protocol is used.

The file transfer occurs between this host and hosts supporting either the TCP/IP or OSI protocol stack shown in. The RFC 1006 stack is a mixed stack that provides upper layer OSI services using TCP/IP. This an transition architecture provides support for OSI applications without providing a full OSI implementation. The last stack is a mixed stack that provides upper layer Internet applications but uses the OSI network protocol.

OSI NSAP address plans

OSI network service access point (NSAP) address plans have been specified for a number of implementation including public data services, such as X.25 and ISDN and implementation for the usage of OSI connectionless network protocol (CLNP) using ES-IS and IS-IS routing. Required as part of the CLNP infrastructure are guidelines for NSAP address assignment as described in RFC 1629. Most of the CLNP addressing plans use either the Digital Country Code (DCC) or the International Code Designator (ICD) format. The US Government OSI Profile Version 2 (GOSIP) addressing plan is an example of an address plan that incorporates NSAP addressing.

The fraction of IPv6 address space reserved to NSAP address allocation is 1/128. shows the general format for NSAP addresses mapped into IPv6 addresses.

TIP: If you see dots within an NSAP address, they are there to help make the address easier to read. The dots are not required for an NSAP address parsing and the location of the inserted dots has no significance.

The NSAP address guidelines are quite similar to the CIDR IP addressing scheme. The major difference between the two is the size of the addresses. A CIDR address has 4 octets while a CLNP-based address has a 20 octet address space. The size of the NSAP address space provides considerable flexibility and scalabiltity. Some implementers have developed NSAP address plans that take advantage of this 20 octet address space.

It is recommended that implementers design native IPv6 addressing plans according to RFC1884, but doing so as a natural re-mapping of their CLNP addressing plans.

Address mapping between NSAP addressing and IPv6 addressing can also lead to problems in terms of routing. You can route NSAP addresses hierarchically down to an area level and then flat route them within an area. You can route IPv6 addresses hierarchically down to the physical subnet level and then flat route them physical subnet.

RFC 1888 defines four mechanisms for NSAP-IPv6 mapping that accommodates the different sizes and different approaches described in these two addressing schemes:

• Restricted NSAP address mapping into 16-octet IPv6 address.

The term restricted indicates that this format is currently restricted to a subset of the ICD and DCC formats. Restricted address mapping should occur when the first byte of an IPv6 address is hexadecimal 0x02 (binary 00000010). The remaining 15 bytes contain the restricted NSAP mapping.

• Truncated NSAP address for routing, full NSAP address in IPv6 option.

The term truncated indicates that a destination option with a complete NSAP address or an encapsulated CLNP packet is present. Truncated address mapping should occur when the first byte of an IPv6 address is hexadecimal 0x03 (binary 00000011). The remaining 15 bytes contain the truncated NSAP mapping.

• Normal IPv6 address, full NSAP address in IPv6 option
• IPv6 address carried as OSI address

Restricted NSAP address mapping into 16-octet IPv6 address

Some organizations might want to use their existing OSI NSAP addressing plan unchanged for IPv6. Note however, that an organization that uses both native IPv6 addresses and NSAP addresses for IPv6 would be likely to have inefficient internal routing. shows restricted NSAP address mapping into the 16-octet IPv6 address space.

Restricted NSAP address mapping relies on the fact that the longest CLNP routing prefixes known to be in active use today are 5 octets. This means the semantics of existing 20-octet NSAP addresses can be fully mapped. GOSIP and DECnet/OSI are two examples where the address semantics are fully mapped.

The AFcode nibble is overloaded, and encoded as follows:

0000-1001 (0 - 9 decimal)1010 (hex. A)	Implied AFI value is 39 (DCC). IDI is the three BCD digits of the DCC.
1011-1111 (hex. B - F)	Reserved, not to be used.

Hosts using restricted NSAP addresses can be configured using IPv6 stateless address autoconfiguration. Such hosts can also use normal IPv6 neighbor discovery mechanisms as described in RFC1970.

Restricted NSAP addresses can be used in IPv6 routing headers if they can be fully routed using IPv6 routing protocols. Packets whose destination address is a restricted NSAPA can be routed using any normal IPv6 routing protocol only as far as the Area. No IPv6 routing protocol can route the packet to the correct router if there is more than one physical subnet that can be reached by several router.

NOTE: If you are using both normal IPv6 address and restricted NSAP addresses, route aggregation does not occur because the addresses differ from the second most significant bit onwards. This means you will incur a significant operational penalty.

Truncated NSAP address used as an IPv6 address

An NSAP address contains routing domain and area/subnet identifiers. The format and length of this information is compatible with a 16-octet IPv6 address and can representing using the format shown in.

If you use this form of address mapping, either an NSAP address destination option or an encapsulated CLNP packet must be present.

A truncated NSAP address can be used as either a destination or source IPv6 address. Used as a destination address it can be interpreted as an IPv6 anycast address. For example, the truncated NSAP address could identify the endpoint of a CLNP tunnel (an IPv6 node) or an OSI capable system in a subnet (an OSI intermediate or end system).

Used as a source address, a truncated NSAP address must be interpreted as a unicast address and must be unique within the IPv6 address space. Truncated NSAP addresses are not meaningful within IPv6 routing headers.

Normal IPv6 address, full NSAP address in IPv6 option

This mechanism relies on either of two destination option configurations. The first involves an IPv6 source node using normal unicast or anycast IPv6 addresses to supply an NSAP destination option header to the IPv6 destination node. The second option involves an IPv6 source node using a truncated NSAP address in place of a normal IPv6 address as the destination. shows the formation of the NSAP address destination option.

The option type code is 11-0-00011 (195 decimal) and the NSAP encoding follows ISO/IEC 8348 exactly. If you use this option, both end systems should use NSAP addresses.

IPv6 address carried as OSI address

This mapping mechanism allows the embedding of an IPv6 addresses inside a 20-octet NSAP addresses. You might want to use this mechanism to allow CLNP packets that encapsulate IPv6 packets to be routed in a CLNP network. shows the address format for this mechanism.

In this example the first three octets are an IDP in binary format and use the AFI code that is in the process of being allocated to IANA. Here the AFI value of 35 with an ICP value of zero means that "this NSAP embeds a 16 byte IPv6 address"). The third octet of the IDP is the Internet Code Point (ICP) and must be zero. This octet must be present, but it has no significance for IPv6. Its default value is zero. All other values are reserved for allocation by the IANA.

Embedded IPv6 addresses must not have he prefixes 0x02 or 0x03 . In addition, NSAP address with the IANA AFI code must not be embedded in an IPv6 header.

Combined IPv4 and IPv6 sending algorithm

RFC 1933 describes the combined IPv4 and IPv6 sending algorithm summarized here. This is just a example, the actual sending algorithm used may vary between IPv6/IPv4 implementations. An implementation can use the algorithm to determine when to send an IPv4 or IPv6 packet and when to perform automatic or configured tunneling.

The algorithm summarized in, shows how you can use the techniques of dual IP layer, configured tunneling, and automatic tunneling together. The sample algorithm follows the table. The sending algorithm has the following properties:

• Sends IPv4 packets to all IPv4 destinations.
• Sends IPv6 packets to all IPv6 destinations on the same link.
• Uses automatic tunneling and sends IPv6 packets encapsulated in IPv4 to IPv6 destinations with IPv4-compatible addresses that are located off-link.
• Sends IPv6 packets to IPv6 destinations located off-link when IPv6 routers are present.
• Uses the default IPv6 tunnel and sends IPv6 packets encapsulated in IPv4 to IPv6 destinations with IPv6-only addresses when no IPv6 routers are present.

A sample sending algorithm

The sample sending algorithm follows:

1. If the address of the end node is an IPv4 address then:

1. If the destination is located on an attached link, then send an IPv4 packet addressed to the end node.
2. If the destination is located off-link, then;

• If there is an IPv4 router on link, send an IPv4 format packet. The IPv4 destination address is the IPv4 address of the end node. The datalink address is the datalink address of the IPv4 router.
• Else, the destination is treated as unreachable because it is located off link and there are no on-link routers.

2. If the address of the end node is an IPv4-compatible IPv6 address with the prefix 0:0:0:0:0:0, then:

1. If the destination is located on an attached link, send an IPv6 format packet (not encapsulated). The IPv6 destination address is the IPv6 address of the end node. The datalink address is the datalink address of the end node.
2. If the destination is located off-link, then:

• If there is an IPv4 router on an attached link, send an IPv6 packet encapsulated in IPv4. The IPv6 destination address is the address of the end node. The IPv4 destination address is the low-order 32-bits of the end node's address. The datalink address is the datalink address of the IPv4 router.
• Else, if there is an IPv6 router on an attached link, send an IPv6 format packet. The IPv6 destination address is the IPv6 address of the end node. The datalink address is the datalink address of the IPv6 router.
• Else, the destination is treated as unreachable because it is located off-link and there are no on-link routers.

3. If the address of the end node is an IPv6-only address, then:

1. If the destination is located on an attached link, send an IPv6 format packet. The IPv6 destination address is the IPv6 address of the end node. The datalink address is the datalink address of the end node.
2. If the destination is located off-link, then:

• If there is an IPv6 router on an attached link, send an IPv6 format packet. The IPv6 destination address is the IPv6 address of the end node. The datalink address is the datalink address of the IPv6 router.
• Else, if the destination is reachable through a configured tunnel, and there is an IPv4 router on an attached link, send an IPv6 packet encapsulated in IPv4. The IPv6 destination address is the address of the end node. The IPv4 destination address is the configured IPv4 address of the tunnel endpoint. The datalink address is the datalink address of the IPv4 router.
• Else, the destination is treated as unreachable because it is located off-link and there are no on-link IPv6 routers.

On/Off Link Determination

Part of the process of whether to send an IPv4 packet format or IPv6 packet format is determining where the destination address is located: on the attached link or off the attached link. IPv4 and IPv6 use different methods to determine the location of the destination address.

IPv4 nodes logically AND the destination and the interface addresses with the netmask of the interface and compare them. RFC 1122 "Requirements for Internet Hosts - Communication Layers" describes this process.

IPv6 nodes uses the neighbor discovery algorithm described in RFC 1970, "Neighbor Discovery for IP Version 6."

IPv6/IPv4 nodes need to use both methods:

outlines how different types of sending nodes determine the on/off link status of the destination address.

IPv6/IPv4 dual node structure

A possible structure for an IPv6/IPv4 dual node at the Network, Internet, and Transport layers is shown in.

Paths 1 and 2 represent testing paths to use with transport drivers for IPv4

Paths 3 and 4 represent tunneling paths

From Here…

This chapter introduced some certification and key distribution methods, identified some key management issues, and provided a listing of some IPv6 key management requirements. It also described some issues revolving around security implementations for IPv6 and provided a brief overview of some key management protocols

For additional information, you may want to see the following:

Chapter 6 "IPv6 Addressing" describes the IPv6 addressing architecture.

Chapter 15 "IP Address Management Preparing forIPv4 and IPv6" describes the role of DHCP, CIDR, and other address configuration options and some strategies to conserve the IPv4 address space, for renumbering networks, and minimizing the impact of migrating to IPv6.

Chapter 17 "Advanced Sockets API for IPv6" describes this application layer API for IPv6

Chapter 18 "Possible Alternative to IPV6 to handle addressing" describes some address alternatives other than IPv6 to handle the current addressing situation on the Internet. This chapter includes a discussion of the pros and cons of using NAT as an addressing alternative.