| 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 | | | | | 7.(wait) (*1) | | | | | 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 Status field is set to 0(Binding Update accepted). 7. (wait) # Wait during enough retransmission timer. Packet Format is: 6. Binding Acknowledgement
(*1) PASS: HA0 does not receive the retransmitting of Binding Update.
(draft-ietf-mobileip-ipv6-24.txt) 11.7.3 Receiving Binding Acknowledgements Upon receiving a packet carrying a Binding Acknowledgement, a mobile node MUST validate the packet according to the following tests: o The packet meets the authentication requirements for Binding Acknowledgements, defined in Section 6.1.8 and Section 5. That is, if the Binding Update was sent to the home agent, underlying IPsec protection is used. If the Binding Update was sent to the correspondent node, the Binding Authorization Data mobility option MUST be present and have a valid value. o The Binding Authorization Data mobility option, if present, MUST be the last option and MUST not have trailing padding. o The Sequence Number field matches the Sequence Number sent by the mobile node to this destination address in an outstanding Binding Update. Any Binding Acknowledgement not satisfying all of these tests MUST be silently ignored. When a mobile node receives a packet carrying a valid Binding Acknowledgement, the mobile node MUST examine the Status field as follows: o If the Status field indicates that the Binding Update was accepted (the Status field is less than 128), then the mobile node MUST update the corresponding entry in its Binding Update List to indicate that the Binding Update has been acknowledged; the mobile node MUST then stop retransmitting the Binding Update. In addition, if the value specified in the Lifetime field in the Binding Acknowledgement is less than the Lifetime value sent in the Binding Update being acknowledged, then the mobile node MUST subtract the difference between these two Lifetime values from the remaining lifetime for the binding as maintained in the corresponding Binding Update List entry (with a minimum value for the Binding Update List entry lifetime of 0). That is, if the Lifetime value sent in the Binding Update was L_update, the Lifetime value received in the Binding Acknowledgement was L_ack, and the current remaining lifetime of the Binding Update List entry is L_remain, then the new value for the remaining lifetime of the Binding Update List entry should be max((L_remain - (L_update - L_ack)), 0) where max(X, Y) is the maximum of X and Y. The effect of this step is to correctly manage the mobile node's view of the binding's remaining lifetime (as maintained in the corresponding Binding Update List entry) so that it correctly counts down from the Lifetime value given in the Binding Acknowledgement, but with the timer countdown beginning at the time that the Binding Update was sent. Mobile nodes SHOULD send a new Binding Update well before the expiration of this period in order to extend the lifetime. This helps to avoid disruptions in communications, which might otherwise be caused by network delays or clock drift. o Additionally, if the Status field value is 1 (Accepted but prefix discovery necessary), the mobile node SHOULD send a Mobile Prefix Solicitation message to update its information about the available prefixes. o If the Status field indicates that the Binding Update was rejected (the Status field is greater than or equal to 128), then the mobile node can take steps to correct the cause of the error and retransmit the Binding Update (with a new Sequence Number value), subject to the rate limiting restriction specified in Section 11.8. If this is not done, or it fails, then the mobile node SHOULD record in its Binding Update List that future Binding Updates SHOULD NOT be sent to this destination.