RFC 1597

Address Allocation for Private Internets 🎀

RFC 1597 💖 · Informational · March 1994

Okay bestie, the header says this came from the Network Working Group 🧚 and was written by Y. Rekhter (T.J. Watson Research Center, IBM Corp.), B. Moskowitz (Chrysler Corp.), D. Karrenberg (RIPE NCC), and G. de Groot (RIPE NCC). It's Informational, and it doesn't list any RFCs it obsoletes or updates. Main character energy 👑

Status of this Memo

This memo is here to give info to the Internet community 📚. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🌈

1. Introduction ✨

So this RFC is all about ways to save IP address space 💅 The trick is to not give globally unique IP addresses to hosts that are private to an enterprise, while still letting every host inside an enterprise talk to each other, and letting all the public hosts of different enterprises talk too. The authors are hoping that with these methods, a lot of savings can be made when it comes to allocating IP address space 🫶

Quick definition 🎀: for the purposes of this memo, an enterprise is an entity that autonomously operates a network using TCP/IP, and in particular decides the addressing plan and the address assignments inside that network.

2. Motivation 🌸

TCP/IP is everywhere now, even outside the Internet itself 🌍 So there's a growing number of enterprises that use it and its addressing only for communication inside the enterprise. They never plan to directly connect to other enterprises or to the Internet. Honestly, that's so valid 🙈

Right now the usual practice is to give every host that uses TCP/IP a globally unique address. People are getting nervous that the finite IP address space might run out 😭 Because of that, the rules for assigning IP address space have gotten tighter over the last few years [1]. Those rules are often stricter than enterprises would like when they're trying to build and run their networks.

Hosts inside enterprises that use IP can be sorted into three categories 🧁:

• hosts that do not need to reach hosts in other enterprises or the Internet at large;
• hosts that need access to a limited set of outside services (e.g., E-mail, FTP, netnews, remote login) which can be handled by application layer gateways;
• hosts that need network layer access outside the enterprise (provided via IP connectivity);
• hosts within the first category may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises.

For a lot of hosts in the second category, unrestricted external access (provided via IP connectivity) might be unnecessary, and even undesirable for privacy or security reasons 🔒 Just like the hosts in the first category, these hosts can use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises.

Only the hosts in the last category need IP addresses that are globally unambiguous 💜

Lots of applications only need connectivity inside one enterprise, and most of the internal hosts don't even need external connectivity 🙌 In bigger enterprises it's pretty easy to spot a big pile of TCP/IP hosts that don't need network layer connectivity outside the enterprise.

Some examples where external connectivity probably isn't needed:

• A large airport has arrival and departure displays that are each individually addressable via TCP/IP. It's super unlikely these displays need to be directly reachable from other networks ✈️
• Big organisations like banks and retail chains are switching to TCP/IP for their internal communication 🏦 A huge number of local workstations, like cash registers, money machines, and equipment at clerical positions, rarely need that kind of connectivity.
• For security reasons, many enterprises use application layer gateways (e.g., firewalls) to connect their internal network to the Internet 🛡️ The internal network usually doesn't have direct access to the Internet, so only one or more firewall hosts are visible from the Internet. In this case, the internal network can use non-unique IP numbers.
• If two enterprises talk over their own private link, usually only a very small set of hosts can reach each other across that link 🔗 Only those hosts need globally unique IP numbers.
• Interfaces of routers on an internal network usually don't 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 networks 🌸

        10.0.0.0        -   10.255.255.255
        172.16.0.0      -   172.31.255.255
        192.168.0.0     -   192.168.255.255

We'll call the first block the "24-bit block", the second the "20-bit block", and the third the "16-bit" block 🎀 Fun fact: the first block is literally just one single class A network number 😭 The second block is a set of 16 contiguous class B network numbers, and the third block is a set of 255 contiguous class C network numbers.

An enterprise that decides to use IP addresses out of the address space defined in this document can do that without any coordination with IANA or an Internet registry 🥳 That means the address space can be used by lots of enterprises at once. Addresses inside this private address space will only be unique within the enterprise, though.

Still, any enterprise that needs globally unique address space is required to get those addresses from an Internet registry 📝 An enterprise that asks for IP addresses for its external connectivity will never be assigned addresses from the blocks defined above.

To use private address space, an enterprise needs to figure out which hosts won't need network layer connectivity outside the enterprise in the foreseeable future ✨ Those hosts are called private hosts, and they'll use the private address space defined above. Private hosts can talk to all the other hosts inside the enterprise, both public and private 💅 But they can't have IP connectivity to any external host. Even without external network layer connectivity, private hosts can still reach external services through application layer relays 🫶

Everything else is called public, and public hosts use globally unique address space assigned by an Internet Registry 🌍 Public hosts can talk to other hosts inside the enterprise, both public and private, and they can have IP connectivity to external public hosts. Public hosts don't have connectivity to private hosts of other enterprises 🚫

Moving a host from private to public, or the other way around, involves a change of IP address. Heads up, bestie 😭

Private addresses don't have any global meaning, so routing information about private networks shall not be propagated on inter-enterprise links 🙅 Packets with private source or destination addresses should not be forwarded across those links either. Routers in networks that don't use private address space, especially the ones run by Internet service providers, are expected to be configured to reject (filter out) routing information about private networks 🧱 If a router like that receives this information, the rejection shall not be treated as a routing protocol error.

Indirect references to these addresses should stay inside the enterprise 🏠 Big examples of those references are DNS Resource Records and other information that points to internal private addresses. Internet service providers in particular should take measures to prevent this kind of leakage 🚨

