JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
<jinmei_tat...@isc.org> writes:
> Whether it's tricky or not (admittedly it's a subjective term), the
> statement doesn't really hold. Consider the following example:
> - 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).
OK. Now I remember your concern from an earlier thread. :-)
One thing that is missing from the entire ND discussion (and I would
say is just assumed and has been for a long time) is that ND is scoped
to a single link (just like ARP is). All NS responses are assumed to
be sent out the same interface on which the corresponding query was
received. There is no need to use normal IP routing when responding to
a NS query. Indeed, as you highlight above, doing so may result in
some failure scenarios.
I think the correct fix is to just state the above, in the sense that
that is what the necessary behavior needs to be. How that is
implemented (so long as it does the above) is not something the spec
needs to say anything about.
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
