RFC 6319

Issues Associated with Designating Additional Private IPv4 Address Space

📅 published July 2011, from ietf

RFC 6319: Issues Associated with Designating Additional Private IPv4 Address Space 💖

📜 The title block, bestie: this one came from the IETF, and the main author is M. Azinger from Frontier Communications Corporation. L. Vegoda from ICANN is the other author. It's Informational, not a Standards Track spec, and it was published in July 2011. Its ISSN is 2070-1721. It doesn't obsolete or update any other RFCs, since none are listed in its header. 🦋

Abstract ✨

okay so picture a private network that gets so big that it runs out of private IPv4 addresses to give every interface 😭. This doc covers the problems those networks face, the options they have, and the issues that come with handing out a new block of private IPv4 space. 💅

It's an informational doc, so it doesn't push one solution. It just lays out the drama around each option that people have considered 🔥.

Status of This Memo 🌸

This document is not an Internet Standards Track specification. It's published for information only, no cap 🧚.

It's a product of the Internet Engineering Task Force (IETF), so it reflects what the IETF community agrees on. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6319 🎀.

Copyright (c) 2011 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 publication date. Please read these carefully because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of 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 the Simplified BSD License describes 🍓.

Table of Contents 🦋

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Large Networks . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  Non-Unique Addresses . . . . . . . . . . . . . . . . . . . . .  3
  3.1.  Subscriber Use Network Address Translation . . . . . . . .  3
  3.2.  Carrier-Grade Network Address Translation  . . . . . . . .  4
4.  Available Options  . . . . . . . . . . . . . . . . . . . . . .  4
  4.1.  IPv6 Options . . . . . . . . . . . . . . . . . . . . . . .  4
    4.1.1.  Unique Globally Scoped IPv6 Unicast Addresses  . . . .  4
    4.1.2.  Unique Local IPv6 Unicast Addresses  . . . . . . . . .  5
  4.2.  IPv4 Options . . . . . . . . . . . . . . . . . . . . . . .  5
    4.2.1.  Address Transfers or Leases from Organizations
            with Available Address Space . . . . . . . . . . . . .  5
    4.2.2.  Using Unannounced Address Space Allocated to
            Another Organization . . . . . . . . . . . . . . . . .  5
    4.2.3.  Unique IPv4 Space Registered by an RIR . . . . . . . .  6
5.  Options and Consequences for Defining New Private Use Space  .  6
  5.1.  Redefining Existing Unicast Space as Private Address
        Space  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
  5.2.  Unique IPv4 Space Shared by a Group of Operators . . . . .  7
  5.3.  Potential Consequences of Not Redefining Existing
        Unicast Space as Private Address Space . . . . . . . . . .  8
  5.4.  Redefining Future Use Space as Unicast Address Space . . .  8
6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
  7.2.  Informative References . . . . . . . . . . . . . . . . . .  9
Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 12

1. Introduction ✨

okay so [RFC1918] sets aside three blocks of IPv4 address space for private networks: 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8 🎀. These blocks can be used at the same time in multiple, separately managed networks without registering them or coordinating with IANA or any Internet registry. That's the whole magic 🧚.

The thing is, very large networks can end up needing more device interfaces than those three ranges can hold 😭. People have occasionally suggested reserving extra private IPv4 space for these networks. That would help some of the needs of these very large network operators, but it's not free of consequences, especially as we get close to the date when the IANA free pool is fully allocated 💀.

The overall conclusion is that handing out extra address space for private use has severe problems. For example, it would affect any software or configuration that has built-in assumptions about private address space 🙈. But it's also well understood that cascading Network Address Translation (NAT) deployments in the existing private address space cause their own severe problems when address spaces overlap 🔥. Right now there's no clear agreement on how likely each problem is or what the trade-offs look like, so it's not settled yet 🦋.

2. Large Networks 🌈

