Folks, Just to make sure this issue is addressed, I think we can allow routers to either respond with a unicast or multicast RA in the case where an RS without SLLAO is received. It seems like there are different cases where multicast would make more sense than unicast (or at least implementers chose to do so) and vice versa. So, unless someone sees a need to mandate a certain response, I think we should allow both behaviours. If there are no objections I'll add that to the draft.
Obviously in the case of unicast RA, address resolution will take place first, resulting in the creation of an NCE. If multicast RA, then there will be no need for address resolution or creating NCE. Hesham > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of > Christian Vogt > Sent: Saturday, February 19, 2005 11:58 AM > To: [EMAIL PROTECTED]; Soliman, Hesham > Cc: Mark Doll; Roland Bless; ipv6@ietf.org > Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO > > > Hi Hesham, Greg. > > > Soliman, Hesham wrote: > >> Christian, Thanks for the detailed description. I think Nick > >> brought this up some time ago too. My suggestion is that upon > >> reception of an RS with no SLLAO the router checks if an entry > >> already exists, if none exists then it creates one and puts it in > >> STALE. [...] > > 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. > > 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. When a packet is > eventually to be > transmitted for an entry in NOSTATE, that entry just moves > to INCOMPLETE > and a NS is sent. > > The question is whether keeping entries in an additional > state makes a > lot of sense. The approach is more conservate, though, than doing > address resolution rightway (which is how things are done in Linux > according to Greg). > > 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. > > > 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. > > Unicast RA's could be advantageous on link layers with > acknowledgements, > like IEEE 802.11, where they are realiably transmitted. > > - 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) > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > =========================================================== 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
