James Kempf wrote:
I think the proposal was not to keep the router information until it was
explicitly invalidated but rather that the host could individually
solicit prior to the expiration of the lifetime. The router information
state is still soft state, its just that the renewal is different. 2641
explicitly prohibits solicitation except for 5 specific cases, and
renewing a router table entry is not one of them.
For some types of wireless links, multicast unsolicited router
advertisements are not really that helpful in determining router
reachability, because the host may be able to hear the router, but not
transmit. If the host depends on a multicast unsolicited router
advertisement, it could end up with a lengthy NUD procedure before it
determined that it couldn't really use the router. That's one reason why
an RS-RA exchange would be more useful. Another is the issue of dormant
mode hosts, which is I think what prompted the original posting on this
thread.
But the cost of solicited advertisement in terms of load on the network
is higher than unsolicited.
Assume there are N routers on the link, and M hosts.
With unsolicted multicast advertisements we get N multicast RAs per time
period. If we assume the the link layer emulates multicast with repeated
unicast, that would end up bring M*N unicast RAs per time period.
With solicited RAs, presumbly we'd want the RS to be unicast instead of
sent to all-routers, right? (Otherwise we'd have a ton of multicast RSs
to handle.)
Thus each host would need to unicast at least one RS per time period.
But with N routers providing potentially different information it would
seem each host needing to unicast an RS to each one each time period.
Thus we'd end up with N*M RSs plus N*M RAs in response; twice the number
of packets!
Note that is addition to sending more packets, such an approach can not
robustly deal with a replacement of a router.
When a new router comes up it initially multicasts a few rapid RAs. But
all those could be lost. The fact that the new router (as well as
others) keep on multicasting RAs periodically means that even if the
initial RAs were lost, the hosts would sooner or later receive an RA.
Without this, we can easily get into states where the new router is
introduced, and a day later the old router is turned off, yet there
might be hosts which do not know there is a new router.
Thus you'd need to have the hosts fall back to sending *multicast* RSs
to compensate for the lack of periodic RAs.
To me the dormant host seems like a red herring.
For a dormant node there is a filter somewhere which determines what
packets will make it wake up. I guess this filter could be either in the
NIC/radio on the host, or in the network. If it is in the network, then
a match on the filter would make the network send the "wakeup" signal to
the host.
Given this, we can get the desired behavior of not having the host
wakeup due to periodic RAs if the wakeup filter blocks (doesn't wake up)
from a RA.
This means that when the host wakes up it might find that its default
routers and/or prefixes have timed out. But we need to deal with that in
the solicited RA case as well (presumably we don't want to have the host
wake up every time period to send the RS/RSs.)
And dealing with that case can be done by just invoking the DNA
procedures - send a unicast RS to a known router and wait for an RA in
response.
Thus I don't see an alternative to periodic RAs that is more attractive;
the alternative seems to cause more packets and be less robust.
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
