[ppml] IPv6>>32

Mon May 9 11:12:18 EDT 2005

                             IPv6>>32

There has been a lot of talk about IPv6 addressing, and how well
it will scale.  Geoff Houston (David Conrad) presented a very well
researched paper at the Orlando meeting which documented the use
of address space.  You can read a copy of it here:
http://www.arin.net/meetings/minutes/ARIN_XV/PDF/wed/Round_Table.pdf

The net result is that we're poised to burn through a /1 to a /4
of the IPv6 address space in the next 60 years based on our best
current guesses.  This makes me extremely nervous.  If anything the
past shows that we are generally poor predictors of the future, and
also that more often than not we predict too low.  I also believe
that we should be able to do much better than 60 years.  IPv4 is
conservatively going to last at least 30 years before it is replaced,
and likely more like 40+ years.  To expect that with those 30-40
years experience that we can only double the life of the next
protocol is a poor target.

Fortunately, there is no fundamental design flaw.  The protocol is
not broken, the addressing design is not broken.  Indeed, the basic
IPv6 architecture documents call for a "variable length subnet mask"
basic implementation.  If we look at RFC 3513, we see that in section
2.5 standard behavior is a variable length subnet mask sort of
behavior, but later in section 2.5.4 we see where 64 bits are
dedicated to the host function.  See: http://www.faqs.org/rfcs/rfc3513.html

What the IETF has done is separate a "host portion" and a "routing
portion" on a /64 boundary.  Having a fixed host portion is convenient
for many reasons.  It allows for autoconfiguration (a la RFC 2462).
It also allows the mapping of a globally unique identifier into the
address.  In the IPv6 case they chose the IEEE's EUI-64 ID (see
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html).

However, now that the host is guaranteed globally unique, it raises
new privacy concerns.  Indeed, these have already been recognized
by the IETF, and are addressed in RFC 3041 (see
http://www.faqs.org/rfcs/rfc3041.html).  Without trivializing the
work in the paper, the solution is basically to use randomized
addresses.  As there is a 64 bit space to work with the probability
of collision is low, and IPv6 already requires Duplicate Address
Detection (DAD) to prevent duplicates from occurring.

One item not addressed in any IETF documents is that most sites
will probably continue to use DHCP to assign addresses.  While IPv6
allows a host to obtain an IPv6 address and determine its default
gateway, it does not pass any of the other information administrators
have come to rely on being in DHCP.  These features include, but
are not limited to DNS information, services information including
boot servers, WINS servers and the like, and time servers.  DHCP
servers also generally update dynamic DNS, allowing the host to
have a stable DNS entry.  All of these point to administrators still
using DHCP even where autoconfiguration is available.

With that background out of the way, a picture is formed where there
is 64 bits of routing information, and 64 bits of host information.
Geoff's paper and proposals for HD ratio address only the 64 bits
of routing information, and how we can recover bits on that side
of the equation.  That's good, and gains us some headroom, but
leaves half of the problem unaddressed.  To address the host portion,
we need to look at the good parts of what the IETF has done:

- Autconfiguration is a nice feature, and may be useful for some
  devices.
- Fixed size host portions facilitate renumbering and easy
  administration.
- Byte boundaries are good.

However, we also have to look at the bad parts:

- EUI-64 addresses are Globally Unique, which is not necessary for
  the host portion.
- EUI-64 in the address raises privacy concerns.  - EUI-64 depends
  on the continued maintenance and management of the
  IEEE.

There is also the unknown:

- It has been stated that there may be future applications developed
  around the fact that the host portion is globally unique.
- It has been stated that it is useful to have the routing portion and
  the host portion be the same bit size, so that one can be embedded in
  the other.

To preserve the good, and eliminate the bad, I propose a simple
change.  Shift all of the current policies to the right by 32 bits.
That is, the host portion becomes a 32 bit quantity.  EUI-64's
would no longer be used, all hosts would simply randomly generate
addresses for autoconfiguration.  This is already the direction the
privacy work is going.  32 bits is more than enough to allow random
address selection on extremely large lans (10-50,000 addresses)
with minimal collisions.  The host portion would still be fixed,
allowing for easy renumbering, autoconfiguration, and similar
features.

All other boundaries move down as well:

- A /64 subnet becomes a /96 subnet.
- A /48 assignment becomes a /80 assignment.
- A /32 ISP allocation becomes a /64 ISP allocation.

Coming back to Geoff's numbers.  If he's right about a /1, the
entire routing system will now fit in a /33 in 60 years, without
changing the HD Ratio.  Less space than we use for a single ISP
today is enough to number the entire world based on our current
understanding.  Note also that the byte boundaries are preserved
allowing for easy DNS administration and other features.

More importantly, if Geoff is off by an order of magnitude (which
is about 3.2 bits), under the current system we'd be short about 2
bits to number everything.  With this change, we would simply consume
a /29.

The largest down side I can find is the unknowns listed above.  It
appears some people are thinking of applications that require the
host portion to be globally unique, and/or applications that depend
on being able to imbed a prefix in the host portion, or a host
portion in the prefix portion.  I have been unable to find any hard
documentation on either of these applications, and I would be
extremely interested in any defined uses of these behaviors.

To me, a change such as this provides several safety nets:

- If we're off by an order of magnitude or more, we don't run out
  of space.
- If we've gotten this 100% wrong, we will have used around a /32 in
  60 years allowing us to adjust the addressing plan without having to
  deploy an entirely new protocol to do it.
- It allows a large amount of growth room for the unknown.
- IPv6 should be able to last significantly longer than 60 years.

Obviously, there are a few down sides:

- The specification and code to do autoconfiguration will have to be
  changed.
- This leaves enough free bits on the top end to further subdivide the
  address space (one proposal would be to assign a /24 for "country
  specific" prefixes, with the next 8 bits being a country identifier
  [there are currently 191 UN members], allowing each country to have a
  /32, which is now enough space to address the entire world).
- ISP's that have already received a /32 (or larger) have made a
  successful land grab if those addresses are not reclaimed.

Finally, I'd like to close with a discussion of why I'm posting
this to PPML.  I've spoken with a number of people about the IETF
process, and what has been made abundantly clear to me is that the
IETF is not even remotely interested in opening this issue for
discussion.  They feel the current proposal out there is the best
proposal, they have fought their war to decide on it and will now
fight to leave the issue sealed.

I also think it's clear the community has some serious concerns
with the current proposal.  Geoff's paper is an illustration, and
I commend him for his work on the routing portion.  I think the
community should also take a hard look at the host portion before
it's too late.  Right now IPv6 deployment is limited, and so it's
not too late to make a change.  Another few years may get us to a
point where it is too late though, with too much inertia behind
the 64 bit boundary.

This is why PPML is involved.  I think the community needs to think
about this issue and if it is worth discussing.  I'm not sure my
proposal is "the best" or even good, but without a straw man to
dissect the discussion will not be complete.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050509/0ef466c0/attachment.sig>