[Note that this file is a concatenation of more than one RFC.] Internet Engineering Task Force (IETF) M. Cotton Request for Comments: 5735 L. Vegoda BCP: 153 ICANN Obsoletes: 3330 January 2010 Category: Best Current Practice ISSN: 2070-1721 Special Use IPv4 Addresses Abstract This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5735. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Cotton & Vegoda Best Current Practice [Page 1] RFC 5735 Special Use IPv4 Addresses January 2010 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Global and Other Specialized Address Blocks . . . . . . . . . 3 4. Summary Table . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Assignments of IPv4 Blocks for New Specialized Uses . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Differences between This Document and RFC 3330 . . . 10 Cotton & Vegoda Best Current Practice [Page 2] RFC 5735 Special Use IPv4 Addresses January 2010 1. Introduction Throughout its history, the Internet has employed a central Internet Assigned Numbers Authority (IANA) responsible for the allocation and assignment of various identifiers needed for the operation of the Internet [RFC1174]. In the case of the IPv4 address space, the IANA allocates parts of the address space to Regional Internet Registries (RIRs) according to their established needs. These RIRs are responsible for the registration of IPv4 addresses to operators and users of the Internet within their regions. On an ongoing basis, the IANA has been designated by the IETF to make assignments in support of the Internet Standards Process [RFC2860]. Section 4 of that document describes that assignment process. Small portions of the IPv4 address space have been allocated or assigned directly by the IANA for global or other specialized purposes. These allocations and assignments have been documented in a variety of RFCs and other documents. This document is intended to collect these scattered references and provide a current list of special use IPv4 addresses. This document is a revision of RFC 3330 [RFC3330], which it obsoletes; its primary purpose is to reflect the changes to the list of special IPv4 assignments since the publication of RFC 3330. It is a companion to [RFC5156], which describes special IPv6 addresses. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. 3. Global and Other Specialized Address Blocks 0.0.0.0/8 - Addresses in this block refer to source hosts on "this" network. Address 0.0.0.0/32 may be used as a source address for this host on this network; other addresses within 0.0.0.0/8 may be used to refer to specified hosts on this network ([RFC1122], Section 3.2.1.3). 10.0.0.0/8 - This block is set aside for use in private networks. Its intended use is documented in [RFC1918]. As described in that RFC, addresses within this block do not legitimately appear on the public Internet. These addresses can be used without any coordination with IANA or an Internet registry. Cotton & Vegoda Best Current Practice [Page 3] RFC 5735 Special Use IPv4 Addresses January 2010 127.0.0.0/8 - This block is assigned for use as the Internet host loopback address. A datagram sent by a higher-level protocol to an address anywhere within this block loops back inside the host. This is ordinarily implemented using only 127.0.0.1/32 for loopback. As described in [RFC1122], Section 3.2.1.3, addresses within the entire 127.0.0.0/8 block do not legitimately appear on any network anywhere. 169.254.0.0/16 - This is the "link local" block. As described in [RFC3927], it is allocated for communication between hosts on a single link. Hosts obtain these addresses by auto-configuration, such as when a DHCP server cannot be found. 172.16.0.0/12 - This block is set aside for use in private networks. Its intended use is documented in [RFC1918]. As described in that RFC, addresses within this block do not legitimately appear on the public Internet. These addresses can be used without any coordination with IANA or an Internet registry. 192.0.0.0/24 - This block is reserved for IETF protocol assignments. At the time of writing this document, there are no current assignments. Allocation policy for future assignments is given in [RFC5736]. 192.0.2.0/24 - This block is assigned as "TEST-NET-1" for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation. As described in [RFC5737], addresses within this block do not legitimately appear on the public Internet and can be used without any coordination with IANA or an Internet registry. See [RFC1166]. 192.88.99.0/24 - This block is allocated for use as 6to4 relay anycast addresses, in [RFC3068]. In contrast with previously described blocks, packets destined to addresses from this block do appear in the public Internet. [RFC3068], Section 7, describes operational practices to prevent the malicious use of this block in routing protocols. 192.168.0.0/16 - This block is set aside for use in private networks. Its intended use is documented in [RFC1918]. As described in that RFC, addresses within this block do not legitimately appear on the public Internet. These addresses can be used without any coordination with IANA or an Internet registry. 198.18.0.0/15 - This block has been allocated for use in benchmark tests of network interconnect devices. [RFC2544] explains that this range was assigned to minimize the chance of conflict in case a Cotton & Vegoda Best Current Practice [Page 4] RFC 5735 Special Use IPv4 Addresses January 2010 testing device were to be accidentally connected to part of the Internet. Packets with source addresses from this range are not meant to be forwarded across the Internet. 198.51.100.0/24 - This block is assigned as "TEST-NET-2" for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation. As described in [RFC5737], addresses within this block do not legitimately appear on the public Internet and can be used without any coordination with IANA or an Internet registry. 203.0.113.0/24 - This block is assigned as "TEST-NET-3" for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation. As described in [RFC5737], addresses within this block do not legitimately appear on the public Internet and can be used without any coordination with IANA or an Internet registry. 224.0.0.0/4 - This block, formerly known as the Class D address space, is allocated for use in IPv4 multicast address assignments. The IANA guidelines for assignments from this space are described in [RFC3171]. 240.0.0.0/4 - This block, formerly known as the Class E address space, is reserved for future use; see [RFC1112], Section 4. The one exception to this is the "limited broadcast" destination address 255.255.255.255. As described in [RFC0919] and [RFC0922], packets with this destination address are not forwarded at the IP layer. Cotton & Vegoda Best Current Practice [Page 5] RFC 5735 Special Use IPv4 Addresses January 2010 4. Summary Table Address Block Present Use Reference ------------------------------------------------------------------ 0.0.0.0/8 "This" Network RFC 1122, Section 3.2.1.3 10.0.0.0/8 Private-Use Networks RFC 1918 127.0.0.0/8 Loopback RFC 1122, Section 3.2.1.3 169.254.0.0/16 Link Local RFC 3927 172.16.0.0/12 Private-Use Networks RFC 1918 192.0.0.0/24 IETF Protocol Assignments RFC 5736 192.0.2.0/24 TEST-NET-1 RFC 5737 192.88.99.0/24 6to4 Relay Anycast RFC 3068 192.168.0.0/16 Private-Use Networks RFC 1918 198.18.0.0/15 Network Interconnect Device Benchmark Testing RFC 2544 198.51.100.0/24 TEST-NET-2 RFC 5737 203.0.113.0/24 TEST-NET-3 RFC 5737 224.0.0.0/4 Multicast RFC 3171 240.0.0.0/4 Reserved for Future Use RFC 1112, Section 4 255.255.255.255/32 Limited Broadcast RFC 919, Section 7 RFC 922, Section 7 5. Assignments of IPv4 Blocks for New Specialized Uses The IANA has responsibility for making assignments of protocol parameters used in the Internet according to the requirements of the "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority" [RFC2860]. Among other things, [RFC2860] requires that protocol parameters be assigned according to the criteria and procedures specified in RFCs, including Proposed, Draft, and full Internet Standards and Best Current Practice documents, and any other RFC that calls for IANA assignment. The domain name and IP address spaces involve policy issues (in addition to technical issues) so that the requirements of [RFC2860] do not apply generally to those spaces. Nonetheless, the IANA is responsible for ensuring assignments of IPv4 addresses as needed in support of the Internet Standards Process. When a portion of the IPv4 address space is specifically required by an RFC, the technical requirements (e.g., size, prefix length) for the portion should be described [RFC5226]. Immediately before the RFC is published, the IANA will, in consultation with the Regional Internet Registries, make the necessary assignment and notify the RFC Editor of the particulars for inclusion in the RFC as published. As required by [RFC2860], the IANA will also make necessary experimental assignments of IPv4 addresses, also in consultation with the Regional Internet Registries. Cotton & Vegoda Best Current Practice [Page 6] RFC 5735 Special Use IPv4 Addresses January 2010 6. IANA Considerations This document describes the IANA's past and current practices and does not create any new requirements for assignments or allocations by the IANA. 7. Security Considerations The particular assigned values of special use IPv4 addresses cataloged in this document do not directly raise security issues. However, the Internet does not inherently protect against abuse of these addresses. If you expect (for instance) that all packets from a private address space such as the 10.0.0.0/8 block or the link local block 169.254.0.0/16 originate within your subnet, all routers at the border of your network should filter such packets that originate from outside your network. Attacks have been mounted that depend on the unexpected use of some of these addresses. It should also be noted that some of these address spaces may be used legitimately outside a single administrative domain, and may appear on the global Internet. Security policy SHOULD NOT blindly filter all of these address spaces without due consideration, and network operators are encouraged to review this document, and references contained therein, and determine what security policies should be associated with each of these address blocks within their specific operating environments. 8. Acknowledgments Many people have made comments on draft versions of this document. The authors would especially like to thank Scott Bradner, Randy Bush, Harald Alvestrand, Peter Koch, Alfred Hoenes, and Jari Arkko for their constructive feedback and comments. They would also like to offer a special note of thanks to APNIC, which nominated 198.51.100.0/24 and 203.0.113.0/24. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC 919, October 1984. Cotton & Vegoda Best Current Practice [Page 7] RFC 5735 Special Use IPv4 Addresses January 2010 [RFC0922] Mogul, J., "Broadcasting Internet datagrams in the presence of subnets", STD 5, RFC 922, October 1984. [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, July 1990. [RFC1174] Cerf, V., "IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet "connected" status", RFC 1174, August 1990. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999. [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000. [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 3171, August 2001. [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, April 2008. Cotton & Vegoda Best Current Practice [Page 8] RFC 5735 Special Use IPv4 Addresses January 2010 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special Purpose Address Registry", RFC 5736, January 2010. [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010. Cotton & Vegoda Best Current Practice [Page 9] RFC 5735 Special Use IPv4 Addresses January 2010 Appendix A. Differences between This Document and RFC 3330 Address blocks that were reserved for a special purpose in RFC 3330 but are no longer reserved for any special purpose and are available for allocation are no longer listed in Sections 4 or 5. The following blocks have become available: - 14.0.0.0/8 is no longer set aside for assignments to the international system of Public Data Networks [RFC1700], page 181. It is now available for allocation to RIRs in the normal way. - 24.0.0.0/8 is no longer listed as the addresses in that block have been managed by the American Registry for Internet Numbers (ARIN) in the normal way since 2001. - 39.0.0.0/8 is no longer listed as it has been subject to allocation to an RIR for assignment in the normal manner since 2001. - 128.0.0.0/16 is not reserved and is subject to future allocation by a Regional Internet Registry for assignment in the normal manner. - 191.255.0.0/16 is not reserved and is subject to future allocation by a RIR for assignment in the normal manner. - 198.51.100.0/24 is assigned as "TEST-NET-2" for use in documentation and example code. - 203.0.113.0/24 is assigned as "TEST-NET-3" for use in documentation and example code. - 223.255.255.0/24 is not reserved and is subject to future allocation by an RIR for assignment in the normal manner. Cotton & Vegoda Best Current Practice [Page 10] RFC 5735 Special Use IPv4 Addresses January 2010 Authors' Addresses Michelle Cotton Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 USA Phone: +1-310-823-9358 EMail: michelle.cotton@icann.org URI: http://www.iana.org/ Leo Vegoda Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 USA Phone: +1-310-823-9358 EMail: leo.vegoda@icann.org URI: http://www.iana.org/ Cotton & Vegoda Best Current Practice [Page 11] ========================================================================= Internet Engineering Task Force (IETF) J. Weil Request for Comments: 6598 Time Warner Cable BCP: 153 V. Kuarsingh Updates: 5735 Rogers Communications Category: Best Current Practice C. Donley ISSN: 2070-1721 CableLabs C. Liljenstolpe Telstra Corp. M. Azinger Frontier Communications April 2012 IANA-Reserved IPv4 Prefix for Shared Address Space Abstract This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier- Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE). Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks. However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document. This document details the allocation of an additional special-use IPv4 address block and updates RFC 5735. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6598. Weil, et al. Best Current Practice [Page 1] RFC 6598 Shared Address Space Request April 2012 IESG Note A number of operators have expressed a need for the special-purpose IPv4 address allocation described by this document. During deliberations, the IETF community demonstrated very rough consensus in favor of the allocation. While operational expedients, including the special-purpose address allocation described in this document, may help solve a short-term operational problem, the IESG and the IETF remain committed to the deployment of IPv6. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ....................................................3 2. Requirements Language ...........................................3 3. Alternatives to Shared Address Space ............................3 4. Use of Shared CGN Space .........................................4 5. Risk ............................................................5 5.1. Analysis ...................................................5 5.2. Empirical Data .............................................6 6. Security Considerations .........................................7 7. IANA Considerations .............................................8 8. References ......................................................8 8.1. Normative References .......................................8 8.2. Informative References .....................................9 Appendix A. Acknowledgments .......................................10 Weil, et al. Best Current Practice [Page 2] RFC 6598 Shared Address Space Request April 2012 1. Introduction IPv4 address space is nearly exhausted. However, ISPs must continue to support IPv4 growth until IPv6 is fully deployed. To that end, many ISPs will deploy a Carrier-Grade NAT (CGN) device, such as that described in [RFC6264]. Because CGNs are used on networks where public address space is expected, and currently available private address space causes operational issues when used in this context, ISPs require a new IPv4 /10 address block. This address block will be called the "Shared Address Space" and will be used to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE). Shared Address Space is similar to [RFC1918] private address space in that it is not globally routable address space and can be used by multiple pieces of equipment. However, Shared Address Space has limitations in its use that the current [RFC1918] private address space does not have. In particular, Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space. In conversations with many ISPs, a /10 is the smallest block that will allow them to deploy CGNs on a regional basis without requiring nested CGNs. For instance, as described in [ISP-SHARED-ADDR], a /10 is sufficient to service Points of Presence in the Tokyo area. This document details the allocation of an additional special-use IPv4 address block and updates [RFC5735]. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Alternatives to Shared Address Space The interfaces that connect CGN devices to CPE might conceivably be numbered from any of the following address spaces: o legitimately assigned globally unique address space o usurped globally unique address space (i.e., squat space) Weil, et al. Best Current Practice [Page 3] RFC 6598 Shared Address Space Request April 2012 o [RFC1918] space o Shared Address Space A Service Provider can number the interfaces in question from legitimately assigned globally unique address space. While this solution poses the fewest problems, it is impractical because globally unique IPv4 address space is in short supply. While the Regional Internet Registries (RIRs) have enough address space to allocate a single /10 to be shared by all Service Providers, they do not have enough address space to make a unique assignment to each Service Provider. Service Providers MUST NOT number the interfaces in question from usurped globally unique address space (i.e., squat space). If a Service Provider leaks advertisements for squat space into the global Internet, the legitimate holders of that address space may be adversely impacted, as would those wishing to communicate with them. Even if the Service Provider did not leak advertisements for squat space, the Service Provider and its subscribers might lose connectivity to the legitimate holders of that address space. A Service Provider can number the interfaces in question from [RFC1918] space if at least one of the following conditions is true: o The Service Provider knows that the CPE/NAT works correctly when the same [RFC1918] address block is used on both its inside and outside interfaces. o The Service Provider knows that the [RFC1918] address block that it uses to number interfaces between the CGN and CPE is not used on the subscriber side of the CPE. Unless at least one of the conditions above is true, the Service Provider cannot safely use [RFC1918] address space and must resort to Shared Address Space. This is typically the case in an unmanaged service, where subscribers provide their own CPE and number their own internal network. 4. Use of Shared CGN Space Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment. Also, Shared Address Space can be used as additional non-globally routable space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Weil, et al. Best Current Practice [Page 4] RFC 6598 Shared Address Space Request April 2012 Devices MUST be capable of performing address translation when identical Shared Address Space ranges are used on two different interfaces. Packets with Shared Address Space source or destination addresses MUST NOT be forwarded across Service Provider boundaries. Service Providers MUST filter such packets on ingress links. One exception to this paragraph's proscription is in the case of business relationships, such as hosted CGN services. When running a single DNS infrastructure, Service Providers MUST NOT include Shared Address Space in zone files. When running a split DNS infrastructure, Service Providers MUST NOT include Shared Address Space in external-facing zone files. Reverse DNS queries for Shared Address Space addresses MUST NOT be forwarded to the global DNS infrastructure. DNS Providers SHOULD filter requests for Shared Address Space reverse DNS queries on recursive nameservers. This is done to avoid having to set up something similar to AS112.net for [RFC1918] private address space that a host has incorrectly sent for a DNS that reverse-maps queries on the public Internet [RFC6304]. Because CGN service requires non-overlapping address space on each side of the home NAT and CGN, entities using Shared Address Space for purposes other than for CGN service, as described in this document, are likely to experience problems implementing or connecting to CGN service at such time as they exhaust their supply of public IPv4 addresses. 5. Risk 5.1. Analysis Some existing applications discover the outside address of their local CPE, determine whether the address is reserved for special use, and behave differently based on that determination. If a new IPv4 address block is reserved for special use and that block is used to number CPE outside interfaces, some of the above-mentioned applications may fail. For example, assume that an application requires its peer (or some other device) to initiate an incoming connection directly with its CPE's outside address. That application discovers the outside address of its CPE and determines whether that address is reserved for special use. If the address is reserved for special use, the application rightly concludes that the address is not reachable from Weil, et al. Best Current Practice [Page 5] RFC 6598 Shared Address Space Request April 2012 the global Internet and behaves in one manner. If the address is not reserved for special use, the application assumes that the address is reachable from the global Internet and behaves in another manner. While the assumption that a non-special-use address is reachable from the global Internet is generally safe, it is not always true (e.g., when the CPE outside interface is numbered from globally unique address space but that address is not advertised to the global Internet as when it is behind a CGN). Such an assumption could cause certain applications to behave incorrectly in those cases. 5.2. Empirical Data The primary motivation for the allocation of Shared Address Space is as address space for CGNs; the use and impact of CGNs has been previously described in [RFC6269] and [NAT444-IMPACTS]. Some of the services adversely impacted by CGNs are as follows: 1. Console gaming -- some games fail when two subscribers using the same outside public IPv4 address try to connect to each other. 2. Video streaming -- performance is impacted when using one of several popular video-streaming technologies to deliver multiple video streams to users behind particular CPE routers. 3. Peer-to-peer -- some peer-to-peer applications cannot seed content due to the inability to open incoming ports through the CGN. Likewise, some SIP client implementations cannot receive incoming calls unless they first initiate outgoing traffic or open an incoming port through the CGN using the Port Control Protocol (PCP) [PCP-BASE] or a similar mechanism. 4. Geo-location -- geo-location systems identify the location of the CGN server, not the end host. 5. Simultaneous logins -- some websites (particularly banking and social-networking websites) restrict the number of simultaneous logins per outside public IPv4 address. 6. 6to4 -- 6to4 requires globally reachable addresses and will not work in networks that employ addresses with limited topological span, such as those employing CGNs. Based on testing documented in [NAT444-IMPACTS], the CGN impacts on items 1-5 above are comparable regardless of whether globally unique, Shared Address Space, or [RFC1918] addresses are used. There is, however, a difference between the three alternatives in the treatment of 6to4. Weil, et al. Best Current Practice [Page 6] RFC 6598 Shared Address Space Request April 2012 As described in [RFC6343], CPE routers do not attempt to initialize 6to4 tunnels when they are configured with [RFC1918] or [RFC5735] WAN addresses. When configured with globally unique or Shared Address Space addresses, such devices may attempt to initiate 6to4, which would fail. Service Providers can mitigate this issue using 6to4 Provider Managed Tunnels [6to4-PMT] or blocking the route to 192.88.99.1 and generating an IPv4 'destination unreachable' message [RFC6343]. When the address range is well-defined, as with Shared Address Space, CPE router vendors can include Shared Address Space in their list of special-use addresses (e.g., [RFC5735]) and treat Shared Address Space similarly to [RFC1918] space. When the CGN-CPE address range is not well-defined, as in the case of globally unique space, it will be more difficult for CPE router vendors to mitigate this issue. Thus, when comparing the use of [RFC1918] and Shared Address Space, Shared Address Space poses an additional impact on 6to4 connectivity, which can be mitigated by Service Provider or CPE router vendor action. On the other hand, the use of [RFC1918] address space poses more of a challenge vis-a-vis Shared Address Space when the subscriber and Service Provider use overlapping [RFC1918] space, which will be outside the Service Provider's control in the case of unmanaged service. Service Providers have indicated that it is more challenging to mitigate the possibility of overlapping [RFC1918] address space on both sides of the CPE router than it is to mitigate the 6to4 impacts of Shared Address Space. 6. Security Considerations Similar to other [RFC5735] special-use IPv4 addresses, Shared Address Space does not directly raise security issues. However, the Internet does not inherently protect against abuse of these addresses. Attacks have been mounted that depend on the unexpected use of similar special-use addresses. Network operators are encouraged to review this document and determine what security policies should be associated with this address block within their specific operating environments. They should consider including Shared Address Space in Ingress Filter lists [RFC3704], unless their Internet service incorporates a CGN. Weil, et al. Best Current Practice [Page 7] RFC 6598 Shared Address Space Request April 2012 To mitigate potential misuse of Shared Address Space, except where required for hosted CGN service or a similar business relationship, o routing information about Shared Address Space networks MUST NOT be propagated across Service Provider boundaries. Service Providers MUST filter incoming advertisements regarding Shared Address Space. o packets with Shared Address Space source or destination addresses MUST NOT be forwarded across Service Provider boundaries. Service Providers MUST filter such packets on ingress links. o Service Providers MUST NOT include Shared Address Space in external-facing DNS zone files. o reverse DNS queries for Shared Address Space addresses MUST NOT be forwarded to the global DNS infrastructure. o DNS Providers SHOULD filter requests for Shared Address Space reverse DNS queries on recursive nameservers. 7. IANA Considerations IANA has recorded the allocation of an IPv4 /10 for use as Shared Address Space. The Shared Address Space address range is 100.64.0.0/10. 8. References 8.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010. Weil, et al. Best Current Practice [Page 8] RFC 6598 Shared Address Space Request April 2012 8.2. Informative References [6to4-PMT] Kuarsingh, V., Ed., Lee, Y., and O. Vautrin, "6to4 Provider Managed Tunnels", Work in Progress, February 2012. [ISP-SHARED-ADDR] Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, "ISP Shared Address", Work in Progress, January 2012. [NAT444-IMPACTS] Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J. Doshi, "Assessing the Impact of Carrier-Grade NAT on Network Applications", Work in Progress, November 2011. [PCP-BASE] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", Work in Progress, March 2012. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011. [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011. [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", RFC 6304, July 2011. [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011. Weil, et al. Best Current Practice [Page 9] RFC 6598 Shared Address Space Request April 2012 Appendix A. Acknowledgments Thanks to the following people (in alphabetical order) for their guidance and feedback: Stan Barber John Brzozowski Isaiah Connell Greg Davies Owen DeLong Kirk Erichsen Wes George Chris Grundemann Tony Hain Philip Matthews John Pomeroy Barbara Stark Jean-Francois Tremblay Leo Vegoda Steven Wright Ikuhei Yamagata Weil, et al. Best Current Practice [Page 10] RFC 6598 Shared Address Space Request April 2012 Authors' Addresses Jason Weil Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 USA EMail: jason.weil@twcable.com Victor Kuarsingh Rogers Communications 8200 Dixie Road Brampton, ON L6T 0C1 Canada EMail: victor.kuarsingh@gmail.com Chris Donley CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA EMail: c.donley@cablelabs.com Christopher Liljenstolpe Telstra Corp. 7/242 Exhibition Street Melbourne, VIC 316 Australia Phone: +61 3 8647 6389 EMail: cdl@asgaard.org Marla Azinger Frontier Communications Vancouver, WA USA Phone: +1.360.513.2293 EMail: marla.azinger@frontiercorp.com Weil, et al. Best Current Practice [Page 11]