v6ops                                                  V. Kuarsingh, Ed.
Internet-Draft                                     Rogers Communications
Intended status: Informational                                 L. Howard
Expires: August 5, November 10, 2012                             Time Warner Cable
                                                        February 2,
                                                             May 9, 2012

                       Wireline Incremental IPv6
             draft-ietf-v6ops-wireline-incremental-ipv6-01
             draft-ietf-v6ops-wireline-incremental-ipv6-02

Abstract

   Operators worldwide are in various stages of preparing for, or
   deploying IPv6 into their networks.  The operators often face
   difficult challenges related to both 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 depleting stagnant supply of IPv4
   addresses.  The IPv6 transition will take most networks from an IPv4-
   only environment to an IPv6 focused dominant environment with long transition
   period of
   dual stack operation 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 5, November 10, 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.

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 . . . . . . . . . . . . . . . .  5  6
     3.2.  IPv4 Resource Challenges . . . . . . . . . . . . . . . . .  6
     3.3.  IPv6 Introduction and Operational Maturity . . . . . . . .  6  7
     3.4.  Service Management . . . . . . . . . . . . . . . . . . . .  7
     3.5.  Sub-Optimal Operation of Transition Technologies . . . . .  8
     3.6.  Future IPv6 Network  . . . . . . . . . . . . . . . . . . .  8  9
   4.  IPv6 Transition Technology Analysis  . . . . . . . . . . . . .  9
     4.1.  Automatic Tunnelling using 6to4 and Teredo . . . . . . . .  9
     4.2.  Carrier Grade NAT (NAT444) . . . . . . . . . . . . . . . .  9 10
     4.3.  6RD  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.4.  Native Dual Stack  . . . . . . . . . . . . . . . . . . . . 10 11
     4.5.  DS-Lite  . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.6.  NAT64  . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12
   5.  IPv6 Transition Phases . . . . . . . . . . . . . . . . . . . . 12
     5.1.  Phase 0 - Foundation . . . . . . . . . . . . . . . . . . . 12 13
       5.1.1.  Phase 0 - Foundation: Training . . . . . . . . . . . . 12 13
       5.1.2.  Phase 0 - Foundation: Routing  . . . . . . . . . . . . 13
       5.1.3.  Phase 0 - Foundation: Network Policy and Security  . . 13 14
       5.1.4.  Phase 0 - Foundation: Transition Architecture  . . . . 13 14
       5.1.5.  Phase 0- Foundation: Tools and Management  . . . . . . 14
     5.2.  Phase 1 - Tunnelled IPv6 . . . . . . . . . . . . . . . . . 14 15
       5.2.1.  6RD Deployment Considerations  . . . . . . . . . . . . 15 16
     5.3.  Phase 2: Native Dual Stack . . . . . . . . . . . . . . . . 17 18
       5.3.1.  Native Dual Stack Deployment Considerations  . . . . . 18 19
     5.4.  Intermediate Phase for CGN . . . . . . . . . . . . . . . . 18 19
       5.4.1.  CGN Deployment Considerations  . . . . . . . . . . . . 20 21
     5.5.  Phase 3 - IPv6-Only  . . . . . . . . . . . . . . . . . . . 21 22
       5.5.1.  DS-Lite Deployment Considerations  . . . . . . . . . . 22 23
       5.5.2.  NAT64 Deployment Considerations  . . . . . . . . . . . 23
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22 24
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22 24
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 24
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 24
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 23 24
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 23 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 27

1.  Introduction

   This draft sets out to help Wireline operators in planning their IPv6
   deployments while ensuring continued support for IPv6-incapable
   consumer devices and applications.  We will identify which
   technologies can be used incrementally to transition from IPv4-only
   to an IPv6 anchored dominant environment with support for dual stack
   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
   legacy equipment resident in end networks and management of long tail
   IPv4-only content.  Although no single plan will work for for all
   operators, options listed herein provide a baseline which can be
   included in many plans.

   This draft is intended for Wireline environments which includes include Cable,
   DSL and/or Fibre as the access method to the end consumer.  This draft also attempts to follow the methodologies set out in
   [I-D.ietf-v6ops-v4v6tran-framework] to identify how transition
   technologies can be used individually and in combination.  This
   document also attempts to follow the principles laid out in [RFC6180]
   which provides guidance on using IPv6 transition mechanisms.  This
   document will focus on technologies which enable and mature IPv6
   within the operator's network, but will also include a cursory view
   of IPv4 connectivity continuance.  The focal transition technologies
   include 6RD [RFC5969], DS-Lite [RFC6333] [RFC6333], NAT64 and Dual Stack
   operation
   with which may also include a view into NAT44/Carrier Grade NAT (NAT44 without tunnelling as
   distinct from DS-Lite). CGN/NAT444 deployment.  Focus on
   these technologies include is based on their inclusion in many off-the-shelf
   CPEs and availability in commercially available network vendor equipment.

