Hi, Abe-san.
My concern is that Redirect is ND's packet itself.
You know,
RFC 4861 defines NCE state transition mechanism
using the packets defined in RFC 4861.
I think that ND packets shouldn't have the special meaning than RFC 4861.
I could understand your claim.
And RFC 4861 is the exeption for upper-layer protocol.
The point is that ND packets can be considerd as the upper-layer or not.
The behavior is not the verification point on the tester.
So I could add the additional cleanup procedure to increase versatility.
Before that
I think that it is better to ask at IETF ML.
How do you think?
And talking about the differences between v1.4.15 and v4.0.1,
the test procedure itself was changed.
For example of v6LC.2.3.13.A,
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>
| | |<------| Procedure step 9: Echo Request
| | |------>| Procedure step 10: Echo Reply
| | | <DELAY>
| <PROBE> | |
| |<------| | NS
| |<------| | NS
| |<------| | NS
| <NONE> | |
| | |------>| NS
| | |------>| NS
| | |------>| NS
| | | <NONE>
| | | |
V V V V
Old procedure didn't have step 5 and 6.
HUT didn't change the state when TR1 sent Redirect,
we needed the cleanup procedure.
Thanks,
On Wed, 18 Jun 2008 17:46:11 +0900
Toyo Abe <tabe@miraclelinux.com> wrote:
> Hi Akisada-san,
>
> Yukiyo Akisada wrote:
> > Hi, Karsten.
> >
> > In Test v6LC.2.3.13,
> > your box changed your Neighbor Cache State for TR1 to REACHABLE
> > by receiving Redirect from TR1 as you said.
> >
> > But, now I have doubt about Test v6LC.2.3.14.
> > In this test, you got PASS.
> > Why your box didn't change to REACHABLE by the Redirect?
> >
> > I think that the situation for TR1 is similar
> > between v6LC.2.3.13 and v6LC.2.3.14.
> >
> Yes, they are similar but not same. Notable difference is that NUT receives
> Redirect when NCE for TR1 is in PROBE state in v6LC.2.3.14.A.
> That is an exception case of the linux's behaviour.
>
> I summarized the behaviour as follows;
>
> o Linux considers the Redirect as upper-layer reachability confirmation as described
> in rfc4861 appendix C.
> o But linux doesn't change NCE state from PROBE to REACHABLE only by upper-layer
> reachability confirmation. Linux allows to update it to REACHABLE from DELAY or from
> REACHABLE by upper-layer reachability confirmation.
>
> Regarding to the failed cases in v6LC.2.3.13;
>
> o NUT changes NCE for TR1, which is in DELAY state, to REACHABLE by Redirct.
> o Cleanup procedure in v6LC.2.3.13 doesn't kill the NCE in NUT.
> o Initialization procedure in the next test expects NS for TR1 from NUT,
> but NUT doesn't send NS because it's in REACHABLE at that moment.
>
>
> In my lab, v6LC.2.3.14 also sometimes failed. It's because NCE for TR1 could be alive
> after the previous test is finished. But it's triggered also by the cleanup procedure of
> v6LC2.3.13, not of 2.3.14.
>
> For example, in the log which I sent to Akisada-san, test #223-#225 of v6LC.2.3.14 failed.
> And #222 of v6LC.2.3.13 was passed. In #222, the cleanup procedure is done at 16:44:59.
> As I said before, NCE for TR1 was not killed after #222 is completed. So initialization
> in #223-#225 failed. In #225, NUT processed 'Neighbour Unreachability Detection' (ie.
> send NS to unicast address of TR1). It resulted that the NCE was unreachable at 16:45:28
> so the NCE in NUT was killed then. The initialization in next test, #226, succeeded because
> there was no NCE for TR1 at that moment.
> The duration b/w completion of #222 and failure of #225 was 29 seconds. Since it was within
> the range of 'ReachableTime' described in rfc4861, the result makes sense for me.
>
> Could you check #222 of Karsten's log? I'm guessing that NUT processed 'Neighbour Unreachability
> Detection' at #222. If so, the NCE was killed in #222. And the later tests were passed
> because all Redirects were received in PROBE state.
>
>
> *My guess* is, linux folks think that a node should wait for the response(ie. NA) once
> request it(ie. sending NS). and should not change the state to REACHABLE without receiving
> the response.
>
> Thanks,
> -toyo
>
> > For the reference,
> > I attached expected state machine.
> >
> > Thanks,
> >
> >
> > On Fri, 13 Jun 2008 07:56:34 +0200
> > Karsten Keil <kkeil@suse.de> wrote:
> >
> >> On Fri, Jun 13, 2008 at 08:36:32AM +0900, Yukiyo Akisada wrote:
> >>> Hi, Karsten
> >>>
> >>>> Hmm, this seems not to be the case, I did run these test with Linux as NUT
> >>>> and Test v6LC.2.3.13 Part B-E are skipped because of "initialization fail"
> >>>> I can send you logs if you want.
> >>> Of course, I want to see the log.
> >>>
> >> I attach the nd.p2 dir as private mail because of size, feel free to post
> >> anything from the logs on the list.
> >>
> >> --
> >> Karsten Keil
> >> SuSE Labs
> >> ISDN and VOIP development
> >> SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg)
> >>
> >
> >
>
>
>
--
Yukiyo Akisada <akisada@tahi.org>