Re: [v6ops] draft-ietf-6man-rfc4291bis prohibiting non-/64 subnets

[Philip Homburg <[e-mail]>]

>For enduser deployment picking 'something' (/64 is perfectly fine) is
>totally sane, and already in the proposed text. The sticking point isn't so
>much: "ipv6 is ipv4 with  more bits" (which the network treats it as) but:
>"hey, we know we allocate longer prefixes all the time for 'reasons' on
>things that have bespoke config, let's not make that harder by letting
>vendors/etc take shortcuts... acknowledge the fact that we really do have
>interfaces with >/64 deployed.

I wonder if (in typical IPv4 fashion) we mix address configuration with
onlink prefixes.

There are three generic address configuration mechanisms, SLAAC, DHCP IA_NA,
and manual. Of these only SLAAC cares about the prefix length. And there
are good reasons to keep SLAAC at 64 bits.

(If would strongly suggest to not pick a random 32 bit IID, combine it
with a /96 and then hope that duplicate addresses detection in all cases
will safe the day. So for longer prefixes, use DHCP or manual configuration.)

For DHCP and manual configuration, an address is just that, an address.
So in that case, the prefix length actually refers to the length of the
onlink prefix.

Note that RFC 4861 (Neighbor Discovery) already specifies that an onlink
prefix can have arbitrary length. 

So it safe to assume that hosts can support arbitrary length onlink
prefixes. Otherwise those host implementations are already broken.

DHCP doesn't have a prefix length, so that's not an issue.

So that leaves hosts that mistakenly combine manual address configuration
with implicit onlink prefix configuration and an arbitrary restriction
on the prefix length. It is safe to declare those hosts broken.