2.  Operator Assumptions

   For the purposes of this document, the authors assume:

      - The operator is considering deploying IPv6 or is in progress in
      deploying IPv6

      - The operator has a legacy IPv4 customer base which will continue
      to exist for a period of time

      - The operator will want to minimize the level of disruption to
      the existing and new customers by minimizing the number of
      technologies and functions that are needed to mediate any given
      set of customer flows (overall preference for Native IP flows)

      - The operator is able to run Dual Stack on their own core network
      and is alble able to transition their own services to support IPv6

   Based on these assumptions, an operator will want to utilize
   technologies which minimize the need to tunnel, translate or mediate
   flows to help simplify optimize traffic flow and lower the cost impacts of
   transition technologies.  Technology  Transition technology selections should be
   made to
   interact with mediate the non-dominant IP family flows and allow Native IP 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 system scaling needed by the relevant transition technology systems.
   deployment size.

   An operator may also choose to prefer more IPv6 focused models where
   the use of transition technologies are based on an effort to enable
   IPv6 at the base layer as soon as possible.  Operators may want to
   promote IPv6 early on in the deployment and have IPv6 traffic perform
   optimally from the outset.  This desire would need to be weighed
   against the cost and support impacts of such an choice.

3.  Reasons and Considerations for a Phased Approach

   When faced with the challenges described in the Introduction,
   operators may need to consider a phased approach when adding IPv6 to
   an existing IPv4 service. customer base.  A phased approach allows the operator to
   add in IPv6 while not ignoring legacy IPv4 connection requirements.
   Some of the main challenges which the operator will face include:

      - IPv4 exhaustion may occur long before all traffic is able to be
      delivered over IPv6, necessitating IPv4 address sharing

      - IPv6 will pose operational challenges since some of the software
      is unvetted quite new and has had short run time in large production
      environments and organizations are also not acclimatized to support
      supporting IPv6 as a service

      - Many access network devices or customer controlled CPEs may not
      support native IPv6 operation for a period of time

      - Connectivity modes will move from IPv4-only to Dual Stack in the
      home, changing functional behaviours in the consumer network
      increasing support requirements for the operator

   These challenges will occur over a period of time which means the
   operator's plans need to address the ever changing requirements of
   the network and customer demand.  The following few sections
   highlight some of the key reasons why a phased approach to IPv6
   transition may be warranted and desired.

   Although phases will be presented in this document, not all operators
   may need to enable each desecrate 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 IPv6 connectivity should be the primary goal for
   operators.  Even though the operator may be focused on IPv6 delivery,
   they should be aware that both IPv4 and IPv6 will play a role in the
   Internet experience during transition.  Many customers use older
   operating systems and hardware which support IPv4-only operation.
   Internet customers don't buy IPv4 or IPv6 connections, they buy
   Internet connections, which demands the need to support both IPv4 and
   IPv6 for as long at the customer's home network demands such support.

   The Internet is made of of many interconnecting systems, networks,
   hardware, software and content sources - all of which will move to
   IPv6 at different rates.  The Operator's mandate during this time of
   transition will be to support connectivity to both IPv6 and IPv4
   through various technological means.  The operator may be able to
   leverage one or the other protocol to help bridge connectivity, 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 addressees for additional endpoints devices means that
   growth in demand of IPv4 connections in some networks will be based
   on
   facilitated by 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 endpoints. 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 for when
   selecting technologies which rely on IPv4 to supply IPv6 services,
   such as 6RD.
   Also,  Additionally, if native Dual Stack is considered by the
   operator, challenges
   on the related to IPv4 path is also of address exhaustion remain a
   concern.

   Some operators may be able to reclaim some small amounts IPv4 addresses
   through
   efficiency addressing efficiencies in the network, although this will
   have little lasting benefits to the network and the replacement of globally-unique IPv4
   assignments with private addresses [RFC1918].  These measures are
   tactical and do are not long meet longer term strategic options.
   connectivity needs.  The lack of new global IPv4 addresses 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 the operationalization of IPv6.
   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 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.  DS-Lite is one such
   technology [RFC6333] and
   NAT64 are both technologies which requires IPv6 to support IPv4.
   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 may be needed 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,
   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, understand its relevance to the IP Service
   offering, how it operates and how to troubleshoot it - the deployment
   is maturing.  This fact should not incline an operator operators to delay their
   IPv6 deployment, but should drive them to deploy IPv6 sooner to gain
   the 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 which has 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 of their network the then work outward towards
   the customer edge.

3.4.  Service Management

   Services are managed within most networks and are often based on the
   gleaning and monitoring of IPv4 addresses. addresses assigned to endpoints.

   Operators will need to address such management tools, troubleshooting
   methods and storage facilities (such as databases) to deal with not
   just a new address type containing 128-bits, a 128-bit IPv6 address, but often
   both IPv4 and IPv6 at the same time.  Examination of address type,
   and recording delegated prefixes along with single addresses, address
   assignments, will likely require additional development.

   With any Dual Stack service - whether Native, 6RD based, DS-Lite
   based DS-Lite,
   NAT64 or otherwise - two address families may need to be managed
   simultaneously to help provide for the full Internet experience.
   This would indicate that IPv6 management is not just an 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 un-
   monitored and impairments undetected.

   These issues may be of consideration when selecting technologies
   which require IPv6 as the base protocol to delivery IPv4. IPv4
   connectivity.  Instability on the IPv6 service in such a case would
   impact IPv4 services.

