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

Versions: 00 01 02

IPv6 Operations                                            J. Brzozowski
Internet-Draft                                              C. Griffiths
Intended status: Informational                                   Comcast
Expires: January 9, 2012                                    July 8, 2011


               Comcast IPv6 Trial/Deployment Experiences
              draft-jjmb-v6ops-comcast-ipv6-experiences-01

Abstract

   This document outlines the various technologies Comcast has trialed
   as part of the company's ongoing IPv6 initiatives.  The focus here
   are the technologies and experiences specific to enabling IPv6 for
   subscriber services like high speed data or Internet.  Comcast has
   learned a great deal about various technologies that we feel are
   important to share with the community.

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 January 9, 2012.

Copyright Notice

   Copyright (c) 2011 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



Brzozowski & Griffiths   Expires January 9, 2012                [Page 1]


Internet-Draft  Comcast IPv6 Trial/Deployment Experiences      July 2011


   described in the Simplified BSD License.


Table of Contents

   1.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  6RD  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Native Dual Stack  . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Dual Stack Lite  . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Content and Services . . . . . . . . . . . . . . . . . . . . .  8
   8.  Backoffice . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   13. Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11































Brzozowski & Griffiths   Expires January 9, 2012                [Page 2]


Internet-Draft  Comcast IPv6 Trial/Deployment Experiences      July 2011


1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  Introduction

   Beginning in early 2010 Comcast announced plans to leverage the work
   the company has been doing related to IPv6 to conduct a number of
   IPv6 technology trials.  These trials were specifically aimed at
   enabling IPv6 for subscriber services.  The purpose of this document
   is to outline the technologies that have been trialed thus far along
   with experiences and observations that adopters of the same may find
   valuable in their own planning and deployment processes.

   Further, there may be some additional feedback that the various
   groups within the IETF may wish to take into account as part of
   ongoing standards efforts.


3.  6to4

   During production deployment planning the widespread use of 6to4
   [RFC3068] to access content and services over IPv6 was assessed.  In
   some scenarios 6to4 usage increased several hundred times.  At the
   time Comcast had not deployed its own 6to4 relay infrastructure as
   such open relays being operated by independent third parties were by
   default used to facilitate 6to4-based communications.  The deployment
   and default use of open 6to4 relays appears to be a key variable
   behind the sub-optimal performance associated with the of 6to4.
   Operators that have not deployed IPv6 or have IPv6 incapable
   infrastructures should note that the use of 6to4 is likely occurring
   today across their infrastructure.  Many operating systems and home
   networking devices continue to support the same and in some cases
   have 6to4 and other transition technologies enabled by default.

   As a community there appears to be some consensus that long term the
   use of 6to4 is not desirable, however, in the near term is it clear
   that 6to4 will be used in specific scenarios.  The expectation and
   goal is to see 6to4 usage diminish over time until use of the same is
   displaced by an alternate technique to access content and services
   over IPv6.  While the debate continues over how and when to deprecate
   6to4, it is clear that 6to4 should not be recommended as a primary
   mechanism to access content and services over IPv6.

   The following documents outline the recommendations surrounding the



Brzozowski & Griffiths   Expires January 9, 2012                [Page 3]


Internet-Draft  Comcast IPv6 Trial/Deployment Experiences      July 2011


   use and status of the 6to4 from a standards point of view:

   1.  [draft-ietf-v6ops-6to4-advisory]

   2.  [draft-ietf-v6ops-6to4-to-historic]

   Comcast deployed a series of five (5) 6to4 relays in a geographically
   dispersed configuration across our network.  The purpose of these
   relays was to reduce the latency typically associated with 6to4
   usage.  During our analysis, the use of off network, open 6to4 relays
   was determined to yield nearly unusable conditions depending on the
   geographic location of the end user relative to the open 6to4 relay.
   By deploying on-network 6to4 relays, latency in most cases was
   reduced by over 50%, which instantly yielded considerable
   improvements from an end user point of view.  The simplistic design
   and deployment of these relays enabled us to rapidly put them in
   network, and in some cases create a better experience for some of our
   users who had 6to4 enabled.

   Through the use of commodity i386 based servers that run a standard
   Linux Operating System, we reduced deployment and operating costs,
   while still maintaining a fault tolerant design.  Each 6to4 relay was
   dual stacked, and with a simple kernel module, we enabled the 6to4
   configuration.  Some 6to4 specific configurations were required to
   ensure compatibility across a wide range of end points.  The logic to
   Anycast the 6to4 records was handled by the network infrastructure
   providing connectivity to the 6to4 relays, and health check enabled
   us to automatically remove the route for any relay from the routing
   table in case of failure.



                              Router Announces
         <---------.            IPv4 Anycast            .--------->
         Redundant |            192.88.99.1             | Redundant
         Network   |           +------------+           | Network
         Path      |           |  Network   |           | Path
                   +-----------+   Router   +-----------+
                               +------------+
                               IPv4 |  | IPv6
                          Interface |  | Interface
                                 +--+--+--+
                                 | Linux  |
                                 |  6to4  |
                                 | Relay  |
                                 +--------+





