Network Working Group J. Brzozowski Internet-Draft Comcast Cable Communications Intended status: Informational March 7, 2011 Expires: September 8, 2011 Comcast IPv6 Experiences draft-jjmb-v6ops-comcast-ipv6-experiences-00 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. 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 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 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 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 /64. [@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 RFC. 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 USA Phone: +1-484-962-0060 Email: john_brzozowski@cable.comcast.com Brzozowski Expires September 8, 2011 [Page 7]