3.5.  Sub-Optimal Operation of Transition Technologies

   When contrasting native Dual Stack versus other transition
   technologies it should be noted that 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 removing many network efficiencies built for native
   IP flows.  Tunnelling and translation devices may not be located on
   the most optimal path in line with natural traffic flow (based on
   route computation) and therefore may increase latency.  These paths
   may also add additional points of failure.

   To minimize risk, an operator should use transition technologies for
   the lesser-used less dominant address family if possible.  During earlier phases
   of transition, IPv4 traffic volumes may still be dominant, so
   tunnelling of IPv6 traffic is reasonable.  Over time, as IPv6 traffic
   volumes will increase, native delivery of IPv6 traffic becomes
   advantageous.  When IPv4 connectivity demands diminish, translation
   and tunnelling of IPv4 over IPv6 may be acceptable and more optimal.

   When IPv6 tunnelling is used, an operator may not want to enable IPv6
   for their services, especially high traffic services. services like high
   quality IP video.  Likewise, if CGN is deployed, the operator may
   wish to promote native IPv6 access. access for these services.

3.6.  Future IPv6 Network

   An operator should also be aware that longer term plans may include
   IPv6-only operation in all or much of the network.  This longer term
   view may be distant to some, but should be considered when planning
   out networks, addressing and services.  The needs and costs of
   maintaining two IP stacks will eventually become burdensome and
   simplification will be required. desirable.  The operators should plan for this
   state and not make IPv6 inherently dependant dependent on IPv4 as this would
   unnecessarily constrain an operator. the network.

4.  IPv6 Transition Technology Analysis

   Operators should understand the main transition technologies for IPv6
   deployment and IPv4 runout.  This draft 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 access, Wireless
   or infrastructure support.

   The technologies in focus for this document are targeted on those
   commercially available and in deployment.

4.1.  Automatic Tunnelling using 6to4 and Teredo

   Even when operators may not be actively deploying IPv6, automatic
   mechanisms exist on customer 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 provides
   guidelines on how to improve it's performance.  An Operator may want
   to provide local relays for 6to4 and/or Teredo to help improve the
   protocol's performance for ambient traffic utilizing these IPv6
   connectivity methods.  Experiences such as those described in
   [I-D.jjmb-v6ops-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 address addresses are used for NAT444/CGN 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 usecase
   is likely to occur if any space other than [RFC1918] is used,
   including Shared
   CGN Address Space [I-D.weil-shared-transition-space-request] [RFC6598] or space registered to
   another organization (squat space).  The operator can use 6to4-PMT

   [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] or attempt to
   block 6to4 operation entirely by blocking the ancycast ranges
   associated with [RFC3068].

4.2.  Carrier Grade NAT (NAT444)

   Carrier Grade NAT (GGN), specifically as deployed in a NAT444
   scenario [I-D.ietf-behave-lsn-requirements], may prove beneficial for
   those operators who offer Dual Stack services to customer 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], but will often may be necessary for a time. depending on how an operator
   has chosen to deal with IPv6 transition and legacy IPv4 connectivity
   requirements.

   In a network where IPv4 address availability is low, CGN based on
   NAT444 CGN/NAT444, may
   provide continued access to IPv4 endpoints.  Other
   technologies (4rd, IVI) may also be used in place of the NAT444 model
   with CGN.  Some of the advantages
   of using CGN using NAT444 CGN/NAT444 include the similarities in provisioning and
   activation of models.  IPv4 hosts in a CGN/NAT444 deployment will likely
   inherent the same addressing and are
   part of current network and operational management procedures for managing such as legacy
   IPv4, globally addressed hosts or CPEs (i.e.  DHCPv6, DNSv4, TFTP, TR-069
   etc).

