| 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 - none 2. Position of Mobile Node 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. 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)
HA0 NUTX R1 R2 CN0 | | | | | | | <---- | | | 1.Router Advertisement | | | | | | NUTY | | | | | | | | | | <------------ | | 2.Router Advertisement | | | | | | | ----> | | | 3.Neighbor Solicitations | | | | | 4.(no reply:3 seconds) | | | | | | <---- | | | | 5.Binding Update(*1) | | | | | 1. Send Router Advertisement. (R1 -> R1_allnode_multi) 2. Send Router Advertisement. (R2 -> R2_allnode_multi) 3. Receive Neighbor Solicitations. (NUTX -> R1) 4. (no reply) # Wait during a maximum of 3 seconds(RFC2461). 5. Receive Binding Update. (NUTY -> HA0) Packet Format is: 5. Binding Update
(*1) PASS: HA0 receives Binding Update message, Then, check whether this packet fills all of the following, - The Sequence Number is set more than that in the previous Binding Update. - The Alternate Care-of Address mobility option is included, and, - The Care-of Address fiels is set to the care-of address.
(draft-ietf-mobileip-ipv6-24.txt) 11.7.1 Sending Binding Updates to the Home Agent After deciding to change its primary care-of address as described in Section 11.5.1 and Section 11.5.2, a mobile node MUST register this care-of address with its home agent in order to make this its primary care-of address. (snip) To register a care-of address or to extend the lifetime of an existing registration, the mobile node sends a packet to its home agent containing a Binding Update, with the packet constructed as follows: o The Home Registration (H) bit MUST be set in the Binding Update. o The Acknowledge (A) bit MUST be set in the Binding Update. o The packet MUST contain a Home Address destination option, giving the mobile node's home address for the binding. o The care-of address for the binding MUST be used as the Source Address in the packet's IPv6 header, unless an Alternate Care-of Address mobility option is included in the Binding Update. This option MUST be included in all home registrations, as the ESP protocol will not be able to protect care-of addresses in the IPv6 header. (Mobile IPv6 implementations that know they are using IPsec AH to protect a particular message might avoid this option. For brevity the usage of AH is not discussed in this document.) o If the mobile node's link-local address has the same interface identifier as the home address for which it is supplying a new care-of address, then the mobile node SHOULD set the Link-Local Address Compatibility (L) bit. o If the home address was generated using RFC 3041 , then the link local address is unlikely to have a compatible interface identifier. In this case, the mobile node MUST clear the Link-Local Address Compatibility (L) bit. o If the IPsec security associations between the mobile node and the home agent have been established dynamically, and the mobile node has the capability to update its endpoint in the used key management protocol to the new care-of address every time it moves, the mobile node SHOULD set the Key Management Mobility Capability (K) bit in the Binding Update. Otherwise, the mobile node MUST clear the bit. o The value specified in the Lifetime field SHOULD be less than or equal to the remaining valid lifetime of the home address and the care-of address specified for the binding. Mobile nodes that use dynamic home agent address discovery should be careful with long lifetimes. If the mobile node loses the knowledge of its binding with a specific home agent, registering a new binding with another home agent may be impossible as the previous home agent is still defending the existing binding. Therefore, mobile nodes that use home agent address discovery SHOULD ensure information about their bindings is not lost, de-register before losing this information, or use small lifetimes. 11.1 Conceptual Data Structures (snip) Each Binding Update List entry conceptually contains the following fields: o The IP address of the node to which a Binding Update was sent. o The home address for which that Binding Update was sent. o The care-of address sent in that Binding Update. This value is necessary for the mobile node to determine if it has sent a Binding Update giving its new care-of address to this destination after changing its care-of address. o The initial value of the Lifetime field sent in that Binding Update. o The remaining lifetime of that binding. This lifetime is initialized from the Lifetime value sent in the Binding Update and is decremented until it reaches zero, at which time this entry MUST be deleted from the Binding Update List. o The maximum value of the Sequence Number field sent in previous Binding Updates to this destination. The Sequence Number field is 16 bits long, and all comparisons between Sequence Number values MUST be performed modulo 2**16 (see Section 9.5.1). o The time at which a Binding Update was last sent to this destination, as needed to implement the rate limiting restriction for sending Binding Updates. o The state of any retransmissions needed for this Binding Update. This state includes the time remaining until the next retransmission attempt for the Binding Update, and the current state of the exponential back-off mechanism for retransmissions. o A flag specifying whether or not future Binding Updates should be sent to this destination. The mobile node sets this flag in the Binding Update List entry when it receives an ICMP Parameter Problem, Code 1, error message in response to a return routability message or Binding Update sent to that destination, as described in Section 11.3.5.