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

From: "Soliman, Hesham" <[email-masked]>
Date: Sun, 20 Feb 2005 18:23:12 -0500

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-masked]]
 > Sent: Sunday, February 20, 2005 6:13 PM
 > To: Christian Vogt
 > Cc: Soliman, Hesham; [email-masked]; 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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

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

Soliman, Hesham wrote:
> 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

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

---

From: Christian Vogt <[email-masked]>
Date: Mon, 21 Feb 2005 20:06:45 +0100

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:
>  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.
> 
> 
>> -----Original Message----- From: Greg Daley
>> [mailto:[email-masked]] Sent: Sunday, February 20,
>> 2005 6:13 PM To: Christian Vogt Cc: Soliman, Hesham; [email-masked];
>> 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.
>> 
>>>> 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?
>>> 
>>> 
>>>>> If an RS contains a TSLLAO [1], the router does not have to
>>>>> >
>>>> immediately
>>>>>>> [...]                      If an entry already exists
>>>>>>> with a LLA then it responds with a (two options):
>>>>>>>>>> - A multicast RA. I think the second option might
>>>>>>>>>> be better to
>> allow for  >
>>>> ODAD to work.
>>>> 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.
>>> 
>>> 
>>> 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
>> 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.
>> 
>>>> 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'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.
>> 
>> 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.
>> 
>> 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
>>> 
> =========================================================== 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.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 22 Feb 2005 07:15:01 +0900

>>>>> On Sun, 20 Feb 2005 18:23:12 -0500, 
>>>>> "Soliman, Hesham" <[email-masked]> said:

> exists (or is created) the entry's IsRouter flag MUST be set to

Hmm...although I'm not necessarily opposing to the proposed text per
se, I'm afraid we're missing the point.  The general issue here, as I
see it, is the ND specification is not very clear about the case where
a (source or target) link-layer address is not provided in an
"unsolicited" messages (i.e., RS, RA, NS, redirects) and the receiving
node does not have a neighbor cache entry for the (source or target)
address.

For example, it's not clear about an NS in Section 7.3.3:

   A Neighbor Cache entry enters the STALE state when created as a
   result of receiving packets other than solicited Neighbor
   Advertisements (i.e., Router Solicitations, Router Advertisements,
   Redirects, and Neighbor Solicitations).  These packets contain the
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^
   link-layer address of either the sender or, in the case of Redirect,
   ^^^^^^^^^^^^^^^^^^
   the redirection target.

As we can see, the specification unconditionally assumes that these
packet contain a source or target LLAO.

So, I believe the more appropriate fix is to clarify how the node
should behave in this case in general.

As already pointed out, entering the STALE state doesn't make sense
without a link-layer address.

Again, as was pointed out in this thread, KAME/BSD creates a new entry
with its implementation-specific state "NOSTATE".  This might be one
possible resolution to this issue.  After re-reading the
specification, however, I now feel it makes more sense to do nothing
with neighbor cache (i.e., do not create a neighbor cache in the first
place).

If the receiving node then needs to send a unicast packet to the
(source or target) address, it will simply create a new entry with the
INCOMPLETE state.  There is no additional delay here except some CPU
cycles in the sending procedure.

Once we clarify this point, I don't see a particular need for adding
something like:

  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.

Since this is already pretty clear from the first part of this section
under a more flexible condition (i.e., whether or not the solicitation
included SLLAO):

   In addition to sending periodic, unsolicited advertisements, a router
   sends advertisements in response to valid solicitations received on
   an advertising interface.  A router MAY choose to unicast the
   response directly to the soliciting host's address (if the
   solicitation's source address is not the unspecified address),

BTW: in any event, we'll also need to fix other similar cases (e.g.,
Section 7.3.3) and Appendix C.

