[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
oDAD: allowing RS from tentative addresses (Re: optimistic dadcomments)
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
The issue which you describe is the setting of the IsRouter flag
to false on the reception of a Router Solicitation from a tentative
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
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.
IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6