> Greg Daley wrote: > > Putting things in STALE doesn't work unless there's a link-layer > > address known ( and there's none in the received RS). > > Greg is correct. When a node has a packet for a neighbor > for which the > NC entry is STALE, it does send the packet (trial and > error), puts the > entry into DELAY, and waits a while for upper-layer reachability > confirmation. If the node receives reachability > confirmation, then the > entry goes back to REACHABLE. Otherwise it goes to PROBE, and the > active part of NUD begins (i.e., the node starts > transmitting NS's for > the neighbor). > > As far as I see it, there is currently no state defined in RFC > 2461[bis], except INCOMPLETE, that is appropriate for a NC > entry without > link-layer address. And INCOMPLETE has the additional semantics that > address resolution is in progress.
=> Agreed. > > I guess this is why FreeBSD introduces a new state, NOSTATE. It does > not do immediate address resolution on an entry in this state. It > doesn't need to, because Rtadvd (on FreeBSD) sends multicast > RA's in all > cases except for ISATAP interfaces. => Right, I was trying to accomodate other ways of implementing Rtadvd that would send unicast RAs in response to the RS in question. For example in the case where no LLA exists in the technology used. In this case it would be wasteful to multicast the RA. This is especially true in a mobile system where you might get several RSs due to MNs appearing on the link. When a packet is > eventually to be > transmitted for an entry in NOSTATE, that entry just moves > to INCOMPLETE > and a NS is sent. => So, from the above, I assume you suggest that we always send a multicast RA in response? I don't know if this is a good way to go given the example I mentioned above. What do you think? > If an RS contains a TSLLAO [1], the router does not have to > immediately > initiate address resolution (i.e., be conservative), but can > still send > a unicast RA. => I think the TSLLAO draft is useful in this case, but we obviously still need to address this case for legacy hosts that don't implement TSLLAO. > > > Soliman, Hesham wrote: > >> [...] If an entry already exists with a > >> LLA then it responds with a (two options): > >> > >> - unicast RA unless a multicast RA was already scheduled. > >> > >> - A multicast RA. > >> > >> I think the second option might be better to allow for > ODAD to work. > > Hesham, why would a multicast RA be required for ODAD? An > optimistic > node can always send a RS from the unspecified source > address to have > the router multicast the RA. => That's true, I didn't consider this case. It's been a long time since I last read ODAD and I don't know if it allows the Onode to send RSs with a tentative src address or if it requires the unspecified address. I guess it should just use the unspecified address while the unicast one is tentative. > > Unicast RA's could be advantageous on link layers with > acknowledgements, > like IEEE 802.11, where they are realiably transmitted. => Sure, there are many other examples of WWANs where unicast RAs make more sense when responding to RSs, that's why I'm not sure if it's always good to follow the FreeBSD way you describe above. It'd be good if we can get some agreement on this before the draft deadline. thx, Hesham > > - Christian > > [1] draft-daley-ipv6-tsllao-01.txt > > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ > > "No great genius has ever existed without some touch of > madness." (Aristotle) > > =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
