Index: [Article Count Order] [Thread]

Date: Wed, 11 Jun 2008 12:46:17 +0900
From: Toyo Abe <tabe@miraclelinux.com>
Subject: [users:00760] Re: Major Version Up: IPv6 Ready Logo Program Phase-1/Phase-2 Core Protocols
To: Yukiyo Akisada <akisada@tahi.org>
Cc: users@tahi.org
Message-Id: <484F4A89.5040308@miraclelinux.com>
In-Reply-To: <20080610105402.b0eb6466.akisada@tahi.org>
References: <20080530095616.101712c1.akisada@tahi.org>	<4843573E.6080208@miraclelinux.com> <20080610105402.b0eb6466.akisada@tahi.org>
X-Mail-Count: 00760

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,
>>>
>>>
>>
>>
> 
>