MN-6-2-1-1-004 - Receiving invalid MH (invalid checksum) from HA
Host
|
R CN0
| |
-----+-------+--------+---------------- LinkZ
|
R2 NUTY
| |
-----+-------+-----------------+------- LinkY
|
R1 NUTX
| |
-----+-------+-----------------+------- LinkX
|
HA0 Node0 NUT0
| | |
----------------------+---------------+---------+------- Link0
| Link0 |
3ffe:501:ffff:100::/64 |
home link |
| LinkX |
3ffe:501:ffff:102::/64 |
|
| LinkY |
3ffe:501:ffff:103::/64 |
|
| LinkZ |
3ffe:501:ffff:104::/64 |
|
| HA0(Link0) |
3ffe:501:ffff:100:200:ff:fe00:a0a0 |
|
| Node0(Link0) |
3ffe:501:ffff:100:200:ff:fe00:a3a3 |
|
| R1(LinkX) |
3ffe:501:ffff:102:200:ff:fe00:a4a4 |
|
| R2(LinkY) |
3ffe:501:ffff:103:200:ff:fe00:a6a6 |
|
| CN0(LinkZ) |
3ffe:501:ffff:104:200:ff:fe00:a8a8 |
|
1. Selection Option
- home registration Binding Update Retransmissions : YES
2. Position of Mobile Node
- none.
HA0 NUT0 R1 R2 CN0
| | | | |
| ----> | | | | 1.Router Advertisement
| | | | |
| NUTX | | |
| | | | |
| | <---- | | | 2.Router Advertisement
| | | | |
| <---- | | | | 3.Neighbor Solicitations
| | | | | 4.(no reply:3 seconds)
| | | | |
| <---- | | | | 5.Binding Update
| ----> | | | | 6.Binding Acknowledgement(*1)
| | | | |
| <---- | | | | 7.Binding Update
| | | | |
1. Send Router Advertisement. (HA0 -> HA0_allnode_multi)
2. Send Router Advertisement. (R1 -> R1_allnode_multi)
3. Receive Neighbor Solicitations. (NUT0 -> HA0)
4. (no reply)
# Wait during a maximum of 3 seconds(RFC2461).
5. Receive Binding Update. (NUTX -> HA0)
6. Send Binding Acknowledgement. (HA0 -> NUTX)
# The Checksum field in Mobility Header has the invalid values.
7. Receive Binding Update. (NUTX -> HA0)
6.Binding Acknowledgement
(*1) PASS: HA0 receives a retransmission of Binding Update.
(draft-ietf-mobileip-ipv6-24.txt)
11.2 Processing Mobility Headers
All IPv6 mobile nodes MUST observe the rules described in Section 9.2
when processing Mobility Headers.
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.
o The MH Type field MUST have a known value (Section 6.1.1).
Otherwise, the node MUST discard the message and issue a Binding
Error message as described in Section 9.3.3, with Status field set
to 2 (unrecognized MH Type value).
o The Payload Proto field MUST be IPPROTO_NONE (59 decimal).
Otherwise, the node MUST discard the message and SHOULD send ICMP
Parameter Problem, Code 0, directly to the Source Address of the
packet as specified in RFC 2463 [14]. Thus no Binding Cache
information is used in sending the ICMP message. The Pointer
field in the ICMP message SHOULD point at the Payload Proto field.
o The Header Len field in the Mobility Header MUST NOT be less than
the length specified for this particular type of message in
Section 6.1. Otherwise, the node MUST discard the message and
SHOULD send ICMP Parameter Problem, Code 0, directly to the Source
Address of the packet as specified in RFC 2463 [14]. (The Binding
Cache information is again not used.) The Pointer field in the
ICMP message SHOULD point at the Header Len field.
Subsequent checks depend on the particular Mobility Header.