ok thanks. > -----Original Message----- > From: Greg Daley [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 20, 2005 6:53 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 > > > > > Soliman, Hesham wrote: > > The text now looks like this: > > > > Router Solicitations in which the Source Address is the unspecified > > address MUST NOT update the router's Neighbor Cache; solicitations > > with a proper source address update the Neighbor Cache as > follows. If > > the router already has a Neighbor Cache entry for the > solicitation's > > sender, the solicitation contains a Source Link-Layer > Address option, > > and the received link-layer address differs from that > already in the > > cache, the link-layer address SHOULD be updated in the appropriate > > Neighbor Cache entry, and its reachability state MUST also > be set to > > STALE. If there is no existing Neighbor Cache entry for the > > solicitation's sender, the router creates one, installs the link- > > layer address and sets its reachability state to STALE as specified > > in Section 7.3.3. If there is no existing Neighbor Cache > entry and no > > Source Link-Layer Address option was present in the > solicitation, the > > router may respond with either a unicast or a multicast router > > advertisement. Whether or not a Source Link-Layer Address option > > is provided, if a Neighbor Cache entry for the > solicitation's sender > > exists (or is created) the entry's IsRouter flag MUST be set to > > FALSE. > > > > > > I hope this is clear, if not let me know ASAP because I'm > submitting > > the draft soon before the deadline. > > It's OK. > > If you wish to swap the 'unicast or multicast' in the second last > sentence to 'multicast or unicast', then that will reflect today's > default preference order. > > Greg > > > Hesham > > > > > > > -----Original Message----- > > > From: Greg Daley [mailto:[EMAIL PROTECTED] > > > Sent: Sunday, February 20, 2005 6:13 PM > > > To: Christian Vogt > > > Cc: Soliman, Hesham; ipv6@ietf.org; Mark Doll; Roland Bless > > > Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO > > > > > > > > > Hi Christian and Hesham, > > > > > > I think people are asymptoting to the > > > same point. > > > > > > Are we supposed to be suggesting text though? > > > > > > Christian Vogt wrote: > > > > Hi Hesham. > > > > > > > > > [...] > > > > > > > >> > 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. > > > > > > > > > > > > I agree. > > > > > > > >> [...] > > > >> => 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? > > > > > > > > > > > > No, I don't think that a RA should always be muticasted. > > > It certainly > > > > makes sense in many situations to unicast a RA. I get > > > back to this in > > > > my last comment. > > > > > > > >> > 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. > > > > > > > > > > > > Ok. > > > > > > > >> > > 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. > > > > > > > > > > > > An optimistic node may use a tentative source address in a > > > RS. But if > > > > it does, it must not include the SLLAO. This prevents the > > > router from > > > > overwriting a possibly existing NC entry for the tentative > > > address's > > > > real owner. > > > > > > > > For the same reason, the optimistic node cannot use a > > > SLLAO in a NS sent > > > > from a tentative source address. But since a NS does not > > > make a lot of > > > > sense without a SLLAO, a NS cannot be sent at all > from a tentative > > > > source address. So it must always be the router or a > neighbor who > > > > starts address resolution for an optimistic node while the > > > optimistic > > > > node's is still tentative. > > > > > > This is just as an aside (won't affect the discussion much). > > > It's true that opti-dad isn't allowed to be sent for multicast > > > destinations, where SLLAO must be sent. > > > In unicast NS, where it's not mandatory, it may still > > > possible to send > > > NS with TSLLAO. I'm not sure it's useful though. > > > > > > It's worth noting that responses to unicast NS from a node > > > which doesn't > > > actually have a valid NCE for the solicitor (it is > assumed to do so, > > > from section 7.2.2 of 2461), NS/NA exchange in the > reverse direction > > > is performed before delivery of the NA. > > > > > > >> > 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. > > > > > > > > Yes, Hesham. I didn't mean to say that the way FreeBSD > > > responds to RS's > > > > is my favorite. Actually, I think that we now have two > > > use-cases where > > > > unicast RS's make more sense, WWANs and 802.11, and there > > > are probably > > > > more. Also, I don't think that the additional state, > > > NOSTATE, which > > > > FreeBSD uses for NC entries without L2 addresses makes a > > > lot of sense. > > > > > > > > Overall, I think that the plethora of scenarios can be > > > accommodated best > > > > if we leave a node some choice with respect to when a > > > router creates a > > > > NC entry, and when it sends a RA by unicast or by multicast. > > > > > > > > RFC 2461bis already depends NC updates on whether the > RS's source > > > > address is unspecified or not: If it is unspecified, the > > > NC is not > > > > updated. If it is valid, either an existing NC entry is > > > modified or a > > > > new NC entry is created. I think this is good; maybe we > > > can expand on > > > > these rules. > > > > > > > > (1) The router can unicast a RA if and only if it > > > previously received a > > > > RS with a valid (specified) source address. Rate > limitations may > > > > prohibit the router from sending a unicast RA, though, and > > > instead send > > > > a multicast RA that is anyway scheduled for transmission. > > > RFC 2461bis > > > > already has this functionality. > > > > > > > > (2) If the received RS has a valid source address, but no > > > SLLAO, then > > > > address resolution must be done before the unicast RA is > > > sent. [Hmm, one > > > > may also consider to trigger address resolution, but > still send a > > > > multicast RA. This could be faster than the unicast RA, > > > which would > > > > have to wait for address resolution to complete...] > > > > > > It's not really worth it to do address resolution. That would > > > need to create neighbour cache state, when there's > nothing to send > > > in the neighbour cache entry queue. The outside the [...] > > > it looks ok. > > > > > > I'd probably guess that it's worth putting a caveat here: > > > > > > If there's no SLLAO, some routers may perfer to > schedule a multicast > > > response, in order to avoid neighbour discovery, which > may be costly > > > on some links. > > > > > > > (3) The router sends multicast RA's, first, on a periodic > > > basis and, > > > > second, whenever it receives a RS with an unspecified > > > source address. > > > > According to RFC 2461bis, rate limitations may cause the > > > router to not > > > > immediately send a solicited multicast RA, but to wait for > > > the next > > > > periodic multicast RA. > > > > > > > > > > (4) Rate limitations should be adjustable according to a > > > particular > > > > link-layer technology, capacity, and deployment scenario. > > > This allows > > > > for easy optimizations, like [1]. > > > > > > Nothing is easy ;-) > > > > > > There's work going on with regard to FastRA which may provide > > > the benefits without manual configuration though. So if this > > > is text we're after, I'd prefer no (informative) references to > > > FastRA in a DS. > > > > > > It's worth specifying that deployers consult IPv6 over > foo documents > > > or IPv6 network deployment BCPs to see if any recommendations > > > update specifications in this document. > > > > > > > - Christian > > > > > > > > [1] draft-mkhalil-ipv6-fastra-05.txt > > > > > > > > > > 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. > > =========================================================== > > >
=========================================================== 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 --------------------------------------------------------------------
