idnits 2.17.1 draft-jjmb-v6ops-comcast-ipv6-experiences-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 2, 2011) is 4587 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3068' is mentioned on line 93, but not defined ** Obsolete undefined reference: RFC 3068 (Obsoleted by RFC 7526) == Missing Reference: 'CMTS' is mentioned on line 264, but not defined == Missing Reference: 'CM' is mentioned on line 266, but not defined == Missing Reference: 'RFC3315' is mentioned on line 291, but not defined ** Obsolete undefined reference: RFC 3315 (Obsoleted by RFC 8415) == Missing Reference: 'RFC3633' is mentioned on line 288, but not defined ** Obsolete undefined reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations J. Brzozowski 3 Internet-Draft C. Griffiths 4 Intended status: Informational Comcast 5 Expires: April 4, 2012 October 2, 2011 7 Comcast IPv6 Trial/Deployment Experiences 8 draft-jjmb-v6ops-comcast-ipv6-experiences-02 10 Abstract 12 This document outlines the various technologies Comcast has trialed 13 as part of the company's ongoing IPv6 initiatives. The focus here 14 are the technologies and experiences specific to enabling IPv6 for 15 subscriber services like high speed data or Internet. Comcast has 16 learned a great deal about various technologies that we feel are 17 important to share with the community. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 4, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. 6RD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Native Dual Stack . . . . . . . . . . . . . . . . . . . . . . 7 58 6. Dual Stack Lite . . . . . . . . . . . . . . . . . . . . . . . 8 59 7. Content and Services . . . . . . . . . . . . . . . . . . . . . 9 60 8. Backoffice . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 9. World IPv6 Day . . . . . . . . . . . . . . . . . . . . . . . . 9 62 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 66 14. Normative References . . . . . . . . . . . . . . . . . . . . . 11 67 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Requirements Language 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 2. Introduction 78 Beginning in early 2010 Comcast announced plans to leverage the work 79 the company has been doing related to IPv6 to conduct a number of 80 IPv6 technology trials. These trials were specifically aimed at 81 enabling IPv6 for subscriber services. The purpose of this document 82 is to outline the technologies that have been trialed thus far along 83 with experiences and observations that adopters of the same may find 84 valuable in their own planning and deployment processes. 86 Further, there may be some additional feedback that the various 87 groups within the IETF may wish to take into account as part of 88 ongoing standards efforts. 90 3. 6to4 92 During production deployment planning the widespread use of 6to4 93 [RFC3068] to access content and services over IPv6 was assessed. In 94 some scenarios 6to4 usage increased several hundred times. At the 95 time Comcast had not deployed its own 6to4 relay infrastructure as 96 such open relays being operated by independent third parties were by 97 default used to facilitate 6to4-based communications. The deployment 98 and default use of open 6to4 relays appears to be a key variable 99 behind the sub-optimal performance associated with the use of 6to4. 100 An important thing to note is that some home gateway vendors have 101 turned on 6to4 by default, and in some of these implementations, they 102 have not presented a user interface a user interface to disable it. 103 For operators that have not deployed IPv6 or have IPv6 incapable 104 infrastructures should note that the use of 6to4 is likely occurring 105 today across their infrastructure. Many operating systems and home 106 networking devices continue to support 6to4 and in some cases have 107 6to4 and other transition technologies enabled by default. 109 As a community there appears to be some consensus that long term the 110 use of 6to4 is not desirable, however, in the near term it is clear 111 that 6to4 will be used in specific scenarios. The expectation and 112 goal is to see 6to4 usage diminish over time until use of the same is 113 displaced by an alternate technique to access content and services 114 over IPv6. While the debate continues over how and when to deprecate 115 6to4, it is clear that 6to4 should not be recommended as a primary 116 mechanism to access content and services over IPv6. 118 The following documents outline the recommendations surrounding the 119 use and status of 6to4 from a standards point of view: 121 1. [draft-ietf-v6ops-6to4-advisory] 123 2. [draft-ietf-v6ops-6to4-to-historic] 125 Comcast deployed a series of five (5) 6to4 relays in a geographically 126 dispersed configuration across our network. The purpose of these 127 relays was to reduce the latency typically associated with 6to4 128 usage. During our analysis, the use of off network, open 6to4 relays 129 was determined to yield nearly unusable conditions depending on the 130 geographic location of the end user relative to the open 6to4 relay. 131 By deploying on-network 6to4 relays, latency in most cases was 132 reduced by over 50%, which instantly yielded considerable 133 improvements from an end user point of view. The simplistic design 134 and deployment of these relays enabled us to rapidly put them in 135 network, and in some cases create a better experience for some of our 136 users who had 6to4 enabled. 138 Through the use of commodity x86 based servers that run a standard 139 Linux Operating System, we reduced deployment and operating costs, 140 while still maintaining a fault tolerant design. Each 6to4 relay was 141 dual stacked, and with a simple kernel module, we enabled the 6to4 142 configuration. Some 6to4 specific configurations were required to 143 ensure compatibility across a wide range of end points. The logic to 144 anycast the 6to4 records was handled by the network infrastructure 145 providing connectivity to the 6to4 relays, and health checking 146 enabled us to automatically remove the route for any relay from the 147 routing table in case of failure. 149 Router Announces 150 <---------. IPv4 Anycast .---------> 151 Redundant | 192.88.99.1 | Redundant 152 Network | +------------+ | Network 153 Path | | Network | | Path 154 +-----------+ Router +-----------+ 155 +------------+ 156 IPv4 | | IPv6 157 Interface | | Interface 158 +--+--+--+ 159 | Linux | 160 | 6to4 | 161 | Relay | 162 +--------+ 164 Figure 1: Comcast 6to4 Data Center View 166 4. 6RD 168 6RD [draft-townsley-ipv6-6rd] is another transition technology 169 similar to 6to4 that Comcast has deployed as part of technology 170 trials. While 6RD yields some improvements over 6to4, 6RD is 171 ultimately a tunneling technology. As such, it is subject to the 172 challenges faced by other tunneling technologies. 174 As advertised, 6RD frees adopters from some restrictions typically 175 associated with 6to4. The use of anycast addressing (IPv4 and IPv6) 176 is no longer required and the infrastructure, like 6to4, is 177 straightforward to deploy. However, at the time of deployment it was 178 observed that a limited number of border relay (BR) implementations 179 were available. This appears to be an evolving area with more 180 implementations becoming available. Similarly it was observed that 181 there we few if any customer edge (CE) implementations available to 182 support a trial of the technology. As such engineering 183 implementations were leveraged to evaluate 6RD. Further, there were 184 no implementations available that supported the 6RD DHCPv4 options 185 [draft-ietf-softwire-ipv6-6rd]. Because of this, every 6RD CE used 186 for trial was manually configured with the necessary information 187 required to enable 6RD. In order to support a wide scale production 188 deployment leveraging 6RD an operator would have to ensure their DHCP 189 infrastructure supports the required 6RD DHCPv4 options along with 190 targeted 6RD CE devices. 192 Trial configurations included two (2) 6RD BRs, which were 193 intentionally deployed in geographically dispersed configuration. An 194 anycast design was used to enable 6RD with a well known IPv4 anycast 195 address and FQDN for the 6RD BR. The use of anycast eased manual 196 configuration and deployment. Additionally, an IPv6 /32 was used to 197 support the 6RD trials permitting subscriber devices were able to 198 yield a usable IPv6 /64 on the LAN side of the 6RD CE. 200 The quantity and location of the 6RD BRs is a key variable when 201 planning the deployment of 6RD. Comcast specifically deployed a 202 limited quantity of BRs resulting in some end users being "closer" to 203 the BRs than others. Proximity to the 6RD BRs is an important factor 204 that impacts the end user experience. While 6RD yields some 205 improvements over 6to4, 6RD is ultimately a tunneling technology as 206 such use of the same is subject to the challenges faced by other 207 tunneling technologies. 209 Placement and quantity of 6RD BRs is also a significant variable to 210 consider when assessing impacts to performance and IPv6 geo-location. 211 A centralized approach to deploying 6RD BRs will yield undesirable 212 impacts to IPv6 geo-location in that end users leveraging a 213 particular 6RD BR that is geographically distant from their true 214 location will not accurately represent the origin of the end user 215 request. Conversely, deploying 6RD BRs that are near to end users 216 may require a substantial quantity of 6RD BRs depending on the 217 operator network. 219 The following provides an overview of the Comcast 6RD trial network 220 design: 222 +-------------------------------------------------------------+ 223 | Internet | 224 +-------+-------------------------------------------+---------+ 225 IPv6 | | IPv6 226 +-------+--------+ +-------+--------+ 227 | | | | 228 | Router | | Router | 229 | | | | 230 +---+--------+---+ +---+---------+--+ 231 | | | | 232 IPv4| | IPv6 IPv4 | | IPv6 233 | | | | 234 +---+--------+---+ +---+---------+--+ 235 | | | | 236 | 6rd-br-01 | | 6rd-br-02 | 237 | | 6rd.comcast.net | | 238 +----------------+ _..-' -.._ +----------------+ 239 _.-' `--._ 240 _.--' ``-.__ 241 _.-' IPv6 IPv6 `-.._ 242 ,-..--' encapsulated encapsulated ``-.. 243 ( ) in IPv4 in IPv4 ( ) 244 `-' `-' 245 6rd CE 6rd CE 246 | | 247 | IPv6 | IPv6 248 | | 250 Figure 2: Comcast 6RD Overview 252 5. Native Dual Stack 254 Native dual stack is central to Comcast's IPv6 program for trial and 255 production deployment. Native dual stack is the model where IPv4 256 services remain as-is with native IPv6 support introduced in parallel 257 or simultaneously. Many of the details surrounding how this is 258 achieved are documented as part of the CableLabs Data Over Cable 259 Service Interface Specification (DOCSIS) 3.0 [DOCSIS3.0]. However, 260 relevant trial and deployment specific information that is of 261 interest to the IETF community will be documented. 263 Native dual stack trials depend on the upgrade and enablement of 264 Cable Modem Termination Systems [CMTS] to support IPv6. A CMTS is a 265 device that end users in a cable network connect directly to using 266 their cable modem [CM]. As with IPv4, native support for IPv6 is 267 critical for the delivery of services to end users in a DOCSIS 268 network. Anything less could yield an undesirable end user 269 experience or instability in the operator network that could 270 adversely impact larger populations of users. 272 Given the CMTS requirements, native dual stack trials have initially 273 been limited to specific areas of the network. Further, where CMTS 274 platforms have been upgraded and enabled to support IPv6 end users 275 have been incrementally enabled with support for IPv6. Again this is 276 to ensure a controlled introduction with a specific focus on 277 maintaining stability. Initially, a limited combination of cable 278 modem and IGD devices are being used to support trial activities. 279 Over time diversity for both cable modem and IGDs are expected to 280 grow. To date a number of cable modems support the ability to enable 281 native dual stack connectivity to CPEs devices behind them. A subset 282 of pre-DOCSIS 3.0 and all DOCSIS 3.0 devices support this capability. 283 The population of DOCSIS devices that support these capabilities 284 varies from operator to operator. 286 Trial enablement requires the stateful provisioning of an IGD using 287 stateful DHCPv6 [RFC3315] for the IGD WAN interface and delegated 288 prefixes [RFC3633] for LAN side connectivity. Similarly, trial 289 supported direct attachment of IPv6 capable CPE devices to the CM. 290 In this configuration the CPE is provisioned with one or more IPv6 291 addresses via stateful DHCPv6 [RFC3315] in similar fashion to the IGD 292 WAN interface. The quantity of devices supporting a native dual 293 stack mode of operation is growing. While some devices are 294 upgradable to support native dual stack many devices deployed today 295 are not upgradable to support this functionality. Early 296 implementations of devices or devices that are upgradable to support 297 native IPv6 were found to only require and/or support the use of an 298 IPv6 /64 for LAN side connectivity. This has been an acceptable mode 299 of operation, however, over time IGDs will be required to support 300 more advanced functionality including the ability to support 301 multiple, routed IPv6 LANs. While support for a single IPv6 /64 is 302 in place today support for shorter IPv6 prefixes is also supported. 303 It is important for operators to ensure they design and plan support 304 across their infrastructures for delegated prefixes that are shorter 305 than /64. 307 +-------------------------------------------------------------+ 308 | Internet | 309 +-------+---------------------+---------------------+---------+ 310 | Native Dual Stack 311 | 312 +-------+--------+ 313 | | 314 | Router | 315 | | 316 +---+---+----+---+ 317 | 318 | Native Dual Stack 319 | 320 +-----------+------------+ 321 | Cable Modem | 322 | Termination System | 323 ''''''''''''''' (CMTS) ''''''''''''' 324 | +------------------------+ | 325 | | 326 | | 327 +--+---+ +--+---+ 328 | | Cable | | Cable 329 +--+---+ Modem +--+---+ Modem 330 +--+---+ | 331 | | IGD <----Native IPv4 and IPv6----> | 332 +--+---+ | 333 ,+. ,+. 334 ( ) Computer ( ) Computer 335 `-' (CPE) `-' (CPE) 337 Figure 3: Comcast Native Dual Stack 339 6. Dual Stack Lite 341 Part of Comcast's trial plans includes the trialing of Dual Stack 342 Lite. At this time trial planning for the same is underway. While 343 Comcast plans on trialing Dual Stack Lite there are no plans at this 344 time to deploy Dual Stack Lite beyond a limited technology trial. 346 7. Content and Services 348 During early phases of our trials Comcast leveraged reverse proxies 349 to expedite the availability of content natively over IPv6. Open 350 source technology running on Linux based servers was used to enable 351 the reverse proxies. To ensure that the origin content, which is 352 IPv4 only, is available natively over IPv6 the proxy servers required 353 native dual stack connectivity. This model allowed us to ensure that 354 Internet facing access to Comcast content occurred natively over 355 IPv6. 357 As third party CDNs introduce production quality support for IPv6 we 358 plan to move away from the use of proxy servers and fully towards 359 native dual stack for Comcast content and services. Native dual 360 stack content is but the first step to ensure the same can be IPv6 361 only at some point in the future. Observations from Comcast's 362 participation in World IPv6 day suggest it is premature to rely on 363 IPv6-only content at this time 365 Further as part of our trials Comcast has also recently enabled IPv6 366 Message Transfer Agents (MTA), in a limited fashion, to allow a 367 subset of Comcast trial users to send electronic mail using SMTP over 368 IPv6.. Due to the limited availability of spam mitigation for IPv6 369 Comcast trials does not include the receipt of electronic mail over 370 IPv6. In order to enable the receipt of electronic mail over IPv6 371 spam mitigation must be in place. 373 8. Backoffice 375 We made the decision early on in our design discussions to move all 376 systems to a dual-stack design since we felt that this was the best 377 way to transition to IPv6. The re-architect of many core systems 378 like DNS, DHCP, OSS/BSS, and Billing systems took many years to plan 379 and complete and this approach has paid off and allowed us to rapidly 380 move towards support for dual-stack at the edge of our network, 381 including support for our customers devices. 383 9. World IPv6 Day 385 During World IPv6 day, Comcast observed a significant increase in 386 native IPv6 traffic once content providers enabled AAAA records for 387 their websites. The resulting traffic has continued to increase even 388 after World IPv6 when about 50% of the websites that participated in 389 World IPv6 Day left their AAAA records enabled after the day. We 390 view this as a positive sign for continuing to drive more IPv6 391 traffic. 393 10. Conclusion 395 To date Comcast trial activities have yielded important, useful 396 information about the various technologies that are available to 397 facilitate the transition to IPv6. Observations and experience to 398 date confirms that native dual stack is the preferred approach to 399 transition to IPv6, where possible. While the various tunneling 400 technologies are indeed straightforward to deploy there are a number 401 of variables that must be considered when planning to deploy the 402 same. 404 Support for native dual stack continues to evolve across various 405 broadband technologies and within consumer electronics. As evidenced 406 by World IPv6 Day many of the world's largest content providers are 407 also making progress with their IPv6 capabilities. 409 11. IANA Considerations 411 This document makes no request of IANA. 413 Note to RFC Editor: this section may be removed on publication as an 414 RFC. 416 12. Security Considerations 418 There are no security considerations at this time. 420 13. Acknowledgements 422 Thanks to the Comcast team supporting the various trial and 423 production deployment activities: 425 Jonathan Boyer 427 Chris Griffiths 429 Tom Klieber 431 Yiu Lee 432 Jason Livingood 434 Anthony Veiga 436 Joel Warburton 438 Richard Woundy 440 14. Normative References 442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 443 Requirement Levels", BCP 14, RFC 2119, March 1997. 445 Appendix A. Document Change Log 447 [RFC Editor: This section is to be removed before publication] 449 -02: Grammatical items and re-wording of some sections. We have also 450 added a new World IPv6 Day section. 452 -01: Added C. Griffiths as co-author. Currently working on ascii art 453 and several new sections. 455 -00: First version published. 457 Authors' Addresses 459 John Jason Brzozowski 460 Comcast Cable Communications 461 One Comcast Center 462 1701 John F. Kennedy Boulevard 463 Philadelphia, PA 19103 464 US 466 Email: john_brzozowski@cable.comcast.com 467 URI: http://www.comcast.com 468 Chris Griffiths 469 Comcast Cable Communications 470 One Comcast Center 471 1701 John F. Kennedy Boulevard 472 Philadelphia, PA 19103 473 US 475 Email: chris_griffiths@cable.comcast.com 476 URI: http://www.comcast.com