Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]