RFC 6598

IANA-Reserved IPv4 Prefix for Shared Address Space

📅 published April 2012, from ietf

RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space 🎀

Okay bestie, here's the deets 💖 This is RFC 6598, a Best Current Practice (so it's also BCP 153 🫶), published in April 2012. The authors are J. Weil (Time Warner Cable), V. Kuarsingh (Rogers Communications), C. Donley (CableLabs), C. Liljenstolpe (Telstra Corp.), and M. Azinger (Frontier Communications). It updates RFC 5735 and its ISSN is 2070-1721. It doesn't obsolete anything 🧚

Abstract ✨

This doc asks for an IPv4 /10 address block to be used as Shared Address Space, so Carrier-Grade NAT (CGN) devices have room to breathe 🌸 Service Providers are expected to use this space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE).

Shared Address Space is not the same as RFC 1918 private address space, because it's meant for Service Provider networks. It can still be used a bit like RFC 1918 space on routing gear that can do address translation across router interfaces when the addresses match on two different interfaces. The details are in the body of the doc 👀

This doc also allocates an extra special-use IPv4 address block, and it 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 got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on BCPs is in Section 2 of RFC 5741.

For the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6598 💜

IESG Note 🔥

A bunch of operators said they needed this special-purpose IPv4 address allocation. During discussions, the IETF community showed very rough consensus in favor of it.

Here's the tea though: while operational shortcuts like this one (including the allocation described here) might help with a short-term operational problem, the IESG and the IETF are still fully committed to deploying IPv6 🫶

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) as they stand on the date of publication. Please read these carefully, because they spell out your rights and restrictions for 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 they come 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

1. Introduction 🌸

IPv4 address space is basically all used up 😭 But ISPs still have to keep supporting IPv4 growth until IPv6 is fully deployed. So a lot of ISPs are going to deploy a Carrier-Grade NAT (CGN) device, like the one described in [RFC6264]. CGNs run on networks where public address space is expected, and the private address space we have right now causes operational issues in that setting. That's why ISPs need a new IPv4 /10 address block. It'll be called the "Shared Address Space," and it'll number the interfaces that connect CGN devices to Customer Premises Equipment (CPE) ✨

Shared Address Space is similar to [RFC1918] private address space because it isn't globally routable and lots of pieces of equipment can use it. The difference is that Shared Address Space has limits that RFC 1918 space doesn't. Specifically, it can only be used in Service Provider networks, or on routing equipment that can 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. When ISPs were asked, a /10 turned out to be the smallest block that lets them deploy CGNs on a regional basis without needing nested CGNs. For example, as described in [ISP-SHARED-ADDR], a /10 is enough to service Points of Presence in the Tokyo area 🗼

This document also allocates an extra special-use IPv4 address block, and it 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 could theoretically be numbered from any of these address spaces:

  • legitimately assigned globally unique address space
  • usurped globally unique address space (i.e., squat space)
  • [RFC1918] space
  • Shared Address Space

A Service Provider can number those interfaces from legitimately assigned globally unique address space. This is the option with the fewest problems, but it's impractical because globally unique IPv4 address space is in short supply 😩 The Regional Internet Registries (RIRs) have enough space to allocate a single /10 to be shared by all Service Providers, but not enough to give each Service Provider its own unique assignment.

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, and so would anyone who wants to talk to them. Even if the Service Provider didn't leak any advertisements for squat space, the Service Provider and its subscribers might still lose connectivity to the legitimate holders of that address space 🚫

A Service Provider can number those interfaces from [RFC1918] space if at least one of the following conditions is true:

  • 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.
  • The Service Provider knows that the [RFC1918] address block it uses to number interfaces between the CGN and CPE isn't 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 set aside for Service Provider use, with the goal of making CGN deployment easier ✨ It can also be used as extra non-globally routable space on routing equipment that can do address translation across router interfaces when the addresses are identical on two different interfaces.

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. There's one exception to this rule, and that's business relationships, like 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 helps avoid having to set up something similar to AS112.net for [RFC1918] private address space that a host has incorrectly sent to a DNS that reverse-maps queries on the public Internet [RFC6304] 🙈

Because CGN service needs non-overlapping address space on each side of the home NAT and CGN, entities that use Shared Address Space for anything other than CGN service (as described in this document) will probably run into problems implementing or connecting to CGN service once they run out of public IPv4 addresses 💀

