On Tue, 2006-09-05 at 09:35 -0400, Thomas Narten wrote: > > > RAs aren't used for reachability we have > > > ND/NUD for that. > > Once again, NUD (as I understand it, and the way it is defined in > 2461) is not based on RS/RA exchanges. It is based on NS/NA > exchanges. Thus, I do not at all understand the rest of your note. > > Further, based on what you wrote below, I think you should start by > defining the problem statement - what it is you are trying to > solve. Your combination of messages sent via a paging channel and one > (and apparently only one message) sent via the normal data channel > doesn't implement NUD as I understand it.
> Finally, why do you care about NUD if the node is in dormant mode? If > the node is dormant, having its NUD state kept up-to-date seems like > an odd thing to require (especially since NUD state is short-lived, on > the order of minutes). OK (but see below please) > > NUD (RS-RA) becomes useless when the host is in dormant mode and > > reachable via a paging channel. > > > To initiate NUD, the host needs to wake up and send RS. The router's > > answer (unicast RA) will be received via a traffic channel. It won't be > > received via a paging channel, because the host is NOT in dormant mode. > > That is, the paging channel is not tested with NUD. > > > After the NUD procedure, the host will re-enter dormant mode. > > But, the host doesn't know if it is reachable. Because the > > paging channel wasn't tested. > > > > With unsolicited RAs: > > > The unsolicited RAs can be received by dormant mode hosts. That is, > > they can check the paging channels. Here is the procedure: > > > 1. Router sends an unsolicited periodic RA to a host. > > 2. The host is in dormant mode, therefore the RA triggers > > link-layer paging. > > 3. Host receives a link-layer paging message via a paging channel, > > and wakes up. > > 4. Host acquires a traffic channel. > > 5. Host receives the unsolicited RA via the traffic channel. > > > If the host successfully received an unsolicited RA, this means > > that the traffic channel and also the paging channel worked > > smoothly. > > Not as I understand it. It only means that the data channel was shown > to work in one direction -- NUD explicitely verifies that a channel is > working in _both_ directions. Are you assuming that if one can send > data via the paging channel, that is good enough to conclude that the > data channel also works? Is that a valid assumption? I wasn't assuming this. NUD checks the traffic channel in both directions. That's OK. But after the NUD procedure, the host enters dormant mode and becomes reachable via another channel: the paging channel that wasn't tested. Consequently, the following scenario is possible: 1. Host performs NUD. Result is OK. 2. Host enters dormant mode. 3. There is an incoming call, but the paging channel is down. 4. The host can't be reached. NUD reported good reachability, but the host missed the call. Because NUD didn't test the paging channel (it can't). IMHO, the following may make sense: 1/ Using NUD for checking the traffic channel (in both directions). 2/ Using unsolicited periodic RAs, for checking the paging channel. In conclusion, all I'm saying is that unsolicited periodic RAs are very useful. They shouldn't be removed. On the contrary, I believe that the RA interval shouldn't be more than 5 minutes when there is paging channel. (what's that? incoming flames! :-) If you have missed 2 or 3 unsolicited RAs, you can suspect a problem. You can move to another network, for example. This has a cost, I agree. But reliability has a cost in general. Security also has a cost. Note also that, we can always reduce the subnet size to reduce the signaling cost of periodic RAs. I think we will still have a very good battery optimization (less optimal, but more reliable and secure). Battery technology is evolving at a high speed. I'm proposing that we profit from that for having some reliability. This makes sense? pars > Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
