RFC 1715

The H Ratio for Address Assignment Efficiency 💖

• Series: Network Working Group 🌸
• RFC number: 1715 ✨
• Author: C. Huitema, INRIA 🧚
• Category: Informational 📚
• Date: November 1994 🗓️
• Obsoletes / Updates: none listed in the title block 🙌

---

Status of this Memo 🫶

okay so this memo is just giving information for the Internet community 💅. it does NOT specify an Internet standard of any kind, so don't go treating it like one 🙈. and distribution is unlimited, so share it with everyone bestie 🌈.

Abstract 🦋

this doc was submitted to the IETF IPng area as a response to RFC 1550. ngl, publishing it doesn't mean the IPng area agrees with any of the ideas inside, so no pressure 😌. if you have comments, send them to the author and/or the sipp@sunroof.eng.sun.com mailing list 💌.

Table of Contents 📚

   1.   Efficiency of address assignment . . . . . . . . . . . . . . 1
   2.   Estimating reasonable values for the ratio H . . . . . . . . 2
   3.   Evaluating proposed address plans. . . . . . . . . . . . . . 3
   4.   Security Considerations . . . . . . . . . . . . . . . . . .  4
   5.   Author's Address . . . . . . . . . . . . . . . . . . . . . . 4

---

1. Efficiency of address assignment ✨

okay so the big IPng debate was basically all about picking an address size 💅. the concept everyone kept bringing up was "assignment efficiency", and most people described it as the ratio of how many systems are actually in the network over the theoretical maximum. like, 32-bit IP could in theory number over 7 billions of systems 😭. but as of today there are about 3.5 millions of addresses reported in the DNS, which works out to an efficiency of 0.05% 💀.

but this classic way of measuring is kinda misleading, because it ignores how many hierarchical levels there are 🙄. IP addresses have at least three levels: network, subnet and host. so to get rid of that dependency, I propose using a logarithmic scale for the efficiency ratio:

                         log (number of objects)
                     H = -----------------------
                              available bits

H is not too dependent on the number of hierarchical levels, and that's the vibe 🫶. say you have two levels encoded on 8 bits each, versus one single level encoded in 16 bits. you get the same efficiency if you allocate on average 100 elements at each 8-bit level, or just 10000 elements in the single 16-bit level 🍓.

I use base 10 logs in what follows, bc they're way easier to do in your head 🧠. when things get huge, people love "powers of 10", like "IPng should be capable of numbering 1 E+15 systems". so with this choice, H varies between 0 and a theoretical maximum of 0.30103 (log base 10 of 2) 🌟.

---

2. Estimating reasonable values for the ratio H: 🎀

we don't actually expect to hit 0.3 in practice 😭, so the real question is what values we can reasonably expect. we can check existing numbering plans for that. the juiciest moments are when the plans broke, aka when people were forced to add digits to phone numbers or bits to computer addresses 👀. here's the tea:

• adding one digit to all French telephone numbers (8 digits to 9) when the number of phones hit a threshold of 1.0 E+7 🇫🇷. the log value is 7, the number of bits was about 27 (1 decimal digit is about 3.3 bits), so the ratio is 0.26 ✨.
• expanding the number of areas in the US telephone system so it became effectively 10 digits long, for about 1.0 E+8 subscribers 📞. the log value is 8, the number of bits is 33, so the ratio is about 0.24 💫.
• expanding the size of Internet addresses from 32 bits to something else 🌐. there are currently about 3 million hosts on the net, for 32 bits. the log of 3.E6 is about 6.5, which gives a ratio of 0.20. indeed, we believe 32 bits will still be enough for some years, e.g. to multiply the number of hosts by 10, in which case the ratio would climb to 0.23 📈.
• expanding the size of the SITA 7 characters address 🛫. according to their documentation, they have about 64000 addressed points in their network, scattered across 1200 cities and 180 countries. an upper case character gives about 5 bits of addressing, which results in an efficiency of 0.14. this is an extreme case, bc SITA uses fixed length tokens in its hierarchy 🥺.
• the globally-connected physics/space science DECnet (Phase IV) stopped growing at about 15K nodes (i.e. new nodes were hidden) 🔬. in a 16 bit space that gives a ratio of 0.26 💅.
• there are about 200 million IEEE 802 nodes in a 46 bit space, which gives a ratio of 0.18 🧃. that number space, however, is not saturated 🤷‍♀️.

from all these examples, we can assert that the efficiency ratio usually lies between 0.14 and 0.26 🎉.

---

3. Evaluating proposed address plans 🔥

using a reverse computation, we get the following population counts in the network:

                    Pessimistic (0.14)     Optimistic (0.26)

       32 bits             3 E+4 (!)           2 E+8
       64 bits             9 E+8               4 E+16
       80 bits           1.6 E+11            2.6 E+27
      128 bits             8 E+17              2 E+33

okay so this figure explains perfectly why some people feel 64 bits is "not enough" while others feel it's "sufficient by a large margin" 🙃. depending on the assignment efficiency, we're either well below the target or well above it. but in my view there's zero question that 128 bits is "more than enough" 👑. even if we presume the lowest efficiency, we're still way above the hyperbolic estimate of 1.E+15 Internet hosts 🚀.

it's also interesting that if we devote 80 bits to the "network" and use 48 bits for "server less autoconfiguration", we can number more than E.11 networks in the pessimistic case. it would only take an efficiency of 0.15 to reach the E+12 networks hyperbole 🤯.

so yeah, I feel like 128 bits is entirely safe for the next 30 years 💜. the level of constraints we'll have to build into the address assignment seems very much in line with what we know how to do today 🫶.

---

4. Security Considerations 🔐

💀 security issues are not discussed in this memo at all. not one word. the document just doesn't go there.

---

5. Author's Address 💌

Christian Huitema
INRIA, Sophia-Antipolis
2004 Route des Lucioles
BP 109
F-06561 Valbonne Cedex
France

Phone: +33 93 65 77 15
EMail: Christian.Huitema@MIRSA.INRIA.FR

that's the whole RFC, bestie 🌈💖✨