[ppml] Policy Proposal 2005-8: Proposal to amend ARIN IPv6assignment and utilisation requirement - Last Call

[Tony Hain]

Thomas Narten wrote:
> ...
> Actually, the text about stateless addrconf is not quite
> true. Stateless addrconf can handle any prefix length, but the real
> issue is that it contains the following line:
> 
> 
> >        If the sum of the prefix length and interface identifier length
> >        does not equal 128 bits, the Prefix Information option MUST be
> >        ignored.
> 
> The rules for constructing interface identifiers are specific to each
> link-layer type (e.g., ethernet vs. token ring vs. ...). And in all
> the individual IPv6-over-linklayer documents, the interface identifier
> is specified to be 64 bits. Plus, RFC 4291 "IP Version 6 Addressing
> Architecture" does say:
> 
> >    For all unicast addresses, except those that start with the binary
> >    value 000, Interface IDs are required to be 64 bits long and to be
> >    constructed in Modified EUI-64 format.
> 
> So, if one wants to use stateless addr conf, we've effectively wired
> in /64.

Also note that if there is to be any hope of securing the relationship
between the endpoints and the first hop router, the currently being
implemented versions of RFC 3971 & 3972 have a need for 64 bits as the IID.

Unfortunately people need continuous reminders that under the operational
practice of that time 64 bits was determined to be 3 orders of magnitude
more than necessary for the bake-off design points of 10^12 networks & 10^15
endpoints. At the start of the bubble it looked like we would need many more
levels of hierarchy so we gave the whole 64 bit space to routing, then
debated how much more to tack on for host identifiers. Unfortunately the
conservation myopic policy community and the greedy control-mongering
routing community is not satisfied with a substantially expanded version of
'more than enough' (despite collapsing back to fewer players & levels than
before), and keeps wanting to encroach on the part the hosts are trying to
use to improve over IPv4. ISPs keep saying they want to see improvements
before they will deploy, but cry out about changing their operational
practice for anything that does actually improve an aspect they don't care
about.

There are many aspects to what makes a protocol useful, and while the
ability to globally route is an important one, it is far from the only thing
that matters. With the HD ratio at .96 and site assignments at /48 we are
looking at 500+ years of life expectancy under current practice. There is no
way this protocol will be in use that long. People need to stop trying to
optimize it for longer lifetimes, as that only reduces the ability to
innovate in other areas.

Tony