Help with DHCPv6 client-identifiers

[Peter Grandi]

>>> Of course using prefixes wider than /64 doesn't break
>>> IPv6. It breaks SLAAC, which is not at all the same thing. [
>>> ... ]

>> Well, it depends on what one means by "prefixes wider than
>> /64" and "break IPv6". A core decision about IPv6 has been
>> that only /64 is *generally routable*. [ ... ] This is not
>> because it would not work for technical reasons; conceivably
>> the routable prefix could be anything up to /128. [ ... ]

> This "convention" has been dead for many years. Routers route
> on all 128 bits.

it is not ded, it is really deeply embedded in the whole IPv6
addressing structure. The first 64 bits are routeable (or local)
network address, the last 64 bits are non-routeable interface
address in the network.

There are plenty of /64 network prefixes and it is certainly not
needed to have longer network prefixes.

[ ... ]

> Let's turn it around - can you give examples of routers that can
> *not* route on the full 128 bits?

It does not matter, because it is proscribed. Using more than
/64 for routing is like assuming specific values for reserved
fields.

It works until it breaks, and even worse, just like assuming
specific values in reserved fields, if it becomes widely used
enough in practice, that becomes a "de-facto" change to the
standards and will restrict the future flexibility of protocol
evolution.

For example, so far most IPv6 stuff is marketed as high-end
added-cost option, but I can easily imagine some time soon some
engineer in Taiwan or Guangdong or Bangalore will be designing
in a hurry to a low price target an IPv6 routing chipset with
64-bit only routing tables. It would be very disappointing if
this were discouraged by the "de-facto" global usage of network
prefixes longer than 64 bits.

[ ... ]

>> * It is rather unwise to do so, because it may trigger corner
>> cases, especially in networks exposed to the Internet.

> Then those corner cases need to be found and fixed. [ ... ]

By making sure that only 64 bits are routed to avoid supporting
a widespread adoption of longer network prefixes.