The main categories of very large networks using private address space are cable operators, wireless (cell phone) operators, private internets, and VPN service providers 💜. For the first two, the whole address space reserved in [RFC1918] tends to be used by one organization. For private internets and VPN service providers, there are multiple independently managed and operated networks, and the hard part is avoiding address clashes 🫶.

3. Non-Unique Addresses 🍓

3.1. Subscriber Use Network Address Translation 🌸

The address space set aside in [RFC1918] is a finite resource, and it can be used to provide limited Internet access via NAT 🧚. A discussion of the advantages and disadvantages of NATs is outside the scope of this document, but you can find an analysis of the advantages, disadvantages, and architectural implications in [RFC2993]. Nonetheless, it must be acknowledged that NAT is adequate in some situations and not in others 🤓. For instance, it might technically be feasible to use NAT, or even multiple layers of NAT, within networks run by residential users or corporations where only limited Internet access is needed 💅. A more detailed analysis is in [RFC3022] 🎀. Where true peer-to-peer communication is needed, or where services or applications don't work properly behind NAT, globally unique address space is required 😭. In other cases, NAT traversal techniques make peer-to-peer like communication possible for devices behind NATs ✨.

In many cases, it's possible to use multiple layers of NAT to re-use parts of the address space defined in [RFC1918] 🦋. It's not always possible to rely on Customer Premises Equipment (CPE) devices using any particular range, though 🙈. In some cases, that means unorthodox workarounds are feasible, like assigning CPE devices unallocated address space or address space allocated to other network operators 👑. In other cases, organizations choose to run multiple separate routing domains so they can re-use the same private address ranges in multiple contexts 🌈. One consequence is the extra complexity of figuring out which system is being referred to when an IP address shows up in a log or management system 💀.

3.2. Carrier-Grade Network Address Translation 💜

Another option is to share one address across multiple interfaces and, in some cases, subscribers 🫶. This model breaks the classical model used for logging address assignments, and it creates significant risks and additional burdens. That's described in [CLAYTON], discussed more fully in [FORD], and documented in [DS-LITE] 🔥.

4. Available Options ✨

When a network operator has used up the private address space set aside in [RFC1918] but still needs to keep running a single routing domain, a number of options are available 🎀. They're described in the following sections 🦋.

4.1. IPv6 Options 🌸

4.1.1. Unique Globally Scoped IPv6 Unicast Addresses 💖

Using unique, globally scoped IPv6 unicast addresses is the best permanent solution, because it removes any worries about address scarcity for the next few decades 👑. Implementing IPv6 is a major endeavor for service providers with millions of consumers, and it's likely to take considerable effort and time 😭. In some cases, rolling out a new network protocol on a very large network takes more time than is available, based on network growth and how much of the private space has already been used 💀. In those cases, there's a call for additional private address space that all network operators can share 🧚. [DAVIES] makes one such case 🍓.

4.1.2. Unique Local IPv6 Unicast Addresses 🌈

Using the unique, local IPv6 unicast addresses defined in [RFC4193] is another approach, and it doesn't require coordination with an Internet registry 💜. Although the addresses defined in [RFC4193] are probabilistically unique, network operators on private internets, and those providing VPN services, might not want to use them. That's because there's a very low probability that the algorithm generates non-unique locally assigned global IDs 🙈. Also, on private internets, it can be very challenging to coordinate the rollout of a new network protocol needed to support the internet's continued growth 🔥.

4.2. IPv4 Options 🦋

4.2.1. Address Transfers or Leases from Organizations with Available Address Space 💅

The Regional Internet Registry (RIR) communities have recently been developing policies that let organizations with available address space transfer that designated space to other organizations [RIR-POLICY] 🎀. In other cases, leases might be arranged 🫶. This approach only works for operators of very large networks if enough address space is made available for transfer or lease, and if the very large networks can pay the costs of those transfers 😭. Nobody can know how much address space will become available this way, when it'll be available, or how much it'll cost ✨. However, it's unlikely to show up in large contiguous blocks 💀. That would add to the network management burden for the operator, because a significant number of small prefixes would inflate the size of the operator's routing table, at a time when it's also adding an IPv6 routing table 🙈. These reasons make address transfers a less attractive proposition for many large network operators 👑. Leases might not be attractive to some organizations if both parties can't agree on a suitable length of time 🌈. Also, the lessor might worry about its own unanticipated needs for additional IPv4 address space 🧚.

