Hi, Abe-san.
The Redirect never update the Neighbor Cache for TR1.
In Redirect case,
the importance is not the source address but the target address -- TR2.
RFC 4861: Neighbor Discovery in IPv6
8.3. Host Specification
------------------------------------------------------------------------
4214 If the redirect contains a Target Link-Layer Address option, the host
4215 either creates or updates the Neighbor Cache entry for the target.
4216 In both cases, the cached link-layer address is copied from the
4217 Target Link-Layer Address option. If a Neighbor Cache entry is
4218 created for the target, its reachability state MUST be set to STALE
4219 as specified in Section 7.3.3. If a cache entry already existed and
4220 it is updated with a different link-layer address, its reachability
4221 state MUST also be set to STALE. If the link-layer address is the
4222 same as that already in the cache, the cache entry's state remains
4223 unchanged.
------------------------------------------------------------------------
The Neighbor Cache for TR2 may be updated by TLL option in Redirect.
But in that case the state is never updated to REACHABLE.
Updating to STALE is the only possibility.
When the Neighbor Cache for TR2 is updated to STALE,
the state will have the same way as I described in the previous E-mail.
IsRouter is one of the parameter for Neighbor Cache,
and it's not the same as the reachability state.
How do you think?
Thanks,
On Wed, 11 Jun 2008 12:46:17 +0900
Toyo Abe <tabe@miraclelinux.com> wrote:
> Akisada-san, thanks for your explanation.
>
> But I have a bit different notion.
>
> Yukiyo Akisada wrote:
> > Hi, Toyo-san.
> >
> > The specification says about the Cleanup procedure like following.
> >
> > Summary: The Cleanup procedure should cause the NUT to transition Neighbor Cache entries created in
> > this test to state No NCE and remove any entries from its Default Router and Prefix Lists.
> >
> > Thinking about v6LC.2.3.13 and v6LC.2.3.14,
> > the neighbor cache will be removed by test procedure itself.
> >
> > For example,
> > v6LC.2.3.13.A will take following sequence.
> >
> > TH1 TR1 HUT TR2
> > | | | |
> > | <NONE> | <NONE>
> > | |------>| | Common Setup 1.1: RA w/o SLL
> > | |------>| | Common Setup 1.1: Echo Request
> > | | <INCOMPLETE> |
> > | |<------| | Common Setup 1.1: multicast NS
> > | |------>| | Common Setup 1.1: NA
> > | | <REACHABLE> |
> > | |<------| | Common Setup 1.1: Echo Reply
> > | | | |
> > | | |<------| Procedure step 1: Echo Request
> > | | | <INCOMPLETE>
> > | | |------>| Procedure step 2: multicast NS
> > | | |<------| Procedure step 2: NA
> > | | | <REACHABLE>
> > | | |------>| Procedure step 3: Echo Reply
> > | | | | Procedure step 4: wait 45 sec
> > | <STALE> | <STALE>
> > |-------+------>| | Procedure step 5: Echo Request
> > |<------+-------| | Procedure step 6: Echo Reply
> > | <DELAY> | |
> > | |------>| | Procedure step 7: Redirect
> > | | | <unchanged>
>
> Note that TR1 send Redirect to HUT when NCE for TR1 in HUT is in DELAY state.
> Looking at RFC4861 section 7.2;
> ---
> 7.2. Address Resolution
> ...
>
> It is possible that a host may receive a solicitation, a router
> advertisement, or a Redirect message without a link-layer address
> option included. These messages MUST NOT create or update neighbor
> cache entries, except with respect to the IsRouter flag as specified
> in Sections 6.3.4 and 7.2.5. If a Neighbor Cache entry does not
> ...
> ---
>
> According to this text, NCE for TR1 can be updated because its IsRouter
> flag is set. Upon receipt of the Redirect, NCE for TR1 can be updated
> to REACHABLE, I think.
> If my understanding is correct, NCE for TR1 could be still alive even after
> the cleanup procedure of v6LC.2.3.13.A is completed, for instance.
>
> Could you give me a comment on this point?
>
> Regards,
> -toyo
>
> > | | |<------| Procedure step 9: Echo Request
> > | | |------>| Procedure step 10: Echo Reply
> > | | | <DELAY>
> > | <PROBE> | |
> > | |<------| | NS
> > | |<------| | NS
> > | |<------| | NS
> > | <NONE> | |
> > | | |------>| NS
> > | | |------>| NS
> > | | |------>| NS
> > | | | <NONE>
> > | | | |
> > V V V V
> >
> > After this test sequence,
> > HUT will remove his neighbor cache entries autonomously.
> > So, TR1 and TR2 are not the target of the Cleanup procedure
> > because neighbor cache entries wasn't created in this test
> > as the Summary of the Cleanup procedure said.
> >
> > Thanks,
> >
> >
> > On Mon, 02 Jun 2008 11:13:18 +0900
> > Toyo Abe <tabe@miraclelinux.com> wrote:
> >
> >> Hi,
> >>
> >> Thank you for your great work!
> >>
> >>> 2008/05/27 Yukiyo Akisada
> >>> M addr.p2/v6LC_3_2_1_[A-C].seq, v6LC_3_2_4_J.seq
> >>> - allow time for all devices
> >>> to perform stateless address autoconfiguration and
> >>> Duplicate Address Detection.
> >> I've confirmed it works well on my test env.
> >>
> >> BTW, I suppose that cleanup procedure in some tests is not good enough.
> >> In v6LC.2.3.13 (A to E) and v6LC.2.3.14 (A to E), which are the tests for hosts only,
> >> the cleanup procedure just sends RA w/o SLL from TR1 to all-nodes multicast addr. That's all.
> >> According to ipv6ready logo test spec, they should follow Common Test Cleanup procedure
> >> but looks different in the test suite.
> >>
> >> Could you take a look?
> >>
> >> Best Regards,
> >> Toyo Abe <tabe@miracleinux.com>
> >> Software Expert
> >> Miracle Linux Corporation.
> >>
> >> Yukiyo Akisada wrote:
> >>> Hi, all.
> >>>
> >>> Major Version Up for Phase-1/Phase-2 Core Protocols has been accomplished
> >>> on IPv6 Ready Logo Program.
> >>>
> >>> We, TAHI project also followed this update.
> >>> Now, Self_Test_4-0-0 and v6eval-3.0.14 have been available on the web.
> >>>
> >>> When you use Self_Test_4-0-0,
> >>> please make sure to use v6eval-3.0.14.
> >>>
> >>> Here is differences of Self_Test.
> >>>
> >>> Self_Test_4-0-0: Change Log from 4.0.0b2
> >>> ========================================================================
> >>> 2008/05/27 Yukiyo Akisada
> >>> M addr.p2/v6LC_3_2_1_[A-C].seq, v6LC_3_2_4_J.seq
> >>> - allow time for all devices
> >>> to perform stateless address autoconfiguration and
> >>> Duplicate Address Detection.
> >>>
> >>>
> >>> 2008/05/21 Yukiyo Akisada
> >>> M addr.p2/INDEX_P1_HOST, INDEX_P1_SPECIAL, INDEX_P2_HOST
> >>> A addr.p2/v6LC_3_2_4_J.{def,seq}
> >>> - add new test (v6LC.3.2.4.J)
> >>>
> >>>
> >>> 2008/05/12 Yukiyo Akisada
> >>> M nd.p2/v6LC_2_3_4_[E-H].seq, redirect.pm (v6LC.2.3.4)
> >>> M nd.p2/redirect.pm (v6LC.2.3.5, v6LC.2.3.6, v6LC.2.3.8, v6LC.2.3.9)
> >>> - set TR2's NCE to REACHABLE before sending ICMPv6 Redirect
> >>>
> >>> M nd.p2/redirect.pm (v6LC.2.3.7)
> >>> - set TR2 and TR3's NCE to REACHABLE before sending ICMPv6 Redirect
> >>> ========================================================================
> >>>
> >>> There is no differences between v6eval-3.0.14 and v6eval-3.0.14b1.
> >>>
> >>> Thanks,
> >>>
> >>>
> >>
> >>
> >
> >
>
>
--
Yukiyo Akisada <akisada@tahi.org>