Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07 - interpretations of the "sum"

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

At Tue, 7 Mar 2017 11:44:04 +0100,
Alexandre Petrescu <[e-mail]> wrote:

> > 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.
>
> Let me say that there are some interpretations of that sum from people
> struggling to make it work.  These interpretations may be surprising to
> the specifier.
>
> The specifier is tempted to think that that "sum" equation is a good way
> to tell everything in just one phrase.
>
> But some people face the problem of making that sum be 128 even though
> the plen is less than 64 and the IID is 64.

> It is the case with the fe80:://10 needing to become a fe80::/64, and it
> is also the case when PIO in RA has a P1::/63.

At least the above text from Section 5.5.3 of RFC4862 is irrelevant to
link-local addresses.  The entire Section 5.5 is about "Creation of
Global Addresses" as the title shows.  In the case of creating global
addresses, I can't think of an interpretation of 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 it allows the creation in the case of advertised plen=63 and IID
len=64.  RFC4862 requires not to do so with the MUST.  BSDs implement
it that way, and so does Linux (according to what I heard here).  I'm
also pretty sure that there's a conformance test tool like that for
"IPv6 ready logo" or USGv6 that confirms the intent of the RFC.  And
so I'm also pretty sure that other major OSes interpret the RFC as it
intends.  So, overall, I don't think it's just what a document editor
intends in his mind, but a widely accepted interpretation.

That said, there's always someone who understands any seemingly clear
text differently from the actual intent, not to mention the recent row
about EH insertion.  So I'm not surprised that there are such people.
If you think this point is so unclear for so many people, I'd suggest
you write a clarification draft or submit an errata.  If you think we
should actually allow the creation in such a case, that's a protocol
change, and I'd suggest you write a draft to update RFC4862.  With
luck, that will become the new standard.

I don't think continuing this topic in this thread brings us anywhere,
so I'll stop here.

--
JINMEI, Tatuya