JINMEI Tatuya / 神明達哉 wrote:
First off, I believe we should be more careful before "deprecating" this rule:- any Neighbor Discovery message is received from the address. As an implementor, I've been aware of the non-trivial flavor of this on-link condition, and have noticed it creates tricky corner cases. But I've always thought it's intentional, rather than a "bug". Although I was not 100% sure in which case this rule is expected to be used, I've imagined it might be useful in a router-less network (as we briefly discussed in a different thread) or some NBMA network.
Yes, I think both bullet three and bullet four where there for some (incomplete) thoughts about NBMA. But I can't see a case when they would be needed. The redirect to an on-link target seems to be sufficient.
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?
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?
(BTW, I've seen a "security" concern on this behavior in a different thread. I was not sure about whether it's a mere FUD or it has a really serious new security implication, due to the lack of details, but in any event I'd not buy that argument in this context. Since ND is a link-local protocol, any attack including this one must be performed within the same link as the victim. And once we consider such a hostile environment, we already know the neighbor discovery as a whole is just vulnerable to many serious attacks. If we want to counter this situation, we must deploy SEND; simply deprecating one minor corner case doesn't help).
Unfortunately, RFC 4861 doesn't specific enough about on-link determination to say whether that is a global activity, or whether it is done per interface.
Appendix A focuses on default router selection on multihomed nodes. How do different multihomed implementation handle on-link determination? Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
