RFC 1627

Network 10 Considered Harmful 🎀

(Some Practices Shouldn't be Codified) 💅

Okay bestie, check the header. This is Request for Comments: 1627, filed under the Network Working Group 📄 It's Category: Informational, so it's giving "here's some info" vibes, not a standard 🤓 It's dated July 1994 🌸 The authors are E. Lear from Silicon Graphics, Inc., E. Fair from Apple Computer, Inc., D. Crocker from Silicon Graphics, Inc., and T. Kessler from Sun Microsystems, Inc. ✨ Nothing in the header says it obsoletes or updates anything, so it's a solo main character 💜

---

Status of this Memo 📜

This memo provides information for the Internet community 💖 It does not specify an Internet standard of any kind, so it's not a rulebook, just info 🫶 Distribution of this memo is unlimited 🌈

---

SUMMARY ✨

Okay so the hot topic here is re-using Internet addresses for private IP networks, which is what the recent RFC 1597 [1] is all about 🦋 It sets aside a bunch of IP network numbers that any number of organizations can (re-)use, as long as those networks don't get routed outside whatever single private IP network they're in 🏠 But here's the tea: RFC 1597 goes against the basic architectural rule that IP addresses must be globally unique 😬 and it did that without the usual public review and approval from the IETF or IAB. So this doc restates why a unique address space matters, and digs into Internet architecture, operations, and IETF procedure too 🧐

---

INTRODUCTION 🌸

Internet tech and attachments have grown so much that we're literally in danger of running out of unassigned IP network numbers 😭 At first, numbers only got formally assigned when a network was about to hook up to the Internet 🤔 That caused problems when IP was already in use way before anyone decided (or got permission) to connect, and re-numbering was super painful 💀 The big lesson we learned: every IP address ought to be globally unique, no matter whether it's attached to the Internet 🔥 That's what lets any two network entities talk to each other, no matter where either one is 🌍 This model came from decades of evolution, where the community realized how painful it is to convert a network of computers to an assigned number after they've been using random or default addresses straight out of the box 📦 RFC 1597 throws this model out without general IETF community discussion or consensus, which leaves all the policy and operational questions unasked and unanswered 🙈

---

KEEP OUR EYES ON THE PRIZE: AN ARCHITECTURAL GOAL AND VIOLATION 👑

A common (if not universal) dream for the future of IP is that every system is globally accessible, as long as the proper security mechanisms are in place 🌈 Whether we're talking about toasters, light switches, utility power poles, field medical equipment, or the classic "computers," our current model of assignment makes sure they can all interoperate 🧚

For that to work, a globally unique addressing system must exist 💜 Lots of people complain that existing security in host software doesn't let every (or even many) hosts in a corporate environment have direct IP access 😤 Once that's fixed with proper privacy and authentication standards, non-unique IP addresses are going to become a bottleneck for easy deployment if we follow RFC 1597's recommendations 🚧

The IP version 4 (IPv4) address space is gonna run out 😭 The only question is: when?

If we say all IP addresses must be globally unique, connected or not, we run out of IP address space soon 😬

If we only say addresses used on the world-wide Internet need to be globally unique, we run out later ⏳

It's absolutely key that the Internet community stays focused on IP next generation (IPng) so we can transcend the limits of IPv4 🚀 RFC 1597 looks like it gives relief from IPv4 running out, but really it just hides the networks that aren't connected to the Internet today 🫠 That fake relief will likely cause two things: complacency from the big chunk of the community that doesn't think long term, and a super sudden IP address space exhaustion at some later date 💀

Before IPng gets deployed, we really need to keep all the semantics that make the Internet and Internet tech so valuable for interoperability ✨ Like, Apple Computer, IBM, and Motorola could not collaborate as easily as they have to produce the PowerPC without uniquely assigned IP addresses 🖥️ The same goes for the Silicon Graphics merger with MIPS. And there are many, many more examples 🙌

Here's the thing: a scheme similar to RFC 1597 could totally be done once we actually run out of assignable IPv4 address space 🤷‍♀️ It just takes organizations that were assigned addresses but aren't connected to the Internet yet to hand those addresses back to IANA. It should be noted, bestie, that the IAB (and IANA as its agent) need to reassert their ownership of the IP address space now, so nobody can challenge this type of reassignment later 🔒

---

OPERATIONAL ISSUES 🛠️

RFC 1597 Implementations 🧩

We need methods to make sure the remaining addresses get allocated and used frugally 💸 Because of current problems, Internet service providers have made it harder and harder for organizations to get public IP network numbers 😤 Private networks have always had the option of using addresses that weren't assigned to them by the right authorities 🤫 Nobody knows how many of these networks exist, since by nature they don't talk to the global Internet 👀 If a company picks a random address, it must take some care to make sure it can still route to the properly registered owner of that network 🧭

RFC 1597 tries to fix the routing problem by assigning numbers that will never be used outside private environments 🔧 Using those standard numbers creates a clash risk in a whole other way 😬 If two private networks both follow RFC 1597 and later want to talk to each other, one of them has to renumber. Same problem if a private network wants to go public. The likely cost of renumbering is linear to the number of hosts on a network, so a big company with 10,000 hosts could rack up serious expense if it merged with another company or joined the Internet so all hosts could directly access the outside network 💸

Over time, the chance of address clashes with RFC 1597 approaches 100% 💀 Picking a random network number lowers the chance of renumbering hosts, but it brings back those routing problems from earlier 🙃 Best of all, grabbing assigned numbers from the right authority in the first place kills both existing and potential address conflicts. The price? You use up a chunk of the address space 🎟️

Apple Computer once thought none of its internal systems would ever speak IP directly to the outside world, so network ops just picked IP class A network 90 out of thin air 🙈 Apple is only now recovering from that mistake, after renumbering some 5,000 hosts so they could get "desktop" Internet access 😭 Unless the Internet community reaffirms its commitment to a globally unique address space, we're basically condemning many thousands of organizations to the same pain when they try to answer the call of the global Internet 📞

Another timely example of RFC 1597 causing trouble is Sun's Internet multicasting 🎶 Sun selectively relays specific multicast conferences, which makes lots of Sun hosts visible to the Internet even though they can't be reached by IP unicast routing 👀 If those hosts had non-global addresses, this wouldn't work at all 🙅‍♀️ You just can't predict in advance which machines need global addresses. Silicon Graphics has a similar setup, and it's likely others do too 🤓

Some people might argue that assigning numbers for private networks will stop accidental leaks through a convention like Martian packets 🤔 Sure, the proposal tries to make a standard for "private" address use, but there's absolutely no way to make sure other addresses aren't also being used 🚫 So the "standard" ends up being nothing but a misleading heuristic 🫤 Honestly, it's essential that routers to the global Internet advertise networks based only on explicit permission, instead of refusing to advertise others based on implicit prohibition, which is the approach the policy formally created in RFC 1597 supports 📜

Security Issues 🔐

Admins are gonna have a hard time spotting unauthorized networks when their network gets breached (on purpose or by accident), because other networks might have the same numbers as the ones normally in the routing tables 🕵️ Plus, an accidental connection could have a double whammy effect and partition two operational networks 💥

Worth emphasizing: IP providers should filter out all but authorized networks 🛡️ That would not only prevent accidents, it'd also make the Internet more secure by cutting down the potential number of points of attack 🔒

Heads up, bestie: duplicate numbers can hide unauthorized networks, and that's a security problem, not just a fun fact 😤

Internet multicasting adds a whole new dimension to security 🌀 In some cases it may be possible to allow multicasting through firewalls that completely restrict unicast routing. Otherwise, unconnected networks might well need unique addresses, like in the example above 🧠

Problems with Examples 🧐

RFC 1597 gives a bunch of examples of IP networks that don't need globally unique address spaces 📚 Each one is plausible, but that doesn't make it legit to ENCOURAGE non-uniqueness of addresses 🙅‍♀️ In fact, it's just as plausible that globally unique IP addresses will be required in every single one of the scenarios RFC 1597 describes:

• Airport displays are public info, and multicasting beyond the airport might be useful ✈️
• An org's machines that don't need global connectivity today might need it tomorrow 📅 Plus, merging orgs creates havoc when the addresses collide 💥
• Using firewalls right now is an artifact of tech limitations 🧱 Let's fix the problem, not the symptom 💡
• Inter-org private links don't get any extra benefit from being more accurate about guessing which machines want to interact than general Internet access does 🔗

Okay, this point is worth repeating: the belief that admins can predict which machines will need Internet access is just plain wrong 🙅 We need to reduce or eliminate the penalties tied to that mistake, so we can encourage as much Internet connectivity as operational policies and technical security allow 🌐 RFC 1597 works very much against this goal 😤

Problems With "Advantages" And More Disadvantages ✨

okay so RFC 1597 says CIDR will make enterprises renumber their networks 🙄. In the general case, though, that only involves networks that are routed outside of enterprises. RFC 1597 is about private enterprise networks, so this argument does not apply 💅.

The authors bring up DCHP-based tools [2] as something that might help with network number transition 🧚. ngl, by and large those tools are still only "potential" right now 💀.

It's also giving chaos with ISDN, slip, and PPP showing up in host implementations 😭. The chance that a workstation accidentally becomes a router has never been higher. And if everyone uses the same set of addresses for private networks, administrators are basically guaranteed to get their networks partitioned, unless they're super careful about controlling modem connections 🫠.

Last thing, RFC 1597 kind of implies that changing a host's IP address is easy 🙈. It's not always, and it's not the norm today. A host might be well known inside a network, or have long-standing services like NFS, and changing its address would break things for clients 🥺. A host might also have software licenses locked to its IP address. So moving a host from private to global addressing could be a real struggle 💔. At the very least, you should be careful about addressing well known hosts 🫶.

POLICY ISSUES 🎀

IANA Has Overstepped Their Mandate 👑

For many years, IANA has followed an assignment policy based on the expectation of Internet connectivity for ALL assignees 🌐. That policy encourages interconnectivity. Assigning the network numbers listed in RFC 1597 formally authorizes behavior that goes against this accepted practice, and honestly that's a big deal 😤. Also, this change happened without any community review or approval, which is not it 🙅‍♀️.

RFC 1597 sets a brand new operational requirement, and it's very explicit about it: network service providers must filter the IANA assigned network numbers listed in RFC 1597 out of their routing tables 🚫. This address space is permanently removed from use on the Internet. Permanently. 😭

As we read RFC 1601 [3], this isn't in IANA's purview. IANA should only be assigning numbers within the current standards and axioms that underlie the Internet 📜. IP network numbers are assigned uniquely on the assumption that they'll be used on the Internet at some future date. These assignments break that axiom and count as an architectural change to the Internet 🏗️. RFC 1602 [4] and RFC 1310 [5] also contain identical wording to this effect, in the section that describes IANA 📖.

RFC 1597 has a view that's worth public debate 🗣️, but it isn't ready for formal authorization. So we strongly encourage IANA to withdraw its IP address assignments documented by RFC 1597 forthwith 🛑.

The IAB should review the address assignment policies and procedures that make up IANA's mandate, and reaffirm the commitment to a globally unique IP address space 🌈.

COMMENTS AND CONCLUSIONS 💜

The Internet technology and service is built on a global address space 🌍. The Internet community has already lived through the problems and pain of uncoordinated private network number assignments, so we know how that goes 😩. Basically, this proposal tries to codify uncoordinated behavior and change the accepted Internet addressing model 🙃. That means it needs a much more thorough look, bestie 🔍.

RFC 1597 gives the illusion of fixing a problem by putting formal structure around a long-standing informal practice 🎭. Honestly, that structure is a distraction from solving these very real problems, and it doesn't even provide substantive help in the near term 😵‍💫.

We've all dreaded the idea of any part of the address space being reused 😰. Plenty of luminaries have written and spoken at length about why we want direct connections from one host to another 🎤. Before we stray from the current architectural path, the community should revisit the reasoning behind the push for unique addressing 🔄. RFC 1597 tries to change this model, and its costs and limitations for enterprises can be enormous, in both the short and long term 💸.

REFERENCES 📚

• [1] Rekhter, Y., Moskowitz, B., Karrenberg, D., and G. de Groot, "Address Allocation for Private Internets", T.J. Watson Research Center, IBM Corp., Chrysler Corp., RIPE NCC, RFC 1597, March 1994.
• [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, Bucknell University, October 1993.
• [3] Huitema, C., "Charter of the Internet Architecture Board (IAB)", RFC 1601, IAB, March 1994.
• [4] Internet Architecture Board, Internet Engineering Steering Group, "The Internet Standards Process -- Revision 2", IAB, IESG, RFC 1602, March 1994.
• [5] Internet Activities Board, "The Internet Standards Process", RFC 1310, IAB, March 1992.
• [6] Internet Activities Board, "Summary of Internet Architecture Discussion", Notes available from ISI, [ftp.isi.edu: pub/IAB/IABmins.jan91Arch.txt], IAB, January 1991.

SECURITY CONSIDERATIONS 🔐

Security is no joke, so pay attention here 🚨. Please see the section, "Security Issues", earlier in this document. That's where the real security concerns are covered, and they're serious 🙏.

AUTHORS' ADDRESSES 🦋

Eliot Lear
Silicon Graphics, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA
94043-1389

Phone: +1 415 390 2414
EMail: lear@sgi.com

Erik Fair
Apple Computer, Inc.
1 Infinite Loop
Cupertino, CA 95014

Phone: +1 408 974 1779
EMail: fair@apple.com

Dave Crocker
Silicon Graphics, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA
94043-1389

Phone: +1 415 390 1804
EMail: dcrocker@sgi.com

Thomas Kessler
Sun Microsystems Inc.
Mail Stop MTV05-44
2550 Garcia Ave.
Mountain View, CA 94043

Phone: +1 415 336 3145
EMail: kessler@eng.sun.com

---

And that's the whole RFC, bestie 🌈💖