RFC4862 and 64-bit IID (Re: draft-bourbaki-6man-classless-ipv6-00)

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

At Sat, 10 Jun 2017 15:24:34 +0200,
[e-mail] wrote:

> >> do we have a rationale for fixing the value in the IPv6-over-foo documents (anymore)?
> > 
> > My rationale is that
> > 
> > a) RFC4862 describes it very carefully as a parameter.
> 
> And explicitly says it must be consistent with the value defined in 4291 and IPV6 over foo documents.

It's actually subtle how RFC4862 ended up with the current text.  It
might help if we recall the discussion at that time:
https://www.ietf.org/mail-archive/web/ipv6/current/msg01797.html

Different people may interpret it in different ways, but my
recollection is that

- we actually thought it was quite unlikely to see a change to the IID
  length, not least because the addressing architecture spec (RFC3513
  at that time) is "100% unambiguous" about it, i.e., 64 bits.
- but, the addr-arch and link-type specific documents defined the
  length (seemingly) independently.  RFC2462 referred to addr-arch in
  one place and referred to link-type specific docs in other place.
  RFC2462 also mentioned the magic number of 64.  Since the
  relationship between the addr-arch and link-type is not explicit
  this could potentially lead to inconsistency between them (we only
  relied on the IETF human review process for consistency).
- ideally we should have resolved this fragility at that point, but it
  was considered out of scope of rfc2462bis (and probably rightly so).
- as a result, in rfc2462bis we decided to remove the reference to the
  magic number to avoid further possible conflict and specify
  link-type specific docs as the primary source of the IID length,
  while noting the addr-arch defines the length so it will be less
  likely to cause inconsistency if and when either of them is updated.
  And, as long as we use link-type specific documents as the primary
  source, it's natural to expect it might be different for different
  link types (no matter how unlikely it was deemed due to the
  constraint of addr-arch).  So we also added notes to implementations
  not to assume a particular constant.

In a nutshell, RFC4862 is not an appropriate source as a supporting
material for either position on this matter, whether to keep fixing 64
or make it more variable even in practice.  RFC4862 tried to keep
itself as independent as possible from that discussion, while being
sufficiently flexible in case the current practice (i.e. fixed 64)
ever changes.

I'd also note once again that this discussion has nothing to do with
the fact that we can perform 'ifconfig en0 2001:db8::1/120'.  This
operation configures a 128-bit IPv6 address with 120-bit on-link
prefix.  On-link prefixes have always been variable, and they have
nothing to do with IID length or SLAAC.  We don't have to update
addr-arch or RFC4862 because of this.  (draft-bourbaki-6man-classless-ipv6-00
seems to be confused on this point, and I suspect it increases the
confusion and controversy in this whole thread).

--
JINMEI, Tatuya