Subject: NUD and solicitated Router Advertisement ?

From: Grubmair Peter <[email-masked]>
Date: Mon, 2 Aug 2004 12:24:11 +0200

In page 49, chapter 4.3.4 of draft-soliman-ipv6-2461-bis-01.txt
it is stated that after reception of Router Advertisement, which 
contains a source link-layer address option, a new
neighbor cache entry SHOULD be created.
The state of this new cache entry shall be STALE.
But to my mind, if the destination address of
Router advertisement packet is a unicast address of
the interface, I can set state to REACHABLE.
This is because this router advertisement must be a
response to my router solicitation.
Why was decided  to set the state to STALE in any case
in the draft ?
Best regards
        Peter

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 16 Aug 2004 14:27:53 +0900

>>>>> On Mon, 2 Aug 2004 12:24:11 +0200 , 
>>>>> Grubmair Peter <[email-masked]> said:

> response to my router solicitation.

This is not correct, since the router advertisement may be an
unsolicited one or a solicited one but in response to other router
solicitations (and your solicitation may have been lost).  So we
cannot set the state to REACHABLE in this case.

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

---

From: "O.L.N.Rao" <[email-masked]>
Date: Mon, 16 Aug 2004 11:38:21 +0530

Hi Jinmei,

    -- See my comments inline --

----- Original Message ----- 
From: <JINMEI Tatuya / $B?@L@C#:H (B <[email-masked]>)>
To: "Grubmair Peter" <[email-masked]>
Cc: "IPV6 IETF (E-mail)" <[email-masked]>
Sent: Monday, August 16, 2004 10:57 AM
Subject: Re: NUD and solicitated Router Advertisement ?

> cannot set the state to REACHABLE in this case.

I think that Unsolicted RA *ALWAYS* sent to "All Nodes Multicast Address -
ff02::1".

[PS : Solicited RA may also be sent to All Nodes, in case unsolicited RA is
just scheduled
after the reception of RS]

Conclusions:
1) All Unsolicited RAs are multicast destined but vice versa does not hold
good :)
2) All unicast RAs are solicited.

Am I right ?

Thank you,
O.L.N. Rao

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 16 Aug 2004 16:22:50 +0900

>>>>> On Mon, 16 Aug 2004 11:38:21 +0530, 
>>>>> "O.L.N.Rao" <[email-masked]> said:

> I think that Unsolicted RA *ALWAYS* sent to "All Nodes Multicast Address -

Oops, I missed the condition of "the RA desitination is
unicast"...hmm, then it may make sense to set the state to REACHABLE
immediately.

					JINMEI, Tatuya

---

From: "O.L.N.Rao" <[email-masked]>
Date: Mon, 16 Aug 2004 14:13:14 +0530

Hello Jinmei,

    I support the argument of optimizing NUD's RA processing.

    However, the RS-RA exchange is not a frequent one to happen.  Hence the
proposed optimization may not be of great advantage.  Also, I am
    wondering if it is going to create some IOT issues with old-RFC
implementations.  The simple example of such an IOT issue is, TAHI scripts
    expect a NS to be sent in some cases where TN guesses that NUT is in
STALE.  After that even if RS-RA exchange has happened, TAHI thinks
    the NUT is in STALE and test case proceeds from there.  If we introduce
this optimization, TAHI is likely going to show the test case result as
    FAIL as the new-NUT is not going to send any NS after RS-RA exchange.

    Hence, I would request you to look much deeper into that optimization
before going to consider it.

    Your comments are highly welcome :).

Thanks,
O.L.N. Rao

----- Original Message ----- 
From: <JINMEI Tatuya / $B?@L@C#:H (B <[email-masked]>)>
To: "O.L.N.Rao" <[email-masked]>
Cc: "IPV6 IETF (E-mail)" <[email-masked]>; "Grubmair Peter"
<[email-masked]>
Sent: Monday, August 16, 2004 12:52 PM
Subject: Re: NUD and solicitated Router Advertisement ?

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 16 Aug 2004 18:13:51 +0900

>>>>> On Mon, 16 Aug 2004 14:13:14 +0530, 

>     Your comments are highly welcome :).

Basically, I don't have a strong opinion on this.  As you mentioned,
this is, even if justified, a very minor optimization (in fact, I
even don't know of a router implementation that supports and does
unicast RAs).  So, I'm basically not interested in using the
optimization in our own implementation.

However, I don't oppose to introducing the optimization if the issue
is only related to protocol-conformance tools.

					JINMEI, Tatuya

---

From: Greg Daley <[email-masked]>
Date: Tue, 17 Aug 2004 10:31:32 +1000

Hi Jinmei,

> optimization in our own implementation.

Radvd supports unicast RAs.

The value of this becomes greater if you're performing DNA,
and only want to send one packet on the link (an RS).
Particularly when you're optimizing the delivery of RAs,
multicast packet delivery may not be an option.

The chance for updating the NCE to reachable through upper layer
packet reception is high though, if a router is adopted, so this
is just an optimization.

If there's value in this, we can either look at it here (it looks
small, self contained), or talk about it in DNA WG.

Greg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 17 Aug 2004 20:42:33 +0900

>>>>> On Tue, 17 Aug 2004 10:31:32 +1000, 
>>>>> Greg Daley <[email-masked]> said:

> small, self contained), or talk about it in DNA WG.

(I'm not sure if I was expected to make a response, but just in case)

As I said in the previous message, I'm not particularly interested in
this optimization, but I won't oppose to introducing that if others
want to do so.  So, please just go ahead if you want.

					JINMEI, Tatuya