[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-kuarsingh-wireline-incremental-ipv6) 00 01 02 03 04 05 06 RFC 6782

v6ops                                                  V. Kuarsingh, Ed.
Internet-Draft                                     Rogers Communications
Intended status: Informational                                 L. Howard
Expires: May 30, 2012                                  Time Warner Cable
                                                       November 27, 2011


                       Wireline Incremental IPv6
             draft-ietf-v6ops-wireline-incremental-ipv6-00

Abstract

   Operators worldwide are in various stages of preparing for, or
   deploying IPv6 into their networks.  The operators often face
   challenges related to both IPv6 introduction along with a growing
   risk of IPv4 run out within their organizations.  The overall problem
   for many operators will be to meet the simultaneous needs of IPv6
   connectivity and continue support for IPv4 connectivity for legacy
   devices and systems with a depleting supply of IPv4 addresses.  The
   overall transition will take most networks from an IPv4-Only
   environment to a dual stack network environment and potentially an
   IPv6-Only operating mode.  This document helps provide a framework
   for Wireline providers who may be faced with many of these challenges
   as they consider what IPv6 transition technologies to use, how to use
   the selected technologies and when to use them.

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 May 30, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Kuarsingh & Howard        Expires May 30, 2012                  [Page 1]


Internet-Draft          Wireline Incremental IPv6          November 2011


   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        Expires May 30, 2012                  [Page 2]


Internet-Draft          Wireline Incremental IPv6          November 2011


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












Kuarsingh & Howard        Expires May 30, 2012                  [Page 3]


Internet-Draft          Wireline Incremental IPv6          November 2011


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 efficient IPv6/IPv4 dual stack environment.  Some plans may
   also include IPv6-Only end state targets, but there is not clear
   consensus on how long IPv4 support is required, and IPv6-Only
   generally means withdrawing IPv4 mechanisms.  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 including 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 the 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 show how
   well defined technologies such as 6RD [RFC5969], DS-Lite [RFC6333]
   and Carrier Grade NAT (NAT44 without tunnelling as distinct from DS-
   Lite) used with native dual stack to deliver effective IPv4 and IPv6
   services in an evolving wireline network.


2.  Operator Assumptions

   For the purposes of this document, assume:

      - The operator is considering deploying IPv6

      - The operator has a legacy IPv4 customer base which will continue
      to exist

      - The operator will want to minimize the level of disruption to
      the existing and new customers by minimizing 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 to transition their own services to support IPv6

   Based on these assumptions, an operator will want to use technologies
   which minimize the number of flows being tunnelled, translated or
   intercepted at any given time.  Technology selections would be made
   to manage the non dominant flows and allow Native IP routing (IPv4
   and/or IPv6) for the dominant traffic.  This allows the operator to



Kuarsingh & Howard        Expires May 30, 2012                  [Page 4]


Internet-Draft          Wireline Incremental IPv6          November 2011


   minimize the cost of IPv6 transition technologies by containing the
   scale required by the relevant systems.


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.  A phased approach addresses many
   challenges:

      - IPv4 exhaustion may occur long before most traffic is able to
      delivered over IPv6

      - IPv6 will pose operational challenges, since much of the
      software, and in some cases the hardware to run it at scale, will
      be new.  Further, the operational processes will be relatively new

      - Connectivity modes will move from single stack to dual stack in
      the Home Changing functional behaviours in the home network add
      complexity to user support

   These challenges will likely occur over time which means the
   operator's plans need to address the every 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 various phases.

3.1.  Relevance of IPv6 and IPv4

   Over the next few years, both IPv4 and IPv6 will play a role in the
   Internet experience.  Many customers use older operating systems and
   hardware which support IPv4-Only.  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



Kuarsingh & Howard        Expires May 30, 2012                  [Page 5]


Internet-Draft          Wireline Incremental IPv6          November 2011


   the home network will 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 means that
   growth in demand of IPv4 connections in some networks will be based
   on address sharing.

   Networks are growing at different rates based on emerging markets
   and/or proliferation of Internet based services and endpoints: growth
   on the Internet will continue.  IPv4 address constraints will likely
   affect many if not most operators at some point.  IPv4 exhaustion is
   a primary consideration for technologies which rely on IPv4 to supply
   IPv6 services, such as 6RD.  Also, if Native Dual Stack is considered
   by the operator, challenges on the IPv4 path is also of concern.

   Some operators may be able to reclaim some IPv4 addresses through
   efficiency in the network and replacement of globally-unique IPv4
   assignments with private addresses [RFC1918].  These measures are
   tactical and do not support a longer term strategic option.  The lack
   of new IPv4 addresses 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 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 instability, and Operators
   should consider this when selecting technologies for early
   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, which requires IPv6
   to support IPv4.

   Further, some of these technologies are new and require refinement
   within running code and support.  Deployment experience may be needed
   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



