Individual Submission E. Jankiewicz (Ed.)
Internet Draft SRI International, Inc.
Intended status: Informational October 5, 2010
Expires: April 2011
An Annotated Bibliography for IPv4-IPv6 Transition and Coexistence
draft-jankiewicz-v6ops-v4v6biblio-01.txt
Abstract
The Internet is in the early stages of what may be a protracted
period of coexistence of IPv4 and IPv6. Network operators are
challenged with the task of activating IPv6 without negative impact
on operating IPv4 networks and their customers. This draft is an
informational "annotated bibliography" compiled to help in the
analysis and development of basic guidelines and recommendations for
network operators. The goal of this document is to survey the
current state of RFCs, Internet-Drafts and external reference
materials that define the use cases, problem statements, protocols,
transition mechanisms and coexistence tools that will be of interest
to a network operator planning to turn on IPv6.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 5, 2009.
Jankiewicz (Ed.) Expires April 5, 2011 [Page 1]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction......................................... 3
2. IPv6 and related Protocol Specifications.................. 4
3. Problem Statements and Use Cases........................ 4
4. Deployment Scenarios and Architectures................... 5
5. How-to, Whitepapers and FAQs ........................... 5
6. Transition/Coexistence Tools ........................... 6
6.1. Address Mapping.................................. 7
6.1.1. Dual-Stack Lite (DS-lite)...................... 8
6.2. Tunneling Mechanisms............................. 10
6.2.1. Teredo.................................... 10
6.2.2. IPv6 Rapid Deployment (6rd)and Extensions........ 10
6.2.3. Tunnel Support Protocol (TSP) ................. 11
6.2.4. Residual IPv4 Deployment over IPv6-only Infrastructure11
6.2.5. Address Plus Port (AplusP).................... 11
6.2.6. IRON-RANGER and ISATAP Solutions............... 12
6.3. Translation.................................... 13
6.3.1. Historic Approach........................... 13
6.3.2. Current Translation Approaches................. 13
6.3.2.1. An IPv6 network to the IPv4 Internet........ 15
6.3.2.2. The IPv4 Internet to an IPv6 network........ 15
6.3.2.3. The IPv6 Internet to an IPv4 network........ 15
6.3.2.4. An IPv4 network to the IPv6 Internet........ 16
6.3.2.5. An IPv6 network to an IPv4 network......... 16
6.3.2.6. An IPv4 network to an IPv6 network......... 16
6.3.2.7. The IPv6 Internet to the IPv4 Internet...... 16
6.3.2.8. The IPv4 Internet to the IPv6 Internet...... 16
7. Prefix and Address Assignment and Distribution............ 16
8. Experiments, Trials and Prototypes...................... 17
9. Implementation Reports ............................... 18
10. Books on IPv6...................................... 18
11. Miscellaneous...................................... 18
12. Security Considerations.............................. 19
Jankiewicz (Ed.) Expires April 5, 2011 [Page 2]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
13. IANA Considerations................................. 19
14. Conclusions........................................ 19
15. References ........................................ 20
15.1. Normative References............................ 20
15.2. Informative References .......................... 20
16. Acknowledgments.................................... 20
1. Introduction
Since the IPv6 protocol was defined in 1995 as RFC 1883 (replaced in
1998 by RFC 2460) the Internet has been in a long transition from
IPv4 to IPv6. In reality, we are still in the early stages of what
is likely to be a protracted period of coexistence, where IPv6
penetration in hosts (both servers and clients) will gradually ramp
up as networks make IPv6 available through their infrastructures.
Network operators face a daunting task to design and implement plans
to activate IPv6 without negative impact on large (in some cases very
large) operating IPv4 networks with many live customers. Some basic
guidelines and recommendations for network operators are being
developed (http://tools.ietf.org/html/draft-lee-v4v6tran-problem) and
this draft is an informational companion to that effort. The goal of
this document is to survey the current state of RFCs, active (and
expired but still relevant) Internet-Drafts and external reference
materials that define the use cases, problem statements, protocols,
transition mechanisms and coexistence tools that will be of interest
to a network operator planning to turn on IPv6.
This is a dynamic and evolving marketplace of ideas. At best, this
draft is a blurry snapshot of the landscape near to the time of its
publication. The editor intends this compendium to be merely the
starting point for an active database or wiki available for community
contribution including feedback on the real-world experience of
network operators as they turn on IPv6.
The following sections comprise an annotated bibliography of the
currently available documentation to knowledge of the editor. It is
provided as informational guidance only, and any network operator
contemplating an IPv6 implementation will of course exercise due
diligence in researching all the issues, standards and
recommendations and analyze applicability to the particular network
operation.
Note that as the body of this text includes full reference
information for the bibliography entries these are not included in
the normal Reference section.
Jankiewicz (Ed.) Expires April 5, 2011 [Page 3]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
[Editor's note to be removed before publication:
While this draft is circulating, the editor is interested in any and
all pointers to additional useful references. Contributions of
capsule summaries and applicability for any of the listed entries
would also be appreciated and will be graciously acknowledged. If I
have missed anyone who already chipped in, this will be cheerfully
rectified upon your reminder via a private e-mail. ]
2. IPv6 and related Protocol Specifications
"IPv6 Node Requirements" J. Loughney, Ed. April 2006
http://tools.ietf.org/html/rfc4294
"IPv6 Node Requirements RFC 4294-bis" E. Jankiewicz, J. Loughney, T.
Narten
http://tools.ietf.org/html/draft-ietf-6man-node-req-bis
RFC 4294 and its update draft are included by reference. These
provide a comprehensive overview of the IPv6 baseline specifications
and the reader is directed to them to avoid a redundant listing here.
3. Problem Statements and Use Cases
"Problem Statements of IPv6 Transition of ISP" Y. Lee, Ed.
http://tools.ietf.org/html/draft-lee-v4v6tran-problem
This draft is being developed by an ad-hoc group interested in
providing guidance to network operators on the IPv6 transition. It
will include high level use cases (as contributed by IETF
participants with network operator experience) and a problem
statement documenting what additional work IETF could do to provide
sufficient tools and guidance for the network operators
"Mobile Networks Considerations for IPv6 Deployment" R. Koodli
http://tools.ietf.org/html/draft-ietf-v6ops-v6-in-mobile-networks
Mobile Internet access from smartphones and other mobile devices is
accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen
as crucial for the continued operation and growth of the Internet,
and in particular, it is critical in mobile networks. This document
discusses the issues that arise when deploying IPv6 in mobile
networks. Hence, this document can be a useful reference for service
providers and network designers.
Jankiewicz (Ed.) Expires April 5, 2011 [Page 4]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
"Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement
and Proposed Mitigations", G. Nakibly and F. Templin
http://tools.ietf.org/html/draft-ietf-v6ops-tunnel-loops
"Use Case for IPv6 Transition for a Large-Scale Broadband Service" H/
Tian and XY. Li
http://tools.ietf.org/html/draft-tian-v4v6tran-broadband-sp-usecase
[v4v6 drafts to be]
Huang: Broadband Use Case
Zhou: Mobile Use Case
4. Deployment Scenarios and Architectures
"Emerging Service Provider Scenarios for IPv6 Deployment", B.
Carpenter, S. Jiang
http://tools.ietf.org/html/draft-ietf-v6ops-isp-scenarios
"Framework for IP Version Transition Scenarios", B. Carpenter, S.
Jiang and V. Kuarasingh
http://tools.ietf.org/html/draft-carpenter-v4v6tran-framework
5. How-to, Whitepapers and FAQs
RFC 5211 "An Internet Transition Plan." J. Curran, July 2008
http://tools.ietf.org/html/rfc5211
"Guidelines for Using Transition Mechanisms During IPv6 Deployment"
J. Arkko and F. Baker
http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines
"IPv6 Transition Guide For A Large ISP Providing Broadband Access",
G. Yang (Ed.), L. Hu and J. Lin
http://tools.ietf.org/html/draft-yang-v4v6tran-ipv6-transition-guide
"IPv6 Rollout: Where do we start?" O. Crepin-Leblond
http://www.slideshare.net/ocl999/suggestion-for-an-ipv6-roll-out
"Everything Sysadmin" T. Limoncelli
http://everythingsysadmin.com/2009/01/google-enables-ipv6-for-most-
s.html
http://everythingsysadmin.com/2010/08/methods-of-converting-to-
ipv6.html
"Happy Eyeballs: Trending Towards Success (IPv6 and SCTP)", D. Wing,
A. Yourtchenko, P. Natarajan.
http://tools.ietf.org/html/draft-wing-http-new-tech
Jankiewicz (Ed.) Expires April 5, 2011 [Page 5]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
This draft makes several recommendations to ensure user satisfaction
and a smooth transition from HTTP's pervasive IPv4 to IPv6 and from
TCP to SCTP. While the target audience is app developers and content
providers, network operators should be aware of techniques needed to
maintain peaceful coexistence without negative impact on end-user
perception of service level.
"Migrating SIP to IPv6 Media Without Connectivity Checks" D. Wing, A.
Yourtchenko
http://tools.ietf.org/html/draft-wing-dispatch-v6-migration
During the migration from IPv4 to IPv6, it is anticipated that an
IPv6 path might be broken for a variety of reasons, causing endpoints
to not receive RTP data. Connectivity checks would detect and avoid
the user noticing such a problem, but there is industry reluctance to
implement connectivity checks.
This document describes a mechanism allowing dual-stack SIP endpoints
to attempt communications over IPv6 and fall back to IPv4 if the IPv6
path is not working. The mechanism does not require connectivity
checks.
"IPv6 Deployment in Internet Exchange Points (IXPs)", Roque Gagliano
http://tools.ietf.org/html/draft-ietf-v6ops-v6inixp
This draft suggests that in an Internet Exchange Point one might use
an address that helps in debugging routing exchanges. One could also
look at what other folks do, embedding identifying marks in
addresses. For example, Facebook includes "face:b00c" in the IID
portion of their address.
6. Transition/Coexistence Tools
As network operators and end-users independently proceed with
transition to IPv6 while others continue to use IPv4, a potentially
long period of coexistence will ensue. Variations on terminology
have been used since the specification of IPv6; transition implies a
process whereby the star of IPv6 rises and the star of IPv4 sets;
coexistence implies that both will operate together. Due to
thoroughly discussed limits to the growth of an Internet using only
IPv4, IPv6 is a necessary technology for the future of the Internet.
However, nothing compels the elimination of IPv4; no protocol police
will forbid its use in the foreseeable future. IPv4 may disappear
due to irrelevance when IPv6 is so pervasive to make it redundant,
but network operators should be prepared to operate IPv4 and IPv6 in
a mixed deployment for some time. However, the techniques and
mechanisms supported by a network operator can be expected to evolve
Jankiewicz (Ed.) Expires April 5, 2011 [Page 6]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
and change over time as a rational goal would be to gradually shift
coexistence costs (real operational expense as well as convenience)
from "early adopters" of IPv6 to the shrinking pool of IPv4
maintainers.
Various techniques are required for coexistence, roughly divided into
three categories:
1. Address Mapping: Many situations will require the use of address
mapping to maintain scalability in the face of dwindling IPv4
global address space and to support translation and tunneling
approaches.
2. Tunneling: A method for the encapsulation and transport of one
protocol over or through the infrastructure that favors the
other, e.g. IPv6 traffic via an IPv4 infrastructure
3. Translation: A mechanism for rewriting packets from one protocol
to the other so they can be delivered as native (non-
encapsulated) packets typically due to incompatible end nodes,
e.g. an IPv6 client to an IPv4 server.
These categories are not mutually exclusive, as some scenarios and
solutions incorporate aspects of multiple approaches.
RFC 4213 "Basic Transition Mechanisms for IPv6 Hosts and Routers" E.
Nordmark and R. Gilligan October 2005
http://tools.ietf.org/html/rfc4213
6.1. Address Mapping
"An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", Sheng
Jiang, Dayong Guo, Brian Carpenter
http://tools.ietf.org/html/draft-ietf-v6ops-incremental-cgn
"Stateful NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers" Bagnulo, Matthews, van Beijnum
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful
"Legacy NAT Traversal for IPv6: Simple Address Mapping for Premises
Legacy Equipment (SAMPLE)"
http://tools.ietf.org/html/draft-carpenter-softwire-sample
"Some Considerations on the Load-Balancer for NAT64" D. Zhang et al.
http://tools.ietf.org/html/draft-wang-behave-nat64-load-balancer
Jankiewicz (Ed.) Expires April 5, 2011 [Page 7]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
"NAT64 for Dual Stack Mobile IPv6" B. Sarikaya and F. Xia
http://tools.ietf.org/html/draft-sarikaya-behave-mext-nat64-dsmip
"NAT64 for Proxy Mobile IPv6" B. Sarikaya and F. Xia
http://tools.ietf.org/html/draft-sarikaya-behave-netext-nat64-pmip
"A Note on NAT64 Interaction with Mobile IPv6" W. Haddad and C.
Perkins
http://tools.ietf.org/html/draft-haddad-mext-nat64-mobility-harmful
"Referrals Across an IPv6/IPv4 Translator" D. Wing, October 19, 2009
http://tools.ietf.org/html/draft-wing-behave-nat64-referrals-01
While this draft is expired, this issue remains a topic of
conversation, including a Bar-BoF at IETF 78. Referrals across
disparate address domains may be needed for provision of services
such as SIP during transition.
"Flexible IPv6 Migration Scenarios in the Context of IPv4 Address
Shortage" M. Boucadair (Ed.) et al, October 20, 2009 (expired)
http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-04
This memo presents a solution to solve IPv4 address shortage and ease
IPv4-IPv6 interconnection. The document presents a set of
incremental steps for the deployment of IPv6 as a means to solve IPv4
address exhaustion. Stateless IPv4/IPv6 address mapping functions
are introduced and IPv4-IPv6 interconnection scenarios presented.
This memo advocates for a more proactive approach for the deployment
of IPv6 into operational networks. This memo specifies the IPv6
variant of the A+P. Both encapsulation and translation scheme are
covered. Moreover, two modes are elaborated: the binding mode
(compatible mode with DS-lite) and the stateless mode.
6.1.1. Dual-Stack Lite (DS-lite)
http://www.networkworld.com/community/node/46600
"Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion" A.
Durand et al.
http://tools.ietf.org/html/draft-ietf-softwire-dual-stack-lite
This document revisits the dual-stack model and introduces the dual-
stack lite technology aimed at better aligning the costs and benefits
of deploying IPv6 in service provider networks. Dual-stack lite
enables a broadband service provider to share IPv4 addresses among
Jankiewicz (Ed.) Expires April 5, 2011 [Page 8]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
customers by combining two well-known technologies: IP in IP (IPv4-
in-IPv6) and Network Address Translation (NAT).
"Dual-stack Lite Mobility Solutions" B. Sarikaya and F. Xia October
11, 2009 (expired)
http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemobility-01
Two solutions are presented to show how to use Dual-Stack Lite
transition technique in mobile networks: one for Proxy Mobile IPv6
and the other for Dual-Stack Mobile IPv6. Proxy Mobile IPv6 allows
IPv4 nodes to receive mobility services using an IPv4 home address.
In case of client based mobility using DSMIPv6, mobile node is a
dual-stack node and it can receive an IPv4 home address from the home
agent which is co-located with DS-lite carrier-grade NAT.
"Scalable Operation of Address Translators with Per-Interface
Bindings" J. Arkko and L. Eggert February 9, 2009 (expired)
http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite-00
This document explains how to employ address translation in networks
that serve a large number of individual customers without requiring a
correspondingly large amount of private IPv4 address space.
"Gateway Initiated Dual-Stack Lite Deployment" F. Brockners et al.
http://tools.ietf.org/html/draft-ietf-softwire-gateway-init-ds-lite
Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a modified approach
to the original Dual-Stack lite (DS-lite) applicable to certain
tunnel-based access architectures. GI-DS-lite extends existing
access tunnels beyond the access gateway to an IPv4-IPv4 NAT using
softwires with an embedded context identifier, that uniquely
identifies the end-system the tunneled packets belong to. The access
gateway determines which portion of the traffic requires NAT using
local policies and sends/receives this portion to/from this softwire
tunnel.
"Deployment DS-lite in Point-to-Point Access Network" Y. Lee (Ed.) et
al. http://tools.ietf.org/html/draft-zhou-softwire-ds-lite-p2p
Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a proposal to
logically extend existing access tunnels beyond the access gateway to
DS-Lite Address Family Transition Router element (AFTR) using
softwires with an embedded context identifier. This memo describes a
deployment model using GI-DS-lite in Point-to-Point access network.
"Deploying Dual-Stack Lite in IPv6 Network" M. Boucadair (Ed.) et al.
http://tools.ietf.org/html/draft-boucadair-dslite-interco-v4v6
Jankiewicz (Ed.) Expires April 5, 2011 [Page 9]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
Dual-Stack lite requires that the AFTR must have IPv4 connectivity.
This forbids a service provider who wants to deploy AFTR in an IPv6-
only network. This memo proposes an extension to implement a
stateless IPv4-in-IPv6 encapsulation in the AFTR so that AFTR can be
deployed in an IPv6-only network.
6.2. Tunneling Mechanisms
RFC 2473 "Generic Packet Tunneling in IPv6 Specification." A. Conta
and S. Deering, December 1998
http://tools.ietf.org/html/rfc2473
RFC 2529 "Transmission of IPv6 over IPv4 Domains without Explicit
Tunnels" B. Carpenter and C. Jung March 1999.
RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" B. Carpenter
and K. Moore February 2001
http://tools.ietf.org/html/rfc3056
RFC 3053 "IPv6 Tunnel Broker" A. Durand, I. Guardini and D. Lento
January 2001
http://tools.ietf.org/html/rfc3053
6.2.1. Teredo
"Teredo Extensions", D. Thaler
http://tools.ietf.org/html/draft-thaler-v6ops-teredo-extensions
6.2.2. IPv6 Rapid Deployment (6rd)and Extensions
RFC 5569 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)" R.
Despres January 2010 http://tools.ietf.org/html/rfc5569
RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)-
Protocol Specification" W. Townsley and O. Troan August 2010
http://tools.ietf.org/html/rfc5969
"IPv6 Across NAT44 CPEs (6a44)" R. Despres, B. Carpenter and S. Jiang
http://tools.ietf.org/html/draft-despres-softwire-6a44
IPv6 Across NAT44 CPEs (6a44) 6a44 is based on an address mapping and
on a mechanism whereby suitably upgraded hosts behind a NAT may
obtain IPv6 connectivity via a stateless 6a44 server function
operated by their Internet Service Provider. With it, traffic
between two 6a44 hosts in a single site remains within the site.
Except for IANA numbers that remain to be assigned, the specification
Jankiewicz (Ed.) Expires April 5, 2011 [Page 10]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
is intended to be complete enough for running codes to be
independently written and interwork.
Note that this draft converges and supersedes work started in two
separate drafts, which are no longer relevant:
http://tools.ietf.org/html/draft-despres-softwire-6rdplus-00
http://tools.ietf.org/html/draft-lee-softwire-6rd-udp-02
6.2.3. Tunnel Support Protocol (TSP)
RFC 5572 "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)" M.
Blanchet and F. Parent, February 2010
http://tools.ietf.org/html/rfc5572
TSP is an Experimental RFC defining a method for a tunnel client to
negotiate tunnel characteristics with a tunnel broker. It enables
tunnels in various deployment architectures including NAT traversal
and mobility, and for user authentication it utilizes:
RFC 4422 "Simple Authentication and Security Layer (SASL)" A. Melikov
ad K. Zeilenga(Eds.) June 2006
http://tools.ietf.org/html/rfc4422
6.2.4. Residual IPv4 Deployment over IPv6-only Infrastructure
Further down the transition road, operators may desire to retire IPv4
routing support and move their backbone networks to IPv6-only. There
may be residual IPv4 legacy customers (clients and servers) still
requiring the delivery of IPv4 packets. While the previously
proposed Dual-Stack Transition Mechanism (DSTM) approach attempted to
satisfy this use case, it was complex and stateful. A stateless
approach to IPv4 residual deployment (4rd) is defined in section 3.2
of the Stateless Address Mapping (SAM) draft. At the time of this
publication, several network operators in Japan are planning
implementation to support residual IPv4 customers.
"Stateless Address Mapping (SAM) - a Simplified Mesh-Softwire Model"
Despres, R. July 12, 2010
http://tools.ietf.org/html/draft-despres-softwire-sam-01
6.2.5. Address Plus Port (AplusP)
"The A+P Approach to the IPv4 Address Shortage" R. Bush (Ed.) October
27, 2009 (expired, but authors indicate a new draft is coming)
http://tools.ietf.org/html/draft-ymbk-aplusp
Jankiewicz (Ed.) Expires April 5, 2011 [Page 11]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
This draft discusses the possibility of address sharing by treating
some of the port number bits as part of an extended IPv4 address
(Address plus Port, or A+P). Instead of assigning a single IPv4
address to a customer device, we propose to extended the address by
"stealing" bits from the port number in the TCP/UDP header, leaving
the applications a reduced range of ports. This means assigning the
same IPv4 address to multiple clients (e.g., CPE, mobile phones),
each with its assigned port-range. In the face of IPv4 address
exhaustion, the need for addresses is stronger than the need to be
able to address thousands of applications on a single host. If
address translation is needed, the end-user should be in control of
the translation process - not some smart boxes in the core.
"Aplusp Lite - A light weight aplusp approach" Z. Xiaoyu
http://tools.ietf.org/html/draft-xiaoyu-aplusp-lite
This document proposes a solution aimed at providing IPv4 continuity
in IPv6 environment. The proposed solution is expected to alleviate
the public IPv4 depletion problem while maximize the benefits from
IPv6 deployment, and meet the desired service availability and
reliability with affordable cost.
6.2.5.1. IRON-RANGER and ISATAP Solutions
A body of RFCs and drafts in progress provide an alternative approach
to IPv4/IPv6 coexistence. This approach utilizes tunneling
techniques to create "overlay" networks. While currently considered
"Experimental" it may be of interest to network operators as an
alternative network architecture.
RFC 5214 "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)"
F. Templin et al. March 2008 http://tools.ietf.org/html/rfc5214
RFC 5320 "The Subnetwork Encapsulation and Adaptation Layer (SEAL)"
F. Templin (Ed.) February 2010 http://tools.ietf.org/html/rfc5320
RFC 5558 "Virtual Enterprise Traversal (VET)" F. Templin (Ed.)
February 2010 http://tools.ietf.org/html/rfc5558
RFC 5579 "Transmission of IPv4 Packets over Intra-Site Automatic
Tunnel Addressing Protocol (ISATAP) Interfaces" F. Templin (Ed.)
February 2010 http://tools.ietf.org/html/rfc5579
RFC 5720 "Routing and Addressing in Networks with Global Enterprise
Recursion (RANGER)" F. Templin (Ed.) February 2010
http://tools.ietf.org/html/rfc5720
Jankiewicz (Ed.) Expires April 5, 2011 [Page 12]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
http://tools.ietf.org/html/draft-templin-intarea-seal
http://tools.ietf.org/html/draft-templin-intarea-vet
http://tools.ietf.org/html/draft-templin-iron
6.3. Translation
From the earliest specification of IPv6 IETF contributors have
recognized that translation would be a necessary tool for transition
and coexistence, as IPv6 was designed as an incompatible replacement
rather than an extension of IPv4. The original approach to stateless
translation defined in RFC 2765 and its implementation as NA(P)T-PT
as described in RFC 2766 had a number of issues that resulting in the
approach being deprecated by RFC 4966. Recently the Behave WG has
taken on the work of defining a set of scenarios covering the use
cases for translation, prioritizing the work and defining new
solutions that overcome the deficiencies of the historic approach.
6.3.1. Historic Approach
RFC 2765 "Stateless IP/ICMP Translation (SIIT)." E. Nordmark,
February 2000 http://tools.ietf.org/html/rfc2765
RFC 2766 "Network Address Translation - Protocol Translation (NAT-
PT)." G. Tsirtsis and P. Srisresh, February 2000
http://tools.ietf.org/html/rfc2766
RFC 2767 "Dual-Stack Hosts Using 'Bump in the Stack' Technique (BIS)"
K. Tsuchiay, H. Higuchi and Y. Atarashi February 2000
RFC 3338 "Dual-Stack Hosts Using 'Bump in the API' (BIA)" S. Lee, et
al. October 2002
http://tools.ietf.org/html/rfc3338
These two RFCs are proposed for obsolescence by a draft that combines
both:
"Dual-Stack Hosts Using 'Bump in the Host'(BIH)" B. Huang, H. Deng
and T. Savolainen
http://tools.ietf.org/html/draft-huang-behave-bih
6.3.2. Current Translation Approaches
A renewed effort to define new translation mechanisms started with
discussions in the Internet Area (intarea) meeting and the Technical
Plenary at IETF 71 in Dublin, and continued at a special meeting in
Jankiewicz (Ed.) Expires April 5, 2011 [Page 13]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
Montreal in October 2008. This led to a commitment by contributors
in the Behave WG to take on the work. A set of scenarios were
defined along with a framework for the translation solutions.
"A Framework for IPv4/IPv6 Translation" F. Baker et al.
http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework
This draft (Framework) is the place to start to understand the
historic context for translation, the definition and rationale for
the set of translation scenarios and canonical definitions for some
of the terminology that arises when talking about translation and
coexistence in general.
The 4 deployment modes for these scenarios are:
1. Connecting between the IPv4 Internet and the IPv6 Internet
2. Connecting an IPv6 network to the IPv4 Internet
3. Connecting an IPv4 network to the IPv6 Internet
4. Connecting between an IPv4 network and an IPv6 network
As solutions may differ with respect to the initiating end of the
conversation, 8 scenarios are defined in the Framework draft, as
recapped in the following sections along with specifications that fit
each scenario.
Some general specifications that are cited in the various solution
specifications (or may be in subsequent revisions) are:
"IPv6 Addressing of IPv4/IPv6 Translators" C. Bao et al. August 16,
2010 http://tools.ietf.org/html/draft-ietf-behave-address-format-10
"DNS64: DNS extensions for Network Address Translation from IPv6
Clients to IPv4 Servers" M. Bagnulo et al. July 5, 2010
http://tools.ietf.org/html/draft-ietf-behave-dns64-10
"Analysis of 64 Translation" R. Penno, T. Saxena and D. Wing
http://tools.ietf.org/html/draft-penno-behave-64-analysis
Due to specific problems, NAT-PT was deprecated by the IETF as a
mechanism to perform IPv6-IPv4 translation. Since then, new effort
has been undertaken within IETF to standardize alternative mechanisms
to perform IPv6-IPv4 translation. This document evaluates how the
new translation mechanisms avoid the problems that caused the IETF to
deprecate NAT-PT.
Jankiewicz (Ed.) Expires April 5, 2011 [Page 14]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
6.3.2.1. An IPv6 network to the IPv4 Internet
The Framework defines Scenario 1 for an early adopter (end user or
network operator) which establishes an IPv6 network and needs to
maintain access to the global IPv4 Internet, preferably without
assigning IPv4 addresses to the nodes of the IPv6 network. Either
the Stateful or Stateless solutions proposed may satisfy this
deployment scenario.
"Stateful NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers" M. Bagnulo, P. Matthews and I. van Beijnum
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful
"IP/ICMP Translation Algorithm" X. Li, C. Bao and F. Baker
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate
6.3.2.2. The IPv4 Internet to an IPv6 network
The Framework defines Scenario 2 for a node on the IPv4 Internet
initiating a transmission to a node on an IPv6 network. The original
approach to this deployment was SIIT (in RFC 2765) which has been
deprecated (by RFC 4966). The Stateless Translation solution for
Scenario 1 also would work for this case as it does support IPv4-
initiated communication with a subset of IPv6 addresses.
6.3.2.3. The IPv6 Internet to an IPv4 network
The Framework defines Scenario 3 where a legacy IPv4 network has a
requirement to provide services to users in the IPv6 Internet.
Stateful Translation with static AAAA records in DNS to represent the
IPv4-only hosts will work.
"Stateful NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers" M. Bagnulo, P. Matthews and I. van Beijnum
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful
"DNS64: DNS extensions for Network Address Translation from IPv6
Clients to IPv4 Servers" M. Bagnulo et al.
http://tools.ietf.org/html/draft-ietf-behave-dns64
Alternatively, host-based translation (BIH) or tightly-coupled
translators may be considered.
Jankiewicz (Ed.) Expires April 5, 2011 [Page 15]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
6.3.2.4. An IPv4 network to the IPv6 Internet
Scenario 4 is not easy to solve but fortunately will not arise until
significant IPv6 uptake. In-network translation is not viable, and
other techniques should be considered including host-based
translation (BIH) or tightly-coupled translators that adapt legacy
hosts or networks to the IPv6 Internet.
6.3.2.5. An IPv6 network to an IPv4 network
Scenario 5 describes a configuration where both the IPv6 network and
IPv4 network are within the administrative control of the same
organization. It appears amenable to the same solutions proposed for
Scenario 1.
6.3.2.6. An IPv4 network to an IPv6 network
Scenario 6 is the mirror image of Scenario 5, with communication
initiated from the IPv4 side. It appears amenable to the same
solution proposed for Scenario 2.
6.3.2.7. The IPv6 Internet to the IPv4 Internet
The Framework indicates that Scenario 7, the interconnection of the
IPv4 Internet with the IPv6 Internet may appear to be an ideal case
for an in-network translator (such as the deprecated NAT-PT), but
there is no viable way to map the immense IPv6 address space onto
IPv4. This situation would not entail until significant IPv6
adoption, and has not been a priority for solution.
6.3.2.8. The IPv4 Internet to the IPv6 Internet
Scenario 8 presents a challenge similar to Scenario 7.
7. Prefix and Address Assignment and Distribution
RFC 4291 "IP Version 6 Addressing Architecture." R. Hinden, S.
Deering. February 2006.
http://tools.ietf.org/html/rfc4291
RFC 5952 "A Recommendation for IPv6 Text Representation" S. Kawamura
and M. Kawashima, August 2010
http://tools.ietf.org/html/rfc5952
"IPv6 Addressing of IPv4/IPv6 Translators" C. Bao et al. (Status:
Standards Track, in RFC Editor will update RFC 4291)
http://datatracker.ietf.org/doc/draft-ietf-behave-address-format/
Jankiewicz (Ed.) Expires April 5, 2011 [Page 16]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
RFC 3177 "IAB/IESG Recommendations on IPv6 Address Allocations to
Sites." IAB, IESG. September 2001.
http://tools.ietf.org/html/rfc3177
"IPv6 Address Assignment to End Sites", T. Narten, G. Huston, R.
Roberts, 12-Jul-10
http://tools.ietf.org/html/draft-narten-ipv6-3177bis-48boundary
RFC 5942 "IPv6 Subnet Model: The Relationship between Links and
Subnet Prefixes." H. Singh, W. Beebee, E. Nordmark. July 2010.
http://tools.ietf.org/html/rfc5942
RFC 4862 "IPv6 Stateless Address Autoconfiguration." S. Thomson, T.
Narten, T. Jinmei. September 2007.
http://tools.ietf.org/html/rfc4862
RFC 4941 "Privacy Extensions for Stateless Address Autoconfiguration
in IPv6." T. Narten, R. Draves, S. Krishnan. September 2007.
http://tools.ietf.org/html/rfc4941
The IPv6 addressing architecture presumes that the remaining 64 bits
are an endpoint interface identifier. This could be the MAC Address
(EUI-64 Address) in an appropriate encoding, or it could be what is
called a "privacy address", which is a random number. You will find
the most common approach to that, for hosts, in this RFC.
RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)." R.
Droms (Ed.), J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July
2003. http://tools.ietf.org/html/rfc3315
8. Experiments, Trials and Prototypes
6bone (concluded)
http://go6.net/ipv6-6bone/
Hurricane Electric (ongoing)
http://www.he.net/
T-Mobile USA (ongoing)
http://groups.google.com/group/tmoipv6beta
Comcast (ongoing)
http://www.comcast6.net/
Internode ADSL (Ongoing)
http://ipv6.internode.on.net/access/adsl/
Jankiewicz (Ed.) Expires April 5, 2011 [Page 17]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
Verizon FiOS (small scale test - concluded)
http://newscenter.verizon.com/press-releases/verizon/2010/verizon-
begins-testing-ipv6.html
9. Implementation Reports
IPv6 Rapid Deployment
http://tools.ietf.org/html/rfc5569
Google has hosted a meeting of IPv6 Implementers in 2009 and 2010,
several presentations covered experimental or live transition
experience.
https://sites.google.com/site/ipv6implementors/2009/agenda
https://sites.google.com/site/ipv6implementors/2010/agenda
10. Books on IPv6
Blanchet, Marc. "Migrating to IPv6: a Practical Guide to Implementing
IPv6 in Mobile and Fixed Networks." Chichester, England: J. Wiley &
Sons, 2006. Print.
Siil, Karl A. "IPv6 Mandates: Choosing a Transition Strategy,
Preparing Transition Plans, and Executing the Migration of a Network
to IPv6." Indianapolis, IN: Wiley, 2008. Print.
11. Miscellaneous
See the Dancing Turtle, but only if you have native IPv6!
http://www.kame.net/
A little more detail than a Dancing Turtle, on your IPv6 readiness
can be obtained by using this site put up by Jason Fesler:
http://test-ipv6.com/
There is an extension for Firefox (and perhaps other browsers) that
displays the IP address of web pages you visit, clearly indicating
when you are connected via IPv4 or IPv6. In Firefox, click on
Tools..Add-ons..Extensions and search for ShowIP.
Eric Vyncke is collecting some statistics on IPv6 penetration.
http://www.vyncke.org/ipv6status/
A reasonable estimation of how fast the sky is falling.
http://www.potaroo.net/tools/ipv4/
Jankiewicz (Ed.) Expires April 5, 2011 [Page 18]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
A graphical representation of IPv4 depletion.
http://www.ipv4depletion.com/old.html
"IPv6 Adoption Remains Slow, Survey Says" W. Jackson, GCN Sept. 5,
2101
http://gcn.com/articles/2010/09/14/adoption-of-ipv6-is-slow.aspx
http://www.nro.net/documents/GlobalIPv6SurveySummaryv2.pdf
Some troubling, yet interesting news about what operators and end-
user organizations are thinking about IPv6 adoption at this time.
A study of some of the brokenness around Path MTU Discovery
http://www.ripe.net/ripe/meetings/ripe-60/presentations/Stasiewicz-
Measurements_of_IPv6_Path_MTU_Discovery_Behaviour.pdf
Cluenet hosts a mailing list with IPv6 operator participation.
Various transition-related topics are brought up there from time to
time.http://lists.cluenet.de/mailman/listinfo/ipv6-ops
12. Security Considerations
This draft does not introduce any security considerations.
13. IANA Considerations
This draft does not require any action from IANA.
[Note to RFC Editor: this section may be removed.]
14. Conclusions
This draft is merely the starting point for a network operator
planning an IPv6 rollout. The intention of the editor was to
document the great work that is already available that can help in
the process and to perhaps save a few hours of redundant effort for
someone to find this information. Of course, this will be out of
date before it is published as active research continues in
coexistence and transition tools. The editor hopes it is at least a
useful "You Are Here" map to help navigate the thrill rides available
in the IPv6 theme park.
This compendium could serve as an initial set of data to populate an
active database or wiki. This would allow continuing community
contribution including feedback on the real-world experience of
network operators as they turn on IPv6.
Jankiewicz (Ed.) Expires April 5, 2011 [Page 19]
Internet-Draft An Annotated Bibliography for IPv4-IPv6 October 2010
15. References
15.1. Normative References
None.
15.2. Informative References
Complete reference information is included in the body of the draft.
16. Acknowledgments
This bibliography is a recapitulation of the contributions of the
authors of the cited RFCs, drafts, websites and other publications
and many folks on the v6ops and v4v6transition mailing lists, the
editor has freely borrowed abstract and summary text from the cited
works and e-mail postings. In addition, the editor wishes to
acknowledge significant contributions and suggestions from Fred
Baker, Brian Carpenter, Remi Despres, Tina Tsou, Yiu Lee, Marc
Blanchet, Med Boucadair, Fred Templin and many contributors on the
v4v6trans mailing list. The mailing list archive can be found at:
https://www.ietf.org/mailman/listinfo/v4tov6transition
This document was prepared using 2-Word-v2.0.template.dot.
Author's Address
Edward J. Jankiewicz
SRI International, Inc.
333 Ravenswood Ave
Menlo Park, CA USA
Phone: 732-389-1003 or 650-859-2000
Email: edward.jankiewicz@sri.com
Jankiewicz (Ed.) Expires April 5, 2011 [Page 20]