RFC 6275
Mobility Support in IPv6
7. Modifications to IPv6 Neighbor Discovery
7.1. Modified Router Advertisement Message Format
Mobile IPv6 modifies the format of the Router Advertisement message [18] by the addition of a single flag bit to indicate that the router sending the Advertisement message is serving as a home agent on this link. The format of the Router Advertisement message is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- This format represents the following changes over that originally specified for Neighbor Discovery [18]: Home Agent (H) The Home Agent (H) bit is set in a Router Advertisement to indicate that the router sending this Router Advertisement is also functioning as a Mobile IPv6 home agent on this link. Reserved Reduced from a 6-bit field to a 5-bit field to account for the addition of the above bit.
7.2. Modified Prefix Information Option Format
Mobile IPv6 requires knowledge of a router's global address in building a Home Agents List as part of the dynamic home agent address discovery mechanism. However, Neighbor Discovery [18] only advertises a router's link- local address, by requiring this address to be used as the IP Source Address of each Router Advertisement. Mobile IPv6 extends Neighbor Discovery to allow a router to advertise its global address, by the addition of a single flag bit in the format of a Prefix Information option for use in Router Advertisement messages. The format of the Prefix Information option is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |L|A|R|Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This format represents the following changes over that originally specified for Neighbor Discovery [18]: Router Address (R) 1-bit router address flag. When set, indicates that the Prefix field contains a complete IP address assigned to the sending router. The indicated prefix is given by the first Prefix Length bits of the Prefix field. The router IP address has the same scope and conforms to the same lifetime values as the advertised prefix. This use of the Prefix field is compatible with its use in advertising the prefix itself, since Prefix Advertisement uses
only the leading bits. Interpretation of this flag bit is thus
independent of the processing required for the On-Link (L) and
Autonomous Address-Configuration (A) flag bits.
Reserved1
Reduced from a 6-bit field to a 5-bit field to account for the
addition of the above bit.
In a Router Advertisement, a home agent MUST, and all other routers
MAY, include at least one Prefix Information option with the Router
Address (R) bit set. Neighbor Discovery (RFC 4861 [18]) specifies
that, when including all options in a Router Advertisement causes the
size of the Advertisement to exceed the link MTU, multiple
Advertisements can be sent, each containing a subset of the Neighbor
Discovery options. Also, when sending unsolicited multicast Router
Advertisements more frequently than the limit specified in RFC 4861,
the sending router need not include all options in each of these
Advertisements. However, in both of these cases the router SHOULD
include at least one Prefix Information option with the Router
Address (R) bit set in each such advertisement, if this bit is set in
some advertisement sent by the router.
In addition, the following requirement can assist mobile nodes in
movement detection. Barring changes in the prefixes for the link,
routers that send multiple Router Advertisements with the Router
Address (R) bit set in some of the included Prefix Information
options SHOULD provide at least one option and router address that
stays the same in all of the Advertisements.
7.3. New Advertisement Interval Option Format
Mobile IPv6 defines a new Advertisement Interval option, used in
Router Advertisement messages to advertise the interval at which the
sending router sends unsolicited multicast Router Advertisements.
The format of the Advertisement Interval option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertisement Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
7
Length
8-bit unsigned integer. The length of the option (including the
type and length fields) is in units of 8 octets. The value of
this field MUST be 1.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Advertisement Interval
32-bit unsigned integer. The maximum time, in milliseconds,
between successive unsolicited Router Advertisement messages sent
by this router on this network interface. Using the conceptual
router configuration variables defined by Neighbor Discovery [18],
this field MUST be equal to the value MaxRtrAdvInterval, expressed
in milliseconds.
Routers MAY include this option in their Router Advertisements. A
mobile node receiving a Router Advertisement containing this option
SHOULD utilize the specified Advertisement Interval for that router
in its movement detection algorithm, as described in Section 11.5.1.
This option MUST be silently ignored for other Neighbor Discovery
messages.
7.4. New Home Agent Information Option Format
Mobile IPv6 defines a new Home Agent Information option, used in
Router Advertisements sent by a home agent to advertise information
specific to this router's functionality as a home agent. The format
of the Home Agent Information option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
8
Length
8-bit unsigned integer. The length of the option (including the
type and length fields) in units of 8 octets. The value of this
field MUST be 1.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Home Agent Preference
16-bit unsigned integer. The preference for the home agent
sending this Router Advertisement, for use in ordering the
addresses returned to a mobile node in the Home Agent Addresses
field of a Home Agent Address Discovery Reply message. Higher
values mean more preferable. If this option is not included in a
Router Advertisement in which the Home Agent (H) bit is set, the
preference value for this home agent MUST be considered to be 0.
Greater values indicate a more preferable home agent than lower
values.
The manual configuration of the Home Agent Preference value is
described in Section 8.4. In addition, the sending home agent MAY
dynamically set the Home Agent Preference value, for example,
basing it on the number of mobile nodes it is currently serving or
on its remaining resources for serving additional mobile nodes;
such dynamic settings are beyond the scope of this document. Any
such dynamic setting of the Home Agent Preference, however, MUST
set the preference appropriately, relative to the default Home
Agent Preference value of 0 that may be in use by some home agents
on this link (i.e., a home agent not including a Home Agent
Information option in its Router Advertisements will be considered
to have a Home Agent Preference value of 0).
Home Agent Lifetime
16-bit unsigned integer. The lifetime associated with the home
agent in units of seconds. The default value is the same as the
Router Lifetime, as specified in the main body of the Router
Advertisement. The maximum value corresponds to 18.2 hours. A
value of 0 MUST NOT be used. The Home Agent Lifetime applies only
to this router's usefulness as a home agent; it does not apply to
information contained in other message fields or options.
Home agents MAY include this option in their Router Advertisements.
This option MUST NOT be included in a Router Advertisement in which
the Home Agent (H) bit (see Section 7.1) is not set. If this option
is not included in a Router Advertisement in which the Home Agent (H)
bit is set, the lifetime for this home agent MUST be considered to be
the same as the Router Lifetime in the Router Advertisement. If
multiple Advertisements are being sent instead of a single larger
unsolicited multicast Router Advertisement, all of the multiple
Advertisements with the Router Address (R) bit set MUST include this
option with the same contents; otherwise, this option MUST be omitted
from all Advertisements.
This option MUST be silently ignored for other Neighbor Discovery
messages.
If both the Home Agent Preference and Home Agent Lifetime are set to
their default values specified above, this option SHOULD NOT be
included in the Router Advertisement messages sent by this home
agent.
7.5. Changes to Sending Router Advertisements
The Neighbor Discovery protocol specification [18] limits routers to
a minimum interval of 3 seconds between sending unsolicited multicast
Router Advertisement messages from any given network interface
(limited by MinRtrAdvInterval and MaxRtrAdvInterval), stating that:
Routers generate Router Advertisements frequently enough that
hosts will learn of their presence within a few minutes, but not
frequently enough to rely on an absence of advertisements to
detect router failure; a separate Neighbor Unreachability
Detection algorithm provides failure detection.
This limitation, however, is not suitable to providing timely
movement detection for mobile nodes. Mobile nodes detect their own
movement by learning the presence of new routers as the mobile node
moves into wireless transmission range of them (or physically
connects to a new wired network), and by learning that previous
routers are no longer reachable. Mobile nodes MUST be able to
quickly detect when they move to a link served by a new router, so
that they can acquire a new care-of address and send Binding Updates
to register this care-of address with their home agent and to notify
correspondent nodes as needed.
One method that can provide for faster movement detection is to increase the rate at which unsolicited Router Advertisements are sent. Mobile IPv6 relaxes this limit such that routers MAY send unsolicited multicast Router Advertisements more frequently. This method can be applied where the router is expecting to provide service to visiting mobile nodes (e.g., wireless network interfaces), or on which it is serving as a home agent to one or more mobile nodes (who may return home and need to hear its Advertisements). Routers supporting mobility SHOULD be able to be configured with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value to allow sending of unsolicited multicast Router Advertisements more often. The minimum allowed values are: o MinRtrAdvInterval 0.03 seconds o MaxRtrAdvInterval 0.07 seconds In the case where the minimum intervals and delays are used, the mean time between unsolicited multicast Router Advertisements is 50 ms. Use of these modified limits MUST be configurable (see also the configuration variable MinDelayBetweenRas in Section 13 that may also have to be modified accordingly). Systems where these values are available MUST NOT default to them, and SHOULD default to values specified in Neighbor Discovery (RFC 4861 [18]). Knowledge of the type of network interface and operating environment SHOULD be taken into account in configuring these limits for each network interface. This is important with some wireless links, where increasing the frequency of multicast beacons can cause considerable overhead. Routers SHOULD adhere to the intervals specified in RFC 4861 [18], if this overhead is likely to cause service degradation. Additionally, the possible low values of MaxRtrAdvInterval may cause some problems with movement detection in some mobile nodes. To ensure that this is not a problem, Routers SHOULD add 20 ms to any Advertisement Intervals sent in RAs that are below 200 ms, in order to account for scheduling granularities on both the MN and the router. Note that multicast Router Advertisements are not always required in certain wireless networks that have limited bandwidth. Mobility detection or link changes in such networks may be done at lower layers. Router advertisements in such networks SHOULD be sent only when solicited. In such networks it SHOULD be possible to disable unsolicited multicast Router Advertisements on specific interfaces. The MinRtrAdvInterval and MaxRtrAdvInterval in such a case can be set to some high values.
Home agents MUST include the Source Link-Layer Address option in all Router Advertisements they send. This simplifies the process of returning home, as discussed in Section 11.5.5. Note that according to Neighbor Discovery (RFC 4861 [18]), AdvDefaultLifetime is by default based on the value of MaxRtrAdvInterval. AdvDefaultLifetime is used in the Router Lifetime field of Router Advertisements. Given that this field is expressed in seconds, a small MaxRtrAdvInterval value can result in a zero value for this field. To prevent this, routers SHOULD keep AdvDefaultLifetime in at least one second, even if the use of MaxRtrAdvInterval would result in a smaller value.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 Quality of Service (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 round-trip 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 Sections 9.1
and 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 [18], 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 that 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 (Sections 10.1 and 10.3.1).
o Every home agent MUST be able to intercept packets (using proxy
Neighbor Discovery [18]) 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 [7] 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 [7] 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
Sections 10.1 and 10.5.1.
o Every home agent MUST be able to accept packets addressed to the
Mobile IPv6 Home-Agents anycast address [8] 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 [7].
o The node MUST be able to process type 2 routing header as defined
in Sections 6.4 and 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
Sections 11.7.1 and 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 [31] 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 [18]. When sending a packet, the Binding Cache is searched before the Neighbor Discovery conceptual Destination Cache [18]. 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. A correspondent node MAY select a smaller lifetime for the Binding Cache entry, and supply that value to the mobile node in the Binding Acknowledgment message. o A flag indicating whether or not this Binding Cache entry is a home registration entry (applicable only on nodes that 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. If invalid, 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 the 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 4443 [17]. 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 4443 [17]. (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. If the Next Header value of the Destination Option is one of the following: {50 (ESP), 51 (AH), 135 (Mobility Header)}, the packet SHOULD be processed normally. Otherwise, the packet 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. If the packet is dropped due to 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 [18] 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 determines 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
Sections 9.2 and 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 [17].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 [7], 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 that fails to satisfy this test 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 that fails to satisfy this test 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 that 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 not zero, 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, 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 indices, 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 Sections 9.2 or 9.5.1, a Binding Acknowledgement MUST NOT be sent. Otherwise, the treatment depends on the following rules. o If the Acknowledge (A) bit is set in the Binding Update, a Binding Acknowledgement MUST be sent. Otherwise, the treatment depends on the next 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 [30]. 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 that 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).
(page 89 continued on part 5)
