idnits 2.17.1 draft-weil-shared-transition-space-request-07.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-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 (Using the creation date from RFC5735, updated by this document, for RFC5378 checks: 2008-03-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 3, 2011) is 4589 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.shirasaki-nat444' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'RFC3068' is defined on line 391, but no explicit reference was found in the text == Unused Reference: 'RFC5969' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'RFC6319' is defined on line 408, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5735 (Obsoleted by RFC 6890) ** Downref: Normative reference to an Informational RFC: RFC 6264 == Outdated reference: A later version (-03) exists of draft-bdgks-arin-shared-transition-space-01 == Outdated reference: A later version (-06) exists of draft-donley-nat444-impacts-01 == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-13 == Outdated reference: A later version (-07) exists of draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-03 == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-04 -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 6304 (Obsoleted by RFC 7534) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Weil 3 Internet-Draft Time Warner Cable 4 Updates: 5735 (if approved) V. Kuarsingh 5 Intended status: BCP Rogers Communications 6 Expires: April 5, 2012 C. Donley 7 CableLabs 8 C. Liljenstolpe 9 Telstra Corp 10 M. Azinger 11 Frontier Communications 12 October 3, 2011 14 IANA Reserved IPv4 Prefix for Shared CGN Space 15 draft-weil-shared-transition-space-request-07 17 Abstract 19 This document requests the allocation of an IPv4 /10 address block to 20 be used as Shared Carrier Grade Network (CGN) Space. Service 21 Providers will use Shared CGN Space to number the interfaces that 22 connect CGN devices to Customer Premise Equipment (CPE). As this 23 document proposes the allocation of an additional special-use IPv4 24 address block, it updates RFC 5735. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 5, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 62 3. Alternatives to Shared CGN Space . . . . . . . . . . . . . . . 5 63 4. Use of Shared CGN Space . . . . . . . . . . . . . . . . . . . 6 64 5. Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5.1. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.2. Empirical Data . . . . . . . . . . . . . . . . . . . . . . 8 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 72 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction 77 IPv4 address space is nearly exhausted. However, ISPs must continue 78 to support IPv4 growth until IPv6 is fully deployed. To that end, 79 many ISPs will deploy Carrier Grade NAT (CGN) [RFC6264]. In order to 80 effectively deploy CGN, ISPs require a new IPv4 /10 address block. 81 This address block will be called the Shared Carrier Grade Network 82 (CGN) Space and will be used to number the interfaces that connect 83 CGN devices to CPE. 85 Shared CGN Space is distinct from [RFC1918] address space. Like 86 [RFC1918] space, Shared CGN Space must be unique to the network but 87 need not be globally unique. Unlike [RFC1918] address space, Shared 88 CGN Space is not available for any purpose other than numbering the 89 interfaces that connect a CGN to CPE. Additional applicability and 90 analysis of Shared CGN Space is described in 91 [I-D.bdgks-arin-shared-transition-space]. 93 This document requests the allocation of an IPv4 /10 address block to 94 be used as Shared Carrier Grade Network (CGN) Space. As this 95 document proposes the allocation of an additional special-use IPv4 96 address block, it updates [RFC5735]. 98 2. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 3. Alternatives to Shared CGN Space 106 The interfaces that connect CGN devices to CPE might conceivably be 107 numbered from any of the following address spaces: 109 o legitimately assigned globally unique address space 111 o usurped globally unique address space (i.e., squat space) 113 o [RFC1918] space 115 o Shared CGN Space 117 A Service Provider can number the interfaces in question from 118 legitimately assigned globally unique address space. While this 119 solution poses the fewest problems, it is impractical because 120 globally unique IPv4 address space is in short supply. While the 121 Regional Internet Registries (RIR) have enough address space to 122 allocate a single /10 to be shared by all Service Providers, they do 123 not have enough address space to make a unique assignment to each 124 Service Provider. 126 Service Providers MUST NOT number the interfaces in question from 127 usurped globally unique address space (i.e., squat space). If a 128 Service Provider leaks advertisements for squat space into the global 129 Internet, the legitimate owners of that address space may be 130 adversely impacted, as would those wishing to communicate with them. 131 Even if the Service Provider did not leak advertisements for squat 132 space, the Service Provider and its subscribers might lose 133 connectivity to the legitimate owner of that address space. 135 A Service Provider can number the interfaces in question from 136 [RFC1918] space if either of the following conditions are true: 138 o The Service Provider knows that the CPE/NAT works correctly when 139 the same [RFC1918] address block is used both on its inside and 140 outside interfaces. 142 o The Service Provider knows that the [RFC1918] address block that 143 it uses to number interfaces between the CGN and CPE is not used 144 on the subscriber side of the CPE. 146 Unless at least one of the conditions above is true, the Service 147 Provider cannot safely use [RFC1918] address space and must resort to 148 Shared CGN Space. This is typically the case in an unmanaged 149 service, where subscribers provide their own CPE and number their own 150 internal network. 152 4. Use of Shared CGN Space 154 Shared CGN Space is IPv4 address space reserved for Service Provider 155 use with the purpose of facilitating CGN deployment. Specifically: 157 o Shared CGN Space MUST NOT be utilized for any purpose other than 158 as "inside" addresses in a CGN environment (e.g., between the CGN 159 and CPE). 161 o Network equipment manufacturers MUST NOT use Shared CGN Space in 162 default or example device configurations. 164 o Shared CGN Space MUST NOT be used on the customer premise side of 165 a subscriber NAT device. 167 Because Shared CGN Space addresses have no meaning outside of the 168 Service Provider, routing information about Shared CGN Space networks 169 MUST NOT be propagated across Service Provider boundaries. Service 170 Providers MUST filter incoming advertisements regarding Shared CGN 171 Space. One exception to the above proscription against exchanging 172 routes for Shared CGN Space is in the case of a defined business 173 relationship between two Service Providers (e.g., for hosted CGN 174 service). 176 Packets with Shared CGN Space source or destination addresses MUST 177 NOT be forwarded across Service Provider boundaries. Service 178 Providers MUST filter such packets on ingress links. As above, one 179 exception to the above proscriptions is in the case of business 180 relationships such as hosted CGN service. 182 When running a single DNS infrastructure, Service Providers MUST NOT 183 include Shared CGN Space in zone files. When running a split DNS 184 infrastructure, Service Providers MUST NOT include Shared CGN Space 185 in external-facing zone files. 187 Reverse DNS queries for Shared CGN Space addresses MUST NOT be 188 forwarded to the global DNS infrastructure. DNS Providers SHOULD 189 filter requests for Shared CGN Space reverse DNS queries on recursive 190 nameservers. This is done to avoid having to set up something 191 similar to AS112.net for RFC 1918 private address space that a host 192 has incorrectly sent for a DNS reverse-mapping queries on the public 193 Internet [RFC6304]. 195 Because CGN service requires non-overlapping address space on each 196 side of the home NAT and CGN, entities misusing Shared CGN Space for 197 purposes other than for CGN service, as described in this document, 198 are likely to experience problems implementing or connecting to CGN 199 service at such time as they exhaust their supply of public IPv4 200 addresses. 202 5. Risk 204 5.1. Analysis 206 Some existing applications discover the outside address of their 207 local CPE, determine whether the address is reserved for special-use, 208 and behave differently based on that determination. If a new IPv4 209 address block is reserved for special-use and that block is used to 210 number CPE outside interfaces, some of the above-mentioned 211 applications may fail. 213 For example, assume that an application requires its peer (or some 214 other device) to initiate an incoming connection directly with its 215 CPE outside address. That application discovers the outside address 216 of its CPE and determines whether that address is reserved for 217 special-use. If the address is reserved for special-use, the 218 application rightly concludes the that address is not reachable from 219 the global Internet and behaves in one manner. If the address is not 220 reserved for special-use, the application assumes that the address is 221 reachable from the global Internet and behaves in another manner. 223 While the assumption that a non-special-use address is reachable from 224 the global Internet is generally safe, it is not always true (e.g., 225 when the CPE outside interface is numbered from globally unique 226 address space but that address is not advertised to the global 227 Internet as when it is behind a CGN). Such an assumption could cause 228 certain applications to behave incorrectly in those cases. 230 5.2. Empirical Data 232 As described in [RFC6269] and [I-D.donley-nat444-impacts], CGNs offer 233 a reasonable quality of experience for many basic services including 234 web, email, and Instant Messaging. This is true regardless of 235 whether the address range between the CGN and CPE is globally unique, 236 Shared CGN Space, or [RFC1918] space. However, CGNs do adversely 237 impact some advanced services, in particular: 239 1. Console gaming - some games fail when two subscribers using the 240 same outside public IPv4 address try to connect to each other. 242 2. Video streaming - performance is impacted when using one of 243 several popular video streaming technologies to deliver multiple 244 video streams to users behind particular CPE routers. 246 3. Peer-to-peer - some peer-to-peer applications cannot seed content 247 due to the inability to open incoming ports through the CGN. 248 Likewise, some SIP client implementations cannot receive incoming 249 calls unless they first initiate outgoing traffic or open an 250 incoming port through the CGN using [I-D.ietf-pcp-base] or 251 similar mechanism. 253 4. Geo-location - geo-location systems identify the location of the 254 CGN server, not the end host. 256 5. Simultaneous logins - some websites (particularly banking and 257 social networking websites) restrict the number of simultaneous 258 logins per outside public IPv4 address. 260 6. 6to4 - 6to4 requires globally reachable addresses, and will not 261 work in networks that employ addresses with limited topological 262 span such as those employing CGNs. 264 Based on testing documented in [I-D.donley-nat444-impacts], the CGN 265 impacts on 1-5 are comparable regardless of whether globally unique, 266 Shared CGN Space, or [RFC1918] addresses are used. There is, 267 however, a difference between the three alternatives in the treatment 268 of 6to4. 270 As described in [RFC6343], CPE routers do not attempt to initialize 271 6to4 tunnels when they are configured with [RFC1918] or [RFC5735] WAN 272 addresses. When configured with globally unique or Shared CGN Space 273 addresses, such devices may attempt to initiate 6to4, which would 274 fail. Service Providers can mitigate this issue using 6to4-PMT 275 [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] or blocking the 276 route to 192.88.99.1 and generating an IPv4 'destination unreachable' 277 message [RFC6343]. When the address range is well-defined, as with 278 Shared CGN Space, CPE router vendors can include Shared CGN Space in 279 their list of special-use addresses (e.g., [RFC5735]) and treat 280 Shared CGN Space similarly to [RFC1918] space. When the CGN-CPE 281 address range is not well-defined, as in the case of globally unique 282 space, it will be more difficult for CPE router vendors to mitigate 283 against this issue. 285 Thus, when comparing the use of [RFC1918] and Shared CGN Space, 286 Shared CGN Space poses an additional impact on 6to4 connectivity, 287 which can be mitigated by Service Provider or CPE router vendor 288 action. On the other hand, the use of [RFC1918] address space poses 289 more of a challenge viz-a-viz Shared CGN Space when the subscriber 290 and Service Provider use overlapping [RFC1918] space, which will be 291 outside the Service Provider's control in the case of unmanaged 292 service. Service Providers have indicated that it is more 293 challenging to mitigate the possibility of overlapping [RFC1918] 294 address space on both sides of the CPE router than it is to mitigate 295 the 6to4 impacts of Shared CGN Space. 297 6. Security Considerations 299 Similar to other [RFC5735] special use IPv4 addresses, Shared CGN 300 Space does not directly raise security issues. However, the Internet 301 does not inherently protect against abuse of these addresses. 302 Attacks have been mounted that depend on the unexpected use of 303 similar special-use addresses. Network operators are encouraged to 304 review this document and determine what security policies should be 305 associated with this address block within their specific operating 306 environments and should consider including Shared CGN Space in 307 Ingress Filter lists [RFC3704] unless their Internet service 308 incorporates a CGN. 310 To mitigate against potential misuse of Shared CGN Space, except 311 where required for hosted CGN service or similar business 312 relationship, 314 o Routing information about Shared CGN Space networks MUST NOT be 315 propagated across Service Provider boundaries. Service Providers 316 MUST filter incoming advertisements regarding Shared CGN Space. 318 o Packets with Shared CGN Space source or destination addresses MUST 319 NOT be forwarded across Service Provider boundaries. Service 320 Providers MUST filter such packets on ingress links. 322 o Service Providers MUST NOT include Shared CGN Space in external- 323 facing DNS zone files. 325 o Reverse DNS queries for Shared CGN Space addresses MUST NOT be 326 forwarded to the global DNS infrastructure. 328 o DNS Providers SHOULD filter requests for Shared CGN Space reverse 329 DNS queries on recursive nameservers. 331 7. IANA Considerations 333 IANA is asked to record the allocation of an IPv4 /10 for use as 334 Shared CGN Space. 336 The Shared CGN Space address range is: x.x.0.0/10. [Note to RFC 337 Editor: this address range to be added before publication] 339 8. References 341 8.1. Normative References 343 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 344 E. Lear, "Address Allocation for Private Internets", 345 BCP 5, RFC 1918, February 1996. 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, March 1997. 350 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 351 BCP 153, RFC 5735, January 2010. 353 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 354 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 355 June 2011. 357 8.2. Informative References 359 [I-D.bdgks-arin-shared-transition-space] 360 Barber, S., Delong, O., Grundemann, C., Kuarsingh, V., and 361 B. Schliesser, "ARIN Draft Policy 2011-5: Shared 362 Transition Space", 363 draft-bdgks-arin-shared-transition-space-01 (work in 364 progress), July 2011. 366 [I-D.donley-nat444-impacts] 367 Donley, C., Howard, L., Kuarsingh, V., Chandrasekaran, A., 368 and V. Ganti, "Assessing the Impact of NAT444 on Network 369 Applications", draft-donley-nat444-impacts-01 (work in 370 progress), October 2010. 372 [I-D.ietf-pcp-base] 373 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 374 Selkirk, "Port Control Protocol (PCP)", 375 draft-ietf-pcp-base-13 (work in progress), July 2011. 377 [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] 378 Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider 379 Managed Tunnels", 380 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-03 381 (work in progress), September 2011. 383 [I-D.shirasaki-nat444] 384 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 385 and H. Ashida, "NAT444", draft-shirasaki-nat444-04 (work 386 in progress), July 2011. 388 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 389 via IPv4 Clouds", RFC 3056, February 2001. 391 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 392 RFC 3068, June 2001. 394 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 395 Networks", BCP 84, RFC 3704, March 2004. 397 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 398 Infrastructures (6rd) -- Protocol Specification", 399 RFC 5969, August 2010. 401 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 402 Roberts, "Issues with IP Address Sharing", RFC 6269, 403 June 2011. 405 [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", 406 RFC 6304, July 2011. 408 [RFC6319] Azinger, M. and L. Vegoda, "Issues Associated with 409 Designating Additional Private IPv4 Address Space", 410 RFC 6319, July 2011. 412 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 413 RFC 6343, August 2011. 415 Appendix A. Acknowledgments 417 Thanks to the following people (in alphabetical order) for their 418 guidance and feedback: 420 Stan Barber 422 John Brzozowski 424 Isaiah Connell 426 Greg Davies 428 Owen DeLong 430 Kirk Erichsen 432 Wes George 434 Chris Grundemann 436 Tony Hain 438 Philip Matthews 440 John Pomeroy 442 Barbara Stark 444 Jean-Francois Tremblay 446 Leo Vegoda 448 Steven Wright 450 Ikuhei Yamagata 452 Authors' Addresses 454 Jason Weil 455 Time Warner Cable 456 13820 Sunrise Valley Drive 457 Herndon, VA 20171 458 USA 460 Email: jason.weil@twcable.com 462 Victor Kuarsingh 463 Rogers Communications 464 8200 Dixie Road 465 Brampton, ON L6T 0C1 466 Canada 468 Email: victor.kuarsingh@gmail.com 470 Chris Donley 471 CableLabs 472 858 Coal Creek Circle 473 Louisville, CO 80027 474 USA 476 Email: c.donley@cablelabs.com 478 Christopher Liljenstolpe 479 Telstra Corp 480 7/242 Exhibition Street 481 Melbourne, VIC 316 482 Australia 484 Phone: +61 3 8647 6389 485 Email: cdl@asgaard.org 487 Marla Azinger 488 Frontier Communications 489 Vancouver, WA 490 USA 492 Phone: +1.360.513.2293 493 Email: marla.azinger@frontiercorp.com