Brzozowski & Griffiths   Expires January 9, 2012                [Page 4]


Internet-Draft  Comcast IPv6 Trial/Deployment Experiences      July 2011


                  Figure 1: Comcast 6to4 Data Center View


4.  6RD

   6RD [draft-townsley-ipv6-6rd] is another transition technology
   similar to 6to4 that Comcast has deployed as part of technology
   trials.  While 6RD shared many similarities with 6to4 technologically
   there were a number of differences noted with the same that adopters
   of the same should consider as part of their own deployments.

   As advertised 6RD frees adopters from some restrictions typically
   associated with 6to4 namely the use of anycast addressing (IPv4 and
   IPv6) and the infrastructure, like 6to4, is straightforward to
   deploy.  However, at the time of deployment it was observed that a
   limited number of border relay (BR) implementations were available.
   This appears to be an evolving area with more implementations
   becoming available.  Similarly it was observed that there we few if
   any customer edge (CE) implementations available to support a trial
   of the technology.  As such engineering implementations were
   leveraged to evaluate 6RD.  Further, there were no implementations
   available that supported the 6RD DHCPv4 options
   [draft-ietf-softwire-ipv6-6rd] as such every 6RD CE used for trial
   was manually configured with the necessary configuration required to
   enable 6RD.  In order to support a wide scale production deployment
   leveraging 6RD an operator would have to ensure their DHCP
   infrastructure supports the required 6RD DHCPv4 options along with
   targeted 6RD CE devices.

   Trial configurations included two (2) 6RD BRs, which were
   intentionally deployed in geographically dispersed configuration.  An
   anycast design was used to enable 6RD with a well known IPv4 anycast
   address and FQDN for the 6RD BR.  The use of the same eased manual
   configuration and deployment.  Additionally, an IPv6 /32 was used to
   support the 6RD trials as such subscriber devices were able to yield
   a usable IPv6 /64 on the LAN side of the 6RD CE.

   The quantity and location of the 6RD BRs is a key variable when
   planning the deployment of 6RD.  Comcast specifically deployed a
   limited quantity of the same resulting in some end users being
   "closer" to the BRs than others.  Proximity to the 6RD BRs is an
   important factor that impacts the end user experience.  While 6RD
   yields some improvements over 6to4, 6RD is ultimately a tunneling
   technology as such use of the same is subject to the challenges faced
   by other tuneling technologies.

   Placement and quantity of 6RD BRs is also a significant variable to
   consider when assessing impacts to performance and IPv6 geo-location.



Brzozowski & Griffiths   Expires January 9, 2012                [Page 5]


Internet-Draft  Comcast IPv6 Trial/Deployment Experiences      July 2011


   A centralized approach to deploying 6RD BRs will yield undesirable
   impacts to IPv6 geo-location in that end users leveraging a
   particular 6RD BR that is geographically distant from their true
   location will not accurately represent the origin of the end user
   request.  Conversely, deploying 6RD BRs that are near to end users
   may require a substantial quantity of 6RD BRs depending on the
   operator network.

   The following provides an overview of the Comcast 6RD trial network
   design:

        +-------------------------------------------------------------+
        |                           Internet                          |
        +-------+-------------------------------------------+---------+
         IPv6   |                                           |    IPv6
        +-------+--------+                          +-------+--------+
        |                |                          |                |
        |    Router      |                          |    Router      |
        |                |                          |                |
        +---+--------+---+                          +---+---------+--+
            |        |                                  |         |
        IPv4|        | IPv6                       IPv4  |         | IPv6
            |        |                                  |         |
        +---+--------+---+                          +---+---------+--+
        |                |                          |                |
        |   6rd-br-01    |                          |   6rd-br-02    |
        |                |     6rd.comcast.net      |                |
        +----------------+     _..-'      -.._      +----------------+
                           _.-'               `--._
                      _.--'                        ``-.__
                  _.-'  IPv6                   IPv6      `-.._
           ,-..--'   encapsulated           encapsulated      ``-..
          (   )        in IPv4                in IPv4          (   )
           `-'                                                  `-'
         6rd CE                                                6rd CE
            |                                                    |
            |  IPv6                                              | IPv6
            |                                                    |

                      Figure 2: Comcast 6RD Overview


5.  Native Dual Stack

   Native dual stack is central to Comcast's IPv6 program for trial and
   production deployment.  Native dual stack is the model where IPv4
   services remain as-is with native IPv6 support introduced in parallel
   or simultaneously.  Many of the details surrounding how this is



Brzozowski & Griffiths   Expires January 9, 2012                [Page 6]


Internet-Draft  Comcast IPv6 Trial/Deployment Experiences      July 2011


   achieved are documented as part of the CableLabs Data Over Cable
   Service Interface Specification (DOCSIS) 3.0 [DOCSIS3.0].  However,
   relevant trial and deployment specific information that is of
   interest to the IETF community will be documented.

   Native dual stack trials depend on the upgrade and enablement of
   Cable Modem Termination Systems [CMTS] to support IPv6.  A CMTS is a
   device that end users in a cable network connect directly to using
   their cable modem [CM].  As with IPv4, native support for IPv6 is
   critical for the delivery of services to end users in a DOCSIS
   network.  Anything less could yield an undesirable end user
   experience or instability in the operator network that could
   adversely impact larger populations of users.

   Given the CMTS requirements, native dual stack trials have initially
   been limited to specific areas of the network.  Further, where CMTS
   platforms have been upgraded and enabled to support IPv6 end users
   have been incrementally enabled with support for IPv6.  Again this is
   to ensure a controlled introduction with a specific focus on
   maintaining stability.  Initially, a limited combination of cable
   modem and IGD devices are being used to support trial activities.
   Overtime diversity for both cable modem and IGDs are expected to
   expand.  To date a number of cable modems support the ability to
   enable native dual stack connectivity to CPEs devices behind the
   same.  A subset of pre-DOCSIS 3.0 and all DOCSIS 3.0 devices support
   this capability.  The population of DOCSIS devices that support these
   capabilities varies from operator to operator.

   Trial enablement requires the stateful provisioning of an IGD using
   stateful DHCPv6 [RFC3315] for the IGD WAN interface and delegated
   prefixes [RFC3633] for LAN side connectivity.  The quantity of
   devices supporting a native dual stack mode of operation is growing.
   While some devices are upgradable to support native dual stack many
   devices deployed today are not upgradable to support this
   functionality.  Early implementations of devices or devices that are
   upgradable to support native IPv6 were found to only require and/or
   support the use of an IPv6 /64 for LAN side connectivity.  This has
   been an acceptable mode of operation, however, over time IGDs will be
   required to support more advanced functionality including the ability
   to support multiple, routed IPv6 LANs.  While support for a single
   IPv6 /64 is in place today support for shorter IPv6 prefixes is also
   supported.  It is important for operators to ensure they design and
   plan support across their infrastructures for delegated prefixes that
   are shorter than /64.







Brzozowski & Griffiths   Expires January 9, 2012                [Page 7]