4. Advantages and Disadvantages of Using Private Address Space 💖

The obvious advantage of using private address space on the Internet at large is that it conserves globally unique address space, because you don't use it where global uniqueness isn't required 🌈

Enterprises get benefits from using private address space too 🎀 They get a lot more flexibility in network design, because they have more address space at their disposal than they could get from the globally unique pool. That makes it easier to pick addressing schemes that are convenient to operate and manage, and it gives them easier growth paths 🧚

The Internet has already run into situations where an enterprise that had never been connected to the Internet was using IP address space for its hosts without getting that space assigned from the IANA 😬 In some cases that address space had already been assigned to other enterprises. When an enterprise like that connects to the Internet later, it could cause really serious problems, because IP routing can't work correctly when addressing is ambiguous 💀 Private address space is a safe choice for these enterprises, since it avoids clashes once they need outside connectivity 🛡️

Someone could argue that the possible need for renumbering is a big drawback of using addresses from the block allocated for private internets 🤔 But the need is only "potential" 🫠 Many hosts may never move into the third category, and an enterprise may never decide to interconnect (at IP level) with another enterprise.

Even if renumbering does have to happen, it's worth noticing that with Classless Inter-Domain Routing (CIDR), an enterprise that's connected to the Internet may be encouraged to renumber its public hosts whenever it changes its Network Service Providers 🔄 So renumbering is likely to happen more often in the future, no matter whether an enterprise uses addresses from the private block or not. Tools that make renumbering easier (e.g., DHCP) would certainly make it less of a concern 🙌

Also, the clear split between public and private hosts, and the renumbering that comes with it, makes uncontrolled outside connectivity harder to set up 🔐 So to some extent, the need to renumber could be seen as an advantage 💜

5. Operational Considerations ✨

okay bestie, this section is about actually living with private address space 🎀. The recommended strategy is to design the private part of the network first 💅 and use private address space for all the internal links. Then you plan public subnets only at the locations you actually need, and design how you connect to the outside world 🧚

Plot twist: this design is not carved in stone 🪨. If a bunch of hosts need to switch status later, you can renumber just those hosts and install another physical subnet if you need one. Easy glow-up 🌸

If your equipment supports a suitable subnetting scheme, it is advisable to use the 24-bit block of private address space and make an addressing plan with a good growth path 📈. If subnetting is being a nightmare, the 16-bit class C block (255 contiguous class C network numbers) can be used instead 🫶

Running multiple IP (sub)nets on the same physical medium has so many pitfalls 🙈. We recommend avoiding it, unless the operational problems are well understood and it's proven that all your equipment supports this properly.

Moving a single host between private and public status usually means a change of address and, in most cases, physical connectivity too 🔌. In places where these changes can be foreseen (machine rooms etc.), it may be advisable to configure separate physical media for public and private subnets. That makes future changes way less painful 💜

Changing the status of all hosts on a whole (sub)network can be done easily, and without disruption for the enterprise network as a whole ✨. So it's advisable to group hosts whose connectivity needs might change in similar ways in the future onto their own subnets. Organized, iconic, no notes 💅

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. This prevents packet and routing information from leaking out 🚫. An enterprise should also filter any private networks from inbound routing information. Why? To protect itself from ambiguous routing situations, which can happen if routes to the private address space point outside the enterprise 😭

Groups of organisations that foresee a big need for mutual communication can consider forming an enterprise together, by designing a common addressing plan. They'd also need the necessary organisational arrangements, like a registry 🗂️

If two sites of the same enterprise need to be connected through an external service provider, they can consider using an IP tunnel. That way, packets don't leak from the private network 🦋

A possible way to avoid leaking DNS RRs is to run two nameservers. One external server is authoritative for all globally unique IP addresses of the enterprise. One internal nameserver is authoritative for all IP addresses of the enterprise, both public and private 🌈. To keep everything consistent, both servers should be configured from the same data, and the external nameserver only receives a filtered version of it. Two servers, one source of truth, zero drama 👑

The resolvers on all internal hosts, both public and private, query only the internal nameserver 🔍. The external server answers queries from resolvers outside the enterprise, and it's linked into the global DNS. The internal server forwards all queries for information outside the enterprise to the external nameserver, so every internal host can still reach the global DNS. This ensures that information about private hosts never reaches resolvers and nameservers outside the enterprise. Privacy served 💅✨

---

6. References 📚

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

---

7. Security Considerations 🔐

Okay, serious moment, bestie 😭. Using private address space can improve security, but it is not a substitute for dedicated security measures. Private addresses alone won't protect you. Please don't treat them as a security blanket 💀

---

8. Conclusion 🎉

With this 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 get increased flexibility from a relatively large private address space too. Everybody wins, it's giving balance ⭐

---

9. Acknowledgments 🫶

We would like to thank Tony Bates (RIPE NCC), Jordan Becker (ANS), Hans-Werner Braun (SDSC), Ross Callon (Wellfleet), John Curran (NEARNET), Vince Fuller (Barrnet), Tony Li (cisco Systems), Anne Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (RIPE NCC), and Geza Turchanyi (RIPE NCC) for their review and constructive comments. The squad really showed up for this one 💖

---

10. Authors' Addresses 🖋️

Yakov Rekhter

Yakov Rekhter
T.J. Watson Research Center, IBM Corp.
P.O. Box 218
Yorktown Heights, NY, 10598

Phone: +1 914 945 3896
Fax: +1 914 945 2141
EMail: yakov@watson.ibm.com

Robert G Moskowitz

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: 3858921@mcimail.com

Daniel Karrenberg

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

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