Internet Protocol version 6 deployment

Template:TOC-right It is necessary to have a basic idea of how IPv6 works in order to understand an explanation of deploying it; see Internet Protocol version 6. Not every detail is relevant, but some of the more critical aspects include addressing administration, address assignment, appropriate Domain Name System (DNS).

Transition terminology

Some terminology will help structure the discussion. From RFC 2893, there are definitions of node types and mechanisms of coexistence.

An additional discussion gets more into the routing aspets of transition; it is intended only for interim cutover.

Node types

• 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.
  • Dual stack node: A host or router whose IPv4 and IPv6 stacks never need to interconnect, and whose interface(s) are connected only to a pure IPv4 or IPv6 network. Ideally, the nature of the application being IPv4 or IPv6 is hidden from the user, and only the host or router administrator is aware of the dual stacks.
• IPv6-only node: A host or router that implements IPv6 and does not implement IPv4. See the easiest case below.
• IPv6 node: Any host or router that implements IPv6. IPv6/IPv4 and IPv6-only nodes are both IPv6 nodes.
• IPv4 node: Any host or router that implements IPv4. IPv6/IPv4 and IPv4-only nodes are both IPv4 nodes.

Transition techniques

RFC identifies two basic transition techniques. Of course, the ideal is when the network and hosts have no legacy IPv4 requirements, and can be all-IPv6 from the first day.

There are two "basic" tunneling modes:

• IPv6-over-IPv4 tunneling: The technique of encapsulating IPv6 packets within IPv4 so that they can be carried across IPv4 routing infrastructures.

• Configured tunneling: IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address(es) are determined by configuration information on tunnel endpoints. All tunnels are assumed to be bidirectional. The tunnel provides a (virtual) point-to-point link to the IPv6 layer, using the configured IPv4 addresses as the lower-layer endpoint addresses.

Other, more complex techniques, involve either a viable application layer gateway between separate IPv4 and IPv6 universes, or some type of translation between IPv4 and IPv6 packets:

• 6to4: Assigns an interim unique IPv6 address prefix to a site with at least one globally routable IPv4 address, and specifies an encapsulation mechanism for transmitting IPv6 packets using such a prefix over the global IPv4 network. Potential scaling problems are known to exist, although it does not increase the size of the IPv4 global routing table, and adds one entry to the IPv6 global routing table.

• ISATAP: An address assignment and host-to-host, host-to-router, and router-to-host automatic tunneling technology that is used to provide unicast IPv6 connectivity between IPv6/IPv4 hosts across an IPv4 intranet. ISATAP is fully compatible with autoconfiguration

• TEREDO: The TEREDO service is a mechanism where the IPv6 packets are carried over a IPv4 network, with the additional constraint that the "TEREDO servers" are located on the "inside" of an IPv4 to IPv4 network address translation device. In addition to the stateless TEREDO servers, there are TEREDO relays, which appear, to the IPv6-only hosts, as IPv6 routers.

Deployment and coexistence principles

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. The simplest form of coexistence comes when only the external routers need to be aware of the other protocok family; they tunnel the less widely deployed protocol over an infrastructure belonging to the more widely deployed. Tunneling protocols are not a panacea, as they may introduce issues, especially when their overhead limits the maximum transmission unit size that can be used by the "payload" protool.

True migration will exist only when 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, or there are "islands" of IPv6-only nodes that only need to deal with IPv4 for inter-island transportation.

IPv4-only nodes can communicate with IPv6-only nodes only when using an IPv4-to-IPv6 proxy or translation gateway.

Considering specific situations

To have meaningful discussions of deployment, the problem has to be stated in terms of:

• The types of end nodes required
• The cases where the other protocol family needs to supply some part of connetivity
• Any constraints that apply to the transfer of information over a "foreign" connectivity medium, such as MTU size or support of a particular per-hop behavior not supported in the foreign protocol
• Operational requirements such as multihoming, especially when multiple providers are involved

An inventory is a fine place to start. Determine:

• which hosts will never speak to anything that is not completely IPv6, such as the internals of the cellular network
• which hosts can be completely proxied at an application level

Basic scenarios

The easiest case

The ideal situation for IPv6 introduction is one in which there is no particular need for compatibility with any existing networks. This has been the case in several situations, such as advanced cellular telephony networks, in which the Internet Protocol addressing is purely internal to the network. The telephones continue to use telephone numbers, not IP addresses.

Most major operating systems and routers have IPv6 support, as well as common support services such as domain name service

In this case, there is no immediately obvious need for IPv6-IPv4 interaction. Do no be surprised, however, if some infrastructure devices, such as a protocol analyzer, network management system, or security device, which you want to use, is not IPv6 compatible, and will present a relatively small coexistence or transition challenge.

Connecting islands

For a variation of the pure IPv6 environment, assume you have three locations that are all IPv6. Your challenge is that there is no economically attractive way to interconnect those sites with direct physical leased line. Somehow, you will have to use the IPv4 public Internet, or a provider-provisioned virtual private network from a IPv4 service provider, to interconnect the three sites.

In this situation, only the routers interconnecting the sites will need to be IPv4 aware. While tunneling protocols are not perfect, they may be a reasonable interim solution.

100% application proxy

Another situation where IPv6 may be minimally disruptive is in a country that has no existing Internet infrastructure, and, for various national policy reasons, will permit no direct connections to the Internet; everything must go through a firewall/application proxy. All machines going into the "inside" can be natively IPv6. Again recognizing this as an ideal situation, assume that any Web requests will only use DNS names. The "inside" HTTP requests terminate at an application-layer proxy, which then takes the name in the URL, looks it up in an IPv4 DNS, speaks to the web server, gets the application data, and transfers the application data in the proxy. As long as there are no embedded IP addresses, this may well work. Of course, the Web is not all of the Internet, and the scenario described is Web only, and for those web pages that never embed IP addresses.

Vendor support

Operating system

• Linux
• Mac OS
• Microsoft Windows

Router

• Cisco
• Juniper
• Quagga