Subject: Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07

From: Philip Homburg <[email-masked]>
Date: Mon, 06 Mar 2017 19:47:55 +0100

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

---

From: Philip Homburg <[email-masked]>
Date: Mon, 06 Mar 2017 19:52:31 +0100

>else requires DHCP or manual config.

This should have gone to 6man. But may be interesting here as well as
some interpretations of RFC 4862 seems to make it impossible to have
onlink prefixes that are not /64.

---

From: james woodyatt <[email-masked]>
Date: Mon, 6 Mar 2017 12:53:19 -0800

> to check out the behavior of existing stacks.

Looking at the relevant source code for a couple of the latest BSD-variant kernels, I believe you’re right about the current behavior on those platforms. My memory of them must be outdated. I think they used to drop PIO according to a strict interpretation of RFC 4862. I distinctly remember having to implement it that way in order to pass a certification test. I believe these implementations will not any longer pass that test. (One imagines either their owners don’t care, or the test has been revised to be more lenient.)

I am however looking at a commonly used lightweight IP stack that simply ignores all PIO options unless Prefix Length = 128 - IID Length (and it safely assumes all interface identifiers are length 64 because it doesn’t support link types with other IID lengths, and it’s also unsuitable for use in the environments where IETF standards make exceptions for other IID lengths). This stack was developed entirely apart from the Linux and KAME efforts, by people who read the fine RFCs and implemented the simplest lightest-weight thing possible that is still compliant with the requirements language. That’s important for people on platforms where every byte of code and stack space is precious.

p1. I get that RFC 4862 has requirements language that annoys some participants. We are not here revising RFC 4862 however, so that’s not relevant.

p2. The stack I’m using implements SLAAC and-- for completely defensible reasons— follows the letter of RFC 4862 requirements. Its current behavior is compliant with RFC 4291, RFC 4861 and RFC 4862. It’s not exactly uncommon in the field today, and it’s not currently broken by the proposed successor to RFC 4291 with its current language about IID length.

p3. I get that people want to hold up promotion of IPv6 to Full Standard until the successor of RFC 4291 is changed to declare explicitly that the stack I’m using is in error. My opinion is this is a procedural matter, not a technical matter.

I object to the procedural step being proposed, not the technical argument. If we MUST declare the stack I’m using to be in error, then please let’s NOT do it in this draft. Can you not wait until RFC 4861 and RFC 4862 are next revised?

--james woodyatt <[email-masked] <mailto:[email-masked]>>