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

Versions: 00 01 02

Network Working Group                                      J. Brzozowski
Internet-Draft                              Comcast Cable Communications
Intended status: Informational                             March 7, 2011
Expires: September 8, 2011

                        Comcast IPv6 Experiences


   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.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 September 8, 2011.

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

Brzozowski              Expires September 8, 2011               [Page 1]

Internet-Draft          Comcast IPv6 Experiences              March 2011

   (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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  6to4  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  6RD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Native Dual Stack . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7

Brzozowski              Expires September 8, 2011               [Page 2]

Internet-Draft          Comcast IPv6 Experiences              March 2011

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

2.  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 occuring
   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.

   [@todo - pointers to active documents pertaining to deprecating 6to4
   and other transition technologies]

   As part of Comcast's IPv6 deployment a series of five (5) 6to4 relays
   were planned for deployment in a geographically dispersed
   configuration.  The purpose of these relays was to reduce the latency
   typically associated with 6to4 usage.  The use of off network, open
   6to4 relays was analyzed and determined to yield nearly unusable

Brzozowski              Expires September 8, 2011               [Page 3]

Internet-Draft          Comcast IPv6 Experiences              March 2011

   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.  To
   be clear the objective behind deploying 6to4 relays was simply to
   reduce latency and improve the end user experience.  Additionally, it
   is important to note that deploying the infrastructure required to
   support 6to4 was very straightforward and immediately noticeable from
   an end user point of view.

   [@todo - additional deployment details and diagrams will be added to
   this section]

3.  6RD

   6RD [draft-townsley-ipv6-6rd-01] 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 of the same from many 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-03] 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 part of the country.  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 configuration and
   deployment.  Additionally, an IPv6 /32 was used to support the 6RD
   trials as such subscriber devices were only able to yield a usable an
   IPv6 /64 on the LAN side of the 6RD CE.

Brzozowski              Expires September 8, 2011               [Page 4]

Internet-Draft          Comcast IPv6 Experiences              March 2011

   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 that others.  Proximity to the 6RD BRs is an
   important factor in end user experience.  While 6RD yields some
   improvements over 6to4, 6RD is ultimately a tunneling technology
   there proximity to the relay, in this case border relay, is an
   important variable.

   Placement and quantity of 6RD BRs is also a significant variable to
   consider when assessing impacts to IPv6 geo-location information.  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 will not accurately
   represent the true 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.

   [@todo - add trial details and diagrams]

4.  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 added or introduced in
   parallel or simultaneously.  Many of the details surrounding how this
   is achieved are documented as part of the Cablelabs Data Over Cable
   Service Interface Specification 3.0 [DOCSIS3.0].  However, relevant
   trial and deployment specific information that is of interest to the
   IETF community will be documented.

   [@todo - add reference to DOCSIS]

   Native dual stack trials depend on the upgrade and enablement of
   Cable Modem Termination Systems [CMTS].  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

   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

Brzozowski              Expires September 8, 2011               [Page 5]

Internet-Draft          Comcast IPv6 Experiences              March 2011

   maintaining stability.  Initially, a limited combination of cable
   modem and IGD devices were used to support trial activities.
   Overtime diversity for both cable modem and IGDs are expected.  To
   date a number of cable modems support the ability to enable native
   dual stack connectivity to CPEs devices.  A subset of DOCSIS 2.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 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

   [@todo - add information about in home consumer devices and rDNS]

   [@todo - add trial details and diagrams]

5.  Conclusion

   [@todo - to be completed]

6.  IANA Considerations

   This document makes no request of IANA.

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

7.  Security Considerations

   There are no security considerations at this time.

Brzozowski              Expires September 8, 2011               [Page 6]

Internet-Draft          Comcast IPv6 Experiences              March 2011

8.  Acknowledgements

   Thanks to the Comcast team supporting the various trial and
   production deployment activities.  A list will be supplied in a
   future version of this draft.

9.  Normative References

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

Author's Address

   John Jason Brzozowski
   Comcast Cable Communications
   Philadelphia, PA

   Phone: +1-484-962-0060
   Email: john_brzozowski@cable.comcast.com

Brzozowski              Expires September 8, 2011               [Page 7]

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