And one last remark: "NOSTATE" was actually introduced for
implementation-specific reasons, rather than to deal with the gap in
the specification.  So, we'll still keep this state as an internal
state specific to the implementation regardless of the result of this
discussion.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Christian Vogt <[email-masked]>
Date: Tue, 22 Feb 2005 17:13:42 +0100

Hi Greg.

>>> - 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.
> 
> I'm not sure if I get this.  Why would the NCE be stale if there's 
> been an NA response for the Router's NS?
> 
> It should be REACHABLE, using existing techniques.

Sorry, my mistake.  You are absolutely right.

The new text suggested a couple of hours back no longer explicitly 
mentions the state, because the usual address-resolution procedure is 
used anyway and the state should therefore be clear.

- Christian

Greg Daley schrieb:
> Hi Christian,
>> 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
>>> 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.
> 
> 
> 
> I'm not sure if I get this.  Why would the NCE be stale if there's
> been an NA response for the Router's NS?
> 
> It should be REACHABLE, using existing techniques.
> 
> You could precis this to:
> 
> - It elects to perform unicast delivery, performs address resolution 
> on Router Solicitation's sender, creating a new neighbour cache
> entry. It delivers a unicast Router Advertisement when neighbour 
> discovery completes.
> 
>>> Whether or not a Source Link-Layer Address option is provided in
>>> the solicitation, [...]
>> 
> Whether we need it, is another matter (to be discussed with Jinmei 
> and others).
> 
> Greg

   "No great genius has ever existed without some touch of
    madness." (Aristotle)

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 23 Feb 2005 04:25:41 +0900

>>>>> On Tue, 22 Feb 2005 11:18:24 +0100, 
>>>>> Christian Vogt <[email-masked]> said:

> Ok, your point is the order implied in the text I suggested.  I actually 
> didn't mean to imply this.  But yes, the text could potentially be 
> misinterpreted.  So maybe you whish to reduce it to the following?

(snip)

