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

[Alexandre Petrescu <[e-mail]>]

Le 02/03/2017 à 12:37, Wilco Baan Hofman a écrit :
>
>
> On 02/03/17 12:06, Alexandre Petrescu wrote:
>> Le 02/03/2017 à 10:31, Mikael Abrahamsson a écrit :
>>> On Thu, 2 Mar 2017, Alexandre Petrescu wrote:
>>>
>>>> perfectly fine to use that plen==65 to have an entry in the rt
>>>>  table, and use a manually configured address in that plen.
>>>
>>> Linux does the right thing in not autoconfiguring itself
>>> address(es) when plen isn't 64.
>>
>> Whereas it is the right thing if on Ethernet (RFC2464) it is wrong
>> on cellular links for which we have no RFC IPv6-over-foo.  Same
>> with USB and to a certain extent on WiFi.
>>
> It is undefined on non-IEEE802 networks and /64 is the one thing that
> works for SLAAC, operationally.

I agree with you.  And this is a place where everything can be right or
wrong: there is no consistency.  Interop problems loom there.

The fact that we have IPv6 running ok over 4G ptp links, and over USBnet 
is a very encouraging sign that makes many happy: look, IPv6 even there! 
  But it does not mean it does not have problems.

>>> However, what does it do when it receives an PIO with plen of 65
>>> and M=1 and then it gets an IA_NA and configures that on the
>>> interface?
>>
>> I dont know.  But I guess it still calls that 65 plen "illegal".
>
> Which would be correct in the IEEE802 case, undefined in other cases,

Yes.  For more precision - correct _only_ for the 802.3 case (IPv6 over 
Ethernet).  Because we dont have an IPv6-over-WiFi either (802.11).

> still not incorrect behaviour from Linux in this case.

I think someone can call it correct or incorrect equally well.  Because
there is no consistent spec or set of specs.  I call it incorrect.

>>> Doesn't it install the /65 in the routing table?
>>
>> Dont know, but there is a need to check.
>>
>> How about the /63 case?  Do you think it is normal that linux
>> kernel does not configure an IP address on Ethernet when receiving
>> a plen==63?
>>
> I would actually consider that normal, because the standard basically
> mandates /64 and configuring on /63 is undefined at this time.

I would like to doubt your saying 'basically'.

Yes, the IP-over-Eth RFC2464 mandates "An IPv6 address prefix used for
stateless autoconfiguration [ACONF] of an Ethernet interface must have a
length of 64 bits".

It does not say which prefix of [ACONF/RFC2462] must be /64?  Is it a
global prefix in RA?  Or is it the link-local prefix?  Both these
prefixes are relevant for the above phrase, both are mentioned in ACONF,
yet only one is present in RA (the one linux complains about when at
65).  Is the mandate cited above applying to the prefix in RA?  Or to
the link-local prefix?  If the mandate applies to the prefix in RA then
linux is right to complain, on Ethernet.  If the mandate applies only to
the LL prefix, then linux is wrong to complain about 65 in RA.  If the
mandate applies to both then RFC4291 is wrong when it says fe80::/10.

RFC2464 does not say "the prefix in an RA on Ethernet MUST be 64".

It does not forbid that that 64bit prefix be formed by self-appending a
0 to a /63 from the RA, or other mechanism.

Besides, RFC4862 (successor to 2462) says "If the sum of the prefix
length and interface identifier length does not equal 128 bits, the
Prefix Information option MUST be ignored." And linux does _not_ ignore
a /63 in the RA: it adds a rt entry for that /63 prefix.  That's not
normal either.

You see what I mean?

> As implementer I would also reject such prefixes, because the code
> for generating the EUI-64 and the privacy extension address all
> (correctly) assume 64-bits of space, not 63, not 65.

Makes sense.

But linux does not simply reject a /63.

A linux kernel receiving a '/63' in RA will add a rt entry even though 
it does not configure an address.  So that's not really 'rejection' of 
the prefix (unless of course you define 'reject' to mean 'silently add a 
route and then drop the packet'.)

Do you agree with that?

Alex

[...]