HA_2_1_3 - Receiving valid BU A=0
Router
NUT
|
--------+-------+-------+------- Link0
| |
R0 MN0
|
--------+-------+------- Link0X
|
MN0X
Link0 global 3ffe:501:ffff:100::/64 home link Link0X global 3ffe:501:ffff:1100::/64 foreign link R0 (Link0) global 3ffe:501:ffff:100::a0a0 ether 00:00:00:00:a0:a0 MN0 global 3ffe:501:ffff:100:200:ff:fe00:a2a2 home address MN0X global 3ffe:501:ffff:1100:200:ff:fe00:a2a2 care-of address
Check Link0 routing tableNUT (Link0) MN0X | | | <---- | Echo Request | ----> | Echo Reply | |
1. MN0X sends Echo Request 2. MN0X receives Echo Reply
Check home registrationNUT (Link0) MN0X | | | <---- | BU (A=1, lifetime=0x0010) (SPI=0x101) | ----> | BA (SPI=0x102) (*1) | |
1. MN0X sends BU packet format is: Binding_Update_message_format_from_MN_to_HA_ESP.gif 2. MN0X receives BA (*1) packet format is: Binding_Acknowledgement_message_format_from_HA_toMN_ESP.gifCheck BCENUT (Link0) MN0X | | | <---- | Echo Request w/ HaO | ----> | Echo Reply w/ RH (*2) | |
1. MN0X sends Echo Request w/ HaO 2. MN0X receives Echo Reply w/ RH (*2)
(*1) PASS: MN0X receives BA (*2) PASS: MN0X receives Echo Reply w/ RH
10.4.2 Processing Intercepted PacketsThe lifetime of the Binding Cache entry depends on a number of factors:o The lifetime for the Binding Cache entry MUST NOT be greater than the Lifetime value specified in the Binding Update.o The lifetime for the Binding Cache entry MUST NOT be greater than the remaining valid lifetime for the subnet prefix in the mobile node's home address specified with the Binding Update. The remaining valid lifetime for this prefix is determined by the home agent based on its own Prefix List entry for this prefix [12].The remaining preferred lifetime SHOULD NOT have any impact on the lifetime for the binding cache entry.The home agent MUST remove a binding when the valid lifetime of the prefix associated with it expires.o The home agent MAY further decrease the specified lifetime for the binding, for example based on a local policy. The resulting lifetime is stored by the home agent in the Binding Cache entry, and this Binding Cache entry MUST be deleted by the home agent after the expiration of this lifetime.Regardless of the setting of the Acknowledge (A) bit in the Binding Update, the home agent MUST return a Binding Acknowledgement to the mobile node, constructed as follows:o The Status field MUST be set to a value indicating success. The value 1 (accepted but prefix discovery necessary) MUST be used if the subnet prefix of the specified home address is deprecated, becomes deprecated during the lifetime of the binding, or becomes invalid at the end of the lifetime. The value 0 MUST be used otherwise. For the purposes of comparing the binding and prefix lifetimes, the prefix lifetimes are first converted into units of four seconds by ignoring the two least significant bits.o The Key Management Mobility Capability (K) bit is set if the following conditions are all fulfilled, and cleared otherwise:* The Key Management Mobility Capability (K) bit was set in the Binding Update.* The IPsec security associations between the mobile node and the home agent have been established dynamically.* The home agent has the capability to update its endpoint in the used key management protocol to the new care-of address every time it movesDepending on the final value of the bit in the Binding Acknowledgement, the home agent SHOULD perform the following actions:K = 0Discard key management connections, if any, to the old care-of address. If the mobile node did not have a binding before sending this Binding Update, discard the connections to the home address.K = 1Move the peer endpoint of the key management protocol connection, if any, to the new care-of address. For an IKE phase 1 connection, this means that any IKE packets sent to the peer are sent to this address, and packets from this address with the original ISAKMP cookies are accepted.Note that Section 2.5.3 in RFC 2408 [8] Section 2.5.3 states three specifies rules that ISAKMP cookies must satisfy: they must depend on specific parties and they can only have been generated by the entity itself. Then it recommends a particular way to do this, namely a hash of IP addresses. With the K bit set to 1, the recommended implementation technique does not work directly. To satisfy the two rules, the specific parties must be treated as the original IP addresses, not the ones in use at the specific moment.o The Sequence Number field MUST be copied from the Sequence Number given in the Binding Update.o The Lifetime field MUST be set to the remaining lifetime for the binding as set by the home agent in its home registration Binding Cache entry for the mobile node, as described above.o If the home agent stores the Binding Cache entry in nonvolatile storage, then the Binding Refresh Advice mobility option MUST be omitted. Otherwise, the home agent MAY include this option to suggest that the mobile node refreshes its binding sooner than the actual lifetime of the binding ends.If the Binding Refresh Advice mobility option is present, the Refresh Interval field in the option MUST be set to a value less than the Lifetime value being returned in the Binding Acknowledgement. This indicates that the mobile node SHOULD attempt to refresh its home registration at the indicated shorter interval. The home agent MUST still retain the registration for the Lifetime period, even if the mobile node does not refresh its registration within the Refresh period.
For any packet sent to a mobile node from the mobile node's home agent (for which the home agent is the original sender of the packet), the home agent is operating as a correspondent node of the mobile node for this packet and the procedures described in Section 9.3.2 apply. The home agent then uses a routing header to route the packet to the mobile node by way of the primary care-of address in the home agent's Binding Cache.