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

Hi James and Philip,

I wanted to quickly comment on this line.

On Mon, Mar 6, 2017 at 3:53 PM, james woodyatt <jhw@google.com> wrote:

> On Mar 6, 2017, at 10:47, Philip Homburg <pch-v6ops-6@u-1.phicoh.com>
> wrote:
>
>
> 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.
>
> Yes,  IPv6 Ready Logo and USGv6 Test Programs confirm that stacks process
PIO with a length larger then 64 bits for on-link determination.   This
works with most IPv6 stacks today.

>
> 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 <jhw@google.com>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR