RFC 1918

RFC 1918: Address Allocation for Private Internets 🎀

Okay bestie, let's start with the title block 🎀. This is RFC 1918, called Address Allocation for Private Internets, from the Network Working Group, dated February 1996. It's filed as a Best Current Practice (that's BCP 5 for the record 💅), and it obsoletes RFC 1627 and RFC 1597, so those are officially retired now 🙈. The authors are Y. Rekhter of Cisco Systems, B. Moskowitz of Chrysler Corp., D. Karrenberg and G. J. de Groot of RIPE NCC, and E. Lear of Silicon Graphics, Inc. 🫶 A whole squad of legends, no cap ✨.

---

Status of this Memo 💅

Okay, the fine print: this document specifies an Internet Best Current Practice for the Internet Community 🌈, and it's literally requesting discussion and suggestions for improvements 💬. Distribution of this memo is unlimited, so share away 🦋.

1. Introduction ✨

Okay so first things first, what even is an enterprise here? 🧚 For this doc, it's an entity that autonomously operates a network using TCP/IP, and in particular, it's the one deciding the addressing plan and the address assignments inside that network 💅.

This document is all about address allocation for private internets 🌸. The whole point is that it gives full network layer connectivity among all hosts inside an enterprise, AND among all the public hosts of different enterprises too 🫶. The cost of using private internet address space? The potentially costly effort to renumber hosts and networks between public and private 😭.

2. Motivation 💖

Okay so TCP/IP is literally everywhere now 🌍, including places that have nothing to do with the Internet itself. An increasing number of non-connected enterprises use this tech and its addressing for sole intra-enterprise communications 📦, without any plan to ever directly connect to other enterprises or the Internet itself 🙅.

The Internet has grown beyond anyone's expectations 🚀, and that sustained exponential growth keeps bringing new challenges 😵‍💫. One is a concern within the community that globally unique address space will be exhausted. A separate and way more pressing concern is that the amount of routing overhead will grow beyond what Internet Service Providers can handle 💀. Efforts are in progress within the community to find long term solutions to both of these problems 🔧. Meanwhile, it is necessary to revisit address allocation procedures, and their impact on the Internet routing system 🔍.

Now, to contain the growth of routing overhead 📈, an Internet Provider grabs a block of address space from an address registry, then hands its customers addresses from within that block based on each customer's requirement 🎀. The result is that routes to many customers get aggregated together and look like one single route to other providers [RFC1518], [RFC1519] ✨. For aggregation to actually work, Internet providers encourage customers joining their network to use the provider's block, and thus renumber their computers 🙈. Such encouragement MAY become a requirement in the future 👀.

With the current size of the Internet and how fast it's growing 📊, it's no longer realistic to assume that acquiring globally unique IP addresses from an Internet registry means an organization will have Internet-wide IP connectivity once it's connected 😬. Plot twist: when the organization connects to the Internet to get that Internet-wide connectivity, it would need to change IP addresses (renumber) all of its public hosts (the hosts that require Internet-wide IP connectivity) 💔, regardless of whether the addresses it started with were globally unique or not.

It has been typical to assign globally unique addresses to every host that uses TCP/IP 🌐. But to extend the life of the IPv4 address space, address registries are requiring more justification than ever, which makes it harder for organizations to acquire additional address space [RFC1466] 🥺.

Hosts within enterprises that use IP can be sorted into three categories 🗂️:

• Category 1: hosts that do not require access to hosts in other enterprises or the Internet at large. Hosts within this category MAY use IP addresses that are unambiguous within an enterprise, but MAY be ambiguous between enterprises.
• Category 2: hosts that need access to a limited set of outside services (e.g., E-mail, FTP, netnews, remote login) which can be handled by mediating gateways (e.g., application layer gateways). For many hosts in this category, an unrestricted external access (provided via IP connectivity) MAY be unnecessary and even undesirable for privacy/security reasons. Same as the first category, such hosts MAY use IP addresses that are unambiguous within an enterprise, but MAY be ambiguous between enterprises.
• Category 3: hosts that need network layer access outside the enterprise (provided via IP connectivity). Hosts in the last category require IP addresses that are globally unambiguous.

We'll call the hosts in the first and second categories "private" 🔒, and the hosts in the third category "public" 🌍.

Many applications only need connectivity within one enterprise 🏠, and most internal hosts don't need external (outside the enterprise) connectivity. In larger enterprises, it's often easy to spot a substantial number of TCP/IP hosts that don't need network layer connectivity outside the enterprise 🔎.

Some examples, where external connectivity might not be REQUIRED, are:

• A large airport has its arrival/departure displays individually addressable via TCP/IP ✈️. It is very unlikely that these displays need to be directly accessible from other networks.
• Large organizations like banks and retail chains are switching to TCP/IP for their internal communication 🏦. Large numbers of local workstations, like cash registers, money machines, and equipment at clerical positions, rarely need to have such connectivity.
• For security reasons, many enterprises use application layer gateways to connect their internal network to the Internet 🛡️. The internal network usually does not have direct access to the Internet, so only one or more gateways are visible from the Internet. In this case, the internal network can use non-unique IP network numbers.
• Interfaces of routers on an internal network usually do not need to be directly accessible from outside the enterprise 🧭.

3. Private Address Space 🦋

The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets 🎀:

10.0.0.0        -   10.255.255.255  (10/8 prefix)
172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

We'll call the first block the "24-bit block", the second the "20-bit block", and the third the "16-bit" block 💅. Note that (in pre-CIDR notation) the first block is nothing but a single class A network number, while the second block is a set of 16 contiguous class B network numbers, and the third block is a set of 256 contiguous class C network numbers 🧠.

An enterprise that decides to use IP addresses out of the address space defined in this document can do so without any coordination with IANA or an Internet registry 🙌. The address space can thus be used by many enterprises. Addresses within this private address space will only be unique within the enterprise, or within the set of enterprises which choose to cooperate over this space so they MAY communicate with each other in their own private internet 🌈.

As before, any enterprise that needs globally unique address space is REQUIRED to obtain such addresses from an Internet registry 📜. An enterprise that requests IP addresses for its external connectivity will never be assigned addresses from the blocks defined above 🚫.

In order to use private address space, an enterprise needs to figure out which hosts do not need network layer connectivity outside the enterprise in the foreseeable future, and thus could be classified as private 🔍. Such hosts will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private 💬. However, they cannot have IP connectivity to any host outside of the enterprise 🧱. Even without external (outside of the enterprise) IP connectivity, private hosts can still have access to external services via mediating gateways (e.g., application layer gateways) 🛡️.

All other hosts will be public and will use globally unique address space assigned by an Internet Registry 🌐. Public hosts can communicate with other hosts inside the enterprise, both public and private, and can have IP connectivity to public hosts outside the enterprise 🌍. Public hosts do not have connectivity to private hosts of other enterprises 🙅.

Moving a host from private to public or vice versa involves a change of IP address, changes to the appropriate DNS entries, and changes to configuration files on other hosts that reference the host by IP address 😩.

Translation: switching a host between private and public is a whole glow-up that touches its IP address, its DNS entries, and every config file that points at it by IP address 💅

Because private addresses have no global meaning, routing information about private networks SHALL NOT be propagated on inter-enterprise links, and packets with private source or destination addresses SHOULD NOT be forwarded across such links 🚧. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks 🧹. If such a router receives such information, the rejection SHALL NOT be treated as a routing protocol error 🙏.

Indirect references to such addresses SHOULD be contained within the enterprise 🏰. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses 📇. In particular, Internet service providers SHOULD take measures to prevent such leakage 🚰.

That's the first chunk, bestie 💖. Part 2 picks up right where this leaves off, so keep your eyes peeled 👀✨

4. Advantages and Disadvantages of Using Private Address Space ✨

okay so the biggest win of private address space for the Internet at large is that we get to conserve the globally unique address space 🌍💖 by simply not using it where global uniqueness isn't actually required. no waste, no cap 💅

enterprises get major perks too 🎀 they gain so much flexibility in network design because they have way more address space to play with than they could ever snag from the globally unique pool 😭 that means addressing schemes that are operationally and administratively convenient, plus easier growth paths. main character energy fr 👑

now the messy part 🙈 for a bunch of reasons, the Internet has already run into situations where an enterprise that wasn't connected to the Internet was using IP address space for its hosts without getting it assigned from the IANA. in some cases that address space had already been assigned to other enterprises. if that enterprise later connects to the Internet, it could potentially cause very serious problems, because IP routing can't work correctly when addressing is ambiguous 💀 ISPs should guard against this with route filters in theory, but in practice it doesn't always happen. so private address space is a safe choice for these enterprises, since it avoids clashes once outside connectivity is needed 🫶

ngl the catch is that private address space can actually reduce an enterprise's flexibility to access the Internet 🥺 once you commit to using a private address, you're committing to renumber part or all of your enterprise if you ever decide to provide IP connectivity between that part (or the whole enterprise) and the Internet. the cost of renumbering is usually measured by counting how many hosts have to switch from private to public. as we talked about earlier though, even a network using globally unique addresses might still have to renumber to get Internet-wide IP connectivity 😩

another drawback is that private address space may require renumbering when you merge several private internets into one 🔀 and remember the examples we listed in Section 2? companies tend to merge 👀 if those companies kept their uncoordinated internets on private address space before the merge, then after combining them into a single private internet, some addresses might not be unique anymore. the hosts with those addresses would then need to be renumbered 💅

renumbering can get a lot less painful with tools that make it easier (like the Dynamic Host Configuration Protocol (DHCP), e.g. 🧚). so when you're deciding whether to use private addresses, we recommend asking your computer and software vendors what tools they have available 🌸 there's also a separate IETF effort (PIER Working Group) that's documenting the full requirements and procedures for renumbering, so keep an eye on that ✨

---

5. Operational Considerations 🛠️

one possible strategy is to design the private part of the network first and use private address space for all internal links 🧩 then plan the public subnets wherever they're needed and design the external connectivity after that 🦋

this design doesn't have to stay the same forever 💜 if a group of one or more hosts needs to switch status (from private to public, or the other way around) later on, you can do it by renumbering only the hosts involved and changing physical connectivity if needed. in places where these changes are predictable (machine rooms, etc.), it's a good idea to configure separate physical media for public and private subnets to make the switch easier 🙌 and to avoid major network disruptions, it's a good idea to group hosts with similar connectivity needs onto their own subnets 🍓

if a suitable subnetting scheme can be designed and your equipment supports it, it's advisable to use the 24-bit block (class A network) of private address space and make an addressing plan with a good growth path 📈 if subnetting is a problem, you can use the 16-bit block (class C networks) or the 20-bit block (class B networks) of private address space instead 🫶

one might be tempted to put both public and private addresses on the same physical medium 🤔 this is possible, but there are pitfalls (and the pitfalls have nothing to do with private addresses. they come from having multiple IP subnets on a common Data Link subnetwork). so be careful when you go down this road ⚠️

it is strongly recommended that routers connecting enterprises to external networks are set up with appropriate packet and routing filters at both ends of the link, to prevent packet and routing information leakage 🔒 an enterprise should also filter any private networks out of inbound routing information, so it's protected from ambiguous routing situations that can happen if routes to the private address space point outside the enterprise 🛡️

two sites that both coordinate their private address space can talk to each other over a public network too 🌐 they just have to use some method of encapsulation at their borders to a public network, which keeps their private addresses private 🤫

now here's the tea ☕ if two (or more) organizations follow the address allocation in this document and then later want IP connectivity with each other, there's a risk that address uniqueness gets violated 😱 to minimize that risk, it is strongly recommended that an organization using private IP addresses choose randomly from the reserved pool of private addresses when allocating sub-blocks for its internal allocation 🎲

if an enterprise uses private address space, or a mix of private and public address space, then DNS clients outside the enterprise should not see the private addresses it uses, since those addresses would be ambiguous 🙈 one way to make sure of this is to run two authority servers for each DNS zone that contains both publicly and privately addressed hosts. one server is visible from the public address space and holds only the subset of the enterprise's addresses that are reachable using public addresses. the other server is reachable only from the private network and holds the full set of data, including the private addresses and whatever public addresses are reachable from the private network. to keep everything consistent, both servers should be configured from the same data, with the publicly visible zone only containing a filtered version of it 🧠 yes, there's a certain degree of additional complexity that comes with providing these capabilities 😮‍💨

---

6. Security Considerations 🔐

security issues are not addressed in this memo. the rest of the security story is on you, bestie 💀 please don't assume this document has your back here.

---

7. Conclusion 🌈

with the described scheme, many large enterprises will only need a relatively small block of addresses from the globally unique IP address space 💖 the Internet at large benefits from conserving that globally unique address space, which effectively lengthens the lifetime of the IP address space ⏳ enterprises benefit from the extra flexibility that a relatively large private address space gives them 🦋 but using private addressing does mean an organization has to renumber part or all of its enterprise network as its connectivity requirements change over time 😭

---

8. Acknowledgments 🫶

we'd like to thank Tony Bates (MCI), Jordan Becker (ANS), Hans-Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN Planet), Vince Fuller (BBN Planet), Tony Li (cisco Systems), Anne Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks), Geza Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute), Andy Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush (PSG), Erik Fair (Apple Computer), Dave Crocker (Brandenburg Consulting), Tom Kessler (SGI), Dave Piscitello (Core Competence), Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie (Internet Software Consortium) for their review and constructive comments 🥰✨

---

9. References 📚

[RFC1466] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1466, Merit Network, Inc., May 1993.

[RFC1518] Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.

[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.

---

10. Authors' Addresses 💌

Yakov Rekhter
Cisco systems
170 West Tasman Drive
San Jose, CA, USA
Phone: +1 914 528 0090
Fax: +1 408 526-4952
EMail: yakov@cisco.com

Robert G Moskowitz
Chrysler Corporation
CIMS: 424-73-00
25999 Lawrence Ave
Center Line, MI 48015
Phone: +1 810 758 8212
Fax: +1 810 758 8173
EMail: rgm3@is.chrysler.com

Daniel Karrenberg
RIPE Network Coordination Centre
Kruislaan 409
1098 SJ Amsterdam, the Netherlands
Phone: +31 20 592 5065
Fax: +31 20 592 5090
EMail: Daniel.Karrenberg@ripe.net

Geert Jan de Groot
RIPE Network Coordination Centre
Kruislaan 409
1098 SJ Amsterdam, the Netherlands
Phone: +31 20 592 5065
Fax: +31 20 592 5090
EMail: GeertJan.deGroot@ripe.net

Eliot Lear
Mail Stop 15-730
Silicon Graphics, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA 94043-1389
Phone: +1 415 960 1980
Fax:   +1 415 961 9584
EMail: lear@sgi.com