okay bestie, that's the first chunk 💖 Part 2 is coming next, so stay tuned 🫶✨

4.2.2. Using Unannounced Address Space Allocated to Another Organization 🫣

okay so some network operators have considered using IP address space that's allocated to another organization but isn't publicly visible in BGP routing tables 👀 this is very strongly discouraged, bestie 🙅‍♀️ just because a block isn't visible from one view doesn't mean it's invisible from another (ngl that's the whole trap 💀). Address usage also leaks past private network borders in e-mail headers, DNS queries, traceroute output and other ways 🫠. The ambiguity this causes is a problem for multiple organizations. This issue is discussed in [RFC3879], Section 2.3.

It's also possible the registrant of the address block might want to increase its visibility to other networks in the future, which would cause problems for anyone using it unofficially. In some cases there might also be legal risks involved in using address space officially allocated to another organization ⚖️

Where this has happened in the past, it has caused operational problems [FASTWEB] 😬

4.2.3. Unique IPv4 Space Registered by an RIR 🌸

RIRs' policies allow network operators to receive unique IP addresses for use on internal networks. Network operators are also not required to have already exhausted the private address space set aside in [RFC1918]. Still, network operators are naturally disinclined to request unique IPv4 addresses for the private areas of their networks, since using addresses that way means they aren't available for new Internet user connections 🙃

It's likely to get harder for network operators to obtain large blocks of unique address space as we approach the point where all IPv4 unicast /8s have been allocated. Several RIRs already have policies about how to allocate from their last /8 [RIR-POLICY-FINAL-8], and there have been policy discussions that would reduce the maximum allocation size available to network operators [MAX-ALLOC] or would reduce the period of need for which the RIR can allocate [SHORTER-PERIODS] 📉

5. Options and Consequences for Defining New Private Use Space ✨

5.1. Redefining Existing Unicast Space as Private Address Space 🦋

It's possible to re-designate a portion of the current global unicast IPv4 address space as private unicast address space. Doing this could benefit a number of operators of large networks for the short period before they finish their IPv6 roll-out. However, this benefit comes with a cost, since it reduces the pool of global unicast addresses available to users in general 🥺

When talking about re-designating a portion of the current global unicast IPv4 address space as private unicast address space, it's important to consider how much space would be used and for how long it would be sufficient. Not all of the large networks making full use of the space defined in [RFC1918] would have their needs met with a single /8. In 2005, [HAIN] suggested reserving three /8s for this purpose, while in 2009 [DAVIES] suggested a single /10 would be sufficient. There doesn't seem to be a consensus for a particular prefix length, nor an agreed basis for deciding what's sufficient 🤷‍♀️ The problem gets worse because of the continually changing needs of ever-expanding networks 📈

A further consideration is which of the currently unallocated IPv4 unicast /8 blocks should be used for this purpose. Using address space that's known to be used unofficially is super tempting 👀 For instance, 1.0.0.0/8, which was unallocated until January 2010, was proposed in [HAIN] and is known to be used by a number of different users. These include networks making use of HIP LSIs [RFC4423], [WIANA], [anoNet], and others. There's anecdotal [VEGODA] and research [WESSELS] evidence suggesting that several other IPv4 /8s are used this way. There have also been discussions [NANOG] about some sections of these /8s being carved out and filtered, which would unofficially enable those sections for private use 🫣

