draft-ietf-v6ops-wireline-incremental-ipv6-01.txt   draft-ietf-v6ops-wireline-incremental-ipv6-02.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: August 5, 2012 Time Warner Cable Expires: November 10, 2012 Time Warner Cable
February 2, 2012 May 9, 2012
Wireline Incremental IPv6 Wireline Incremental IPv6
draft-ietf-v6ops-wireline-incremental-ipv6-01 draft-ietf-v6ops-wireline-incremental-ipv6-02
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
difficult challenges related to both IPv6 introduction along with difficult challenges related to both IPv6 introduction along with
those related to IPv4 run out. Operators will need to meet the those related to IPv4 run out. Operators will need to meet the
simultaneous needs of IPv6 connectivity and continue support for IPv4 simultaneous needs of IPv6 connectivity and continue support for IPv4
connectivity for legacy devices with a depleting supply of IPv4 connectivity for legacy devices with a stagnant supply of IPv4
addresses. The IPv6 transition will take most networks from an IPv4- addresses. The IPv6 transition will take most networks from an IPv4-
only environment to an IPv6 focused environment with long period of only environment to an IPv6 dominant environment with long transition
dual stack operation varying by operator. This document helps period varying by operator. This document helps provide a framework
provide a framework for Wireline providers who are faced with the for Wireline providers who are faced with the challenges of
challenges of introducing IPv6 along meeting the legacy needs of IPv4 introducing IPv6 along with meeting the legacy needs of IPv4
connectivity utilizing well defined and commercially available IPv6 connectivity utilizing well defined and commercially available IPv6
transition technologies. 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 August 5, 2012. This Internet-Draft will expire on November 10, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 3, line 10 skipping to change at page 3, line 10
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 . . . . . . . . . . . . . . . . 6
3.2. IPv4 Resource Challenges . . . . . . . . . . . . . . . . . 6 3.2. IPv4 Resource Challenges . . . . . . . . . . . . . . . . . 6
3.3. IPv6 Introduction and Operational Maturity . . . . . . . . 6 3.3. IPv6 Introduction and Operational Maturity . . . . . . . . 7
3.4. Service Management . . . . . . . . . . . . . . . . . . . . 7 3.4. Service Management . . . . . . . . . . . . . . . . . . . . 7
3.5. Sub-Optimal Operation of Transition Technologies . . . . . 8 3.5. Sub-Optimal Operation of Transition Technologies . . . . . 8
3.6. Future IPv6 Network . . . . . . . . . . . . . . . . . . . 8 3.6. Future IPv6 Network . . . . . . . . . . . . . . . . . . . 9
4. IPv6 Transition Technology Analysis . . . . . . . . . . . . . 9 4. IPv6 Transition Technology Analysis . . . . . . . . . . . . . 9
4.1. Automatic Tunnelling using 6to4 and Teredo . . . . . . . . 9 4.1. Automatic Tunnelling using 6to4 and Teredo . . . . . . . . 9
4.2. Carrier Grade NAT (NAT444) . . . . . . . . . . . . . . . . 9 4.2. Carrier Grade NAT (NAT444) . . . . . . . . . . . . . . . . 10
4.3. 6RD . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. 6RD . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 10 4.4. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 11
4.5. DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5. DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.6. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. IPv6 Transition Phases . . . . . . . . . . . . . . . . . . . . 12 5. IPv6 Transition Phases . . . . . . . . . . . . . . . . . . . . 12
5.1. Phase 0 - Foundation . . . . . . . . . . . . . . . . . . . 12 5.1. Phase 0 - Foundation . . . . . . . . . . . . . . . . . . . 13
5.1.1. Phase 0 - Foundation: Training . . . . . . . . . . . . 12 5.1.1. Phase 0 - Foundation: Training . . . . . . . . . . . . 13
5.1.2. Phase 0 - Foundation: Routing . . . . . . . . . . . . 13 5.1.2. Phase 0 - Foundation: Routing . . . . . . . . . . . . 13
5.1.3. Phase 0 - Foundation: Network Policy and Security . . 13 5.1.3. Phase 0 - Foundation: Network Policy and Security . . 14
5.1.4. Phase 0 - Foundation: Transition Architecture . . . . 13 5.1.4. Phase 0 - Foundation: Transition Architecture . . . . 14
5.1.5. Phase 0- Foundation: Tools and Management . . . . . . 14 5.1.5. Phase 0- Foundation: Tools and Management . . . . . . 14
5.2. Phase 1 - Tunnelled IPv6 . . . . . . . . . . . . . . . . . 14 5.2. Phase 1 - Tunnelled IPv6 . . . . . . . . . . . . . . . . . 15
5.2.1. 6RD Deployment Considerations . . . . . . . . . . . . 15 5.2.1. 6RD Deployment Considerations . . . . . . . . . . . . 16
5.3. Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 17 5.3. Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 18
5.3.1. Native Dual Stack Deployment Considerations . . . . . 18 5.3.1. Native Dual Stack Deployment Considerations . . . . . 19
5.4. Intermediate Phase for CGN . . . . . . . . . . . . . . . . 18 5.4. Intermediate Phase for CGN . . . . . . . . . . . . . . . . 19
5.4.1. CGN Deployment Considerations . . . . . . . . . . . . 20 5.4.1. CGN Deployment Considerations . . . . . . . . . . . . 21
5.5. Phase 3 - IPv6-Only . . . . . . . . . . . . . . . . . . . 21 5.5. Phase 3 - IPv6-Only . . . . . . . . . . . . . . . . . . . 22
5.5.1. DS-Lite Deployment Considerations . . . . . . . . . . 22 5.5.1. DS-Lite Deployment Considerations . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5.5.2. NAT64 Deployment Considerations . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
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 IPv6 anchored environment with support for dual stack to an IPv6 dominant environment with support for dual stack
operation. The end state goal for most operators will be IPv6-only, operation. The end state goal for most operators will be IPv6-only,
but the path to this final state will heavily depend on the amount of but the path to this final state will heavily depend on the amount of
legacy equipment resident in end networks and management of long tail legacy equipment resident in end networks and management of long tail
IPv4-only content. Although no single plan will work for for all IPv4-only content. Although no single plan will work for all
operators, options listed herein provide a baseline which can be operators, options listed herein provide a baseline which can be
included in many plans. included in many plans.
This draft is intended for Wireline environments which includes This draft is intended for Wireline environments which include Cable,
Cable, DSL and/or Fibre as the access method to the end consumer. DSL and/or Fibre as the access method to the end consumer. This
This draft also attempts to follow the methodologies set out in document attempts to follow the principles laid out in [RFC6180]
[I-D.ietf-v6ops-v4v6tran-framework] to identify how transition
technologies can be used individually and in combination. This
document also attempts to follow the principles laid out in [RFC6180]
which provides guidance on using IPv6 transition mechanisms. This which provides guidance on using IPv6 transition mechanisms. This
document will focus on technologies which enable and mature IPv6 document will focus on technologies which enable and mature IPv6
within the operator's network, but will also include a cursory view within the operator's network, but will also include a cursory view
of IPv4 connectivity continuance. The focal transition technologies of IPv4 connectivity continuance. The focal transition technologies
include 6RD [RFC5969], DS-Lite [RFC6333] and Dual Stack operation include 6RD [RFC5969], DS-Lite [RFC6333], NAT64 and Dual Stack
with a view into NAT44/Carrier Grade NAT (NAT44 without tunnelling as operation which may also include a CGN/NAT444 deployment. Focus on
distinct from DS-Lite). Focus on these technologies include their these technologies is based on their inclusion in many off-the-shelf
inclusion in many off-the-shelf CPEs and availability in commercially CPEs and availability in commercially available equipment.
available network vendor equipment.
2. Operator Assumptions 2. Operator Assumptions
For the purposes of this document, the authors assume: For the purposes of this document, the authors assume:
- The operator is considering deploying IPv6 or is in progress in - The operator is considering deploying IPv6 or is in progress in
deploying IPv6 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 for a period of time 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 the 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 is alble to transition their own services to support IPv6 and is able to transition their own services to support IPv6
Based on these assumptions, an operator will want to utilize Based on these assumptions, an operator will want to utilize
technologies which minimize the need to tunnel, translate or mediate technologies which minimize the need to tunnel, translate or mediate
flows to help simplify traffic flow and lower cost impacts of flows to help optimize traffic flow and lower the cost impacts of
transition technologies. Technology selections should be made to transition technologies. Transition technology selections should be
interact with the non-dominant flows and allow Native IP routing made to mediate the non-dominant IP family flows and allow native
(IPv4 and/or IPv6) to forward the dominant traffic whenever possible. routing (IPv4 and/or IPv6) to forward the dominant traffic whenever
This allows the operator to minimize the cost of IPv6 transition possible. This allows the operator to minimize the cost of IPv6
technologies by minimizing the system scaling needed by the relevant transition technologies by minimizing the transition technology
transition technology systems. deployment size.
An operator may also choose to prefer more IPv6 focused models where
the use of transition technologies are based on an effort to enable
IPv6 at the base layer as soon as possible. Operators may want to
promote IPv6 early on in the deployment and have IPv6 traffic perform
optimally from the outset. This desire would need to be weighed
against the cost and support impacts of such an choice.
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 allows the operator to an existing customer base. A phased approach allows the operator to
add in IPv6 while not ignoring legacy IPv4 connection requirements. add in IPv6 while not ignoring legacy IPv4 connection requirements.
Some of the main challenges which the operator will face include: Some of the main challenges which the operator will face include:
- IPv4 exhaustion may occur long before all traffic is able to - IPv4 exhaustion may occur long before all traffic is able to be
delivered over IPv6, necessitating IPv4 address sharing delivered over IPv6, necessitating IPv4 address sharing
- IPv6 will pose operational challenges since some of the software - IPv6 will pose operational challenges since some of the software
is unvetted in large production environments and organizations are is quite new and has had short run time in large production
not acclimatized to support IPv6 as a service environments and organizations are also not acclimatized to
supporting IPv6 as a service
Many access network devices or customer controlled CPEs may not - Many access network devices or customer controlled CPEs may not
support native IPv6 operation for a period of time support native IPv6 operation for a period of time
- Connectivity modes will move from IPv4-only to Dual Stack in the - Connectivity modes will move from IPv4-only to Dual Stack in the
home, changing functional behaviours in the consumer network home, changing functional behaviours in the consumer network
increasing support requirements for the operator increasing support requirements for the operator
These challenges will occur over a period of time which means the These challenges will occur over a period of time which means the
operator's plans need to address the ever changing requirements of 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 or jump to various phases.
3.1. Relevance of IPv6 and IPv4 3.1. Relevance of IPv6 and IPv4
The delivery of IPv6 connectivity should be the primary goal for The delivery of IPv6 connectivity should be the primary goal for
operators. Even though the operator may be focused on IPv6 delivery, operators. Even though the operator may be focused on IPv6 delivery,
they should be aware that both IPv4 and IPv6 will play a role in the they should be aware that both IPv4 and IPv6 will play a role in the
Internet experience during transition. Many customers use older Internet experience during transition. Many customers use older
operating systems and hardware which support IPv4-only operation. operating systems and hardware which support IPv4-only operation.
Internet customers don't buy IPv4 or IPv6 connections, they buy Internet customers don't buy IPv4 or IPv6 connections, they buy
Internet connections, which demands the need to support both IPv4 and Internet connections, which demands the need to support both IPv4 and
IPv6 for as long at the customer's home network demands such support. 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 likely 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 devices 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
on address sharing. facilitated by address sharing.
Networks are growing at different rates including those in emerging Networks are growing at different rates including those in emerging
markets and established networks based on the proliferation of markets and established networks based on the proliferation of
Internet based services and endpoints. IPv4 address constraints will Internet based services and devices. IPv4 address constraints will
likely affect many if not most operators at some point increasing the likely affect many if not most operators at some point increasing the
benefits of IPv6. IPv4 exhaustion is a consideration for benefits of IPv6. IPv4 address exhaustion is a consideration when
technologies which rely on IPv4 to supply IPv6 services, such as 6RD. selecting technologies which rely on IPv4 to supply IPv6 services,
Also, if native Dual Stack is considered by the operator, challenges such as 6RD. Additionally, if native Dual Stack is considered by the
on the IPv4 path is also of concern. operator, challenges related to IPv4 address exhaustion remain a
concern.
Some operators may be able to reclaim some IPv4 addresses through Some operators may be able to reclaim small amounts IPv4 addresses
efficiency in the network and the replacement of globally-unique IPv4 through addressing efficiencies in the network, although this will
assignments with private addresses [RFC1918]. These measures are have little lasting benefits to the network and not meet longer term
tactical and do are not long term strategic options. The lack of new connectivity needs. The lack of new global IPv4 address allocations
IPv4 addresses will therefore force operators to support some form of will therefore force operators to support some form of IPv4 address
IPv4 address sharing and may impact technological options for sharing and may impact technological options for transition once the
transition once the operator runs out of new IPv4 addresses for operator runs out of new IPv4 addresses for assignment.
assignment.
3.3. IPv6 Introduction and Operational 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 early IPv6 deployment with IPv6. Inexperience may lead to early IPv6 deployment
instability, and Operators should consider this when selecting instability, and Operators should consider this when selecting
technologies for initial transition. Operators may not want to technologies for initial transition. Operators may not want to
subject their mature IPv4 service to a "new IPv6" path initially subject their mature IPv4 service to a "new IPv6" path initially
while it may be going through growing pains. DS-Lite is one such while it may be going through growing pains. DS-Lite [RFC6333] and
technology which requires IPv6 to support IPv4. NAT64 are both technologies which requires IPv6 to support
connectivity to IPv4 endpoints or content over an IPv6-only access
network.
Further, some of these transition technologies are new and require Further, some of these transition technologies are new and require
refinement within running code. Deployment experience may be needed refinement within running code. Deployment experience is required to
to expose bugs and stabilize software in production environments. expose bugs and stabilize software in production environments. Many
Many supporting systems are also under development and have newly 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 elements. 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, organizational experience is low. 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 - the deployment offering, how it operates and how to troubleshoot it - the deployment
is maturing. This fact should not incline an operator to delay their is maturing. This fact should not incline operators to delay their
IPv6 deployment, but should drive them to deploy IPv6 sooner to gain 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 the much needed experience before IPv6 is the only viable way to
hosts to the network. connect new hosts to the network.
It should also be noted that although many transition technologies It should also be noted that although many transition technologies
may be new, and some code related to access environments may be new, 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 there is a large segment of the networking fabric which has had IPv6
available for a long period of time and has had extended exposure in available for a long period of time and has had extended exposure in
production. Operators may use this to their advantage by first production. Operators may use this to their advantage by first
enabling IPv6 in the core of their network the work outward towards enabling IPv6 in the core of their network then work outward towards
the customer edge. 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 assigned to endpoints.
address such management tools, troubleshooting methods and storage
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
time. Examination of address type, and recording delegated prefixes
along with single addresses, will likely require additional
development.
With any Dual Stack service - whether Native, 6RD based, DS-Lite Operators will need to address such management tools, troubleshooting
based or otherwise - two address families may need to be managed methods and storage facilities (such as databases) to deal with not
simultaneously to help provide for the full Internet experience. just a new address type containing a 128-bit IPv6 address, but often
both IPv4 and IPv6 at the same time. Examination of address type,
and recording delegated prefixes along with single address
assignments, will likely require additional development.
This would indicate that IPv6 management is not just an simple add With any Dual Stack service - whether Native, 6RD based, DS-Lite,
in, but needs to be well integrated into the service management NAT64 or otherwise - two address families may need to be managed
simultaneously to help provide for the full Internet experience.
This would indicate that IPv6 management is not just a simple add in,
but needs to be well integrated into the service management
infrastructure. In the early transition phases, it's quite likely infrastructure. In the early transition phases, it's quite likely
that many systems will be missed and that IPv6 services will go un- that many systems will be missed and that IPv6 services will go un-
monitored and impairments undetected. 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 connectivity. Instability on the IPv6 service in such a case would
services. impact IPv4 services.
3.5. Sub-Optimal Operation of Transition Technologies 3.5. Sub-Optimal Operation of Transition Technologies
When contrasting native Dual Stack versus other transition When contrasting native Dual Stack versus other transition
technologies it should be noted that native IP paths are well technologies it should be noted that native IP paths are well
understood and networks are often optimized to send such traffic understood and networks are often optimized to send such traffic
efficiently. Transition technologies however, may alter the normal efficiently. Transition technologies however, may alter the normal
path of traffic removing many network efficiencies built for native path of traffic removing many network efficiencies built for native
IP flows. Tunnelling and translation devices may not be located on IP flows. Tunnelling and translation devices may not be located on
the most optimal path in line with natural traffic flow and may the most optimal path in line with natural traffic flow (based on
increase latency. These paths may also add additional points of route computation) and therefore may increase latency. These paths
failure. 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 if possible. During earlier phases of the less dominant address family if possible. During earlier phases
transition, IPv4 traffic volumes may still be dominant, so tunnelling of transition, IPv4 traffic volumes may still be dominant, so
of IPv6 traffic is reasonable. Over time, as IPv6 traffic volumes tunnelling of IPv6 traffic is reasonable. Over time, as IPv6 traffic
will increase, native delivery of IPv6 traffic becomes advantageous. volumes will increase, native delivery of IPv6 traffic becomes
When IPv4 connectivity demands diminish, translation and tunnelling advantageous. When IPv4 connectivity demands diminish, translation
of IPv4 over IPv6 may be acceptable and more optimal. and tunnelling 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, if for their services, especially high traffic services like high
CGN is deployed, the operator may wish to promote native IPv6 access. quality IP video. Likewise, if CGN is deployed, the operator may
wish to promote native IPv6 access for these services.
3.6. Future IPv6 Network 3.6. Future IPv6 Network
An operator should also be aware that longer term plans may include 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 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 view may be distant to some, but should be considered when planning
out networks, addressing and services. The needs and costs of out networks, addressing and services. The needs and costs of
maintaining two IP stacks will eventually become burdensome and maintaining two IP stacks will eventually become burdensome and
simplification will be required. The operators should plan for this simplification will be desirable. The operators should plan for this
state and not make IPv6 inherently dependant on IPv4 as this would state and not make IPv6 inherently dependent on IPv4 as this would
unnecessarily constrain an operator. unnecessarily constrain the network.
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 and commercially available options. This of some of the mainstream and commercially available options. This
analysis is focused on the applicability of technologies to deliver analysis is focused on the applicability of technologies to deliver
residential services and less focused on commercial access or residential services and less focused on commercial access, Wireless
infrastructure support. 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 CPE hardware. mechanisms exist on customer operating systems and CPE hardware.
Such technologies include 6to4 [RFC3056] which is most commonly used Such technologies include 6to4 [RFC3056] which is most commonly used
with anycast relays [RFC3068]. Teredo [RFC4380] is also used widely with anycast relays [RFC3068]. Teredo [RFC4380] is also used widely
skipping to change at page 9, line 35 skipping to change at page 9, line 46
Documents such as [RFC6343] have been written to help operators Documents such as [RFC6343] have been written to help operators
understand observed problems with 6to4 deployments and provides understand observed problems with 6to4 deployments and provides
guidelines on how to improve it's performance. An Operator may want guidelines on how to improve it's performance. An Operator may want
to provide local relays for 6to4 and/or Teredo to help improve the to provide local relays for 6to4 and/or Teredo to help improve the
protocol's performance for ambient traffic utilizing these IPv6 protocol's performance for ambient traffic utilizing these IPv6
connectivity methods. Experiences such as those described in connectivity methods. Experiences such as those described in
[I-D.jjmb-v6ops-comcast-ipv6-experiences] show that local relays have [I-D.jjmb-v6ops-comcast-ipv6-experiences] show that local relays have
proved beneficial to 6to4 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 NAT444/CGN zones. Many off the shelf RFC1918 addresses are used within CGN/NAT444 zones. Many off the
CPEs and operating systems may turn on 6to4 without a valid return shelf CPEs and operating systems may turn on 6to4 without a valid
path to the originating (local) host. This particular use is likely return path to the originating (local) host. This particular usecase
to occur if any space other than [RFC1918] is used, including Shared is likely to occur if any space other than [RFC1918] is used,
CGN Space [I-D.weil-shared-transition-space-request] or space including Shared Address Space [RFC6598] or space registered to
registered to another organization (squat space). The operator can another organization (squat space). The operator can use 6to4-PMT
use 6to4-PMT [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] or
attempt to block 6to4 operation entirely by blocking the ancycast [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] or attempt to
ranges associated with [RFC3068]. 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 may be necessary depending on how an operator
has chosen to deal with IPv6 transition and legacy IPv4 connectivity
requirements.
In a network where IPv4 address availability is low, CGN based on In a network where IPv4 address availability is low, CGN/NAT444, may
NAT444 may provide continued access to IPv4 endpoints. Other provide continued access to IPv4 endpoints. Some of the advantages
technologies (4rd, IVI) may also be used in place of the NAT444 model of using CGN/NAT444 include the similarities in provisioning and
with CGN. Some of the advantages of using CGN using NAT444 include activation models. IPv4 hosts in a CGN/NAT444 deployment will likely
the similarities in provisioning and activation of IPv4 hosts and are inherent the same addressing and management procedures as legacy
part of current network and operational procedures for managing such IPv4, globally addressed hosts (i.e. DHCPv6, DNSv4, TFTP, TR-069
hosts or CPEs (i.e. DHCPv6, DNSv4, TFTP, TR-069 etc). etc).
4.3. 6RD 4.3. 6RD
6RD [RFC5969] does provide a quick and effective way to deliver IPv6 6RD [RFC5969] provides a way of offering IPv6 connectivity to
services to customer endpoints when native IPv6 addressing on the customer endpoints when native IPv6 addressing on the access network
access network is not yet possible. 6RD provides tunnelled is not yet possible. 6RD provides tunnelled connectivity for IPv6
connectivity for IPv6 over the existing IPv4 path. As the access over the existing IPv4 path. As the access edge is upgraded and
edge is upgraded and customer premise equipment is replaced, 6RD can customer premise equipment is replaced, 6RD can be replace by native
be superseded by native IPv6 access. 6RD can be delivered along side IPv6 connectivity. 6RD can be delivered over top a CGN/NAT444
a CGN/NAT444 deployment, but this would cause all traffic to be deployment, but this would cause all traffic to be subject to some
subject to some type of transition technology. 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 by adding relays to
relays. As IPv6 traffic volume grows, the operator can gradually the operator's network. Another advantage for 6RD is that the
replace 6RD with native IPv6. operator does not need a DHCPv6 address assignment infrastructure and
and does not need to support IPv6 routing to the CPE to support a
delegated prefix (as it's derived from the IPv4 address and other
configuration parameters).
6RD client support is required, but most currently deployed CPEs do Client support is required for 6RD operation and may not be available
not have 6RD client functionality built into them and may not be on deployed hardware. 6RD deployments may require the customer or
upgradable. 6RD deployments would most likely require the replacement operator to replace the CPE. 6RD will also require parameter
of the home CPE. An advantage of 6RD in the early stages of
transition is that the WAN side interface does not need to implement
IPv6 to function correctly which may make it easier to deploy to
field hardware which is restricted in memory footprint, processing
power and storage space. 6RD will also require parameter
configuration which can be powered by the operator through DHCPv4, configuration which can be powered by the operator through DHCPv4,
manually provisioned on the CPE or automatically through some other manually provisioned on the CPE or automatically through some other
means. 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. 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 traditional native Dual Stack. In cases will not be able to provide traditional native Dual Stack
where sufficient IPv4 addresses are not available, CGN/NAT444 can be connectivity for new customers. In Dual Stack deployments where
used on the IPv4 path. 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 to support IPv6. Other systems like DHCP, DNS, and access network to support IPv6. Other systems like DHCP, DNS, and
diagnostic/management facilities need to be upgraded to support IPv6. diagnostic/management facilities need to be upgraded to support IPv6
The upgrade of such systems may often be non-trivial. as well. The upgrade of such systems may often be non-trivial and
costly.
4.5. DS-Lite 4.5. DS-Lite
Dual-Stack Lite (DS-Lite, [RFC6333]) is based on an native IPv6 Dual-Stack Lite (DS-Lite, [RFC6333]) is based on a native IPv6
service delivery model where IPv4 services are supported. DS-Lite connection model where IPv4 services are supported. DS-Lite provides
provides tunnelled connectivity for IPv4 over the IPv6 path between tunnelled connectivity for IPv4 over the IPv6 path between the
the customer's network device and a provider managed gateway (AFTR). 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 connection
between the AFTR and the customer premise endpoint. This may mean between the AFTR and the CPE. This may mean that the technology's
that the technology's use may not be viable during early transition use may not be viable during early transition if the core or access
if the core or access network lacks IPv6 support. Early transition network lacks IPv6 support. During the early transition period a
stages may also occur when a significant about of content and significant amount of content and services may by IPv4-only.
services are delivered over the legacy IPv4 path. Operators may be Operators may be sensitive to this and may not want the newer IPv6
sensitive to this and may not want the newer IPv6 path to be the only path to be the only bridge to IPv4 at that time given the potential
bridge to IPv4 at that time. The provider may also want to make sure impact. The operator may also want to make sure that most of their
that most of their internal services and a significant about of internal services and a significant about of external content is
external content is available over IPv6 before deploying DS-Lite. available over IPv6 before deploying DS-Lite. The availability of
The availability of services on IPv6 would help lower the demand on services on IPv6 would help lower the demand on the AFTRs.
the AFTRs.
By sharing IPv4 addresses among multiple endpoints, like CGN/NAT444, By sharing IPv4 addresses among multiple endpoints, like CGN/NAT444,
DS- Lite can facilitate continued support of legacy IPv4 services DS-Lite can facilitate continued support of legacy IPv4 services even
even after IPv4 run out. There are some functional considerations to after IPv4 address run out. There are some functional considerations
consider event with DS-Lite such as those described in to take into account even with DS-Lite such as those described in
[draft-donley-nat444-impacts].
Similar to 6RD, DS-Lite requires client support on the CPE to [I-D.donley-nat444-impacts] and [I-D.ietf-softwire-dslite-
function. Client functionality is likely to be more prevalent in the deployment].
future as IPv6 capable (WAN side) CPEs begin to penetrate the market.
This includes both retail and operator provided gateways. DS-Lite requires client support on the CPE to function. The ability
to utilize DS-Lite will be dependent on the operator providing DS-
Lite capable CPEs or retail availability of the supported client for
customer acquired endpoints.
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 without any tunnelling. 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. All IPv6-capable equipment scenarios are not considered operation. Home networks do not commonly contain equipment which is
typical in most traditional Wireline hosted customer networks, are all IPv6-capable. It is also not anticipated that common home
are not likely to be so in the near future. networks will be ready for IPv6-only operation for a number of years.
However, IPv6-only networking can be deployed by early adopters or
highly controlled networks.
Viability of NAT64 will increase in Wireline networks as consumer Viability of NAT64 will increase in Wireline networks as consumer
equipment is replaced by IPv6 capable versions. equipment is replaced by IPv6 capable versions. There are incentives
for operators to move to IPv6-only operation, when feasible, which
includes the simplicity of a single stack access network.
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 operators 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, (residential/corporate, fixed/mobile), their business
development perspectives (which may affect the pace of migration
towards full IPv6), or a combination thereof.
The phases are based on an expectation that IPv6 traffic volume may The phases are based on the 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 traffic volumes of IPv6 increase, IPv4 traffic volume over time. As traffic volumes of IPv6 increase, IPv4 traffic volumes
will correspondingly decrease, until IPv6 is the predominant address will correspondingly decrease, until IPv6 is the predominant address
family used. For each phase, the predominant address family should family used. Operators may want to keep the traffic flow for the
be native, while mediation (tunnelling or translation) may be dominant traffic class (IPv4 vs. IPv6) native to help manage costs
acceptable for address family which generates the lower amount of related to transition technologies. The cost of using multiple
volume on the network. technologies in succession to optimize each stage of the transition
should also be compared against the cost of changing and upgrading
customer connections.
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. The with IPv6, and many do not even have a solid grounding in IPv4. The
implementation of IPv6 will likely produce many challenges - due to implementation of IPv6 will likely produce many challenges due to
immature code on hardware, and the evolution of many applications and immature code on hardware, and the evolution of many applications and
systems to support IPv6 - organizations must train their staff on systems to support IPv6. To properly deal with these impending or
IPv6. current challenges organizations must train their staff on IPv6.
Training should also be provided within reasonable timelines from the 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 since many organizations have massive call centres to training since many organizations have massive call centres to
support the customer base. support the customer base. Tailored training will also be required
for marketing and sales staff to help them understand IPv6 and build
it into the product development and sales process.
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 several 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 network environments will no longer receive a One such change is the notion of a delegated prefix which deviates
token single address as is common in IPv4, operators will need to from the common single address phenomenon in IPv4-only deployments.
understand the impacts of delegating a large sum of addresses Deploying prefixes per CPE can load the routing tables and require a
(prefixes) to consumer endpoints. Delegating prefixes can be of routing protocol or route gleaning to manage connectivity to the
specific importance in access network environments where downstream customer's network. Delegating prefixes can be of specific
customers often move between access nodes, raising the concern of importance in access network environments where downstream customers
frequent renumbering and/or managing movement of routed prefixes often move between access nodes, raising the concern of frequent
within the network (common in cable based networks). renumbering and/or managing movement of routed prefixes 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
operation. This document does not highlight these specific issues, operation. This document does not highlight these specific issues,
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 such
([RFC4942], [RFC6092], [RFC6169], for instance) are excellent as [RFC4942], [RFC6092], and [RFC6169] 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 operators should plan out their transition architecture in
(with room for flexibility) to help optimize how they will build out advance (with room for flexibility) to help optimize how they will
and scale their networks. If the operator should want to use build out and scale their networks. Should the operator consider
multiple technologies like CGN/NAT444, DS-Lite and 6RD, they may want multiple technologies like CGN/NAT444, DS-Lite, NAT64 and 6RD, they
to plan out where network resident equipment may be located and may want to plan out where network resident equipment may be located
potentially choose locations which can be used for all three and potentially choose locations which can be used for all functional
functional roles (i.e. placement of NAT44 translator, AFTR and 6RD roles (i.e. placement of NAT44 translator, AFTR, NAT64 gateway and
relays). This would allow for the least disruption as the operator 6RD relays). Although these functions are not inherently connected,
evolves the transition environment to meet the needs of the customer additional management, diagnostic and monitoring functions can be
base. This approach may also prove beneficial if traffic patterns deployed along side the transition hardware without the need to
change rapidly in the future and the operator may need to evolve distribute these to an excessive or divergent number of locations.
their transition infrastructure faster than originally anticipated.
This approach may also prove beneficial if traffic patterns change
rapidly in the future as the operators may need to evolve their
transition infrastructure faster than originally anticipated. Once
such example may be the movement from a CGN/NAT44 model (dual stack)
to DS-Lite. Since both traffic sets require a translation function
(NAT44), synchronized pool management, routing and management system
positioning can allow rapid movement (notwithstanding the
technological means to re-provision the customers).
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 The operator should also plan their overall strategy to meet the
target needs of an IPv6-only deployment. Over time, IPv4 maintenance target needs of an IPv6-only deployment. As traffic moves to IPv6,
will become cumbersome so support and an operator may want to remove the benefits of only a single stack on the access network may justify
it from the access connectivity portion of their network. Planning the removal of IPv4 for simplicity. Planning for this eventual
for this eventual stage, no matter how far off this may be, will help model, no matter how far off this may be, will help the operator
the operator embrace this end state when needed. 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 management systems to develop requirements for each phase. This will
include concepts related to the 128-bit IPv6 address, the notation of include concepts related to the 128-bit IPv6 address, the notation of
an assigned IPv6 prefix (PD) and the ability to detect either or both an assigned IPv6 prefix (PD) and the ability to detect either or both
address families when determining if a customer has full Internet address families when determining if a customer has 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
Tunnelled access to IPv6 offers a viable early stage transition Tunnelled access to IPv6 can be regarded as an early stage transition
option to operators. Many network operators can deploy native IPv6 option by operators. Many network operators can deploy native IPv6
from access edge to peering edge fairly quickly but may not be able from the access edge to the peering edge fairly quickly but may not
to offer IPv6 natively to the customer edge device. During this be able to offer IPv6 natively to the customer edge device. During
period of time, tunnelled access to IPv6 is a viable alternative to this period of time, tunnelled access to IPv6 is a viable alternative
native IPv6. It is also possible that operators my be rolling out to native IPv6. It is also possible that operators my be rolling out
IPv6 natively to the customer edge but the time involved may be long IPv6 natively to the customer edge but the time involved may be long
due to logistics and other factors. Even while slowly rolling out due to logistics and other factors. Even while slowly rolling out
native IPv6, operators can deploy relays for automatic tunnelling native IPv6, operators can deploy relays for automatic tunnelling
technologies like 6to4 and Teredo. Where native IPv6 to the access technologies like 6to4 and Teredo. Where native IPv6 to the access
edge is a longer-term project, operators can consider 6RD [RFC5969] 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 as an option to offer in-home IPv6 access. Note that 6to4 and Teredo
have different address selection behaviours from 6RD [RFC3484]. have different address selection behaviours than 6RD [RFC3484].
Additional guidelines on deploying and supporting 6to4 can be found Additional guidelines on deploying and supporting 6to4 can be found
in [RFC6343]. in [RFC6343].
The operator can deploy 6RD relays easily and scale them as needed to The operator can deploy 6RD relays into the network and scale them as
meet the early customer needs of IPv6. Since 6RD requires the needed to meet the early customer needs of IPv6. Since 6RD requires
upgrade or replacement of CPE gateways, the operator may want ensure the upgrade or replacement of CPE devices, the operator may want
that the gateways support not just 6RD but native Dual Stack and ensure that the CPE devices support not just 6RD but native Dual
other tunnelling technologies if possible such as DS-Lite. 6RD Stack and other tunnelling technologies if possible such as DS-Lite.
clients are becoming available in some retail channel products and 6RD clients are becoming available in some retail channel products
within the OEM market. Retail availability of 6RD is important since and within the OEM market. Retail availability of 6RD is important
not all operators control or have influence over what equipment is since not all operators control or have influence over what equipment
deployed in the consumer home network. is deployed in the consumer home network. The operator can support
6RD access with unmanaged devices using DHCPv4 option 212
(OPTION_6RD).
+--------+ ----- +--------+ -----
| | / \ | | / \
Encap IPv6 Flow | 6RD | | IPv6 | Encap IPv6 Flow | 6RD | | IPv6 |
- - -> | BR | <- > | Net | - - -> | BR | <- > | Net |
+---------+ / | | \ / +---------+ / | | \ /
| | / +--------+ ----- | | / +--------+ -----
| 6RD + <----- ----- | 6RD + <----- -----
| | / \ | | / \
| Client | IPv4 Flow | IPv4 | | Client | IPv4 Flow | IPv4 |
| + < - - - - - - - - - - - - - - -> | Net | | + < - - - - - - - - - - - - - - -> | Net |
| | \ / | | \ /
+---------+ ----- +---------+ -----
Figure 1: 6RD Basic Model Figure 1: 6RD Basic Model
6RD used as an initial phase technology also provides the added 6RD used as an initial transition 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 CPE. So a simple tool and/or method can be built to help
help the operational staff in an organization know that the IPv6 the operational staff in an organization know that the IPv6 prefix is
prefix is for 6RD based on knowledge of the IPv4 address. for a 6RD serviced CPE 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
tunnelled access to IPv6 is used since some services generate a large tunnelled access to IPv6 is used since some services generate a large
amount of traffic. This mode of operation should avoid the need to amount of traffic. Such traffic may include Video content like IPTV.
greatly increase the scale of the 6RD Relay environment. By limiting how much traffic is delivered over the 6RD connection (if
possible), the operator can avoid costly and complex scaling of the
relay infrastructure.
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 if native IPv6 connectivity cannot be
deployed, provisioned, scaled and managed. supplied. The speed at which 6RD can be deployed is highlighted in
[RFC5569].
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
an anycast model, the operator can deploy all the 6RD relays using an anycast model, the operator can deploy all the 6RD relays using
the same IPv4 interior service address. As the load increases on the the same IPv4 interior service address. As the load increases on the
deployed relays, the operator can deploy more relays into the deployed relays, the operator can deploy more relays into the
network. The one drawback here is that it may be difficult manage network. The one drawback here is that it may be difficult to manage
the traffic volume among additional relays, since all 6RD traffic the traffic volume among additional relays, since all 6RD traffic
will find the nearest (in terms of IGP cost) relay. Use of specific will find the nearest (in terms of IGP cost) relay. Use of multiple
addresses can help provide more control but has the disadvantage of relay addresses can help provide more control but has the
being more complex to provision as CPEs will contain different disadvantage of being more complex to provision as subsets of CPEs
across the network will require and contain different relay
information. An alternative approach is to use a hybrid model using information. An alternative approach is to use a hybrid model using
multiple anycast service IPs for clusters of 6RD relays should the multiple anycast service IPs for clusters of 6RD relays should the
operator anticipate massive scaling of the environment. This way, operator anticipate massive scaling of the environment. Thus, the
the operator has multiple vectors by which to scale the service. operator has multiple vectors by which to scale the service.
+--------+ +--------+
| | | |
IPv4 Addr.X | 6RD | IPv4 Addr.X | 6RD |
- - - > | BR | - - - > | BR |
+-----------+ / | | +-----------+ / | |
| Client A | <- - - +--------+ | Client A | <- - - +--------+
+-----------+ +-----------+
Separate IPv4 Service Addresses Separate IPv4 Service Addresses
+-----------+ +-----------+
skipping to change at page 17, line 34 skipping to change at page 18, 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 down to the CPEs. This
This phase would then allow for both IPv6 and IPv4 to be natively phase would then allow for both IPv6 and IPv4 to be natively accessed
accessed by the customer home gateway/CPE. The native Dual Stack by the customer home network without translation or tunnelling. The
phase can be rolled out across the network while the tunnelled IPv6 native Dual Stack phase can be rolled out across the network while
service remains running, if used. As areas begin to support native the tunnelled IPv6 service remains operational, if used. As areas
IPv6, customer home equipment can be set to use it in place of begin to support native IPv6, customer home equipment will generally
technologies like 6RD. Hosts using 6to4 and/or Teredo will prefer using the IPv6 addresses derived from the delegated IPv6
automatically prefer [RFC3484] the IPv6 address delivered via native prefix versus tunnelling options such as 6to4, 6RD and Teredo as
IPv6 (assumed to be a Delegated Prefix as per [RFC3769]). defined in [RFC3484]
Native Dual Stack is the best option at this point in the transition, Native Dual Stack is the best option at this point in the transition,
and should be sought as soon as possible. During this phase, the and should be sought as soon as possible. During this phase, the
operator can confidently move both internal and external services to operator can confidently move both internal and external services to
IPv6. Since there are no translation devices needed for this mode of IPv6. Since there are no translation devices needed for this mode of
operation, it transports both protocols (IPv6 and IPv4) efficiently operation, it transports both protocols (IPv6 and IPv4) efficiently
within the network. within the network.
5.3.1. Native Dual Stack Deployment Considerations 5.3.1. Native Dual Stack Deployment Considerations
Native Dual Stack is a a very desirable option for the IPv6 Native Dual Stack is a very desirable option for the IPv6 transition
transition. The operator must enable IPv6 on the network core and if feasible. The operator must enable IPv6 on the network core and
peering before they attempt to turn on native IPv6 services. peering edge before they attempt to turn on native IPv6 services.
Additionally, provisioning and support systems such as DHCPv6, DNS Additionally, provisioning and support systems such as DHCPv6, DNS
and other functions which support the customer's IPv6 Internet and other functions which support the customer's IPv6 Internet
connection need to be in place. connection need to be in place.
The operator must treat IPv6 connectivity as seriously as IPv4. Poor The operator must treat IPv6 connectivity with the same operational
IPv6 service may be worse than not offering an IPv6 service at all, importance as IPv4. Poor IPv6 service may be worse than not offering
since users may disable IPv6, which will be difficult for the an IPv6 service at all, since users may cause users to disable IPv6
operator to reverse. New code and IPv6 functionality may cause and negatively impact their Internet experience. New code and IPv6
instability at first. The operator will need to monitor, functionality may cause instability at first. The operator will need
troubleshoot and resolve issues promptly. to monitor, 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 new Access nodes. renumbering customers who 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- address along with the IPv6 address and prefix. Any additional
generated DNS names, need to be considered and planned for. dynamic elements, such as auto-generated host 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 Acquiring more IPv4 addresses is already challenging, if not
addresses may become challenging or impossible, therefore CGN/NAT444 impossible, therefore address sharing may be required on the IPv4
may be required on the IPv4 path. The operator may have a preference path. The operator may have a preference to move directly to a more
to move directly to a more efficient way of IPv4 address shared such efficient way of IPv4 address sharing such as DS-Lite, but conditions
as DS-LIte, but conditions may dictate that CGN/NAT444 is the only may dictate that CGN/NAT444 is the only workable option. CGN/NAT444
workable option. CGN is less optimal and should be used cautiously is less optimal and should be used cautiously in a 6RD deployment (if
in a 6RD deployment (if used with 6RD to a given endpoint) since all used with 6RD to a given endpoint) since all traffic must traverse
traffic must transverse some type of operator service node (relay and some type of operator service node (relay and translator).
translator).
+--------+ ----- +--------+ -----
| | / \ | | / \
IPv4 Flow | CGN | | | IPv4 Flow | CGN | | |
- - -> + + < -> | | - - -> + + < -> | |
+---------+ / | | | | +---------+ / | | | |
| CPE | <- - - / +--------+ | IPv4 | | CPE | <- - - / +--------+ | IPv4 |
|---------+ | Net | |---------+ | Net |
| | | |
+---------+ IPv4 Flow | | +---------+ IPv4 Flow | |
skipping to change at page 19, line 25 skipping to change at page 20, line 25
|---------+ \ / |---------+ \ /
----- -----
Figure 5: Overlay CGN Deployment Figure 5: Overlay CGN Deployment
In the case of native Dual Stack, CGN/NAT444 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/NAT444 model the native. For endpoints operating in a IPv6+CGN/NAT444 model the
native IPv6 path is available for higher quality connectivity helping native IPv6 path is available for higher quality connectivity helping
host operation over the network while the CGN path may offer a less host operation over the network while the CGN path may offer a less
then optimal performance. than optimal performance. These points are also true for DS-Lite.
+--------+ ----- +--------+ -----
| | / \ | | / \
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/NAT444 deployments may make use of a number of address options CGN/NAT444 deployments may make use of a number of address options
which include RFC1918 or Shared CGN Address Space [I-D.weil-shared- which include RFC1918 or Shared Address Space [RFC6598]. It is also
transition-space-request]. It is also possible that operators may possible that operators may use part of their own RIR assigned
use part of their own RIR assigned address space for CGN zone address space for CGN zone addressing if [RFC1918] addresses pose
addressing if RFC918 addresses pose technical challenges in their technical challenges in their network. It is not recommended that
network. It is not recommended that operators use squat space as it operators use squat space as it may pose additional challenges with
may pose additional challenges with filtering and policy control. 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 capabilities should
it's impacts to the network. CGN is often deployed in addition to consider the impacts of the function to the network. CGN is often
running IPv4 services and should not negatively impact the already deployed in addition to running IPv4 services and should not
working Native IPv4 service. CGNs will also be needed at low scale negatively impact the already working Native IPv4 service. CGNs will
at first and grown to meet future demands based on traffic and also be needed at low scale at first and grown to meet the demands
connection dynamics of the customer, content and network peers. based on traffic and connection dynamics of the customer, content and
network peers.
The operator may want to deploy CGNs more centrally at first and then The operator may want to deploy CGNs more centrally at first and then
scale the system as needed. This approach can help conserve costs of scale the system as needed. This approach can help conserve costs of
the system and only spend money on equipment with the actual growth the system and only spend money on equipment based on the actual
of traffic (demand on CGN system). The operator will need a growth of traffic (demand on CGN system). The operator will need a
deployment model and architecture which allows the system to scale as deployment model and architecture which allows the system to scale as
needed. needed.
+--------+ ----- +--------+ -----
| | / \ | | / \
| CGN | | | | CGN | | |
- - -> + + < -> | | - - -> + + < -> | |
+---------+ / | | | | +---------+ / | | | |
| CPE | <- - - / +--------+ | IPv4 | | CPE | <- - - / +--------+ | IPv4 |
| | ^ | | | | ^ | |
skipping to change at page 20, line 43 skipping to change at page 21, line 44
| CPE | <- > + + <- - - - - - - > | | | CPE | <- > + + <- - - - - - - > | |
|---------+ | | \ / |---------+ | | \ /
+--------+ ----- +--------+ -----
^ ^
| |
Distributed CGN Distributed CGN
Figure 7: CGN Deployment: Centralized vs. Distributed Figure 7: CGN Deployment: Centralized vs. Distributed
The operator may be required to log translation information The operator may be required to log translation information
[draft-sivakumar-behave-nat-logging]. This logging may require [I-D.sivakumar-behave-nat-logging]. This logging may require
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 [I-D.donley-behave-deterministic-cgn].
[draft-donley-behave-deterministic-cgn].
Since CGN has impacts on some applications Since CGN has noticeable impacts on certain applications [I.D.donley-
[draft-donley-nat444-impacts], operators may deploy CGN only for nat444-impacts], operators may deploy CGN only for those customers
those customers who do not use affected applications. Affected who may not likely be affected by CGN (if possible).
customers could be selected by observing usage, or by offering CGN
and Native IPv4 for different prices.
5.5. Phase 3 - IPv6-Only 5.5. Phase 3 - IPv6-Only
Once Native IPv6 is widely deployed in the network and well-supported Once Native IPv6 is widely deployed in the network and well-supported
by tools, staff, and processes, an operator may consider supporting by tools, staff, and processes, an operator may consider supporting
only IPv6 to all or some customer endpoints. During this final only IPv6 to all or some customer endpoints. During this final
phase, IPv4 connectivity may or may not need to be supported phase, IPv4 connectivity may or may not need to be supported
depending on the conditions of the network and customer demand. If depending on the conditions of the network and customer demand. If
legacy IPv4 connectivity is still demanded, DS-Lite may be used to legacy IPv4 connectivity is still demanded, DS-Lite may be used to
tunnel the traffic. If IPv4 connectivity is not required, but access tunnel the traffic. If IPv4 connectivity is not required, but access
to legacy IPv4 content is only required, NAT64 can be used as well or to legacy IPv4 content is , then NAT64 can be used.
as a follow-up to DS-Lite.
DS-Lite allows continued access for the IPv4 customer base using DS-Lite allows continued access for the IPv4 customer base using
address sharing for IPv4 Internet connectivity, but with only a address sharing for IPv4 Internet connectivity, but with only a
single layer of translation, compared to CGN/NAT444. This mode of single layer of translation, compared to CGN/NAT444. This mode of
operation also removes the need to directly address customer operation also removes the need to directly address customer
endpoints with an IPv4 address simplifying the connectivity to the endpoints with an IPv4 address simplifying the connectivity to the
customer (single address family) and supporting IPv6 only addressing customer (single address family) and supporting IPv6 only addressing
to the CPE. to the CPE.
The operator can also move Dual Stack endpoints to DS-Lite The operator can also move Dual Stack endpoints to DS-Lite
retroactively to reclaim IPv4 addresses for redeployment or general retroactively to help optimize the IPv4 address sharing deployment by
simplification of the routing domain. To minimize traffic needing removing the IPv4 address assignment and routing component. To
translation, the operator should have already moved most content to minimize traffic needing translation, the operator should have
IPv6 before the IPv6-only phase is implemented. 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 |
| | \ / | | \ /
+---------+ ----- +---------+ -----
Figure 8: DS-Lite Basic Model Figure 8: DS-Lite Basic Model
If the operator was forced to enable CGN for a NAT444 deployment, If the operator decided to enable a CGN/NAT444 deployment, they may
they may be able to co-locate the AFTR and CGN functions within the be able to co-locate the AFTR and CGN/NAT444 processing functions
network to simplify capacity management and the engineering of flows. within a common network location to simplify capacity management and
DS-Lite however requires configuration of the CPE and the the engineering of flows. This case may be evident in a later
implementation of the AFTR. transition stages when an operator chooses to optimize their network
and IPv6-only operation is feasible.
5.5.1. DS-Lite Deployment Considerations 5.5.1. DS-Lite Deployment Considerations
The same deployment considerations associated with Native IPv6 The same deployment considerations associated with Native IPv6
deployments apply to DS-LIte. IPv4 will now be dependent on IPv6 deployments apply to DS-LIte and NAT64. IPv4 will now be dependent
service quality, so the IPv6 network and service must be running well on IPv6 service quality, so the IPv6 network and services must be
to ensure a quality experience for the end customer. Tools and running well to ensure a quality experience for the end customer.
processes will be needed to manage the encapsulated IPv4 service. If Tools and processes will be needed to manage the encapsulated IPv4
flow analysis is required for IPv4 traffic, this should be enabled at service. If flow analysis is required for IPv4 traffic, this should
a point beyond the AFTR (after de-capsulation). be enabled at a point beyond the AFTR (after de-capsulation).
+---------+ IPv4 Encapsulation +------------+ +---------+ IPv4 Encapsulation +------------+
| + - - - - - - - - - - -+ | | + - - - - - - - - - - -+ |
| AFTR +----------------------+ AFTR +--------- | AFTR +----------------------+ AFTR +---------
| | IPv4 Packet | | IPv4 Packet | | IPv4 Packet | | IPv4 Packet
| Client +----------------------+ +--------- | Client +----------------------+ +---------
| + - - - - - - - - - - -+ | ^ | + - - - - - - - - - - -+ | ^
+---------+ ^ +------------+ | +---------+ ^ +------------+ |
| | | |
| | | |
skipping to change at page 22, line 35 skipping to change at page 23, line 35
Figure 9: DS-Lite Tools and Flow Analysis Figure 9: DS-Lite Tools and Flow Analysis
DS-Lite also requires client support. The operator must clearly DS-Lite also requires client support. The operator must clearly
articulate to vendors which technologies will be used at which articulate to vendors which technologies will be used at which
points, how they interact with each other at the CPE, and how they points, how they interact with each other at the CPE, and how they
will be provisioned. As an example, an operator may use 6RD in the will be provisioned. As an example, an operator may use 6RD in the
outset of the transition, then move to Native Dual Stack followed by outset of the transition, then move to Native Dual Stack followed by
DS-Lite. DS-Lite.
5.5.2. NAT64 Deployment Considerations
The deployment of NAT64 assumes the network assigns an IPv6 addresses
to an network endpoint which are translated to IPv4 addresses to
provide connectivity to IPv4 Internet services and content.
Experiments such as the one described in [RFC6586] highlight issues
related to IPv6-only deployments due to legacy IPv4 APIs and IPv4
literals. Many of these issues will be resolved by the eventual
removal this undesired legacy behaviour. In the short term,
technology options include the 464xlat [I-D.ietf-v6ops-464xlat] model
which helps managed legacy IPv4 calls. Operational deployment models
and experiences related to NAT64 have been documented in [I-D.chen-
v6ops-nat64-experience].
As the support for IPv6 increased within content and network
endpoints, the more efficient the IPv6-Only model becomes with NAT64.
The NAT64 deployment would see an overall declined in usage as more
traffic is promoted to IPv6 to IPv6 native communication. NAT64 may
play an important part of an operators late stage transition as it
removes the need to support IPv4 on the access network and provides a
solid go-forward networking model.
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 Special thanks to Wes George, Christian Jacquenet and John Brzozowski
review and comments. 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: Jason Weil, Nik Lavorato, guidance on IPv6 deployment considerations: Jason Weil, Gang Chen,
John Cianfarani, Chris Donley, and Tina TSOU. Nik Lavorato, John Cianfarani, Chris Donley, and Tina TSOU.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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.chen-v6ops-nat64-experience]
Chen, G., Cao, Z., Byrne, C., and Q. Niu, "NAT64
Operational Experiences",
draft-chen-v6ops-nat64-experience-01 (work in progress),
March 2012.
[I-D.donley-behave-deterministic-cgn]
Donley, C., Grundemann, C., Sarawat, V., and K.
Sundaresan, "Deterministic Address Mapping to Reduce
Logging in Carrier Grade NAT Deployments",
draft-donley-behave-deterministic-cgn-02 (work in
progress), March 2012.
[I-D.donley-nat444-impacts] [I-D.donley-nat444-impacts]
Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. Donley, C., Howard, L., Colorado, U., and V. Kuarsingh,
Colorado, "Assessing the Impact of Carrier-Grade NAT on "Assessing the Impact of Carrier-Grade NAT on Network
Network Applications", draft-donley-nat444-impacts-03 Applications", draft-donley-nat444-impacts-03 (work in
(work in progress), November 2011. 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 NATs and H. Ashida, "Common requirements for Carrier Grade NATs
(CGNs)", draft-ietf-behave-lsn-requirements-05 (work in (CGNs)", draft-ietf-behave-lsn-requirements-06 (work in
progress), November 2011. progress), May 2012.
[I-D.ietf-v6ops-v4v6tran-framework] [I-D.ietf-softwire-dslite-deployment]
Carpenter, B., Jiang, S., and V. Kuarsingh, "Framework for Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M.
IP Version Transition Scenarios", Boucadair, "Deployment Considerations for Dual-Stack
draft-ietf-v6ops-v4v6tran-framework-02 (work in progress), Lite", draft-ietf-softwire-dslite-deployment-03 (work in
July 2011. progress), March 2012.
[I-D.ietf-v6ops-464xlat]
Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
draft-ietf-v6ops-464xlat-03 (work in progress), May 2012.
[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-05
(work in progress), September 2011. (work in progress), February 2012.
[I-D.weil-shared-transition-space-request] [I-D.sivakumar-behave-nat-logging]
Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and Sivakumar, S., "Logging of NAT Events",
M. Azinger, "IANA Reserved IPv4 Prefix for Shared Address draft-sivakumar-behave-nat-logging-03 (work in progress),
Space", draft-weil-shared-transition-space-request-14 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.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3769] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
Delegation", RFC 3769, June 2004.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380,
February 2006. February 2006.
[RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
Co-existence Security Considerations", RFC 4942, Co-existence Security Considerations", RFC 4942,
September 2007. September 2007.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification", Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010. RFC 5969, August 2010.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092, Residential IPv6 Internet Service", RFC 6092,
January 2011. January 2011.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
skipping to change at page 25, line 15 skipping to change at page 27, line 5
Roberts, "Issues with IP Address Sharing", RFC 6269, Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011. June 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4 Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011. Exhaustion", RFC 6333, August 2011.
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
RFC 6343, August 2011. RFC 6343, August 2011.
[RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
Network", RFC 6586, April 2012.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
Space", BCP 153, RFC 6598, April 2012.
Authors' Addresses Authors' Addresses
Victor Kuarsingh (editor) Victor Kuarsingh (editor)
Rogers Communications Rogers Communications
8200 Dixie Road 8200 Dixie Road
Brampton, Ontario L6T 0C1 Brampton, Ontario L6T 0C1
Canada Canada
Email: victor.kuarsingh@gmail.com Email: victor.kuarsingh@gmail.com
URI: http://www.rogers.com URI: http://www.rogers.com
 End of changes. 113 change blocks. 
356 lines changed or deleted 438 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/