Correspondent Registration

When the mobile node is assured that its home address is valid, it can initiate a correspondent registration with the purpose of allowing the correspondent node to cache the mobile node’s current care-of address. This procedure consists of the return routability procedure followed by a registration.

This section defines when the correspondent registration is to be initiated and the rules to follow while it is being performed.

After the mobile node has sent a Binding Update to its home agent, registering a new primary care-of address (as described in

Section 11.7.1), the mobile node SHOULD initiate a correspondent registration for each node that already appears in the mobile node’s Binding Update List. The initiated procedures can be used to either update or delete binding information in the correspondent node.

For nodes that do not appear in the mobile node’s Binding Update List, the mobile node MAY initiate a correspondent registration at any time after sending the Binding Update to its home agent.

Considerations regarding when (and if) to initiate the procedure depend on the specific movement and traffic patterns of the mobile node and are outside the scope of this document.

In addition, the mobile node MAY initiate the correspondent

registration in response to receiving a packet that meets all of the following tests:

o The packet was tunneled using IPv6 encapsulation.

o The Destination Address in the tunnel (outer) IPv6 header is equal to any of the mobile node’s care-of addresses.

o The Destination Address in the original (inner) IPv6 header is equal to one of the mobile node’s home addresses.

o The Source Address in the tunnel (outer) IPv6 header differs from the Source Address in the original (inner) IPv6 header.

o The packet does not contain a Home Test, Home Test Init, Care-of Test, or Care-of Test Init message.

If a mobile node has multiple home addresses, it becomes important to select the right home address to use in the correspondent

registration. The used home address MUST be the Destination Address of the original (inner) packet.

The peer address used in the procedure MUST be determined as follows:

o If a Home Address destination option is present in the original (inner) packet, the address from this option is used.

o Otherwise, the Source Address in the original (inner) IPv6 header of the packet is used.

Note that the validity of the original packet is checked before attempting to initiate a correspondent registration. For instance, if a Home Address destination option appeared in the original packet, then rules in Section 9.3.1 are followed.

A mobile node MAY also choose to keep its topological location

private from certain correspondent nodes, and thus need not initiate the correspondent registration.

Upon successfully completing the return routability procedure, and after receiving a successful Binding Acknowledgement from the home agent, a Binding Update MAY be sent to the correspondent node.

In any Binding Update sent by a mobile node, the care-of address (either the Source Address in the packet’s IPv6 header or the Care-of Address in the Alternate Care-of Address mobility option of the

Binding Update) MUST be set to one of the care-of addresses currently

in use by the mobile node or to the mobile node’s home address. A mobile node MAY set the care-of address differently for sending Binding Updates to different correspondent nodes.

A mobile node MAY also send a Binding Update to such a correspondent node, instructing it to delete any existing binding for the mobile node from its Binding Cache, as described in Section 6.1.7. Even in this case a successful completion of the return routability procedure is required first.

If the care-of address is not set to the mobile node’s home address, the Binding Update requests that the correspondent node create or update an entry for the mobile node in the correspondent node’s

Binding Cache. This is done in order to record a care-of address for use in sending future packets to the mobile node. In this case, the value specified in the Lifetime field sent in the Binding Update SHOULD be less than or equal to the remaining lifetime of the home registration and the care-of address specified for the binding. The care-of address given in the Binding Update MAY differ from the mobile node’s primary care-of address.

If the Binding Update is sent to the correspondent node, requesting the deletion of any existing Binding Cache entry it has for the mobile node, the care-of address is set to the mobile node’s home address and the Lifetime field set to zero. In this case, generation of the binding management key depends exclusively on the home keygen token (Section 5.2.5). The care-of nonce index SHOULD be set to zero in this case. In keeping with the Binding Update creation rules below, the care-of address MUST be set to the home address if the mobile node is at home, or to the current care-of address if it is away from home.

If the mobile node wants to ensure that its new care-of address has been entered into a correspondent node’s Binding Cache, the mobile node needs to request an acknowledgement by setting the Acknowledge (A) bit in the Binding Update.

A Binding Update is created as follows:

o The current care-of address of the mobile node MUST be sent either in the Source Address of the IPv6 header or in the Alternate

Care-of Address mobility option.

o The Destination Address of the IPv6 header MUST contain the address of the correspondent node.

o The Mobility Header is constructed according to rules in Sections 6.1.7 and 5.2.6, including the Binding Authorization Data

(calculated as defined in Section 6.2.7) and possibly the Nonce Indices mobility options.

o The home address of the mobile node MUST be added to the packet in a Home Address destination option, unless the Source Address is the home address.

Each Binding Update MUST have a Sequence Number greater than the Sequence Number value sent in the previous Binding Update to the same destination address (if any). The sequence numbers are compared modulo 2**16, as described in Section 9.5.1. There is no

requirement, however, that the Sequence Number value strictly

increase by 1 with each new Binding Update sent or received, as long as the value stays within the window. The last Sequence Number value sent to a destination in a Binding Update is stored by the mobile node in its Binding Update List entry for that destination. If the sending mobile node has no Binding Update List entry, the Sequence Number SHOULD start at a random value. The mobile node MUST NOT use the same Sequence Number in two different Binding Updates to the same correspondent node, even if the Binding Updates provide different care-of addresses.

The mobile node is responsible for the completion of the

correspondent registration, as well as any retransmissions that may be needed (subject to the rate limitation defined in Section 11.8).