Subject: prefix length ban for RFC4861 (Re: [v6ops] A proposal for draft-ietf-6man-rfc4291bis-07)

From: 神明達哉 <[email-masked]>
Date: Mon, 6 Mar 2017 14:15:36 -0800

At Mon, 6 Mar 2017 12:53:19 -0800,
james woodyatt <[email-masked]> 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.

> 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

BSD variants did NOT ignore PIO for on-link determination simply due
to its prefix length value at least at the time of the publication of
RFC4862 (actually since way before that RFC).  For example, this is
FreeBSD's implementation as of Oct 21, 2005, about two years before
RFC4862 was published:
https://github.com/freebsd/freebsd/blob/c2b19f24a4ba01108e047a35a4a060cbfdf28a17/sys/netinet6/nd6_rtr.c
see nd6_prelist_add() starting at line 993, and find that it only
checks the prefix length for SLAAC (lines from 1258).  At this point
the on-link determination has been completed without any check on the
prefix length (lines 1043-1056).

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

This is quite surprising to me.  Do you have any reference to such a
certification test that requires the host to ignore PIO with a non-64
prefix length for the purpose of on-link determination (i.e., for
RFC4861)?

--
JINMEI, Tatuya

---

From: james woodyatt <[email-masked]>
Date: Mon, 6 Mar 2017 14:26:15 -0800

> prefix length (lines 1043-1056).

Indeed, I am unable to find source code history in FreeBSD, NetBSD or Darwin consistent with my memory. Perhaps I am mistaken that it was ever there.

> prefix length for the purpose of on-link determination (i.e., for

My admittedly questionable memory is that it was a USGv6 Test Program for SLAAC [Host] Conformance that checked for this behavior in a host implementation I maintained at the time. As I said, I wouldn’t be surprised if that test has been revised to be more lenient, but I remember having to modify the KAME source code to pass the test.

Nevertheless, the LwIP stack does what I’m talking about, and it’s used in a plethora of constrained resource host operating systems these days.

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

---

From: Timothy Winters <[email-masked]>
Date: Mon, 6 Mar 2017 18:45:08 -0500

The USGv6 and IPv6 Ready Logo have the same test for the PIO option with a
prefix length larger then 64.

It's test 2.2.19 in the IPv6 Core Test Specification
<https://www.ipv6ready.org/docs/Core_Conformance_Latest.pdf>.

It checks that a device is capable of determining the on-link prefix with a
length set to 96.   All IPv6 Ready Logo/USGv6 Basic devices support this
properly.

~Tim

On Mon, Mar 6, 2017 at 5:26 PM, james woodyatt <[email-masked]> wrote:

> Indeed, I am unable to find source code history in FreeBSD, NetBSD or
> Darwin consistent with my memory. Perhaps I am mistaken that it was ever
> there.
>
> My admittedly questionable memory is that it was a USGv6 Test Program for
> SLAAC [Host] Conformance that checked for this behavior in a host
> implementation I maintained at the time. As I said, I wouldn’t be surprised
> if that test has been revised to be more lenient, but I remember having to
> modify the KAME source code to pass the test.
>
> Nevertheless, the LwIP stack does what I’m talking about, and it’s used in
> a plethora of constrained resource host operating systems these days.
>
>
> --james woodyatt <[email-masked]>
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

-- 

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