At Mon, 14 Jul 2008 03:22:44 -0700, Erik Nordmark <[EMAIL PROTECTED]> wrote:
> > BSD variants have in fact supported this behavior for years: I've just > > tested this with a FreeBSD 7.0 box and confirmed it (that is, if that > > host receives an NS from an address that is not covered by "on-link" > > prefixes advertised by RAs, it will create a specific neighbor cache > > entry for that address). I've also quickly checked that Linux > > (seemingly) supports this behavior, too. > > Did you verify that it in fact treats the source of the NS as on-link as > a result? Yes. > I don't have an issue with creating a neighbor cache entry; that has no > security implications because it does impact anything but the neighbor > cache on the interface where the NS was received. The question is about > on-link determination. > Thus will the source of the NS be treated as on-link? Is the behavior of > the implementations different if the source of the NS falls in a prefix > which is already considered on-link on some other interface? Ah, that's an interesting point. To be clear, you're asking about a case like this - the receiving node has two interfaces, I1 and I2 - the node regards prefix P as on-link on interface I1 - the node receives an NS from P::X on interface I2 right? I've not tested that case, but according to the source code, I guess the following will happen: - if the node has already a neighbor cache entry for P::x on interface I1, it does nothing about the source address of that NS - if the node does not have any neighbor cache entry for P::x on any interface, it will create a new neighbor cache entry on interface I2. But, this is a tricky case, so I may be wrong. --- JINMEI, Tatuya Internet Systems Consortium, Inc. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
