RFC 6275
Mobility Support in IPv6
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 [18]. 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 [18] 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 [18].
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 [19] 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 [18]. 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.
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 choose to omit 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 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.
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, and
the Binding Update came from a mobile node on the same 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).
When a mobile node sends a Binding Update to refresh the binding from
the visited link and soon after moves to the home link and sends a
de-registration Binding Update, a race condition can happen if the
first Binding Update gets delayed. The delayed Binding Update can
cause the home agent to create a new Binding Cache entry for a mobile
node that had just attached to the home link and successfully deleted the binding. This would prevent the mobile node from using its home address from the home link. In order to prevent this, the home agent SHOULD NOT remove the Binding Cache entry immediately after receiving the de-registration Binding Update from the mobile node. It SHOULD mark the Binding Cache entry as invalid, and MUST stop intercepting packets on the mobile node's home link that are addressed to the mobile node (Section 10.4.1). The home agent should wait for MAX_DELETE_BCE_TIMEOUT (Section 12) seconds before removing the Binding Cache entry completely. In the scenario described above, if the home agent receives the delayed Binding Update that the mobile node sent from the visited link, it would reject the message since the sequence number would be less than the last received de- registration Binding Update from the home link. The home agent would then send a Binding Acknowledgment with status '135' (Sequence number out of window) to the care-of address on the visited link. The mobile node can continue using the home address from the home link.10.4. Packet Processing
10.4.1. Intercepting Packets for a Mobile Node
While a node is serving as the home agent for a 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 have performed Duplicate Address Detection (as specified in Section 10.3.1), and subsequently it MUST multicast onto the home link a Neighbor Advertisement message [18] on behalf of the mobile node. For the home address specified in the Binding Update, the home agent sends a Neighbor Advertisement message [18] 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 [18] 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 (S) flag in the Advertisement MUST NOT be set, since
it was not solicited by any Neighbor Solicitation.
o The Override (O) flag 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
[18]) 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 [18].
While a node is serving as a home agent for some mobile node, the
home agent uses IPv6 Neighbor Discovery [18] 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 [18].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 [7]. 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 [7] 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). 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 address. Multicast packets addressed to a multicast address with link-local scope [16], 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 [16]), 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 Multicast Listener Discovery (MLD) [9] or in other protocols such as [41]. 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 that 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 security association (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 [31] 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 that 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 implement either 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 [7].
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.
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 [3] specific to the tunnel interface (the node's attachment to the tunnel [6]).10.5. Dynamic Home Agent Address Discovery
This section describes an optional mechanism by which a home agent can help mobile nodes to discover the addresses of other home agents on the mobile node's home network. 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; the mobile node uses the list as described in Section 11.4.1. 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 [18]. 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 [18], 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 [18].
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 [8] 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 [6]. 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 [17]).
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
Advertisement 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 Neighbor Discovery (RFC 4861 [18]) 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 4861.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 that 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
that 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 that 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.11. Mobile Node Operation
11.1. Conceptual Data Structures
Each mobile node MUST maintain a Binding Update List. The Binding Update List records information for each Binding Update sent by this mobile node, in which the lifetime of the binding has not yet expired. The Binding Update List includes all bindings sent by the mobile node to either its home agent or correspondent nodes. It also contains Binding Updates that are waiting for the completion of the return routability procedure before they can be sent. However, for multiple Binding Updates sent to the same destination address, the Binding Update List contains only the most recent Binding Update (i.e., with the greatest Sequence Number value) sent to that destination. The Binding Update List MAY be implemented in any manner consistent with the external behavior described in this document. Each Binding Update List entry conceptually contains the following fields: o The IP address of the node to which a Binding Update was sent. o The home address for which that Binding Update was sent. o The care-of address sent in that Binding Update. This value is necessary for the mobile node to determine if it has sent a Binding Update while giving its new care-of address to this destination after changing its care-of address. o The initial value of the Lifetime field sent in that Binding Update. o The remaining lifetime of that binding. This lifetime is initialized from the Lifetime value sent in the Binding Update and is decremented until it reaches zero, at which time this entry MUST be deleted from the Binding Update List.
o The maximum value of the Sequence Number field sent in previous
Binding Updates to this destination. The Sequence Number field is
16 bits long and all comparisons between Sequence Number values
MUST be performed modulo 2**16 (see Section 9.5.1).
o The time at which a Binding Update was last sent to this
destination, as needed to implement the rate limiting restriction
for sending Binding Updates.
o The state of any retransmissions needed for this Binding Update.
This state includes the time remaining until the next
retransmission attempt for the Binding Update and the current
state of the exponential back-off mechanism for retransmissions.
o A flag specifying whether or not future Binding Updates should be
sent to this destination. The mobile node sets this flag in the
Binding Update List entry when it receives an ICMP Parameter
Problem, Code 1, error message in response to a return routability
message or Binding Update sent to that destination, as described
in Section 11.3.5.
The Binding Update List is used to determine whether a particular
packet is sent directly to the correspondent node or tunneled via the
home agent (see Section 11.3.1).
The Binding Update list also conceptually contains the following data
related to running the return routability procedure. This data is
relevant only for Binding Updates sent to correspondent nodes.
o The time at which a Home Test Init or Care-of Test Init message
was last sent to this destination, as needed to implement the rate
limiting restriction for the return routability procedure.
o The state of any retransmissions needed for this return
routability procedure. This state includes the time remaining
until the next retransmission attempt and the current state of the
exponential back-off mechanism for retransmissions.
o Cookie values used in the Home Test Init and Care-of Test Init
messages.
o Home and care-of keygen tokens received from the correspondent
node.
o Home and care-of nonce indices received from the correspondent
node.
o The time at which each of the tokens and nonces were received from
the correspondent node, as needed to implement reuse while moving.
11.2. Processing Mobility Headers
All IPv6 mobile nodes MUST observe the rules described in Section 9.2
when processing Mobility Headers.
(page 110 continued on part 6)
