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.
> 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...]
(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].
- Christian
[1] draft-mkhalil-ipv6-fastra-05.txt
-- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/
Soliman, Hesham wrote:
>
> > 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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