> In the above, the first paragraph specifies NC-state creation, and the 
> second specifies the additional address-resolution procedure that may be 
> required in the case of a unicast RA.  This second paragraph is based on 
> the corresponding existing paragraph in section 7.2.4.  (Note the 
> difference between "[unicast] Router Solicitations" and "[unicast] 
> Router Advertisements", though.)  This is good for conformity.

> We don't need to explicitly address the case of a solicitation without 
> SLLAO in the first paragraph, because (a) no NC state is created in case 
> of a multicast RA, (b) the second paragraph describes address resolution 
> and state creation in case of a unicast RA in conformance with section 
> 7.2.4, and (c) the decision of whether to send a multicast or a unicast 
> RA is already attended to in the beginning of section 6.2.6.

Okay, the proposed text looks reasonable.

> An aside with respect to the second paragraph:  You may also want to 
> modify this paragraph through a s/Neighbor Discovery/address resolution/ 
> in both section 7.2.4 and, as suggested, section 6.2.6.

I tend to agree (although it's not a strong preference).

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 23 Feb 2005 04:31:08 +0900

>>>>> On Tue, 22 Feb 2005 16:26:26 +1100, 
>>>>> Greg Daley <[email-masked]> said:

> So if this is the case, we need to describe messages which request a
> response or change configuration state without having LLAOs.

> How about a paragraph (maybe somewhere else) saying:

> "... It is possible that a host may receive a solicitation or a router
(snip)
> ..."

> I'm not sure about whether this is better or not perhaps this could go
> into 7.2.X, in an effort to tie the exercise to address resolution,
> rather than reception of a particular message (considering that the
> document is basically broken into 3 sections: RD, ND, Redirect).

I think this type of general clarification makes sense.

					JINMEI, Tatuya

---

From: Christian Vogt <[email-masked]>
Date: Wed, 23 Feb 2005 08:48:29 +0100

Hi Jinmei, Greg, Hesham.

JINMEI Tatuya wrote:
> Greg Daley said:
> 
>> It has been a bit confusing with crossing e-mails and timezone
>> differences.
> 
> Sorry, I actually noticed the possible confusion when I was writing 
> the messages, but I simply let it go..

Actually, the guy who has been messung things up the most is me.  There
was no bad intention.  I'm sorry... :)

>> I think that there's agreement for clarification.
> 
> Yes, I think so.

Same here.  And not only that we agree on the need for clarification,
the suggested text fragments are also very similar now.

>> I think that people agree what needs to be clarified.
> 
> Ditto.

Yes.

>> I'm not sure if it's decided where to put the clarification (but I
>> don't care myself, so long as everyone else agrees)
> 
> 
> Actually, I'm not sure, either.

I think that Jinmei's suggestion to have a general description about
unsolicited RS's and NS's without SLLAO is needed.  This would be a good
place to explicitly mention in which cases NC state is NOT to be
created.  In contrast, in sections 6.2.6 and 7.2.3/7.2.4, it's probably 
wise to say only what a node/router does rather than what it refrains 
from doing.

Given the separation in RD, ND, and Redirect (which Greg previously
mentioned), would you agree that we also amend sections 6.2.6 and 
7.2.3/7.2.4?  I'd be in favor of doing this.  Both parts of the document 
specify NC-state creation and the decision of whether a multicast or 
unicast response ought to be used.  And both of these subjects are relevant.

>> I'm not sure if there is a text which is agreed. (I've heard more
>> harmonious responses in later text, but there were two or three
>> fairly related pieces of text going round).
> 
> Again, I'm not sure, either.  But I agreed on the Christian's second 
> proposal **if we agree on the need for revising Section 6.2.6**.

See above.  Yes, I do agree.

> I don't have a strong preference on how to fix the issue, but if I 
> were to ask, I'd
> 
> - at least add a general note about what the node should do when it 
> receives an unsolicited ND message (NS, RS, RA, Redirect) without 
> LLAO and does not have a corresponding neighbor cache.  I don't care 
> about the place, but I'd probably use Section 7.3.3, and
> 
> - updated APPENDIX C (state machine) accordingly, and
> 
> - (optionally) describe a bit more details of each case (e.g., add 
> clarification 6.2.6 for the RS case)

Agreed.  What would have to be added to (or modified in) section 6.2.6
is not too far from what is needed for section 7.2.3/7.2.4.  So, we 
might be able to reuse some text, making the modifications consistent.

- Christian

---

From: Greg Daley <[email-masked]>
Date: Tue, 22 Feb 2005 11:11:40 +1100

Hi Christian,

>  > responds with a unicast Router Advertisement directed to the

I'm not sure if I get this.  Why would the NCE be stale if there's been
an NA response for the Router's NS?

- It elects to perform unicast delivery, performs address resolution
   on Router Solicitation's sender, creating a new neighbour cache entry.
   It delivers a unicast Router Advertisement when neighbour
   discovery completes.

Greg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 22 Feb 2005 10:21:09 +0900

>>>>> On Mon, 21 Feb 2005 20:06:45 +0100, 

>> responds with a unicast Router Advertisement directed to the

I personally think this is overspecification.  As I said in a separate
message, the essential problem (IMO) is that the spec is unclear on
the case where
  - an unsolicited ND message does not contain source/target LLAO
  - the receiving node does not have a neighbor cache entry for the
    source/target

(and this is a general issue, not specific to RS).

Once we clarify this point, I believe we can simply leave the other
details to implementors.  In this specific case, for example, if the
router that receives the RS decides to respond to it with a unicast
RA (this is already explicitly allowed in the current spec), the
outgoing RA will create a new neighbor cache entry, causing link-layer
address resolution (again, per the current specification).  There'd be
no difference on the external behavior.

Moreover, I even think specifying this level of details can be harmful
for some implementations.  In the case of BSD/KAME, it is a userland
process (rtadvd) which would decide to respond to the RS with a
unicast RA (although currently it only supports multicast RAs), while
NS/NA exchanges can only happen inside the kernel.  Thus, it is
difficult for the implementation to follow the specified ordering:

  1. it performs address resolution on the solicitation's sender
  2. creates a new Neighbor Cache entry
  3. installs the link-layer address
  4. sets its reachability state to STALE
     (BTW: this is strange.  after a successful address resolution,
      the state should be REACHABLE)
  5. responds with a unicast Router Advertisement

because the kernel, which performs 1 through 4, cannot tell the
application's decision beforehand.

Again, note that we can realize (almost) exactly the same external
behavior without specifying this ordering.  IMO, what we should do is
to fix the real generic issue, and then there should be no ambiguity
in further details.

					JINMEI, Tatuya

---

From: Greg Daley <[email-masked]>
Date: Tue, 22 Feb 2005 16:26:26 +1100

Hi Jinmei,

> to fix the real generic issue, and then there should be no ambiguity

I don't think the issue of Unsolicited NA is a big one, since there's
no implied response,  and well known unreliability issues with
sending an unsolicited NA (people ignore it if there's no existing 
entry) which limit its use.

"... It is possible that a host may receive a solicitation or a router
      advertisement without a link-layer address option included.
      These messages will not create or update neighbor cache entries,
      except with respect to the IsRouter flag as specified in
      Sections XXX and YYY.

      If a neighbour cache entry does not exist for the source of such a
      message, Address Resolution will be required before unicast
      communications with that address to begin.
      This is particularly relevant for unicast responses to
      solicitations where an additional packet exchange is required for
      advertisement delivery.
..."

Greg

---

From: Christian Vogt <[email-masked]>
Date: Tue, 22 Feb 2005 11:18:24 +0100

Hi Jinmei.

> (and this is a general issue, not specific to RS).

I agree that it would be good to address this issue on a general level. 
  On the other hand, there are also related differences between RS 
handling and NS handling that need to be described on a separate basis 
anyway.  For instance, RFC 2461[bis] specifies exactly when a NA is to 
be multicast and when it is to be unicast (section 7.2.4).  This is a 
difference to RA's, which may be either multicast or unicast (if the 
RS's source address was not unspecified), even if there is no SLLAO.

Also, section 7.2.4 explicitly says what to do if a unicast NA is to be 
sent, but the recipient's link-layer address is unknown (i.e., invoke 
address resolution).  So one may consider to put a similar note into 
section 6.2.6.  I don't think this would be overspecification.

   [...]                 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 a Neighbor Cache
   entry for the solicitation's sender exists (or is created) the entry's
   IsRouter flag MUST be set to FALSE.

   Because Router Solicitations are not required to include a Source
   Link-Layer Address, it is possible that a router sending a solicited
   unicast Router Advertisement does not have a corresponding link-
   layer address for its neighbor in its Neighbor Cache.  In such
   situations, a router will first have to use Neighbor Discovery to
   determine the link-layer address of its neighbor (i.e, send out a
   multicast Neighbor Solicitation).

- Christian

---

From: Greg Daley <[email-masked]>
Date: Wed, 23 Feb 2005 10:27:02 +1100

Hi Jinmei and Christian,

It has been a bit confusing with crossing e-mails and
timezone differences.

I'm not sure if it's decided where to put the clarification
(but I don't care myself, so long as everyone else agrees)

I'm not sure if there is a text which is agreed.
(I've heard more harmonious responses in later text, but
  there were two or three fairly related pieces of text going round).

Can we confirm whether there's agreement on the location
of clarifying statements?

Can we also agree or confirm (possibly conditionally on the
previous question) whether there's an agreement on text?

I'm not worried at the moment, since things seem to be
going the right way.

Greg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 23 Feb 2005 11:55:25 +0900

Hi,

>>>>> On Wed, 23 Feb 2005 10:27:02 +1100, 

Yes, I think so.

Ditto.

Hope this helps,

					JINMEI, Tatuya