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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to