Framework for IP Version Transition Scenarios
Department of Computer Science
University of Auckland
PB 92019
Auckland
1142
New Zealand
brian.e.carpenter@gmail.com
Huawei Technologies Co., Ltd
Huawei Building, No.3 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing
P.R. China
shengjiang@huawei.com
Rogers Communications
Canada
Victor.Kuarsingh@rci.rogers.com
Operations
V6OPS
This document sets out a framework for the presentation of scenarios and
recommendations for a variety of approaches to the transition from IPv4 to IPv6,
given the necessity for a long period of co-existence of the two
protocols.
This document sets out a framework for the presentation of scenarios and
recommendations for a variety of approaches to the transition from IPv4 to IPv6,
given the necessity for a long period of co-existence of the two
protocols. A general "call to arms" for transition is found in ,
and a recommendation for four principal scenarios is given in
. A report on experience and plans
of various Internet Service Providers (ISPs) is given in
. However, it is clear that operators require
more detailed technical recommendations than are available so far.
Unfortunately, the number
of different combinations of existing IPv4 deployment models, customer profiles
and requirements, and possible coexistence and transition models, is enormous,
so it is quite impracticable to produce either a set of recommendations for each
case, or a recommended "one size fits all" model. That is why this document proposes
a set of topics or dimensions, as a framework for a reasonable number of
recommendation documents.
The reader is assumed to be familiar with IPv6. The IETF's
view of core IPv6 requirements is to be found in
(currently being updated as ). However,
this does not give a complete view of mechanisms an ISP may need to deploy, since
it considers the requirements for an individual node, not for a network or
service infrastructure as a whole.
discussed scenarios for introducing IPv6 into ISP networks, as the problem
was viewed some years ago.
Its end goal was simply a dual-stack ISP backbone. Today's view is that
this is insufficient, as it does not allow for prolonged interworking between IPv6-only and legacy (IPv4-only)
hosts. Indeed, the end goal today might be an IPv6-only ISP backbone, with some form of
legacy IPv4 support .
Although the basic IPv6 standards are stable, considerable
work continues in several IETF working groups, on issues such as multihoming,
tunneling, and IP layer interworking between IPv6-only and IPv4-only hosts.
However, operators faced with IPv4 address exhaustion in the coming few years
need immediate guidance. These operators cannot avoid the need for general skills
acquisition, or the need to write their own detailed deployment plan, but
they also need guidance for generic scenarios similar to their actual situation.
They cannot obtain such guidance from individual protocol specifications developed
by the IETF, so there is a need for additional documents.
On the assumption that a series of documents are produced describing and recommending
transition scenarios, there are two basic conditions:
The documents will not be primary protocol specifications, because those are
the outcome of IETF working groups chartered to work on specific protocol mechanisms.
The documents are addressed to service providers who have taken the decision to support
IPv6, have acquired basic knowledge and skills, have determined how they will
obtain upstream IPv6 connectivity, and are ready to write their operational plan
for transition.
The documents should describe scenarios for real transition to IPv6, not life
extensions to IPv4 or other matters best handled in other working groups.
They should each cover some or all of the following aspects or dimensions:
For the convenience of readers, each document should briefly describe its
network model in the Abstract (or Introduction) for quick reference.
The documents should explain how certain technology components fit together
in a given transition and co-existence scenario.
They will present major generic network models, and their subsets, which exist (or are firmly planned) today, including network topologies and/or architectures.
They should specify their scope: the range of technologies that they do or do not apply to
(e.g. specific access network technologies, core network technologies and topologies,
mobile vs fixed hosts, business vs private customers, etc.).
They should develop analysis criteria on how to recognize appropriate transition technologies for
existing provider networks within their scope. This should include information related to deployed protocols and functions which may assist or hinder various transition technologies from being deployed.
If multiple transition technologies are needed for provider
environments where access networks differ and have various capabilities, the documents should show
how these technologies can be deployed simultaneously.
They should describe how multiple technologies can co-exist, if necessary, during all
stages of migration (e.g., moving from IPv4 Only to Dual-Stack to DS-Lite to NAT64).
They should cover considerations for legacy operation while moving to IPv6 and its
transition technologies. Many operators will have large quantities of IPv4-only equipment
which cannot feasibly be upgraded until the end of its economic life, or which
is under customer control.
They should cover considerations which apply when retro-fitting various technologies to existing networks. Included in this would be impacts on ancillary protocols, routing platforms/systems, security policies, provisioning systems, network services (i.e. DHCP, DNS etc), law enforcement procedures and more.
They should quantify scaling characteristics of deployment modes for each technology model and intersections during co-existence (e.g. if some of the Network is DS-Lite and some is classical Dual Stack; peak load
on NAT64; etc.).
The documents should include security considerations for their specific transition scenario(s).
A desirable outcome would be a set of Best Current Practice (BCP) or advisory (Informational)
documents for a range of generic deployment models and how they fit into a network, including key
services such as subscriber authentication, DHCP, and DNS. However, it must not be forgotten that every
service provider is different and such documents can never replace specific deployment plans
drawn up by each individual service provider.
Service providers will insist on having security for IPv6 services,
and for all transition technologies, that is at least as good as for
IPv4 services in all respects. Particular attention must be paid to
security exposures that are specific to transition and coexistence
mechanisms. Thus, all recommendations for transition
scenarios must include any security aspects that are specific to that scenario.
This document makes no request of the IANA.
Useful comments and contributions were made by Randy Bush and other members of the V6OPS WG.
This document was produced using the xml2rfc tool
.
draft-ietf-v6ops-v4v6tran-framework-01: small addition following WGLC, 2011-02-02
draft-ietf-v6ops-v4v6tran-framework-00: adopted by WG at IETF 79, 2010-12-01
draft-carpenter-v4v6tran-framework-00: original version, 2010-08-18
&RFC2629;
&RFC4029;
&RFC4294;
&RFC5211;
&RFC6036;
&DRAFT-nodereq;
&DRAFT-arkko;