Having just gone through this entire thread, some questions. 1) Is there an issue with multicast RAs vs. unicast RAs? I.e., would it help if the RAs were unicast rather than multicast? (Or is there no true unicast in the networks we are talking about). My assumption is that use of IP multicast is not an issue here, since no one has suggested this.
2) What I'm clearing hearing is that it will be common to have devices in "dormant" mode for long periods of time, i.e., hours. The desire is that they not be bothered with RAs during that time (if that is the only only traffic they would be getting, i.e., no other packets are being sent their way). 3) The current ND specs have an upper limit of 30 minutes on the interval between router advertisements. That should be changed, to allow deployments to use a higher value. (that is the assertion/problem.) What makes this all not as easy as it sounds is that periodic RAs are a simple protocol. Send them periodically (and somewhat frequently) so that if one or two get lost, hosts continue operating and nothing breaks. Even if they miss two, they'll receive a third one soon enough. That works pretty well when the periodic interval is short. It doesn't really work at all, when the periodic interval is hours apart. Unless the RAs are delivered with a high degree of reliability. How reliably will the periodic RAs be delivered in the networks at issue here? Are they essentially reliable link layers? "James Kempf" <[EMAIL PROTECTED]> writes: > 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. The current wording in 2461 is a bit narrow, not really making it clear that there may be other times when it is appropriate to send an RS. IMO, a device that has been dormant a long time should be allowed to send an RS. But this is very similar ground to what DNA is covering. Maybe DNA should explicitely cover the case of nodes that switch from dormant to active mode? Note that when 2461 was written, we really didn't have the notion of dormant nodes. So we probably do need to think about how to accomodate 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. 2461 takes the same view. RAs aren't used for reachability we have ND/NUD for that. So I'm not sure why you raise this issue here (in the context of RAs) > 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. See above. > I suspect this was originally done to avoid packet storms when the lifetime > expired. But that could be avoided by specifying that the host needs to pick > a random time prior to the expiration time over some interval. No. The assumption is that long before the default router expires, you receive fresh RAs. What is being proposed here is to break that assumption, namely (effectively), to ignore (by not receiving) RAs while in dormant mode. Right? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
