>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.