Kuarsingh & Howard        Expires May 30, 2012                  [Page 6]


Internet-Draft          Wireline Incremental IPv6          November 2011


   DHCPv6, Management Tools, Monitoring Systems, Diagnostic systems,
   along with other systems.

   Although the base technological capabilities exist to enable and run
   IPv6 in most environments, it may not be as robust as IPv4, and 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 - it's still
   maturing.

3.4.  Service Management

   Services are managed within most networks and are often based on the
   gleaning and monitoring of IPv4 addresses.  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, but often both IPv4 and IPv6 at the same
   time.  Examination of address type, and recording CIDR blocks instead
   of single addresses, may require additional development.

   With any Dual Stack service - whether Native, 6RD based, DS-Lite
   based or otherwise - two address families need to be managed
   simultaneously to help provide for the full Internet experience.  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.
   Instability on the IPv6 service in such case would impact IPv4
   services.

3.5.  Sub-Optimal Operation of Transition Technologies

   When considering native dual-stack versus a transition technology,
   note that native paths are well understood and networks are optimized
   to send traffic efficiently.  Transition technologies may alter the
   normal path of traffic.  Tunnel servers or translation relays may not
   be located on the shortest path, may increase latency, and may add a
   single point of failure.

   To minimize risk, an operator should use transition technologies for
   the lesser-used address family.  During earlier phases of transition,
   IPv6 traffic volumes may be lower, so tunnelling of IPv6 traffic may
   be reasonable.  Over time, these traffic volumes will increase,
   raising the benefits of native delivery of this traffic.  Then, as
   IPv4 content diminishes, translation and tunnelling of IPv4 may be
   acceptable.



Kuarsingh & Howard        Expires May 30, 2012                  [Page 7]


Internet-Draft          Wireline Incremental IPv6          November 2011


   When IPv6 tunnelling is used, an operator may not want to enable IPv6
   for their services, especially high traffic services.  Likewise, when
   CGN is deployed, the operation may wish to promote IPv6 access.


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 options.  This analysis is focused on the
   applicability of technologies to deliver residential services and
   less focused on commercial access 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 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 and provide guidelines on how to manage
   such protocols.  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 are used for CGN 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 is likely to occur if
   any space other than [RFC1918] is used, including Shared CGN Space[I-
   D.weil-shared-transition-space-request] or space registered to
   another organization (squatted space).  The operator can use 6to4-PMT
   [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] or attempt to
   block 6to4 operation entirely by blocking 2002::/16 at its edges.

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



Kuarsingh & Howard        Expires May 30, 2012                  [Page 8]


Internet-Draft          Wireline Incremental IPv6          November 2011


   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 be necessary for a time.

   In a network where IPv4 address availability is low, CGN 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 include the similarities in provisioning and
   activation of IPv4 hosts within a network and operational procedures
   in managing such hosts or CPEs (i.e.  DHCPv6, DNSv4, TFTP, TR-069
   etc).

   When considered in the overall IPv6 transition, CGN may play a vital
   role in the delivery of Internet services.

4.3.  6RD

   6RD [RFC5969] does provide a quick and effective way to deliver IPv6
   services to customers who do not yet support Native. 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 by Native IPv6 access. 6RD can be delivered
   along with CGN, but then no traffic would be native; all traffic
   would be intermediated.

   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 the home CPE.  An advantage of this technology over DS-Lite is
   that the WAN side interface does not need to implement IPv6 to
   function correctly which may make it easier to deploy to field
   hardware which is restricted in memory footprint, processing power
   and storage space. 6RD will also require parameter configuration
   which can be powered by the operator through DHCPv4, 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



Kuarsingh & Howard        Expires May 30, 2012                  [Page 9]


Internet-Draft          Wireline Incremental IPv6          November 2011


   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 to the operator's access network.

   An operator who runs out of IPv4 addresses to assign to customers
   will not be able to provide Native Dual Stack.  For a sub-set of the
   IPv6 Native Customers, operators may include IPv4 through a CGN.

   Delivering Native Dual Stack would require the operator's core and
   access network support IPv6.  Additionally, other systems like
   DHCPv6, DNS, and diagnostic/management facilities need to be upgraded
   to support IPv6.  The upgrade of such systems may often not be
   trivial.

4.5.  DS-Lite

   Dual-Stack Lite (DS-Lite, [RFC6333]) provides IPv4 services to
   customer networks which are only addressed with IPv6.  DS-Lite
   provides tunnelled connectivity for IPv4 over an 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
   between the AFTR and the customer premise endpoint.  This may mean
   that the technology's use may not be viable during early transition.
   The operator may also not want to subject the customers' IPv4
   connection to the IPv6 path.  The provider may also want to make sure
   that most of their internal services, and external content is
   available over IPv6 before deploying DS-Lite.  This would lower the
   overall load on the AFTR devices helping reduce.

   By sharing IPv4 addresses among multiple endpoints, like a CGN, DS-
   Lite can facilitate continued growth of IPv4 services even at runout.
   There are some functional considerations
   [draft-donley-nat444-impacts].

   Similar to 6RD, DS-Lite requires client support on the CPE to
   function.  Client functionality is likely to be more prevalent in the
   future as IPv6 capable (WAN side) CPEs begin to penetrate the market.
   This includes both retail and operator provided gateways.

4.6.  NAT64

   NAT64 [RFC6146] provides the ability to connect IPv6-Only connected
   clients and hosts to IPv4 Servers (or other like hosts).  NAT64
   requires that the host and home network supports IPv6-Only modes of
   operation.  This type of environment is not considered typical in



Kuarsingh & Howard        Expires May 30, 2012                 [Page 10]


Internet-Draft          Wireline Incremental IPv6          November 2011


   most traditional Wireline connections.

   In the future, NAT64 may become more viable for Wireline providers as
   home networking environments support IPv6-Only.  In the meantime, DS-
   Lite provides in-home IPv4 services over an IPv6-Only network (WAN).


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 planning their IPv6 transition.  Operators may choose to
   skip steps based on technological capabilities within their specific
   networks.

   The phases are based on an expectation that IPv6 traffic volume will
   initially be low, and operator staff will gain experience with IPv6
   over time.  As volume of IPv6 increases, IPv4 traffic volume will
   correspondingly decrease, until IPv6 is predominant.  For each phase,
   the predominant address family should be native, while mediation
   (tunnelling or translation) may be acceptable for the smaller traffic
   volume.

   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.
   Since there are likely to be challenges with implementing IPv6 - due
   to immature code on hardware, and the evolution of many applications
   and systems to support IPv6 - organizations must train their staff on
   IPv6.

   Training should also be provided within reasonable timelines from
   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.



Kuarsingh & Howard        Expires May 30, 2012                 [Page 11]


Internet-Draft          Wireline Incremental IPv6          November 2011


   Customer support staff would require much more basic, but large scale
   training as many organizations have massive call centres to support
   the customer base.

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 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 networks environments will no longer receive a
   token single address as is common in IPv4, operators will need to
   understand the impacts of delegating larges sums of addresses
   (prefixes) to consumer endpoints.  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], [RFC6092], [RFC6169], for instance) are excellent
   resources.

5.1.4.  Phase 0 - Foundation: Transition Architecture

   The operator 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 the operator should want to use
   multiple technologies like CGN, DS-Lite and 6RD, they may want to
   plan out where such equipment may be located and potentially choose
   locations which can be used for all three functional roles (i.e.
   placement of NAT44 translator, AFTR and 6RD relays).  This would
   allow for the least disruption as the operator evolves the transition
   environment to meet the needs of the network.  This approach may also
   prove beneficial if traffic patterns change rapidly in the future and
   the operator may need to evolve their network faster than originally
   anticipated.

   Operators should inform their vendors of what technologies they plan
   to support over the course of the transition to make sure the



Kuarsingh & Howard        Expires May 30, 2012                 [Page 12]


Internet-Draft          Wireline Incremental IPv6          November 2011


   equipment is suited to support those modes of operation.  This is
   important for both network gear and customer premise equipment.

5.1.5.  Phase 0- Foundation: Tools and Management

   The operator should thoroughly analyze all provisioning and
   operations systems to develop requirements for each phase.  This will
   include address concepts related to the 128-bit addressing field, 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

   Many network operators can deploy native IPv6 from access edge to
   peering edge fairly quickly.  Others, may want to support IPv6
   services before they can support native IPv6.  During this period of
   time, tunnelled access to IPv6 is a viable alternative to Native
   IPv6.  Even while slowly rolling out native IPv6, operators can
   deploy relays for automatic tunnelling technologies like 6to4 and
   Teredo.  Where native IPv6 is a longer-term project, operators can
   consider 6RD [RFC5969].  Note that 6to4 and Teredo have different
   address selection behaviours from 6RD [RFC3484].  Additional
   guidelines on deploying and supporting 6to4 can be found in
   [RFC6343].

   The operator can deploy 6RD relays easily and scale them as needed to
   meet the early customer needs of IPv6.  Since 6RD requires the
   upgrade or replacement of CPE gateways, the operator may want ensure
   that the gateways support not just 6RD but Native Dual Stack and
   other tunnelling technologies if possible. 6RD clients are now
   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.











Kuarsingh & Howard        Expires May 30, 2012                 [Page 13]


Internet-Draft          Wireline Incremental IPv6          November 2011


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


                         Figure 1: 6RD Basic Model

   6RD used as an initial phase 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.  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 6RD based on knowledge of the IPv4 address.

   An operator may choose to not offer internal services over IPv6 if
   such services generate a large amount of traffic.  This mode of
   operation should avoid the need to greatly increase the scale of the
   6RD Relay environment.

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 be
   deployed, provisioned, scaled and managed.

   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 manage
   the traffic volume among additional relays, since all 6RD traffic
   will find the nearest (in terms of IGP cost) relay.  Use of specific
   addresses can help provide more control but has the disadvantage of
   being more complex to provision as CPEs will contain different
   information.  An alternative approach is to use a hybrid model using
   multiple anycast service IPs for clusters of 6RD relays should the



Kuarsingh & Howard        Expires May 30, 2012                 [Page 14]


Internet-Draft          Wireline Incremental IPv6          November 2011


   operator anticipate massive scaling of the environment.  This way,
   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



Kuarsingh & Howard        Expires May 30, 2012                 [Page 15]


Internet-Draft          Wireline Incremental IPv6          November 2011


   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 to the customer premise.
   This phase would then allow for both IPv6 and IPv4 to be natively
   accessed by the customer home gateway/CPE.  The Native Dual Stack
   phase be rolled out across the network while the tunnelled IPv6
   service remains running.  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 prefer
   [RFC3484] the IPv6 address delivered via Native IPv6 (assumed to be a
   Delegated Prefix as per [RFC3769]).

   Native Dual Stack is the best option, 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 very desirable option for deployment.  The
   operator must enable IPv6 at the network core and peering before they
   attempt to turn on Native IPv6 services.  Additionally, provisioning



Kuarsingh & Howard        Expires May 30, 2012                 [Page 16]


Internet-Draft          Wireline Incremental IPv6          November 2011


   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 as IPv4.  Poor
   IPv6 service may be worse than not offering an IPv6 service at all,
   since users will disable IPv6, which will be difficult for the
   operator to reverse.  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 a new Access nodes.

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

5.4.  Intermediate Phase for CGN

   At some point during the first two phases, acquiring more IPv4
   addresses may become challenging or impossible, therefore CGN may be
   required on the IPv4 path.  The CGN infrastructure can be enabled if
   needed during either phase.  CGN is less optimal in a 6RD deployment
   (if used with 6RD to a given endpoint) since all traffic must
   transverse some type of operator service node (relay and translator).


                                       +--------+         -----
                                       |        |       /       \
                             IPv4 Flow |  CGN   |      |         |
                                - - -> +        + < -> |         |
          +---------+         /        |        |      |         |
          |   CPE   | <- - - /         +--------+      |  IPv4   |
          |---------+                                  |   Net   |
                                                       |         |
          +---------+         IPv4 Flow                |         |
          |   CPE   | <- - - - - - - - - - - - - - - > |         |
          |---------+                                   \       /
                                                          -----


                     Figure 5: Overlay CGN Deployment

   In the case of Native Dual Stack, CGN can be used to assist in



Kuarsingh & Howard        Expires May 30, 2012                 [Page 17]


