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

[james woodyatt <[e-mail]>]

On Mar 6, 2017, at 14:15, 神明達哉 <[e-mail]> wrote:
> 
> 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).

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.

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

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 <[e-mail] <mailto:[e-mail]>>