JINMEI Tatuya / ???? wrote:
On Fri, 31 Oct 2003 12:52:14 +1100, Greg Daley <[EMAIL PROTECTED]> said:
The difficulty comes when an RS comes from a global source address which is not directly connected to a router.
Based on RS processing rules, the host which sent the RS is within a hop of the router, but has asked for an RA from an address which doesn't exist locally.
It is not very clear what "an address which doesn't exist locally" means. I guess you probably mean, e.g., an address that belongs to a prefix that the receiving router does not configure as on-link.
RFC2461 clearly (IMO) says that such an address must be regarded as on-link:
on-link - an address that is assigned to an interface on a specified link. A node considers an address to be on- link if: (snip) - any Neighbor Discovery message is received from the address. (Section 2.1 of RFC2461)
Note that in this case a neighbor discovery message (router solicitation) is received from the address.
Indeed.
This is quite possibly incorrect behaviour though, since wireless nodes may have mistaken ideas as to where they are connected, and send Router Solicitations (quite unaware) from global addresses which are _not_ on-link.
It is very likely in the case that a node has changed its link-layer connection, but it has not received an RA, that it has invalid configuration on the link.
In this case, should the router put entries into its ND cache for addresses from global prefixes associated with another subnet?
I'm not conviced (yet) that it should (even if it's allowed to by RFC-2461).
Does the router reply to a message which has a source address not believed to be on this link?
So, again, it is not clear what "a source address not believed to be on
this link" means, but if the question is, e.g.,
Does the router reply to a message which has a source address that belongs to a prefix that the receiving router does not configure as on-link?
then the answer is yes.
I can understand if the router responds with a multicast (since even :: addresses are capable of receiving a multicast response). I'm more concerned about the creation of incorrect state for the router.
For example, invalid NC state could be used to create local routing between addresses on seemingly unconnected subnets, without going through the router controlling the foreign prefix.
I've not got any dire predictions as to why this would be a bad thing, but it seems unnecessary (since we have LL) and incorrect (since NC's will have entries which don't reflect the routing architecture).
Does it only reply with a multicast destination?
No, a unicasted response is also valid.
Which means that we accept any prefix from any host as part of a valid address, to put in our neighbor caches.
So all a node has to do to get bidirectional communication with hosts on a link is to (if it knows their address, as with the router): send them an NS or RS with SLLAO with an arbitrary source address (or even send RS without SLLAO, and respond to the router's NS).
This will place an NC on the peer.
No routing involved, just neighbor discovery.
I'm just wondering if this was the intended functionality?
What do current implementations do in this case?
This doesn't help your question here, but FWIW, the KAME/BSD implementation only supports for multicast router advertisement. So, the implementation always replies with a multicast destination, whether the source of the solicitation is link-local or global.
That's helpful to know though.
radvd primarily works on multicast advertisement, but I'll have to check the source to see how it works for unicast too.
Thanks for your help.
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
