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

[Philip Homburg <[e-mail]>]

>    I found it confusing at first too, but the RFC 2119 keyword
>    language in RFC 4862 is pretty unambiguous, and it makes sense
>    too if you think about PIO updates that only change the lifetimes
>    and the value of the A flag. The requirement to drop all PIO
>    with invalid prefix length for the link type, regardless of the
>    A flag, ensures with a simple-to-implement rule that you never
>    take a misconfigured prefix as on-link if you cannot ever
>    auto-configure an address in the prefix when the update to A=1
>    arrives.
> 
>    This may not be the behavior youd prefer that RFC 4862 require,
>    but the requirement is clearly there and certification tests
>    are within their ambit to check for it. Moreover, this proposed
>    successor to RFC 4291 doesnt even have an informative reference
>    to RFC 4862 in it, much less an explicitly declared update. And
>    I dont believe it should.

If your stack only does this when the A bit is set, then I don't care
that much. I'm perfectly happy if SLAAC remains at 64 bits and anything
else requires DHCP or manual config.

Technically, if you only drop the PIO if the A bit is set, then it is 
still future proof, because any future change to the prefix length can
just require two options, one with the A bit set and one with the L 
bit set.

Certainly if the A bit is clear, to reach the MUST in step d), you must
have ignored step a). In addition, step d) spells out that prefixes that
don't match the IID have a meaning in onlink processing, making it
completely clear that 'in order to detect and avoid a configuration error
specifying an invalid prefix length in the context of address
autoconfiguration' means just that.

If RFC 4861 meant to ignore the PIO option for the purpose of onlink
then RFC 4861 would have said so directly.

In any case, I think the 'MUST drop' interpretation of RFC 4862 is
completely wrong. There is no way that a MUST in RFC 4862 can change the
behavior of RFC 4861 without RFC 4862 explicitly updating RFC 4861. If
that is intended, we should at least add an errata to RFC 4862.

I'm not sure why you would think RFC 4291 should say something about the
PIO option and the L bit processing?

So it is not so much what I prefer. It is already spelled out. Note that your
argument 'ensures with a simple-to-implement rule that you never take a
misconfigured prefix as on-link' is not reflected in RFC 4862. RFC 4862
talks about misconfiguration with respect to autoconfiguration and
is explict that this length check does not hold for onlink processing.
Again 'in order to detect and avoid a configuration error specifying
an invalid prefix length in the context of address autoconfiguration'

Finally, the 'MUST drop' interpetation is not consistent with the
behavior of FreeBSD, MacOS, and Linux. So I now start to wonder where
the 'MUST drop' interpretation comes from and if anyone ever bothered
to check out the behavior of existing stacks.