Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07

[神明達哉 <[e-mail]>]

At Mon, 6 Mar 2017 19:34:43 -0500,
Timothy Winters <[e-mail]> wrote:

> I don't believe this test is too strict based on 4862 Section 6.3.4 "
> Similarly,
>
>    [ADDRCONF <https://tools.ietf.org/html/rfc4861#ref-ADDRCONF>] may
> impose certain restrictions on the prefix length for
>    address configuration purposes.  Therefore, the prefix might be
>    rejected by [ADDRCONF
> <https://tools.ietf.org/html/rfc4861#ref-ADDRCONF>] implementation in
> the host.  However, the
>
>    prefix length is still valid for on-link determination when combined
>    with other flags in the prefix option."
>
> Basically ND still works even if SLAAC thinks the prefix length is
> invalid.   It's really a ND test for on-link deteremination.

I'd also note that the above text didn't exist in RFC2461; it was
newly introduced in RFC4861.  If I remember it correctly the added
text was an attempt of clarifying validation for on-link determination
and validation for SLAAC are independent, as it had often been
misunderstood.  RFC4862 also tried to clarify that point, e.g., in
this text:

      [...]  It should be noted, however, that this does not mean
      the advertised prefix length is meaningless.  In fact, the
      advertised length has non-trivial meaning for on-link
      determination in [RFC4861] where the sum of the prefix length and
      the interface identifier length may not be equal to 128.

But this thread and another similar discussion seem to suggest that
it's still not clear enough for some people.  At least two different
readers interpret this text:

      If the sum of the prefix length and interface identifier length
      does not equal 128 bits, the Prefix Information option MUST be
      ignored.

as the PIO MUST be ignored for all purposes including on-link
determination.  In a sense, it's not necessarily surprising - no
matter how we try to clarify a point there's always a reader that
still interprets it differently.  But if there is really a protocol
conformance test that doesn't interpret the text differently it's
really surprising to me.

The bottom line is, if there is an implementation that ignores a PIO
- with both L and A flag on, and
- with prefix length being something other than 64
- received on a link whose IID is specified to be 64 (like Ethernet)
even for on-link determination, then that implementation violates
RFC4861.  I can also assure that the document editor of RFC4862 didn't
intend such "strictness" - on the contrary, he actually tried to
clarify that's not the intent, but it looks like it's still not super
clear.

--
JINMEI, Tatuya