idnits 2.17.1 draft-weil-shared-transition-space-request-15.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. -- The abstract seems to indicate that this document updates RFC1918, but the header doesn't have an 'Updates:' line to match this. 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 (February 16, 2012) is 4450 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) ** Obsolete normative reference: RFC 5735 (Obsoleted by RFC 6890) == Outdated reference: A later version (-06) exists of draft-donley-nat444-impacts-03 == 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 (-08) exists of draft-shirasaki-isp-shared-addr-06 -- Obsolete informational reference (is this intentional?): RFC 6304 (Obsoleted by RFC 7534) Summary: 1 error (**), 0 flaws (~~), 6 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: August 19, 2012 C. Donley 7 CableLabs 8 C. Liljenstolpe 9 Telstra Corp 10 M. Azinger 11 Frontier Communications 12 February 16, 2012 14 IANA Reserved IPv4 Prefix for Shared Address Space 15 draft-weil-shared-transition-space-request-15 17 Abstract 19 This document requests the allocation of an IPv4 /10 address block to 20 be used as Shared Address Space to accommodate the needs of Carrier 21 Grade Network Address Translation (CGN) devices. It is anticipated 22 that Service Providers will use this Shared Address Space to number 23 the interfaces that connect CGN devices to Customer Premise Equipment 24 (CPE). 26 Shared Address Space is distinct from RFC1918 private address space 27 because it is intended for use on Service Provider networks. 28 However, it may be used in a manner similar to RFC 1918 private 29 address space on routing equipment that is able to do address 30 translation across router interfaces when the addresses are identical 31 on two different interfaces. Details are provided in the text of 32 this document. 34 As this document proposes the allocation of an additional special-use 35 IPv4 address block, it updates RFC 5735. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on August 19, 2012. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 73 3. Alternatives to Shared Address Space . . . . . . . . . . . . . 6 74 4. Use of Shared CGN Space . . . . . . . . . . . . . . . . . . . 7 75 5. Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5.1. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 5.2. Empirical Data . . . . . . . . . . . . . . . . . . . . . . 8 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 83 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 IPv4 address space is nearly exhausted. However, ISPs must continue 89 to support IPv4 growth until IPv6 is fully deployed. To that end, 90 many ISPs will deploy Carrier Grade NAT (CGN) such as that described 91 in [RFC6264]. Because CGNs are used on networks where public address 92 space is expected, and currently available private address space 93 causes operational issues when used in this context, ISPs require a 94 new IPv4 /10 address block. This address block will be called the 95 Shared Address Space and will be used to number the interfaces that 96 connect CGN devices to Customer Premise Equipment (CPE). 98 Shared Address Space is similar to [RFC1918] private address space in 99 that it is not global routable address space and can be used by 100 multiple pieces of equipment. However, Shared Address Space has 101 limitations in its use that the current [RFC1918] private address 102 space does not have. In particular, Shared Address Space can only be 103 used in Service Provider networks or on routing equipment that is 104 able to do address translation across router interfaces when the 105 addresses are identical on two different interfaces. 107 This document requests the allocation of an IPv4 /10 address block to 108 be used as Shared Address Space. In conversations with many ISPs, a 109 /10 is the smallest block that will allow them to deploy CGNs on a 110 regional basis without requiring nested CGNs. For Instance, as 111 described in [I-D.shirasaki-isp-shared-addr], a /10 is sufficient to 112 service Points of Presence in the Tokyo area. 114 As this document proposes the allocation of an additional special-use 115 IPv4 address block, it updates [RFC5735]. 117 2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 3. Alternatives to Shared Address Space 125 The interfaces that connect CGN devices to CPE might conceivably be 126 numbered from any of the following address spaces: 128 o legitimately assigned globally unique address space 130 o usurped globally unique address space (i.e., squat space) 132 o [RFC1918] space 134 o Shared Address Space 136 A Service Provider can number the interfaces in question from 137 legitimately assigned globally unique address space. While this 138 solution poses the fewest problems, it is impractical because 139 globally unique IPv4 address space is in short supply. While the 140 Regional Internet Registries (RIR) have enough address space to 141 allocate a single /10 to be shared by all Service Providers, they do 142 not have enough address space to make a unique assignment to each 143 Service Provider. 145 Service Providers MUST NOT number the interfaces in question from 146 usurped globally unique address space (i.e., squat space). If a 147 Service Provider leaks advertisements for squat space into the global 148 Internet, the legitimate holders of that address space may be 149 adversely impacted, as would those wishing to communicate with them. 150 Even if the Service Provider did not leak advertisements for squat 151 space, the Service Provider and its subscribers might lose 152 connectivity to the legitimate holders of that address space. 154 A Service Provider can number the interfaces in question from 155 [RFC1918] space if either of the following conditions are true: 157 o The Service Provider knows that the CPE/NAT works correctly when 158 the same [RFC1918] address block is used both on its inside and 159 outside interfaces. 161 o The Service Provider knows that the [RFC1918] address block that 162 it uses to number interfaces between the CGN and CPE is not used 163 on the subscriber side of the CPE. 165 Unless at least one of the conditions above is true, the Service 166 Provider cannot safely use [RFC1918] address space and must resort to 167 Shared Address Space. This is typically the case in an unmanaged 168 service, where subscribers provide their own CPE and number their own 169 internal network. 171 4. Use of Shared CGN Space 173 Shared Address Space is IPv4 address space designated for Service 174 Provider use with the purpose of facilitating CGN deployment. Also, 175 Shared Address Space can be used as additional non-globally routable 176 space on routing equipment that is able to do address translation 177 across router interfaces when the addresses are identical on two 178 different interfaces. 180 Devices MUST be capable of performing address translation when 181 identical Shared Address Space ranges are used on two different 182 interfaces. 184 Packets with Shared Address Space source or destination addresses 185 MUST NOT be forwarded across Service Provider boundaries. Service 186 Providers MUST filter such packets on ingress links. As above, one 187 exception to the above proscriptions is in the case of business 188 relationships such as hosted CGN service. 190 When running a single DNS infrastructure, Service Providers MUST NOT 191 include Shared Address Space in zone files. When running a split DNS 192 infrastructure, Service Providers MUST NOT include Shared Address 193 Space in external-facing zone files. 195 Reverse DNS queries for Shared Address Space addresses MUST NOT be 196 forwarded to the global DNS infrastructure. DNS Providers SHOULD 197 filter requests for Shared Address Space reverse DNS queries on 198 recursive nameservers. This is done to avoid having to set up 199 something similar to AS112.net for RFC 1918 private address space 200 that a host has incorrectly sent for a DNS reverse-mapping queries on 201 the public Internet [RFC6304]. 203 Because CGN service requires non-overlapping address space on each 204 side of the home NAT and CGN, entities using Shared Address Space for 205 purposes other than for CGN service, as described in this document, 206 are likely to experience problems implementing or connecting to CGN 207 service at such time as they exhaust their supply of public IPv4 208 addresses. 210 5. Risk 212 5.1. Analysis 214 Some existing applications discover the outside address of their 215 local CPE, determine whether the address is reserved for special-use, 216 and behave differently based on that determination. If a new IPv4 217 address block is reserved for special-use and that block is used to 218 number CPE outside interfaces, some of the above-mentioned 219 applications may fail. 221 For example, assume that an application requires its peer (or some 222 other device) to initiate an incoming connection directly with its 223 CPE outside address. That application discovers the outside address 224 of its CPE and determines whether that address is reserved for 225 special-use. If the address is reserved for special-use, the 226 application rightly concludes the that address is not reachable from 227 the global Internet and behaves in one manner. If the address is not 228 reserved for special-use, the application assumes that the address is 229 reachable from the global Internet and behaves in another manner. 231 While the assumption that a non-special-use address is reachable from 232 the global Internet is generally safe, it is not always true (e.g., 233 when the CPE outside interface is numbered from globally unique 234 address space but that address is not advertised to the global 235 Internet as when it is behind a CGN). Such an assumption could cause 236 certain applications to behave incorrectly in those cases. 238 5.2. Empirical Data 240 The primary motivation for the allocation of Shared Address Space is 241 as address space for CGNs; the use and impact of CGNs has been 242 previously described in [RFC6269] and [I-D.donley-nat444-impacts]. 243 Some of the services adversely impacted by CGNs are: 245 1. Console gaming - some games fail when two subscribers using the 246 same outside public IPv4 address try to connect to each other. 248 2. Video streaming - performance is impacted when using one of 249 several popular video streaming technologies to deliver multiple 250 video streams to users behind particular CPE routers. 252 3. Peer-to-peer - some peer-to-peer applications cannot seed content 253 due to the inability to open incoming ports through the CGN. 254 Likewise, some SIP client implementations cannot receive incoming 255 calls unless they first initiate outgoing traffic or open an 256 incoming port through the CGN using [I-D.ietf-pcp-base] or 257 similar mechanism. 259 4. Geo-location - geo-location systems identify the location of the 260 CGN server, not the end host. 262 5. Simultaneous logins - some websites (particularly banking and 263 social networking websites) restrict the number of simultaneous 264 logins per outside public IPv4 address. 266 6. 6to4 - 6to4 requires globally reachable addresses, and will not 267 work in networks that employ addresses with limited topological 268 span such as those employing CGNs. 270 Based on testing documented in [I-D.donley-nat444-impacts], the CGN 271 impacts on 1-5 are comparable regardless of whether globally unique, 272 Shared Address Space, or [RFC1918] addresses are used. There is, 273 however, a difference between the three alternatives in the treatment 274 of 6to4. 276 As described in [RFC6343], CPE routers do not attempt to initialize 277 6to4 tunnels when they are configured with [RFC1918] or [RFC5735] WAN 278 addresses. When configured with globally unique or Shared Address 279 Space addresses, such devices may attempt to initiate 6to4, which 280 would fail. Service Providers can mitigate this issue using 6to4-PMT 281 [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] or blocking the 282 route to 192.88.99.1 and generating an IPv4 'destination unreachable' 283 message [RFC6343]. When the address range is well-defined, as with 284 Shared Address Space, CPE router vendors can include Shared Address 285 Space in their list of special-use addresses (e.g., [RFC5735]) and 286 treat Shared Address Space similarly to [RFC1918] space. When the 287 CGN-CPE address range is not well-defined, as in the case of globally 288 unique space, it will be more difficult for CPE router vendors to 289 mitigate against this issue. 291 Thus, when comparing the use of [RFC1918] and Shared Address Space, 292 Shared Address Space poses an additional impact on 6to4 connectivity, 293 which can be mitigated by Service Provider or CPE router vendor 294 action. On the other hand, the use of [RFC1918] address space poses 295 more of a challenge vis-a-vis Shared Address Space when the 296 subscriber and Service Provider use overlapping [RFC1918] space, 297 which will be outside the Service Provider's control in the case of 298 unmanaged service. Service Providers have indicated that it is more 299 challenging to mitigate the possibility of overlapping [RFC1918] 300 address space on both sides of the CPE router than it is to mitigate 301 the 6to4 impacts of Shared Address Space. 303 6. Security Considerations 305 Similar to other [RFC5735] special use IPv4 addresses, Shared Address 306 Space does not directly raise security issues. However, the Internet 307 does not inherently protect against abuse of these addresses. 308 Attacks have been mounted that depend on the unexpected use of 309 similar special-use addresses. Network operators are encouraged to 310 review this document and determine what security policies should be 311 associated with this address block within their specific operating 312 environments and should consider including Shared Address Space in 313 Ingress Filter lists [RFC3704] unless their Internet service 314 incorporates a CGN. 316 To mitigate against potential misuse of Shared Address Space, except 317 where required for hosted CGN service or similar business 318 relationship, 320 o Routing information about Shared Address Space networks MUST NOT 321 be propagated across Service Provider boundaries. Service 322 Providers MUST filter incoming advertisements regarding Shared 323 Address Space. 325 o Packets with Shared Address Space source or destination addresses 326 MUST NOT be forwarded across Service Provider boundaries. Service 327 Providers MUST filter such packets on ingress links. 329 o Service Providers MUST NOT include Shared Address Space in 330 external-facing DNS zone files. 332 o Reverse DNS queries for Shared Address Space addresses MUST NOT be 333 forwarded to the global DNS infrastructure. 335 o DNS Providers SHOULD filter requests for Shared Address Space 336 reverse DNS queries on recursive nameservers. 338 7. IANA Considerations 340 IANA is asked to record the allocation of an IPv4 /10 for use as 341 Shared Address Space. 343 The Shared Address Space address range is: x.x.0.0/10. [Note to RFC 344 Editor: this address range to be added before publication] 346 8. References 348 8.1. Normative References 350 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 351 E. Lear, "Address Allocation for Private Internets", 352 BCP 5, RFC 1918, February 1996. 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 358 BCP 153, RFC 5735, January 2010. 360 8.2. Informative References 362 [I-D.donley-nat444-impacts] 363 Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U. 364 Colorado, "Assessing the Impact of Carrier-Grade NAT on 365 Network Applications", draft-donley-nat444-impacts-03 366 (work in progress), November 2011. 368 [I-D.ietf-pcp-base] 369 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 370 Selkirk, "Port Control Protocol (PCP)", 371 draft-ietf-pcp-base-13 (work in progress), July 2011. 373 [I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel] 374 Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider 375 Managed Tunnels", 376 draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-03 377 (work in progress), September 2011. 379 [I-D.shirasaki-isp-shared-addr] 380 Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 381 and H. Ashida, "ISP Shared Address", 382 draft-shirasaki-isp-shared-addr-06 (work in progress), 383 July 2011. 385 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 386 Networks", BCP 84, RFC 3704, March 2004. 388 [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental 389 Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, 390 June 2011. 392 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 393 Roberts, "Issues with IP Address Sharing", RFC 6269, 394 June 2011. 396 [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", 397 RFC 6304, July 2011. 399 [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", 400 RFC 6343, August 2011. 402 Appendix A. Acknowledgments 404 Thanks to the following people (in alphabetical order) for their 405 guidance and feedback: 407 Stan Barber 409 John Brzozowski 411 Isaiah Connell 413 Greg Davies 415 Owen DeLong 417 Kirk Erichsen 419 Wes George 421 Chris Grundemann 423 Tony Hain 425 Philip Matthews 427 John Pomeroy 429 Barbara Stark 431 Jean-Francois Tremblay 433 Leo Vegoda 435 Steven Wright 437 Ikuhei Yamagata 439 Authors' Addresses 441 Jason Weil 442 Time Warner Cable 443 13820 Sunrise Valley Drive 444 Herndon, VA 20171 445 USA 447 Email: jason.weil@twcable.com 449 Victor Kuarsingh 450 Rogers Communications 451 8200 Dixie Road 452 Brampton, ON L6T 0C1 453 Canada 455 Email: victor.kuarsingh@gmail.com 457 Chris Donley 458 CableLabs 459 858 Coal Creek Circle 460 Louisville, CO 80027 461 USA 463 Email: c.donley@cablelabs.com 465 Christopher Liljenstolpe 466 Telstra Corp 467 7/242 Exhibition Street 468 Melbourne, VIC 316 469 Australia 471 Phone: +61 3 8647 6389 472 Email: cdl@asgaard.org 474 Marla Azinger 475 Frontier Communications 476 Vancouver, WA 477 USA 479 Phone: +1.360.513.2293 480 Email: marla.azinger@frontiercorp.com