Internet-Draft          Wireline Incremental IPv6          November 2011


   extending connectivity for the IPv4 path while the IPv6 path remains
   native.  For endpoints operating in a IPv6+CGN 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
   optimal performance.


                                       +--------+         -----
                                       |        |       /       \
                             IPv4 Flow |  CGN   |      |  IPv4   |
                                - - -> +        + < -> |   Net   |
          +---------+         /        |        |       \       /
          |         | <- - - /         +--------+        -------
          |   Dual  |
          |  Stack  |                                     -----
          |   CPE   |         IPv6 Flow                 / IPv6  \
          |         | <- - - - - - - - - - - - - - - > |   Net   |
          |---------+                                   \       /
                                                          -----


                       Figure 6: Dual Stack with CGN

   CGN 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].  It is also possible that operators may
   use part of their own RIR assigned address space for CGN zone
   addressing if RFC918 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.

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 should consider
   it's impacts 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 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 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.




Kuarsingh & Howard        Expires May 30, 2012                 [Page 18]


Internet-Draft          Wireline Incremental IPv6          November 2011


                                       +--------+         -----
                                       |        |       /       \
                                       |  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].  This logging may require
   significant investment in external systems which ingest, aggregate
   and report on such information
   [draft-donley-behave-deterministic-cgn].

   Since CGN has impacts on some applications
   [draft-donley-nat444-impacts], operators may deploy CGN only for
   those customers who do not use affected applications.  Affected
   customers could be selected by observing usage, or by offering CGN
   and Native IPv4 for different prices.

5.5.  Phase 3 - Tunnelled IPv4

   Once Native IPv6 is ubiquitous, and well-supported by tools, staff,
   and processes, an operator may consider Dual-Stack Lite.  DS-Lite
   allows growth of the IPv4 customer base using IPv4 address sharing
   for IPv4 Internet connectivity, but with only a single layer of
   translation, compared to CGN (NAT44).  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).

   The operator can also move IPv4 endpoints (Dual Stack) to DS-Lite
   retroactively to reclaim IPv4 addresses for redeployment.  To
   minimize traffic needing translation, the operator should have
   already moved most content to IPv6 before this phase.



Kuarsingh & Howard        Expires May 30, 2012                 [Page 19]


Internet-Draft          Wireline Incremental IPv6          November 2011


                                        +--------+      -----
                                        |        |    /       \
                        Encap IPv4 Flow |  AFTR  |   |  IPv4   |
                                 -------+        +---+   Net   |
           +---------+         /        |        |    \       /
           |         |        /         +--------+      -----
           | DS-Lite +-------                           -----
           |         |                                /       \
           |  Client |         IPv6 Flow             |  IPv6   |
           |         +-------------------------------|   Net   |
           |         |                                \       /
           +---------+                                  -----

                       Figure 8: DS-Lite Basic Model

   If the operator was forced to enable CGN for a NAT444 deployment,
   they may be able to co-locate the AFTR and CGN functions within the
   network to simplify capacity management and the engineering of flows.
   DS-Lite however requires configuration of the CPE and the
   implementation of the AFTR.

5.5.1.  DS-Lite Deployment Considerations

   The same deployment considerations associated with Native IPv6
   deployments apply to DS-LIte.  IPv4 will now be dependent on IPv6
   service quality, so the IPv6 network and service 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



Kuarsingh & Howard        Expires May 30, 2012                 [Page 20]


Internet-Draft          Wireline Incremental IPv6          November 2011


   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.


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

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


9.  References

9.1.  Normative References

   [I-D.ietf-v6ops-v4v6tran-framework]
              Carpenter, B., Jiang, S., and V. Kuarsingh, "Framework for
              IP Version Transition Scenarios",
              draft-ietf-v6ops-v4v6tran-framework-02 (work in progress),
              July 2011.

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

9.2.  Informative References

   [I-D.donley-nat444-impacts]
              Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U.
              Colorado, "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.,



Kuarsingh & Howard        Expires May 30, 2012                 [Page 21]


Internet-Draft          Wireline Incremental IPv6          November 2011


              and H. Ashida, "Common requirements for Carrier Grade NAT
              (CGN)", draft-ietf-behave-lsn-requirements-04 (work in
              progress), October 2011.

   [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
              (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 CGN
              Space", draft-weil-shared-transition-space-request-09
              (work in progress), 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.

   [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd) -- Protocol Specification",



Kuarsingh & Howard        Expires May 30, 2012                 [Page 22]


Internet-Draft          Wireline Incremental IPv6          November 2011


              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.


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











Kuarsingh & Howard        Expires May 30, 2012                 [Page 23]


Internet-Draft          Wireline Incremental IPv6          November 2011


   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        Expires May 30, 2012                 [Page 24]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/