Hi,
Please try to check calculation of a checksum.
The value of Upper-Layer Packet Length in pseudo-header may have a difference.
(Since I do not have the processing to calculate, this is imagination.)
RFC2460
----
8.1 Upper-Layer Checksums
o The Upper-Layer Packet Length in the pseudo-header is the
length of the upper-layer header and data (e.g., TCP header
plus TCP data). Some upper-layer protocols carry their own
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
length information (e.g., the Length field in the UDP header);
^^^^^^^^^^^^^^^^^^
for such protocols, that is the length used in the pseudo-
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
header. Other protocols (such as TCP) do not carry their own
^^^^^^^
length information, in which case the length used in the
pseudo-header is the Payload Length from the IPv6 header, minus
the length of any extension headers present between the IPv6
header and the upper-layer header.
----
RFC3775
----
6.1.1. Format
Header Len
8-bit unsigned integer, representing the length of the Mobility
^^^^^^^^^^^^^^^^^^^^^^^^^^
Header in units of 8 octets, excluding the first 8 octets.
^^^^^^
Checksum
16-bit unsigned integer. This field contains the checksum of the
Mobility Header. The checksum is calculated from the octet string
consisting of a "pseudo-header" followed by the entire Mobility
^^^^^^^^^^^^^^^
Header starting with the Payload Proto field. The checksum is the
^^^^^^
16-bit one's complement of the one's complement sum of this
string.
The pseudo-header contains IPv6 header fields, as specified in
Section 8.1 of RFC 2460 [11]. The Next Header value used in the
pseudo-header is 2. The addresses used in the pseudo-header are
the addresses that appear in the Source and Destination Address
fields in the IPv6 packet carrying the Mobility Header.
Note that the procedures of calculating upper layer checksums
while away from home described in Section 11.3.1 apply even for
the Mobility Header. If a mobility message has a Home Address
destination option, then the checksum calculation uses the home
address in this option as the value of the IPv6 Source Address
field. The type 2 routing header is treated as explained in [11].
The Mobility Header is considered as the upper layer protocol for
the purposes of calculating the pseudo-header. The Upper-Layer
^^^^^^^^^^^^^^^
Packet Length field in the pseudo-header MUST be set to the total
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
length of the Mobility Header.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For computing the checksum, the checksum field is set to zero.
----
for Normal HoTI
----
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upper-Layer Packet Length | <== 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len=1 | MH Type | Reserved | ==> 8 + (8 * Header Len(1)) = 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Home Init Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
----
for CN-2-1-3 HoTI (without cookie length)
----
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upper-Layer Packet Length | <============================ 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len=0 | MH Type | Reserved | ==> 8 + (8 * Header Len(0)) = 8
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
----
Best Regards
--
Kiyoaki Kawaguchi
""Leino, Tammy" <tammy_leino@mentor.com>" wrote:
> This is a multi-part message in MIME format.
>
>
>
>
> Hello All,
>
> When running test #6 for the Correspondent Node self-test suite, I see that the HoTI message sent from the TAHI node has a wrong checksum value; therefore, the NUT throws this packet out before trying to validate the length of the Mobility Header. This causes the NUT to fail the test, but this is proper functionality per RFC 3775:
>
> 9.2. Processing Mobility Headers
>
> Mobility Header processing MUST observe the following rules:
>
> o The checksum must be verified as per Section 6.1. Otherwise, the
> node MUST silently discard the message.
>
> Can someone please confirm that there is a checksum error in this test? I have attached the output file for this test for your reference.
>
> Best Regards,
> Tammy Leino
> <<6.html>>
>
>
>
>
>
>
>