"Wes Beebee (wbeebee)" <[email protected]> writes: > I guess RFC 4861 doesn't go so far as to require that:
> "Because unicast Neighbor Solicitations are not required to include a > Source Link-Layer Address, it is possible that a node sending a > solicited Neighbor Advertisement does not have a corresponding link- > layer address for its neighbor in its Neighbor Cache. In such > situations, a node will first have to use Neighbor Discovery to > determine the link-layer address of its neighbor (i.e., send out a > multicast Neighbor Solicitation)." > Which gives us three ways to solve this problem: None of which are acceptable. :-) > 1) Amend "A host only performs address resolution for IPv6 addresses > that are on-link." to say "A host only performs address resolution > for IPv6 addresses that are on-link or possibly in response to an > NUD message without a link-layer address option with an L2 source > address that is unavailable to the ND stack." This would be too complicated. > 2) Require hosts to extract the L2 header of the NS when sending the > NA (which goes beyond RFC 4861) when the link-layer address option > is not supplied in unicast NS messages. No. we designed ND to have LL option precisely to avoid needing to do this, as it is problematic in some implementations and is a layer violation. > 3) Drop incoming NS's for addresses which are not already deemed to > be on-link. No, for reasons outlined in an earlier note. Lets try a different approach: 4) ND (like ARP) is scoped to a single link/interface. All responsese to ND queries MUST be sent back out onto the same link. taking Jinmei's original scenario: > - There is a host X. X has a global address P::X, but has no > information about on-link prefixes (for X, only link-local addresses > can be considered on-link). Note that even P::/plen is not > considered an on-link prefix for X. > - There is another host Y with a global address P::Y. Y somehow knows > P::X is a neighbor of it. Y also somehow knows the link-layer > address of P::X. > - Y sends an NS to P::X without link-layer source address option, with > the source address being P::Y. > - X tries to respond to the NS with NA. The NA must be sent to P::Y. > But since X doesn't know the link-layer address of P::Y, it first > needs to perform address resolution. On the other hand, according > to the revised "on-link" definition, P::Y is not considered > "on-link" (for X). By definition, all NAs must go out onto the same interface on which they were received. By this rule, one would know in trying to respond that one did not have the LL address for P::Y, one would know which interface the destination is on, and one could send out an NS on that interface. Things would work. Going through a node-wide IP routing table (with multiple interfaces, etc.) would (in this case) lead to the wrong result. I could imagine other scenarios where going through the routing table would lead to the wrong result. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