Internet-Draft  Comcast IPv6 Trial/Deployment Experiences      July 2011


     +-------------------------------------------------------------+
     |                           Internet                          |
     +-------+---------------------+---------------------+---------+
                                   | Native Dual Stack
                                   |
                           +-------+--------+
                           |                |
                           |    Router      |
                           |                |
                           +---+---+----+---+
                                   |
                                   | Native Dual Stack
                                   |
                       +-----------+------------+
                       |   Cable Modem          |
                       |   Termination System   |
         '''''''''''''''   (CMTS)               '''''''''''''
         |             +------------------------+           |
         |                                                  |
         |                                                  |
      +--+---+                                           +--+---+
      |      | Cable                                     |      | Cable
      +--+---+ Modem                                     +--+---+ Modem
      +--+---+                                              |
      |      | IGD     <----Native IPv4 and IPv6---->       |
      +--+---+                                              |
        ,+.                                                ,+.
       (   )   Computer                                   (   ) Computer
        `-'    (CPE)                                       `-'  (CPE)

                    Figure 3: Comcast Native Dual Stack


6.  Dual Stack Lite

   Part of Comcast's trial plans includes the trialing of Dual Stack
   Lite.  At this time trial planning for the same is underway.  While
   Comcast plans on trialing Dual Stack Lite there are no plans at this
   time to deploy Dual Stack Lite beyond a limited technology trial.


7.  Content and Services

   During early phases of our trials Comcast leveraged reverse proxies
   to expedite the availability of content natively over IPv6.  Open
   source techology running on Linux based servers was used enable the
   reverse proxies.  To ensure that the origin content, which is IPv4
   only, is available natively over IPv6 the proxy servers required



Brzozowski & Griffiths   Expires January 9, 2012                [Page 8]


Internet-Draft  Comcast IPv6 Trial/Deployment Experiences      July 2011


   native dual stack connectivity.  This model allowed us to ensure that
   Internet facing access to Comcast occured natively over IPv6.

   As third party CDNs introduce production quality support for IPv6 we
   plan to move away from the use of proxy servers and fully towards
   native dual stack for Comcast content and services.  Native dual
   stack content is but the first step to ensure the same can be IPv6
   only at some point in the future.  As observed during World IPv6 Day
   it is still somewhat premature to have IPv6 only content.

   Further as part of our trials Comcast has also recently enabled, in a
   limited fashion, Message Transfer Agents (MTA) to allow a subset of
   Comcast trial users to send electronic mail using SMTP.  Due to the
   limited availability of spam mitigation for IPv6 Comcast trials does
   not include the receipt of electronic mail over IPv6.  In order to
   enable the receipt of electronic mail over IPv6 spam mitigation must
   be in place.


8.  Backoffice

   We made the decision early on in our design discussions to move all
   systems to a dual-stack since we felt that this was the best way to
   transition to IPv6.  We have been planning for several years to re-
   architect many core systems like DNS, DHCP, OSS/BSS, and Billing
   systems.  This approach has paid off and allowed us to rapidly move
   towards support for dual-stack at the edge of our network, including
   support for our customers devices.


9.  Conclusion

   To date Comcast trial activities have yielded important, useful
   information about the various technologies that are available to
   facilitate the transition to IPv6.  Observations and experiene to
   date confirms that native dual stack is the preferred approach to
   transition to IPv6, where possible.  While the various tunneling
   technologies are indeed straightforward to deploy there are a number
   of variables that must be considered when planning to deploy the
   same.

   Support for native dual stack continues to evolve across various
   broadband technologies and within consumer electronics.  As evidenced
   by World IPv6 Day many of the world's largest content providers are
   also making progress with their IPv6 capabilities.






Brzozowski & Griffiths   Expires January 9, 2012                [Page 9]


Internet-Draft  Comcast IPv6 Trial/Deployment Experiences      July 2011


10.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


11.  Security Considerations

   There are no security considerations at this time.


12.  Acknowledgements

   Thanks to the Comcast team supporting the various trial and
   production deployment activities:

      Jonathan Boyer

      Chris Griffiths

      Tom Klieber

      Yiu Lee

      Jason Livingood

      Anthony Veiga

      Joel Warburton

      Richard Woundy


13.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


Appendix A.  Document Change Log

   [RFC Editor: This section is to be removed before publication]

   -01: Added C. Griffiths as co-author.  Currently working on ascii art
   and several new sections.




Brzozowski & Griffiths   Expires January 9, 2012               [Page 10]


Internet-Draft  Comcast IPv6 Trial/Deployment Experiences      July 2011


   -00: First version published.


Authors' Addresses

   John Jason Brzozowski
   Comcast Cable Communications
   One Comcast Center
   1701 John F. Kennedy Boulevard
   Philadelphia, PA  19103
   US

   Email: john_brzozowski@cable.comcast.com
   URI:   http://www.comcast.com


   Chris Griffiths
   Comcast Cable Communications
   One Comcast Center
   1701 John F. Kennedy Boulevard
   Philadelphia, PA  19103
   US

   Email: chris_griffiths@cable.comcast.com
   URI:   http://www.comcast.com


























Brzozowski & Griffiths   Expires January 9, 2012               [Page 11]


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