4.3.  6RD

   6RD [RFC5969] does provide provides a quick and effective way to deliver of offering IPv6
   services connectivity to
   customer endpoints when native IPv6 addressing on the access network
   is not yet possible. 6RD provides tunnelled connectivity for IPv6
   over the existing IPv4 path.  As the access edge is upgraded and
   customer premise equipment is replaced, 6RD can be superseded replace by native
   IPv6 access. connectivity. 6RD can be delivered along side over top a CGN/NAT444
   deployment, but this would cause all traffic to be subject to some
   type of transition technology.

   6RD may also be advantageous during the early transition while IPv6
   traffic volumes are low.  During this period, the operator can gain
   experience with IPv6 on the core and improve their peering framework
   to match those of the IPv4 service. 6RD scales easily by adding
   relays.  As IPv6 traffic volume grows, the operator can gradually
   replace 6RD with native IPv6.

   6RD client support is required, but most currently deployed CPEs do
   not have 6RD client functionality built into them and may not be
   upgradable. 6RD deployments would most likely require the replacement
   of relays to
   the home CPE.  An operator's network.  Another advantage of for 6RD in the early stages of
   transition is that the WAN side interface
   operator does not need a DHCPv6 address assignment infrastructure and
   and does not need to implement
   IPv6 to function correctly which may make it easier to deploy support IPv6 routing to
   field hardware which the CPE to support a
   delegated prefix (as it's derived from the IPv4 address and other
   configuration parameters).

   Client support is restricted in memory footprint, processing
   power required for 6RD operation and storage space. may not be available
   on deployed hardware. 6RD deployments may require the customer or
   operator to replace the CPE. 6RD will also require parameter
   configuration which can be powered by the operator through DHCPv4,
   manually provisioned on the CPE or automatically 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 which is
   already used in many existing IPv6 deployments.  Native Dual Stack
   does however require that Native IPv6 be delivered to the customer
   premise.  This technology option is desirable in many cases and can
   be used immediately if the access network and customer premise
   equipment supports native IPv6.

   An operator who runs out of IPv4 addresses to assign to customers
   will not be able to provide traditional native Dual Stack. Stack
   connectivity for new customers.  In cases 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 network to support IPv6.  Other systems like DHCP, DNS, and
   diagnostic/management facilities need to be upgraded to support IPv6. IPv6
   as well.  The upgrade of such systems may often be non-trivial. non-trivial and
   costly.

4.5.  DS-Lite

   Dual-Stack Lite (DS-Lite, [RFC6333]) is based on an a native IPv6
   service delivery
   connection model where IPv4 services are supported.  DS-Lite provides
   tunnelled connectivity for IPv4 over the IPv6 path between the
   customer's network device and a provider managed gateway (AFTR).

   DS-Lite can only be used where there is native IPv6 connectivity connection
   between the AFTR and the customer premise endpoint. 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.  Early  During the early transition
   stages may also occur when period a
   significant about amount of content and services are delivered over the legacy IPv4 path. 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. time given the potential
   impact.  The provider operator may also want to make sure that most of their
   internal services and a significant about of external content is
   available over IPv6 before deploying DS-Lite.  The availability of
   services on IPv6 would help lower the demand on the AFTRs.

   By sharing IPv4 addresses among multiple endpoints, like CGN/NAT444,
   DS- Lite
   DS-Lite can facilitate continued support of legacy IPv4 services even
   after IPv4 address run out.  There are some functional considerations
   to
   consider event take into account even with DS-Lite such as those described in
   [draft-donley-nat444-impacts].

   Similar to 6RD,

   [I-D.donley-nat444-impacts] and [I-D.ietf-softwire-dslite-
   deployment].

   DS-Lite requires client support on the CPE to function.  Client functionality is likely  The ability
   to utilize DS-Lite will be more prevalent in dependent on the
   future as IPv6 operator providing DS-
   Lite capable (WAN side) CPEs begin to penetrate the market.
   This includes both or retail and operator provided gateways. availability of the supported client for
   customer acquired endpoints.

4.6.  NAT64

   NAT64 [RFC6146] provides the ability to connect IPv6-only connected
   clients and hosts to IPv4 servers without any tunnelling.  NAT64
   requires that the host and home network supports IPv6-only modes of
   operation.  All IPv6-capable equipment scenarios are  Home networks do not considered
   typical in most traditional Wireline hosted customer networks, are
   are commonly contain equipment which is
   all IPv6-capable.  It is also not likely to anticipated that common home
   networks will be so in the near future. ready for IPv6-only operation for a number of years.
   However, IPv6-only networking can be deployed by early adopters or
   highly controlled networks.

   Viability of NAT64 will increase in Wireline networks as consumer
   equipment is replaced by IPv6 capable versions.  There are incentives
   for operators to move to IPv6-only operation, when feasible, which
   includes the simplicity of a single stack access network.

5.  IPv6 Transition Phases

   The Phases described in this document are not provided as a rigid set
   of steps, but are considered a guideline which should be analyzed by
   an operator
   operators planning their IPv6 transition.  Operators may choose to
   skip steps based on technological capabilities within their specific
   networks.
   networks, (residential/corporate, fixed/mobile), their business
   development perspectives (which may affect the pace of migration
   towards full IPv6), or a combination thereof.

   The phases are based on an 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 volume volumes
   will correspondingly decrease, until IPv6 is the predominant address
   family used.  For each phase, the predominant address family should
   be native, while mediation (tunnelling or translation)  Operators may be
   acceptable want to keep the traffic flow for address family which generates the lower amount
   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
   volume on the network. transition
   should also be compared against the cost of changing and upgrading
   customer connections.

   Additional guidance and information on utilizing IPv6 transition
   mechanisms can be found in [RFC6180].  Also, guidance on incremental
   CGN for IPv6 transition can also 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 - IPv6.  To properly deal with these impending or
   current challenges organizations must train their staff on IPv6.

   Training should also be provided within reasonable timelines from the
   actual IPv6 deployment.  This means the operator needs to plan in
   advance as they train the various parts of their 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 staff who support the network and other systems
   need to be trained closer to the deployment timeframes, so they
   immediately use their new-found knowledge before forgetting.

   Customer support staff would require much more basic but large scale
   training since many organizations have massive call centres to
   support the customer base.  Tailored training will also be required
   for marketing and sales staff to help them understand IPv6 and build
   it into the product development and sales process.