Although new IPv4 /8s are allocated about once a month, they aren't easy to bring into use, because network operators are slow to change their filter configurations 🐢 This is despite long-running awareness campaigns [CYMRU] [LEWIS] and active work [ripe-351] to notify people whose filters aren't changed in a timely fashion. Updating code that recognizes private address space in deployed software and infrastructure systems is likely to be far more difficult, since many systems have these ranges hard-coded and can't be quickly changed with a new configuration file 💀

Another consideration when redefining existing unicast space as private address space is that no single class of user can expect the space to stay unique to them 🫶 This means an ISP using a new private address range can't expect its customers not to already be using that same range within their own networks.

5.2. Unique IPv4 Space Shared by a Group of Operators 👯‍♀️

When a group of networks find themselves needing a large amount of IPv4 address space from an RIR in addition to what's defined in [RFC1918], they might cooperatively agree to all use the same address space to number their networks. The clear benefit is that this significantly reduces the potential demand on the pool of unallocated IPv4 address space 🙌 However, the issues discussed in Sections 4.2.2 and 5.3 are a concern here, especially the possibility that one operator might decide to use the address space to number customer connections rather than private infrastructure 😳

Nonetheless, this approach has the potential to create an unofficial new private address range without proper scrutiny 🚨

5.3. Potential Consequences of Not Redefining Existing Unicast Space as Private Address Space 📦

If additional private address space isn't defined, and the large network operators affected by this problem can't solve their problems with IPv6 address space or by segmenting their networks into multiple routing domains, those networks will need unique IPv4 addresses. It's possible, and even likely, that a single network could consume a whole IPv4 /8 in a year. At the time this document was written, there were just 24 unallocated IPv4 /8s, so it wouldn't take many such requests to make a major dent in the available IPv4 address space 😭 [POTAROO] provides an analysis of IPv4 address consumption and projects the date on which the IANA and RIR pools will be fully allocated 📅

5.4. Redefining Future Use Space as Unicast Address Space 🔮

There have also been proposals to re-designate the former Class E space (240.0.0.0/4) as unicast address space. [WILSON] suggests it should be privately scoped, while [FULLER] doesn't propose a scope. Both proposals note that existing deployed equipment may not be able to use addresses from 240.0.0.0/4. Potential users would need to be sure of the status of the equipment on their network, and of the networks they intend to communicate with 🧐

It's not immediately clear how useful 240.0.0.0/4 could be in practice. While [FULLER] documents the status of several popular desktop and server operating systems, the status of the most widely deployed routers and switches is less clear. It's possible that 240.0.0.0/4 might only be useful in very large, new green field deployments where full control of all deployed systems is available. However, in those cases it might well be easier to deploy an IPv6 network 💅

6. Security Considerations 🔐

This document has no security implications. Nothing to panic about here, bestie 🫶

7. References 📚

7.1. Normative References

[RFC1918]     Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
              and E. Lear, "Address Allocation for Private
              Internets", BCP 5, RFC 1918, February 1996.

[RFC2993]     Hain, T., "Architectural Implications of NAT",
              RFC 2993, November 2000.

[RFC3022]     Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

[RFC4193]     Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

7.2. Informative References ✨

okay bestie, here's the reading list for the extra-helpful stuff 📚 (not required to implement, but SO worth the tab-hoarding 💅)

Appendix A. Acknowledgments 🫶

the authors wanna give a huge shoutout to Ron Bonica, Michelle Cotton, Lee Howard, and Barbara Roseman for helping out with early discussions of this doc 💖 and to Maria Blackmore, Alex Bligh, Mat Ford, Thomas Narten, and Ricardo Patara for the suggested improvements ✨. literally the squad 👑

Authors' Addresses 📮

Marla Azinger
Frontier Communications Corporation
Vancouver, WA
United States of America

EMail: marla.azinger@ftr.com
URI:   http://www.frontiercorp.com/


Leo Vegoda
Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Rey, CA  90292
United States of America

Phone: +1-310-823-9358
EMail: leo.vegoda@icann.org
URI:   http://www.iana.org/
📦 where this page comes from