[arin-ppml] Controlling the IPv6 address consumption rate
On Oct 14, 2010, at 6:24 PM, William Herrin wrote:
> Hokay. Sure. Did it offend you that I described that I described the
> local LAN as robbing from routing? Would you prefer something along
> the lines of, "From the routing perspective, IPv6 is only 64 bits
> large, not 128?" I humbly apologize for my choice of words.
I think there is a question of requirements. Hopefully I can say this without people throwing bricks.
The requirements IPv6 was developed against include but are not limited to
1726 Technical Criteria for Choosing IP The Next Generation (IPng). C.
Partridge, F. Kastenholz. December 1994. (Format: TXT=74109 bytes)
That RFC states:
The IPng Protocol must scale to allow the identification and
addressing of at least 10**12 end systems (and preferably much
more). The IPng Protocol, and its associated routing protocols
and architecture must allow for at least 10**9 individual networks
(and preferably more). The routing schemes must scale at a rate
that is less than the square root of the number of constituent
We note that one of the white papers solicited for the IPng
process  indicates that 10**12 end nodes is a reasonable
estimate based on the expected number of homes in the world and
adding two orders of magnitude for "safety". However, this white
paper treats each home in the world as an end-node of a world-wide
Internet. We believe that each home in the world will in fact be
a network of the world-wide Internet. Therefore, if we take 's
derivation of 10**12 as accurate, and change their assumption that
a home will be an end-node to a home being a network, we may
expect that there will be the need to support at least 10**12
networks, with the possibility of supporting up to 10**15 end-
First and foremost, the routing architecture must scale to support
a very large Internet. Current expectations are for an Internet
of about 10**9 to 10**12 networks. The routing architecture must
be able to deal with networks of this size. Furthermore, the
routing architecture must be able to deal with this size without
requiring massive, global databases and algorithms. Such
databases or algorithms would, in effect, be single points of
failure in the architecture (which is not robust), and because of
the nature of Internet administration (cooperative anarchy), it
would be impossible to maintain the needed consistency.
There are several numbers in there - 10^9, 10^12, and 10^15 figure prominently.
pulling out my trusty gonkulator, aka 'bc':
so, 10^9 is a 30 bit number, 10^12 is a 40 bit number, and 10^15 is a 50 bit number. IPv6's original design basically was IPv4 with 64 bit addresses, and I think anybody looking at that would have agreed that, if addresses are handled the way they are handled in IPv4, it met the requirement. It allowed you to represent 10^9 or 10^12 networks (LANs) in the global Internet, and it allowed you to handle 10^12 or 10^15 systems in the global Internet.
What we wound up with separates the LAN identifier - the prefix by any other name - into one place, and puts the host identifier in another. You not only can represent at least 10^12 identifiable LANs (40 bits fits in 64), but allows you to fit at least 10^15 hosts (50 bits fits in 64) on each LAN.
Now, you can argue that the requirements were incorrect. If so, please advise: how many LANs in the world do you need to be able to individually enumerate, and what are your aggregation requirements? How many hosts per LAN? In the Smart Grid, we actually do have things that map to IP subnets that want to have O(10^5) hosts in them...
If you can't justify changing the requirement - if you can't show how 64 bits for the prefix just isn't enough, or 64 bits for the host identifier just isn't enough, or that the only way the address can be organized is the way it was done in IPv4, I have to say that your engineering requirements have been met. That happens to be what I personally believe. I'm sorry you don't like the way it was done. You weren't shortchanged.