IPv6: Invalid nd6 entry created for an RA without an lladdr

Ryan Stone rysto32 at gmail.com
Wed Oct 2 23:12:32 UTC 2019


Ah, that’s my mistake. I originally saw the issue on an older FreeBSD release and missed that the code had changed subtly when I looked up the version in head. r328552 fixed this issue already

Thanks for the sanity check. 

Sent from my iPhone

> On Oct 2, 2019, at 6:51 PM, 神明達哉 <jinmei at wide.ad.jp> wrote:
> 
> At Wed, 2 Oct 2019 17:04:23 -0400,
> Ryan Stone <rysto32 at gmail.com> wrote:
> > 
> > At work, our product is putting through an IPv6 conformance test and
> > it's found an issue in our handling of Routing Advertisements (RAs).
> > If we receive an RA that does not specify an lladdr, then
> > nd6_cache_lladdr() is called with lladdr NULL:
> > 
> > https://svnweb.freebsd.org/base/head/sys/netinet6/nd6.c?revision=347984&view=markup#l1961
> > 
> > In this case, the linkhdr cache is never initialized, but we still put
> > the entry in the STALE state at line 2032.
> 
> If lladdr is NULL shouldn't it reach line 2032?
> 
> if (lladdr != NULL) {	/* (7) */
> nd6_llinfo_setstate(ln, ND6_LLINFO_STALE);
> EVENTHANDLER_INVOKE(lle_event, ln,
>    LLENTRY_RESOLVED);
> }
> 
> In any case, if a host receives an RA without a link-layer address
> option and no neighbor cache entry exists for the RA sender at that
> point, it shouldn't set the state of a newly created cache entry to
> STALE.  While RFC4861 is not so explicit about this particular
> condition, I believe it's pretty clear from Section 6.3.4 of the RFC
> (it may even be questionable just to create an entry in this case, but
> that's probably within the scope of acceptable implementation choices
> as long as the entry is a mere placeholder).  I also believe FreeBSD
> used to not do this (correctly), so if it currently sets it to STALE
> it's quite likely to be some regression.
> 
> --
> JINMEI, Tatuya


More information about the freebsd-net mailing list