[arin-ppml] Controlling the IPv6 address consumption rate

Fred Baker fred at cisco.com
Fri Oct 15 00:52:00 EDT 2010


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 

http://www.ietf.org/rfc/rfc1726.txt
1726 Technical Criteria for Choosing IP The Next Generation (IPng). C.
     Partridge, F. Kastenholz. December 1994. (Format: TXT=74109 bytes)
     (Status: INFORMATIONAL)

That RFC states:

   CRITERION
      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
      networks [10].

      We note that one of the white papers solicited for the IPng
      process [5] 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 [5]'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-
      nodes.

      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':

10^9
1000000000
10^12
1000000000000
10^15
1000000000000000
obase=16
10^9
3B9ACA00
10^12
E8D4A51000
10^15
38D7EA4C68000

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.


More information about the ARIN-PPML mailing list