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

[Alexandre Petrescu <[e-mail]>]

Le 04/03/2017 à 10:15, Philip Homburg a écrit :
>> Im saying that my stack tries to comply with RFC 4862 which
>> requires that it ignore PIO options where the Prefix Length is not
>> 64 on link types that define the length of the IID as 64 bits in
>> the relevant IPv6-over-link document. My stack does that in the
>> hopes of eventually passing the IPv6 Ready certification test,
>> which Ive been through before, and, yes, it tests for that MUST In
>> RFC 4862. It tests both the requirements for processing the A flag
>> as well as the requirements for processing the L flag.
>>
>> If you send me a Prefix Length other than 64 bits, then Im gonna
>> ignore it. Just as RFC 4862 commands.
>
> I find this confusing, you are ignoring an onlink prefix because of
> auto configuration? That is IPv4 thinking. In IPv6 they are supposed
> to be decoupled.
>
> But in any case, ignoring an onlink prefix should be safe from an
> interoperability point of view.

I agree with the IPv6 facility to have many on-link prefixes.  IPv4 does
it too these days anyways.

But I do not agree with mandating there to be multiple on-link prefixes.

The fe80::/64 is there by default.

So if I add a 2001:db8:abba:abb*::/60 on some computer it will get two
different onlink prefixes with different prefix lengths.

Two is too much, because it means ND  messages for that /64.  That is
noise that can create interference.

Ideally, freedom from /64 means that I would only have that /60 prefix
on the link if that's what I mnaually added.

To realize that freedom (avoid ND noise for /64) I have to add the /60
_and_ delete the /64.

Ideally just add the /60 should be sufficient.

Alex

> Without the prefix you have to send the traffic to the default
> router, which will send redirects. So slightly less efficient but no
> big deal.
>
> What I really don't understand is that if you implement RFC 4861 (ND)
> and you get a PIO option with the A bit clear, that you would drop
> that prefix because the address configuration that you are not doing
> anyhow would not allow it.
>
> To me that seems like a completely perverse reading of RFC 4861.
> Maybe the host requirements RFC should clarify this issue.
>
> Note that this prefix could be used for DHCPv6. And even if you
> stack cannnot use those addresses for address configuration, they may
> still be onlink.
>
> Also note that RFC 4861 clearly distinguishes between onlink and
> autoconfiguration with the text: "It also assists with address
> autoconfiguration as specified in [ADDRCONF], for which there may be
>  more restrictions on the prefix length." It would be really weird
> that assume that RFC 4862 can silently update 4861 in this regard.
>
> Ah, RFC 4862 (Section 5.5.3) is even specific about this problem:
> "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.
>
> So this consistency check should only be done if the A bit is set.
> And even then, it is not clear of RFC 4862 can change behavior
> specified by RFC 4861 without explictly saying so.
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>