Hi, Otoshi-san.
Observable Results allows following 2 behavior.
- TAR-Host1 MUST not transmit an Echo Reply using TAR-Router1 as its first hop.
- TAR-Host1 MUST ***not*** transmit a multicast NS with a target address set to TR1's link-local address.
You need to read 'or transmit' as 'TAR-Host1 MUST not transmit'.
Even me, it is confusable,
But the original text was written by American, so the English must be correct. :-)
Furthermore, you must refer to RFC 4861.
You know, it was revised in the past.
On-link assumption has been removed.
Your behavior is still valid, but it isn't required any more.
Thanks,
On Wed, 27 Feb 2008 12:11:23 +0900
otoshi.naoyuki@jp.panasonic.com (大利 直行/Naoyuki Otoshi) wrote:
> Hi, all
>
> I have a guestion about IPv6 CORE Protocol's implementation.
>
> CORE Protocol Interop TEST IP6Interop1.4
> 1. Configure TAR-Router1 to transmit Router Advertisements with Router Lifetimes equal to 0 and
> at a normal interval on Network1, and Router Lifetimes greater than the Router Advertisement
> Interval on Network2.
> 2. Transmit an ICMPv6 Echo Request from REF-Host2 to the Global Address of TAR-Host1.
> 3. Observe the packets sent on Network1 and Netwokk2
> 4. .....
>
> Observable Results:
> Step 3: TAR-Host1 MUST not transmit an Echo Reply using TAR-Router1 as its first hop or
> transmit a multicast NS with a target address set to TR1's link-local address.
> and Step 9 is same.
>
> Our test result is differnt. Our result is blow.
> Step 3 and Step 9
> TAR-Host1(Our TARGET) dosen't transmit an Echo Reply using TAR-Router1 as its first hop.
> But TAR-Host1 transmit a multicast NS with a target address set to REF-Host2's Global Address.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> When our target receive RA with Router Lifetime equal to 0
> Step1 : Keep Default Router List empty
> Step7 : Delete Defulat Router List entry which is created in Step4.
> So, Default Router List becomes empty.
>
> Then Step2 or Step8, when our target receive ICMPv6 Echo Request from REF-Host2,
> our target operate "next-hop determination" to send ICMPv6 Echo Reply.
>
> Accorging to RFC2461
> ---------------------------------------------------------------------------
> 5.2 Conceptual Sending Algorithm
> 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.
> ----------------------------------------------------------------------------
>
> In Step2 or Step8, Default Router List is empty. So, our target think that the
> destination(REF-Host2) is on-link. Then our target operate "7.2 Address Resolution"
> "7.2.2 Sending Neighor Solicitations".
> So, our target send a multicast NS with a target address set to REF-Host2' Global Address.
>
> Is such implemantation is correct or not?
> And if our implementation is not correct, where is wrong ?
> ( I don't understand why it is correct to transmit a multicast NS (TR1's link-local address)
> or not to transmit any packet.)
>
> Regars,
> Otoshi
>
> [Wed, 27 Feb 2008 11:03:49 +0900]
>
> ---- 2007/2/13付けで電話番号が変わりました
> 松下電器産業（株） パナソニック システムソリューションズ社
> 先行技術センター 技術３グループ １チーム
> TEL 050-3686-0617(Pana-VAN 7-373-2737) FAX 045-544-3829
> 大利 直行 otoshi.naoyuki@jp.panasonic.com
>
>
----
Yukiyo Akisada <akisada@tahi.org>