5.1.2.  Phase 0 - Foundation: Routing

   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 number of several ways
   including the number of addresses which are made available, careful
   attention to a scalable and manageable architecture needs to be made.
   Also, given that home network environments will no longer receive
   One such change is the notion of a
   token delegated prefix which deviates
   from the common single address as is common phenomenon in IPv4, operators will need to
   understand IPv4-only deployments.
   Deploying prefixes per CPE can load the impacts of delegating routing tables and require a large sum of addresses
   (prefixes)
   routing protocol or route gleaning to consumer endpoints. manage connectivity to the
   customer's network.  Delegating prefixes can be of specific
   importance in access network environments where downstream customers
   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).

5.1.3.  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 they are of consideration and should be
   addressed when delivering IPv6 services.  Other IETF documents
   ([RFC4942], such
   as [RFC4942], [RFC6092], [RFC6169], for instance) and [RFC6169] are excellent resources.

5.1.4.  Phase 0 - Foundation: Transition Architecture

   The operator 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.  If  Should the operator should want to use consider
   multiple technologies like CGN/NAT444, DS-Lite DS-Lite, NAT64 and 6RD, they
   may want to plan out where network resident equipment may be located
   and potentially choose locations which can be used for all three functional
   roles (i.e. placement of NAT44 translator, AFTR AFTR, NAT64 gateway and
   6RD relays).  This would allow for the least disruption as the operator
   evolves  Although these functions are not inherently connected,
   additional management, diagnostic and monitoring functions can be
   deployed along side the transition environment to meet hardware without the needs need to
   distribute these to an excessive or divergent number of the customer
   base. locations.

   This approach may also prove beneficial if traffic patterns change
   rapidly in the future and as the operator operators may need to evolve their
   transition infrastructure faster than originally anticipated.  Once
   such example may be the movement from a CGN/NAT44 model (dual stack)
   to DS-Lite.  Since both traffic sets require a translation function
   (NAT44), synchronized pool management, routing and management system
   positioning can allow rapid movement (notwithstanding the
   technological means to re-provision the customers).

   Operators should inform their vendors of what technologies they plan
   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 customer premise equipment.

   The operator should also plan their overall strategy to meet the
   target needs of an IPv6-only deployment.  Over time, IPv4 maintenance
   will become cumbersome so support and an operator may want  As traffic moves to remove
   it from IPv6,
   the access connectivity portion benefits of their network. only a single stack on the access network may justify
   the removal of IPv4 for simplicity.  Planning for this eventual stage,
   model, no matter how far off this may be, will help the operator
   embrace this end state when needed.

5.1.5.  Phase 0- Foundation: Tools and Management

   The operator should thoroughly analyze all provisioning and
   operations
   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 (PD) and the ability to detect either or both
   address families when determining if a customer has full Internet
   service.

   If an operator stores usage information, this would need to be
   aggregated to include both the IPv4 and IPv6 traffic flows.  Also,
   tools that verify connectivity may need to query the IPv4 and IPv6
   addresses.

5.2.  Phase 1 - Tunnelled IPv6

   Tunnelled access to IPv6 offers a viable can be regarded as an early stage transition
   option to 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 customer edge device.  During
   this period of time, tunnelled access to IPv6 is a viable alternative
   to native IPv6.  It is also possible that operators my be rolling out
   IPv6 natively to the customer edge but the time involved may be long
   due to logistics and other factors.  Even while slowly rolling out
   native IPv6, operators can deploy relays for automatic tunnelling
   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 behaviours from than 6RD [RFC3484].
   Additional guidelines on deploying and supporting 6to4 can be found
   in [RFC6343].

   The operator can deploy 6RD relays easily into the network and scale them as
   needed to meet the early customer needs of IPv6.  Since 6RD requires
   the upgrade or replacement of CPE gateways, devices, the operator may want
   ensure that the gateways CPE devices support not just 6RD but native Dual
   Stack and other tunnelling technologies if possible such as DS-Lite.
   6RD clients are becoming available in some retail channel products
   and within the 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).

                                       +--------+         -----
                                       |        |       /       \
                       Encap IPv6 Flow |  6RD   |      |  IPv6   |
                                - - -> |  BR    | <- > |   Net   |
          +---------+         /        |        |       \       /
          |         |        /         +--------+         -----
          |   6RD   + <-----                              -----
          |         |                                   /       \
          |  Client |         IPv4 Flow                |  IPv4   |
          |         + < - - - - - - - - - - - - - - -> |   Net   |
          |         |                                   \       /
          +---------+                                     -----

                         Figure 1: 6RD Basic Model

   6RD used as an initial phase transition technology also provides the added
   benefit of a deterministic IPv6 prefix which is 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
   customer host/CPE. CPE.  So a simple tool and/or method can be built to help
   the operational staff in an organization know that the IPv6 prefix is
   for a 6RD serviced CPE based on knowledge of the IPv4 address.

   An operator may choose to not offer internal services over IPv6 if
   tunnelled access to IPv6 is used since some services generate a large
   amount of traffic.  This mode of operation should avoid  Such traffic may include Video content like IPTV.
   By limiting how much traffic is delivered over the need to
   greatly increase 6RD connection (if
   possible), the scale operator can avoid costly and complex scaling of the 6RD Relay environment.
   relay infrastructure.

