Re: draft-bourbaki-6man-classless-ipv6-00

[Philip Homburg <[e-mail]>]

>> look into the numbers, I assume there are one huge group missing
>> there, the enterprises and that's where the money, and damage will be
>> done.
>
>You talk about "damage", I think what you meant to say is "finally, the
>enterprise will deploy IPv6 too".

The way I see it, at a fundamental technical level, this draft is wrong.

Now if this draft were to say that in the case of address assignment using
DHCPv6 IA_NA or when using static addresses, hosts should support any
prefix length, then I would be perfectly okay with that.

In general we can assume that operators know how to run a network and it
is perfectly possible to run a network on just DHCP or static.

With this in mind, if enterprises want to make their lives easier, they
should tell vendors that refuse to support DHCPv6, that in a couple of
your their devices will not work anymore on enterprise networks. Support
DHCPv6 or be gone.

However, that is not what the draft actually says. The draft tries play games
with SLAAC, and that is a bad idea.

Traditionally, SLAAC used modified EUI-64 interface identifiers, which are
of course exactly 64 bits. So that implies a hard 64-bit boundary.

In recent years there has been a change to pseudo random interface identifiers.
Because the boundary was effectively at 64 bits, none of those RFCs
contains a specification of what the minimum amount of randomness has to
be to avoid problems.

Leaving that to the network operator without any kind of constraint or
guidance is just a recipe for disaster. So without an RFC that properly
sets a lower limit for pseudo random IIDs, this draft is a bad idea.

Moving on to a network architecture point of view, when using pseudo random
IIDs there will be a longest prefix that can be supported. Lets say for the
sake of argument we can support of /96.

Then the effect will be that if in the future hosts support SLAAC upto /96
then we are back at the same hard limit. We have just moved be boundary by
32 bits.

At the moment we don't have an address shortage. Any kind of address shortage
at the moment is due to a combination of political and commercial issues
(with a hint of political issues masking as technical issues thrown in).

There is no reason to expect this to change if we make longer prefixes possible.
It is just that end users will then end up with a /96 and find that they
can't subdivide it any further.

So, to make a full circle, if you want to deploy long prefixes, limit yourself
to DHCPv6 and static. If you find that hosts routinely have problems with
long prefixes in combination with DHCPv6 or static then write a draft about
that.

Do not try to move the boundary for SLAAC. That may give a short term gain,
in the long run that just locks ourselves in a small corner.