At Fri, 24 Feb 2017 02:20:09 -0600,
David Farmer <farmer@xxxxxxx> wrote:
> > IPv6 unicast routing is based on prefixes of any valid length up to
> > and including 128 [BCP198]. However, subnet prefixes of 64 bits in
> > length are REQUIRED for use with Stateless Address Autoconfiguration
> > (SLAAC)[RFC4862] and are RECOMMENDED for all other general purpose
> > use. The rationale for the 64 bit boundary in IPv6 addresses can be
> > found in [RFC7421].
> >
> > Except RFC4862(SLAAC) does not say anywhere that 64 bits long IIDs are
> > required.
> > Only mention I find of 64 is given as an example for EUI-64 for ethernet
> > links.
>
> I believe most implementations of SLAAC require /64, but I could be wrong.
I don't know about "most implementations", but at least BSD variants
don't unconditionally require /64 for the IID (and therefore prefix)
length of SLAAC. It literally implements what RFC4862 states:
interface identifier - [...] The
exact length of an interface identifier and the way it is created
is defined in a separate link-type specific document that covers
issues related to the transmission of IP over a particular link
type (e.g., [RFC2464]).
That is, for the SLAAC implementation the length of the IID is a
parameter per link-type, not a magic constant value of 64. And, as
specified in RFC2464, the value for Ethernet links is defined to be
64. For an external observer it may not be distinguishable from the
magic number is hardcoded as if required for the entire
implementation, but the actual implementation is far from that.
So, aside from whether the above text is good in the main context of
this thread, just to make it more accurate it should be, e.g.:
IPv6 unicast routing is based on prefixes of any valid length up to
and including 128 [BCP198]. However, subnet prefixes of 64 bits
are REQUIRED for use with Stateless Address Autoconfiguration
(SLAAC)[RFC4862] in some link types such as Ethernet [RFC2464]. [...]
BTW, I think your idea of separating the implementation guidance and
operational guidance can be a compromise. If I correctly interpret
the interests of main stake holders in this thread, these are:
- some educated adults (aka "operators") want to be allowed to
configure there IPv6 addresses with an arbitrary IID (and therefore
arbitrary length of subnet prefix). and they don't want rfc4291bis
to explicitly ban such an operation
- some implementers want to be allowed to write code that only allows
64-bit IIDs for IPv6 addresses (except those that start with the
binary value 000) to configure for that implementation. and they
don't want rfc4291bis to make such an implementation non-compliant.
- maybe some others also want to use the existence of such
implementations as leverage to refuse ISPs offering very small size
of subnet.
If I'm correct that these are main concerns, text like your proposal
seems to meet these even if no one is completely satisfied.
--
JINMEI, Tatuya