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

[Christian Vogt]

Hi Hesham,
hope this is not too late.
Not sure but the text may suggest to create NC state even if the RS did 
not contain a SLLAO.  In this case, it's actually not necessary to 
create NC state, especially if the router chooses to respond with a 
multicast RA.  If you agree, you could change the text from this...

> [...]                 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, [...]
...to this...
> [...]                 If there is no existing Neighbor Cache entry
> for the solicitation's sender and a Source Link-Layer Address option
> was present in the solicitation, the router creates a new Neighbor
> Cache entry, 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 does either one of the
> following:
>
> - It performs address resolution on the solicitation's sender, creates
> a new Neighbor Cache entry, installs the link-layer address, sets its
> reachability state to STALE as specified in Section 7.3.3, and
> responds with a unicast Router Advertisement directed to the
> solicitation's sender.
>
> - It responds with a multicast Router Advertisement.
>
> Whether or not a Source Link-Layer Address option is provided in the
> solicitation, [...]
The rest is perfect, IMO.
Oh, just a nit:  s/link- layer/link-layer/.
- Christian
--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/
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.

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


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