draft-arkko-ipv6-transition-guidelines-13.txt   draft-arkko-ipv6-transition-guidelines.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational F. Baker Intended status: Informational F. Baker
Expires: June 25, 2011 Cisco Systems Expires: June 4, 2011 Cisco Systems
December 22, 2010 December 2010
Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment
draft-arkko-ipv6-transition-guidelines-13 draft-arkko-ipv6-transition-guidelines-14
Abstract Abstract
The Internet continues to grow beyond the capabilities of IPv4. An The Internet continues to grow beyond the capabilities of IPv4. An
expansion in the address space is clearly required. With its expansion in the address space is clearly required. With its
increase in the number of available prefixes and addresses in a increase in the number of available prefixes and addresses in a
subnet, and improvements in address management, IPv6 is the only real subnet, and improvements in address management, IPv6 is the only real
option on the table. Yet, IPv6 deployment requires some effort, option on the table. Yet, IPv6 deployment requires some effort,
resources, and expertise. The availability of many different resources, and expertise. The availability of many different
deployment models is one reason why expertise is required. This deployment models is one reason why expertise is required. This
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 25, 2011. This Internet-Draft will expire on June 4, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Choosing a Deployment Model . . . . . . . . . . . . . . . 6 3.2. Choosing a Deployment Model . . . . . . . . . . . . . . . 6
4. Guidelines for IPv6 Deployment . . . . . . . . . . . . . . . . 7 4. Guidelines for IPv6 Deployment . . . . . . . . . . . . . . . . 8
4.1. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 8 4.1. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 8
4.2. Crossing IPv4 Islands . . . . . . . . . . . . . . . . . . 10 4.2. Crossing IPv4 Islands . . . . . . . . . . . . . . . . . . 10
4.3. IPv6-Only Core Network . . . . . . . . . . . . . . . . . . 11 4.3. IPv6-Only Core Network . . . . . . . . . . . . . . . . . . 11
4.4. IPv6-only Deployment . . . . . . . . . . . . . . . . . . . 11 4.4. IPv6-only Deployment . . . . . . . . . . . . . . . . . . . 12
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 15 6. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The Internet continues to grow beyond the capabilities of IPv4. The The Internet continues to grow beyond the capabilities of IPv4. The
tremendous success of the Internet has strained the IPv4 address tremendous success of the Internet has strained the IPv4 address
space, which is no longer sufficient to fuel future growth. At the space, which is no longer sufficient to fuel future growth. At the
time of this writing, August 2010, the IANA "free pool" contains only time of this writing, August 2010, the IANA "free pool" contains only
14 unallocated unicast IPv4 /8 prefixes. Credible estimates based on 14 unallocated unicast IPv4 /8 prefixes. Credible estimates based on
past behavior suggest that the RIRs will exhaust their remaining past behavior suggest that the RIRs will exhaust their remaining
skipping to change at page 4, line 8 skipping to change at page 4, line 8
principles behind choosing particular deployment models and tools, principles behind choosing particular deployment models and tools,
Section 4 goes through the recommended deployment models for common Section 4 goes through the recommended deployment models for common
situations, and Section 5 provides some concluding remarks about the situations, and Section 5 provides some concluding remarks about the
choice between these models. choice between these models.
Many networks can follow one of the four scenarios described in this Many networks can follow one of the four scenarios described in this
document. However, variations will certainly occur in the details, document. However, variations will certainly occur in the details,
and there will be questions such as the particular choice of and there will be questions such as the particular choice of
tunneling solution for which there is no "one size fits all" answer. tunneling solution for which there is no "one size fits all" answer.
Network managers must each take the responsibility of choosing the Network managers must each take the responsibility of choosing the
best solution for their own case. Also, a systematic operational best solution for their own case. This document does not attempt to
plan for the transition is required, but the details depend entirely provide guidance for all possible networking situations. Also, a
on the individual network. systematic operational plan for the transition is required, but the
details depend entirely on the individual network.
2. Terminology 2. Terminology
In this document, the following terms are used. In this document, the following terms are used.
IPv4/IPv4 NAT: refers to any IPv4-to-IPv4 network address IPv4/IPv4 NAT: refers to any IPv4-to-IPv4 network address
translation algorithm, both "Basic NAT" and "Network Address/Port translation algorithm, both "Basic NAT" and "Network Address/Port
Translator (NAPT)", as defined by [RFC2663]. Translator (NAPT)", as defined by [RFC2663].
Dual Stack: refers to a technique for providing complete support for Dual Stack: refers to a technique for providing complete support for
skipping to change at page 4, line 39 skipping to change at page 4, line 40
routing domain in which applications can only use IPv4 to routing domain in which applications can only use IPv4 to
communicate, whether due to host limitations, application communicate, whether due to host limitations, application
limitations, or network limitations. limitations, or network limitations.
IPv6-only domain: as defined in [I-D.ietf-behave-v6v4-framework], a IPv6-only domain: as defined in [I-D.ietf-behave-v6v4-framework], a
routing domain in which applications can only use IPv6 to routing domain in which applications can only use IPv6 to
communicate, whether due to host limitations, application communicate, whether due to host limitations, application
limitations, or network limitations. limitations, or network limitations.
NAT-PT: refers to a specific, old design of a Network Address NAT-PT: refers to a specific, old design of a Network Address
Translator - Protocol Translator defined in [RFC4966]. Translator - Protocol Translator defined in [RFC2766] and
deprecated due to the reasons stated in [RFC4966].
3. Principles 3. Principles
The primary goal is to facilitate the continued growth of the The primary goal is to facilitate the continued growth of the
networking industry and deployment of Internet technology at networking industry and deployment of Internet technology at
relatively low capital and operational expense without destabilizing relatively low capital and operational expense without destabilizing
deployed services or degrading customer experience. This is at risk deployed services or degrading customer experience. This is at risk
with IPv4 due to the address runout; economics teaches us that a with IPv4 due to the address runout; economics teaches us that a
finite resource, when stressed, becomes expensive, either in the finite resource, when stressed, becomes expensive, either in the
actual cost of the resource or in the complexity of the technology actual cost of the resource or in the complexity of the technology
skipping to change at page 6, line 16 skipping to change at page 6, line 18
IPv4-only applications, systems, or services must be accommodated. IPv4-only applications, systems, or services must be accommodated.
Most networks that cross administrative boundaries or allow end user Most networks that cross administrative boundaries or allow end user
equipment have such requirements. Even in situations where the equipment have such requirements. Even in situations where the
network consists of only new, IPv6-capable devices it is typically network consists of only new, IPv6-capable devices it is typically
required that the devices can communicate with the IPv4 Internet. required that the devices can communicate with the IPv4 Internet.
It is expected that after a period of supporting both IPv4 and IPv6, It is expected that after a period of supporting both IPv4 and IPv6,
IPv4 can eventually be turned off. This should happen gradually. IPv4 can eventually be turned off. This should happen gradually.
For instance, a service provider network might stop providing IPv4 For instance, a service provider network might stop providing IPv4
service within its own network, while still allowing its IPv6 service within its own network, while still allowing its IPv6
customers to access the rest of the IPv4 Internet through overlay or customers to access the rest of the IPv4 Internet through overlay,
proxy services. Regardless of progress in supporting IPv6, it is proxy, or translation services. Regardless of progress in supporting
widely expected that some legacy applications and some networks will IPv6, it is widely expected that some legacy applications and some
continue to run only over IPv4 for many years. All deployment networks will continue to run only over IPv4 for many years. All
scenarios need to deal with this situation. deployment scenarios need to deal with this situation.
3.2. Choosing a Deployment Model 3.2. Choosing a Deployment Model
The first requirement is that the model or tool actually allows The first requirement is that the model or tool actually allows
communications to flow and services to appropriately be delivered to communications to flow and services to appropriately be delivered to
customers without perceived degradation. While this sounds too customers without perceived degradation. While this sounds too
obvious to even state, it is sometimes not easy to ensure that a obvious to even state, it is sometimes not easy to ensure that a
proposed model does not have failure modes related to supporting proposed model does not have failure modes related to supporting
older devices, for instance. A network that is not serving all of older devices, for instance. A network that is not serving all of
its users is not fulfilling its task. its users is not fulfilling its task.
skipping to change at page 7, line 23 skipping to change at page 7, line 25
o The ability to scale. The IPv4 Internet grew far larger than its o The ability to scale. The IPv4 Internet grew far larger than its
original designers had anticipated, and scaling limits only became original designers had anticipated, and scaling limits only became
apparent 20-30 years later. apparent 20-30 years later.
o The design supports robust interoperability rather than mere o The design supports robust interoperability rather than mere
correctness. This is important in order to ensure that the correctness. This is important in order to ensure that the
solution works in different circumstances and in an imperfectly solution works in different circumstances and in an imperfectly
controlled world. controlled world.
These factors are also important when choosing IPv6 migration tools. Similar factors are also important when choosing IPv6 migration
tools. Success factors should be evaluated in the context of a
migration solution. For instance, incremental deployability and lack
of dependencies to components that are under someone else's control
are key factors.
It is also essential that any chosen designs allow the network to be It is also essential that any chosen designs allow the network to be
maintained, serviced, diagnosed and measured. The ability of the maintained, serviced, diagnosed and measured. The ability of the
network to operate under many different circumstances and surprising network to operate under many different circumstances and surprising
conditions is a key. Any large network that employs brittle conditions is a key. Any large network that employs brittle
components will incur significant support costs. components will incur significant support costs.
Properly executed IPv6 deployment normally involves a step-wise Properly executed IPv6 deployment normally involves a step-wise
approach where individual functions or parts of the network are approach where individual functions or parts of the network are
updated at different times. For instance, IPv6 connectivity has to updated at different times. For instance, IPv6 connectivity has to
skipping to change at page 11, line 41 skipping to change at page 11, line 50
for this purpose, as the same addresses would be used in several for this purpose, as the same addresses would be used in several
parts of the network. parts of the network.
o It may be simpler for the service provider to employ a single- o It may be simpler for the service provider to employ a single-
version network. version network.
The recommended tool for this model is Dual Stack Lite The recommended tool for this model is Dual Stack Lite
[I-D.ietf-softwire-dual-stack-lite]. Dual Stack Lite provides both [I-D.ietf-softwire-dual-stack-lite]. Dual Stack Lite provides both
relief for IPv4 address shortage and makes forward progress on IPv6 relief for IPv4 address shortage and makes forward progress on IPv6
deployment, by moving service provider networks and IPv4 traffic over deployment, by moving service provider networks and IPv4 traffic over
IPv6. Given this IPv6 connectivity, as a side-effect it becomes easy IPv6. Given the IPv6 connectivity that Dual Stack Lite runs over, it
to provide IPv6 connectivity all the way to the end users. becomes easy to provide IPv6 connectivity all the way to the end
users as well.
4.4. IPv6-only Deployment 4.4. IPv6-only Deployment
Our final deployment model breaks the requirement that all parties Our final deployment model breaks the requirement that all parties
must upgrade to IPv6 before any end-to-end communications use IPv6. must upgrade to IPv6 before any end-to-end communications use IPv6.
This model makes sense when the following conditions are met: This model makes sense when the following conditions are met:
o There is a fact or requirement that there be an IPv4-only domain o There is a fact or requirement that there be an IPv4-only domain
and an IPv6-only domain. and an IPv6-only domain.
skipping to change at page 13, line 5 skipping to change at page 13, line 16
understanding of what applications are used in the network, enabling understanding of what applications are used in the network, enabling
him to ensure that any communication exchange is in fact predictable, him to ensure that any communication exchange is in fact predictable,
capable of using IPv6, and translatable. In such a case, full capable of using IPv6, and translatable. In such a case, full
interoperability can be expected. This has been demonstrated with interoperability can be expected. This has been demonstrated with
some mobile devices, for instance. Note that the requirements on some mobile devices, for instance. Note that the requirements on
applications are similar to those in networks employing IPv4 NAT applications are similar to those in networks employing IPv4 NAT
technology. technology.
One obvious IPv6-only deployment approach applies to applications One obvious IPv6-only deployment approach applies to applications
that include proxies or relays. One might position a web proxy, a that include proxies or relays. One might position a web proxy, a
mail server, or a SIP (Session Identity Protocol) back-to-back user mail server, or a SIP (Session Initiation Protocol) and media stream
agent across the boundary between IPv4 and IPv6 domains, so that the back-to-back user agent across the boundary between IPv4 and IPv6
application terminates IPv4 sessions on one side and IPv6 sessions on domains, so that the application terminates IPv4 sessions on one side
the other. Doing this preserves the end-to-end nature of and IPv6 sessions on the other. Doing this preserves the end-to-end
communications between gateways. For obvious reasons, this solution nature of communications from the gateway to the communicating peer.
is preferable to the implementation of Application Layer Gateways in For obvious reasons, this solution is preferable to the
network layer translators. implementation of Application Layer Gateways in network layer
translators.
The other approach is network layer IPv4/IPv6 translation as The other approach is network layer IPv4/IPv6 translation as
described in IPv4/IPv6 Translation [I-D.ietf-behave-v6v4-framework] described in IPv4/IPv6 Translation [I-D.ietf-behave-v6v4-framework]
[I-D.ietf-behave-v6v4-xlate] [I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate] [I-D.ietf-behave-v6v4-xlate-stateful]
[RFC6052] [I-D.ietf-behave-dns64] [I-D.ietf-behave-ftp64]. IPv4/IPv6 [RFC6052] [I-D.ietf-behave-dns64] [I-D.ietf-behave-ftp64]. IPv4/IPv6
translation at the network layer is similar in its advantages and translation at the network layer is similar in its advantages and
disadvantages to IPv4/IPv4 translation. It allows a network to disadvantages to IPv4/IPv4 translation. It allows a network to
provide two types of services to IPv6-only hosts: provide two types of services to IPv6-only hosts:
o a relatively small set of systems may be configured with IPv4- o a relatively small set of systems may be configured with IPv4-
skipping to change at page 13, line 39 skipping to change at page 13, line 51
The former service is used today in some university networks, and the The former service is used today in some university networks, and the
latter in some corporate and mobile networks. The stateless service latter in some corporate and mobile networks. The stateless service
is naturally better suited for servers, and the stateful service for is naturally better suited for servers, and the stateful service for
large numbers of client devices. The latter case occurs typically in large numbers of client devices. The latter case occurs typically in
a public network access setting. The two services can of course also a public network access setting. The two services can of course also
be used together. In this scenario, network layer translation be used together. In this scenario, network layer translation
provides for straightforward services for most applications crossing provides for straightforward services for most applications crossing
the IPv4-only/IPv6-only boundary. the IPv4-only/IPv6-only boundary.
One challenge in this model relates to communications involving IPv4 One challenge in this model is that as long as IPv4 addresses are
referrals. IPv4-literals within certain protocols and formats such still shared, issues similar to those caused by IPv4 NATs will still
at HTML, will fail when passed to IPv6-only hosts since the host does appear [I-D.ietf-intarea-shared-addressing-issues]. Another
not have an IPv4 address to source the IPv4 communications or an IPv4 challenge relates to communications involving IPv4 referrals. IPv4-
route. Measurements on the public internet show that literals appear literals within certain protocols and formats such at HTML, will fail
in a tiny but measurable part of web pages when passed to IPv6-only hosts since the host does not have an IPv4
address to source the IPv4 communications or an IPv4 route.
Measurements on the public internet show that literals appear in a
tiny but measurable part of web pages
[I-D.arkko-ipv6-only-experience], though whether this poses a [I-D.arkko-ipv6-only-experience], though whether this poses a
practical problem is debatable. If this poses a particular problem practical problem is debatable. If this poses a particular problem
for the types of applications in use, proxy configurations could be for the types of applications in use, proxy configurations could be
modified to use a proxy for the traffic in question, hosts could be modified to use a proxy for the traffic in question, hosts could be
modified to understand how they can map IPv4 literals to IPv6 modified to understand how they can map IPv4 literals to IPv6
addresses, or native dual stack could be employed instead. addresses, or native dual stack could be employed instead.
5. Conclusions 5. Conclusions
The fundamental recommendation is to turn IPv6 on. Section 4 The fundamental recommendation is to turn IPv6 on. Section 4
skipping to change at page 15, line 14 skipping to change at page 15, line 28
6. Further Reading 6. Further Reading
Various aspects of IPv6 deployment have been covered in several Various aspects of IPv6 deployment have been covered in several
documents. Of particular interest may be the basic dual stack documents. Of particular interest may be the basic dual stack
definition [RFC4213], application aspects [RFC4038], deployment in definition [RFC4213], application aspects [RFC4038], deployment in
Internet Service Provider Networks [RFC4029] [RFC6036], deployment in Internet Service Provider Networks [RFC4029] [RFC6036], deployment in
enterprise networks [RFC4057] [RFC4852], IPv6-only deployment enterprise networks [RFC4057] [RFC4852], IPv6-only deployment
[I-D.arkko-ipv6-only-experience], and considerations in specific [I-D.arkko-ipv6-only-experience], and considerations in specific
access networks such as cellular networks [RFC3314] [RFC3574] access networks such as cellular networks [RFC3314] [RFC3574]
[RFC4215] or 802.16 networks [RFC5181]. [RFC4215] [I-D.ietf-v6ops-v6-in-mobile-networks] or 802.16 networks
[RFC5181].
This document provides general guidance on IPv6 deployment models This document provides general guidance on IPv6 deployment models
that have been found suitable for most organizations. The purpose of that have been found suitable for most organizations. The purpose of
this document is not to enumerate all special circumstances that may this document is not to enumerate all special circumstances that may
warrant other types of deployment models or the details of the warrant other types of deployment models or the details of the
necessary transition tools. Many of the special cases and details necessary transition tools. Many of the special cases and details
have been discussed in the above documents. have been discussed in the above documents.
7. Security Considerations 7. Security Considerations
skipping to change at page 19, line 44 skipping to change at page 20, line 17
traffic spike", Network World article http:// traffic spike", Network World article http://
www.networkworld.com/news/2010/020110-youtube-ipv6.html, www.networkworld.com/news/2010/020110-youtube-ipv6.html,
February 2010. February 2010.
[I-D.ietf-v6ops-tunnel-security-concerns] [I-D.ietf-v6ops-tunnel-security-concerns]
Krishnan, S., Thaler, D., and J. Hoagland, "Security Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns With IP Tunneling", Concerns With IP Tunneling",
draft-ietf-v6ops-tunnel-security-concerns-03 (work in draft-ietf-v6ops-tunnel-security-concerns-03 (work in
progress), October 2010. progress), October 2010.
[I-D.ietf-v6ops-v6-in-mobile-networks]
Koodli, R., "Mobile Networks Considerations for IPv6
Deployment", draft-ietf-v6ops-v6-in-mobile-networks-02
(work in progress), October 2010.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank the many people who have engaged in The authors would like to thank the many people who have engaged in
discussions around this topic over the years. Some of the material discussions around this topic over the years. Some of the material
in this document comes originally from Fred Baker's presentation in a in this document comes originally from Fred Baker's presentation in a
workshop in Shanghai [Baker.Shanghai]. In addition, the authors workshop in Shanghai [Baker.Shanghai]. In addition, the authors
would like to thank Mark Townsley with whom the Jari Arkko wrote an would like to thank Mark Townsley with whom the Jari Arkko wrote an
earlier document [I-D.arkko-townsley-coexistence]. Brian Carpenter earlier document [I-D.arkko-townsley-coexistence]. Brian Carpenter
submitted an in-depth review and provided significant new text. submitted an in-depth review and provided significant new text.
Cameron Byrne provided significant feedback on the key Cameron Byrne provided significant feedback on the key
 End of changes. 16 change blocks. 
35 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/