5. Risk 🔥

5.1. Analysis ✨

okay so some apps are lowkey nosy 👀 they find out their CPE's outside address, check if it's a special-use address, and then act totally different depending on the answer. 💅 if a brand new IPv4 block gets reserved for special use and that block is used for CPE outside interfaces, some of these apps might just... break 💀

picture this: an app needs its peer (or some other device) to start an incoming connection straight to its CPE's outside address. it finds that address, checks if it's special-use, and goes "ok bet." if it IS special-use, the app correctly figures it's not reachable from the global Internet and does its thing. if it's NOT special-use, the app assumes it's reachable from the global Internet and does a whole different thing. 🦋

and ngl the assumption that a non-special-use address is reachable from the global Internet is usually fine 🫶 but it's not always true!! like when the CPE outside interface is numbered from globally unique address space but that address isn't advertised to the global Internet, which is the case when it's behind a CGN. 😭 that wrong assumption could make some apps misbehave in those situations. yikes

5.2. Empirical Data 📊

okay the main reason Shared Address Space got allocated is to be address space for CGNs 🎀 we already covered how CGNs affect things in [RFC6269] and [NAT444-IMPACTS]. here are some of the services that get hit by CGNs:

  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 takes a hit when you use 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 apps can't seed content because they can't open incoming ports through the CGN. same vibe for some SIP clients: they can't receive incoming calls unless they first start 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 figure out where the CGN server is, not where the end host is. 🗺️
  5. Simultaneous logins -- some websites (especially banking and social-networking ones) limit how many simultaneous logins you can have per outside public IPv4 address. 🔐
  6. 6to4 -- 6to4 needs globally reachable addresses and won't work in networks that use addresses with limited topological span, like the ones that use CGNs. 🙅‍♀️

based on the testing in [NAT444-IMPACTS], the CGN impacts on items 1-5 above are comparable no matter whether you use globally unique, Shared Address Space, or [RFC1918] addresses. 💖 BUT there's one difference between the three when it comes to 6to4, and that's the tea 🍵

as [RFC6343] describes, CPE routers don't try to initialize 6to4 tunnels when they're configured with [RFC1918] or [RFC5735] WAN addresses. when they're configured with globally unique or Shared Address Space addresses, those devices might try to start 6to4, and that would fail. 😬 Service Providers can deal with this using 6to4 Provider Managed Tunnels [6to4-PMT], or by blocking the route to 192.88.99.1 and generating an IPv4 'destination unreachable' message [RFC6343]. when the address range is well-defined, like with Shared Address Space, CPE router vendors can put Shared Address Space on their list of special-use addresses (e.g., [RFC5735]) and treat it kinda like [RFC1918] space. 🧠 but when the CGN-CPE address range isn't well-defined, like with globally unique space, it's way harder for CPE router vendors to fix this. 😤

so when you compare [RFC1918] and Shared Address Space, Shared Address Space adds an extra impact on 6to4 connectivity, which can be fixed by Service Provider or CPE router vendor action. ✅ on the flip side, [RFC1918] space is more of a challenge compared to Shared Address Space when the subscriber and Service Provider use overlapping [RFC1918] space. that's outside the Service Provider's control with unmanaged service, so 🙃 Service Providers have said it's harder to deal with overlapping [RFC1918] address space on both sides of the CPE router than it is to deal with the 6to4 impacts of Shared Address Space. 💅

6. Security Considerations 🔒

okay this part is serious, bestie 🫶 Shared Address Space doesn't directly raise security issues, same as other [RFC5735] special-use IPv4 addresses. BUT the Internet doesn't inherently protect against abuse of these addresses, and attacks have been run that depend on the unexpected use of similar special-use addresses. 🚨 Network operators are encouraged to review this document and figure out what security policies should go with this address block in their specific operating environments. they should consider including Shared Address Space in Ingress Filter lists [RFC3704], unless their Internet service uses a CGN. 🛡️

to cut down on potential misuse of Shared Address Space, except where it's needed for hosted CGN service or a similar business relationship, here's the vibe:

  • 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.
  • 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.
  • Service Providers MUST NOT include Shared Address Space in external-facing DNS 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.

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.

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.

Appendix A. Acknowledgments 🫶

thank you to these amazing 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

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
📦 where this page comes from