draft-ietf-v6ops-wireline-incremental-ipv6-00.txt   draft-ietf-v6ops-wireline-incremental-ipv6-01.txt 
v6ops V. Kuarsingh, Ed. v6ops V. Kuarsingh, Ed.
Internet-Draft Rogers Communications Internet-Draft Rogers Communications
Intended status: Informational L. Howard Intended status: Informational L. Howard
Expires: May 30, 2012 Time Warner Cable Expires: August 5, 2012 Time Warner Cable
November 27, 2011 February 2, 2012
Wireline Incremental IPv6 Wireline Incremental IPv6
draft-ietf-v6ops-wireline-incremental-ipv6-00 draft-ietf-v6ops-wireline-incremental-ipv6-01
Abstract Abstract
Operators worldwide are in various stages of preparing for, or Operators worldwide are in various stages of preparing for, or
deploying IPv6 into their networks. The operators often face deploying IPv6 into their networks. The operators often face
challenges related to both IPv6 introduction along with a growing difficult challenges related to both IPv6 introduction along with
risk of IPv4 run out within their organizations. The overall problem those related to IPv4 run out. Operators will need to meet the
for many operators will be to meet the simultaneous needs of IPv6 simultaneous needs of IPv6 connectivity and continue support for IPv4
connectivity and continue support for IPv4 connectivity for legacy connectivity for legacy devices with a depleting supply of IPv4
devices and systems with a depleting supply of IPv4 addresses. The addresses. The IPv6 transition will take most networks from an IPv4-
overall transition will take most networks from an IPv4-Only only environment to an IPv6 focused environment with long period of
environment to a dual stack network environment and potentially an dual stack operation varying by operator. This document helps
IPv6-Only operating mode. This document helps provide a framework provide a framework for Wireline providers who are faced with the
for Wireline providers who may be faced with many of these challenges challenges of introducing IPv6 along meeting the legacy needs of IPv4
as they consider what IPv6 transition technologies to use, how to use connectivity utilizing well defined and commercially available IPv6
the selected technologies and when to use them. transition technologies.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 30, 2012. This Internet-Draft will expire on August 5, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Operator Assumptions . . . . . . . . . . . . . . . . . . . . . 4 2. Operator Assumptions . . . . . . . . . . . . . . . . . . . . . 4
3. Reasons and Considerations for a Phased Approach . . . . . . . 5 3. Reasons and Considerations for a Phased Approach . . . . . . . 5
3.1. Relevance of IPv6 and IPv4 . . . . . . . . . . . . . . . . 5 3.1. Relevance of IPv6 and IPv4 . . . . . . . . . . . . . . . . 5
3.2. IPv4 Resource Challenges . . . . . . . . . . . . . . . . . 6 3.2. IPv4 Resource Challenges . . . . . . . . . . . . . . . . . 6
3.3. IPv6 Introduction and Maturity . . . . . . . . . . . . . . 6 3.3. IPv6 Introduction and Operational Maturity . . . . . . . . 6
3.4. Service Management . . . . . . . . . . . . . . . . . . . . 7 3.4. Service Management . . . . . . . . . . . . . . . . . . . . 7
3.5. Sub-Optimal Operation of Transition Technologies . . . . . 7 3.5. Sub-Optimal Operation of Transition Technologies . . . . . 8
4. IPv6 Transition Technology Analysis . . . . . . . . . . . . . 8 3.6. Future IPv6 Network . . . . . . . . . . . . . . . . . . . 8
4.1. Automatic Tunnelling using 6to4 and Teredo . . . . . . . . 8 4. IPv6 Transition Technology Analysis . . . . . . . . . . . . . 9
4.2. Carrier Grade NAT (NAT444) . . . . . . . . . . . . . . . . 8 4.1. Automatic Tunnelling using 6to4 and Teredo . . . . . . . . 9
4.3. 6RD . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Carrier Grade NAT (NAT444) . . . . . . . . . . . . . . . . 9
4.4. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 9 4.3. 6RD . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 10
4.6. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5. DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IPv6 Transition Phases . . . . . . . . . . . . . . . . . . . . 11 4.6. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Phase 0 - Foundation . . . . . . . . . . . . . . . . . . . 11 5. IPv6 Transition Phases . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Phase 0 - Foundation: Training . . . . . . . . . . . . 11 5.1. Phase 0 - Foundation . . . . . . . . . . . . . . . . . . . 12
5.1.2. Phase 0 - Foundation: Routing . . . . . . . . . . . . 12 5.1.1. Phase 0 - Foundation: Training . . . . . . . . . . . . 12
5.1.3. Phase 0 - Foundation: Network Policy and Security . . 12 5.1.2. Phase 0 - Foundation: Routing . . . . . . . . . . . . 13
5.1.4. Phase 0 - Foundation: Transition Architecture . . . . 12 5.1.3. Phase 0 - Foundation: Network Policy and Security . . 13
5.1.5. Phase 0- Foundation: Tools and Management . . . . . . 13 5.1.4. Phase 0 - Foundation: Transition Architecture . . . . 13
5.2. Phase 1 - Tunnelled IPv6 . . . . . . . . . . . . . . . . . 13 5.1.5. Phase 0- Foundation: Tools and Management . . . . . . 14
5.2.1. 6RD Deployment Considerations . . . . . . . . . . . . 14 5.2. Phase 1 - Tunnelled IPv6 . . . . . . . . . . . . . . . . . 14
5.3. Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 16 5.2.1. 6RD Deployment Considerations . . . . . . . . . . . . 15
5.3.1. Native Dual Stack Deployment Considerations . . . . . 16 5.3. Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 17
5.4. Intermediate Phase for CGN . . . . . . . . . . . . . . . . 17 5.3.1. Native Dual Stack Deployment Considerations . . . . . 18
5.4.1. CGN Deployment Considerations . . . . . . . . . . . . 18 5.4. Intermediate Phase for CGN . . . . . . . . . . . . . . . . 18
5.5. Phase 3 - Tunnelled IPv4 . . . . . . . . . . . . . . . . . 19 5.4.1. CGN Deployment Considerations . . . . . . . . . . . . 20
5.5.1. DS-Lite Deployment Considerations . . . . . . . . . . 20 5.5. Phase 3 - IPv6-Only . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 5.5.1. DS-Lite Deployment Considerations . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
This draft sets out to help wireline operators in planning their IPv6 This draft sets out to help Wireline operators in planning their IPv6
deployments, while ensuring continued support for IPv6-incapable deployments while ensuring continued support for IPv6-incapable
consumer devices and applications. We will identify which consumer devices and applications. We will identify which
technologies can be used incrementally to transition from IPv4-only technologies can be used incrementally to transition from IPv4-only
to an efficient IPv6/IPv4 dual stack environment. Some plans may to an IPv6 anchored environment with support for dual stack
also include IPv6-Only end state targets, but there is not clear operation. The end state goal for most operators will be IPv6-only,
consensus on how long IPv4 support is required, and IPv6-Only but the path to this final state will heavily depend on the amount of
generally means withdrawing IPv4 mechanisms. Although no single plan legacy equipment resident in end networks and management of long tail
will work for for all operators, options listed herein provide a IPv4-only content. Although no single plan will work for for all
baseline which can be included in many plans. operators, options listed herein provide a baseline which can be
included in many plans.
This draft is intended for wireline environments including Cable, DSL This draft is intended for Wireline environments which includes
and/or Fibre as the access method to the end consumer. This draft Cable, DSL and/or Fibre as the access method to the end consumer.
also attempts to follow the methodologies set out in [I-D.ietf-v6ops- This draft also attempts to follow the methodologies set out in
v4v6tran-framework] to identify how the technologies can be used [I-D.ietf-v6ops-v4v6tran-framework] to identify how transition
individually and in combination. This document also attempts to technologies can be used individually and in combination. This
follow the principles laid out in [RFC6180] which provides guidance document also attempts to follow the principles laid out in [RFC6180]
on using IPv6 transition mechanisms. This document will show how which provides guidance on using IPv6 transition mechanisms. This
well defined technologies such as 6RD [RFC5969], DS-Lite [RFC6333] document will focus on technologies which enable and mature IPv6
and Carrier Grade NAT (NAT44 without tunnelling as distinct from DS- within the operator's network, but will also include a cursory view
Lite) used with native dual stack to deliver effective IPv4 and IPv6 of IPv4 connectivity continuance. The focal transition technologies
services in an evolving wireline network. include 6RD [RFC5969], DS-Lite [RFC6333] and Dual Stack operation
with a view into NAT44/Carrier Grade NAT (NAT44 without tunnelling as
distinct from DS-Lite). Focus on these technologies include their
inclusion in many off-the-shelf CPEs and availability in commercially
available network vendor equipment.
2. Operator Assumptions 2. Operator Assumptions
For the purposes of this document, assume: For the purposes of this document, the authors assume:
- The operator is considering deploying IPv6 - The operator is considering deploying IPv6 or is in progress in
deploying IPv6
- The operator has a legacy IPv4 customer base which will continue - The operator has a legacy IPv4 customer base which will continue
to exist to exist for a period of time
- The operator will want to minimize the level of disruption to - The operator will want to minimize the level of disruption to
the existing and new customers by minimizing number of the existing and new customers by minimizing number of
technologies and functions that are needed to mediate any given technologies and functions that are needed to mediate any given
set of customer flows (overall preference for Native IP flows) set of customer flows (overall preference for Native IP flows)
- The operator is able to run Dual Stack on their own core network - The operator is able to run Dual Stack on their own core network
and to transition their own services to support IPv6 and is alble to transition their own services to support IPv6
Based on these assumptions, an operator will want to use technologies Based on these assumptions, an operator will want to utilize
which minimize the number of flows being tunnelled, translated or technologies which minimize the need to tunnel, translate or mediate
intercepted at any given time. Technology selections would be made flows to help simplify traffic flow and lower cost impacts of
to manage the non dominant flows and allow Native IP routing (IPv4 transition technologies. Technology selections should be made to
and/or IPv6) for the dominant traffic. This allows the operator to interact with the non-dominant flows and allow Native IP routing
minimize the cost of IPv6 transition technologies by containing the (IPv4 and/or IPv6) to forward the dominant traffic whenever possible.
scale required by the relevant systems. This allows the operator to minimize the cost of IPv6 transition
technologies by minimizing the system scaling needed by the relevant
transition technology systems.
3. Reasons and Considerations for a Phased Approach 3. Reasons and Considerations for a Phased Approach
When faced with the challenges described in the Introduction, When faced with the challenges described in the Introduction,
operators may need to consider a phased approach when adding IPv6 to operators may need to consider a phased approach when adding IPv6 to
an existing IPv4 service. A phased approach addresses many an existing IPv4 service. A phased approach allows the operator to
challenges: add in IPv6 while not ignoring legacy IPv4 connection requirements.
Some of the main challenges which the operator will face include:
- IPv4 exhaustion may occur long before most traffic is able to - IPv4 exhaustion may occur long before all traffic is able to
delivered over IPv6 delivered over IPv6, necessitating IPv4 address sharing
- IPv6 will pose operational challenges, since much of the - IPv6 will pose operational challenges since some of the software
software, and in some cases the hardware to run it at scale, will is unvetted in large production environments and organizations are
be new. Further, the operational processes will be relatively new not acclimatized to support IPv6 as a service
- Connectivity modes will move from single stack to dual stack in Many access network devices or customer controlled CPEs may not
the Home Changing functional behaviours in the home network add support native IPv6 operation for a period of time
complexity to user support
These challenges will likely occur over time which means the - Connectivity modes will move from IPv4-only to Dual Stack in the
operator's plans need to address the every changing requirements of home, changing functional behaviours in the consumer network
increasing support requirements for the operator
These challenges will occur over a period of time which means the
operator's plans need to address the ever changing requirements of
the network and customer demand. The following few sections the network and customer demand. The following few sections
highlight some of the key reasons why a phased approach to IPv6 highlight some of the key reasons why a phased approach to IPv6
transition may be warranted and desired. transition may be warranted and desired.
Although phases will be presented in this document, not all operators Although phases will be presented in this document, not all operators
may need to enable each desecrate phase. It is possible that may need to enable each desecrate phase. It is possible that
characteristics in individual networks may allow certain operators to characteristics in individual networks may allow certain operators to
skip various phases. skip various phases.
3.1. Relevance of IPv6 and IPv4 3.1. Relevance of IPv6 and IPv4
Over the next few years, both IPv4 and IPv6 will play a role in the The delivery of IPv6 connectivity should be the primary goal for
Internet experience. Many customers use older operating systems and operators. Even though the operator may be focused on IPv6 delivery,
hardware which support IPv4-Only. Internet customers don't buy IPv4 they should be aware that both IPv4 and IPv6 will play a role in the
or IPv6 connections, they buy Internet connections, which demands the Internet experience during transition. Many customers use older
need to support both IPv4 and IPv6 for as long at the customer's home operating systems and hardware which support IPv4-only operation.
network demands such support. Internet customers don't buy IPv4 or IPv6 connections, they buy
Internet connections, which demands the need to support both IPv4 and
IPv6 for as long at the customer's home network demands such support.
The Internet is made of of many interconnecting systems, networks, The Internet is made of of many interconnecting systems, networks,
hardware, software and content sources - all of which will move to hardware, software and content sources - all of which will move to
IPv6 at different rates. The Operator's mandate during this time of IPv6 at different rates. The Operator's mandate during this time of
transition will be to support connectivity to both IPv6 and IPv4 transition will be to support connectivity to both IPv6 and IPv4
through various technological means. The operator may be able to through various technological means. The operator may be able to
leverage one or the other protocol to help bridge connectivity, but leverage one or the other protocol to help bridge connectivity, but
the home network will demand both IPv4 and IPv6 for some time. the home network will demand both IPv4 and IPv6 for some time.
3.2. IPv4 Resource Challenges 3.2. IPv4 Resource Challenges
Since connectivity to IPv4-Only endpoints and/or content will remain Since connectivity to IPv4-only endpoints and/or content will remain
common, IPv4 resource challenges are of key concern to operators. common, IPv4 resource challenges are of key concern to operators.
The lack of new IPv4 addressees for additional endpoints means that The lack of new IPv4 addressees for additional endpoints means that
growth in demand of IPv4 connections in some networks will be based growth in demand of IPv4 connections in some networks will be based
on address sharing. on address sharing.
Networks are growing at different rates based on emerging markets Networks are growing at different rates including those in emerging
and/or proliferation of Internet based services and endpoints: growth markets and established networks based on the proliferation of
on the Internet will continue. IPv4 address constraints will likely Internet based services and endpoints. IPv4 address constraints will
affect many if not most operators at some point. IPv4 exhaustion is likely affect many if not most operators at some point increasing the
a primary consideration for technologies which rely on IPv4 to supply benefits of IPv6. IPv4 exhaustion is a consideration for
IPv6 services, such as 6RD. Also, if Native Dual Stack is considered technologies which rely on IPv4 to supply IPv6 services, such as 6RD.
by the operator, challenges on the IPv4 path is also of concern. Also, if native Dual Stack is considered by the operator, challenges
on the IPv4 path is also of concern.
Some operators may be able to reclaim some IPv4 addresses through Some operators may be able to reclaim some IPv4 addresses through
efficiency in the network and replacement of globally-unique IPv4 efficiency in the network and the replacement of globally-unique IPv4
assignments with private addresses [RFC1918]. These measures are assignments with private addresses [RFC1918]. These measures are
tactical and do not support a longer term strategic option. The lack tactical and do are not long term strategic options. The lack of new
of new IPv4 addresses will therefore force operators to support some IPv4 addresses will therefore force operators to support some form of
form of IPv4 address sharing and may impact technological options for IPv4 address sharing and may impact technological options for
transition once the operator runs out of new IPv4 addresses for transition once the operator runs out of new IPv4 addresses for
assignment. assignment.
3.3. IPv6 Introduction and Maturity 3.3. IPv6 Introduction and Operational Maturity
The introduction of IPv6 will require the operationalization of IPv6. The introduction of IPv6 will require the operationalization of IPv6.
The IPv4 environment we have today was built over many years and The IPv4 environment we have today was built over many years and
matured by experience. Although many of these experiences are matured by experience. Although many of these experiences are
transferable from IPv4 to IPv6, new experience specific to IPv6 will transferable from IPv4 to IPv6, new experience specific to IPv6 will
be needed. be needed.
Engineering and Operational staff will need to develop experience Engineering and Operational staff will need to develop experience
with IPv6. Inexperience may lead to instability, and Operators with IPv6. Inexperience may lead to early IPv6 deployment
should consider this when selecting technologies for early instability, and Operators should consider this when selecting
transition. Operators may not want to subject their mature IPv4 technologies for initial transition. Operators may not want to
service to a "new IPv6" path initially while it may be going through subject their mature IPv4 service to a "new IPv6" path initially
growing pains. DS-Lite is one such technology, which requires IPv6 while it may be going through growing pains. DS-Lite is one such
to support IPv4. technology which requires IPv6 to support IPv4.
Further, some of these technologies are new and require refinement Further, some of these transition technologies are new and require
within running code and support. Deployment experience may be needed refinement within running code. Deployment experience may be needed
to expose bugs and stabilize software in production environments. to expose bugs and stabilize software in production environments.
Many supporting systems are also under development and have newly Many supporting systems are also under development and have newly
developed IPv6 functionality including vendor implementations of developed IPv6 functionality including vendor implementations of
DHCPv6, Management Tools, Monitoring Systems, Diagnostic systems, DHCPv6, Management Tools, Monitoring Systems, Diagnostic systems,
along with other systems. along with other elements.
Although the base technological capabilities exist to enable and run Although the base technological capabilities exist to enable and run
IPv6 in most environments, it may not be as robust as IPv4, and until IPv6 in most environments, organizational experience is low. Until
such time as each key technical member of an operator's organization such time as each key technical member of an operator's organization
can identify IPv6, understand its relevance to the IP Service can identify IPv6, understand its relevance to the IP Service
offering, how it operates and how to troubleshoot it - it's still offering, how it operates and how to troubleshoot it - the deployment
maturing. is maturing. This fact should not incline an operator to delay their
IPv6 deployment, but should drive them to deploy IPv6 sooner to gain
the much needed experience before IPv6 is the only way to connect new
hosts to the network.
It should also be noted that although many transition technologies
may be new, and some code related to access environments may be new,
there is a large segment of the networking fabric which has has IPv6
available for a long period of time and has had extended exposure in
production. Operators may use this to their advantage by first
enabling IPv6 in the core of their network the work outward towards
the customer edge.
3.4. Service Management 3.4. Service Management
Services are managed within most networks and are often based on the Services are managed within most networks and are often based on the
gleaning and monitoring of IPv4 addresses. Operators will need to gleaning and monitoring of IPv4 addresses. Operators will need to
address such management tools, troubleshooting methods and storage address such management tools, troubleshooting methods and storage
facilities (such as databases) to deal with not just a new address facilities (such as databases) to deal with not just a new address
type containing 128-bits, but often both IPv4 and IPv6 at the same type containing 128-bits, but often both IPv4 and IPv6 at the same
time. Examination of address type, and recording CIDR blocks instead time. Examination of address type, and recording delegated prefixes
of single addresses, may require additional development. along with single addresses, will likely require additional
development.
With any Dual Stack service - whether Native, 6RD based, DS-Lite With any Dual Stack service - whether Native, 6RD based, DS-Lite
based or otherwise - two address families need to be managed based or otherwise - two address families may need to be managed
simultaneously to help provide for the full Internet experience. In simultaneously to help provide for the full Internet experience.
the early transition phases, it's quite likely that many systems will
be missed and that IPv6 services will go un-monitored and impairments This would indicate that IPv6 management is not just an simple add
undetected. in, but needs to be well integrated into the service management
infrastructure. In the early transition phases, it's quite likely
that many systems will be missed and that IPv6 services will go un-
monitored and impairments undetected.
These issues may be of consideration when selecting technologies These issues may be of consideration when selecting technologies
which require IPv6 as the base protocol to delivery IPv4. which require IPv6 as the base protocol to delivery IPv4.
Instability on the IPv6 service in such case would impact IPv4 Instability on the IPv6 service in such case would impact IPv4
services. services.
3.5. Sub-Optimal Operation of Transition Technologies 3.5. Sub-Optimal Operation of Transition Technologies
When considering native dual-stack versus a transition technology, When contrasting native Dual Stack versus other transition
note that native paths are well understood and networks are optimized technologies it should be noted that native IP paths are well
to send traffic efficiently. Transition technologies may alter the understood and networks are often optimized to send such traffic
normal path of traffic. Tunnel servers or translation relays may not efficiently. Transition technologies however, may alter the normal
be located on the shortest path, may increase latency, and may add a path of traffic removing many network efficiencies built for native
single point of failure. IP flows. Tunnelling and translation devices may not be located on
the most optimal path in line with natural traffic flow and may
increase latency. These paths may also add additional points of
failure.
To minimize risk, an operator should use transition technologies for To minimize risk, an operator should use transition technologies for
the lesser-used address family. During earlier phases of transition, the lesser-used address family if possible. During earlier phases of
IPv6 traffic volumes may be lower, so tunnelling of IPv6 traffic may transition, IPv4 traffic volumes may still be dominant, so tunnelling
be reasonable. Over time, these traffic volumes will increase, of IPv6 traffic is reasonable. Over time, as IPv6 traffic volumes
raising the benefits of native delivery of this traffic. Then, as will increase, native delivery of IPv6 traffic becomes advantageous.
IPv4 content diminishes, translation and tunnelling of IPv4 may be When IPv4 connectivity demands diminish, translation and tunnelling
acceptable. of IPv4 over IPv6 may be acceptable and more optimal.
When IPv6 tunnelling is used, an operator may not want to enable IPv6 When IPv6 tunnelling is used, an operator may not want to enable IPv6
for their services, especially high traffic services. Likewise, when for their services, especially high traffic services. Likewise, if
CGN is deployed, the operation may wish to promote IPv6 access. CGN is deployed, the operator may wish to promote native IPv6 access.
3.6. Future IPv6 Network
An operator should also be aware that longer term plans may include
IPv6-only operation in all or much of the network. This longer term
view may be distant to some, but should be considered when planning
out networks, addressing and services. The needs and costs of
maintaining two IP stacks will eventually become burdensome and
simplification will be required. The operators should plan for this
state and not make IPv6 inherently dependant on IPv4 as this would
unnecessarily constrain an operator.
4. IPv6 Transition Technology Analysis 4. IPv6 Transition Technology Analysis
Operators should understand the main transition technologies for IPv6 Operators should understand the main transition technologies for IPv6
deployment and IPv4 runout. This draft provides a brief description deployment and IPv4 runout. This draft provides a brief description
of some of the mainstream options. This analysis is focused on the of some of the mainstream and commercially available options. This
applicability of technologies to deliver residential services and analysis is focused on the applicability of technologies to deliver
less focused on commercial access or infrastructure support. residential services and less focused on commercial access or
infrastructure support.
The technologies in focus for this document are targeted on those The technologies in focus for this document are targeted on those
commercially available and in deployment. commercially available and in deployment.
4.1. Automatic Tunnelling using 6to4 and Teredo 4.1. Automatic Tunnelling using 6to4 and Teredo
Even when operators may not be actively deploying IPv6, automatic Even when operators may not be actively deploying IPv6, automatic
mechanisms exist on customer operating systems and hardware . Such mechanisms exist on customer operating systems and CPE hardware.
technologies include 6to4 [RFC3056] which is most commonly used with Such technologies include 6to4 [RFC3056] which is most commonly used
anycast relays [RFC3068]. Teredo [RFC4380] is also used widely by with anycast relays [RFC3068]. Teredo [RFC4380] is also used widely
many Internet hosts. by many Internet hosts.
Documents such as [RFC6343] have been written to help operators Documents such as [RFC6343] have been written to help operators
understand observed problems and provide guidelines on how to manage understand observed problems with 6to4 deployments and provides
such protocols. An Operator may want to provide local relays for guidelines on how to improve it's performance. An Operator may want
6to4 and/or Teredo to help improve the protocol's performance for to provide local relays for 6to4 and/or Teredo to help improve the
ambient traffic utilizing these IPv6 connectivity methods. protocol's performance for ambient traffic utilizing these IPv6
Experiences such as those described in [I-D.jjmb-v6ops-comcast-ipv6- connectivity methods. Experiences such as those described in
experiences] show that local relays have proved beneficial to 6to4 [I-D.jjmb-v6ops-comcast-ipv6-experiences] show that local relays have
protocol performance. proved beneficial to 6to4 protocol performance.
Operators should also be aware of breakage cases for 6to4 if non- Operators should also be aware of breakage cases for 6to4 if non-
RFC1918 address are used for CGN zones. Many off the shelf CPEs and RFC1918 address are used for NAT444/CGN zones. Many off the shelf
operating systems may turn on 6to4 without a valid return path to the CPEs and operating systems may turn on 6to4 without a valid return
originating (local) host. This particular use is likely to occur if path to the originating (local) host. This particular use is likely
any space other than [RFC1918] is used, including Shared CGN Space[I- to occur if any space other than [RFC1918] is used, including Shared
D.weil-shared-transition-space-request] or space registered to CGN Space [I-D.weil-shared-transition-space-request] or space
another organization (squatted space). The operator can use 6to4-PMT registered to another organization (squat space). The operator can
[I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] or attempt to use 6to4-PMT [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] or
block 6to4 operation entirely by blocking 2002::/16 at its edges. attempt to block 6to4 operation entirely by blocking the ancycast
ranges associated with [RFC3068].
4.2. Carrier Grade NAT (NAT444) 4.2. Carrier Grade NAT (NAT444)
Carrier Grade NAT (GGN), specifically as deployed in a NAT444 Carrier Grade NAT (GGN), specifically as deployed in a NAT444
scenario [I-D.ietf-behave-lsn-requirements], may prove beneficial for scenario [I-D.ietf-behave-lsn-requirements], may prove beneficial for
those operators who offer Dual Stack services to customer endpoints those operators who offer Dual Stack services to customer endpoints
once they exhaust their pools of IPv4 addresses. CGNs, and address once they exhaust their pools of IPv4 addresses. CGNs, and address
sharing overall, are known to cause certain challenges for the IPv4 sharing overall, are known to cause certain challenges for the IPv4
service [RFC6269], but will often be necessary for a time. service [RFC6269], but will often be necessary for a time.
In a network where IPv4 address availability is low, CGN may provide In a network where IPv4 address availability is low, CGN based on
continued access to IPv4 endpoints. Other technologies (4rd, IVI) NAT444 may provide continued access to IPv4 endpoints. Other
may also be used in place of the NAT444 model with CGN. Some of the technologies (4rd, IVI) may also be used in place of the NAT444 model
advantages of using CGN include the similarities in provisioning and with CGN. Some of the advantages of using CGN using NAT444 include
activation of IPv4 hosts within a network and operational procedures the similarities in provisioning and activation of IPv4 hosts and are
in managing such hosts or CPEs (i.e. DHCPv6, DNSv4, TFTP, TR-069 part of current network and operational procedures for managing such
etc). hosts or CPEs (i.e. DHCPv6, DNSv4, TFTP, TR-069 etc).
When considered in the overall IPv6 transition, CGN may play a vital
role in the delivery of Internet services.
4.3. 6RD 4.3. 6RD
6RD [RFC5969] does provide a quick and effective way to deliver IPv6 6RD [RFC5969] does provide a quick and effective way to deliver IPv6
services to customers who do not yet support Native. 6RD provides services to customer endpoints when native IPv6 addressing on the
tunnelled connectivity for IPv6 over the existing IPv4 path. As the access network is not yet possible. 6RD provides tunnelled
access edge is upgraded and customer premise equipment is replaced, connectivity for IPv6 over the existing IPv4 path. As the access
6RD can be superseded by Native IPv6 access. 6RD can be delivered edge is upgraded and customer premise equipment is replaced, 6RD can
along with CGN, but then no traffic would be native; all traffic be superseded by native IPv6 access. 6RD can be delivered along side
would be intermediated. a CGN/NAT444 deployment, but this would cause all traffic to be
subject to some type of transition technology.
6RD may also be advantageous during the early transition while IPv6 6RD may also be advantageous during the early transition while IPv6
traffic volumes are low. During this period, the operator can gain traffic volumes are low. During this period, the operator can gain
experience with IPv6 on the core and improve their peering framework experience with IPv6 on the core and improve their peering framework
to match those of the IPv4 service. 6RD scales easily by adding to match those of the IPv4 service. 6RD scales easily by adding
relays. As IPv6 traffic volume grows, the operator can gradually relays. As IPv6 traffic volume grows, the operator can gradually
replace 6RD with native IPv6. replace 6RD with native IPv6.
6RD client support is required, but most currently deployed CPEs do 6RD client support is required, but most currently deployed CPEs do
not have 6RD client functionality built into them and may not be not have 6RD client functionality built into them and may not be
upgradable. 6RD deployments would most likely require the replacement upgradable. 6RD deployments would most likely require the replacement
of the home CPE. An advantage of this technology over DS-Lite is of the home CPE. An advantage of 6RD in the early stages of
that the WAN side interface does not need to implement IPv6 to transition is that the WAN side interface does not need to implement
function correctly which may make it easier to deploy to field IPv6 to function correctly which may make it easier to deploy to
hardware which is restricted in memory footprint, processing power field hardware which is restricted in memory footprint, processing
and storage space. 6RD will also require parameter configuration power and storage space. 6RD will also require parameter
which can be powered by the operator through DHCPv4, manually configuration which can be powered by the operator through DHCPv4,
provisioned on the CPE or automatically through some other means. manually provisioned on the CPE or automatically through some other
Manual provisioning would likely limit deployment scale. means. Manual provisioning would likely limit deployment scale.
4.4. Native Dual Stack 4.4. Native Dual Stack
Native Dual Stack is often referred to as the "Gold Standard" of IPv6 Native Dual Stack is often referred to as the "Gold Standard" of IPv6
and IPv4 delivery. It is a method of service delivery which is and IPv4 delivery. It is a method of service delivery which is
already used in many existing IPv6 deployments. Native Dual Stack already used in many existing IPv6 deployments. Native Dual Stack
does however require that Native IPv6 be delivered to the customer does however require that Native IPv6 be delivered to the customer
premise. This technology option is desirable in many cases and can premise. This technology option is desirable in many cases and can
be used immediately if the access network and customer premise be used immediately if the access network and customer premise
equipment supports Native IPv6 to the operator's access network. equipment supports native IPv6.
An operator who runs out of IPv4 addresses to assign to customers An operator who runs out of IPv4 addresses to assign to customers
will not be able to provide Native Dual Stack. For a sub-set of the will not be able to provide traditional native Dual Stack. In cases
IPv6 Native Customers, operators may include IPv4 through a CGN. where sufficient IPv4 addresses are not available, CGN/NAT444 can be
used on the IPv4 path.
Delivering Native Dual Stack would require the operator's core and Delivering native Dual Stack would require the operator's core and
access network support IPv6. Additionally, other systems like access network to support IPv6. Other systems like DHCP, DNS, and
DHCPv6, DNS, and diagnostic/management facilities need to be upgraded diagnostic/management facilities need to be upgraded to support IPv6.
to support IPv6. The upgrade of such systems may often not be The upgrade of such systems may often be non-trivial.
trivial.
4.5. DS-Lite 4.5. DS-Lite
Dual-Stack Lite (DS-Lite, [RFC6333]) provides IPv4 services to Dual-Stack Lite (DS-Lite, [RFC6333]) is based on an native IPv6
customer networks which are only addressed with IPv6. DS-Lite service delivery model where IPv4 services are supported. DS-Lite
provides tunnelled connectivity for IPv4 over an IPv6 path between provides tunnelled connectivity for IPv4 over the IPv6 path between
the customer's network device and a provider managed gateway (AFTR). the customer's network device and a provider managed gateway (AFTR).
DS-Lite can only be used where there is native IPv6 connectivity DS-Lite can only be used where there is native IPv6 connectivity
between the AFTR and the customer premise endpoint. This may mean between the AFTR and the customer premise endpoint. This may mean
that the technology's use may not be viable during early transition. that the technology's use may not be viable during early transition
The operator may also not want to subject the customers' IPv4 if the core or access network lacks IPv6 support. Early transition
connection to the IPv6 path. The provider may also want to make sure stages may also occur when a significant about of content and
that most of their internal services, and external content is services are delivered over the legacy IPv4 path. Operators may be
available over IPv6 before deploying DS-Lite. This would lower the sensitive to this and may not want the newer IPv6 path to be the only
overall load on the AFTR devices helping reduce. bridge to IPv4 at that time. The provider may also want to make sure
that most of their internal services and a significant about of
external content is available over IPv6 before deploying DS-Lite.
The availability of services on IPv6 would help lower the demand on
the AFTRs.
By sharing IPv4 addresses among multiple endpoints, like a CGN, DS- By sharing IPv4 addresses among multiple endpoints, like CGN/NAT444,
Lite can facilitate continued growth of IPv4 services even at runout. DS- Lite can facilitate continued support of legacy IPv4 services
There are some functional considerations even after IPv4 run out. There are some functional considerations to
consider event with DS-Lite such as those described in
[draft-donley-nat444-impacts]. [draft-donley-nat444-impacts].
Similar to 6RD, DS-Lite requires client support on the CPE to Similar to 6RD, DS-Lite requires client support on the CPE to
function. Client functionality is likely to be more prevalent in the function. Client functionality is likely to be more prevalent in the
future as IPv6 capable (WAN side) CPEs begin to penetrate the market. future as IPv6 capable (WAN side) CPEs begin to penetrate the market.
This includes both retail and operator provided gateways. This includes both retail and operator provided gateways.
4.6. NAT64 4.6. NAT64
NAT64 [RFC6146] provides the ability to connect IPv6-Only connected NAT64 [RFC6146] provides the ability to connect IPv6-only connected
clients and hosts to IPv4 Servers (or other like hosts). NAT64 clients and hosts to IPv4 servers without any tunnelling. NAT64
requires that the host and home network supports IPv6-Only modes of requires that the host and home network supports IPv6-only modes of
operation. This type of environment is not considered typical in operation. All IPv6-capable equipment scenarios are not considered
most traditional Wireline connections. typical in most traditional Wireline hosted customer networks, are
are not likely to be so in the near future.
In the future, NAT64 may become more viable for Wireline providers as Viability of NAT64 will increase in Wireline networks as consumer
home networking environments support IPv6-Only. In the meantime, DS- equipment is replaced by IPv6 capable versions.
Lite provides in-home IPv4 services over an IPv6-Only network (WAN).
5. IPv6 Transition Phases 5. IPv6 Transition Phases
The Phases described in this document are not provided as a rigid set The Phases described in this document are not provided as a rigid set
of steps, but are considered a guideline which should be analyzed by of steps, but are considered a guideline which should be analyzed by
an operator planning their IPv6 transition. Operators may choose to an operator planning their IPv6 transition. Operators may choose to
skip steps based on technological capabilities within their specific skip steps based on technological capabilities within their specific
networks. networks.
The phases are based on an expectation that IPv6 traffic volume will The phases are based on an expectation that IPv6 traffic volume may
initially be low, and operator staff will gain experience with IPv6 initially be low, and operator staff will gain experience with IPv6
over time. As volume of IPv6 increases, IPv4 traffic volume will over time. As traffic volumes of IPv6 increase, IPv4 traffic volume
correspondingly decrease, until IPv6 is predominant. For each phase, will correspondingly decrease, until IPv6 is the predominant address
the predominant address family should be native, while mediation family used. For each phase, the predominant address family should
(tunnelling or translation) may be acceptable for the smaller traffic be native, while mediation (tunnelling or translation) may be
volume. acceptable for address family which generates the lower amount of
volume on the network.
Additional guidance and information on utilizing IPv6 transition Additional guidance and information on utilizing IPv6 transition
mechanisms can be found in [RFC6180]. Also, guidance on incremental mechanisms can be found in [RFC6180]. Also, guidance on incremental
CGN for IPv6 transition can also be found in [RFC6264]. CGN for IPv6 transition can also be found in [RFC6264].
5.1. Phase 0 - Foundation 5.1. Phase 0 - Foundation
5.1.1. Phase 0 - Foundation: Training 5.1.1. Phase 0 - Foundation: Training
Training is one of the most important steps in preparing an Training is one of the most important steps in preparing an
organization to support IPv6. Most people have little experience organization to support IPv6. Most people have little experience
with IPv6, and many do not even have a solid grounding in IPv4. with IPv6, and many do not even have a solid grounding in IPv4. The
Since there are likely to be challenges with implementing IPv6 - due implementation of IPv6 will likely produce many challenges - due to
to immature code on hardware, and the evolution of many applications immature code on hardware, and the evolution of many applications and
and systems to support IPv6 - organizations must train their staff on systems to support IPv6 - organizations must train their staff on
IPv6. IPv6.
Training should also be provided within reasonable timelines from Training should also be provided within reasonable timelines from the
actual IPv6 deployment. This means the operator needs to plan in actual IPv6 deployment. This means the operator needs to plan in
advance as they train the various parts of their organization. New advance as they train the various parts of their organization. New
Technology and Engineering staff often receive little training Technology and Engineering staff often receive little training
because of their depth of knowledge, but must at least be provided because of their depth of knowledge, but must at least be provided
opportunities to read documentation, architectural white papers, and opportunities to read documentation, architectural white papers, and
RFCs. Operations staff who support the network and other systems RFCs. Operations staff who support the network and other systems
need to be trained closer to the deployment timeframes, so they need to be trained closer to the deployment timeframes, so they
immediately use their new-found knowledge before forgetting. immediately use their new-found knowledge before forgetting.
Customer support staff would require much more basic, but large scale Customer support staff would require much more basic but large scale
training as many organizations have massive call centres to support training since many organizations have massive call centres to
the customer base. support the customer base.
5.1.2. Phase 0 - Foundation: Routing 5.1.2. Phase 0 - Foundation: Routing
The network infrastructure will need to be in place to support IPv6. The network infrastructure will need to be in place to support IPv6.
This includes the routed infrastructure along with addressing This includes the routed infrastructure along with addressing
principles, routing principles, peering policy and related network principles, routing principles, peering policy and related network
functions. Since IPv6 is quite different from IPv4 in number of ways functions. Since IPv6 is quite different from IPv4 in number of ways
including the number of addresses which are made available, careful including the number of addresses which are made available, careful
attention to a scalable and manageable architecture needs to be made. attention to a scalable and manageable architecture needs to be made.
Also, given that home networks environments will no longer receive a Also, given that home network environments will no longer receive a
token single address as is common in IPv4, operators will need to token single address as is common in IPv4, operators will need to
understand the impacts of delegating larges sums of addresses understand the impacts of delegating a large sum of addresses
(prefixes) to consumer endpoints. Delegating prefixes can be of (prefixes) to consumer endpoints. Delegating prefixes can be of
specific importance in access network environments where downstream specific importance in access network environments where downstream
customers often move between access nodes, raising the concern of customers often move between access nodes, raising the concern of
frequent renumbering and/or managing movement of routed prefixes frequent renumbering and/or managing movement of routed prefixes
within the network (common in cable based networks). within the network (common in cable based networks).
5.1.3. Phase 0 - Foundation: Network Policy and Security 5.1.3. Phase 0 - Foundation: Network Policy and Security
Many, but not all, security policies will map easily from IPv4 to Many, but not all, security policies will map easily from IPv4 to
IPv6. Some new policies may be required for issues specific to IPv6 IPv6. Some new policies may be required for issues specific to IPv6
skipping to change at page 12, line 41 skipping to change at page 13, line 41
but raises the awareness they are of consideration and should be but raises the awareness they are of consideration and should be
addressed when delivering IPv6 services. Other IETF documents addressed when delivering IPv6 services. Other IETF documents
([RFC4942], [RFC6092], [RFC6169], for instance) are excellent ([RFC4942], [RFC6092], [RFC6169], for instance) are excellent
resources. resources.
5.1.4. Phase 0 - Foundation: Transition Architecture 5.1.4. Phase 0 - Foundation: Transition Architecture
The operator should plan out their transition architecture in advance The operator should plan out their transition architecture in advance
(with room for flexibility) to help optimize how they will build out (with room for flexibility) to help optimize how they will build out
and scale their networks. If the operator should want to use and scale their networks. If the operator should want to use
multiple technologies like CGN, DS-Lite and 6RD, they may want to multiple technologies like CGN/NAT444, DS-Lite and 6RD, they may want
plan out where such equipment may be located and potentially choose to plan out where network resident equipment may be located and
locations which can be used for all three functional roles (i.e. potentially choose locations which can be used for all three
placement of NAT44 translator, AFTR and 6RD relays). This would functional roles (i.e. placement of NAT44 translator, AFTR and 6RD
allow for the least disruption as the operator evolves the transition relays). This would allow for the least disruption as the operator
environment to meet the needs of the network. This approach may also evolves the transition environment to meet the needs of the customer
prove beneficial if traffic patterns change rapidly in the future and base. This approach may also prove beneficial if traffic patterns
the operator may need to evolve their network faster than originally change rapidly in the future and the operator may need to evolve
anticipated. their transition infrastructure faster than originally anticipated.
Operators should inform their vendors of what technologies they plan Operators should inform their vendors of what technologies they plan
to support over the course of the transition to make sure the to support over the course of the transition to make sure the
equipment is suited to support those modes of operation. This is equipment is suited to support those modes of operation. This is
important for both network gear and customer premise equipment. important for both network gear and customer premise equipment.
The operator should also plan their overall strategy to meet the
target needs of an IPv6-only deployment. Over time, IPv4 maintenance
will become cumbersome so support and an operator may want to remove
it from the access connectivity portion of their network. Planning
for this eventual stage, no matter how far off this may be, will help
the operator embrace this end state when needed.
5.1.5. Phase 0- Foundation: Tools and Management 5.1.5. Phase 0- Foundation: Tools and Management
The operator should thoroughly analyze all provisioning and The operator should thoroughly analyze all provisioning and
operations systems to develop requirements for each phase. This will operations systems to develop requirements for each phase. This will
include address concepts related to the 128-bit addressing field, the include concepts related to the 128-bit IPv6 address, the notation of
notation of an assigned IPv6 prefix (PD) and the ability to detect an assigned IPv6 prefix (PD) and the ability to detect either or both
either or both address families when determining if a customer has address families when determining if a customer has full Internet
full Internet service. service.
If an operator stores usage information, this would need to be If an operator stores usage information, this would need to be
aggregated to include both the IPv4 and IPv6 traffic flows. Also, aggregated to include both the IPv4 and IPv6 traffic flows. Also,
tools that verify connectivity may need to query the IPv4 and IPv6 tools that verify connectivity may need to query the IPv4 and IPv6
addresses. addresses.
5.2. Phase 1 - Tunnelled IPv6 5.2. Phase 1 - Tunnelled IPv6
Many network operators can deploy native IPv6 from access edge to Tunnelled access to IPv6 offers a viable early stage transition
peering edge fairly quickly. Others, may want to support IPv6 option to operators. Many network operators can deploy native IPv6
services before they can support native IPv6. During this period of from access edge to peering edge fairly quickly but may not be able
time, tunnelled access to IPv6 is a viable alternative to Native to offer IPv6 natively to the customer edge device. During this
IPv6. Even while slowly rolling out native IPv6, operators can period of time, tunnelled access to IPv6 is a viable alternative to
deploy relays for automatic tunnelling technologies like 6to4 and native IPv6. It is also possible that operators my be rolling out
Teredo. Where native IPv6 is a longer-term project, operators can IPv6 natively to the customer edge but the time involved may be long
consider 6RD [RFC5969]. Note that 6to4 and Teredo have different due to logistics and other factors. Even while slowly rolling out
address selection behaviours from 6RD [RFC3484]. Additional native IPv6, operators can deploy relays for automatic tunnelling
guidelines on deploying and supporting 6to4 can be found in technologies like 6to4 and Teredo. Where native IPv6 to the access
[RFC6343]. edge is a longer-term project, operators can consider 6RD [RFC5969]
as an option to offer in-home IPv6 access. Note that 6to4 and Teredo
have different address selection behaviours from 6RD [RFC3484].
Additional guidelines on deploying and supporting 6to4 can be found
in [RFC6343].
The operator can deploy 6RD relays easily and scale them as needed to The operator can deploy 6RD relays easily and scale them as needed to
meet the early customer needs of IPv6. Since 6RD requires the meet the early customer needs of IPv6. Since 6RD requires the
upgrade or replacement of CPE gateways, the operator may want ensure upgrade or replacement of CPE gateways, the operator may want ensure
that the gateways support not just 6RD but Native Dual Stack and that the gateways support not just 6RD but native Dual Stack and
other tunnelling technologies if possible. 6RD clients are now other tunnelling technologies if possible such as DS-Lite. 6RD
available in some retail channel products and within the OEM market. clients are becoming available in some retail channel products and
Retail availability of 6RD is important since not all operators within the OEM market. Retail availability of 6RD is important since
control or have influence over what equipment is deployed in the not all operators control or have influence over what equipment is
consumer home network. deployed in the consumer home network.
+--------+ ----- +--------+ -----
| | / \ | | / \
Encap IPv6 Flow | 6RD | | IPv6 | Encap IPv6 Flow | 6RD | | IPv6 |
- - -> | BR | <- > | Net | - - -> | BR | <- > | Net |
+---------+ / | | \ / +---------+ / | | \ /
| | / +--------+ ----- | | / +--------+ -----
| 6RD + <----- ----- | 6RD + <----- -----
| | / \ | | / \
| Client | IPv4 Flow | IPv4 | | Client | IPv4 Flow | IPv4 |
skipping to change at page 14, line 29 skipping to change at page 15, line 32
6RD used as an initial phase technology also provides the added 6RD used as an initial phase technology also provides the added
benefit of a deterministic IPv6 prefix which is based on the IPv4 benefit of a deterministic IPv6 prefix which is based on the IPv4
assigned address. Many operational tools are available or have been assigned address. Many operational tools are available or have been
built to identify what IPv4 (often dynamic) address was assigned to a built to identify what IPv4 (often dynamic) address was assigned to a
customer host/CPE. So a simple tool and/or method can be built to customer host/CPE. So a simple tool and/or method can be built to
help the operational staff in an organization know that the IPv6 help the operational staff in an organization know that the IPv6
prefix is for 6RD based on knowledge of the IPv4 address. prefix is for 6RD based on knowledge of the IPv4 address.
An operator may choose to not offer internal services over IPv6 if An operator may choose to not offer internal services over IPv6 if
such services generate a large amount of traffic. This mode of tunnelled access to IPv6 is used since some services generate a large
operation should avoid the need to greatly increase the scale of the amount of traffic. This mode of operation should avoid the need to
6RD Relay environment. greatly increase the scale of the 6RD Relay environment.
5.2.1. 6RD Deployment Considerations 5.2.1. 6RD Deployment Considerations
Deploying 6RD can greatly speed up an operator's ability to support Deploying 6RD can greatly speed up an operator's ability to support
IPv6 to the customer network. Consider by whom the system would be IPv6 to the customer network. Consider by whom the system would be
deployed, provisioned, scaled and managed. deployed, provisioned, scaled and managed.
The first core consideration is deployment models. 6RD requires the The first core consideration is deployment models. 6RD requires the
CPE (6RD client) to send traffic to a 6RD relay. These relays can CPE (6RD client) to send traffic to a 6RD relay. These relays can
share a common anycast address, or can use unique addresses. Using share a common anycast address, or can use unique addresses. Using
skipping to change at page 16, line 29 skipping to change at page 17, line 34
+---------+ ^ +------------+ | +---------+ ^ +------------+ |
| | | |
| | | |
IPv4 IP (Tools/Mgmt) IPv6 Flow Analysis IPv4 IP (Tools/Mgmt) IPv6 Flow Analysis
Figure 4: 6RD Tools and Flow Management Figure 4: 6RD Tools and Flow Management
5.3. Phase 2: Native Dual Stack 5.3. Phase 2: Native Dual Stack
Either as a follow-up phase to "Tunnelled IPv6" or as an initial Either as a follow-up phase to "Tunnelled IPv6" or as an initial
step, the operator may deploy Native IPv6 to the customer premise. step, the operator may deploy native IPv6 to the customer premise.
This phase would then allow for both IPv6 and IPv4 to be natively This phase would then allow for both IPv6 and IPv4 to be natively
accessed by the customer home gateway/CPE. The Native Dual Stack accessed by the customer home gateway/CPE. The native Dual Stack
phase be rolled out across the network while the tunnelled IPv6 phase can be rolled out across the network while the tunnelled IPv6
service remains running. As areas begin to support Native IPv6, service remains running, if used. As areas begin to support native
customer home equipment can be set to use it in place of technologies IPv6, customer home equipment can be set to use it in place of
like 6RD. Hosts using 6to4 and/or Teredo will automatically prefer technologies like 6RD. Hosts using 6to4 and/or Teredo will
[RFC3484] the IPv6 address delivered via Native IPv6 (assumed to be a automatically prefer [RFC3484] the IPv6 address delivered via native
Delegated Prefix as per [RFC3769]). IPv6 (assumed to be a Delegated Prefix as per [RFC3769]).
Native Dual Stack is the best option, and should be sought as soon as Native Dual Stack is the best option at this point in the transition,
possible. During this phase, the operator can confidently move both and should be sought as soon as possible. During this phase, the
internal and external services to IPv6. Since there are no operator can confidently move both internal and external services to
translation devices needed for this mode of operation, it transports IPv6. Since there are no translation devices needed for this mode of
both protocols (IPv6 and IPv4) efficiently within the network. operation, it transports both protocols (IPv6 and IPv4) efficiently
within the network.
5.3.1. Native Dual Stack Deployment Considerations 5.3.1. Native Dual Stack Deployment Considerations
Native Dual Stack is a very desirable option for deployment. The Native Dual Stack is a a very desirable option for the IPv6
operator must enable IPv6 at the network core and peering before they transition. The operator must enable IPv6 on the network core and
attempt to turn on Native IPv6 services. Additionally, provisioning peering before they attempt to turn on native IPv6 services.
and support systems such as DHCPv6, DNS and other functions which Additionally, provisioning and support systems such as DHCPv6, DNS
support the customer's IPv6 Internet connection need to be in place. and other functions which support the customer's IPv6 Internet
connection need to be in place.
The operator must treat IPv6 connectivity as seriously as IPv4. Poor The operator must treat IPv6 connectivity as seriously as IPv4. Poor
IPv6 service may be worse than not offering an IPv6 service at all, IPv6 service may be worse than not offering an IPv6 service at all,
since users will disable IPv6, which will be difficult for the since users may disable IPv6, which will be difficult for the
operator to reverse. New code and IPv6 functionality may cause operator to reverse. New code and IPv6 functionality may cause
instability at first. The operator will need to monitor, instability at first. The operator will need to monitor,
troubleshoot and resolve issues promptly. troubleshoot and resolve issues promptly.
Prefix assignment and routing are new for common residential Prefix assignment and routing are new for common residential
services. Prefix assignment is straightforward (DHCPv6 using services. Prefix assignment is straightforward (DHCPv6 using
IA_PDs), but installation and propagation of routing information for IA_PDs), but installation and propagation of routing information for
the prefix, especially during access layer instability, is often the prefix, especially during access layer instability, is often
poorly understood. The Operator should develop processes for poorly understood. The Operator should develop processes for
renumbering customers who they move to a new Access nodes. renumbering customers who they move to new Access nodes.
Operators need to keep track of both the dynamically assigned IPv4 Operators need to keep track of both the dynamically assigned IPv4
and IPv6 addresses. Any additional dynamic elements, such as auto- and IPv6 addresses. Any additional dynamic elements, such as auto-
generated DNS names, need to be considered and planned for. generated DNS names, need to be considered and planned for.
5.4. Intermediate Phase for CGN 5.4. Intermediate Phase for CGN
At some point during the first two phases, acquiring more IPv4 At some point during the first two phases, acquiring more IPv4
addresses may become challenging or impossible, therefore CGN may be addresses may become challenging or impossible, therefore CGN/NAT444
required on the IPv4 path. The CGN infrastructure can be enabled if may be required on the IPv4 path. The operator may have a preference
needed during either phase. CGN is less optimal in a 6RD deployment to move directly to a more efficient way of IPv4 address shared such
(if used with 6RD to a given endpoint) since all traffic must as DS-LIte, but conditions may dictate that CGN/NAT444 is the only
transverse some type of operator service node (relay and translator). workable option. CGN is less optimal and should be used cautiously
in a 6RD deployment (if used with 6RD to a given endpoint) since all
traffic must transverse some type of operator service node (relay and
translator).
+--------+ ----- +--------+ -----
| | / \ | | / \
IPv4 Flow | CGN | | | IPv4 Flow | CGN | | |
- - -> + + < -> | | - - -> + + < -> | |
+---------+ / | | | | +---------+ / | | | |
| CPE | <- - - / +--------+ | IPv4 | | CPE | <- - - / +--------+ | IPv4 |
|---------+ | Net | |---------+ | Net |
| | | |
+---------+ IPv4 Flow | | +---------+ IPv4 Flow | |
| CPE | <- - - - - - - - - - - - - - - > | | | CPE | <- - - - - - - - - - - - - - - > | |
|---------+ \ / |---------+ \ /
----- -----
Figure 5: Overlay CGN Deployment Figure 5: Overlay CGN Deployment
In the case of Native Dual Stack, CGN can be used to assist in In the case of native Dual Stack, CGN/NAT444 can be used to assist in
extending connectivity for the IPv4 path while the IPv6 path remains extending connectivity for the IPv4 path while the IPv6 path remains
native. For endpoints operating in a IPv6+CGN model the Native IPv6 native. For endpoints operating in a IPv6+CGN/NAT444 model the
path is available for higher quality connectivity helping host native IPv6 path is available for higher quality connectivity helping
operation over the network while the CGN path may offer a less then host operation over the network while the CGN path may offer a less
optimal performance. then optimal performance.
+--------+ ----- +--------+ -----
| | / \ | | / \
IPv4 Flow | CGN | | IPv4 | IPv4 Flow | CGN | | IPv4 |
- - -> + + < -> | Net | - - -> + + < -> | Net |
+---------+ / | | \ / +---------+ / | | \ /
| | <- - - / +--------+ ------- | | <- - - / +--------+ -------
| Dual | | Dual |
| Stack | ----- | Stack | -----
| CPE | IPv6 Flow / IPv6 \ | CPE | IPv6 Flow / IPv6 \
| | <- - - - - - - - - - - - - - - > | Net | | | <- - - - - - - - - - - - - - - > | Net |
|---------+ \ / |---------+ \ /
----- -----
Figure 6: Dual Stack with CGN Figure 6: Dual Stack with CGN
CGN deployments may make use of a number of address options which CGN/NAT444 deployments may make use of a number of address options
include RFC1918 or Shared CGN Address Space [I-D.weil-shared- which include RFC1918 or Shared CGN Address Space [I-D.weil-shared-
transition-space-request]. It is also possible that operators may transition-space-request]. It is also possible that operators may
use part of their own RIR assigned address space for CGN zone use part of their own RIR assigned address space for CGN zone
addressing if RFC918 addresses pose technical challenges in their addressing if RFC918 addresses pose technical challenges in their
network. It is not recommended that operators use squat space as it network. It is not recommended that operators use squat space as it
may pose additional challenges with filtering and policy control. may pose additional challenges with filtering and policy control.
5.4.1. CGN Deployment Considerations 5.4.1. CGN Deployment Considerations
CGN is often considered undesirable by operators but required in many CGN is often considered undesirable by operators but required in many
cases. An operator who needs to deploy CGN services should consider cases. An operator who needs to deploy CGN services should consider
skipping to change at page 19, line 37 skipping to change at page 21, line 7
significant investment in external systems which ingest, aggregate significant investment in external systems which ingest, aggregate
and report on such information and report on such information
[draft-donley-behave-deterministic-cgn]. [draft-donley-behave-deterministic-cgn].
Since CGN has impacts on some applications Since CGN has impacts on some applications
[draft-donley-nat444-impacts], operators may deploy CGN only for [draft-donley-nat444-impacts], operators may deploy CGN only for
those customers who do not use affected applications. Affected those customers who do not use affected applications. Affected
customers could be selected by observing usage, or by offering CGN customers could be selected by observing usage, or by offering CGN
and Native IPv4 for different prices. and Native IPv4 for different prices.
5.5. Phase 3 - Tunnelled IPv4 5.5. Phase 3 - IPv6-Only
Once Native IPv6 is ubiquitous, and well-supported by tools, staff, Once Native IPv6 is widely deployed in the network and well-supported
and processes, an operator may consider Dual-Stack Lite. DS-Lite by tools, staff, and processes, an operator may consider supporting
allows growth of the IPv4 customer base using IPv4 address sharing only IPv6 to all or some customer endpoints. During this final
for IPv4 Internet connectivity, but with only a single layer of phase, IPv4 connectivity may or may not need to be supported
translation, compared to CGN (NAT44). This mode of operation also depending on the conditions of the network and customer demand. If
removes the need to directly address customer endpoints with an IPv4 legacy IPv4 connectivity is still demanded, DS-Lite may be used to
address simplifying the connectivity to the customer (single address tunnel the traffic. If IPv4 connectivity is not required, but access
family). to legacy IPv4 content is only required, NAT64 can be used as well or
as a follow-up to DS-Lite.
The operator can also move IPv4 endpoints (Dual Stack) to DS-Lite DS-Lite allows continued access for the IPv4 customer base using
retroactively to reclaim IPv4 addresses for redeployment. To address sharing for IPv4 Internet connectivity, but with only a
minimize traffic needing translation, the operator should have single layer of translation, compared to CGN/NAT444. This mode of
already moved most content to IPv6 before this phase. operation also removes the need to directly address customer
endpoints with an IPv4 address simplifying the connectivity to the
customer (single address family) and supporting IPv6 only addressing
to the CPE.
The operator can also move Dual Stack endpoints to DS-Lite
retroactively to reclaim IPv4 addresses for redeployment or general
simplification of the routing domain. To minimize traffic needing
translation, the operator should have already moved most content to
IPv6 before the IPv6-only phase is implemented.
+--------+ ----- +--------+ -----
| | / \ | | / \
Encap IPv4 Flow | AFTR | | IPv4 | Encap IPv4 Flow | AFTR | | IPv4 |
-------+ +---+ Net | -------+ +---+ Net |
+---------+ / | | \ / +---------+ / | | \ /
| | / +--------+ ----- | | / +--------+ -----
| DS-Lite +------- ----- | DS-Lite +------- -----
| | / \ | | / \
| Client | IPv6 Flow | IPv6 | | Client | IPv6 Flow | IPv6 |
| +-------------------------------| Net | | +-------------------------------| Net |
skipping to change at page 21, line 19 skipping to change at page 22, line 45
6. IANA Considerations 6. IANA Considerations
No IANA considerations are defined at this time. No IANA considerations are defined at this time.
7. Security Considerations 7. Security Considerations
No Additional Security Considerations are made in this document. No Additional Security Considerations are made in this document.
8. Acknowledgements 8. Acknowledgements
Special thanks to Wes George and John Brzozowski for their extensive
review and comments.
Thanks to the following people for their textual contributions and/or Thanks to the following people for their textual contributions and/or
guidance on IPv6 deployment considerations: John Brzozowski, Jason guidance on IPv6 deployment considerations: Jason Weil, Nik Lavorato,
Weil, Nik Lavorato, John Cianfarani, Chris Donley, Wesley George and John Cianfarani, Chris Donley, and Tina TSOU.
Tina TSOU.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-v6ops-v4v6tran-framework]
Carpenter, B., Jiang, S., and V. Kuarsingh, "Framework for
IP Version Transition Scenarios",
draft-ietf-v6ops-v4v6tran-framework-02 (work in progress),
July 2011.
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6
Transition Mechanisms during IPv6 Deployment", RFC 6180, Transition Mechanisms during IPv6 Deployment", RFC 6180,
May 2011. May 2011.
9.2. Informative References 9.2. Informative References
[I-D.donley-nat444-impacts] [I-D.donley-nat444-impacts]
Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U.
Colorado, "Assessing the Impact of Carrier-Grade NAT on Colorado, "Assessing the Impact of Carrier-Grade NAT on
Network Applications", draft-donley-nat444-impacts-03 Network Applications", draft-donley-nat444-impacts-03
(work in progress), November 2011. (work in progress), November 2011.
[I-D.ietf-behave-lsn-requirements] [I-D.ietf-behave-lsn-requirements]
Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for Carrier Grade NAT and H. Ashida, "Common requirements for Carrier Grade NATs
(CGN)", draft-ietf-behave-lsn-requirements-04 (work in (CGNs)", draft-ietf-behave-lsn-requirements-05 (work in
progress), October 2011. progress), November 2011.
[I-D.ietf-v6ops-v4v6tran-framework]
Carpenter, B., Jiang, S., and V. Kuarsingh, "Framework for
IP Version Transition Scenarios",
draft-ietf-v6ops-v4v6tran-framework-02 (work in progress),
July 2011.
[I-D.jjmb-v6ops-comcast-ipv6-experiences] [I-D.jjmb-v6ops-comcast-ipv6-experiences]
Brzozowski, J. and C. Griffiths, "Comcast IPv6 Trial/ Brzozowski, J. and C. Griffiths, "Comcast IPv6 Trial/
Deployment Experiences", Deployment Experiences",
draft-jjmb-v6ops-comcast-ipv6-experiences-02 (work in draft-jjmb-v6ops-comcast-ipv6-experiences-02 (work in
progress), October 2011. progress), October 2011.
[I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel]
Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider
Managed Tunnels", Managed Tunnels",
draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-04 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-04
(work in progress), September 2011. (work in progress), September 2011.
[I-D.weil-shared-transition-space-request] [I-D.weil-shared-transition-space-request]
Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA Reserved IPv4 Prefix for Shared CGN M. Azinger, "IANA Reserved IPv4 Prefix for Shared Address
Space", draft-weil-shared-transition-space-request-09 Space", draft-weil-shared-transition-space-request-14
(work in progress), October 2011. (work in progress), January 2012.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001. RFC 3068, June 2001.
 End of changes. 83 change blocks. 
324 lines changed or deleted 402 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/