Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux

[Alexandre Petrescu <[e-mail]>]

Le 03/03/2017 à 23:02, 神明達哉 a écrit :
> At Fri, 3 Mar 2017 22:09:47 +0100, Alexandre Petrescu
> <[e-mail]> wrote:
>
>>> Both, and I believe at least most implementers have had no
>>> difficulty in interpreting the spec that way.
>>
>> If it is both, then it requires that the prefix used for address
>> autoconfiguration of LL addresses to be 64bit length.
>>
>> But the LL prefix is fe80::/10.
>>
>> "fe80::/10" means it is a prefix.  It does not mean it is "a mask
>> for implementation in BSD and other OSs C macros to recognise the
>> LL address".
>>
>> So, what goes between /10 and /64?  Why?
>
> For (auto)configuring a link-local address?  If so, it's all-0 bits,
>  as defined in Section 2.5.6 of RFC4291:
>
> |   10     | |  bits    |         54 bits         |          64 bits
> | +----------+-------------------------+----------------------------+
>  |1111111010|           0             |       interface ID         |
>  +----------+-------------------------+----------------------------+

Is that figure picturing a fe80::/10 or a fe80::/64?

Is the prefix extended from fe80::/10 to fe80::/64 with 0s?  Or is the
IID len extended from 64 to to become an IID len==108?

If we stopped saying fe80::/10 then it would be clearer.

But one seems to be forced to continue talking about fe80::/10.

Otherwise we would never write text reading "fe80::/10".

>>> - uses the 64-bit IID (as specified in RFC2464) - uses the
>>> fe80::/64 prefix (as defined in RFC4291 Section 2.5.6)
>>
>> And ignores the same document's fe80::/10.  And some implementer
>> does not appreciate that.
>
> I'm not sure what you mean by this here, but out of curiosity, who is
> that implementer and what does it actually do by not appreciating
> that?

Let us say that I talked to many IPv6 stack implementers and I continue
to.  So to answer this question there is not one person in particular
that I could name, but rather the name of a few persons, and a sort of
average I make from my discussions.

Moreover, whenever I invoke such 3rd person, it is the very optimistic
view.  I avoid saying all the bad things that I heard, and I keep the
good things.

> Auto-configuring a link-local address that does not match fe80::/64?

I mean this: is one implementer mandated to bzero() the bits from /10 to
/64?  Or not?  Nobody is telling her so.

If one writes code that generate an LL address by using a /64 mask, and
then tries to make sure by recognising it by using a /10 macro, there is
obviously place for false negatives or false positives.

If the 4291 spec wrote everywhere that the prefix is "fe80::/64"  (and
never write "fe80::/10"), then the implementer would be helped a lot.
She would generate and reognise by always using a 64bit mask.

But that would be wrong to put in an IPv6 Addressing Archi, because 64
is too much of a limit, anyways.

Additionally, when we talk  about the first 3 bits 000, we dont write
"::/3" because "::/3" is a prefix and there is a risk of confusion.

You may remember the discussion about how to denote a default route.

>>> - combine these to configure a link-local address fe80::<64-bit
>>> IID> as specified in Section 5.3 of RFC4862
>>
>> And who tells the implementer what to put between /10 and /64?
>
>> Should that be 0s?  1s?  An arbitrary random mix of 0s and 1s?
>
> 0s, as described in RFC4291 Section 2.5.6.

Are these 0s part of the plen or part of the IID?

>>> To me there's nothing confusing or unclear here, and I suspect
>>> the Linux implementation essentially does the same thing.
>>
>> I think you dont want to see the potential confusion because you
>> do not ask yourself what to put between /10 and /64.  I think you
>> silently assume that should be 0s.
>
> If "what to put between /10 and /64" is for (auto)configuring
> link-local addresses, yes, I assume it's 0s.  But not "silently" -
> it's based on Section 2.5.6 of RFC4291.

That section 2.5.6 does not say whether the 0s are part of the plen or
part of the IID.

It is your reading, with an inclined view to make everything work, that
makes it read so.

But read it with an inquiring view: is the 0 part of the IID or of the
plen?  The section does not answer.

> BTW, I do not necessarily disagree that there may be "some confusion"
> if one sees this:
>
> Link-Local unicast   1111111010           FE80::/10       2.5.6
> (Section 2.4 of RFC4291)
>
> and this:
>
> |   10     | |  bits    |         54 bits         |          64 bits
> | +----------+-------------------------+----------------------------+
>  |1111111010|           0             |       interface ID         |
>  +----------+-------------------------+----------------------------+
>  (Section 2.5.6 of RFC4291)
>
> like, wondering "what if the intermediate 54 bits are non-0?  should
>  it be called a link-local address?".

I agree with the doubt.

> But, at least in terms of auto-generating link-local addresses, the
> specs are clear enough to me that these bits should be set to 0.
> That's why I always try to clarify the context is to auto-generate a
>  link-local address in this conversation.

Yes, it's clear it should be 0.  But it's not clear whether the 0s are
part of the plen or part of the IID.

