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 / [EMAIL PROTECTED]@C#:H (B <[EMAIL PROTECTED]>)>
To: "O.L.N.Rao" <[EMAIL PROTECTED]>
Cc: "IPV6 IETF (E-mail)" <[EMAIL PROTECTED]>; "Grubmair Peter"
<[EMAIL PROTECTED]>
Sent: Monday, August 16, 2004 12:52 PM
Subject: Re: NUD and solicitated Router Advertisement ?
> >>>>> On Mon, 16 Aug 2004 11:38:21 +0530,
> >>>>> "O.L.N.Rao" <[EMAIL PROTECTED]> said:
>
> >> > 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.
> >>
> >> 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.
>
> > I think that Unsolicted RA *ALWAYS* sent to "All Nodes Multicast
Address -
> > ff02::1".
>
> 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
> Communication Platform Lab.
> Corporate R&D Center, Toshiba Corp.
> [EMAIL PROTECTED]
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [EMAIL PROTECTED]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
