Hi, William.
Because this is just the test,
TN must send any packet even it is not acceptable in RFC.
The purpose of this test is not the sending function on TN but the reception function on NUT.
And RFC never say that such packet must be ignored.
From the viewpoint of reception,
the packet must be processed
by NUT according to Section 7.2.5 (Receipt of Neighbor Advertisements).
I have a good example for my explanation.
This is the very similar case to the test for reserved field.
Usually, it is defined that the reserved filed must be set to zero by the sender,
and it must be ignored by the receiver.
Even though RFC inhibits to use non-zero value for the reserved field,
but for testing purpose, we did it in the test.
Thanks,
On Tue, 16 Sep 2008 09:45:48 -0400
William Seppeler <wrs@pt.com> wrote:
> In this test, the TN sends an (un)soliticted NA with the S bit set with
> the expectation that the NUT will update it's NCE. However, based on
> RFC4861:
>
> S Solicited flag. When set, the S-bit indicates that
> the advertisement was sent in response to a
> Neighbor Solicitation from the Destination address.
> The S-bit is used as a reachability confirmation
> for Neighbor Unreachability Detection. It MUST NOT
> be set in multicast advertisements or in
> unsolicited unicast advertisements.
>
> So my thoughts are the TN sends a packet that violates the spec (ie: MUST
> NOT). Can someone explain to me why the table shown in the test
> description expects the NUT to update it's NCE. It would seem that the
> RFC expects such a packet should get ignored.
>
> Thank you,
>
> ========================================
> William Seppeler
> Test Engineer
> Performance Technologies Inc.
> 205 Indigo Creek Dr.
> Rochester, NY 14626
>
> Phone: (585) 256-0200, Fax: (585) 256-0791
> Email: wrs@pt.com, Web: www.pt.com
> ========================================
>
>
--
Yukiyo Akisada <akisada@tahi.org>