> If you want to further clear any possible confusion between the
> intermediate 54 bits, I wouldn't discourage you to write a "mystery
> of the intermediate 54 bits for fe80::/10" draft:-)

I agree :-)  When I hear this I think I need to stop talking because I
cant write so many drafts as I write emails :-)

But some of these things are indeed doubts there for a long time.
>
>>>> It does not forbid that that 64bit prefix be formed by
>>>> self-appending a 0 to a /63 from the RA, or other mechanism.
>>>
>>> It's not the job of RFC2464.  RFC4862 imposes the restriction
>>> through its Section 5.5.3 bullet d):
>>
>> Well then, it should.
>>
>> BEcause currently RFC2464 says "An IPv6 address prefix used for
>> stateless autoconfiguration [ACONF] of an Ethernet interface must
>> have a length of 64 bits".
>>
>> If we go by your recommendation above, then it means RFC2464 must
>> not say that.
>
> I guess we're just not on the same page...trying to rephrase my
> point, it doesn't matter that RFC2464 "does not forbid that that
> 64bit prefix be formed by self-appending a 0 to a /63 from the RA",
> since RFC4862 forbids it anyway (by the "sum must be 128"
> requirement).

I dont understand you.

I want to say this: RFC2464 does require the prefix len to be 64.


>>> I guess that "rt entry for that /63 prefix" is to treat the /63
>>> prefix as on-link (assuming the corresponding PIO has L bit on).
>>
>> YEs.
>>
>>> If so, that's the correct behavior per RFC4861 (not 4862).
>>
>> So RFC4862 should not require the Host to ignore a received non 128
>> plen+IID, because RFC4861 accepts it.
>
> Here I actually see conflating.  RFC4862 only says the host MUST
> ignore such prefix *for SLAAC*.

That emphasis is yours, it's not in the document.  The document says it
must ignore it.

> It doesn't say, for example, it should ignore the entire RA or even
> for that particular PIO for other purposes than SLAAC.

It says it must ignore the PIO.  IT does not say for what to ignore it.

> But I admit this point may be subtle and can easily be misunderstood.
> RFC4862 tried to clarify that subtlety a bit in the following
> paragraph of that section (that was actually written by me):
>
> It is the responsibility of the system administrator to ensure that
> the lengths of prefixes contained in Router Advertisements are
> consistent with the length of interface identifiers for that link
> type.  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.  Thus, it should be safe
> to validate the advertised prefix length here, in order to detect and
> avoid a configuration error specifying an invalid prefix length in
> the context of address autoconfiguration.

It reads reasonable.  But the other paragraph requiring to ignore the 
PIO which is non 64 is still there.  These two paragraphs are contradictory.

One requires consistency, the other requires 64.

We are going to write the same for IPv6 Addressing Architecture?  A 
paragraph requiring 64 and another requiring variable length?

> but this conversation seems to suggest it's still not clear enough.

BEcause when writing RFCs it is not by adding paragraphs that things get 
clearer.  Clarification paragraphs may be good, but often removing some 
paragraphs can also improve clarity.

There are readers out there, most often the programmers.  They dont care 
about the earlier discussion involving pride and other feelings.  They 
want consistency - things that can be easily implemented.

>> As such, either rfc4862 or rfc4861 should be modified to make it
>> work together.
>
> 4861 and 4862 already work together.  But, we could make it even
> clearer that prefix length validation for on-link determination
> (actually there's no restriction for this) and prefix length
> validation for SLAAC are independent, if and when we want to update
> these RFCs.
>
>> Maybe rfc4862 should not require the Host to refuse a received
>> plen+IID not making for 128.
>
> No, it should still require that, as there's currently no defect in
> the spec even if it may still not be crystal clear for some. However,
> you have the right to propose loosening the requirement, so if you
> think that change is necessary, please feel free to write a draft.

Ah this invitation.  The title reads great!  "Mistery of...".  Thanks, 
but no, not at this time :-)

>>> It's also correct to ignore that prefix for SLAAC per RFC4862
>>> (not 4861).
>>
>> If some RFC requires the Host to ignore the PIO and some other RFC
>>  requires the Host to interpret it, and both RFCs are mandatory to
>>  implement, under the same conditions, isn't there a conflict?
>
> No, there's no conflict, once one understands the two types
> validations are independent:
>
> - RFC4861 does not impose any restriction on the prefix length in PIO
> for on-link determination purpose (and therefore the host is expected
> to accept any length of prefix for on-link determination) - RFC4862
> requires the host to ignore the PIO of some particular length for the
> purpose of SLAAC (and therefore the host is expected to not use a
> prefix of "invalid length" to configure an address)
>
> Both can coexist.  BSDs literally implement it.  From your previous
> message, I guess so does Linux.  I also suspect so do other major OS
>  implementations such as Windows or Solaris, as this separation has
> been in fact one of common test cases in IPv6 protocol conformance
> test suites.

Ok.

Alex

>
> -- JINMEI, Tatuya
>