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

[神明達哉 <[e-mail]>]

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