Subject: RE: RFC 2461[bis]: RS with srcaddr but w/o SLLAO

From: "Soliman, Hesham" <[email-masked]>
Date: Sat, 19 Feb 2005 14:58:28 -0500

> 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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Christian Vogt <[email-masked]>
Date: Sun, 20 Feb 2005 08:58:32 +0100

Hi Hesham.

 > [...]

I agree.

> [...]

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.

> still need to address this case for legacy hosts that don't implement

Ok.

> 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.

 > It'd be good if we can get some agreement on this before the

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

---

From: Greg Daley <[email-masked]>
Date: Mon, 21 Feb 2005 10:12:44 +1100

Hi Christian and Hesham,

I think people are asymptoting to the
same point.

Are we supposed to be suggesting text though?

Christian Vogt wrote:
>>  > doesn't need to, because Rtadvd (on FreeBSD) sends multicast  > 
>> RA's in all
>> => 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
>>  > 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 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.
>>
>> 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.
> 
> 

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.
>>

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.

> 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.

> [1] draft-mkhalil-ipv6-fastra-05.txt

Greg