RFC 3775
Mobility Support in IPv6
8. Requirements for Types of IPv6 Nodes
Mobile IPv6 places some special requirements on the functions provided by different types of IPv6 nodes. This section summarizes those requirements, identifying the functionality each requirement is intended to support. The requirements are set for the following groups of nodes: o All IPv6 nodes. o All IPv6 nodes with support for route optimization. o All IPv6 routers. o All Mobile IPv6 home agents. o All Mobile IPv6 mobile nodes. It is outside the scope of this specification to specify which of these groups are mandatory in IPv6. We only describe what is mandatory for a node that supports, for instance, route optimization. Other specifications are expected to define the extent of IPv6.8.1. All IPv6 Nodes
Any IPv6 node may at any time be a correspondent node of a mobile node, either sending a packet to a mobile node or receiving a packet from a mobile node. There are no Mobile IPv6 specific MUST requirements for such nodes, and basic IPv6 techniques are sufficient. If a mobile node attempts to set up route optimization with a node with only basic IPv6 support, an ICMP error will signal that the node does not support such optimizations (Section 11.3.5), and communications will flow through the home agent. An IPv6 node MUST NOT support the Home Address destination option, type 2 routing header, or the Mobility Header unless it fully supports the requirements listed in the next sections for either route optimization, mobile node, or home agent functionality.8.2. IPv6 Nodes with Support for Route Optimization
Nodes that implement route optimization are a subset of all IPv6 nodes on the Internet. The ability of a correspondent node to participate in route optimization is essential for the efficient operation of the IPv6 Internet, for the following reasons:
o Avoidance of congestion in the home network, and enabling the use
of lower-performance home agent equipment even for supporting
thousands of mobile nodes.
o Reduced network load across the entire Internet, as mobile devices
begin to predominate.
o Reduction of jitter and latency for the communications.
o Greater likelihood of success for QoS signaling as tunneling is
avoided and, again, fewer sources of congestion.
o Improved robustness against network partitions, congestion, and
other problems, since fewer routing path segments are traversed.
These effects combine to enable much better performance and
robustness for communications between mobile nodes and IPv6
correspondent nodes. Route optimization introduces a small amount of
additional state for the peers, some additional messaging, and up to
1.5 roundtrip delays before it can be turned on. However, it is
believed that the benefits far outweigh the costs in most cases.
Section 11.3.1 discusses how mobile nodes may avoid route
optimization for some of the remaining cases, such as very short-term
communications.
The following requirements apply to all correspondent nodes that
support route optimization:
o The node MUST be able to validate a Home Address option using an
existing Binding Cache entry, as described in Section 9.3.1.
o The node MUST be able to insert a type 2 routing header into
packets to be sent to a mobile node, as described in Section
9.3.2.
o Unless the correspondent node is also acting as a mobile node, it
MUST ignore type 2 routing headers and silently discard all
packets that it has received with such headers.
o The node SHOULD be able to interpret ICMP messages as described in
Section 9.3.4.
o The node MUST be able to send Binding Error messages as described
in Section 9.3.3.
o The node MUST be able to process Mobility Headers as described in
Section 9.2.
o The node MUST be able to participate in a return routability
procedure (Section 9.4).
o The node MUST be able to process Binding Update messages (Section
9.5).
o The node MUST be able to return a Binding Acknowledgement (Section
9.5.4).
o The node MUST be able to maintain a Binding Cache of the bindings
received in accepted Binding Updates, as described in Section 9.1
and Section 9.6.
o The node SHOULD allow route optimization to be administratively
enabled or disabled. The default SHOULD be enabled.
8.3. All IPv6 Routers
All IPv6 routers, even those not serving as a home agent for Mobile
IPv6, have an effect on how well mobile nodes can communicate:
o Every IPv6 router SHOULD be able to send an Advertisement Interval
option (Section 7.3) in each of its Router Advertisements [12], to
aid movement detection by mobile nodes (as in Section 11.5.1).
The use of this option in Router Advertisements SHOULD be
configurable.
o Every IPv6 router SHOULD be able to support sending unsolicited
multicast Router Advertisements at the faster rate described in
Section 7.5. If the router supports a faster rate, the used rate
MUST be configurable.
o Each router SHOULD include at least one prefix with the Router
Address (R) bit set and with its full IP address in its Router
Advertisements (as described in Section 7.2).
o Routers supporting filtering packets with routing headers SHOULD
support different rules for type 0 and type 2 routing headers (see
Section 6.4) so that filtering of source routed packets (type 0)
will not necessarily limit Mobile IPv6 traffic which is delivered
via type 2 routing headers.
8.4. IPv6 Home Agents
In order for a mobile node to operate correctly while away from home,
at least one IPv6 router on the mobile node's home link must function
as a home agent for the mobile node. The following additional
requirements apply to all IPv6 routers that serve as a home agent:
o Every home agent MUST be able to maintain an entry in its Binding
Cache for each mobile node for which it is serving as the home
agent (Section 10.1 and Section 10.3.1).
o Every home agent MUST be able to intercept packets (using proxy
Neighbor Discovery [12]) addressed to a mobile node for which it
is currently serving as the home agent, on that mobile node's home
link, while the mobile node is away from home (Section 10.4.1).
o Every home agent MUST be able to encapsulate [15] such intercepted
packets in order to tunnel them to the primary care-of address for
the mobile node indicated in its binding in the home agent's
Binding Cache (Section 10.4.2).
o Every home agent MUST support decapsulating [15] reverse tunneled
packets sent to it from a mobile node's home address. Every home
agent MUST also check that the source address in the tunneled
packets corresponds to the currently registered location of the
mobile node (Section 10.4.5).
o The node MUST be able to process Mobility Headers as described in
Section 10.2.
o Every home agent MUST be able to return a Binding Acknowledgement
in response to a Binding Update (Section 10.3.1).
o Every home agent MUST maintain a separate Home Agents List for
each link on which it is serving as a home agent, as described in
Section 10.1 and Section 10.5.1.
o Every home agent MUST be able to accept packets addressed to the
Mobile IPv6 Home-Agents anycast address [16] for the subnet on
which it is serving as a home agent, and MUST be able to
participate in dynamic home agent address discovery (Section
10.5).
o Every home agent SHOULD support a configuration mechanism to allow
a system administrator to manually set the value to be sent by
this home agent in the Home Agent Preference field of the Home
Agent Information Option in Router Advertisements that it sends
(Section 7.4).
o Every home agent SHOULD support sending ICMP Mobile Prefix
Advertisements (Section 6.8), and SHOULD respond to Mobile Prefix
Solicitations (Section 6.7). If supported, this behavior MUST be
configurable, so that home agents can be configured to avoid
sending such Prefix Advertisements according to the needs of the
network administration in the home domain.
o Every home agent MUST support IPsec ESP for protection of packets
belonging to the return routability procedure (Section 10.4.6).
o Every home agent SHOULD support the multicast group membership
control protocols as described in Section 10.4.3. If this support
is provided, the home agent MUST be capable of using it to
determine which multicast data packets to forward via the tunnel
to the mobile node.
o Home agents MAY support stateful address autoconfiguration for
mobile nodes as described in Section 10.4.4.
8.5. IPv6 Mobile Nodes
Finally, the following requirements apply to all IPv6 nodes capable
of functioning as mobile nodes:
o The node MUST maintain a Binding Update List (Section 11.1).
o The node MUST support sending packets containing a Home Address
option (Section 11.3.1), and follow the required IPsec interaction
(Section 11.3.2).
o The node MUST be able to perform IPv6 encapsulation and
decapsulation [15].
o The node MUST be able to process type 2 routing header as defined
in Section 6.4 and Section 11.3.3.
o The node MUST support receiving a Binding Error message (Section
11.3.6).
o The node MUST support receiving ICMP errors (Section 11.3.5).
o The node MUST support movement detection, care-of address
formation, and returning home (Section 11.5).
o The node MUST be able to process Mobility Headers as described in
Section 11.2.
o The node MUST support the return routability procedure (Section
11.6).
o The node MUST be able to send Binding Updates, as specified in
Section 11.7.1 and Section 11.7.2.
o The node MUST be able to receive and process Binding
Acknowledgements, as specified in Section 11.7.3.
o The node MUST support receiving a Binding Refresh Request (Section
6.1.2), by responding with a Binding Update.
o The node MUST support receiving Mobile Prefix Advertisements
(Section 11.4.3) and reconfiguring its home address based on the
prefix information contained therein.
o The node SHOULD support use of the dynamic home agent address
discovery mechanism, as described in Section 11.4.1.
o The node MUST allow route optimization to be administratively
enabled or disabled. The default SHOULD be enabled.
o The node MAY support the multicast address listener part of a
multicast group membership protocol as described in Section
11.3.4. If this support is provided, the mobile node MUST be able
to receive tunneled multicast packets from the home agent.
o The node MAY support stateful address autoconfiguration mechanisms
such as DHCPv6 [29] on the interface represented by the tunnel to
the home agent.
9. Correspondent Node Operation
9.1. Conceptual Data Structures
IPv6 nodes with route optimization support maintain a Binding Cache
of bindings for other nodes. A separate Binding Cache SHOULD be
maintained by each IPv6 node for each of its unicast routable
addresses. The Binding Cache MAY be implemented in any manner
consistent with the external behavior described in this document, for
example by being combined with the node's Destination Cache as
maintained by Neighbor Discovery [12]. When sending a packet, the
Binding Cache is searched before the Neighbor Discovery conceptual
Destination Cache [12].
Each Binding Cache entry conceptually contains the following fields:
o The home address of the mobile node for which this is the Binding
Cache entry. This field is used as the key for searching the
Binding Cache for the destination address of a packet being sent.
o The care-of address for the mobile node indicated by the home
address field in this Binding Cache entry.
o A lifetime value, indicating the remaining lifetime for this
Binding Cache entry. The lifetime value is initialized from the
Lifetime field in the Binding Update that created or last modified
this Binding Cache entry.
o A flag indicating whether or not this Binding Cache entry is a
home registration entry (applicable only on nodes which support
home agent functionality).
o The maximum value of the Sequence Number field received in
previous Binding Updates for this home address. The Sequence
Number field is 16 bits long. Sequence Number values MUST be
compared modulo 2**16 as explained in Section 9.5.1.
o Usage information for this Binding Cache entry. This is needed to
implement the cache replacement policy in use in the Binding
Cache. Recent use of a cache entry also serves as an indication
that a Binding Refresh Request should be sent when the lifetime of
this entry nears expiration.
Binding Cache entries not marked as home registrations MAY be
replaced at any time by any reasonable local cache replacement policy
but SHOULD NOT be unnecessarily deleted. The Binding Cache for any
one of a node's IPv6 addresses may contain at most one entry for each
mobile node home address. The contents of a node's Binding Cache
MUST NOT be changed in response to a Home Address option in a
received packet.
9.2. Processing Mobility Headers
Mobility Header processing MUST observe the following rules:
o The checksum must be verified as per Section 6.1. Otherwise, the
node MUST silently discard the message.
o The MH Type field MUST have a known value (Section 6.1.1).
Otherwise, the node MUST discard the message and issue a Binding
Error message as described in Section 9.3.3, with Status field set
to 2 (unrecognized MH Type value).
o The Payload Proto field MUST be IPPROTO_NONE (59 decimal).
Otherwise, the node MUST discard the message and SHOULD send ICMP
Parameter Problem, Code 0, directly to the Source Address of the
packet as specified in RFC 2463 [14]. Thus no Binding Cache
information is used in sending the ICMP message. The Pointer
field in the ICMP message SHOULD point at the Payload Proto field.
o The Header Len field in the Mobility Header MUST NOT be less than
the length specified for this particular type of message in
Section 6.1. Otherwise, the node MUST discard the message and
SHOULD send ICMP Parameter Problem, Code 0, directly to the Source
Address of the packet as specified in RFC 2463 [14]. (The Binding
Cache information is again not used.) The Pointer field in the
ICMP message SHOULD point at the Header Len field.
Subsequent checks depend on the particular Mobility Header.
9.3. Packet Processing
This section describes how the correspondent node sends packets to
the mobile node, and receives packets from it.
9.3.1. Receiving Packets with Home Address Option
Packets containing a Home Address option MUST be dropped if the given
home address is not a unicast routable address.
Mobile nodes can include a Home Address destination option in a
packet if they believe the correspondent node has a Binding Cache
entry for the home address of a mobile node. Packets containing a
Home Address option MUST be dropped if there is no corresponding
Binding Cache entry. A corresponding Binding Cache entry MUST have
the same home address as appears in the Home Address destination
option, and the currently registered care-of address MUST be equal to
the source address of the packet. These tests MUST NOT be done for
packets that contain a Home Address option and a Binding Update.
If the packet is dropped due the above tests, the correspondent node
MUST send the Binding Error message as described in Section 9.3.3.
The Status field in this message should be set to 1 (unknown binding
for Home Address destination option).
The correspondent node MUST process the option in a manner consistent
with exchanging the Home Address field from the Home Address option
into the IPv6 header and replacing the original value of the Source
Address field there. After all IPv6 options have been processed, it
MUST be possible for upper layers to process the packet without the
knowledge that it came originally from a care-of address or that a
Home Address option was used.
The use of IPsec Authentication Header (AH) for the Home Address
option is not required, except that if the IPv6 header of a packet is
covered by AH, then the authentication MUST also cover the Home
Address option; this coverage is achieved automatically by the
definition of the Option Type code for the Home Address option, since
it indicates that the data within the option cannot change en route to the packet's final destination, and thus the option is included in the AH computation. By requiring that any authentication of the IPv6 header also cover the Home Address option, the security of the Source Address field in the IPv6 header is not compromised by the presence of a Home Address option. When attempting to verify AH authentication data in a packet that contains a Home Address option, the receiving node MUST calculate the AH authentication data as if the following were true: The Home Address option contains the care-of address, and the source IPv6 address field of the IPv6 header contains the home address. This conforms with the calculation specified in Section 11.3.2.9.3.2. Sending Packets to a Mobile Node
Before sending any packet, the sending node SHOULD examine its Binding Cache for an entry for the destination address to which the packet is being sent. If the sending node has a Binding Cache entry for this address, the sending node SHOULD use a type 2 routing header to route the packet to this mobile node (the destination node) by way of its care-of address. However, the sending node MUST not do this in the following cases: o When sending an IPv6 Neighbor Discovery [12] packet. o Where otherwise noted in Section 6.1. When calculating authentication data in a packet that contains a type 2 routing header, the correspondent node MUST calculate the AH authentication data as if the following were true: The routing header contains the care-of address, the destination IPv6 address field of the IPv6 header contains the home address, and the Segments Left field is zero. The IPsec Security Policy Database lookup MUST based on the mobile node's home address. For instance, assuming there are no additional routing headers in this packet beyond those needed by Mobile IPv6, the correspondent node could set the fields in the packet's IPv6 header and routing header as follows: o The Destination Address in the packet's IPv6 header is set to the mobile node's home address (the original destination address to which the packet was being sent).
o The routing header is initialized to contain a single route
segment, containing the mobile node's care-of address copied from
the Binding Cache entry. The Segments Left field is, however,
temporarily set to zero.
The IP layer will insert the routing header before performing any
necessary IPsec processing. Once all IPsec processing has been
performed, the node swaps the IPv6 destination field with the Home
Address field in the routing header, sets the Segments Left field to
one, and sends the packet. This ensures the AH calculation is done
on the packet in the form it will have on the receiver after
advancing the routing header.
Following the definition of a type 2 routing header in Section 6.4,
this packet will be routed to the mobile node's care-of address,
where it will be delivered to the mobile node (the mobile node has
associated the care-of address with its network interface).
Note that following the above conceptual model in an implementation
creates some additional requirements for path MTU discovery since the
layer that decides the packet size (e.g., TCP and applications using
UDP) needs to be aware of the size of the headers added by the IP
layer on the sending node.
If, instead, the sending node has no Binding Cache entry for the
destination address to which the packet is being sent, the sending
node simply sends the packet normally, with no routing header. If
the destination node is not a mobile node (or is a mobile node that
is currently at home), the packet will be delivered directly to this
node and processed normally by it. If, however, the destination node
is a mobile node that is currently away from home, the packet will be
intercepted by the mobile node's home agent and tunneled to the
mobile node's current primary care-of address.
9.3.3. Sending Binding Error Messages
Section 9.2 and Section 9.3.1 describe error conditions that lead to
a need to send a Binding Error message.
A Binding Error message is sent directly to the address that appeared
in the IPv6 Source Address field of the offending packet. If the
Source Address field does not contain a unicast address, the Binding
Error message MUST NOT be sent.
The Home Address field in the Binding Error message MUST be copied
from the Home Address field in the Home Address destination option of
the offending packet, or set to the unspecified address if no such
option appeared in the packet.
Note that the IPv6 Source Address and Home Address field values discussed above are the values from the wire, i.e., before any modifications possibly performed as specified in Section 9.3.1. Binding Error messages SHOULD be subject to rate limiting in the same manner as is done for ICMPv6 messages [14].9.3.4. Receiving ICMP Error Messages
When the correspondent node has a Binding Cache entry for a mobile node, all traffic destined to the mobile node goes directly to the current care-of address of the mobile node using a routing header. Any ICMP error message caused by packets on their way to the care-of address will be returned in the normal manner to the correspondent node. On the other hand, if the correspondent node has no Binding Cache entry for the mobile node, the packet will be routed through the mobile node's home link. Any ICMP error message caused by the packet on its way to the mobile node while in the tunnel, will be transmitted to the mobile node's home agent. By the definition of IPv6 encapsulation [15], the home agent MUST relay certain ICMP error messages back to the original sender of the packet, which in this case is the correspondent node. Thus, in all cases, any meaningful ICMP error messages caused by packets from a correspondent node to a mobile node will be returned to the correspondent node. If the correspondent node receives persistent ICMP Destination Unreachable messages after sending packets to a mobile node based on an entry in its Binding Cache, the correspondent node SHOULD delete this Binding Cache entry. Note that if the mobile node continues to send packets with the Home Address destination option to this correspondent node, they will be dropped due to the lack of a binding. For this reason it is important that only persistent ICMP messages lead to the deletion of the Binding Cache entry.9.4. Return Routability Procedure
This subsection specifies actions taken by a correspondent node during the return routability procedure.
9.4.1. Receiving Home Test Init Messages
Upon receiving a Home Test Init message, the correspondent node verifies the following: o The packet MUST NOT include a Home Address destination option. Any packet carrying a Home Test Init message which fails to satisfy all of these tests MUST be silently ignored. Otherwise, in preparation for sending the corresponding Home Test Message, the correspondent node checks that it has the necessary material to engage in a return routability procedure, as specified in Section 5.2. The correspondent node MUST have a secret Kcn and a nonce. If it does not have this material yet, it MUST produce it before continuing with the return routability procedure. Section 9.4.3 specifies further processing.9.4.2. Receiving Care-of Test Init Messages
Upon receiving a Care-of Test Init message, the correspondent node verifies the following: o The packet MUST NOT include a Home Address destination option. Any packet carrying a Care-of Test Init message which fails to satisfy all of these tests MUST be silently ignored. Otherwise, in preparation for sending the corresponding Care-of Test Message, the correspondent node checks that it has the necessary material to engage in a return routability procedure in the manner described in Section 9.4.1. Section 9.4.4 specifies further processing.9.4.3. Sending Home Test Messages
The correspondent node creates a home keygen token and uses the current nonce index as the Home Nonce Index. It then creates a Home Test message (Section 6.1.5) and sends it to the mobile node at the latter's home address.
9.4.4. Sending Care-of Test Messages
The correspondent node creates a care-of keygen token and uses the current nonce index as the Care-of Nonce Index. It then creates a Care-of Test message (Section 6.1.6) and sends it to the mobile node at the latter's care-of address.9.5. Processing Bindings
This section explains how the correspondent node processes messages related to bindings. These messages are: o Binding Update o Binding Refresh Request o Binding Acknowledgement o Binding Error9.5.1. Receiving Binding Updates
Before accepting a Binding Update, the receiving node MUST validate the Binding Update according to the following tests: o The packet MUST contain a unicast routable home address, either in the Home Address option or in the Source Address, if the Home Address option is not present. o The Sequence Number field in the Binding Update is greater than the Sequence Number received in the previous valid Binding Update for this home address, if any. If the receiving node has no Binding Cache entry for the indicated home address, it MUST accept any Sequence Number value in a received Binding Update from this mobile node. This Sequence Number comparison MUST be performed modulo 2**16, i.e., the number is a free running counter represented modulo 65536. A Sequence Number in a received Binding Update is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding 32768 values, inclusive. For example, if the last received sequence number was 15, then messages with sequence numbers 0 through 15, as well as 32783 through 65535, would be considered less than or equal.
When the Home Registration (H) bit is not set, the following are also
required:
o A Nonce Indices mobility option MUST be present, and the Home and
Care-of Nonce Index values in this option MUST be recent enough to
be recognized by the correspondent node. (Care-of Nonce Index
values are not inspected for requests to delete a binding.)
o The correspondent node MUST re-generate the home keygen token and
the care-of keygen token from the information contained in the
packet. It then generates the binding management key Kbm and uses
it to verify the authenticator field in the Binding Update as
specified in Section 6.1.7.
o The Binding Authorization Data mobility option MUST be present,
and its contents MUST satisfy rules presented in Section 5.2.6.
Note that a care-of address different from the Source Address MAY
have been specified by including an Alternate Care-of Address
mobility option in the Binding Update. When such a message is
received and the return routability procedure is used as an
authorization method, the correspondent node MUST verify the
authenticator by using the address within the Alternate Care-of
Address in the calculations.
o The Binding Authorization Data mobility option MUST be the last
option and MUST NOT have trailing padding.
If the Home Registration (H) bit is set, the Nonce Indices mobility
option MUST NOT be present.
If the mobile node sends a sequence number which is not greater than
the sequence number from the last valid Binding Update for this home
address, then the receiving node MUST send back a Binding
Acknowledgement with status code 135, and the last accepted sequence
number in the Sequence Number field of the Binding Acknowledgement.
If a binding already exists for the given home address and the home
registration flag has a different value than the Home Registration
(H) bit in the Binding Update, then the receiving node MUST send back
a Binding Acknowledgement with status code 139 (registration type
change disallowed). The home registration flag stored in the Binding
Cache entry MUST NOT be changed.
If the receiving node no longer recognizes the Home Nonce Index
value, Care-of Nonce Index value, or both values from the Binding
Update, then the receiving node MUST send back a Binding
Acknowledgement with status code 136, 137, or 138, respectively.
Packets carrying Binding Updates that fail to satisfy all of these
tests for any reason other than insufficiency of the Sequence Number,
registration type change, or expired nonce index values, MUST be
silently discarded.
If the Binding Update is valid according to the tests above, then the
Binding Update is processed further as follows:
o The Sequence Number value received from a mobile node in a Binding
Update is stored by the receiving node in its Binding Cache entry
for the given home address.
o If the Lifetime specified in the Binding Update is nonzero and the
specified care-of address is not equal to the home address for the
binding, then this is a request to cache a binding for the home
address. If the Home Registration (H) bit is set in the Binding
Update, the Binding Update is processed according to the procedure
specified in Section 10.3.1; otherwise, it is processed according
to the procedure specified in Section 9.5.2.
o If the Lifetime specified in the Binding Update is zero or the
specified care-of address matches the home address for the
binding, then this is a request to delete the cached binding for
the home address. In this case, the Binding Update MUST include a
valid home nonce index, and the care-of nonce index MUST be
ignored by the correspondent node. The generation of the binding
management key depends then exclusively on the home keygen token
(Section 5.2.5). If the Home Registration (H) bit is set in the
Binding Update, the Binding Update is processed according to the
procedure specified in Section 10.3.2; otherwise, it is processed
according to the procedure specified in Section 9.5.3.
The specified care-of address MUST be determined as follows:
o If the Alternate Care-of Address option is present, the care-of
address is the address in that option.
o Otherwise, the care-of address is the Source Address field in the
packet's IPv6 header.
The home address for the binding MUST be determined as follows:
o If the Home Address destination option is present, the home
address is the address in that option.
o Otherwise, the home address is the Source Address field in the
packet's IPv6 header.
9.5.2. Requests to Cache a Binding
This section describes the processing of a valid Binding Update that requests a node to cache a binding, for which the Home Registration (H) bit is not set in the Binding Update. In this case, the receiving node SHOULD create a new entry in its Binding Cache for this home address, or update its existing Binding Cache entry for this home address, if such an entry already exists. The lifetime for the Binding Cache entry is initialized from the Lifetime field specified in the Binding Update, although this lifetime MAY be reduced by the node caching the binding; the lifetime for the Binding Cache entry MUST NOT be greater than the Lifetime value specified in the Binding Update. Any Binding Cache entry MUST be deleted after the expiration of its lifetime. Note that if the mobile node did not request a Binding Acknowledgement, then it is not aware of the selected shorter lifetime. The mobile node may thus use route optimization and send packets with the Home Address destination option. As discussed in Section 9.3.1, such packets will be dropped if there is no binding. This situation is recoverable, but can cause temporary packet loss. The correspondent node MAY refuse to accept a new Binding Cache entry if it does not have sufficient resources. A new entry MAY also be refused if the correspondent node believes its resources are utilized more efficiently in some other purpose, such as serving another mobile node with higher amount of traffic. In both cases the correspondent node SHOULD return a Binding Acknowledgement with status value 130.9.5.3 Requests to Delete a Binding
This section describes the processing of a valid Binding Update that requests a node to delete a binding when the Home Registration (H) bit is not set in the Binding Update. Any existing binding for the given home address MUST be deleted. A Binding Cache entry for the home address MUST NOT be created in response to receiving the Binding Update. If the Binding Cache entry was created by use of return routability nonces, the correspondent node MUST ensure that the same nonces are not used again with the particular home and care-of address. If both nonces are still valid, the correspondent node has to remember the particular combination of nonce indexes, addresses, and sequence number as illegal until at least one of the nonces has become too old.
9.5.4. Sending Binding Acknowledgements
A Binding Acknowledgement may be sent to indicate receipt of a Binding Update as follows: o If the Binding Update was discarded as described in Section 9.2 or Section 9.5.1, a Binding Acknowledgement MUST NOT be sent. Otherwise the treatment depends on the following rules. o If the Acknowledge (A) bit set is set in the Binding Update, a Binding Acknowledgement MUST be sent. Otherwise, the treatment depends on the below rule. o If the node rejects the Binding Update due to an expired nonce index, sequence number being out of window (Section 9.5.1), or insufficiency of resources (Section 9.5.2), a Binding Acknowledgement MUST be sent. If the node accepts the Binding Update, the Binding Acknowledgement SHOULD NOT be sent. If the node accepts the Binding Update and creates or updates an entry for this binding, the Status field in the Binding Acknowledgement MUST be set to a value less than 128. Otherwise, the Status field MUST be set to a value greater than or equal to 128. Values for the Status field are described in Section 6.1.8 and in the IANA registry of assigned numbers [19]. If the Status field in the Binding Acknowledgement contains the value 136 (expired home nonce index), 137 (expired care-of nonce index), or 138 (expired nonces) then the message MUST NOT include the Binding Authorization Data mobility option. Otherwise, the Binding Authorization Data mobility option MUST be included, and MUST meet the specific authentication requirements for Binding Acknowledgements as defined in Section 5.2. If the Source Address field of the IPv6 header that carried the Binding Update does not contain a unicast address, the Binding Acknowledgement MUST NOT be sent and the Binding Update packet MUST be silently discarded. Otherwise, the acknowledgement MUST be sent to the Source Address. Unlike the treatment of regular packets, this addressing procedure does not use information from the Binding Cache. However, a routing header is needed in some cases. If the Source Address is the home address of the mobile node, i.e., the Binding Update did not contain a Home Address destination option, then the Binding Acknowledgement MUST be sent to that address and the routing header MUST NOT be used. Otherwise, the Binding Acknowledgement MUST be sent using a type 2 routing header which contains the mobile node's home address.
9.5.5. Sending Binding Refresh Requests
If a Binding Cache entry being deleted is still in active use when sending packets to a mobile node, then the next packet sent to the mobile node will be routed normally to the mobile node's home link. Communication with the mobile node continues, but the tunneling from the home network creates additional overhead and latency in delivering packets to the mobile node. If the sender knows that the Binding Cache entry is still in active use, it MAY send a Binding Refresh Request message to the mobile node in an attempt to avoid this overhead and latency due to deleting and recreating the Binding Cache entry. This message is always sent to the home address of the mobile node. The correspondent node MAY retransmit Binding Refresh Request messages as long as the rate limitation is applied. The correspondent node MUST stop retransmitting when it receives a Binding Update.9.6. Cache Replacement Policy
Conceptually, a node maintains a separate timer for each entry in its Binding Cache. When creating or updating a Binding Cache entry in response to a received and accepted Binding Update, the node sets the timer for this entry to the specified Lifetime period. Any entry in a node's Binding Cache MUST be deleted after the expiration of the Lifetime specified in the Binding Update from which the entry was created or last updated. Each node's Binding Cache will, by necessity, have a finite size. A node MAY use any reasonable local policy for managing the space within its Binding Cache. A node MAY choose to drop any entry already in its Binding Cache in order to make space for a new entry. For example, a "least-recently used" (LRU) strategy for cache entry replacement among entries should work well, unless the size of the Binding Cache is substantially insufficient. When entries are deleted, the correspondent node MUST follow the rules in Section 5.2.8 in order to guard the return routability procedure against replay attacks. If the node sends a packet to a destination for which it has dropped the entry from its Binding Cache, the packet will be routed through the mobile node's home link. The mobile node can detect this and establish a new binding if necessary.
However, if the mobile node believes that the binding still exists, it may use route optimization and send packets with the Home Address destination option. This can create temporary packet loss, as discussed earlier, in the context of binding lifetime reductions performed by the correspondent node (Section 9.5.2).10. Home Agent Operation
10.1. Conceptual Data Structures
Each home agent MUST maintain a Binding Cache and Home Agents List. The rules for maintaining a Binding Cache are the same for home agents and correspondent nodes and have already been described in Section 9.1. The Home Agents List is maintained by each home agent, recording information about each router on the same link that is acting as a home agent. This list is used by the dynamic home agent address discovery mechanism. A router is known to be acting as a home agent, if it sends a Router Advertisement in which the Home Agent (H) bit is set. When the lifetime for a list entry (defined below) expires, that entry is removed from the Home Agents List. The Home Agents List is similar to the Default Router List conceptual data structure maintained by each host for Neighbor Discovery [12]. The Home Agents List MAY be implemented in any manner consistent with the external behavior described in this document. Each home agent maintains a separate Home Agents List for each link on which it is serving as a home agent. A new entry is created or an existing entry is updated in response to receipt of a valid Router Advertisement in which the Home Agent (H) bit is set. Each Home Agents List entry conceptually contains the following fields: o The link-local IP address of a home agent on the link. This address is learned through the Source Address of the Router Advertisements [12] received from the router. o One or more global IP addresses for this home agent. Global addresses are learned through Prefix Information options with the Router Address (R) bit set and received in Router Advertisements from this link-local address. Global addresses for the router in a Home Agents List entry MUST be deleted once the prefix associated with that address is no longer valid [12].
o The remaining lifetime of this Home Agents List entry. If a Home
Agent Information Option is present in a Router Advertisement
received from a home agent, the lifetime of the Home Agents List
entry representing that home agent is initialized from the Home
Agent Lifetime field in the option (if present); otherwise, the
lifetime is initialized from the Router Lifetime field in the
received Router Advertisement. If Home Agents List entry lifetime
reaches zero, the entry MUST be deleted from the Home Agents List.
o The preference for this home agent; higher values indicate a more
preferable home agent. The preference value is taken from the
Home Agent Preference field in the received Router Advertisement,
if the Router Advertisement contains a Home Agent Information
Option and is otherwise set to the default value of 0. A home
agent uses this preference in ordering the Home Agents List when
it sends an ICMP Home Agent Address Discovery message.
10.2. Processing Mobility Headers
All IPv6 home agents MUST observe the rules described in Section 9.2
when processing Mobility Headers.
10.3. Processing Bindings
10.3.1. Primary Care-of Address Registration
When a node receives a Binding Update, it MUST validate it and
determine the type of Binding Update according to the steps described
in Section 9.5.1. Furthermore, it MUST authenticate the Binding
Update as described in Section 5.1. An authorization step specific
for the home agent is also needed to ensure that only the right node
can control a particular home address. This is provided through the
home address unequivocally identifying the security association that
must be used.
This section describes the processing of a valid and authorized
Binding Update when it requests the registration of the mobile node's
primary care-of address.
To begin processing the Binding Update, the home agent MUST perform
the following sequence of tests:
o If the node implements only correspondent node functionality, or
has not been configured to act as a home agent, then the node MUST
reject the Binding Update. The node MUST also return a Binding
Acknowledgement to the mobile node, in which the Status field is
set to 131 (home registration not supported).
o Else, if the home address for the binding (the Home Address field
in the packet's Home Address option) is not an on-link IPv6
address with respect to the home agent's current Prefix List, then
the home agent MUST reject the Binding Update and SHOULD return a
Binding Acknowledgement to the mobile node, in which the Status
field is set to 132 (not home subnet).
o Else, if the home agent chooses to reject the Binding Update for
any other reason (e.g., insufficient resources to serve another
mobile node as a home agent), then the home agent SHOULD return a
Binding Acknowledgement to the mobile node, in which the Status
field is set to an appropriate value to indicate the reason for
the rejection.
o A Home Address destination option MUST be present in the message.
It MUST be validated as described in Section 9.3.1 with the
following additional rule. The Binding Cache entry existence test
MUST NOT be done for IPsec packets when the Home Address option
contains an address for which the receiving node could act as a
home agent.
If home agent accepts the Binding Update, it MUST then create a new
entry in its Binding Cache for this mobile node or update its
existing Binding Cache entry, if such an entry already exists. The
Home Address field as received in the Home Address option provides
the home address of the mobile node.
The home agent MUST mark this Binding Cache entry as a home
registration to indicate that the node is serving as a home agent for
this binding. Binding Cache entries marked as a home registration
MUST be excluded from the normal cache replacement policy used for
the Binding Cache (Section 9.6) and MUST NOT be removed from the
Binding Cache until the expiration of the Lifetime period.
Unless this home agent already has a binding for the given home
address, the home agent MUST perform Duplicate Address Detection [13]
on the mobile node's home link before returning the Binding
Acknowledgement. This ensures that no other node on the home link
was using the mobile node's home address when the Binding Update
arrived. If this Duplicate Address Detection fails for the given
home address or an associated link local address, then the home agent
MUST reject the complete Binding Update and MUST return a Binding
Acknowledgement to the mobile node, in which the Status field is set
to 134 (Duplicate Address Detection failed). When the home agent
sends a successful Binding Acknowledgement to the mobile node, the
home agent assures to the mobile node that its address(es) will be
kept unique by the home agent for as long as the lifetime was granted
for the binding.
The specific addresses, which are to be tested before accepting the
Binding Update and later to be defended by performing Duplicate
Address Detection, depend on the setting of the Link-Local Address
Compatibility (L) bit, as follows:
o L=0: Defend only the given address. Do not derive a link-local
address.
o L=1: Defend both the given non link-local unicast (home) address
and the derived link-local. The link-local address is derived by
replacing the subnet prefix in the mobile node's home address with
the link-local prefix.
The 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 [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, or
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 moves.
Depending on the final value of the bit in the Binding
Acknowledgement, the home agent SHOULD perform the following
actions:
K = 0
Discard 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 = 1
Move 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 RFC 2408 [8] Section 2.5.3 gives specific rules that
ISAKMP cookies must satisfy: they must depend on specific
parties and can only be 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 before 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.
The rules for selecting the Destination IP address (and possibly
routing header construction) for the Binding Acknowledgement to the
mobile node are the same as in Section 9.5.4.
In addition, the home agent MUST follow the procedure defined in
Section 10.4.1 to intercept packets on the mobile node's home link
addressed to the mobile node, while the home agent is serving as the
home agent for this mobile node. The home agent MUST also be
prepared to accept reverse tunneled packets from the new care-of
address of the mobile node, as described in Section 10.4.5. Finally,
the home agent MUST also propagate new home network prefixes, as
described in Section 10.6.
10.3.2. Primary Care-of Address De-Registration
A binding may need to be de-registered when the mobile node returns
home or when the mobile node knows that it will not have any care-of
addresses in the visited network.
A Binding Update is validated and authorized in the manner described
in the previous section; note that when the mobile node de-registers
when it is at home, it may not include the Home Address destination
option, in which case the mobile node's home address is the source IP
address of the de-registration Binding Update. This section
describes the processing of a valid Binding Update that requests the
receiving node to no longer serve as its home agent, de-registering
its primary care-of address.
To begin processing the Binding Update, the home agent MUST perform
the following test:
o If the receiving node has no entry marked as a home registration
in its Binding Cache for this mobile node, then this node MUST
reject the Binding Update and SHOULD return a Binding
Acknowledgement to the mobile node, in which the Status field is
set to 133 (not home agent for this mobile node).
If the home agent does not reject the Binding Update as described
above, then it MUST delete any existing entry in its Binding Cache
for this mobile node. Then, 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 0, indicating success.
o The Key Management Mobility Capability (K) bit is set or cleared
and actions based on its value are performed as described in the
previous section. The mobile node's home address is used as its
new care-of address for the purposes of moving the key management
connection to a new endpoint.
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 zero.
o The Binding Refresh Advice mobility option MUST be omitted.
In addition, the home agent MUST stop intercepting packets on the
mobile node's home link that are addressed to the mobile node
(Section 10.4.1).
The rules for selecting the Destination IP address (and, if required,
routing header construction) for the Binding Acknowledgement to the
mobile node are the same as in the previous section. When the Status
field in the Binding Acknowledgement is greater than or equal to 128
and the Source Address of the Binding Update is on the home link, the
home agent MUST send it to the mobile node's link layer address
(retrieved either from the Binding Update or through Neighbor
Solicitation).
10.4. Packet Processing
10.4.1. Intercepting Packets for a Mobile Node
While a node is serving as the home agent for mobile node it MUST attempt to intercept packets on the mobile node's home link that are addressed to the mobile node. In order to do this, when a node begins serving as the home agent it MUST multicast onto the home link a Neighbor Advertisement message [12] on behalf of the mobile node. For the home address specified in the Binding Update, the home agent sends a Neighbor Advertisement message [12] to the all-nodes multicast address on the home link to advertise the home agent's own link-layer address for this IP address on behalf of the mobile node. If the Link-Layer Address Compatibility (L) flag has been specified in the Binding Update, the home agent MUST do the same for the link-local address of the mobile node. All fields in each Neighbor Advertisement message SHOULD be set in the same way they would be set by the mobile node if it was sending this Neighbor Advertisement [12] while at home, with the following exceptions: o The Target Address in the Neighbor Advertisement MUST be set to the specific IP address for the mobile node. o The Advertisement MUST include a Target Link-layer Address option specifying the home agent's link-layer address. o The Router (R) bit in the Advertisement MUST be set to zero. o The Solicited Flag (S) in the Advertisement MUST NOT be set, since it was not solicited by any Neighbor Solicitation. o The Override Flag (O) in the Advertisement MUST be set, indicating that the Advertisement SHOULD override any existing Neighbor Cache entry at any node receiving it. o The Source Address in the IPv6 header MUST be set to the home agent's IP address on the interface used to send the advertisement. Any node on the home link that receives one of the Neighbor Advertisement messages (described above) will update its Neighbor Cache to associate the mobile node's address with the home agent's link layer address, causing it to transmit any future packets normally destined to the mobile node to the mobile node's home agent.
Since multicasting on the local link (such as Ethernet) is typically not guaranteed to be reliable, the home agent MAY retransmit this Neighbor Advertisement message up to MAX_NEIGHBOR_ADVERTISEMENT (see [12]) times to increase its reliability. It is still possible that some nodes on the home link will not receive any of the Neighbor Advertisements, but these nodes will eventually be able to detect the link-layer address change for the mobile node's address through use of Neighbor Unreachability Detection [12]. While a node is serving as a home agent for some mobile node, the home agent uses IPv6 Neighbor Discovery [12] to intercept unicast packets on the home link addressed to the mobile node. In order to intercept packets in this way, the home agent MUST act as a proxy for this mobile node and reply to any received Neighbor Solicitations for it. When a home agent receives a Neighbor Solicitation, it MUST check if the Target Address specified in the message matches the address of any mobile node for which it has a Binding Cache entry marked as a home registration. If such an entry exists in the home agent's Binding Cache, the home agent MUST reply to the Neighbor Solicitation with a Neighbor Advertisement giving the home agent's own link-layer address as the link-layer address for the specified Target Address. In addition, the Router (R) bit in the Advertisement MUST be set to zero. Acting as a proxy in this way allows other nodes on the mobile node's home link to resolve the mobile node's address and for the home agent to defend these addresses on the home link for Duplicate Address Detection [12].10.4.2. Processing Intercepted Packets
For any packet sent to a mobile node from the mobile node's home agent (in 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. While the mobile node is away from home, the home agent intercepts any packets on the home link addressed to the mobile node's home address, as described in Section 10.4.1. In order to forward each intercepted packet to the mobile node, the home agent MUST tunnel the packet to the mobile node using IPv6 encapsulation [15]. When a home agent encapsulates an intercepted packet for forwarding to the mobile node, the home agent sets the Source Address in the new tunnel IP header to the home agent's own IP address and sets the Destination Address in the tunnel IP header to the mobile node's primary care-of
address. When received by the mobile node, normal processing of the tunnel header [15] will result in decapsulation and processing of the original packet by the mobile node. However, packets addressed to the mobile node's link-local address MUST NOT be tunneled to the mobile node. Instead, these packets MUST be discarded and the home agent SHOULD return an ICMP Destination Unreachable, Code 3, message to the packet's Source Address (unless this Source Address is a multicast address). Packets addressed to the mobile node's site-local address SHOULD NOT be tunneled to the mobile node by default. Interception and tunneling of the following multicast addressed packets on the home network are only done if the home agent supports multicast group membership control messages from the mobile node as described in the next section. Tunneling of multicast packets to a mobile node follows similar limitations to those defined above for unicast packets addressed to the mobile node's link-local and site- local addresses. Multicast packets addressed to a multicast address with link-local scope [3], to which the mobile node is subscribed, MUST NOT be tunneled to the mobile node. These packets SHOULD be silently discarded (after delivering to other local multicast recipients). Multicast packets addressed to a multicast address with a scope larger than link-local, but smaller than global (e.g., site- local and organization-local [3], to which the mobile node is subscribed, SHOULD NOT be tunneled to the mobile node. Multicast packets addressed with a global scope, to which the mobile node has successfully subscribed, MUST be tunneled to the mobile node. Before tunneling a packet to the mobile node, the home agent MUST perform any IPsec processing as indicated by the security policy data base.10.4.3. Multicast Membership Control
This section is a prerequisite for the multicast data packet forwarding, described in the previous section. If this support is not provided, multicast group membership control messages are silently ignored. In order to forward multicast data packets from the home network to all the proper mobile nodes, the home agent SHOULD be capable of receiving tunneled multicast group membership control information from the mobile node in order to determine which groups the mobile node has subscribed to. These multicast group membership messages are Listener Report messages specified in MLD [17] or in other protocols such as [37].
The messages are issued by the mobile node, but sent through the reverse tunnel to the home agent. These messages are issued whenever the mobile node decides to enable reception of packets for a multicast group or in response to an MLD Query from the home agent. The mobile node will also issue multicast group control messages to disable reception of multicast packets when it is no longer interested in receiving multicasts for a particular group. To obtain the mobile node's current multicast group membership the home agent must periodically transmit MLD Query messages through the tunnel to the mobile node. These MLD periodic transmissions will ensure the home agent has an accurate record of the groups in which the mobile node is interested despite packet losses of the mobile node's MLD group membership messages. All MLD packets are sent directly between the mobile node and the home agent. Since all of these packets are destined to a link-scope multicast address and have a hop limit of 1, there is no direct forwarding of such packets between the home network and the mobile node. The MLD packets between the mobile node and the home agent are encapsulated within the same tunnel header used for other packet flows between the mobile node and home agent. Note that at this time, even though a link-local source is used on MLD packets, no functionality depends on these addresses being unique, nor do they elicit direct responses. All MLD messages are sent to multicast destinations. To avoid ambiguity on the home agent, due to mobile nodes which may choose identical link-local source addresses for their MLD function, it is necessary for the home agent to identify which mobile node was actually the issuer of a particular MLD message. This may be accomplished by noting which tunnel such an MLD arrived by, which IPsec SA was used, or by other distinguishing means. This specification puts no requirement on how the functions in this section and the multicast forwarding in Section 10.4.2 are to be achieved. At the time of this writing it was thought that a full IPv6 multicast router function would be necessary on the home agent, but it may be possible to achieve the same effects through a "proxy MLD" application coupled with kernel multicast forwarding. This may be the subject of future specifications.
10.4.4. Stateful Address Autoconfiguration
This section describes how home agents support the use of stateful address autoconfiguration mechanisms such as DHCPv6 [29] from the mobile nodes. If this support is not provided, then the M and O bits must remain cleared on the Mobile Prefix Advertisement Messages. Any mobile node which sends DHCPv6 messages to the home agent without this support will not receive a response. If DHCPv6 is used, packets are sent with link-local source addresses either to a link-scope multicast address or a link-local address. Mobile nodes desiring to locate a DHCPv6 service may reverse tunnel standard DHCPv6 packets to the home agent. Since these link-scope packets cannot be forwarded onto the home network, it is necessary for the home agent to either implement a DHCPv6 relay agent or a DHCPv6 server function itself. The arriving tunnel or IPsec SA of DHCPv6 link-scope messages from the mobile node must be noted so that DHCPv6 responses may be sent back to the appropriate mobile node. DHCPv6 messages sent to the mobile node with a link-local destination must be tunneled within the same tunnel header used for other packet flows.10.4.5. Handling Reverse Tunneled Packets
Unless a binding has been established between the mobile node and a correspondent node, traffic from the mobile node to the correspondent node goes through a reverse tunnel. Home agents MUST support reverse tunneling as follows: o The tunneled traffic arrives to the home agent's address using IPv6 encapsulation [15]. o Depending on the security policies used by the home agent, reverse tunneled packets MAY be discarded unless accompanied by a valid ESP header. The support for authenticated reverse tunneling allows the home agent to protect the home network and correspondent nodes from malicious nodes masquerading as a mobile node. o Otherwise, when a home agent decapsulates a tunneled packet from the mobile node, the home agent MUST verify that the Source Address in the tunnel IP header is the mobile node's primary care-of address. Otherwise, any node in the Internet could send traffic through the home agent and escape ingress filtering limitations. This simple check forces the attacker to know the current location of the real mobile node and be able to defeat ingress filtering. This check is not necessary if the reverse- tunneled packet is protected by ESP in tunnel mode.
10.4.6. Protecting Return Routability Packets
The return routability procedure, described in Section 5.2.5, assumes that the confidentiality of the Home Test Init and Home Test messages is protected as they are tunneled between the home agent and the mobile node. Therefore, the home agent MUST support tunnel mode IPsec ESP for the protection of packets belonging to the return routability procedure. Support for a non-null encryption transform and authentication algorithm MUST be available. It is not necessary to distinguish between different kinds of packets during the return routability procedure. Security associations are needed to provide this protection. When the care-of address for the mobile node changes as a result of an accepted Binding Update, special treatment is needed for the next packets sent using these security associations. The home agent MUST set the new care-of address as the destination address of these packets, as if the outer header destination address in the security association had changed [21]. The above protection SHOULD be used with all mobile nodes. The use is controlled by configuration of the IPsec security policy database both at the mobile node and at the home agent. As described earlier, the Binding Update and Binding Acknowledgement messages require protection between the home agent and the mobile node. The Mobility Header protocol carries both these messages as well as the return routability messages. From the point of view of the security policy database these messages are indistinguishable. When IPsec is used to protect return routability signaling or payload packets, this protection MUST only be applied to the return routability packets entering the IPv6 encapsulated tunnel interface between the mobile node and the home agent. This can be achieved, for instance, by defining the security policy database entries specifically for the tunnel interface. That is, the policy entries are not generally applied on all traffic on the physical interface(s) of the nodes, but rather only on traffic that enters the tunnel. This makes use of per-interface security policy database entries [4] specific to the tunnel interface (the node's attachment to the tunnel [11]).10.5. Dynamic Home Agent Address Discovery
This section describes how a home agent can help mobile nodes to discover the addresses of the home agents. The home agent keeps track of the other home agents on the same link and responds to queries sent by the mobile node.
10.5.1. Receiving Router Advertisement Messages
For each link on which a router provides service as a home agent, the router maintains a Home Agents List recording information about all other home agents on that link. This list is used in the dynamic home agent address discovery mechanism, described in Section 10.5. The information for the list is learned through receipt of the periodic unsolicited multicast Router Advertisements, in a manner similar to the Default Router List conceptual data structure maintained by each host for Neighbor Discovery [12]. In the construction of the Home Agents List, the Router Advertisements are from each (other) home agent on the link and the Home Agent (H) bit is set in them. On receipt of a valid Router Advertisement, as defined in the processing algorithm specified for Neighbor Discovery [12], the home agent performs the following steps in addition to any steps already required of it by Neighbor Discovery: o If the Home Agent (H) bit in the Router Advertisement is not set, delete the sending node's entry in the current Home Agents List (if one exists). Skip all the following steps. o Otherwise, extract the Source Address from the IP header of the Router Advertisement. This is the link-local IP address on this link of the home agent sending this Advertisement [12]. o Determine the preference for this home agent. If the Router Advertisement contains a Home Agent Information Option, then the preference is taken from the Home Agent Preference field in the option; otherwise, the default preference of 0 MUST be used. o Determine the lifetime for this home agent. If the Router Advertisement contains a Home Agent Information Option, then the lifetime is taken from the Home Agent Lifetime field in the option; otherwise, the lifetime specified by the Router Lifetime field in the Router Advertisement SHOULD be used. o If the link-local address of the home agent sending this Advertisement is already present in this home agent's Home Agents List and the received home agent lifetime value is zero, immediately delete this entry in the Home Agents List. o Otherwise, if the link-local address of the home agent sending this Advertisement is already present in the receiving home agent's Home Agents List, reset its lifetime and preference to the values determined above.
o If the link-local address of the home agent sending this
Advertisement is not already present in the Home Agents List
maintained by the receiving home agent, and the lifetime for the
sending home agent is non-zero, create a new entry in the list,
and initialize its lifetime and preference to the values
determined above.
o If the Home Agents List entry for the link-local address of the
home agent sending this Advertisement was not deleted as described
above, determine any global address(es) of the home agent based on
each Prefix Information option received in this Advertisement in
which the Router Address (R) bit is set (Section 7.2). Add all
such global addresses to the list of global addresses in this Home
Agents List entry.
A home agent SHOULD maintain an entry in its Home Agents List for
each valid home agent address until that entry's lifetime expires,
after which time the entry MUST be deleted.
As described in Section 11.4.1, a mobile node attempts dynamic home
agent address discovery by sending an ICMP Home Agent Address
Discovery Request message to the Mobile IPv6 Home-Agents anycast
address [16] for its home IP subnet prefix. A home agent receiving a
Home Agent Address Discovery Request message that serves this subnet
SHOULD return an ICMP Home Agent Address Discovery Reply message to
the mobile node with the Source Address of the Reply packet set to
one of the global unicast addresses of the home agent. The Home
Agent Addresses field in the Reply message is constructed as follows:
o The Home Agent Addresses field SHOULD contain all global IP
addresses for each home agent currently listed in this home
agent's own Home Agents List (Section 10.1).
o The IP addresses in the Home Agent Addresses field SHOULD be
listed in order of decreasing preference values, based either on
the respective advertised preference from a Home Agent Information
option or on the default preference of 0 if no preference is
advertised (or on the configured home agent preference for this
home agent itself).
o Among home agents with equal preference, their IP addresses in the
Home Agent Addresses field SHOULD be listed in an order randomized
with respect to other home agents with equal preference every time
a Home Agent Address Discovery Reply message is returned by this
home agent.
o If more than one global IP address is associated with a home
agent, these addresses SHOULD be listed in a randomized order.
o The home agent SHOULD reduce the number of home agent IP addresses
so that the packet fits within the minimum IPv6 MTU [11]. The
home agent addresses selected for inclusion in the packet SHOULD
be those from the complete list with the highest preference. This
limitation avoids the danger of the Reply message packet being
fragmented (or rejected by an intermediate router with an ICMP
Packet Too Big message [14]).
10.6. Sending Prefix Information to the Mobile Node
10.6.1. List of Home Network Prefixes
Mobile IPv6 arranges to propagate relevant prefix information to the
mobile node when it is away from home, so that it may be used in
mobile node home address configuration and in network renumbering.
In this mechanism, mobile nodes away from home receive Mobile Prefix
Advertisements messages. These messages include Prefix Information
Options for the prefixes configured on the home subnet interface(s)
of the home agent.
If there are multiple home agents, differences in the advertisements
sent by different home agents can lead to an inability to use a
particular home address when changing to another home agent. In
order to ensure that the mobile nodes get the same information from
different home agents, it is preferred that all of the home agents on
the same link be configured in the same manner.
To support this, the home agent monitors prefixes advertised by
itself and other home agents on the home link. In RFC 2461 [12] it
is acceptable for two routers to advertise different sets of prefixes
on the same link. For home agents, the differences should be
detected for a given home address because the mobile node
communicates only with one home agent at a time and the mobile node
needs to know the full set of prefixes assigned to the home link.
All other comparisons of Router Advertisements are as specified in
Section 6.2.7 of RFC 2461.
10.6.2. Scheduling Prefix Deliveries
A home agent serving a mobile node will schedule the delivery of the
new prefix information to that mobile node when any of the following
conditions occur:
MUST:
o The state of the flags changes for the prefix of the mobile node's
registered home address.
o The valid or preferred lifetime is reconfigured or changes for any
reason other than advancing real time.
o The mobile node requests the information with a Mobile Prefix
Solicitation (see Section 11.4.2).
SHOULD:
o A new prefix is added to the home subnet interface(s) of the home
agent.
MAY:
o The valid or preferred lifetime or the state of the flags changes
for a prefix which is not used in any Binding Cache entry for this
mobile node.
The home agent uses the following algorithm to determine when to send
prefix information to the mobile node.
o If a mobile node sends a solicitation, answer right away.
o If no Mobile Prefix Advertisement has been sent to the mobile node
in the last MaxMobPfxAdvInterval seconds (see Section 13), then
ensure that a transmission is scheduled. The actual transmission
time is randomized as described below.
o If a prefix matching the mobile node's home registration is added
on the home subnet interface or if its information changes in any
way that does not deprecate the mobile node's address, ensure that
a transmission is scheduled. The actual transmission time is
randomized as described below.
o If a home registration expires, cancel any scheduled
advertisements to the mobile node.
The list of prefixes is sent in its entirety in all cases.
If the home agent has already scheduled the transmission of a Mobile
Prefix Advertisement to the mobile node, then the home agent will
replace the advertisement with a new one to be sent at the scheduled
time.
Otherwise, the home agent computes a fresh value for RAND_ADV_DELAY
which offsets from the current time for the scheduled transmission.
First calculate the maximum delay for the scheduled Advertisement:
MaxScheduleDelay = min (MaxMobPfxAdvInterval, Preferred Lifetime),
where MaxMobPfxAdvInterval is as defined in Section 12. Then compute
the final delay for the advertisement:
RAND_ADV_DELAY = MinMobPfxAdvInterval +
(rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval))
Here rand() returns a random integer value in the range of 0 to the
maximum possible integer value. This computation is expected to
alleviate bursts of advertisements when prefix information changes.
In addition, a home agent MAY further reduce the rate of packet
transmission by further delaying individual advertisements, when
necessary to avoid overwhelming local network resources. The home
agent SHOULD periodically continue to retransmit an unsolicited
Advertisement to the mobile node, until it is acknowledged by the
receipt of a Mobile Prefix Solicitation from the mobile node.
The home agent MUST wait PREFIX_ADV_TIMEOUT (see Section 12) before
the first retransmission and double the retransmission wait time for
every succeeding retransmission until a maximum number of
PREFIX_ADV_RETRIES attempts (see Section 12) has been tried. If the
mobile node's bindings expire before the matching Binding Update has
been received, then the home agent MUST NOT attempt any more
retransmissions, even if not all PREFIX_ADV_RETRIES have been
retransmitted. In the meantime, if the mobile node sends another
Binding Update without returning home, then the home agent SHOULD
begin transmitting the unsolicited Advertisement again.
If some condition, as described above, occurs on the home link and
causes another Prefix Advertisement to be sent to the mobile node,
before the mobile node acknowledges a previous transmission, the home
agent SHOULD combine any Prefix Information options in the
unacknowledged Mobile Prefix Advertisement into a new Advertisement.
The home agent then discards the old Advertisement.
10.6.3. Sending Advertisements
When sending a Mobile Prefix Advertisement to the mobile node, the
home agent MUST construct the packet as follows:
o The Source Address in the packet's IPv6 header MUST be set to the
home agent's IP address to which the mobile node addressed its
current home registration or its default global home agent address
if no binding exists.
o If the advertisement was solicited, it MUST be destined to the
source address of the solicitation. If it was triggered by prefix
changes or renumbering, the advertisement's destination will be
the mobile node's home address in the binding which triggered the
rule.
o A type 2 routing header MUST be included with the mobile node's
home address.
o IPsec headers MUST be supported and SHOULD be used.
o The home agent MUST send the packet as it would any other unicast
IPv6 packet that it originates.
o Set the Managed Address Configuration (M) flag if the
corresponding flag has been set in any of the Router
Advertisements from which the prefix information has been learned
(including the ones sent by this home agent).
o Set the Other Stateful Configuration (O) flag if the corresponding
flag has been set in any of the Router Advertisements from which
the prefix information has been learned (including the ones sent
by this home agent).
10.6.4. Lifetimes for Changed Prefixes
As described in Section 10.3.1, the lifetime returned by the home
agent in a Binding Acknowledgement MUST not be greater than the
remaining valid lifetime for the subnet prefix in the mobile node's
home address. This limit on the binding lifetime serves to prohibit
use of a mobile node's home address after it becomes invalid.
(page 105 continued on part 4)
