Hi, Subramani.
Supporting revised RFCs including RFC 4443 will be our next work.
In this moment, we haven't support RFC 4443 yet.
Revising RFCs are defined as major version/revision up in our document update policy.
And it will done at Nov. or May.
Please refer to <http://www.ipv6ready.org/pdf/IPv6-LC_maintenancev100.pdf> and
wait for our future release.
Regards,
On Fri, 12 Oct 2007 14:30:32 -0600
"Swaminadhan, Subramani" <subramani_swaminadhan@mentor.com> wrote:
> Yukiyo-san,
>
> Thanks for your reply. I was trying to test protocol changes
> caused due to compliance with RFC 4443 in the stack. That is why I used
> the Conformance Test Suite at http://www.tahi.org/release/
> (ct-2.1.1.tar.gz) to test my stack for RFC 4443 compliance.
>
> The Self Test 1.4.9 that you pointed me seems to tests RFC 2463
> - the older RFC that 4443 obsoleted. So, I am not sure if running
> Self_Test_1-4-9.tgz would test RFC 4443 conformance on my stack.
>
> Thanks,
> Subramani
>
> -----Original Message-----
> From: Yukiyo Akisada [mailto:akisada@tahi.org]
> Sent: Thursday, October 11, 2007 6:44 PM
> To: Swaminadhan, Subramani
> Cc: users@tahi.org
> Subject: Re: [users:00392] Phase 1 Conformance Test (ICMPv6 Test 6 and
> offlink NS messages)
>
> Hi, Subramani.
>
> Please try <http://www.tahi.org/logo/release/Self_Test_1-4-9.tgz>.
> Talking about IPv6 Core Protocols, it is the newest.
>
> Regards,
>
> On Thu, 11 Oct 2007 10:40:57 -0600
> "Swaminadhan, Subramani" <subramani_swaminadhan@mentor.com> wrote:
>
> > Hello All,
> >
> > I am currently testing RFC4443 changes to ICMPv6 using the TAHI IPv6
> > Conformance Test for ICMPv6 Phase 1 (Tool Version 3.0.12, Test Program
>
> > Version 2.1.1). The test keeps failing on ICMPv6 Route Unreachable
> > (Test #6) when trying to determine if the NUT sends a valid
> > Destination Unreachable (code 0).
> >
> > The sequence log for this test shows the following:
> > Start
> > Initialization
> > Start Caputring Packets (Link0)
> > Send Echo Request (Link-local address)
> > Receive Echo Reply (Link-local address)
> > TN created the entry of TN's link-local address to Neighbor cache
> > of NUT.
> > Send Echo Request (Global address)
> > Receive Echo Reply (Global address)
> > TN created the entry of TN's global address to Neighbor cache of
> > NUT.
> > Test
> > Send Echo Request to an offlink host
> > recv unexpected packet (ICMPv6 Neighbor Solicitation)
> > recv unexpected packet (ICMPv6 Neighbor Solicitation)
> > recv unexpected packet (ICMPv6 Neighbor Solicitation)
> > recv unexpected packet (ICMPv6 Dst Unreach Code 3)
> >
> >
> > RFC 2461 specifies:
> > Next-hop determination for a given unicast destination operates as
> > follows. The sender performs a longest prefix match against the
> > Prefix List to determine whether the packet's destination is on- or
> > off-link. If the destination is on-link, the next-hop address is
> the
> > same as the packet's destination address. Otherwise, the sender
> > selects a router from the Default Router List (following the rules
> > described in Section 6.3.6). If the Default Router List is empty,
> > the sender assumes that the destination is on-link.
> >
> > Going by the above RFC, the IPv6 stack always tries to find a route by
>
> > sending Neighbor Solicitations out of the same interface where a
> > packet destined to an off-link host arrived. I would like to know why
>
> > the TAHI Test Suite thinks sending this NS packet is illegal. Can
> > someone help me determine where the problem is?
> >
> > Thanks,
> > Subramani
> >
> >
> >
>
>
> ------------------------------------------------------------------------
> Yukiyo Akisada <akisada@tahi.org>
>
>
>
------------------------------------------------------------------------
Yukiyo Akisada <akisada@tahi.org>