draft-ietf-v6ops-wireline-incremental-ipv6-05.txt   draft-ietf-v6ops-wireline-incremental-ipv6-06.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: January 12, 2013 Time Warner Cable Expires: March 14, 2013 Time Warner Cable
July 11, 2012 September 10, 2012
Wireline Incremental IPv6 Wireline Incremental IPv6
draft-ietf-v6ops-wireline-incremental-ipv6-05 draft-ietf-v6ops-wireline-incremental-ipv6-06
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 stagnant 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-
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 January 12, 2013. This Internet-Draft will expire on March 14, 2013.
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 26 skipping to change at page 3, line 26
4. IPv6 Transition Technology Analysis . . . . . . . . . . . . . 9 4. IPv6 Transition Technology Analysis . . . . . . . . . . . . . 9
4.1. Automatic Tunneling using 6to4 and Teredo . . . . . . . . 9 4.1. Automatic Tunneling using 6to4 and Teredo . . . . . . . . 9
4.2. Carrier Grade NAT (NAT444) . . . . . . . . . . . . . . . . 10 4.2. Carrier Grade NAT (NAT444) . . . . . . . . . . . . . . . . 10
4.3. 6RD . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. 6RD . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 11 4.4. Native Dual Stack . . . . . . . . . . . . . . . . . . . . 11
4.5. DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5. DS-Lite . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. IPv6 Transition Phases . . . . . . . . . . . . . . . . . . . . 12 5. IPv6 Transition Phases . . . . . . . . . . . . . . . . . . . . 12
5.1. Phase 0 - Foundation . . . . . . . . . . . . . . . . . . . 13 5.1. Phase 0 - Foundation . . . . . . . . . . . . . . . . . . . 13
5.1.1. Phase 0 - Foundation: Training . . . . . . . . . . . . 13 5.1.1. Phase 0 - Foundation: Training . . . . . . . . . . . . 13
5.1.2. Phase 0 - Foundation: Routing . . . . . . . . . . . . 13 5.1.2. Phase 0 - Foundation: System Capabilities . . . . . . 14
5.1.3. Phase 0 - Foundation: Network Policy and Security . . 14 5.1.3. Phase 0 - Foundation: Routing . . . . . . . . . . . . 14
5.1.4. Phase 0 - Foundation: Transition Architecture . . . . 14 5.1.4. Phase 0 - Foundation: Network Policy and Security . . 14
5.1.5. Phase 0- Foundation: Tools and Management . . . . . . 15 5.1.5. Phase 0 - Foundation: Transition Architecture . . . . 14
5.1.6. Phase 0- Foundation: Tools and Management . . . . . . 15
5.2. Phase 1 - Tunneled IPv6 . . . . . . . . . . . . . . . . . 15 5.2. Phase 1 - Tunneled IPv6 . . . . . . . . . . . . . . . . . 15
5.2.1. 6RD Deployment Considerations . . . . . . . . . . . . 16 5.2.1. 6RD Deployment Considerations . . . . . . . . . . . . 17
5.3. Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 18 5.3. Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 19
5.3.1. Native Dual Stack Deployment Considerations . . . . . 19 5.3.1. Native Dual Stack Deployment Considerations . . . . . 19
5.4. Intermediate Phase for CGN . . . . . . . . . . . . . . . . 19 5.4. Intermediate Phase for CGN . . . . . . . . . . . . . . . . 20
5.4.1. CGN Deployment Considerations . . . . . . . . . . . . 21 5.4.1. CGN Deployment Considerations . . . . . . . . . . . . 21
5.5. Phase 3 - IPv6-Only . . . . . . . . . . . . . . . . . . . 22 5.5. Phase 3 - IPv6-Only . . . . . . . . . . . . . . . . . . . 22
5.5.1. DS-Lite Deployment Considerations . . . . . . . . . . 23 5.5.1. DS-Lite . . . . . . . . . . . . . . . . . . . . . . . 23
5.5.2. NAT64 Deployment Considerations . . . . . . . . . . . 24 5.5.2. DS-Lite Deployment Considerations . . . . . . . . . . 23
5.5.3. NAT64 Deployment Considerations . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . . 25 9.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
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. This document identifies which consumer devices and applications. This document identifies which
technologies can be used incrementally to transition from IPv4-only technologies can be used incrementally to transition from IPv4-only
to an IPv6 dominant 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
skipping to change at page 4, line 35 skipping to change at page 4, line 35
of IPv4 connectivity continuance. The focal transition technologies of IPv4 connectivity continuance. The focal transition technologies
include 6RD [RFC5969], DS-Lite [RFC6333], NAT64 [RFC6146] and Dual include 6RD [RFC5969], DS-Lite [RFC6333], NAT64 [RFC6146] and Dual
Stack operation which may also include a CGN/NAT444 deployment. Stack operation which may also include a CGN/NAT444 deployment.
Focus on these technologies is based on their inclusion in many off- Focus on these technologies is based on their inclusion in many off-
the-shelf CPEs and availability in commercially available equipment. the-shelf CPEs and availability in commercially available 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 the progress
deploying IPv6 in deploying IPv6
- The operator has a legacy IPv4 subscriber base that will - The operator has a legacy IPv4 subscriber base that will
continue to exist for a period of time continue 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 subscribers by minimizing the number of the existing and new subscribers
- The operator may also want to minimize 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 subscribers flows (overall preference for Native IP flows) set of subscribers 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 able 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 that minimize the need to tunnel, translate or mediate technologies that minimize the need to tunnel, translate or mediate
flows to help optimize traffic flow and lower the cost impacts of flows to help optimize traffic flow and lower the cost impacts of
transition technologies. Transition technology selections should be transition technologies. Transition technology selections should be
skipping to change at page 5, line 22 skipping to change at page 5, line 24
the use of transition technologies are based on an effort to enable the use of transition technologies are based on an effort to enable
IPv6 at the base layer as soon as possible. Some operators may want IPv6 at the base layer as soon as possible. Some operators may want
to promote IPv6 early on in the deployment and have IPv6 traffic to promote IPv6 early on in the deployment and have IPv6 traffic
perform optimally from the outset. This desire would need to be perform optimally from the outset. This desire would need to be
weighed against the cost and support impacts of such a choice and the weighed against the cost and support impacts of such a choice and the
quality of experience offered to subscribers. quality of experience offered to subscribers.
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 want to consider a phased approach when adding IPv6 to
an existing subscriber base. A phased approach allows the operator an existing subscriber base. A phased approach allows the operator
to add in IPv6 while not ignoring legacy IPv4 connection to add in IPv6 while not ignoring legacy IPv4 connection
requirements. Some of the main challenges the operator will face requirements. Some of the main challenges the operator will face
include: include:
- IPv4 exhaustion may occur long before all traffic is able to be - 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 quite new and has had short run time in large production is quite new and has had short run time in large production
skipping to change at page 6, line 49 skipping to change at page 6, line 51
likely affect many if not most operators at some point, increasing likely affect many if not most operators at some point, increasing
the benefits of IPv6. IPv4 address exhaustion is a consideration the benefits of IPv6. IPv4 address exhaustion is a consideration
when selecting technologies which rely on IPv4 to supply IPv6 when selecting technologies which rely on IPv4 to supply IPv6
services, such as 6RD. Additionally, if native Dual Stack is services, such as 6RD. Additionally, if native Dual Stack is
considered by the operator, challenges related to IPv4 address considered by the operator, challenges related to IPv4 address
exhaustion remain a concern. exhaustion remain a concern.
Some operators may be able to reclaim small amounts IPv4 addresses Some operators may be able to reclaim small amounts IPv4 addresses
through addressing efficiencies in the network, although this will through addressing efficiencies in the network, although this will
have little lasting benefits to the network and not meet longer term have little lasting benefits to the network and not meet longer term
connectivity needs. The lack of new global IPv4 address allocations connectivity needs. Secondary markets for IPv4 addresses have also
will therefore force operators to support some form of IPv4 address begun to arise, but it's not well understood how this will complement
sharing and may impact technological options for transition once the overall demand for Internet growth. Address transfers will also be
operator runs out of new IPv4 addresses for assignment. subject to market prices and transfer rules governed by the Regional
Registries.
The lack of new global IPv4 address allocations will therefore force
operators to support some form of IPv4 address sharing and may impact
technological options for transition once the operator runs out of
new IPv4 addresses for assignment.
3.3. IPv6 Introduction and Operational Maturity 3.3. IPv6 Introduction and Operational Maturity
The introduction of IPv6 will require new operational practices. The The introduction of IPv6 will require new operational practices. The
IPv4 environment we have today was built over many years and matured IPv4 environment we have today was built over many years and matured
by experience. Although many of these experiences are transferable by experience. Although many of these experiences are transferable
from IPv4 to IPv6, new experience and practices specific to IPv6 will from IPv4 to IPv6, new experience and practices 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
skipping to change at page 8, line 26 skipping to change at page 8, line 32
With any Dual Stack service - whether Native, 6RD-based, DS-Lite, With any Dual Stack service - whether Native, 6RD-based, DS-Lite,
NAT64 or otherwise - two address families may need to be managed NAT64 or otherwise - two address families may need to be managed
simultaneously to help provide for the full Internet experience. simultaneously to help provide for the full Internet experience.
This would indicate that IPv6 management is not just a simple add in, This would indicate that IPv6 management is not just a simple add in,
but needs to be well integrated into the service management 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 that These issues may be of consideration when selecting technologies that
require IPv6 as the base protocol to delivery IPv4 connectivity. require IPv6 as the base protocol to deliver IPv4 connectivity.
Instability on the IPv6 service in such a case would impact IPv4 Instability on the IPv6 service in such a case would impact IPv4
services. services.
3.5. Sub-Optimal Operation of Transition Technologies 3.5. Sub-Optimal Operation of Transition Technologies
Native delivery of IPv4 and IPv6 provides a solid foundation for Native delivery of IPv4 and IPv6 provides a solid foundation for
delivery of Internet services to subscribers since native IP paths delivery of Internet services to subscribers since native IP paths
are well understood and networks are often optimized to send such are well understood and networks are often optimized to send such
traffic efficiently. Transition technologies however, may alter the traffic efficiently. Transition technologies however, may alter the
normal path of traffic or reduce the path MTU, removing many network normal path of traffic or reduce the path MTU, removing many network
skipping to change at page 9, line 22 skipping to change at page 9, line 29
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. The IPv6-only IPv6-only operation in all or much of the network. The IPv6-only
operation may be complemented by technologies such as NAT64 for long- operation may be complemented by technologies such as NAT64 for long-
tail IPv4 content reach. This longer term view may be distant to tail IPv4 content reach. This longer term view may be distant to
some, but should be considered when planning out networks, addressing some, but should be considered when planning out networks, addressing
and services. The needs and costs of maintaining two IP stacks will and services. The needs and costs of maintaining two IP stacks will
eventually become burdensome and simplification will be desirable. eventually become burdensome and simplification will be desirable.
The operators should plan for this state and not make IPv6 inherently The operators should plan for this state and not make IPv6 inherently
dependent on IPv4 as this would unnecessarily constrain the network. dependent on IPv4 as this would unnecessarily constrain the network.
Other design considerations and guidelines for running an IPv6
network should also be considered by the operator. Guidance on
designing an IPv6 network can be found in
[draft-matthews-v6ops-design-guidelines] and
[draft-ietf-v6ops-icp-guidance].
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 run out. This draft provides a brief description deployment and IPv4 run out. 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, wireless, residential services and less focused on commercial access, wireless,
or 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
skipping to change at page 9, line 38 skipping to change at page 10, line 4
residential services and less focused on commercial access, wireless, residential services and less focused on commercial access, wireless,
or 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 Tunneling using 6to4 and Teredo 4.1. Automatic Tunneling 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 subscriber operating systems and CPE hardware. mechanisms exist on subscriber 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
by many Internet hosts. by many Internet hosts.
Documents such as [RFC6343] have been written to help operators Documents such as [RFC6343] have been written to help operators
understand observed problems 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 its 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 addresses are used within CGN/NAT444 zones. Many off-the- RFC1918 addresses are used within CGN/NAT444 zones. Many off-the-
shelf CPEs and operating systems may turn on 6to4 without a valid shelf CPEs and operating systems may turn on 6to4 without a valid
return path to the originating (local) host. This particular use return path to the originating (local) host. This particular use
skipping to change at page 10, line 31 skipping to change at page 10, line 44
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][I-D.donley-nat444-impacts], but may be necessary service [RFC6269][I-D.donley-nat444-impacts], but may be necessary
depending on how an operator has chosen to deal with IPv6 transition depending on how an operator has chosen to deal with IPv6 transition
and legacy IPv4 connectivity requirements. and legacy IPv4 connectivity requirements.
In a network where IPv4 address availability is low, CGN/NAT444, may In a network where IPv4 address availability is low, CGN/NAT444, may
provide continued access to IPv4 endpoints. Some of the advantages provide continued access to IPv4 endpoints. Some of the advantages
of using CGN/NAT444 include the similarities in provisioning and of using CGN/NAT444 include the similarities in provisioning and
activation models. IPv4 hosts in a CGN/NAT444 deployment will likely activation models. IPv4 hosts in a CGN/NAT444 deployment will likely
inherent the same addressing and management procedures as legacy inherit the same addressing and management procedures as legacy IPv4,
IPv4, globally addressed hosts (i.e. DHCPv6, DNSv4, TFTP, TR-069 globally addressed hosts (i.e. DHCPv4, DNSv4, TFTP, TR-069 etc).
etc).
4.3. 6RD 4.3. 6RD
6RD [RFC5969] provides a way of offering IPv6 connectivity to 6RD [RFC5969] provides a way of offering IPv6 connectivity to
subscriber endpoints when native IPv6 addressing on the access subscriber endpoints when native IPv6 addressing on the access
network is not yet possible. 6RD provides tunneled connectivity for network is not yet possible. 6RD provides tunneled connectivity for
IPv6 over the existing IPv4 path. As the access edge is upgraded and IPv6 over the existing IPv4 path. As the access edge is upgraded and
subscriber premise equipment is replaced, 6RD can be replace by subscriber premise equipment is replaced, 6RD can be replace by
native IPv6 connectivity. 6RD can be delivered over top a CGN/NAT444 native IPv6 connectivity. 6RD can be delivered over top a CGN/NAT444
deployment, but this would cause all traffic to be subject to some deployment, but this would cause all traffic to be subject to some
skipping to change at page 11, line 43 skipping to change at page 12, line 7
as well. The upgrade of such systems may often be non-trivial and as well. The upgrade of such systems may often be non-trivial and
costly. costly.
4.5. DS-Lite 4.5. DS-Lite
Dual-Stack Lite (DS-Lite, [RFC6333]) is based on a native IPv6 Dual-Stack Lite (DS-Lite, [RFC6333]) is based on a native IPv6
connection model where IPv4 services are supported. DS-Lite provides connection model where IPv4 services are supported. DS-Lite provides
tunneled connectivity for IPv4 over the IPv6 path between the tunneled connectivity for IPv4 over the IPv6 path between the
subscriber's network device and a provider managed gateway (AFTR). subscriber's network device and a provider managed gateway (AFTR).
DS-Lite can only be used where there is native IPv6 connection DS-Lite can only be used where there is a native IPv6 connection
between the AFTR and the CPE. This may mean that the technology's between the AFTR and the CPE. This may mean that the technology's
use may not be viable during early transition if the core or access use may not be viable during early transition if the core or access
network lacks IPv6 support. During the early transition period, a network lacks IPv6 support. During the early transition period, a
significant amount of content and services may by IPv4-only. significant amount of content and services may by IPv4-only.
Operators may be sensitive to this and may not want the newer IPv6 Operators may be sensitive to this and may not want the newer IPv6
path to be the only bridge to IPv4 at that time given the potential path to be the only bridge to IPv4 at that time given the potential
impact. The operator may also want to make sure that most of its impact. The operator may also want to make sure that most of its
internal services and a significant about of external content is internal services and a significant amount of external content is
available over IPv6 before deploying DS-Lite. The availability of available over IPv6 before deploying DS-Lite. The availability of
services on IPv6 would help lower the demand on the AFTRs. services on IPv6 would help lower the demand on 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 even DS-Lite can facilitate continued support of legacy IPv4 services even
after IPv4 address run out. There are some functional considerations after IPv4 address run out. There are some functional considerations
to take into account with DS-Lite, such as those described in to take into account with DS-Lite, such as those described in
[I-D.donley-nat444-impacts]and in [I-D.ietf-softwire-dslite- [I-D.donley-nat444-impacts]and in [I-D.ietf-softwire-dslite-
deployment]. deployment].
DS-Lite requires client support on the CPE to function. The ability DS-Lite requires client support on the CPE to function. The ability
to utilize DS-Lite will be dependent on the operator providing DS- to utilize DS-Lite will be dependent on the operator providing DS-
Lite capable CPEs or retail availability of the supported client for Lite capable CPEs or retail availability of the supported client for
subscriber-acquired endpoints. subscriber-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 tunneling. NAT64 clients and hosts to IPv4 servers without any tunneling. NAT64
requires that the host and home network supports IPv6-only modes of requires that the host and home network support IPv6-only modes of
operation. Home networks do not commonly contain equipment that is operation. Home networks do not commonly contain equipment that is
100% IPv6-capable. It is also not anticipated that common home 100% IPv6-capable. It is also not anticipated that common home
networks will be ready for IPv6-only operation for a number of years. networks will be ready for IPv6-only operation for a number of years.
However, IPv6-only networking can be deployed by early adopters or However, IPv6-only networking can be deployed by early adopters or
highly controlled networks [RFC6586]. highly controlled networks [RFC6586].
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. There are incentives equipment is replaced by IPv6 capable versions. There are incentives
for operators to move to IPv6-only operation, when feasible, which for operators to move to IPv6-only operation, when feasible, which
includes the simplicity of a single stack access network. includes the simplicity of a single stack access network.
skipping to change at page 12, line 48 skipping to change at page 13, line 13
of steps, but are considered a guideline which should be analyzed by of steps, but are considered a guideline which should be analyzed by
operators 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, (residential/corporate, fixed/mobile), their business networks, (residential/corporate, fixed/mobile), their business
development perspectives (which may affect the pace of migration development perspectives (which may affect the pace of migration
towards full IPv6), or a combination thereof. towards full IPv6), or a combination thereof.
The phases are based on the 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 volumes over time. As traffic volumes of IPv6 increase, IPv4 traffic volumes
will decline (in percentage relative to IPv4), until IPv6 is the will decline (in percentage relative to IPv6), until IPv6 is the
dominant address family used. Operators may want to keep the traffic dominant address family used. Operators may want to keep the traffic
flow for the dominant traffic class (IPv4 vs. IPv6) native to help flow for the dominant traffic class (IPv4 vs. IPv6) native to help
manage costs related to transition technologies. The cost of using manage costs related to transition technologies. The cost of using
multiple technologies in succession to optimize each stage of the multiple technologies in succession to optimize each stage of the
transition should also be compared against the cost of changing and transition should also be compared against the cost of changing and
upgrading subscriber connections. upgrading subscriber 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].
skipping to change at page 13, line 41 skipping to change at page 14, line 5
RFCs. Operations personnel who support the network and other systems RFCs. Operations personnel 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.
Subscriber support staff would require much more basic but large Subscriber support staff would require much more basic but large
scale training since many organizations have massive call centers to scale training since many organizations have massive call centers to
support the subscriber base. Tailored training will also be required support the subscriber base. Tailored training will also be required
for marketing and sales staff to help them understand IPv6 and build for marketing and sales staff to help them understand IPv6 and build
it into the product development and sales process. it into the product development and sales process.
5.1.2. Phase 0 - Foundation: Routing 5.1.2. Phase 0 - Foundation: System Capabilities
An important component with any IPv6 network architecture and
implementation is the assessment of the hardware and operating
capabilities of the deployed equipment (and software). The
assessment needs to be conducted irrespective of how the operator
plans to transition their network. The capabilities of the install
base will however impact what technologies and modes of operation may
be supported and therefore what technologies can be considered for
the transition. If some systems do not meet the needs of the
operator's IPv6 deployment and/or transition plan, the operator may
need to plan for replacement and/or upgrade.
5.1.3. 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 several 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.
One such change is the notion of a delegated prefix, which deviates One such change is the notion of a delegated prefix, which deviates
from the common single address phenomenon in IPv4-only deployments. from the common single address phenomenon in IPv4-only deployments.
Deploying prefixes per CPE can load the routing tables and require a Deploying prefixes per CPE can load the routing tables and require a
routing protocol or route gleaning to manage connectivity to the routing protocol or route gleaning to manage connectivity to the
subscriber's network. Delegating prefixes can be of specific subscriber's network. Delegating prefixes can be of specific
importance in access network environments where downstream subscriber importance in access network environments where downstream
often move between access nodes, raising the concern of frequent subscribers often move between access nodes, raising the concern of
renumbering and/or managing movement of routed prefixes within the frequent renumbering and/or managing movement of routed prefixes
network (common in cable based networks). within the network (common in cable based networks).
5.1.3. Phase 0 - Foundation: Network Policy and Security 5.1.4. 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 such addressed when delivering IPv6 services. Other IETF documents such
as [RFC4942], [RFC6092], and [RFC6169] are excellent resources. as [RFC4942], [RFC6092], and [RFC6169] are excellent resources.
5.1.4. Phase 0 - Foundation: Transition Architecture 5.1.5. Phase 0 - Foundation: Transition Architecture
The operators should plan out their transition architecture in The operators should plan out their transition architecture in
advance (with room for flexibility) to help optimize how they will advance (with room for flexibility) to help optimize how they will
build out and scale their networks. Should the operator consider build out and scale their networks. Should the operator consider
multiple technologies like CGN/NAT444, DS-Lite, NAT64 and 6RD, they multiple technologies like CGN/NAT444, DS-Lite, NAT64 and 6RD, they
may want to plan out where network resident equipment may be located may want to plan out where network resident equipment may be located
and potentially choose locations which can be used for all functional and potentially choose locations which can be used for all functional
roles (i.e. Placement of NAT44 translator, AFTR, NAT64 gateway and roles (i.e. Placement of NAT44 translator, AFTR, NAT64 gateway and
6RD relays). Although these functions are not inherently connected, 6RD relays). Although these functions are not inherently connected,
additional management, diagnostic and monitoring functions can be additional management, diagnostic and monitoring functions can be
deployed along side the transition hardware without the need to deployed along side the transition hardware without the need to
distribute these to an excessive or divergent number of locations. distribute these to an excessive or divergent number of locations.
This approach may also prove beneficial if traffic patterns change This approach may also prove beneficial if traffic patterns change
rapidly in the future as the operators may need to evolve their rapidly in the future as the operators may need to evolve their
transition infrastructure faster than originally anticipated. Once transition infrastructure faster than originally anticipated. One
such example may be the movement from a CGN/NAT44 model (dual stack) such example may be the movement from a CGN/NAT44 model (dual stack)
to DS-Lite. Since both traffic sets require a translation function to DS-Lite. Since both traffic sets require a translation function
(NAT44), synchronized pool management, routing and management system (NAT44), synchronized pool management, routing and management system
positioning can allow rapid movement (notwithstanding the positioning can allow rapid movement (notwithstanding the
technological means to re-provision the subscriber). technological means to re-provision the subscriber).
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 subscriber premise equipment. important for both network gear and subscriber 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. As traffic moves to IPv6, target needs of an IPv6-only deployment. As traffic moves to IPv6,
the benefits of only a single stack on the access network may the benefits of only a single stack on the access network may
eventually justify the removal of IPv4 for simplicity. Planning for eventually justify the removal of IPv4 for simplicity. Planning for
this eventual model, no matter how far off this may be, will help the this eventual model, no matter how far off this may be, will help the
operator embrace this end state when needed. operator embrace this end state when needed.
5.1.5. Phase 0- Foundation: Tools and Management 5.1.6. Phase 0- Foundation: Tools and Management
The operator should thoroughly analyze all provisioning and The operator should thoroughly analyze all provisioning and
management 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 (Prefix Delegation) and the ability to detect an assigned IPv6 prefix (Prefix Delegation) and the ability to detect
either or both address families when determining if a subscriber has either or both address families when determining if a subscriber has
full Internet service. full Internet 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 as both address families aggregated to include both the IPv4 and IPv6 as both address families
skipping to change at page 19, line 44 skipping to change at page 20, line 26
Operators need to keep track of both the dynamically assigned IPv4 Operators need to keep track of both the dynamically assigned IPv4
address along with the IPv6 address and prefix. Any additional address along with the IPv6 address and prefix. Any additional
dynamic elements, such as auto-generated host names, need to be dynamic elements, such as auto-generated host names, need to be
considered and planned for. considered and planned for.
5.4. Intermediate Phase for CGN 5.4. Intermediate Phase for CGN
Acquiring more IPv4 addresses is already challenging, if not Acquiring more IPv4 addresses is already challenging, if not
impossible; therefore address sharing may be required on the IPv4 impossible; therefore address sharing may be required on the IPv4
path. The operator may have a preference to move directly to a path of a Dual Stack deployment. The operator may have a preference
transition technology such as DS-Lite [RFC6333] or may choose CGN/ to move directly to a transition technology such as DS-Lite [RFC6333]
NAT444 to facilitate IPv4 connections. CGN/NAT444 requires IPv4 or may use Dual Stack with CGN/NAT444 to facilitate IPv4 connections.
addressing between the subscriber premise equipment and the
operator's translator which may be facilitated by shared address CGN/NAT444 requires IPv4 addressing between the subscriber premise
[RFC6598], private address [RFC1918] or other address space. CGN/ equipment and the operator's translator which may be facilitated by
NAT444 should be used cautiously if used simultaneously with 6RD for shared address [RFC6598], private address [RFC1918] or other address
a common set of subscribers. Operators should be aware that if CGN/ space. CGN/NAT444 is only recommended to be used along side IPv6 in
NAT444 is used in such manner, subscriber all traffic must traverse a Dual Stack deployment and not on it's own. Figure 5 provides a
some type of operator service node (relay and translator). Also, comparative view of a traditional IPv4 path versus one which uses
care should be taken so as not to run 6RD through a DS-Lite tunnel or CGN/NAT444.
vice versa.
+--------+ ----- +--------+ -----
| | / \ | | / \
IPv4 Flow | CGN | | | IPv4 Flow | CGN | | |
- - -> + + < -> | | - - -> + + < -> | |
+---------+ / | | | | +---------+ / | | | |
| CPE | <- - - / +--------+ | IPv4 | | CPE | <- - - / +--------+ | IPv4 |
|---------+ | Net | |---------+ | Net |
| | | |
+---------+ IPv4 Flow | | +---------+ IPv4 Flow | |
skipping to change at page 21, line 18 skipping to change at page 21, line 45
operators use 'squat space', as it may pose additional challenges operators use 'squat space', as it may pose additional challenges
with filtering and policy control [RFC6598]. with filtering and policy control [RFC6598].
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 capabilities should cases. An operator who needs to deploy CGN capabilities should
consider the impacts of the function to the network. CGN is often consider the impacts of the function to the network. CGN is often
deployed in addition to running IPv4 services and should not deployed in addition to running IPv4 services and should not
negatively impact the already working Native IPv4 service. CGNs will negatively impact the already working Native IPv4 service. CGNs will
be needed at low scale at first and grown to meet the demands based be needed at low scale at first and grow to meet the demands based on
on traffic and connection dynamics of the subscriber, content and traffic and connection dynamics of the subscriber, content and
network peers. 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 limiting the deploy based and scaling it based on actual the system limiting the deployed base and scaling it based on actual
traffic demand. The operator should use a deployment model and traffic demand. The operator should use a deployment model and
architecture which allows the system to scale as needed. architecture which allows the system to scale as needed.
+--------+ ----- +--------+ -----
| | / \ | | / \
| CGN | | | | CGN | | |
- - -> + + < -> | | - - -> + + < -> | |
+---------+ / | | | | +---------+ / | | | |
| CPE | <- - - / +--------+ | IPv4 | | CPE | <- - - / +--------+ | IPv4 |
| | ^ | | | | ^ | |
skipping to change at page 22, line 17 skipping to change at page 22, line 43
Since CGN has noticeable impacts on certain applications [I-D.donley- Since CGN has noticeable impacts on certain applications [I-D.donley-
nat444-impacts], operators may deploy CGN only for those subscribers nat444-impacts], operators may deploy CGN only for those subscribers
who may be less affected by CGN (if possible). who may be less affected by CGN (if possible).
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 subscriber endpoints. During this final only IPv6 to all or some subscriber 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 subscriber demand. If depending on the conditions of the network, subscriber demand and
legacy IPv4 connectivity is still demanded (e.g. for older nodes), legacy device requirements. If legacy IPv4 connectivity is still
DS-Lite [RFC6333] may be used to tunnel the traffic. If IPv4 demanded (e.g. for older nodes), DS-Lite [RFC6333] may be used to
connectivity is not required, but access to legacy IPv4 content is, tunnel the traffic. If IPv4 connectivity is not required, but access
then NAT64 [RFC6144][RFC6146] can be used. to legacy IPv4 content is, then NAT64 [RFC6144][RFC6146] can be used.
5.5.1. DS-Lite
DS-Lite allows continued access for the IPv4 subscriber base using DS-Lite allows continued access for the IPv4 subscriber 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 supply subscriber operation also removes the need to directly supply subscriber
endpoints with an IPv4 address, potentially simplifying the endpoints with an IPv4 address, potentially simplifying the
connectivity to the customer (single address family) and supporting connectivity to the customer (single address family) and supporting
IPv6 only addressing to the CPE. IPv6 only addressing 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
skipping to change at page 23, line 12 skipping to change at page 23, line 43
Figure 8: DS-Lite Basic Model Figure 8: DS-Lite Basic Model
If the operator had previously decided to enable a CGN/NAT444 If the operator had previously decided to enable a CGN/NAT444
deployment, it may be able to co-locate the AFTR and CGN/NAT444 deployment, it may be able to co-locate the AFTR and CGN/NAT444
processing functions within a common network location to simplify processing functions within a common network location to simplify
capacity management and the engineering of flows. This case may be capacity management and the engineering of flows. This case may be
evident in a later transition stages when an operator chooses to evident in a later transition stages when an operator chooses to
optimize its network and IPv6-only operation is feasible. optimize its network and IPv6-only operation is feasible.
5.5.1. DS-Lite Deployment Considerations 5.5.2. 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 and NAT64. IPv4 will now be dependent deployments apply to DS-Lite and NAT64. IPv4 will now be dependent
on IPv6 service quality, so the IPv6 network and services must be on IPv6 service quality, so the IPv6 network and services must be
running well to ensure a quality experience for the end subscriber. running well to ensure a quality experience for the end subscriber.
Tools and processes will be needed to manage the encapsulated IPv4 Tools and processes will be needed to manage the encapsulated IPv4
service. If flow analysis is required for IPv4 traffic, this may be service. If flow analysis is required for IPv4 traffic, this may be
enabled at a point beyond the AFTR (after de-capsulation) or DS-Lite enabled at a point beyond the AFTR (after de-capsulation) or DS-Lite
[RFC6333] aware equipment is used to process traffic midstream. [RFC6333] aware equipment is used to process traffic midstream.
skipping to change at page 23, line 38 skipping to change at page 24, line 20
| + - - - - - - - - - - -+ | ^ | + - - - - - - - - - - -+ | ^
+---------+ ^ ^ +------------+ | +---------+ ^ ^ +------------+ |
| | | | | |
| | | | | |
IPv6 IP (Tools/Mgmt) | IPv4 Packet Flow Analysis IPv6 IP (Tools/Mgmt) | IPv4 Packet Flow Analysis
| |
Midstream IPv4 Packet Flow Analysis (Encapsulation Aware) Midstream IPv4 Packet Flow Analysis (Encapsulation Aware)
Figure 9: DS-Lite Tools and Flow Analysis Figure 9: DS-Lite Tools and Flow Analysis
DS-Lite [RFC6333] also requires client support on the subscribers DS-Lite [RFC6333] also requires client support on the subscriber
premise device. The operator must clearly articulate to vendors premises device. The operator must clearly articulate to vendors
which technologies will be used at which points, how they interact which technologies will be used at which points, how they interact
with each other at the CPE, and how they will be provisioned. As an with each other at the CPE, and how they will be provisioned. As an
example, an operator may use 6RD in the outset of the transition, example, an operator may use 6RD in the outset of the transition,
then move to Native Dual Stack followed by DS-Lite. then move to Native Dual Stack followed by DS-Lite.
DS-Lite [RFC6333], as any tunneling option, is subject to a reduced DS-Lite [RFC6333], as any tunneling option, is subject to a reduced
MTU so operators need to plan to manage this environment. Additional MTU so operators need to plan to manage this environment. Additional
considerations for DS-Lite deployments can be found in considerations for DS-Lite deployments can be found in.
[I-D.ietf-softwire-dslite-deployment]. [I-D.ietf-softwire-dslite-deployment]
5.5.2. NAT64 Deployment Considerations 5.5.3. NAT64 Deployment Considerations
The deployment of NAT64 assumes the network assigns an IPv6 address The deployment of NAT64 assumes the network assigns an IPv6 address
to a network endpoint that is translated to an IPv4 address to to a network endpoint that is translated to an IPv4 address to
provide connectivity to IPv4 Internet services and content. provide connectivity to IPv4 Internet services and content.
Experiments such as the one described in [RFC6586] highlight issues Experiments such as the one described in [RFC6586] highlight issues
related to IPv6-only deployments due to legacy IPv4 APIs and IPv4 related to IPv6-only deployments due to legacy IPv4 APIs and IPv4
literals. Many of these issues will be resolved by the eventual literals. Many of these issues will be resolved by the eventual
removal this undesired legacy behavior. Operational deployment removal of this undesired legacy behavior. Operational deployment
models, considerations and experiences related to NAT64 have been models, considerations and experiences related to NAT64 have been
documented in [I-D.chen-v6ops-nat64-experience]. documented in [I-D.chen-v6ops-nat64-experience].
+--------+ ----- +--------+ -----
| | / \ | | / \
IPv6 Flow | NAT64 | | IPv4 | IPv6 Flow | NAT64 | | IPv4 |
-------+ DNS64 +---+ Net | -------+ DNS64 +---+ Net |
+---------+ / | | \ / +---------+ / | | \ /
| | / +--------+ ----- | | / +--------+ -----
| IPv6 +------- ----- | IPv6 +------- -----
skipping to change at page 25, line 39 skipping to change at page 26, line 27
[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] [I-D.chen-v6ops-nat64-experience]
Chen, G., Cao, Z., Byrne, C., Xie, C., and D. Binet, Chen, G., Cao, Z., Byrne, C., Xie, C., and D. Binet,
"NAT64 Operational Experiences", "NAT64 Operational Experiences",
draft-chen-v6ops-nat64-experience-02 (work in progress), draft-chen-v6ops-nat64-experience-03 (work in progress),
July 2012. July 2012.
[I-D.donley-behave-deterministic-cgn] [I-D.donley-behave-deterministic-cgn]
Donley, C., Grundemann, C., Sarawat, V., and K. Donley, C., Grundemann, C., Sarawat, V., and K.
Sundaresan, "Deterministic Address Mapping to Reduce Sundaresan, "Deterministic Address Mapping to Reduce
Logging in Carrier Grade NAT Deployments", Logging in Carrier Grade NAT Deployments",
draft-donley-behave-deterministic-cgn-03 (work in draft-donley-behave-deterministic-cgn-04 (work in
progress), June 2012. progress), June 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., Kuarsingh, V., Berg, J., and U.
Colorado, "Assessing the Impact of Carrier-Grade NAT on Colorado, "Assessing the Impact of Carrier-Grade NAT on
Network Applications", draft-donley-nat444-impacts-04 Network Applications", draft-donley-nat444-impacts-04
(work in progress), May 2012. (work in progress), May 2012.
[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-07 (work in (CGNs)", draft-ietf-behave-lsn-requirements-09 (work in
progress), June 2012. progress), June 2012.
[I-D.ietf-softwire-dslite-deployment] [I-D.ietf-softwire-dslite-deployment]
Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M. Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M.
Boucadair, "Deployment Considerations for Dual-Stack Boucadair, "Deployment Considerations for Dual-Stack
Lite", draft-ietf-softwire-dslite-deployment-03 (work in Lite", draft-ietf-softwire-dslite-deployment-06 (work in
progress), March 2012. progress), March 2012.
[I-D.ietf-v6ops-464xlat] [I-D.ietf-v6ops-464xlat]
Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", Combination of Stateful and Stateless Translation",
draft-ietf-v6ops-464xlat-05 (work in progress), July 2012. draft-ietf-v6ops-464xlat-07 (work in progress), July 2012.
[I-D.ietf-v6ops-6204bis] [I-D.ietf-v6ops-6204bis]
Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", Requirements for IPv6 Customer Edge Routers",
draft-ietf-v6ops-6204bis-09 (work in progress), May 2012. draft-ietf-v6ops-6204bis-10 (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",
 End of changes. 42 change blocks. 
77 lines changed or deleted 107 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/