There are numerous mechanisms that support a step-by-step introduction of IPv6. There is no one mechanism that can cover all requirements or be optimal for all scenarios. In most cases, a combination of different mechanisms will be chosen. What the best combination and sequence are depends on the infrastructure of the current environment and the goals and requirements for the transition/integration. In the IETF, the work on the basic protocol is completed. They now focus on developing practical scenarios for different types of environments, and the results are published. We offer a summary here, not with the intent to deliver a cookbook for your environment, but rather to provide food for thought that you can apply to your requirements.

Organizations

To connect a single host or a small network with the IPv6 Internet is not a big challenge and can be done with one of the tunnel mechanisms described earlier. It is easy to implement with most operating systems.

If you have a public IPv4 address and want access to the IPv6 Internet, 6to4 or a Tunnel Broker can be used. If you have NAT in place and make use of private IPv4 addresses, you may choose to use Teredo or Proto 41 Forwarding if the NAT box supports it. Organizations that have the privilege of their providers offering native IPv6 connections can have a dual-stack Internet connection. Dual-stack is in many cases the easiest way to go if your devices and operating systems support IPv6 (and they do if they are on an up-to-date level). If you have routers or layer 3 switches that do not support IPv6, or if you do not want to enable IPv6 on your routers for some reason, you can use ISATAP for internal IPv6 communication on your IPv4 network. You can then also add an ISATAP or 6to4 router to access the IPv6 Internet if desired.

Many organizations have a number of IPv4 Virtual LANs (VLANs). In such situations, an IPv6 router can advertise one single IPv6 prefix into all VLANs that support dual-stack communication. This is only advisable for a transition period, though. All the IPv6 nodes in the VLANs can autoconfigure for an IPv6 address using the prefix advertised by the IPv6 router.

The tunnel mechanisms do not only support the transport of IPv6 over the IPv4 Internet, but also internally over an IPv4 backbone. A backbone upgrade is not something you choose to do every year; you probably want to wait for the end of the backbone router lifecycle before touching it. This does not prevent rolling out IPv6 at the edge of the network. As long as the backbone is based on IPv4, IPv6 packets are tunneled to IPv6 islands on the other side.

RFC 4057, "IPv6 Enterprise Network Scenarios," is an RFC that assists you in identifying your enterprise transition strategy. It describes different scenarios for IPv6 deployment within enterprise networks and provides guidance and checklists of how to approach this task. This RFC includes enterprises that decide to deploy IPv6 in conjunction with IPv4, or to deploy IPv6 because of a specific set of applications that it wants to use over an IPv6 network, or to build a new network or restructure an existing network and decides to deploy IPv6 as the predominant protocol within the enterprise in coexistence with IPv4. The document then reviews a set of network infrastructure components common to most enterprises that must be analyzed.

ISPs

IPv6 is designed to enable Internet Service Providers (ISP) to meet the challenges with the exponential growth of the Internet and to provide new services to their customers. The number of devices will explode in the coming years, a challenge that can be met only with the address space of IPv6. Cable, DSL, wireless, and other always-on technologies can also benefit from the address space. Other benefits of IPv6 include the capability to enhance end-to-end security and mobile communications, and to ease system managementburdens. Some examples include peer-to-peer communication without NAT traversal problems, being able to securely access devices and applications at work from home or vice versa, enhanced IP Mobility, and many more.

Therefore, ISPs have to evaluate the capabilities of IPv6 to meet these needs. Some countries have taken a lead role in this area and moved from testing and evaluation to real deployments of IPv6 in the broadband arena. Japan is a prime example, along with other countries that are looking at moving towards large-scale production deployments of IPv6.

ISPs will have to offer both IPv4 and IPv6 services in the coming years. To provide access to IPv6 networks to customers in a first phase, tunnel mechanisms can be used. This is a simpler and more economical method to start offering IPv6 services. Depending on customer needs and requirements, a native IPv6 deployment option might be more scalable and provide better service performance. You may be able to use the next due backbone upgrade and introduce dual-stack. All other services such as web hosting, email, and FTP are best if offered for both protocols (IPv4 and IPv6). The migration steps should be well-planned, and a useful combination of mechanisms chosen and implemented. The main goal for an ISP will be to offer all of the services over both protocols: this is the only way to cover the whole market. Especially for ISPs, the introduction of IPv6 offers the possibility to create business opportunities and new service offerings.

RFC 4029, "Scenarios and Analysis for Introducing IPv6 into ISP Networks," analyzes the challenges and opportunities for ISPs and discusses different integration and transition scenarios, divided into exploring backbone transition actions, customer connection transition actions, and network and service operation actions. Draft-ietf-v6ops-bb-deployment-scenarios-04.txt presents the options available in deploying IPv6 services in the access part of a broadband Service Provider network, namely Cable/HFC, Broadband Ethernet, xDSL, WLAN, and PLC/BPL. It briefly discusses the other elements of a provider network as well. It provides different viable IPv6 deployment and integration techniques and models for each of the previously mentioned broadband technologies. Draft-shin-v6ops-802-16-deployment-scenarios-00.txt extends the discussion in the previous draft and goes into deployment scenarios for wireless broadband access networks. RFC 3574 discusses transition scenarios for 3GPP networks. RFC 4215 goes into more details for 3GPP networks and is an additional document to RFC 3574.