idnits 2.17.1 draft-weil-opsawg-provider-address-space-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 3 instances 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 date (September 23, 2010) is 4957 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-azinger-additional-private-ipv4-space-issues-04 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-06 == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-02 == Outdated reference: A later version (-08) exists of draft-shirasaki-nat444-isp-shared-addr-04 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Weil 3 Internet-Draft Cox Communications 4 Intended status: Informational V. Kuarsingh 5 Expires: March 27, 2011 Rogers Communications 6 C. Donley 7 CableLabs 8 September 23, 2010 10 IANA Reserved IPv4 Prefix for IPv6 Transition 11 draft-weil-opsawg-provider-address-space-02 13 Abstract 15 This document specifies the use of a reserved IANA IPv4 address 16 allocation to support the deployment of IPv6 transition technologies 17 and IPv4 address sharing technologies post IPv4 exhaustion. Service 18 providers are in the process of implementing IPv6 support by 19 providing dual-stack IPv4 and IPv6 services to their end-users. One 20 method for continued support of the IPv4 Internet post IANA IPv4 21 depletion is through the use of a carrier-provided NAT444 22 infrastructure. Another mechanism used to transition to IPv6 is an 23 IPv6-in-IPv4 tunnel such as IPv6 Rapid Deployment (6RD). This 24 document details the use of an IANA reserved address block for these 25 purposes. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 27, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 63 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Shared Transition Space . . . . . . . . . . . . . . . . . . . 7 65 5. Dual-Stack Home Gateway Transition Scenarios . . . . . . . . . 8 66 5.1. Legacy IPv4-only Home Gateway . . . . . . . . . . . . . . 8 67 5.2. Dual-Stack Home Gateway . . . . . . . . . . . . . . . . . 8 68 6. Benefits of a Single Large Allocation . . . . . . . . . . . . 10 69 7. Problems using Future Use Space . . . . . . . . . . . . . . . 11 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 10. Informative References . . . . . . . . . . . . . . . . . . . . 14 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 76 1. Introduction 78 The majority of large network service providers are in the process of 79 transitioning from IPv4 to IPv6 in response to the upcoming depletion 80 of the IPv4 address pool. For large networks, this transition 81 represents a multi-year project that will impact services and sectors 82 in the network at various stages in the plan. Many of the strategies 83 for the transition, including dual-stack, encapsulation, and 84 translation protocols, require a large amount of IPv4 addresses. 85 These addresses are internal to the service provider network, and 86 need not be globally routable. Deployment of such technologies 87 becomes increasingly more challenging for providers to acquire 88 sufficient address space the closer the IANA global pool nears 89 depletion, and is compounded by the fact that a number of these 90 providers have depleted the use of the Private [RFC1918] address 91 space and can currently only obtain sufficient address space through 92 allocations from RIRs. 94 While it is tempting to tell such operators to accelerate their plans 95 and simply switch to IPv6, such a strategy is not practical, since 96 many applications, content sites, and devices do not currently 97 support IPv6, and are unlikely to do so prior to IPv4 exhaustion. 98 Thus, service providers require additional address space to 99 facilitate the transition to IPv6 while maintaining support for IPv4. 101 As IANA depletion is expected in early 2011, it is imperative that 102 address space requirements for these transition strategies is 103 reserved quickly for this purpose. This document requests that IANA 104 reserve a portion of the remaining unallocated space as Shared 105 Transition Space for the enablement of a clean transition strategy in 106 large networks. 108 2. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 3. Motivation 116 The Internet community is rapidly consuming the remaining supply of 117 unallocated IPv4 addresses. At current projections, IANA will 118 completely allocate its IPv4 address space during the second quarter 119 of 2011. The solution to this IPv4 address consumption is to migrate 120 Internet traffic to IPv6. However, during the transition to IPv6, it 121 is imperative that Service Providers maintain IPv4 service for 122 devices and networks that are incapable of upgrading to IPv6. 124 Mobile data access networks also have large sums of GPRS (2G) and 125 UMTS (3G) UEs which have limited or no support of IPv6 operation. 126 Although mobile data equipment is refreshed on a higher frequency 127 then Wireline counterparts, many handsets and other mobile service 128 termination equipment will remain IPv4 only for a long period of 129 time. Even with the operators? best intentions, support for Roaming 130 (visitor equipment) will demand continued support for IPv4 unti 131 worldwide adoption reaches a certain threshold. 133 In order to provide IPv4 service to new customers and/or devices once 134 the IPv4 address space is exhausted, Service Providers must multiplex 135 several subscribers behind a single IPv4 address using one of several 136 techniques including NAT444 [I-D.shirasaki-nat444] and Dual-Stack 137 Lite [I-D.ietf-softwire-dual-stack-lite]. 139 Deploying IPv6 into service provider core and metro networks is 140 straightforward, and is progressing rapidly. The hardware that 141 exists in this portion of the network generally requires new software 142 only to route and forward both IPv4 and IPv6 datagrams. Moving 143 outward from the core towards the edges of the network, hardware 144 resources available tend to diminish relative to the expected 145 forwarding capacity. 147 In broadband access provider networks, the move towards the edge of 148 the network results in reduced hardware resources and less capability 149 in the core. These changes are significant when looking beyond the 150 edge aggregation layer and into the residential subscriber's home 151 network. In this environment, hosts and CPE routers tend to be 152 purpose built for efficiency, cost, and ease of use. Such devices 153 have been optimized for IPv4 operation, and typically do not support 154 IPv6. Furthermore, such home gateway router devices typically 155 require replacement in order to fully support the transition to IPv6. 156 The home gateway is a critical segment for any migration strategy. 157 This device must implement a dual-stack environment facing the home 158 LAN in order to enable IPv6 in the home. In addition, various 159 consumer devices including IP- enabled televisions, gaming consoles, 160 medical and family monitoring devices, etc. are IPv4-only, and cannot 161 be upgraded. While these will eventually be replaced with dual-stack 162 or IPv6 capable devices, this transition will take many years. As 163 these are typically consumer-owned devices, service providers do not 164 have control over the speed of their replacement cycle. However, 165 consumers have an expectation that they will continue to receive IPv4 166 service, and that such devices will continue to have IPv4 Internet 167 connectivity after the IPv4 pool is exhausted, even if the customer 168 contracts for new service with a new provider. 170 4. Shared Transition Space 172 This document proposes the assignment of a single /8 CIDR block as 173 Shared Transition Space. Shared Transition Space is IPv4 address 174 space reserved for Service Provider or large enterprise use with the 175 purpose of facilitating IPv6 transition and IPv4 coexistence 176 deployment. This space SHOULD only be used for the purpose of 177 providing NAT'ed IPv4 access to subscriber networks or IPv6-in-IPv4 178 tunnels during the transition to full IPv6 deployment. These 179 addresses MAY be used without any coordination with IANA or any other 180 Internet registry. It is RECOMMENDED that they not be used to 181 address LANs used by subscriber networks. It is RECOMMENDED that 182 equipment vendors not use these addresses in the default 183 configuration for CPEs. A single allocation that addresses all of 184 the detailed Home Gateway transition scenarios presented in this 185 document offers maximum utilization and flexibility to the Internet 186 community. 188 Because Shared Transition addresses have no meaning outside of the 189 Service Provider, routing information about shared transition space 190 networks MUST NOT be propagated on Internet links, and packets with 191 shared transition source or destination addresses SHOULD NOT be 192 forwarded across such links. Internet service providers are expected 193 filter out routing information about shared transition space networks 194 on ingress links. 196 A single shared IP block would also provide a common way for 197 [RFC1918]-constrained environments to support IPv6 transition 198 technologies without the need to select IP address space which is not 199 assigned to them ("address squatting") or implement complex 200 overlapping strategies that inevitably impacts customer connectivity 201 and performance. 203 5. Dual-Stack Home Gateway Transition Scenarios 205 This section details two use cases where different transition 206 technologies require IPv4 address space to support home network 207 services post IPv4 depletion. 209 5.1. Legacy IPv4-only Home Gateway 211 In this model, the home gateway is unable to support dual-stack 212 operation due to some combination of insufficient memory, processing 213 power, or other operational limitations such as lack of vendor 214 support. Also, many devices in the home will only support the IPv4 215 protocol. Until such customers replace their Home Gateways and all 216 IPv4-only CPE devices with IPv6-capable devices Service Providers 217 will be required to continue to offer IPv4 services through the use 218 of an IPv4 address sharing technology such as NAT444, as described in 219 [I-D.shirasaki-nat444]. The challenges associated with these 220 deployments are identified in [I-D.shirasaki-nat444-isp-shared-addr] 221 and [I-D.ford-shared-addressing-issues]. 223 Addressing solutions for dealing with the depletion of the IPv4 224 public address space and the lack of available private addresses 225 within large providers are presented in 226 [I-D.azinger-additional-private-ipv4-space-issues] as well as 227 [I-D.shirasaki-nat444-isp-shared-addr]. For larger Service Providers 228 who require more than the 16 million Net-10 addresses, or who have 229 already assigned Net-10 addresses in their networks, the preferred 230 method for addressing the problems presented in both draft documents 231 is to direct IANA to reserve a /8 from its unassigned IPv4 address 232 pool for Shared Transition Space. 234 5.2. Dual-Stack Home Gateway 236 In this model, the Home Gateway supports dual-stack operation 237 natively on the LAN interface. The Home Gateway may also support 238 Dual-stack on the WAN interface, or alternatively could deploy native 239 IPv6 service and tunnel IPv4 traffic over IPv6 using methods 240 specified in [I-D.ietf-softwire-dual-stack-lite]. To maintain IPv4 241 operation on the WAN interface post IPv4 depletion, a CGN technology 242 is required to offer NAT service, one within the Home Gateway and the 243 other within the provider's network. The tunneling approach has the 244 potential benefit of removing the Home Gateway NAT, but still relies 245 on the service provider NAT. 247 Regardless of deployment model chosen, the deployment of the NAT will 248 require new IPv4 public addressing. The preferred method for 249 addressing either of the dual-stack Home Gateway models would be a 250 unique IPv4 reservation of shared transition space from the IANA 251 unassigned pool. 253 In some cases, due to limited equipment capabilities, budget, or 254 deployment considerations, the service provider will not be able to 255 enable native IPv6 on the access network prior to IPv4 depletion, and 256 will need to use an IPv6-in-IPv4 encapsulation technology such as 6RD 257 [RFC5569] to offer IPv6 services. Such technologies require IPv4 258 address space between the dual-stack Home Gateway and the 6RD Border 259 Relay. This IPv4 address space does not need to be globally- 260 routable. As with the previous case, the preferred solution is to 261 use IANA-reserved shared transition space to support 6RD deployments. 263 6. Benefits of a Single Large Allocation 265 There are a number of benefits related to the use of a single /8 266 assignment from the IANA free pool. 268 o Flexibility: Allocating a /8 address pool as shared transition 269 space allows flexibility in the type of transition mechanisms that 270 can be deployed by Service Providers. Providers can expand the 271 number of addresses available for transition technology deployment 272 beyond those provided in [RFC1918]. 274 o Efficiency: A Number of large and mid-sized providers are actively 275 analyzing the use of Carrier Network Address Translators. The 276 demand for public IPv4 address space needed to number these 277 carrier address realms for large providers who lack enough 278 [RFC1918] space exceeds the available supply. Reserving such 279 space as Shared Transition Space should reduce the demand for 280 public IPv4 space by Service Providers, and result in a net gain 281 of available public IPv4 address space. 283 o RFC1918 Overlap: Utilization of separate assignment can remove the 284 challenge of [RFC1918] address overlap between the customer 285 network and the provider network. 287 o Removes need for bogon space or IPv4 squatting: Providers can 288 avoid the use of bogon and/or squatted space within their 289 networks. This type of address usage can cause connectivity 290 problems for customers and can be difficult to diagnose. 292 o Clear IP allocation for IPv6 transition technologies: A block 293 reserved for transition usage can be well defined and provide best 294 practices for transition technology deployment. 296 o Security: It is easier and more secure to build security polices 297 for larger address blocks, rather than multiple smaller blocks. 298 Larger blocks minimize the number of firewall rules or access list 299 statements required to implement such a policy, and thereby reduce 300 the number of errors. This results in better customer Internet 301 experiences. In addition, service providers can filter [RFC1918] 302 space at the edge of their network, and creating separate policies 303 for shared transition space, which ought to only be deployed 304 between the customer premise router and the service provider NAT/ 305 Border Relay. 307 7. Problems using Future Use Space 309 [I-D.fuller-240space] and [I-D.wilson-class-e] suggest that 310 240.0.0.0/4 space could be used as Shared Transition Space. However, 311 as discussed in [I-D.azinger-additional-private-ipv4-space-issues], 312 some existing network equipment does not support addresses in the 313 240.0.0.0/4 range. In particular, [CISCO] states that "no addresses 314 are allowed with the highest-order bits set to 1111". It is likely 315 that many home routers will not support this range, either. In order 316 use this range, equipment vendors would need to update software code 317 for existing routers and end users would need to upgrade their home 318 devices. As many older home routers do not support automatic 319 updates, it is unlikely that enough end users would upgrade to make 320 the 240.0.0.0/4 range viable for Shared Transition Space use. 322 8. Security Considerations 324 This memo does not define any protocol, and raises no security 325 issues. Any /8 allocated for ISP use would not be routable on the 326 Internet. 328 9. IANA Considerations 330 IANA is asked to reserve an IPv4 /8 from its remaining pool of 331 unallocated IPv4 addresses for use as Shared Transition Space. 333 10. Informative References 335 [CISCO] Cisco Systems, "TCP/IP Overview", . 339 [I-D.azinger-additional-private-ipv4-space-issues] 340 Azinger, M. and L. Vegoda, "Additional Private IPv4 Space 341 Issues", 342 draft-azinger-additional-private-ipv4-space-issues-04 343 (work in progress), April 2010. 345 [I-D.ford-shared-addressing-issues] 346 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 347 Roberts, "Issues with IP Address Sharing", 348 draft-ford-shared-addressing-issues-02 (work in progress), 349 March 2010. 351 [I-D.fuller-240space] 352 Fuller, V., "Reclassifying 240/4 as usable unicast address 353 space", draft-fuller-240space-02 (work in progress), 354 March 2008. 356 [I-D.ietf-softwire-dual-stack-lite] 357 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 358 Stack Lite Broadband Deployments Following IPv4 359 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work 360 in progress), August 2010. 362 [I-D.shirasaki-nat444] 363 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 364 and H. Ashida, "NAT444", draft-shirasaki-nat444-02 (work 365 in progress), July 2010. 367 [I-D.shirasaki-nat444-isp-shared-addr] 368 Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 369 and H. Ashida, "NAT444 addressing models", 370 draft-shirasaki-nat444-isp-shared-addr-04 (work in 371 progress), July 2010. 373 [I-D.wilson-class-e] 374 Wilson, P., Michaelson, G., and G. Huston, "Redesignation 375 of 240/4 from "Future Use" to "Private Use"", 376 draft-wilson-class-e-02 (work in progress), 377 September 2008. 379 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 380 E. Lear, "Address Allocation for Private Internets", 381 BCP 5, RFC 1918, February 1996. 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, March 1997. 386 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 387 Infrastructures (6rd)", RFC 5569, January 2010. 389 Appendix A. Acknowledgements 391 Thanks to the following people (in alphabetical order) for their 392 guidance and feedback: 394 John Brzozowski 396 Isaiah Connell 398 Greg Davies 400 Kirk Erichsen 402 Wes George 404 Tony Hain 406 Philip Matthews 408 John Pomeroy 410 Barbara Stark 412 Jean-Francois Tremblay 414 Leo Vegoda 416 Steven Wright 418 Ikuhei Yamagata 420 Authors' Addresses 422 Jason Weil 423 Cox Communications 424 1400 Lake Hearn Drive 425 Atlanta, GA 30319 426 USA 428 Email: jason.weil@cox.com 430 Victor Kuarsingh 431 Rogers Communications 432 8200 Dixie Road 433 Brampton, ON L6T 0C1 434 Canada 436 Email: victor.kuarsingh@rogers.com 438 Chris Donley 439 CableLabs 440 858 Coal Creek Circle 441 Louisville, CO 80027 442 USA 444 Email: c.donley@cablelabs.com