G'day Sharkey,
Nick 'Sharkey' Moore wrote:
[G'day Eric, thanks for your input ...]
On 2004-06-01, Erik Nordmark wrote:
[Pekka Savola wrote:]
1) The draft specifies that instead of using a tentative address as the source address for RS, another address or the unspecified address should be used instead. To me, using the unspecified address would seem shortsighted, so I'd like to disallow its use in this context. (This might cause a problem, though, because I don't think the nodes typically have an another address they can use...)
But RFC 2461 explicitly allows sending RS with an unspecified source. Is there a bug in RFC 2461 in this area?
I don't think it's a bug ...
"A router MAY choose to unicast the response directly to
the soliciting host's address (if the solicitation's source address is not the unspecified address), but the
usual case is to multicast the response to the all-nodes
group" [RFC2461 6.2.6]
... it's a feature, asking the router "please be sure to broadcast the response back to me since I don't have an address I'm sure of yet".
The only problem there is the rate-limiting imposed on the multicast responses, but I think we can assume that access routers for fast mobile networks will have MinRtrAdvInterval and related 2461 variables tweaked appropriately and some of the other rules bent ... and I think that's MipSHOp WG's problem, not IPv6 WG's problem ...
(I'm probably going to disallow RSes from Optimistic addresses entirely, so if we don't have any other addresses we'll _have_ to RS from unspecified. The current draft tries to get around this with some tricks, but they tickle weird features of 2461, I think ... see the last sentence of 6.2.6)
...
Actually, I think that tweaking the advertisement intervals for multicast router advertisements (solicited or unsolicited) are problematic. All-nodes multicast packets will consume bandwidth on every LAN segment or cell within the IP subnet equally.
Allowing faster rates of unsolicited RAs as in MIPv6 wastes bandwidth to no purpose when devices aren't moving into a new cell.
Allowing shorter intervals between multicast RAs puts an upper limit on the scalability of IP access networks since more devices are likely to be soliciting/configuring at any time. Such solicitations would therefore reduce available bandwidth uniformly across constrained LAN segments (or cells).
Unicast (and potentially Solicited-Nodes multicast) packets only consume bandwidth on segments where a host would be interested in receiving them. This allows significantly greater scalability when the configuring nodes are spread across many different LAN segments or cells.
The issue which you describe is the setting of the IsRouter flag to false on the reception of a Router Solicitation from a tentative node.
Although this is a new issue caused by the presence of a node which hasn't completed DAD. This flag is normally unset upon reception of (neighbour or router) solicitations sent from the router itself, when a new neighbour cache entry is created.
RFC2461's Section 7.2.3 describes the router's own recovery from this incorrect state, by sending subsequent router or neigbour advertisements.
Considering that the device doing optimistic DAD which erroneously causes the IsRouter flag to be unset has already sent a DAD NS to the address owner (in this case the router), the router will schedule an NA to all-nodes within a second of this NS's reception.
Assuming that the NA is received by the other routers, the NA will set the IsRouter flag in the NC entries on the receving routers. Otherwise, any router or neighbour advertisements will repair the damage, as described in RFC2461's appendix D.
Please also be aware there is no issue for default router selection on hosts, (which is what the IsRouter flag is for) since they never receive the RS in the first place.
This issue is very close to my interest, since I've been looking at fast ways of soliciting configuration when a host may have just arrived on a link.
It seems that treating addresses as tentative is an appropriate precaution in this case.
If Optimistic DAD doesn't allow for unicast responses to router solicitations, the potential for fast advertisement to such hosts is severely diminished.
Greg
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
