Correspondent Registration
There are two ways in which mobile nodes that are away from home can communicate with correspondent nodes:
- Directly:
If the correspondent node is Mobile IPv6-capable, data can be sent directly between the mobile node and the correspondent node. The mobile node sends data directly to the correspondent node using the correspondent node's address and includes the Home Address destination option to indicate its home address. The correspondent node sends data directly to the mobile node's care-of address and includes the Type 2 Routing header to indicate the mobile node's home address. The direct method of data delivery is referred to in RFC 3775 as route optimization. - Indirectly:
If the correspondent node is not Mobile IPv6-capable or the registration of the binding for the mobile node with the correspondent node that is Mobile IPv6- capable has not yet been completed, data can be sent indirectly between the mobile node and the correspondent node via the home agent.
For traffic from the mobile node to the correspondent node, packets are tunneled to the home agent. The mobile node encapsulates the IPv6 packet sent from the mobile node's home address and to the correspondent node's address with an additional IPv6 header, the source address of the mobile node's care-of address, and the destination address of the home agent's global address. After receiving the packet, the home agent strips the outer IPv6 header and forwards the original IPv6 packet to the correspondent node.
For traffic from the correspondent node to the mobile node, the correspondent node sends the packet to the mobile node's home address. When the home agent intercepts the packet, it is encapsulated with an additional IPv6 header containing the source address of the home agent's address, and the destination address of the mobile node's care-of address.
Indirect delivery via the home agent, although inefficient, allows communication between mobile nodes and correspondent nodes that are not Mobile IPv6-capable.
The indirect method of data delivery is referred to in RFC 3775 as bidirectional tunneling.
For direct delivery to occur, the correspondent node with which the mobile node is communicating must be Mobile IPv6-capable and must have a binding cache entry that maps the mobile node's home address to its care-of address. Correspondent nodes that receive packets that contain a Home Address option in a Destination Options header must have a corresponding binding cache entry; otherwise, the packet is silently discarded. This behavior provides some protection against malicious users or programs that attempt to impersonate mobile nodes that are away from home.
The process of creating a binding cache entry on the correspondent node and a binding update list entry on the mobile node is known as correspondent registration and consists of the following:
- Return Routability procedure:
The Return Routability procedure establishes proof to the correspondent node that the mobile node is reachable at both its home address (using the indirect path) and its care-of address (using the direct path). It also determines tokens that are used to derive a binding management key, which is used to calculate authorization data values for binding messages. - Binding Update and Binding Acknowledgement message exchange:
The Binding Update and Binding Acknowledgement message exchange uses the binding management key to prove that the messages were sent from the nodes that participated in the Return Routability procedure. For the binding update, the correspondent node verifies the included authorization data, updates its binding cache with an entry for the mobile node, and typically returns a Binding Acknowledgement message, which also contains authorization data calculated using the binding management key.
The result of the correspondent registration is the following:
- On the mobile node, there is an entry in its binding update list for the correspondent node.
- On the correspondent node, there is an entry in its binding cache for the mobile node.
The binding management key can be used for subsequent binding maintenance as long as the mobile node's home address or care-of address does not change. When they do, the Return Routability procedure is performed again to ensure that the mobile node is reachable at its new addresses.
Return Routability Procedure
Figure below shows the Return Routability procedure.
The full Return Routability process is the following:
- The mobile node sends a Home Test Init (HoTI) message indirectly to the correspondent node, tunneling the message through the home agent.
- The mobile node sends a Care-of Test Init (CoTI) message directly to the correspondent node.
- The correspondent node sends a Home Test (HoT) message in response to the HoTI message (sent indirectly to the mobile node via the home agent).
- The correspondent node sends a Care-of Test (CoT) message in response to the CoTI message (sent directly to the mobile node).
The correspondent node responds to the HoTI and CoTI messages as they arrive, independently of each other. The messages can arrive in any order. The correspondent node does not store any state information after responding to the HoTI or CoTI message.
The HoT message is sent to the mobile node's home address. To provide security for the HoTI and HoT messages in the path from the home agent to the mobile node, the home agent can use Internet Protocol security (IPsec) Encapsulating Security Payload (ESP) tunnel mode to provide data confidentiality, data origin authentication, and data integrity for the HoT message.
From the tokens in the HoT and CoT messages, the mobile node can derive a binding management key. From information in the Binding Update message, the correspondent node can derive the same binding management key and use it to verify authentication data stored in the Binding Update message.
Note:
The Return Routability procedure is designed to verify that the mobile node is reachable at both its home address and its care-of address. The home address must be verified to prevent spoofing of binding updates. The care-of address must be verified to protect against denial-of-service attacks in which the correspondent node is tricked to flood a false care-of address with packets.
The binding management key is derived from two separate token values: one value in the HoT message, and one in the CoT message. The purpose of the HoT message is to verify that the mobile node is reachable at its home address. An attacker can learn the home address token in the HoT message only if it has access to the path from the correspondent node to the home agent. The purpose of the CoT message, on the other hand, is to verify that the mobile node is reachable at the care-of address. To learn the care-of address token in the CoT message, the attacker must have access to either the care-of address or the path from the correspondent node to the mobile node. If an attacker cannot capture both tokens, it cannot calculate the binding management key.
Detecting Correspondent Nodes That Are Not Mobile IPv6-Capable
If a correspondent node is not Mobile IPv6-capable, it will not recognize mobility messages, specifically the HoTI and CoTI messages sent by the mobile node that use the new Mobility header. Because the correspondent node does not recognize the new Mobility header, it responds with an ICMPv6 Bad Parameter-Unrecognized Next Header Type Encountered (ICMPv6 Type 4, Code 1) message. Upon receipt of the ICMPv6 message, the mobile node records the correspondent node's lack of support for Mobile IPv6 in its corresponding entry in the binding update list. Subsequent packets sent to the correspondent node are always tunneled via the home agent. Depending on the Mobile IPv6 implementation, the mobile node might periodically retry the Return Routability procedure to test for the correspondent node's current support for Mobile IPv6.
