Hi Greg, I was definitely assuming that address resolution will take place in the case where the response is sent unicast. I assume that's what you're suggesting, but I'm not sure what state you're suggesting.
Hesham > -----Original Message----- > From: Greg Daley [mailto:[EMAIL PROTECTED] > Sent: Friday, February 18, 2005 9:19 PM > To: Soliman, Hesham > Cc: Christian Vogt; ipv6@ietf.org; Mark Doll; Roland Bless > Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO > > > Hi Hesham, > > 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. If an entry already exists with > > a LLA then it responds with a (two options): > > Putting things in STALE doesn't work unless there's a link-layer > address known ( and there's none in the received RS). > > > - 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. > > > > Thoughts? > > This was discussed recently on DNA list since there's an idea to > use TSLLAOs (Tentative source link-layer address options) in > RSs without SLLAOs when a node is optimistic. > > I believe that Erik indicated multicast was the logical way to go. > I guess that's the way most implementations have gone. > > We already have at least one implementation (RADVD on linux) > which will send a unicast RA without needing an existing neighbour > entry (and works without SLLAO in RS). It first does neighbour > resolution before delivering the unicast RA. > > Where the NS is sent, the recipient has to respond with an NA > before the RA is sent, so there's no real potential for > multiplicative attacks (except for NS retries when a node isn't > present). > > Bandwidth utilization and packet loss probability are higher though. > > Greg > =========================================================== 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 --------------------------------------------------------------------
