Hi.
As I wrote before the test expects you to treat this prefix as on-link,
meaning when you receive ICMP request, since you don't have NCE, you
need to invoke Neighbor Discovery and send NS for this IP. Instead you
treat it as off-link and send ICMP reply to default router TR1.
Best regards,
Vladimir Kuk
-----Original Message-----
From: Gunnia Chandrasekaran, Praveen Kumar [mailto:gcpraveen@hp.com]
Sent: Wednesday, June 18, 2008 12:23 PM
To: users@tahi.org
Subject: [users:00783] Re: Self_Test v4.0.1 NDP test v6LC.2.2.19
Hi,
For V6LC.2.2.19:
From the test specification observable results, "The HUT should transmit
an Echo Reply to TN1's global address on-link"
But the test case fails as it was expecting the NS packet. According to
the release notes and the observed results the same, but the test case
fails.
So please find the attached logs and let us know your findings.
Thanks and Regards,
Praveen Kumar Gunia Chandrasekaran
IPG R&D HSL, Hewlett Packard ISO,
30, Cunningham Road, Bengalooru - 560 052.
Karnataka, India.
Phone: +91 80 2205 1791
E-mail: gcpraveen@hp.com
-----Original Message-----
From: Vladimir Kuk [mailto:vkuk@marvell.com]
Sent: Wednesday, June 18, 2008 10:21 AM
To: Yukiyo Akisada
Cc: users@tahi.org
Subject: [users:00781] Re: Self_Test v4.0.1 NDP test v6LC.2.2.19
Hi, Akisada-san.
I can see from the test specification that I was right about the test
purpose. And so my problem still stays the same. Although RFC 4861
expects that the prefix will be on-link, RFC 4862 permits invalidating
this prefix because of invalid prefix length.
Please correct me if I'm wrong.
Thank you for your time.
Best regards,
Marvell Software Solutions Israel Ltd.
Atidim Technological Park Bldg #4
Tel Aviv, 61581, Israel
Email: vkuk@marvell.com
Office: +972-3-645-8955
Web site: http://www.marvell.com
-----Original Message-----
From: Yukiyo Akisada [mailto:akisada@tahi.org]
Sent: Wednesday, June 18, 2008 3:33 AM
To: Vladimir Kuk
Cc: users@tahi.org
Subject: Re: [users:00777] Self_Test v4.0.1 NDP test v6LC.2.2.19
Hi, Vladimir.
The official test specification can be downloaded from
<http://www.ipv6ready.org/about_phase2_test.html>.
<http://www.ipv6ready.org/pdf/IPv6_Ready_Test_Specification_Core_Protoco
lsv4_0_0.pdf> is the newest.
The documents in the test script have differences from it because of my
loose.
Please refer to the official specification in this moment.
If you still have questions after checking the official document, please
let me know again.
Thanks,
On Tue, 17 Jun 2008 12:00:04 +0300
"Vladimir Kuk" <vkuk@marvell.com> wrote:
> Hello.
>
> I'm running Self Tests for phase 2 host part and ran into some problem
> with NDP test 2.2.19.
>
> In it a little problematic to understand the test since the
description
> in it, is for another test (2.2.12.A).
>
> As far as I can it tests for discarding the invalid prefix for
purposes
> of autoconfiguration but expects this prefix to be accepted for onlink
> determination.
>
> If I understood the test correctly, then there is a problem since RFC
> 4892 states:
>
> 5.5.3. Router Advertisement Processing p.19:
>
> If the sum of the prefix length and interface identifier length does
> not equal 128 bits, the Prefix Information option MUST be ignored. An
> implementation MAY wish to log a system management error in this case.
> The length of the interface identifier is defined in a separate
> link-type specific document, which should also be consistent with the
> address architecture [RFC4291] (see Section 2).
>
> Also, in same section:
> It should be noted, however, that this does not mean the advertised
> prefix length is meaningless. In fact, the advertised length has
> non-trivial meaning for on-link determination in [RFC4861] where the
> sum of the prefix length and the interface identifier length may not
> be equal to 128. Thus, it should be safe to validate the advertised
> prefix length here, in order to detect and avoid a configuration error
> specifying an invalid prefix length in the context of address
> autoconfiguration.
>
>
> Can anyone shed a light on the matter?
>
>
> Thank you.
>
> Best regards,
>
> Vladimir Kuk
>
> Marvell Software Solutions Israel Ltd.
> Atidim Technological Park Bldg #4
> Tel Aviv, 61581, Israel
> Email: vkuk@marvell.com
> Office: +972-3-645-8955
> Web site: http://www.marvell.com
>
>
>
>
>
>
--
Yukiyo Akisada <akisada@tahi.org>