doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc6782.txt b/doc/rfc/rfc6782.txt
new file mode 100644
index 0000000..0fe573f
--- /dev/null
+++ b/doc/rfc/rfc6782.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                 V. Kuarsingh, Ed.
+Request for Comments: 6782                         Rogers Communications
+Category: Informational                                        L. Howard
+ISSN: 2070-1721                                        Time Warner Cable
+                                                           November 2012
+
+
+                       Wireline Incremental IPv6
+
+Abstract
+
+   Operators worldwide are in various stages of preparing for or
+   deploying IPv6 in their networks.  These operators often face
+   difficult challenges related to IPv6 introduction, along with those
+   related to IPv4 run-out.  Operators will need to meet the
+   simultaneous needs of IPv6 connectivity and continue support for IPv4
+   connectivity for legacy devices with a stagnant supply of IPv4
+   addresses.  The IPv6 transition will take most networks from an IPv4-
+   only environment to an IPv6-dominant environment with long transition
+   periods varying by operator.  This document helps provide a framework
+   for wireline providers who are faced with the challenges of
+   introducing IPv6 along with meeting the legacy needs of IPv4
+   connectivity, utilizing well-defined and commercially available IPv6
+   transition technologies.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6782.
+
+
+
+
+
+
+
+
+
+
+
+Kuarsingh & Howard            Informational                     [Page 1]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kuarsingh & Howard            Informational                     [Page 2]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Operator Assumptions ............................................4
+   3. Reasons and Considerations for a Phased Approach ................5
+      3.1. Relevance of IPv6 and IPv4 .................................6
+      3.2. IPv4 Resource Challenges ...................................6
+      3.3. IPv6 Introduction and Operational Maturity .................7
+      3.4. Service Management .........................................8
+      3.5. Suboptimal Operation of Transition Technologies ............8
+      3.6. Future IPv6 Network ........................................9
+   4. IPv6 Transition Technology Analysis .............................9
+      4.1. Automatic Tunneling Using 6to4 and Teredo .................10
+      4.2. Carrier-Grade NAT (NAT444) ................................10
+      4.3. 6rd .......................................................11
+      4.4. Native Dual Stack .........................................11
+      4.5. DS-Lite ...................................................12
+      4.6. NAT64 .....................................................12
+   5. IPv6 Transition Phases .........................................13
+      5.1. Phase 0 - Foundation ......................................13
+           5.1.1. Phase 0 - Foundation: Training .....................13
+           5.1.2. Phase 0 - Foundation: System Capabilities ..........14
+           5.1.3. Phase 0 - Foundation: Routing ......................14
+           5.1.4. Phase 0 - Foundation: Network Policy and Security ..15
+           5.1.5. Phase 0 - Foundation: Transition Architecture ......15
+           5.1.6. Phase 0 - Foundation: Tools and Management .........16
+      5.2. Phase 1 - Tunneled IPv6 ...................................16
+           5.2.1. 6rd Deployment Considerations ......................17
+      5.3. Phase 2 - Native Dual Stack ...............................19
+           5.3.1. Native Dual Stack Deployment Considerations ........20
+      5.4. Intermediate Phase for CGN ................................20
+           5.4.1. CGN Deployment Considerations ......................22
+      5.5. Phase 3 - IPv6-Only .......................................23
+           5.5.1. DS-Lite ............................................23
+           5.5.2. DS-Lite Deployment Considerations ..................24
+           5.5.3. NAT64 Deployment Considerations ....................25
+   6. Security Considerations ........................................26
+   7. Acknowledgements ...............................................26
+   8. References .....................................................26
+      8.1. Normative References ......................................26
+      8.2. Informative References ....................................26
+
+
+
+
+
+
+
+
+
+
+Kuarsingh & Howard            Informational                     [Page 3]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+1.  Introduction
+
+   This document sets out to help wireline operators in planning their
+   IPv6 deployments while ensuring continued support for IPv6-incapable
+   consumer devices and applications.  This document identifies which
+   technologies can be used incrementally to transition from IPv4-only
+   to an IPv6-dominant environment with support for Dual Stack
+   operation.  The end state or goal for most operators will be
+   IPv6-only, but the path to this final state will depend heavily on
+   the amount of legacy equipment resident in end networks and
+   management of long-tail IPv4-only content.  Although no single plan
+   will work for all operators, options listed herein provide a baseline
+   that can be included in many plans.
+
+   This document is intended for wireline environments that include
+   cable, DSL, and/or fiber as the access method to the end consumer.
+   This document attempts to follow the principles laid out in
+   [RFC6180], which provides guidance on using IPv6 transition
+   mechanisms.  This document will focus on technologies that enable and
+   mature IPv6 within the operator's network, but it will also include a
+   cursory view of IPv4 connectivity continuance.  This document will
+   focus on transition technologies that are readily available in
+   off-the-shelf Customer Premises Equipment (CPE) devices and
+   commercially available network equipment.
+
+2.  Operator Assumptions
+
+   For the purposes of this document, the authors assume the following:
+
+   -  The operator is considering deploying IPv6 or is in the process of
+      deploying IPv6.
+
+   -  The operator has a legacy IPv4 subscriber base that will continue
+      to exist for a period of time.
+
+   -  The operator will want to minimize the level of disruption to 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 set of
+      subscribers' flows (overall preference for native IP flows).
+
+   -  The operator is able to run Dual Stack in its own core network and
+      is able to transition its own services to support IPv6.
+
+
+
+
+
+
+
+Kuarsingh & Howard            Informational                     [Page 4]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   Based on these assumptions, an operator will want to utilize
+   technologies that minimize the need to tunnel, translate, or mediate
+   flows to help optimize traffic flow and lower the cost impacts of
+   transition technologies.  Transition technology selections should be
+   made to mediate the non-dominant IP family flows and allow native
+   routing (IPv4 and/or IPv6) to forward the dominant traffic whenever
+   possible.  This allows the operator to minimize the cost of IPv6
+   transition technologies by minimizing the transition technology
+   deployment size.
+
+   An operator may also choose to prefer more IPv6-focused models where
+   the use of transition technologies is based on an effort to enable
+   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
+   perform optimally from the outset.  This desire would need to be
+   weighed against the cost and support impacts of such a choice and the
+   quality of experience offered to subscribers.
+
+3.  Reasons and Considerations for a Phased Approach
+
+   When faced with the challenges described in the introduction,
+   operators may want to consider a phased approach when adding IPv6 to
+   an existing subscriber base.  A phased approach allows the operator
+   to add in IPv6 while not ignoring legacy IPv4 connection
+   requirements.  Some of the main challenges the operator will face
+   include the following:
+
+   -  IPv4 exhaustion may occur long before all traffic is able to be
+      delivered over IPv6, necessitating IPv4 address sharing.
+
+   -  IPv6 will pose operational challenges, since some of the software
+      is quite new and has had short run time in large production
+      environments and organizations are also not acclimatized to
+      supporting IPv6 as a service.
+
+   -  Connectivity modes will move from IPv4-only to Dual Stack in the
+      home, changing functional behaviors in the consumer network and
+      increasing support requirements for the operator.
+
+   -  Although IPv6 support on CPEs is a newer phenomenon, there is a
+      strong push by operators and the industry as a whole to enable
+      IPv6 on devices.  As demand grows, IPv6 enablement will no longer
+      be optional but will be necessary on CPEs.  Documents like
+      [RFC6540] provide useful tools in the short term to help vendors
+      and implementors understand what "IPv6 support" means.
+
+
+
+
+
+
+Kuarsingh & Howard            Informational                     [Page 5]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   These challenges will occur over a period of time, which means that
+   the operator's plans need to address the ever-changing requirements
+   of the network and subscriber demand.  Although phases will be
+   presented in this document, not all operators may need to enable each
+   discrete phase.  It is possible that characteristics in individual
+   networks may allow certain operators to skip or jump to various
+   phases.
+
+3.1.  Relevance of IPv6 and IPv4
+
+   The delivery of high-quality unencumbered Internet service should be
+   the primary goal for operators.  With the imminent exhaustion of
+   IPv4, IPv6 will offer the highest quality of experience in the long
+   term.  Even though the operator may be focused on IPv6 delivery, it
+   should be aware that both IPv4 and IPv6 will play a role in the
+   Internet experience during transition.  The Internet is made of many
+   interconnecting systems, networks, hardware, software, and content
+   sources -- all of which will support IPv6 at different rates.
+
+   Many subscribers use older operating systems and hardware that
+   support IPv4-only operation.  Internet subscribers don't buy IPv4 or
+   IPv6 connections; they buy Internet connections, which demand the
+   need to support both IPv4 and IPv6 for as long as the subscriber's
+   home network demands such support.  The operator may be able to
+   leverage one or the other protocol to help bridge connectivity on the
+   operator's network, but the home network will likely demand both IPv4
+   and IPv6 for some time.
+
+3.2.  IPv4 Resource Challenges
+
+   Since connectivity to IPv4-only endpoints and/or content will remain
+   common, IPv4 resource challenges are of key concern to operators.
+   The lack of new IPv4 addresses for additional devices means that
+   meeting the growth in demand of IPv4 connections in some networks
+   will require address sharing.
+
+   Networks are growing at different rates, including those in emerging
+   markets and established networks based on the proliferation of
+   Internet-based services and devices.  IPv4 address constraints will
+   likely affect many, if not most, operators at some point, increasing
+   the benefits of IPv6.  IPv4 address exhaustion is a consideration
+   when selecting technologies that rely on IPv4 to supply IPv6
+   services, such as 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)
+   [RFC5969].  Additionally, if native Dual Stack is considered by the
+   operator, challenges related to IPv4 address exhaustion remain a
+   concern.
+
+
+
+
+
+Kuarsingh & Howard            Informational                     [Page 6]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   Some operators may be able to reclaim small amounts of IPv4 addresses
+   through addressing efficiencies in the network, although this will
+   have few lasting benefits to the network and will not meet longer-
+   term connectivity needs.  Secondary markets for IPv4 addresses have
+   also begun to arise, but it's not well understood how this will
+   complement overall demand for Internet growth.  Address transfers
+   will also be 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
+
+   The introduction of IPv6 will require new operational practices.  The
+   IPv4 environment we have today was built over many years and matured
+   by experience.  Although many of these experiences are transferable
+   from IPv4 to IPv6, new experience and practices specific to IPv6 will
+   be needed.
+
+   Engineering and operational staff will need to develop experience
+   with IPv6.  Inexperience may lead to early IPv6 deployment
+   instability, and operators should consider this when selecting
+   technologies for initial transition.  Operators may not want to
+   subject their mature IPv4 service to a "new IPv6" path initially
+   while it may be going through growing pains.  Dual Stack Lite
+   (DS-Lite) [RFC6333] and NAT64 [RFC6146] are both technologies that
+   require 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
+   refinement within running code.  Deployment experience is required to
+   expose bugs and stabilize software in production environments.  Many
+   supporting systems are also under development and have newly
+   developed IPv6 functionality, including vendor implementations of
+   DHCPv6, management tools, monitoring systems, diagnostic systems, and
+   logging, along with other elements.
+
+   Although the base technological capabilities exist to enable and run
+   IPv6 in most environments, organizational experience is low.  Until
+   such time as each key technical member of an operator's organization
+   can identify IPv6 and can understand its relevance to the IP service
+   offering, how it operates, and how to troubleshoot it, the deployment
+   needs to mature and may be subject to events that impact subscribers.
+   This fact should not incline operators to delay their IPv6 deployment
+
+
+
+
+Kuarsingh & Howard            Informational                     [Page 7]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   but should drive them to deploy IPv6 sooner, to gain much-needed
+   experience before IPv6 is the only viable way to connect new hosts to
+   the network.
+
+   It should also be noted that although many transition technologies
+   may be new, and some code related to access environments may be new,
+   there is a large segment of the networking fabric that has had IPv6
+   available for a long period of time and has had extended exposure in
+   production.  Operators may use this to their advantage by first
+   enabling IPv6 in the core network and then working outward towards
+   the subscriber edge.
+
+3.4.  Service Management
+
+   Services are managed within most networks and are often based on the
+   gleaning and monitoring of IPv4 addresses assigned to endpoints.
+   Operators will need to address such management tools, troubleshooting
+   methods, and storage facilities (such as databases) to deal with not
+   only new address types containing 128-bit IPv6 addresses [RFC2460]
+   but often both IPv4 and IPv6 at the same time.  Examination of
+   address types, and recording delegated prefixes along with single
+   address assignments, will likely require additional development.
+
+   With any Dual Stack service -- whether native, 6rd-based, DS-Lite,
+   NAT64, or some other service -- two address families may need to be
+   managed simultaneously to help provide 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
+   that many systems will be missed, and that IPv6 services will go
+   unmonitored and impairments will go undetected.
+
+   These issues may be worthy of consideration when selecting
+   technologies that require IPv6 as the base protocol to deliver IPv4
+   connectivity.  Instability of the IPv6 service in such a case would
+   impact IPv4 services.
+
+3.5.  Suboptimal Operation of Transition Technologies
+
+   Native delivery of IPv4 and IPv6 provides a solid foundation for
+   delivery of Internet services to subscribers, since native IP paths
+   are well understood and networks are often optimized to send such
+   traffic efficiently.  Transition technologies, however, may alter the
+   normal path of traffic or reduce the path MTU, removing many network
+   efficiencies built for native IP flows.  Tunneling and translation
+   devices may not be located on the most optimal path in line with the
+
+
+
+
+
+Kuarsingh & Howard            Informational                     [Page 8]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   natural traffic flow (based on route computation) and therefore may
+   increase latency.  These paths may also introduce additional points
+   of failure.
+
+   Generally, the operator will want to deliver native IPv6 as soon as
+   possible and utilize transition technologies only when required.
+   Transition technologies may be used to provide continued access to
+   IPv4 via tunneling and/or translation or may be used to deliver IPv6
+   connectivity.  The delivery of Internet or internal services should
+   be considered by the operator, since supplying connections using a
+   transition technology will reduce overall performance for the
+   subscriber.
+
+   When choosing between various transition technologies, operators
+   should consider the benefits and drawbacks of each option.  Some
+   technologies, like Carrier-Grade NAT (CGN)/NAT444, utilize many
+   existing addressing and management practices.  Other options, such as
+   DS-Lite and NAT64, remove the IPv4 addressing requirement to the
+   subscriber premises device but require IPv6 to be operational and
+   well supported.
+
+3.6.  Future IPv6 Network
+
+   An operator should also be aware that longer-term plans may include
+   IPv6-only operation in all or much of the network.  The IPv6-only
+   operation may be complemented by technologies such as NAT64 for long-
+   tail IPv4 content reach.  This longer-term view may be distant to
+   some but should be considered when planning out networks, addressing,
+   and services.  The needs and costs of maintaining two IP stacks will
+   eventually become burdensome, and simplification will be desirable.
+   Operators should plan for this state and not make IPv6 inherently
+   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 [IPv6-DESIGN] and
+   [IPv6-ICP-ASP-GUIDANCE].
+
+4.  IPv6 Transition Technology Analysis
+
+   Operators should understand the main transition technologies for IPv6
+   deployment and IPv4 run-out.  This document provides a brief
+   description of some of the mainstream and commercially available
+   options.  This analysis is focused on the applicability of
+   technologies to deliver residential services and less focused on
+   commercial access, wireless, or infrastructure support.
+
+
+
+
+
+Kuarsingh & Howard            Informational                     [Page 9]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   This document focuses on those technologies that are commercially
+   available and in deployment.
+
+4.1.  Automatic Tunneling Using 6to4 and Teredo
+
+   Even when operators may not be actively deploying IPv6, automatic
+   mechanisms exist on subscriber operating systems and CPE hardware.
+   Such technologies include 6to4 [RFC3056], which is most commonly used
+   with anycast relays [RFC3068].  Teredo [RFC4380] is also used widely
+   by many Internet hosts.
+
+   Documents such as [RFC6343] have been written to help operators
+   understand observed problems with 6to4 deployments and provide
+   guidelines on how to improve their performance.  An operator may want
+   to provide local relays for 6to4 and/or Teredo to help improve the
+   protocol's performance for ambient traffic utilizing these IPv6
+   connectivity methods.  Experiences such as those described in
+   [COMCAST-IPv6-EXPERIENCES] show that local relays have proved
+   beneficial to 6to4 protocol performance.
+
+   Operators should also be aware of breakage cases for 6to4 if
+   non-[RFC1918] addresses are used within CGN/NAT444 zones.  Many
+   off-the-shelf CPEs and operating systems may turn on 6to4 without a
+   valid return path to the originating (local) host.  This particular
+   use case can occur if any space other than [RFC1918] is used,
+   including Shared Address Space [RFC6598] or space registered to
+   another organization (squat space).  The operator can use 6to4
+   Provider Managed Tunnels (6to4-PMT) [RFC6732] or attempt to block
+   6to4 operation entirely by blocking the anycast ranges associated
+   with [RFC3068].
+
+4.2.  Carrier-Grade NAT (NAT444)
+
+   Carrier-Grade NAT (CGN), specifically as deployed in a NAT444
+   scenario [CGN-REQS], may prove beneficial for those operators who
+   offer Dual Stack services to subscriber endpoints once they exhaust
+   their pools of IPv4 addresses.  CGNs, and address sharing overall,
+   are known to cause certain challenges for the IPv4 service [RFC6269]
+   [NAT444-IMPACTS] 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/NAT444 may
+   provide continued access to IPv4 endpoints.  Some of the advantages
+   of using CGN/NAT444 include similarities in provisioning and
+
+
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 10]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   activation models.  IPv4 hosts in a CGN/NAT444 deployment will
+   likely inherit the same addressing and management procedures as
+   legacy IPv4 globally addressed hosts (i.e., DHCPv4, DNS (v4), TFTP,
+   TR-069, etc.).
+
+4.3.  6rd
+
+   6rd [RFC5969] provides a way of offering IPv6 connectivity to
+   subscriber endpoints when native IPv6 addressing on the access
+   network is not yet possible.  6rd provides tunneled connectivity for
+   IPv6 over the existing IPv4 path.  As the access edge is upgraded and
+   subscriber premises equipment is replaced, 6rd can be replaced by
+   native IPv6 connectivity.  6rd can be delivered on top of a CGN/
+   NAT444 deployment, but this would cause all traffic to be subject to
+   some type of transition technology.
+
+   6rd may also be advantageous during the early transition period while
+   IPv6 traffic volumes are low.  During this period, the operator can
+   gain experience with IPv6 in the core network and improve the
+   operator's peering framework to match those of the IPv4 service.  6rd
+   scales by adding relays to the operator's network.  Another advantage
+   of 6rd is that the operator does not need a DHCPv6 address assignment
+   infrastructure 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).
+
+   Client support is required for 6rd operation and may not be available
+   on deployed hardware.  6rd deployments may require the subscriber or
+   operator to replace the CPE.  6rd will also require parameter
+   configuration that can be powered by the operator through DHCPv4,
+   manually provisioned on the CPE, or automatically provisioned through
+   some other means.  Manual provisioning would likely limit deployment
+   scale.
+
+4.4.  Native Dual Stack
+
+   Native Dual Stack is often referred to as the "gold standard" of IPv6
+   and IPv4 delivery.  It is a method of service delivery that is
+   already used in many existing IPv6 deployments.  Native Dual Stack
+   does, however, require that native IPv6 be delivered through the
+   access network to the subscriber premises.  This technology option is
+   desirable in many cases and can be used immediately if the access
+   network and subscriber premises equipment support native IPv6.
+
+
+
+
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 11]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   An operator who runs out of IPv4 addresses to assign to subscribers
+   will not be able to provide traditional native Dual Stack
+   connectivity for new subscribers.  In Dual Stack deployments where
+   sufficient IPv4 addresses are not available, CGN/NAT444 can be used
+   on the IPv4 path.
+
+   Delivering native Dual Stack would require the operator's core and
+   access networks to support IPv6.  Other systems, like DHCP, DNS, and
+   diagnostic/management facilities, need to be upgraded to support IPv6
+   as well.  The upgrade of such systems may often be non-trivial and
+   costly.
+
+4.5.  DS-Lite
+
+   DS-Lite [RFC6333] is based on a native IPv6 connection model where
+   IPv4 services are supported.  DS-Lite provides tunneled connectivity
+   for IPv4 over the IPv6 path between the subscriber's network device
+   and a provider-managed gateway (Address Family Transition Router
+   (AFTR)).
+
+   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
+   use may not be viable during early transition if the core or access
+   network lacks IPv6 support.  During the early transition period, a
+   significant amount of content and services may by IPv4-only.
+   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
+   impact.  The operator may also want to make sure that most of its
+   internal services and a significant amount of external content are
+   available over IPv6 before deploying DS-Lite.  The availability of
+   services on IPv6 would help lower the demand on the AFTRs.
+
+   By sharing IPv4 addresses among multiple endpoints, like CGN/NAT444,
+   DS-Lite can facilitate continued support of legacy IPv4 services even
+   after IPv4 address run-out.  There are some functional considerations
+   to take into account with DS-Lite, such as those described in
+   [NAT444-IMPACTS] and in [DSLITE-DEPLOYMENT].
+
+   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 subscriber-acquired endpoints.
+
+4.6.  NAT64
+
+   NAT64 [RFC6146] provides the ability to connect IPv6-only connected
+   clients and hosts to IPv4 servers without any tunneling.  NAT64
+   requires that the host and home network support IPv6-only modes of
+
+
+
+Kuarsingh & Howard            Informational                    [Page 12]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   operation.  Home networks do not commonly contain equipment that is
+   100% IPv6-capable.  It is also not anticipated that common home
+   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 [RFC6586].
+
+   Viability of NAT64 will increase in wireline networks as consumer
+   equipment is replaced by IPv6-capable versions.  There are incentives
+   for operators to move to IPv6-only operation, when feasible; these
+   include the simplicity of a single-stack access network.
+
+5.  IPv6 Transition Phases
+
+   The phases described in this document are not provided as a rigid set
+   of steps but are considered a guideline that should be analyzed by
+   operators planning their IPv6 transition.  Operators may choose to
+   skip steps based on technological capabilities within their specific
+   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 the expectation that IPv6 traffic volume may
+   initially be low, and operator staff will gain experience with IPv6
+   over time.  As traffic volumes of IPv6 increase, IPv4 traffic volumes
+   will decline (in percentage relative to IPv6), until IPv6 is the
+   dominant address family used.  Operators may want to keep the traffic
+   flow for the dominant traffic class (IPv4 vs. IPv6) native to help
+   manage costs related to transition technologies.  The cost of using
+   multiple technologies in succession to optimize each stage of the
+   transition should also be compared against the cost of changing and
+   upgrading subscriber connections.
+
+   Additional guidance and information on utilizing IPv6 transition
+   mechanisms can be found in [RFC6180].  Also, guidance on incremental
+   CGN for IPv6 transition can be found in [RFC6264].
+
+5.1.  Phase 0 - Foundation
+
+5.1.1.  Phase 0 - Foundation: Training
+
+   Training is one of the most important steps in preparing an
+   organization to support IPv6.  Most people have little experience
+   with IPv6, and many do not even have a solid grounding in IPv4.  The
+   implementation of IPv6 will likely produce many challenges due to
+   immature code on hardware, and the evolution of many applications and
+   systems to support IPv6.  To properly deal with these impending or
+   current challenges, organizations must train their staff on IPv6.
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 13]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   Training should also be provided within reasonable timelines from the
+   actual IPv6 deployment.  This means the operator needs to plan in
+   advance as it trains the various parts of its organization.  New
+   technology and engineering staff often receive little training
+   because of their depth of knowledge but must at least be provided
+   opportunities to read documentation, architectural white papers, and
+   RFCs.  Operations personnel who support the network and other systems
+   need to be trained closer to the deployment timeframes so that they
+   immediately use their newfound knowledge before forgetting.
+
+   Subscriber support staff would require much more basic but large-
+   scale training, since many organizations have massive call centers to
+   support the subscriber 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: 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 its 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 of those systems.
+
+5.1.3.  Phase 0 - Foundation: Routing
+
+   The network infrastructure will need to be in place to support IPv6.
+   This includes the routed infrastructure, along with addressing
+   principles, routing principles, peering policy, and related network
+   functions.  Since IPv6 is quite different from IPv4 in several ways,
+   including the number of addresses that are made available, careful
+   attention to a scalable and manageable architecture is needed.  One
+   such change is the notion of a delegated prefix, which deviates from
+   the common single-address phenomenon in IPv4-only deployments.
+   Deploying prefixes per CPE can load the routing tables and require a
+   routing protocol or route gleaning to manage connectivity to the
+   subscriber's network.  Delegating prefixes can be of specific
+   importance in access network environments where downstream
+   subscribers often move between access nodes, raising the concern of
+   frequent renumbering and/or managing movement of routed prefixes
+   within the network (common in cable-based networks).
+
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 14]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+5.1.4.  Phase 0 - Foundation: Network Policy and Security
+
+   Many, but not all, security policies will map easily from IPv4 to
+   IPv6.  Some new policies may be required for issues specific to IPv6
+   operation.  This document does not highlight these specific issues
+   but raises the awareness that they are to be taken into consideration
+   and should be addressed when delivering IPv6 services.  Other IETF
+   documents, such as [RFC4942], [RFC6092], and [RFC6169], are excellent
+   resources.
+
+5.1.5.  Phase 0 - Foundation: Transition Architecture
+
+   Operators should plan out their transition architecture in advance
+   (with room for flexibility) to help optimize how they will build out
+   and scale their networks.  Should operators consider multiple
+   technologies, like CGN/NAT444, DS-Lite, NAT64, and 6rd, they may want
+   to plan out where network resident equipment may be located and
+   potentially choose locations that can be used for all functional
+   roles (i.e., placement of a NAT44 translator, AFTR, NAT64 gateway,
+   and 6rd relays).  Although these functions are not inherently
+   connected, additional management, diagnostic, and monitoring
+   functions can be deployed alongside the transition hardware without
+   the need to distribute these functions to an excessive or divergent
+   number of locations.
+
+   This approach may also prove beneficial if traffic patterns change
+   rapidly in the future, as operators may need to evolve their
+   transition infrastructure faster than originally anticipated.  One
+   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 (the technological means to
+   re-provision the subscriber notwithstanding).
+
+   Operators should inform their vendors of what technologies they plan
+   to support over the course of the transition to make sure the
+   equipment is suited to support those modes of operation.  This is
+   important for both network gear and subscriber premises equipment.
+
+   Operators should also plan their overall strategy to meet the target
+   needs of an IPv6-only deployment.  As traffic moves to IPv6, the
+   benefits of only a single stack on the access network may eventually
+   justify the removal of IPv4 for simplicity.  Planning for this
+   eventual model, no matter how far off this may be, will help
+   operators embrace this end state when needed.
+
+
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 15]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+5.1.6.  Phase 0 - Foundation: Tools and Management
+
+   The operator should thoroughly analyze all provisioning and
+   management systems to develop requirements for each phase.  This will
+   include concepts related to the 128-bit IPv6 address, the notation of
+   an assigned IPv6 prefix (Prefix Delegation), and the ability to
+   detect either or both address families when determining if a
+   subscriber has full Internet service.
+
+   If an operator stores usage information, this would need to be
+   aggregated to include both IPv4 and IPv6 information as both address
+   families are assigned to the same subscriber.  Tools that verify
+   connectivity may need to query the IPv4 and IPv6 addresses.
+
+5.2.  Phase 1 - Tunneled IPv6
+
+   Tunneled access to IPv6 can be regarded as an early-stage transition
+   option by operators.  Many network operators can deploy native IPv6
+   from the access edge to the peering edge fairly quickly but may not
+   be able to offer IPv6 natively to the subscriber edge device.  During
+   this period of time, tunneled access to IPv6 is a viable alternative
+   to native IPv6.  It is also possible that operators may be rolling
+   out IPv6 natively to the subscriber edge, but the time involved may
+   be long, due to logistics and other factors.  Even while carefully
+   rolling out native IPv6, operators can deploy relays for automatic
+   tunneling technologies like 6to4 and Teredo.  Where native IPv6 to
+   the access edge is a longer-term project, operators can consider 6rd
+   [RFC5969] as an option to offer in-home IPv6 access.  Note that 6to4
+   and Teredo have different address selection [RFC6724] behaviors than
+   6rd.  Additional guidelines on deploying and supporting 6to4 can be
+   found in [RFC6343].
+
+   The operator can deploy 6rd relays into the network and scale them as
+   needed to meet the early subscriber needs of IPv6.  Since 6rd
+   requires the upgrade or replacement of CPE devices, the operator may
+   want to ensure that the CPE devices support not just 6rd but native
+   Dual Stack and other tunneling technologies, such as DS-Lite, if
+   possible [IPv6-CE-RTR-REQS].  6rd clients are becoming available in
+   some retail channel products and within the original equipment
+   manufacturer (OEM) market.  Retail availability of 6rd is important,
+   since not all operators control or have influence over what equipment
+   is deployed in the consumer home network.  The operator can support
+   6rd access with unmanaged devices using DHCPv4 Option 212
+   (OPTION_6RD) [RFC5969].
+
+
+
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 16]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+                                       +--------+         -----
+                                       |        |       /       \
+                       Encap IPv6 Flow |  6rd   |      |  IPv6   |
+                                - - -> | Relay  | <- > |   Net   |
+          +---------+         /        |        |       \       /
+          |         |        /         +--------+         -----
+          |   6rd   + <-----                              -----
+          |         |                                   /       \
+          |  Client |         IPv4 Flow                |  IPv4   |
+          |         + < - - - - - - - - - - - - - - -> |   Net   |
+          |         |                                   \       /
+          +---------+                                     -----
+
+                         Figure 1: 6rd Basic Model
+
+   6rd used as an initial transition technology also provides the added
+   benefit of a deterministic IPv6 prefix based on the IPv4 assigned
+   address.  Many operational tools are available or have been built to
+   identify what IPv4 (often dynamic) address was assigned to a
+   subscriber CPE.  So, a simple tool and/or method can be built to help
+   identify the IPv6 prefix using the knowledge of the assigned IPv4
+   address.
+
+   An operator may choose to not offer internal services over IPv6 if
+   tunneled access to IPv6 is used, since some services generate a large
+   amount of traffic.  Such traffic may include video content, like
+   IPTV.  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
+
+   Deploying 6rd can greatly speed up an operator's ability to support
+   IPv6 to the subscriber network if native IPv6 connectivity cannot be
+   supplied.  The speed at which 6rd can be deployed is highlighted in
+   [RFC5569].
+
+   The first core consideration is deployment models.  6rd requires the
+   CPE (6rd client) to send traffic to a 6rd relay.  These relays can
+   share a common anycast address or can use unique addresses.  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
+   deployed relays, the operator can deploy more relays into the
+   network.  The one drawback is that it may be difficult to manage the
+   traffic volume among additional relays, since all 6rd traffic will
+   find the nearest (in terms of IGP cost) relay.  The use of multiple
+   relay addresses can help provide more control but has the
+   disadvantage of being more complex to provision.  Subsets of CPEs
+
+
+
+Kuarsingh & Howard            Informational                    [Page 17]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   across the network will require and contain different relay
+   information.  An alternative approach is to use a hybrid model using
+   multiple anycast service IP addresses for clusters of 6rd relays,
+   should the operator anticipate massive scaling of the environment.
+   Thus, the operator has multiple vectors by which to scale the
+   service.
+
+                                              +--------+
+                                              |        |
+                                IPv4 Addr.X   |  6rd   |
+                                     - - - >  | Relay  |
+               +-----------+        /         |        |
+               | Client A  | <- - -           +--------+
+               +-----------+
+                             Separate IPv4 Service Addresses
+               +-----------+
+               | Client B  | < - -            +--------+
+               +-----------+       \          |        |
+                                     - - - >  |  6rd   |
+                                IPv4 Addr.Y   | Relay  |
+                                              |        |
+                                              +--------+
+
+             Figure 2: 6rd Multiple IPv4 Service Address Model
+
+
+                                            +--------+
+                                            |        |
+                              IPv4 Addr.X   |  6rd   |
+                                   - - - >  | Relay  |
+             +-----------+        /         |        |
+             | Client A  |- - - -           +--------+
+             +-----------+
+                       Common (Anycast) IPv4 Service Addresses
+             +-----------+
+             | Client B  | - - -            +--------+
+             +-----------+       \          |        |
+                                   - - - >  |  6rd   |
+                              IPv4 Addr.X   | Relay  |
+                                            |        |
+                                            +--------+
+
+             Figure 3: 6rd Anycast IPv4 Service Address Model
+
+   Provisioning of the 6rd endpoints is affected by the deployment model
+   chosen (i.e., anycast vs. specific service IP addresses).  Using
+   multiple IP addresses may require more planning and management, as
+   subscriber equipment will have different sets of data to be
+
+
+
+Kuarsingh & Howard            Informational                    [Page 18]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   provisioned into the devices.  The operator may use DHCPv4, manual
+   provisioning, or other mechanisms to provide parameters to subscriber
+   equipment.
+
+   If the operator manages the CPE, support personnel will need tools
+   able to report the status of the 6rd tunnel.  Usage information can
+   be collected on the operator edge, but if source/destination flow
+   details are required, data must be collected after the 6rd relay (the
+   IPv6 side of the connection).
+
+   6rd [RFC5969], like any tunneling option, is subject to a reduced
+   MTU, so operators need to plan to manage this type of environment.
+
+       +---------+  IPv4 Encapsulation  +------------+
+       |         +- - - - - - - - - - - +            |
+       |   6rd   +----------------------+     6rd    +------------
+       |         |   IPv6 Packet        |    Relay   | IPv6 Packet
+       | Client  +----------------------+            +------------
+       |         +- - - - - - - - - - - +            |      ^
+       +---------+  ^                   +------------+      |
+                    |                                       |
+                    |                                       |
+             IPv4 (Tools/Mgmt)                     IPv6 Flow Analysis
+
+                  Figure 4: 6rd Tools and Flow Management
+
+5.3.  Phase 2 - Native Dual Stack
+
+   Either as a follow-up phase to "tunneled IPv6" or as an initial step,
+   the operator may deploy native IPv6 down to the CPEs.  This phase
+   would then allow both IPv6 and IPv4 to be natively accessed by the
+   subscriber home network without translation or tunneling.  The native
+   Dual Stack phase can be rolled out across the network while the
+   tunneled IPv6 service remains operational, if used.  As areas begin
+   to support native IPv6, subscriber home equipment will generally
+   prefer using the IPv6 addresses derived from the delegated IPv6
+   prefix versus tunneling options as defined in [RFC6724], such as 6to4
+   and Teredo.  Specific care is needed when moving to native Dual Stack
+   from 6rd, as documented in [6rd-SUNSETTING].
+
+   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
+   operator can confidently move both internal and external services to
+   IPv6.  Since there are no translation devices needed for this mode of
+   operation, it transports both protocols (IPv6 and IPv4) efficiently
+   within the network.
+
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 19]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+5.3.1.  Native Dual Stack Deployment Considerations
+
+   Native Dual Stack is a very desirable option for the IPv6 transition,
+   if feasible.  The operator must enable IPv6 on the network core and
+   peering edge before attempting to turn on native IPv6 services.
+   Additionally, provisioning and support systems such as DHCPv6, DNS,
+   and other functions that support the subscriber's IPv6 Internet
+   connection need to be in place.
+
+   The operator must treat IPv6 connectivity with the same operational
+   importance as IPv4.  A poor IPv6 service may be worse than not
+   offering an IPv6 service at all, as it will negatively impact the
+   subscriber's Internet experience.  This may cause users or support
+   personnel to disable IPv6, limiting the subscriber from the benefits
+   of IPv6 connectivity as network performance improves.  New code and
+   IPv6 functionality may cause instability at first.  The operator will
+   need to monitor, troubleshoot, and resolve issues promptly.
+
+   Prefix assignment and routing are new for common residential
+   services.  Prefix assignment is straightforward (DHCPv6 using
+   Identity Associations for Prefix Delegation (IA_PDs)), but
+   installation and propagation of routing information for the prefix,
+   especially during access layer instability, are often poorly
+   understood.  The operator should develop processes for renumbering
+   subscribers who move to new access nodes.
+
+   Operators need to keep track of the dynamically assigned IPv4 address
+   along with the IPv6 address and prefix.  Any additional dynamic
+   elements, such as auto-generated host names, need to be considered
+   and planned for.
+
+5.4.  Intermediate Phase for CGN
+
+   Acquiring more IPv4 addresses is already challenging, if not
+   impossible; therefore, address sharing may be required on the IPv4
+   path of a Dual Stack deployment.  The operator may have a preference
+   to move directly to a transition technology such as DS-Lite [RFC6333]
+   or may use Dual Stack with CGN/NAT444 to facilitate IPv4 connections.
+
+   CGN/NAT444 requires IPv4 addressing between the subscriber premises
+   equipment and the operator's translator; this may be facilitated by
+   shared addresses [RFC6598], private addresses [RFC1918], or another
+   address space.  CGN/NAT444 is only recommended to be used alongside
+
+
+
+
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 20]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   IPv6 in a Dual Stack deployment and not on its own.  Figure 5
+   provides a comparative view of a traditional IPv4 path versus one
+   that uses CGN/NAT444.
+
+                                       +--------+         -----
+                                       |        |       /       \
+                             IPv4 Flow |  CGN   |      |         |
+                                - - -> +        + < -> |         |
+          +---------+         /        |        |      |         |
+          |   CPE   | <- - - /         +--------+      |  IPv4   |
+          |---------+                                  |   Net   |
+                                                       |         |
+          +---------+         IPv4 Flow                |         |
+          |   CPE   | <- - - - - - - - - - - - - - - > |         |
+          |---------+                                   \       /
+                                                          -----
+
+                     Figure 5: Overlay CGN Deployment
+
+   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
+   native.  For endpoints operating in an IPv6+CGN/NAT444 model, the
+   native IPv6 path is available for higher-quality connectivity,
+   helping host operation over the network.  At the same time, the CGN
+   path may offer less than optimal performance.  These points are also
+   true for DS-Lite.
+
+                                       +--------+         -----
+                                       |        |       /       \
+                             IPv4 Flow |  CGN   |      |  IPv4   |
+                                - - -> +        + < -> |   Net   |
+          +---------+         /        |        |       \       /
+          |         | <- - - /         +--------+        -------
+          |   Dual  |
+          |  Stack  |                                     -----
+          |   CPE   |         IPv6 Flow                 / IPv6  \
+          |         | <- - - - - - - - - - - - - - - > |   Net   |
+          |---------+                                   \       /
+                                                          -----
+
+                       Figure 6: Dual Stack with CGN
+
+   CGN/NAT444 deployments may make use of a number of address options,
+   which include [RFC1918] or Shared Address Space [RFC6598].  It is
+   also possible that operators may use part of their own Regional
+   Internet Registry (RIR) assigned address space for CGN zone
+   addressing if [RFC1918] addresses pose technical challenges in their
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 21]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   networks.  It is not recommended that operators use 'squat space', as
+   it may pose additional challenges with filtering and policy control
+   [RFC6598].
+
+5.4.1.  CGN Deployment Considerations
+
+   CGN is often considered undesirable by operators but is required in
+   many cases.  An operator who needs to deploy CGN capabilities should
+   consider the impacts of the function on the network.  CGN is often
+   deployed in addition to running IPv4 services and should not
+   negatively impact the already working native IPv4 service.  CGNs will
+   be needed on a small scale at first and will grow to meet the demands
+   based on traffic and connection dynamics of the subscriber, content,
+   and network peers.
+
+   The operator may want to deploy CGNs more centrally at first and then
+   scale the system as needed.  This approach can help conserve the
+   costs of the system, limiting the deployed base and scaling it based
+   on actual traffic demand.  The operator should use a deployment model
+   and architecture that allow the system to scale as needed.
+
+                                       +--------+         -----
+                                       |        |       /       \
+                                       |  CGN   |      |         |
+                                - - -> +        + < -> |         |
+          +---------+         /        |        |      |         |
+          |   CPE   | <- - - /         +--------+      |  IPv4   |
+          |         |                      ^           |         |
+          |---------+                      |           |   Net   |
+                           +--------+    Centralized   |         |
+          +---------+      |        |       CGN        |         |
+          |         |      |  CGN   |                  |         |
+          |   CPE   | <- > +        + <- - - - - - - > |         |
+          |---------+      |        |                   \       /
+                           +--------+                     -----
+                               ^
+                               |
+                           Distributed CGN
+
+           Figure 7: CGN Deployment: Centralized vs. Distributed
+
+   The operator may be required to log translation information
+   [CGN-REQS].  This logging may require significant investment in
+   external systems that ingest, aggregate, and report such information
+   [DETERMINISTIC-CGN].
+
+
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 22]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   Since CGN has noticeable impacts on certain applications
+   [NAT444-IMPACTS], operators may deploy CGN only for those subscribers
+   who may be less affected by CGN (if possible).
+
+5.5.  Phase 3 - IPv6-Only
+
+   Once native IPv6 is widely deployed in the network and well supported
+   by tools, staff, and processes, an operator may consider supporting
+   only IPv6 to all or some subscriber endpoints.  During this final
+   phase, IPv4 connectivity may or may not need to be supported,
+   depending on the conditions of the network, subscriber demand, and
+   legacy device requirements.  If legacy IPv4 connectivity is still
+   demanded (e.g., for older nodes), DS-Lite [RFC6333] may be used to
+   tunnel the traffic.  If IPv4 connectivity is not required but access
+   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
+   address sharing for IPv4 Internet connectivity but with only a single
+   layer of translation, as compared to CGN/NAT444.  This mode of
+   operation also removes the need to directly supply subscriber
+   endpoints with an IPv4 address, potentially simplifying the
+   connectivity to the customer (single address family) and supporting
+   IPv6-only addressing to the CPE.
+
+   The operator can also move Dual Stack endpoints to DS-Lite
+   retroactively to help optimize the IPv4 address-sharing deployment by
+   removing the IPv4 address assignment and routing component.  To
+   minimize traffic needing translation, the operator should have
+   already moved most content to IPv6 before the IPv6-only phase is
+   implemented.
+                                        +--------+      -----
+                                        |        |    /       \
+                        Encap IPv4 Flow |  AFTR  |   |  IPv4   |
+                                 -------+        +---+   Net   |
+           +---------+         /        |        |    \       /
+           |         |        /         +--------+      -----
+           | DS-Lite +-------                           -----
+           |         |                                /       \
+           |  Client |         IPv6 Flow             |  IPv6   |
+           |         +-------------------------------|   Net   |
+           |         |                                \       /
+           +---------+                                  -----
+
+                       Figure 8: DS-Lite Basic Model
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 23]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   If the operator had previously decided to enable a CGN/NAT444
+   deployment, it may be able to co-locate the AFTR and CGN/NAT444
+   processing functions within a common network location to simplify
+   capacity management and the engineering of flows.  This case may be
+   evident in a later transition stage, when an operator chooses to
+   optimize its network and IPv6-only operation is feasible.
+
+5.5.2.  DS-Lite Deployment Considerations
+
+   The same deployment considerations associated with native IPv6
+   deployments apply to DS-Lite and NAT64.  IPv4 will now be dependent
+   on IPv6 service quality, so the IPv6 network and services must be
+   running well to ensure a quality experience for the end subscriber.
+   Tools and processes will be needed to manage the encapsulated IPv4
+   service.  If flow analysis is required for IPv4 traffic, this may be
+   enabled at a point beyond the AFTR (after decapsulation) or where
+   DS-Lite-aware equipment is used to process traffic midstream.
+
+     +---------+  IPv6 Encapsulation  +------------+
+     |         + - - - - - - - - - - -+            |
+     |  AFTR   +----------------------+    AFTR    +------------
+     |         |   IPv4 Packet        |            | IPv4 Packet
+     | Client  +----------------------+            +------------
+     |         + - - - - - - - - - - -+            |      ^
+     +---------+  ^               ^   +------------+      |
+                  |               |                       |
+                  |               |                       |
+           IPv6 (Tools/Mgmt)      |           IPv4 Packet Flow Analysis
+                                  |
+             Midstream IPv4 Packet Flow Analysis (Encapsulation Aware)
+
+                 Figure 9: DS-Lite Tools and Flow Analysis
+
+   DS-Lite [RFC6333] also requires client support on the subscriber
+   premises device.  The operator must clearly articulate to vendors
+   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
+   example, an operator may use 6rd in the outset of the transition,
+   then move to native Dual Stack followed by DS-Lite.
+
+   DS-Lite [RFC6333], like any tunneling option, is subject to a reduced
+   MTU, so operators need to plan to manage this type of environment.
+   Additional considerations for DS-Lite deployments can be found in
+   [DSLITE-DEPLOYMENT].
+
+
+
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 24]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+5.5.3.  NAT64 Deployment Considerations
+
+   The deployment of NAT64 assumes that the network assigns an IPv6
+   address to a network endpoint that is translated to an IPv4 address
+   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 of this undesirable legacy behavior.  Operational deployment
+   models, considerations, and experiences related to NAT64 have been
+   documented in [NAT64-EXPERIENCE].
+
+                                        +--------+      -----
+                                        |        |    /       \
+                              IPv6 Flow | NAT64  |   |  IPv4   |
+                                 -------+ DNS64  +---+   Net   |
+           +---------+         /        |        |    \       /
+           |         |        /         +--------+      -----
+           |  IPv6   +-------                           -----
+           |         |                                /       \
+           |  Only   |         IPv6 Flow             |  IPv6   |
+           |         +-------------------------------|   Net   |
+           |         |                                \       /
+           +---------+                                  -----
+
+                    Figure 10: NAT64/DNS64 Basic Model
+
+   To navigate some of the limitations of NAT64 when dealing with legacy
+   IPv4 applications, the operator may choose to implement 464XLAT
+   [464XLAT] if possible.  As support for IPv6 on subscriber equipment
+   and content increases, the efficiency of NAT64 increases by reducing
+   the need to translate traffic.  NAT64 deployments would see an
+   overall decline in translator usage as more traffic is promoted to
+   IPv6-to-IPv6 native communication.  NAT64 may play an important part
+   in an operator's late-stage transition, as it removes the need to
+   support IPv4 on the access network and provides a solid go-forward
+   networking model.
+
+   It should be noted, as with any technology that utilizes address
+   sharing, that the IPv4 public pool sizes (IPv4 transport addresses
+   per [RFC6146]) can pose limits to IPv4 server connectivity for the
+   subscriber base.  Operators should be aware that some IPv4 growth in
+   the near term is possible, so IPv4 translation pools need to be
+   monitored.
+
+
+
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 25]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+6.  Security Considerations
+
+   Operators should review the documentation related to the technologies
+   selected for IPv6 transition.  In those reviews, operators should
+   understand what security considerations are applicable to the chosen
+   technologies.  As an example, [RFC6169] should be reviewed to
+   understand security considerations related to tunneling technologies.
+
+7.  Acknowledgements
+
+   Special thanks to Wes George, Chris Donley, Christian Jacquenet, and
+   John Brzozowski for their extensive review and comments.
+
+   Thanks to the following people for their textual contributions,
+   guidance, and comments: Jason Weil, Gang Chen, Nik Lavorato, John
+   Cianfarani, Chris Donley, Tina TSOU, Fred Baker, and Randy Bush.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC6180]  Arkko, J. and F. Baker, "Guidelines for Using IPv6
+              Transition Mechanisms during IPv6 Deployment", RFC 6180,
+              May 2011.
+
+8.2.  Informative References
+
+   [464XLAT]  Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
+              Combination of Stateful and Stateless Translation", Work
+              in Progress, September 2012.
+
+   [6rd-SUNSETTING]
+              Townsley, W. and A. Cassen, "6rd Sunsetting", Work
+              in Progress, November 2011.
+
+   [CGN-REQS]
+              Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
+              A., and H. Ashida, "Common requirements for Carrier Grade
+              NATs (CGNs)", Work in Progress, August 2012.
+
+   [COMCAST-IPv6-EXPERIENCES]
+              Brzozowski, J. and C. Griffiths, "Comcast IPv6 Trial/
+              Deployment Experiences", Work in Progress, October 2011.
+
+
+
+
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 26]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   [DETERMINISTIC-CGN]
+              Donley, C., Grundemann, C., Sarawat, V., and K.
+              Sundaresan, "Deterministic Address Mapping to Reduce
+              Logging in Carrier Grade NAT Deployments", Work
+              in Progress, July 2012.
+
+   [DSLITE-DEPLOYMENT]
+              Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M.
+              Boucadair, "Deployment Considerations for Dual-Stack
+              Lite", Work in Progress, August 2012.
+
+   [IPv6-CE-RTR-REQS]
+              Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
+              Requirements for IPv6 Customer Edge Routers", Work
+              in Progress, October 2012.
+
+   [IPv6-DESIGN]
+              Matthews, P., "Design Guidelines for IPv6 Networks", Work
+              in Progress, October 2012.
+
+   [IPv6-ICP-ASP-GUIDANCE]
+              Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
+              Content and Application Service Providers", Work
+              in Progress, September 2012.
+
+   [NAT444-IMPACTS]
+              Donley, C., Ed., Howard, L., Kuarsingh, V., Berg, J., and
+              J. Doshi, "Assessing the Impact of Carrier-Grade NAT on
+              Network Applications", Work in Progress, October 2012.
+
+   [NAT64-EXPERIENCE]
+              Chen, G., Cao, Z., Byrne, C., Xie, C., and D. Binet,
+              "NAT64 Operational Experiences", Work in Progress,
+              August 2012.
+
+   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+              E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, February 1996.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+              via IPv4 Clouds", RFC 3056, February 2001.
+
+   [RFC3068]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
+              RFC 3068, June 2001.
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 27]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+              Network Address Translations (NATs)", RFC 4380,
+              February 2006.
+
+   [RFC4942]  Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
+              Co-existence Security Considerations", RFC 4942,
+              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
+              Infrastructures (6rd) -- Protocol Specification",
+              RFC 5969, August 2010.
+
+   [RFC6092]  Woodyatt, J., "Recommended Simple Security Capabilities in
+              Customer Premises Equipment (CPE) for Providing
+              Residential IPv6 Internet Service", RFC 6092,
+              January 2011.
+
+   [RFC6144]  Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
+              IPv4/IPv6 Translation", RFC 6144, April 2011.
+
+   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+              NAT64: Network Address and Protocol Translation from IPv6
+              Clients to IPv4 Servers", RFC 6146, April 2011.
+
+   [RFC6169]  Krishnan, S., Thaler, D., and J. Hoagland, "Security
+              Concerns with IP Tunneling", RFC 6169, April 2011.
+
+   [RFC6264]  Jiang, S., Guo, D., and B. Carpenter, "An Incremental
+              Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264,
+              June 2011.
+
+   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
+              Roberts, "Issues with IP Address Sharing", RFC 6269,
+              June 2011.
+
+   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
+              Stack Lite Broadband Deployments Following IPv4
+              Exhaustion", RFC 6333, August 2011.
+
+   [RFC6343]  Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
+              RFC 6343, August 2011.
+
+   [RFC6540]  George, W., Donley, C., Liljenstolpe, C., and L. Howard,
+              "IPv6 Support Required for All IP-Capable Nodes", BCP 177,
+              RFC 6540, April 2012.
+
+
+
+Kuarsingh & Howard            Informational                    [Page 28]
+
+RFC 6782                Wireline Incremental IPv6          November 2012
+
+
+   [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.
+
+   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
+              "Default Address Selection for Internet Protocol Version 6
+              (IPv6)", RFC 6724, September 2012.
+
+   [RFC6732]  Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider
+              Managed Tunnels", RFC 6732, September 2012.
+
+Authors' Addresses
+
+   Victor Kuarsingh (editor)
+   Rogers Communications
+   8200 Dixie Road
+   Brampton, Ontario  L6T 0C1
+   Canada
+
+   EMail: victor.kuarsingh@gmail.com
+   URI:   http://www.rogers.com
+
+
+   Lee Howard
+   Time Warner Cable
+   13820 Sunrise Valley Drive
+   Herndon, VA  20171
+   US
+
+   EMail: lee.howard@twcable.com
+   URI:   http://www.timewarnercable.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kuarsingh & Howard            Informational                    [Page 29]
+