idnits 2.17.1 draft-weil-shared-transition-space-request-01.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 (November 11, 2010) is 4914 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 (-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 (~~), 7 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: May 15, 2011 Rogers Communications 6 C. Donley 7 CableLabs 8 C. LILJENSTOLPE 9 Telstra Corp 10 M. Azinger 11 Frontier Communications 12 November 11, 2010 14 IANA Reserved IPv4 Prefix for Shared Transition Space 15 draft-weil-shared-transition-space-request-01 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 May 15, 2011. 40 Copyright Notice 42 Copyright (c) 2010 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. Problems using Future Use Space . . . . . . . . . . . . . . . 8 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 8. Informative References . . . . . . . . . . . . . . . . . . . . 11 65 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 68 1. Introduction 70 Many operators are currently implimenting their IPv6 transition 71 plans. During the transition, continued support for heritage IPv4 72 only devices will be required. While most operators are well aware 73 of the limitations of NAT444 [I-D.shirasaki-nat444] (see 74 [I-D.donley-nat444-impacts]), it is the transition mechnism that has 75 the least customer impact for many carriers. 77 To deal with some of the NAT444 limitations, it becomes necessary for 78 a provider to utilize address space in the NAT444 infrastructure that 79 will not conflict with it's customer space. 81 This document requests that IANA reserve a portion of the remaining 82 unallocated space as Shared Transition Space for the enablement of a 83 clean transition strategy in provider networks. 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 . Providers need sufficient non- 103 [RFC1918] address space to deploy such technologies and avoid overlap 104 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, the preferred 137 method for addressing the problems presented in both documents is to 138 direct IANA to reserve address space from its unassigned IPv4 address 139 pool for Shared Transition Space. 141 4. Shared Transition Space 143 This document proposes the assignment of the equivalent of a /10 as 144 Shared Transition Space. This block could be composed of one 145 contiguous assignment, or several discontiguous assignments. Shared 146 Transition Space is IPv4 address space reserved for Infrastructure 147 provider use with the purpose of facilitating IPv6 transition and 148 IPv4 coexistence deployment. The requested block SHOULD NOT be 149 utilized for any purpose other than 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. Problems using Future Use Space 163 [I-D.fuller-240space] and [I-D.wilson-class-e] suggest that 164 240.0.0.0/4 space could be used as Shared Transition Space. However, 165 as discussed in [I-D.azinger-additional-private-ipv4-space-issues], 166 some existing network equipment does not support addresses in the 167 240.0.0.0/4 range. In particular, [CISCO] states that "no addresses 168 are allowed with the highest-order bits set to 1111". It is likely 169 that many home routers will not support this range, either. In order 170 to use this range, equipment vendors would need to update software 171 code for existing routers and end users would need to upgrade their 172 home devices. As many older home routers do not support automatic 173 updates, it is unlikely that enough end users would upgrade to make 174 the 240.0.0.0/4 range viable for Shared Transition Space use. 176 6. Security Considerations 178 This memo does not define any protocol, and raises no security 179 issues. Any addresses allocated as Shared Transition Space would not 180 be routable on the Internet. 182 7. IANA Considerations 184 IANA is asked to reserve an IPv4 /10 from its remaining pool of 185 unallocated IPv4 addresses for use as Shared Transition Space. 187 8. Informative References 189 [CISCO] Cisco Systems, "TCP/IP Overview", . 193 [I-D.azinger-additional-private-ipv4-space-issues] 194 Azinger, M. and L. Vegoda, "Additional Private IPv4 Space 195 Issues", 196 draft-azinger-additional-private-ipv4-space-issues-04 197 (work in progress), April 2010. 199 [I-D.donley-nat444-impacts] 200 Donley, C., Howard, L., Kuarsingh, V., Chandrasekaran, A., 201 and V. Ganti, "Assessing the Impact of NAT444 on Network 202 Applications", draft-donley-nat444-impacts-01 (work in 203 progress), October 2010. 205 [I-D.fuller-240space] 206 Fuller, V., "Reclassifying 240/4 as usable unicast address 207 space", draft-fuller-240space-02 (work in progress), 208 March 2008. 210 [I-D.ietf-intarea-shared-addressing-issues] 211 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 212 Roberts, "Issues with IP Address Sharing", 213 draft-ietf-intarea-shared-addressing-issues-02 (work in 214 progress), October 2010. 216 [I-D.shirasaki-nat444] 217 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 218 and H. Ashida, "NAT444", draft-shirasaki-nat444-02 (work 219 in progress), July 2010. 221 [I-D.shirasaki-nat444-isp-shared-addr] 222 Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 223 and H. Ashida, "NAT444 addressing models", 224 draft-shirasaki-nat444-isp-shared-addr-04 (work in 225 progress), July 2010. 227 [I-D.wilson-class-e] 228 Wilson, P., Michaelson, G., and G. Huston, "Redesignation 229 of 240/4 from "Future Use" to "Private Use"", 230 draft-wilson-class-e-02 (work in progress), 231 September 2008. 233 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 234 E. Lear, "Address Allocation for Private Internets", 235 BCP 5, RFC 1918, February 1996. 237 [RFC2119] "". 239 Appendix A. Acknowledgements 241 Thanks to the following people (in alphabetical order) for their 242 guidance and feedback: 244 John Brzozowski 246 Isaiah Connell 248 Greg Davies 250 Kirk Erichsen 252 Wes George 254 Tony Hain 256 Philip Matthews 258 John Pomeroy 260 Barbara Stark 262 Jean-Francois Tremblay 264 Leo Vegoda 266 Steven Wright 268 Ikuhei Yamagata 270 Authors' Addresses 272 Jason Weil 273 Cox Communications 274 1400 Lake Hearn Drive 275 Atlanta, GA 30319 276 USA 278 Email: jason.weil@cox.com 280 Victor Kuarsingh 281 Rogers Communications 282 8200 Dixie Road 283 Brampton, ON L6T 0C1 284 Canada 286 Email: victor.kuarsingh@rci.rogers.com 288 Chris Donley 289 CableLabs 290 858 Coal Creek Circle 291 Louisville, CO 80027 292 USA 294 Email: c.donley@cablelabs.com 296 Christopher Liljenstolpe 297 Telstra Corp 298 7/242 Exhibition Street 299 Melbourne, VIC 316 300 AU 302 Phone: +61 3 8647 6389 303 Fax: 304 Email: cdl@asgaard.org 305 URI: 307 Marla Azinger 308 Frontier Communications 309 Vancouver, WA 310 US 312 Phone: +1.360.513.2293 313 Fax: 314 Email: marla.azinger@frontiercorp.com 315 URI: