| 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 - Route Optimization support : YES - IPsec support between MN and CN : YES 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.ICMP Echo Request | | | | | | <==== | ---------------------> | 2.Home Test Init | | ---------------------> | 3.Care-of Test Init | | <--------------------- | 4.Care-of Test | ====> | <--------------------- | 5.Home Test | | | | | | <==== | ---------------------> | 6.ICMP Echo Reply | | ---------------------> | 7.Binding Update | | ---------------------> | 8.ICMP Echo Reply | | | | | | | <--------------------- | 9.ICMP Echo Request | | ---------------------> | 10.ICMP Echo Reply (*1) | | | | | 1. Send ICMP Echo Request. (out: HA0 -> NUTX, in: CN0 -> NUT0) # The ESP Header is included in the inner packet. 2. Receive Home Test Init. (out: NUTX -> HA0, in: NUT0 -> CN0) 3. Receive Care-of Test Init. (NUTX -> CN0) 4. Send Care-of Test. (CN0 -> NUTX) 5. Send Home Test. (out: HA0 -> NUTX, in: CN0 -> NUT0) 6. Receive reverse tunneled ICMP Echo Reply or . (out: NUTX -> HA0, in: NUT0 -> CN0) # The ESP Header is included in the inner packet. 7. Receive Binding Update to CN0. (NUTX -> CN0) 8.  or Receive ICMP Echo Reply. (NUTX -> CN0) # The ESP Header is included. # Home Address destination option is included. 9. Send ICMP Echo Request. (CN0 -> NUTX) # The ESP Header is included. # Type2 Routing Header is included. 10. Receive ICMP Echo Reply. (NUTX -> CN0) # The ESP Header is included. # Home Address destination option is included.
(*1) PASS: CN0 receives ICMP Echo Reply. Then, check whether this packet fills all of the following, - The ESP Header is included.
(draft-ietf-mobileip-ipv6-24.txt) 11.3.2 Interaction with Outbound IPsec Processing This section sketches the interaction between outbound Mobile IPv6 processing and outbound IP Security (IPsec) processing for packets sent by a mobile node while away from home. Any specific implementation MAY use algorithms and data structures other than those suggested here, but its processing MUST be consistent with the effect of the operation described here and with the relevant IPsec specifications. In the steps described below, it is assumed that IPsec is being used in transport mode  and that the mobile node is using its home address as the source for the packet (from the point of view of higher protocol layers or applications, as described in Section 11.3.1): o The packet is created by higher layer protocols and applications (e.g., by TCP) as if the mobile node were at home and Mobile IPv6 were not being used. o Determine the outgoing interface for the packet. (Note that the selection between reverse tunneling and route optimization may imply different interfaces, particularly if tunnels are considered interfaces as well.) o As part of outbound packet processing in IP, the packet is compared against the IPsec security policy database to determine what processing is required for the packet . o If IPsec processing is required, the packet is either mapped to an existing Security Association (or SA bundle), or a new SA (or SA bundle) is created for the packet, according to the procedures defined for IPsec. o Since the mobile node is away from home, the mobile is either using reverse tunneling or route optimization to reach the correspondent node. If reverse tunneling is used, the packet is constructed in the normal manner and then tunneled through the home agent. If route optimization is in use, the mobile node inserts a Home Address destination option into the packet, replacing the Source Address in the packet's IP header with the care-of address used with this correspondent node, as described in Section 11.3.1. The Destination Options header in which the Home Address destination option is inserted MUST appear in the packet after the routing header, if present, and before the IPsec (AH  or ESP ) header, so that the Home Address destination option is processed by the destination node before the IPsec header is processed. Finally, once the packet is fully assembled, the necessary IPsec authentication (and encryption, if required) processing is performed on the packet, initializing the Authentication Data in the IPsec header. RFC 2402 treatment of destination options is extended as follows. The AH authentication data MUST be calculated as if the following were true: * the IPv6 source address in the IPv6 header contains the mobile node's home address, * the Home Address field of the Home Address destination option (Section 6.3) contains the new care-of address. o This allows, but does not require, the receiver of the packet containing a Home Address destination option to exchange the two fields of the incoming packet to reach the above situation, simplifying processing for all subsequent packet headers. However, such an exchange is not required, as long as the result of the authentication calculation remains the same. When an automated key management protocol is used to create new security associations for a peer, it is important to ensure that the peer can send the key management protocol packets to the mobile node. This may not be possible if the peer is the home agent of the mobile node, and the purpose of the security associations would be to send a Binding Update to the home agent. Packets addressed to the home address of the mobile node cannot be used before the Binding Update has been processed. For the default case of using IKE  as the automated key management protocol, such problems can be avoided by the following requirements when communicating with its home agent: o When the mobile node is away from home, it MUST use its care-of address as the Source Address of all packets it sends as part of the key management protocol (without use of Mobile IPv6 for these packets, as suggested in Section 11.3.1). o In addition, for all security associations bound to the mobile node's home address established by IKE, the mobile node MUST include an ISAKMP Identification Payload  in the IKE exchange, giving the mobile node's home address as the initiator of the Security Association . The Key Management Mobility Capability (K) bit in Binding Updates and Acknowledgements can be used avoid the need to rerun IKE upon movements.