Re: draft-bourbaki-6man-classless-ipv6-00

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

At Thu, 8 Jun 2017 20:56:15 +0900,
Lorenzo Colitti <[e-mail]> wrote:

> > "Interface Identifiers should be 64 bit long except
> > when the addresses are manually configured,
> 
> In order to publish that text we need to agree on what it means. Can you
> explain the semantics of the the interface identifier of a manually
> configured IPv6 address? What are they used for?

Right, this text is actually a bit awkward in that sense.  I think
this message is a good answer to this question:
https://www.ietf.org/mail-archive/web/ipv6/current/msg27573.html

"only relevant to SLAAC" may be too strong from an architectural point
of view, but at least that's today's reality.  So "except when the
addresses are manually configured" actually doesn't make much sense.
I was aware of that oddity too, but I didn't go into this point so we
could focus on whether we can at least agree on a more higher level
point, i.e., if we can agree that manual configuration is
(effectively) an exception of the IID length woe while 64 is
acceptable for SLAAC (unless other standard protocol overturns it).
Now that we are on this detail, this is what I would envision as
something that this draft might actually have wanted to say and that
most of us can hopefully agree on:

    Interface Identifiers must be 64 bit except for addresses that
    start with the binary value 000 and unless a different value is
    defined in standards track documents.  The rationale for using 64
    bit Interface Identifiers can be found in [RFC7421].  Note that
    the separation between the interface identifier and the subnet
    prefix is not important unless the address is configured using
    stateless address autoconfiguration [RFC4862].  So, for example,
    this constraint on the length of interface identifiers is
    irrelevant to manually configured addresses in practice.

    IPv6 unicast routing is based on prefixes of any valid length up
    to 128 [BCP198], and so is on-link determination ([RFC5942],
    [I-D.jinmei-6man-prefix-clarify]).  In particular, the fact that
    the "subnet prefix" length of certain addresses is 64 in terms of
    the addressing architecture is independent from whether addresses
    that match this prefix are considered to be on-link.  For example,
    [RFC6164] standardises 127 bit prefixes for on-link determination
    on inter-router point-to-point links.  This is not contradictory
    to that an address used in this link may have a 64-bit interface
    identifier (and a 64-bit subnet prefix as a result).

Notes:
- I've replaced "should" with "must" in the first sentence as
  discussed before, as I thought this is critical for some group and
  is still acceptable for other group with the additional conditions
  ("except" and "unless").
- Brian might want to be more explicit about the relationship between
  this and ipv6-over-foo specs, but I didn't do that for now.  If we
  can agree on the sense of the text it will be a relatively
  straightforward update.
- we may also want to emphasize that an implementation must not
  blindly hardcode 64 either as the length of interface identifiers or
  as on-link prefix length.  again, as long as we can agree on the
  general sense it will be a trivial update.

--
JINMEI, Tatuya