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

[Alexandre Petrescu <[e-mail]>]

Le 07/03/2017 à 19:36, 神明達哉 a écrit :
> 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.

The Host won't drop it because there's that other RFC needing it, right?
As such this RFC should say "the received PIO value MUST not be used as
such to generate an address; but it could be used if padded with 0s, or
trimmed of other bits".

> 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.

And there are people looking deep into RFC details to understand what
could be implemented correctly, in order to solve this
"single-/64-per-Host" delivered by 3GPP.

> 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.

This is the topic of allowing or not allowing 64 limit.

I think continuing to defend that 64 limit makes no sense after all
these problems.

The problem is in all these RFCs, and there is no need of a new one.  We 
wrote already too many on this topic of 64.

Alex

>
> -- JINMEI, Tatuya
>