by Bob Fink
Margaret Wasserman, Wind River,
Jun-ichiro Itojun Hagino, IIJ

During 2002, the Internet Engineering Task Force (IETF) determined that it was best to focus the introduction of IPv6 into the IPv4 Internet by developing deployment scenarios before further development of transition mechanisms without any clearly identified framework for their place in an IPv6 deployment.

Previously the IPv6 Transition working group of the IETF, called ngtrans (for IP next-generation transition), was chartered to develop mechanisms and tools to support an IPv6 transition. This work initially focused, in 1995-1996, on the development of the original IPv6 standards, and it led to the basic Transition Mechanism RFC 1933[1] and later RFC 2893[2] that defined dual IPv4 and IPv6 protocol stack operation as well as IPv6-over-IPv4 tunnels.

Subsequent attempts to define a framework for transition in 1998-1999 were not successful because there did not appear to be a single vision for a transition to IPv6. Indeed the focus became one of how to have IPv4 and IPv6 coexist for a long period of time, because most felt that a full transition could take well over 10-15 years, with many believing that it would never completely obsolete IPv4. This led to the development of many transition mechanisms and tools, some of which might possibly be more useful than others, that never fit into a coherent framework for operation of a dual protocol , that is, IPv4 and IPv6, network.

v6ops
Thus in 2002 the ngtrans working group was disbanded, and the IPv6 Operations working group, v6ops, created. The v6ops working group was chartered to:

	Solicit input from network operators and users to identify operational or security issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. This includes identifying standards work that is needed in other IETF working groups or areas and working with those groups or areas to begin appropriate work. These issues will be documented in Informational or Best Current Practice (BCP) RFCs, or in Internet-Drafts. For example, important pieces of the Internet infrastructure such as the Domain Name System (DNS), the Simple Mail Transfer Protocol (SMTP), and the Session Initiation Protocol (SIP) have specific operational issues when they operate in a shared IPv4/IPv6 network. The v6ops working group will cooperate with the relevant areas and working groups to document those issues, and find protocol or operational solutions to those problems.
	Provide feedback to the IPv6 working group regarding portions of the IPv6 specifications that cause, or are likely to cause, operational or security concerns, and work with the IPv6 working group to resolve those concerns. This feedback will be published in Internet-Drafts or RFCs.
	Publish Informational RFCs that help application developers (within and outside the IETF) understand how to develop IP version-independent applications. Work with the Applications area, and other areas, to ensure that these documents answer the real-world concerns of application developers. This includes helping to identify IPv4 dependencies in existing IETF application protocols and working with other areas or groups within the IETF to resolve them.
	Publish informational or BCP RFCs that identify potential security risks in the operation of shared IPv4/IPv6 networks, and document operational practices to eliminate or mitigate those risks. This work will be done in cooperation with the Security area and other relevant areas or working groups.
	Publish Informational or BCP RFCs that identify and analyze solutions for deploying IPv6 within common network environments, such as Internet Service Provider (ISP) networks (including core, Hybrid Fiber-Coaxial [HFC] or cable, DSL, and dialup networks), enterprise networks, unmanaged networks (home or small office), and cellular networks. These documents should serve as useful guides to network operators and users on how to deploy IPv6 within their existing IPv4 networks, as well as in new network installations.
	Identify open operational or security issues with the deployment scenarios documented in the previous bullet point and fully document those open issues in Internet-Drafts or informational RFCs. Try to find workarounds or solutions to basic, IP-level operational or security issues that can be solved using widely applicable transition mechanisms, such as dual-stack, tunneling, or translation. If the satisfactory resolution of an operational or security issue requires the standardization of a new, widely applicable transition mechanism that does not properly fit into any other IETF working group or area, the v6ops working group will standardize a transition mechanism to meet that need.
	Assume responsibility for advancing the basic IPv6 transition mechanism RFCs along the standards track, if their applicability to common deployment scenarios is demonstrated.

v6ops has started by creating four efforts to define transition scenarios and subsequently to analyze them for potential solutions to the deployment scenarios. These four efforts follow:

	Third Generation Partnership Project (3GPP) defined packet networks, that is, General Packet Radio Service (GPRS) that would need IP Version 6 deployment into the IPv4 Internet.
	"Unmanaged networks," which typically correspond to home networks or small office networks.
	ISP networks, including core, HFC or coaxial, DSL, dialup, public wireless, broadband Ethernet, and Internet exchange points.
	Enterprise networks, which are networks that have multiple links and a router connection to an ISP, and are actively managed by a network operations entity.

During 2003 and 2004 it is expected that these deployment scenario efforts will lead to further analysis and identification of deployment solutions and development of appropriate mechanisms to support them.

In addition to this work, serious efforts are under way to engage the entire IETF standards process in the identification and development of appropriate solutions for an IPv6 deployment. One such effort is the IPv4 Survey project, which has reviewed the entire IETF RFC catalog of standards to identify what work might need to be done and to disseminate this information to the appropriate area within the IETF.

As progress is made in v6ops, follow-up articles in IPJ will inform you of these efforts.

For Further Reading
[1] "Transition Mechanisms for IPv6 Hosts and Routers," R. Gilligan and E. Nordmark, RFC 1933, April 1996.

[2] "Transition Mechanisms for IPv6 Hosts and Routers," R. Gilligan and E. Nordmark, RFC 2893, August 2000.

ROBERT FINK is a retired U.S. national laboratory network researcher working with the IPv6 Forum. He is currently a co-chair of the IETF v6ops (IPv6 Operations) working group, and leads the 6bone project. You can reach him at: bob@thefinks.com

MARGARET WASSERMAN is a Principal Technologist at Wind River. She is currently a co-chair of the IETF IPv6 and v6ops working groups. You can reach her at: mrw@windriver.com

JUN-ICHIRO ITOJUN HAGINO is a network researcher with IIJ Research Laboratory. He is currently a co-chair of the IETF v6ops working group and a member of the IETF IAB. You can reach him at itojun@iijlab.net