idnits 2.17.1 draft-weil-shared-transition-space-request-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2011) is 4677 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-bdgks-arin-shared-transition-space-00 == Outdated reference: A later version (-06) exists of draft-donley-nat444-impacts-01 == Outdated reference: A later version (-05) exists of draft-ietf-intarea-shared-addressing-issues-02 == 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 Operations and Management Area Working J. Weil 3 Group Time Warner Cable 4 Internet-Draft V. Kuarsingh 5 Intended status: Informational Rogers Communications 6 Expires: January 9, 2012 C. Donley 7 CableLabs 8 C. LILJENSTOLPE 9 Telstra Corp 10 M. Azinger 11 Frontier Communications 12 July 8, 2011 14 IANA Reserved IPv4 Prefix for Shared Transition Space 15 draft-weil-shared-transition-space-request-02 17 Abstract 19 This document requests a reserved IANA IPv4 address allocation as 20 Shared Transition Space to support the deployment of IPv4 address 21 sharing technologies post IPv4 exhaustion. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 9, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 59 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Shared Transition Space . . . . . . . . . . . . . . . . . . . 7 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 7. Informative References . . . . . . . . . . . . . . . . . . . . 10 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 67 1. Introduction 69 Many operators are currently implementing their IPv6 transition 70 plans. During the transition, continued support for heritage IPv4 71 only devices will be required. While most operators are well aware 72 of the limitations of Carrier Grade NAT, particularly NAT444 73 [I-D.shirasaki-nat444] (see [I-D.donley-nat444-impacts]), it is the 74 transition mechanism that has the least customer impact for many 75 carriers. 77 To deploy Carrier Grade NAT, it becomes necessary for a provider to 78 create an inside address pool that will not conflict with its 79 customer address space. This document requests that IANA reserve a 80 /10 of IPv4 addresses to use as Shared Transition Space. As IANA has 81 exhausted its pool of addresses, one or more RIR(s) or legacy address 82 holder(s) will need to supply IANA with such addresses (e.g. per ARIN 83 Draft Policy 2011-5 [ARIN]). 85 2. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119 [RFC2119]. 91 3. Motivation 93 The Internet community is rapidly consuming the remaining supply of 94 unallocated IPv4 addresses. During the transition period to IPv6, it 95 is imperative that Service Providers maintain IPv4 service for 96 devices and networks that are currently incapable of upgrading to 97 IPv6. 99 In order to provide IPv4 service to customers and/or devices once the 100 IPv4 address space is exhausted, Service Providers must multiplex 101 several subscribers behind a single IPv4 address using one of several 102 techniques including NAT444 or Carrier Grade NAT. Providers need 103 sufficient non-[RFC1918] address space to deploy such technologies 104 and avoid overlap with customer use of private address space. 106 Many CPE router devices used to provide residential or small-medium 107 business services have been optimized for IPv4 operation, and 108 typically require replacement in order to fully support the 109 transition to IPv6 (either natively or via one of many transition 110 technologies). In addition, various consumer devices including IP- 111 enabled televisions, gaming consoles, medical and family monitoring 112 devices, etc. are IPv4-only, and cannot be upgraded. While these 113 will eventually be replaced with dual-stack or IPv6 capable devices, 114 this transition will take many years. As these are typically 115 consumer-owned devices, service providers do not have control over 116 the speed of their replacement cycle. However, consumers have an 117 expectation that they will continue to receive IPv4 service, and that 118 such devices will continue to have IPv4 Internet connectivity after 119 the IPv4 pool is exhausted, even if the customer contracts for new 120 service with a new provider. 122 Until such customers replace their Home Gateways and all IPv4-only 123 CPE devices with IPv6-capable devices, Service Providers will be 124 required to continue to offer IPv4 services through the use of an 125 IPv4 address sharing technology such as NAT444 126 [I-D.shirasaki-nat444]. The challenges associated with these 127 deployments are identified in [I-D.shirasaki-nat444-isp-shared-addr], 128 [I-D.donley-nat444-impacts], and 129 [I-D.ietf-intarea-shared-addressing-issues]. 131 Addressing solutions for dealing with the depletion of the IPv4 132 public address space and the lack of available private addresses 133 within large providers are presented in 134 [I-D.azinger-additional-private-ipv4-space-issues] as well as 135 [I-D.shirasaki-nat444-isp-shared-addr]. For infrastructure providers 136 whose customers are already using [RFC1918] space, as described in 137 [I-D.bdgks-arin-shared-transition-space] and [ARIN], the preferred 138 method for addressing the problems presented in both documents is to 139 direct IANA to reserve address space for Shared Transition Space. 141 4. Shared Transition Space 143 This document proposes the assignment of a /10 as Shared Transition 144 Space. Shared Transition Space is IPv4 address space reserved for 145 Infrastructure provider use with the purpose of facilitating IPv6 146 transition and IPv4 coexistence deployment. The requested block 147 SHOULD NOT be utilized for any purpose other than as "inside" 148 addresses in a carrier NAT environment (e.g. between the CGN and 149 customer CPE devices) or for other IPv4 to IPv6 transition 150 infrastructure. Network equipment manufacturers MUST NOT use the 151 assigned block in default or example device configurations. 153 Because Shared Transition addresses have no meaning outside of the 154 Infrastructure Provider, routing information about shared transition 155 space networks MUST NOT be propagated on interdomain links, and 156 packets with shared transition source or destination addresses SHOULD 157 NOT be forwarded across such links. Internet service providers 158 SHOULD filter out routing information about shared transition space 159 networks on ingress links. 161 5. Security Considerations 163 This memo does not define any protocol, and raises no security 164 issues. Any addresses allocated as Shared Transition Space would not 165 be routable on the Internet. 167 6. IANA Considerations 169 IANA is asked to reserve an IPv4 /10 for use as Shared Transition 170 Space. This prefix is intended to be non-routable. As IANA has 171 exhausted its pool of IPv4 address space, it may be necessary for one 172 or more RIRs and/or legacy address holders to provide such addresses 173 for IANA reservation (e.g. per ARIN Draft Policy 2011-5 [ARIN]). 175 7. Informative References 177 [ARIN] American Registry for Internet Numbers, "Shared Transition 178 Space for IPv4 Address Extension", 179 . 181 [I-D.azinger-additional-private-ipv4-space-issues] 182 Azinger, M. and L. Vegoda, "Issues Associated with 183 Designating Additional Private IPv4 Address Space", 184 draft-azinger-additional-private-ipv4-space-issues-05 185 (work in progress), January 2011. 187 [I-D.bdgks-arin-shared-transition-space] 188 Barber, S., Delong, O., Grundemann, C., Kuarsingh, V., and 189 B. Schliesser, "ARIN Draft Policy 2011-5: Shared 190 Transition Space", 191 draft-bdgks-arin-shared-transition-space-00 (work in 192 progress), July 2011. 194 [I-D.donley-nat444-impacts] 195 Donley, C., Howard, L., Kuarsingh, V., Chandrasekaran, A., 196 and V. Ganti, "Assessing the Impact of NAT444 on Network 197 Applications", draft-donley-nat444-impacts-01 (work in 198 progress), October 2010. 200 [I-D.ietf-intarea-shared-addressing-issues] 201 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 202 Roberts, "Issues with IP Address Sharing", 203 draft-ietf-intarea-shared-addressing-issues-02 (work in 204 progress), October 2010. 206 [I-D.shirasaki-nat444] 207 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 208 and H. Ashida, "NAT444", draft-shirasaki-nat444-02 (work 209 in progress), July 2010. 211 [I-D.shirasaki-nat444-isp-shared-addr] 212 Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 213 and H. Ashida, "NAT444 addressing models", 214 draft-shirasaki-nat444-isp-shared-addr-04 (work in 215 progress), July 2010. 217 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 218 E. Lear, "Address Allocation for Private Internets", 219 BCP 5, RFC 1918, February 1996. 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, March 1997. 224 Appendix A. Acknowledgements 226 Thanks to the following people (in alphabetical order) for their 227 guidance and feedback: 229 John Brzozowski 231 Isaiah Connell 233 Greg Davies 235 Kirk Erichsen 237 Wes George 239 Tony Hain 241 Philip Matthews 243 John Pomeroy 245 Barbara Stark 247 Jean-Francois Tremblay 249 Leo Vegoda 251 Steven Wright 253 Ikuhei Yamagata 255 Authors' Addresses 257 Jason Weil 258 Time Warner Cable 259 13820 Sunrise Valley Drive 260 Herndon, VA 20171 261 USA 263 Email: jason.weil@twcable.com 265 Victor Kuarsingh 266 Rogers Communications 267 8200 Dixie Road 268 Brampton, ON L6T 0C1 269 Canada 271 Email: victor.kuarsingh@rci.rogers.com 273 Chris Donley 274 CableLabs 275 858 Coal Creek Circle 276 Louisville, CO 80027 277 USA 279 Email: c.donley@cablelabs.com 281 Christopher Liljenstolpe 282 Telstra Corp 283 7/242 Exhibition Street 284 Melbourne, VIC 316 285 AU 287 Phone: +61 3 8647 6389 288 Fax: 289 Email: cdl@asgaard.org 290 URI: 292 Marla Azinger 293 Frontier Communications 294 Vancouver, WA 295 US 297 Phone: +1.360.513.2293 298 Fax: 299 Email: marla.azinger@frontiercorp.com 300 URI: