Erik,
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.
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.
jak
----- Original Message -----
From: "Erik Nordmark" <[EMAIL PROTECTED]>
To: "Basavaraj Patil" <[EMAIL PROTECTED]>
Cc: <ipv6@ietf.org>; "ext Pars MUTAF" <[EMAIL PROTECTED]>
Sent: Wednesday, August 30, 2006 5:25 PM
Subject: Re: Proposal to change aspects of Neighbor Discovery
Basavaraj Patil wrote:
Ignoring cellular hosts for a moment, how are periodic RAs useful for any
host? RAs can be used as a means for detecting network attachment status
or
to detect movement (prefix change). In the case of a stationary host (as
an
example), periodic RAs really are of no benefit to the host (IMO).
A design principle for many Internet protocols is known as "soft state".
I wonder if that might have something to do with the periodic RAs ;-)
If the hosts would keep the information received until it being explicitly
invalidated we would probably end up with a more complex and/or more
fragile approach to handle the stale state. Hence the soft state approach.
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