5.2.1.  6RD Deployment Considerations

   Deploying 6RD can greatly speed up an operator's ability to support
   IPv6 to the customer network.  Consider by whom the system would network if native IPv6 connectivity cannot be
   deployed, provisioned, scaled and managed.
   supplied.  The speed at which 6RD can be deployed is highlighted in
   [RFC5569].

   The first core consideration is deployment models. 6RD requires the
   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 here 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.  Use of specific multiple
   relay addresses can help provide more control but has the
   disadvantage of being more complex to provision as subsets of CPEs
   across the network will require and contain different relay
   information.  An alternative approach is to use a hybrid model using
   multiple anycast service IPs for clusters of 6RD relays should the
   operator anticipate massive scaling of the environment.  This way,  Thus, the
   operator has multiple vectors by which to scale the service.

                                              +--------+
                                              |        |
                                IPv4 Addr.X   |  6RD   |
                                     - - - >  |   BR   |
               +-----------+        /         |        |
               | Client A  | <- - -           +--------+
               +-----------+
                             Separate IPv4 Service Addresses
               +-----------+
               | Client B  | < - -            +--------+
               +-----------+       \          |        |
                                     - - - >  |  6RD   |
                                IPv4 Addr.Y   |   BR   |
                                              |        |
                                              +--------+

             Figure 2: 6RD Multiple IPv4 Service Address Model

                                            +--------+
                                            |        |
                              IPv4 Addr.X   |  6RD   |
                                   - - - >  |   BR   |
             +-----------+        /         |        |
             | Client A  |- - - -           +--------+
             +-----------+
                       Common (Anycast) IPv4 Service Addresses
             +-----------+
             | Client B  | - - -            +--------+
             +-----------+       \          |        |
                                   - - - >  |  6RD   |
                              IPv4 Addr.X   |   BR   |
                                            |        |
                                            +--------+

             Figure 3: 6RD Anycast IPv4 Service Address Model

   Provisioning of the endpoints is affected by the deployment model
   chosen (i.e. anycast vs. specific service IPs).  Using multiple IPs
   may require more planning and management as customer equipment will
   have different sets of data to be provisioned into the devices.  The
   operator may use DHCPv4, manual provisioning or other mechanisms to
   provide parameters to customer 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 counted on the operator edge, but if it requires source/
   destination flow details, data must be collected after the 6RD relay
   (IPv6 side of connection).

       +---------+  IPv4 Encapsulation  +------------+
       |         +- - - - - - - - - - - +            |
       |   6RD   +----------------------+     6RD    +---------
       |         |   IPv6 Packet        |    Relay   | IPv6 Packet
       | Client  +----------------------+            +---------
       |         +- - - - - - - - - - - +            |      ^
       +---------+  ^                   +------------+      |
                    |                                       |
                    |                                       |
                IPv4 IP (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 "Tunnelled IPv6" or as an initial
   step, the operator may deploy native IPv6 down to the customer premise. CPEs.  This
   phase would then allow for both IPv6 and IPv4 to be natively accessed
   by the customer home gateway/CPE. network without translation or tunnelling.  The
   native Dual Stack phase can be rolled out across the network while
   the tunnelled IPv6 service remains running, operational, if used.  As areas
   begin to support native IPv6, customer home equipment can be set to use it in place of
   technologies like 6RD.  Hosts using 6to4 and/or Teredo will
   automatically generally
   prefer [RFC3484] using the IPv6 address delivered via native addresses derived from the delegated IPv6 (assumed to be a Delegated Prefix
   prefix versus tunnelling options such as per [RFC3769]). 6to4, 6RD and Teredo as
   defined in [RFC3484]

   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.

5.3.1.  Native Dual Stack Deployment Considerations

   Native Dual Stack is a a very desirable option for the IPv6
   transition. transition
   if feasible.  The operator must enable IPv6 on the network core and
   peering edge before they attempt to turn on native IPv6 services.
   Additionally, provisioning and support systems such as DHCPv6, DNS
   and other functions which support the customer's IPv6 Internet
   connection need to be in place.

   The operator must treat IPv6 connectivity as seriously with the same operational
   importance as IPv4.  Poor IPv6 service may be worse than not offering
   an IPv6 service at all, since users may disable IPv6, which will be difficult for the
   operator cause users to reverse. disable IPv6
   and negatively impact their Internet experience.  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
   IA_PDs), but installation and propagation of routing information for
   the prefix, especially during access layer instability, is often
   poorly understood.  The Operator should develop processes for
   renumbering customers who they move to new Access nodes.

   Operators need to keep track of both the dynamically assigned IPv4
   and
   address along with the IPv6 addresses. address and prefix.  Any additional
   dynamic elements, such as auto-
   generated DNS auto-generated host names, need to be
   considered and planned for.

