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.

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.

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