5.4.  Intermediate Phase for CGN

   At some point during the first two phases, acquiring

   Acquiring more IPv4 addresses may become challenging or is already challenging, if not
   impossible, therefore CGN/NAT444 address sharing may be required on the IPv4
   path.  The operator may have a preference to move directly to a more
   efficient way of IPv4 address shared sharing such as DS-LIte, DS-Lite, but conditions
   may dictate that CGN/NAT444 is the only workable option.  CGN  CGN/NAT444
   is less optimal and should be used cautiously in a 6RD deployment (if
   used with 6RD to a given endpoint) since all traffic must transverse traverse
   some type of operator service node (relay and translator).

                                       +--------+         -----
                                       |        |       /       \
                             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 a IPv6+CGN/NAT444 model the
   native IPv6 path is available for higher quality connectivity helping
   host operation over the network while the CGN path may offer a less
   then
   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 CGN Address Space [I-D.weil-shared-
   transition-space-request]. [RFC6598].  It is also
   possible that operators may use part of their own RIR assigned
   address space for CGN zone addressing if RFC918 [RFC1918] addresses pose
   technical challenges in their network.  It is not recommended that
   operators use squat space as it may pose additional challenges with
   filtering and policy control. control,

5.4.1.  CGN Deployment Considerations

   CGN is often considered undesirable by operators but required in many
   cases.  An operator who needs to deploy CGN services capabilities should
   consider
   it's the impacts of the function to 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
   also be needed at low scale at first and grown to meet future the demands
   based on traffic and connection dynamics of the customer, content and
   network peers.

   The operator may want to deploy CGNs more centrally at first and then
   scale the system as needed.  This approach can help conserve costs of
   the system and only spend money on equipment with based on the actual
   growth of traffic (demand on CGN system).  The operator will need a
   deployment model and architecture which allows 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
   [draft-sivakumar-behave-nat-logging].
   [I-D.sivakumar-behave-nat-logging].  This logging may require
   significant investment in external systems which ingest, aggregate
   and report on such information
   [draft-donley-behave-deterministic-cgn]. [I-D.donley-behave-deterministic-cgn].

   Since CGN has noticeable impacts on some certain applications
   [draft-donley-nat444-impacts], [I.D.donley-
   nat444-impacts], operators may deploy CGN only for those customers
   who do may not use affected applications.  Affected
   customers could likely be selected by observing usage, or affected by offering CGN
   and Native IPv4 for different prices. (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 customer endpoints.  During this final
   phase, IPv4 connectivity may or may not need to be supported
   depending on the conditions of the network and customer demand.  If
   legacy IPv4 connectivity is still demanded, DS-Lite may be used to
   tunnel the traffic.  If IPv4 connectivity is not required, but access
   to legacy IPv4 content is only required, , then NAT64 can be used as well or
   as a follow-up to DS-Lite. used.

   DS-Lite allows continued access for the IPv4 customer base using
   address sharing for IPv4 Internet connectivity, but with only a
   single layer of translation, compared to CGN/NAT444.  This mode of
   operation also removes the need to directly address customer
   endpoints with an IPv4 address simplifying the connectivity to the
   customer (single address family) and supporting IPv6 only addressing
   to the CPE.

   The operator can also move Dual Stack endpoints to DS-Lite
   retroactively to reclaim help optimize the IPv4 addresses for redeployment or general
   simplification of address sharing deployment by
   removing the IPv4 address assignment and routing domain. 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

   If the operator was forced decided to enable CGN for a NAT444 CGN/NAT444 deployment, they may
   be able to co-locate the AFTR and CGN CGN/NAT444 processing functions
   within the a common network location to simplify capacity management and
   the engineering of flows.
   DS-Lite however requires configuration of the CPE  This case may be evident in a later
   transition stages when an operator chooses to optimize their network
   and the
   implementation of the AFTR. IPv6-only operation is feasible.

5.5.1.  DS-Lite Deployment Considerations

   The same deployment considerations associated with Native IPv6
   deployments apply to DS-LIte. DS-LIte and NAT64.  IPv4 will now be dependent
   on IPv6 service quality, so the IPv6 network and service services must be
   running well to ensure a quality experience for the end customer.
   Tools and processes will be needed to manage the encapsulated IPv4
   service.  If flow analysis is required for IPv4 traffic, this should
   be enabled at a point beyond the AFTR (after de-capsulation).

     +---------+  IPv4 Encapsulation  +------------+
     |         + - - - - - - - - - - -+            |
     |  AFTR   +----------------------+    AFTR    +---------
     |         |   IPv4 Packet        |            | IPv4 Packet
     | Client  +----------------------+            +---------
     |         + - - - - - - - - - - -+            |      ^
     +---------+  ^                   +------------+      |
                  |                                       |
                  |                                       |
           IPv6 IP (Tools/Mgmt)               IPv4 Packet Flow Analysis

                 Figure 9: DS-Lite Tools and Flow Analysis

   DS-Lite also requires client support.  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.

5.5.2.  NAT64 Deployment Considerations

   The deployment of NAT64 assumes the network assigns an IPv6 addresses
   to an network endpoint which are translated to IPv4 addresses to
   provide connectivity to IPv4 Internet services and content.
   Experiments such as the one described in [RFC6586] highlight issues
   related to IPv6-only deployments due to legacy IPv4 APIs and IPv4
   literals.  Many of these issues will be resolved by the eventual
   removal this undesired legacy behaviour.  In the short term,
   technology options include the 464xlat [I-D.ietf-v6ops-464xlat] model
   which helps managed legacy IPv4 calls.  Operational deployment models
   and experiences related to NAT64 have been documented in [I-D.chen-
   v6ops-nat64-experience].

   As the support for IPv6 increased within content and network
   endpoints, the more efficient the IPv6-Only model becomes with NAT64.

   The NAT64 deployment would see an overall declined in usage as more
   traffic is promoted to IPv6 to IPv6 native communication.  NAT64 may
   play an important part of an operators late stage transition as it
   removes the need to support IPv4 on the access network and provides a
   solid go-forward networking model.

6.  IANA Considerations

   No IANA considerations are defined at this time.

7.  Security Considerations

   No Additional Security Considerations are made in this document.

8.  Acknowledgements

   Special thanks to Wes George George, Christian Jacquenet and John Brzozowski
   for their extensive review and comments.

   Thanks to the following people for their textual contributions and/or
   guidance on IPv6 deployment considerations: Jason Weil, Gang Chen,
   Nik Lavorato, John Cianfarani, Chris Donley, and Tina TSOU.

9.  References

9.1.  Normative References

   [RFC6180]  Arkko, J. and F. Baker, "Guidelines for Using IPv6
              Transition Mechanisms during IPv6 Deployment", RFC 6180,
              May 2011.

9.2.  Informative References

   [I-D.chen-v6ops-nat64-experience]
              Chen, G., Cao, Z., Byrne, C., and Q. Niu, "NAT64
              Operational Experiences",
              draft-chen-v6ops-nat64-experience-01 (work in progress),
              March 2012.

   [I-D.donley-behave-deterministic-cgn]
              Donley, C., Grundemann, C., Sarawat, V., and K.
              Sundaresan, "Deterministic Address Mapping to Reduce
              Logging in Carrier Grade NAT Deployments",
              draft-donley-behave-deterministic-cgn-02 (work in
              progress), March 2012.

   [I-D.donley-nat444-impacts]
              Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. Colorado, U., and V. Kuarsingh,
              "Assessing the Impact of Carrier-Grade NAT on Network
              Applications", draft-donley-nat444-impacts-03 (work in
              progress), November 2011.

   [I-D.ietf-behave-lsn-requirements]
              Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
              and H. Ashida, "Common requirements for Carrier Grade NATs
              (CGNs)", draft-ietf-behave-lsn-requirements-05 draft-ietf-behave-lsn-requirements-06 (work in
              progress), November 2011.

   [I-D.ietf-v6ops-v4v6tran-framework]
              Carpenter, B., Jiang, S., May 2012.

   [I-D.ietf-softwire-dslite-deployment]
              Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and V. Kuarsingh, "Framework M.
              Boucadair, "Deployment Considerations for
              IP Version Transition Scenarios",
              draft-ietf-v6ops-v4v6tran-framework-02 Dual-Stack
              Lite", draft-ietf-softwire-dslite-deployment-03 (work in
              progress),
              July 2011. March 2012.

   [I-D.ietf-v6ops-464xlat]
              Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
              Combination of Stateful and Stateless Translation",
              draft-ietf-v6ops-464xlat-03 (work in progress), May 2012.

   [I-D.jjmb-v6ops-comcast-ipv6-experiences]
              Brzozowski, J. and C. Griffiths, "Comcast IPv6 Trial/
              Deployment Experiences",
              draft-jjmb-v6ops-comcast-ipv6-experiences-02 (work in
              progress), October 2011.

   [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel]
              Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider
              Managed Tunnels",
              draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-04
              draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-05
              (work in progress), September 2011.

   [I-D.weil-shared-transition-space-request]
              Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
              M. Azinger, "IANA Reserved IPv4 Prefix for Shared Address
              Space", draft-weil-shared-transition-space-request-14 February 2012.

   [I-D.sivakumar-behave-nat-logging]
              Sivakumar, S., "Logging of NAT Events",
              draft-sivakumar-behave-nat-logging-03 (work in progress), January 2012.
              October 2011.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [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.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC3769]  Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
              Delegation", RFC 3769, June 2004.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              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.

   [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.

   [RFC6586]  Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
              Network", RFC 6586, April 2012.

   [RFC6598]  Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
              M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
              Space", BCP 153, RFC 6598, April 2012.

Authors' Addresses

   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