11.3. Packet Processing
11.3.1. Sending Packets While Away from Home
While a mobile node is away from home, it continues to use its home
address, as well as also using one or more care-of addresses. When
sending a packet while away from home, a mobile node MAY choose among
these in selecting the address that it will use as the source of the
packet, as follows:
o Protocols layered over IP will generally treat the mobile node's
home address as its IP source address for most packets. For
packets sent that are part of transport-level connections
established while the mobile node was at home, the mobile node
MUST use its home address. Likewise, for packets sent that are
part of transport-level connections that the mobile node may still
be using after moving to a new location, the mobile node SHOULD
use its home address in this way. If a binding exists, the mobile
node SHOULD send the packets directly to the correspondent node.
Otherwise, if a binding does not exist, the mobile node MUST use
o The mobile node MAY choose to directly use one of its care-of
addresses as the source of the packet, not requiring the use of a
Home Address option in the packet. This is particularly useful
for short-term communication that may easily be retried if it
fails. Using the mobile node's care-of address as the source for
such queries will generally have a lower overhead than using the
mobile node's home address, since no extra options need to be used
in either the query or its reply. Such packets can be routed
normally, directly between their source and destination without
relying on Mobile IPv6. If application running on the mobile node
has no particular knowledge that the communication being sent fits
within this general type of communication, however, the mobile
node should not use its care-of address as the source of the
packet in this way.
The choice of the most efficient communications method is
application specific, and outside the scope of this specification.
The APIs necessary for controlling the choice are also out of
scope. One example of such an API is described in the IPv6 Socket
API for Source Address Selection specification .
o While not at its home link, the mobile node MUST NOT use the Home
Address destination option when communicating with link-local
Similarly, the mobile node MUST NOT use the Home Address
destination option for IPv6 Neighbor Discovery  packets.
Detailed operation of these cases is described later in this section
and also discussed in .
For packets sent by a mobile node while it is at home, no special
Mobile IPv6 processing is required. Likewise, if the mobile node
uses any address other than one of its home addresses as the source
of a packet sent while away from home, no special Mobile IPv6
processing is required. In either case, the packet is simply
addressed and transmitted in the same way as any normal IPv6 packet.
For packets sent by the mobile node sent while away from home using
the mobile node's home address as the source, special Mobile IPv6
processing of the packet is required. This can be done in the
following two ways:
This manner of delivering packets does not require going through
the home network, and typically will enable faster and more
The mobile node needs to ensure that a Binding Cache entry exists
for its home address so that the correspondent node can process
the packet (Section 9.3.1 specifies the rules for Home Address
Destination Option Processing at a correspondent node). The
mobile node SHOULD examine its Binding Update List for an entry
that fulfills the following conditions:
* The Source Address field of the packet being sent is equal to
the home address in the entry.
* The Destination Address field of the packet being sent is equal
to the address of the correspondent node in the entry.
* One of the current care-of addresses of the mobile node appears
as the care-of address in the entry.
* The entry indicates that a binding has been successfully
* The remaining lifetime of the binding is greater than zero.
When these conditions are met, the mobile node knows that the
correspondent node has a suitable Binding Cache entry.
A mobile node SHOULD arrange to supply the home address in a Home
Address option, and MUST set the IPv6 header's Source Address
field to the care-of address that the mobile node has registered
to be used with this correspondent node. The correspondent node
will then use the address supplied in the Home Address option to
serve the function traditionally done by the Source IP address in
the IPv6 header. The mobile node's home address is then supplied
to higher protocol layers and applications.
* Construct the packet using the mobile node's home address as
the packet's Source Address, in the same way as if the mobile
node were at home. This includes the calculation of upper-
layer checksums using the home address as the value of the
* Insert a Home Address option into the packet with the Home
Address field copied from the original value of the Source
Address field in the packet.
* Change the Source Address field in the packet's IPv6 header to
one of the mobile node's care-of addresses. This will
typically be the mobile node's current primary care-of address,
but MUST be an address assigned to the interface on the link
By using the care-of address as the Source Address in the IPv6
header, with the mobile node's home address instead in the Home
Address option, the packet will be able to safely pass through any
router implementing ingress filtering .
This is the mechanism that tunnels the packets via the home agent.
It is not as efficient as the above mechanism, but is needed if
there is no binding yet with the correspondent node.
This mechanism is used for packets that have the mobile node's
home address as the Source Address in the IPv6 header, or with
multicast control protocol packets as described in Section 11.3.4.
* The packet is sent to the home agent using IPv6 encapsulation
* The Source Address in the tunnel packet is the primary care-of
address as registered with the home agent.
* The Destination Address in the tunnel packet is the home
Then, the home agent will pass the encapsulated packet to the
11.3.2. Interaction with Outbound IPsec Processing
This section sketches the interaction between outbound Mobile IPv6
processing and outbound IP Security (IPsec) processing for packets
sent by a mobile node while away from home. Any specific
implementation MAY use algorithms and data structures other than
those suggested here, but its processing MUST be consistent with the
effect of the operation described here and with the relevant IPsec
specifications. In the steps described below, it is assumed that
IPsec is being used in transport mode  and that the mobile node is
using its home address as the source for the packet (from the point
of view of higher protocol layers or applications, as described in
o The packet is created by higher-layer protocols and applications
(e.g., by TCP) as if the mobile node were at home and Mobile IPv6
were not being used.
o Determine the outgoing interface for the packet. (Note that the
selection between reverse tunneling and route optimization may
imply different interfaces, particularly if tunnels are considered
interfaces as well.)
o As part of outbound packet processing in IP, the packet is
compared against the IPsec security policy database to determine
what processing is required for the packet .
o If IPsec processing is required, the packet is either mapped to an
existing security association (or SA bundle), or a new SA (or SA
bundle) is created for the packet, according to the procedures
defined for IPsec.
o Since the mobile node is away from home, the mobile is using
either reverse tunneling or route optimization to reach the
If reverse tunneling is used, the packet is constructed in the
normal manner and then tunneled through the home agent.
If route optimization is in use, the mobile node inserts a Home
Address destination option into the packet, replacing the Source
Address in the packet's IP header with the care-of address used
with this correspondent node, as described in Section 11.3.1. The
Destination Options header in which the Home Address destination
option is inserted MUST appear in the packet after the routing
header, if present, and before the IPsec (AH  or ESP )
header, so that the Home Address destination option is processed
by the destination node before the IPsec header is processed.
Finally, once the packet is fully assembled, the necessary IPsec
authentication (and encryption, if required) processing is
performed on the packet, initializing the Authentication Data in
the IPsec header.
The treatment of destination options described in RFC 4302 is
extended as follows. The AH authentication data MUST be
calculated as if the following were true:
* the IPv6 source address in the IPv6 header contains the mobile
node's home address, and
* the Home Address field of the Home Address destination option
(Section 6.3) contains the new care-of address.
o This allows, but does not require, the receiver of the packet
containing a Home Address destination option to exchange the two
fields of the incoming packet to reach the above situation,
simplifying processing for all subsequent packet headers.
However, such an exchange is not required, as long as the result
of the authentication calculation remains the same.
When an automated key management protocol is used to create new
security associations for a peer, it is important to ensure that the
peer can send the key management protocol packets to the mobile node.
This may not be possible if the peer is the home agent of the mobile
node and the purpose of the security associations would be to send a
Binding Update to the home agent. Packets addressed to the home
address of the mobile node cannot be used before the Binding Update
has been processed. For the default case of using IKEv2  as the
automated key management protocol, such problems can be avoided by
the following requirements when communicating with its home agent:
o When the mobile node is away from home, it MUST use its care-of
address as the Source Address of all packets it sends as part of
the key management protocol (without use of Mobile IPv6 for these
packets, as suggested in Section 11.3.1).
The Key Management Mobility Capability (K) bit in Binding Updates and
Acknowledgements can be used to avoid the need to rerun IKEv2 upon
11.3.3. Receiving Packets While Away from Home
While away from home, a mobile node will receive packets addressed to
its home address, by one of two methods:
o Packets sent by a correspondent node that does not have a Binding
Cache entry for the mobile node will be sent to the home address,
captured by the home agent and tunneled to the mobile node.
o Packets sent by a correspondent node that has a Binding Cache
entry for the mobile node that contains the mobile node's current
care-of address will be sent by the correspondent node using a
type 2 routing header. The packet will be addressed to the mobile
node's care-of address, with the final hop in the routing header
directing the packet to the mobile node's home address; the
processing of this last hop of the routing header is entirely
internal to the mobile node, since the care-of address and home
address are both addresses within the mobile node.
For packets received by the first method, the mobile node MUST check
that the IPv6 source address of the tunneled packet is the IP address
of its home agent. In this method, the mobile node may also send a
Binding Update to the original sender of the packet as described in
Section 11.7.2 and subject to the rate limiting defined in
Section 11.8. The mobile node MUST also process the received packet
in the manner defined for IPv6 encapsulation , which will result
in the encapsulated (inner) packet being processed normally by upper-
layer protocols within the mobile node as if it had been addressed
(only) to the mobile node's home address.
For packets received by the second method, the following rules will
result in the packet being processed normally by upper-layer
protocols within the mobile node as if it had been addressed to the
mobile node's home address.
A node receiving a packet addressed to itself (i.e., one of the
node's addresses is in the IPv6 destination field) follows the next
header chain of headers and processes them. When it encounters a
type 2 routing header during this processing, it performs the
following checks. If any of these checks fail, the node MUST
silently discard the packet.
o The length field in the routing header is exactly 2.
o The segments left field in the routing header is 1 on the wire.
(But implementations may process the routing header so that the
value may become 0 after the routing header has been processed,
but before the rest of the packet is processed.)
o The Home Address field in the routing header is one of the node's
home addresses, if the segments left field was 1. Thus, in
particular the address field is required to be a unicast routable
Once the above checks have been performed, the node swaps the IPv6
destination field with the Home Address field in the routing header,
decrements segments left by one from the value it had on the wire,
and resubmits the packet to IP for processing the next header.
Conceptually, this follows the same model as in RFC 2460. However,
in the case of the type 2 routing header, this can be simplified
since it is known that the packet will not be forwarded to a
The definition of AH requires the sender to calculate the AH
integrity check value of a routing header in the same way it appears
in the receiver after it has processed the header. Since IPsec
headers follow the routing header, any IPsec processing will operate
on the packet with the home address in the IP destination field and
segments left being zero. Thus, the AH calculations at the sender
and receiver will have an identical view of the packet.
11.3.4. Routing Multicast Packets
A mobile node that is connected to its home link functions in the
same way as any other (stationary) node. Thus, when it is at home, a
mobile node functions identically to other multicast senders and
receivers. Therefore, this section describes the behavior of a
mobile node that is not on its home link.
In order to receive packets sent to some multicast group, a mobile
node must join that multicast group. One method, in which a mobile
node MAY join the group, is via a (local) multicast router on the
foreign link being visited. In this case, the mobile node MUST use
its care-of address and MUST NOT use the Home Address destination
option when sending MLD packets .
Alternatively, a mobile node MAY join multicast groups via a
bidirectional tunnel to its home agent. The mobile node tunnels its
multicast group membership control packets (such as those defined in
 or in ) to its home agent, and the home agent forwards
multicast packets down the tunnel to the mobile node. A mobile node
MUST NOT tunnel multicast group membership control packets until (1)
the mobile node has a binding in place at the home agent, and (2) the
latter sends at least one multicast group membership control packet
via the tunnel. Once this condition is true, the mobile node SHOULD
assume it does not change as long as the binding does not expire.
A mobile node that wishes to send packets to a multicast group also
has two options:
1. Send directly on the foreign link being visited.
To do this, the application uses the care-of address as a source
address for multicast traffic, just as it would use a stationary
address. This requires that the application either knows the
care-of address, or uses an API such as the IPv6 Socket API for
Source Address Selection specification  to request that the
care-of address be used as the source address in transmitted
packets. The mobile node MUST NOT use the Home Address
destination option in such traffic.
2. Send via a tunnel to its home agent.
Because multicast routing in general depends upon the Source
Address used in the IPv6 header of the multicast packet, a mobile
node that tunnels a multicast packet to its home agent MUST use
its home address as the IPv6 Source Address of the inner
Note that direct sending from the foreign link is only applicable
while the mobile node is at that foreign link. This is because the
associated multicast tree is specific to that source location and any
change of location and source address will invalidate the source-
specific tree or branch and the application context of the other
multicast group members.
This specification does not provide mechanisms to enable such local
multicast session to survive hand-off and to seamlessly continue from
a new care-of address on each new foreign link. Any such mechanism,
developed as an extension to this specification, needs to take into
account the impact of fast moving mobile nodes on the Internet
multicast routing protocols and their ability to maintain the
integrity of source specific multicast trees and branches.
While the use of bidirectional tunneling can ensure that multicast
trees are independent of the mobile nodes movement, in some case such
tunneling can have adverse effects. The latency of specific types of
multicast applications (such as multicast-based discovery protocols)
will be affected when the round-trip time between the foreign subnet
and the home agent is significant compared to that of the topology to
be discovered. In addition, the delivery tree from the home agent in
such circumstances relies on unicast encapsulation from the agent to
the mobile node. Therefore, bandwidth usage is inefficient compared
to the native multicast forwarding in the foreign multicast system.
11.3.5. Receiving ICMP Error Messages
Any node that does not recognize the Mobility header will return an
ICMP Parameter Problem, Code 1, message to the sender of the packet.
If the mobile node receives such an ICMP error message in response to
a return routability procedure or Binding Update, it SHOULD record in
its Binding Update List that future Binding Updates SHOULD NOT be
sent to this destination. Such Binding Update List entries SHOULD be
removed after a period of time in order to allow for retrying route
New Binding Update List entries MUST NOT be created as a result of
receiving ICMP error messages.
Correspondent nodes that have participated in the return routability
procedure MUST implement the ability to correctly process received
packets containing a Home Address destination option. Therefore,
correctly implemented correspondent nodes should always be able to
recognize Home Address options. If a mobile node receives an ICMP
Parameter Problem, Code 2, message from some node indicating that it
does not support the Home Address option, the mobile node SHOULD log
the error and then discard the ICMP message.
11.3.6. Receiving Binding Error Messages
When a mobile node receives a packet containing a Binding Error
message, it should first check if the mobile node has a Binding
Update List entry for the source of the Binding Error message. If
the mobile node does not have such an entry, it MUST ignore the
message. This is necessary to prevent a waste of resources, e.g., on
return routability procedure due to spoofed Binding Error messages.
Otherwise, if the message Status field was 1 (unknown binding for
Home Address destination option), the mobile node should perform one
of the following three actions:
o If the Binding Error Message was sent by the home agent, the
mobile node SHOULD send a Binding Update to the home agent
according to Section 11.7.1.
o If the mobile node has recent upper-layer progress information,
which indicates that communications with the correspondent node
are progressing, it MAY ignore the message. This can be done in
order to limit the damage that spoofed Binding Error messages can
cause to ongoing communications.
o If the mobile node has no upper-layer progress information, it
MUST remove the entry and route further communications through the
home agent. It MAY also optionally start a return routability
procedure (see Section 5.2).
If the message Status field was 2 (unrecognized MH Type value), the
mobile node should perform one of the following two actions:
o If the mobile node is not expecting an acknowledgement or response
from the correspondent node, the mobile node SHOULD ignore this
o Otherwise, the mobile node SHOULD cease the use of any extensions
to this specification. If no extensions had been used, the mobile
node should cease the attempt to use route optimization.
11.4. Home Agent and Prefix Management
11.4.1. Dynamic Home Agent Address Discovery
Sometimes when the mobile node needs to send a Binding Update to its
home agent to register its new primary care-of address, as described
in Section 11.7.1, the mobile node may not know the address of any
router on its home link that can serve as a home agent for it. For
example, some nodes on its home link may have been reconfigured while
the mobile node has been away from home, such that the router that
was operating as the mobile node's home agent has been replaced by a
different router serving this role.
In this case, the mobile node MAY attempt to discover the address of
a suitable home agent on its home link. To do so, the mobile node
sends an ICMP Home Agent Address Discovery Request message to the
Mobile IPv6 Home-Agents anycast address  for its home subnet
prefix. As described in Section 10.5, the home agent on its home
link that receives this Request message will return an ICMP Home
Agent Address Discovery Reply message. This message gives the
addresses for the home agents operating on the home link.
The mobile node, upon receiving this Home Agent Address Discovery
Reply message, MAY then send its home registration Binding Update to
any of the unicast IP addresses listed in the Home Agent Addresses
field in the Reply. For example, the mobile node MAY attempt its
home registration to each of these addresses, in turn, until its
registration is accepted. The mobile node sends a Binding Update to
an address and waits for the matching Binding Acknowledgement, moving
on to the next address if there is no response. The mobile node
MUST, however, wait at least InitialBindackTimeoutFirstReg seconds
(see Section 13) before sending a Binding Update to the next home
agent. In trying each of the returned home agent addresses, the
mobile node SHOULD try each of them in the order they appear in the
Home Agent Addresses field in the received Home Agent Address
Discovery Reply message. In order to do this, the mobile node SHOULD
store the list of home agents for later use in case the home agent
currently managing the mobile node's care-of address forwarding
should become unavailable. The list MAY be stored, along with any
available lifetime information for the home agent addresses, in
nonvolatile memory to survive reboots by the mobile node.
If the mobile node has a current registration with some home agent
(the Lifetime for that registration has not yet expired), then the
mobile node MUST attempt any new registration first with that home
agent. If that registration attempt fails (e.g., timed out or
rejected), the mobile node SHOULD then reattempt this registration
with another home agent. If the mobile node knows of no other
suitable home agent, then it MAY attempt the dynamic home agent
address discovery mechanism described above.
If, after a mobile node transmits a Home Agent Address Discovery
Request message to the Home Agents Anycast address, it does not
receive a corresponding Home Agent Address Discovery Reply message
within INITIAL_DHAAD_TIMEOUT (see Section 12) seconds, the mobile
node MAY retransmit the same Request message to the same anycast
address. This retransmission MAY be repeated up to a maximum of
DHAAD_RETRIES (see Section 12) attempts. Each retransmission MUST be
delayed by twice the time interval of the previous retransmission.
11.4.2. Sending Mobile Prefix Solicitations
When a mobile node has a home address that is about to become
invalid, it SHOULD send a Mobile Prefix Solicitation to its home
agent in an attempt to acquire fresh routing prefix information. The
new information also enables the mobile node to participate in
renumbering operations affecting the home network, as described in
The mobile node MUST use the Home Address destination option to carry
its home address. The mobile node MUST support and SHOULD use IPsec
to protect the solicitation. The mobile node MUST set the Identifier
field in the ICMP header to a random value.
As described in Section 11.7.2, Binding Updates sent by the mobile
node to other nodes MUST use a lifetime no greater than the remaining
lifetime of its home registration of its primary care-of address.
The mobile node SHOULD further limit the lifetimes that it sends on
any Binding Updates to be within the remaining valid lifetime (see
Section 10.6.2) for the prefix in its home address.
When the lifetime for a changed prefix decreases, and the change
would cause cached bindings at correspondent nodes in the Binding
Update List to be stored past the newly shortened lifetime, the
mobile node MUST issue a Binding Update to all such correspondent
These limits on the binding lifetime serve to prohibit use of a
mobile node's home address after it becomes invalid.
11.4.3. Receiving Mobile Prefix Advertisements
Section 10.6 describes the operation of a home agent to support boot
time configuration and renumbering a mobile node's home subnet while
the mobile node is away from home. The home agent sends Mobile
Prefix Advertisements to the mobile node while away from home, giving
"important" Prefix Information options that describe changes in the
prefixes in use on the mobile node's home link.
The Mobile Prefix Solicitation is similar to the Router Solicitation
used in Neighbor Discovery , except it is routed from the mobile
node on the visited network to the home agent on the home network by
usual unicast routing rules.
When a mobile node receives a Mobile Prefix Advertisement, it MUST
validate it according to the following test:
o The Source Address of the IP packet carrying the Mobile Prefix
Advertisement is the same as the home agent address to which the
mobile node last sent an accepted home registration Binding Update
to register its primary care-of address. Otherwise, if no such
registrations have been made, it SHOULD be the mobile node's
stored home agent address, if one exists. Otherwise, if the
mobile node has not yet discovered its home agent's address, it
MUST NOT accept Mobile Prefix Advertisements.
o The packet MUST have a type 2 routing header and SHOULD be
protected by an IPsec header as described in Sections 5.4 and 6.8.
o If the ICMP Identifier value matches the ICMP Identifier value of
the most recently sent Mobile Prefix Solicitation and no other
advertisement has yet been received for this value, then the
advertisement is considered to be solicited and will be processed
Otherwise, the advertisement is unsolicited, and MUST be
discarded. In this case the mobile node SHOULD send a Mobile
Any received Mobile Prefix Advertisement not meeting these tests MUST
be silently discarded.
For an accepted Mobile Prefix Advertisement, the mobile node MUST
process Managed Address Configuration (M), Other Stateful
Configuration (O), and the Prefix Information Options as if they
arrived in a Router Advertisement  on the mobile node's home
link. (This specification does not, however, describe how to acquire
home addresses through stateful protocols.) Such processing may
result in the mobile node configuring a new home address, although
due to separation between preferred lifetime and valid lifetime, such
changes should not affect most communications by the mobile node, in
the same way as for nodes that are at home.
This specification assumes that any security associations and
security policy entries that may be needed for new prefixes have been
pre-configured in the mobile node. Note that while dynamic key
management avoids the need to configure new security associations, it
is still necessary to add policy entries to protect the
communications involving the home address(es). Mechanisms for
setting up these entries are outside the scope of this specification.
11.5.1. Movement Detection
The primary goal of movement detection is to detect L3 handovers.
This section does not attempt to specify a fast movement detection
algorithm that will function optimally for all types of applications,
link layers, and deployment scenarios; instead, it describes a
generic method that uses the facilities of IPv6 Neighbor Discovery,
including Router Discovery and Neighbor Unreachability Detection. At
the time of this writing, this method is considered well enough
understood to recommend for standardization; however, it is expected
that future versions of this specification or other specifications
may contain updated versions of the movement detection algorithm that
have better performance.
Generic movement detection uses Neighbor Unreachability Detection to
detect when the default router is no longer bidirectionally
reachable, in which case the mobile node must discover a new default
router (usually on a new link). However, this detection only occurs
when the mobile node has packets to send, and in the absence of
frequent Router Advertisements or indications from the link-layer,
the mobile node might become unaware of an L3 handover that occurred.
Therefore, the mobile node should supplement this method with other
information whenever it is available to the mobile node (e.g., from
lower protocol layers).
When the mobile node detects an L3 handover, it performs Duplicate
Address Detection  on its link-local address, selects a new
default router as a consequence of Router Discovery, and then
performs prefix discovery with that new router to form new care-of
address(es) as described in Section 11.5.3. It then registers its
new primary care-of address with its home agent as described in
Section 11.7.1. After updating its home registration, the mobile
node then updates associated mobility bindings in correspondent nodes
that it is performing route optimization with as specified in
Due to the temporary packet flow disruption and signaling overhead
involved in updating mobility bindings, the mobile node should avoid
performing an L3 handover until it is strictly necessary.
Specifically, when the mobile node receives a Router Advertisement
from a new router that contains a different set of on-link prefixes,
if the mobile node detects that the currently selected default router
on the old link is still bidirectionally reachable, it should
generally continue to use the old router on the old link rather than
switch away from it to use a new default router.
Mobile nodes can use the information in received Router
Advertisements to detect L3 handovers. In doing so the mobile node
needs to consider the following issues:
o There might be multiple routers on the same link. Thus, hearing a
new router does not necessarily constitute an L3 handover.
o When there are multiple routers on the same link they might
advertise different prefixes. Thus, even hearing a new router
with a new prefix might not be a reliable indication of an L3
o The link-local addresses of routers are not globally unique, hence
after completing an L3 handover the mobile node might continue to
receive Router Advertisements with the same link-local source
address. This might be common if routers use the same link-local
address on multiple interfaces. This issue can be avoided when
routers use the Router Address (R) bit, since that provides a
global address of the router.
In addition, the mobile node should consider the following events as
indications that an L3 handover may have occurred. Upon receiving
such indications, the mobile node needs to perform Router Discovery
to discover routers and prefixes on the new link, as described in
Section 6.3.7 of Neighbor Discovery (RFC 4861 ).
o If Router Advertisements that the mobile node receives include an
Advertisement Interval option, the mobile node may use its
Advertisement Interval field as an indication of the frequency
with which it should expect to continue to receive future
Advertisements from that router. This field specifies the minimum
rate (the maximum amount of time between successive
Advertisements) that the mobile node should expect. If this
amount of time elapses without the mobile node receiving any
Advertisement from this router, the mobile node can be sure that
at least one Advertisement sent by the router has been lost. The
mobile node can then implement its own policy to determine how
many lost Advertisements from its current default router
constitute an L3 handover indication.
o Neighbor Unreachability Detection determines that the default
router is no longer reachable.
o With some types of networks, notification that an L2 handover has
occurred might be obtained from lower-layer protocols or device
driver software within the mobile node. While further details
around handling L2 indications as movement hints is an item for
further study, at the time of writing this specification the
following is considered reasonable:
An L2 handover indication may or may not imply L2 movement and L2
movement may or may not imply L3 movement; the correlations might
be a function of the type of L2 but might also be a function of
actual deployment of the wireless topology.
Unless it is well-known that an L2 handover indication is likely
to imply L3 movement, instead of immediately multicasting a router
solicitation it may be better to attempt to verify whether the
default router is still bidirectionally reachable. This can be
accomplished by sending a unicast Neighbor Solicitation and
waiting for a Neighbor Advertisement with the Solicited flag set.
Note that this is similar to Neighbor Unreachability detection,
but it does not have the same state machine, such as the STALE
If the default router does not respond to the Neighbor
Solicitation it makes sense to proceed to multicasting a Router
11.5.2. Home Link Detection
When an MN detects that it has arrived on a new link using the
movement detection algorithm in use (Section 11.5.1) or on
bootstrapping, it performs the following steps to determine if it is
on the home link.
o The MN performs the procedure described in Section 11.5.3 and
configures an address. It also keeps track of all the on-link
prefix(es) received in the RA along with their prefix lengths.
o If the home prefix has not been statically configured the MN uses
some form of bootstrapping procedure (e.g., RFC 5026 ) to
determine the home prefix.
o Given the availability of the home prefix, the MN checks whether
or not the home prefix matches one of the prefixes received in the
RA. If it does, the MN concludes that it is connected to the home
11.5.3. Forming New Care-of Addresses
After detecting that it has moved a mobile node SHOULD generate a new
primary care-of address using normal IPv6 mechanisms. This SHOULD
also be done when the current primary care-of address becomes
deprecated. A mobile node MAY form a new primary care-of address at
any time, but a mobile node MUST NOT send a Binding Update about a
new care-of address to its home agent more than MAX_UPDATE_RATE times
within a second.
In addition, a mobile node MAY form new non-primary care-of addresses
even when it has not switched to a new default router. A mobile node
can have only one primary care-of address at a time (which is
registered with its home agent), but it MAY have an additional
care-of address for any or all of the prefixes on its current link.
Furthermore, since a wireless network interface may actually allow a
mobile node to be reachable on more than one link at a time (i.e.,
within wireless transmitter range of routers on more than one
separate link), a mobile node MAY have care-of addresses on more than
one link at a time. The use of more than one care-of address at a
time is described in Section 11.5.4.
As described in Section 4, in order to form a new care-of address, a
mobile node MAY use either stateless  or stateful (e.g., DHCPv6
) Address Autoconfiguration. If a mobile node needs to use a
source address (other than the unspecified address) in packets sent
as a part of address autoconfiguration, it MUST use an IPv6 link-
local address rather than its own IPv6 home address.
RFC 4862  specifies that in normal processing for Duplicate
Address Detection, the node SHOULD delay sending the initial Neighbor
Solicitation message by a random delay between 0 and
MAX_RTR_SOLICITATION_DELAY. Since delaying Duplicate Address
Detection (DAD) can result in significant delays in configuring a new
care-of address when the mobile node moves to a new link, the mobile
node preferably SHOULD NOT delay DAD when configuring a new care-of
address. The mobile node SHOULD delay according to the mechanisms
specified in RFC 4862 unless the implementation has a behavior that
desynchronizes the steps that happen before the DAD in the case that
multiple nodes experience handover at the same time. Such
desynchronizing behaviors might be due to random delays in the L2
protocols or device drivers, or due to the movement detection
mechanism that is used.
11.5.4. Using Multiple Care-of Addresses
As described in Section 11.5.3, a mobile node MAY use more than one
care-of address at a time. Particularly in the case of many wireless
networks, a mobile node effectively might be reachable through
multiple links at the same time (e.g., with overlapping wireless
cells), on which different on-link subnet prefixes may exist. The
mobile node MUST ensure that its primary care-of address always has a
prefix that is advertised by its current default router. After
selecting a new primary care-of address, the mobile node MUST send a
Binding Update containing that care-of address to its home agent.
The Binding Update MUST have the Home Registration (H) and
Acknowledge (A) bits set its home agent, as described on
To assist with smooth handovers, a mobile node SHOULD retain its
previous primary care-of address as a (non-primary) care-of address,
and SHOULD still accept packets at this address, even after
registering its new primary care-of address with its home agent.
This is reasonable, since the mobile node could only receive packets
at its previous primary care-of address if it were indeed still
connected to that link. If the previous primary care-of address was
allocated using stateful Address Autoconfiguration , the mobile
node may not wish to release the address immediately upon switching
to a new primary care-of address.
Whenever a mobile node determines that it is no longer reachable
through a given link, it SHOULD invalidate all care-of addresses
associated with address prefixes that it discovered from routers on
the unreachable link that are not in the current set of address
prefixes advertised by the (possibly new) current default router.
11.5.5. Returning Home
A mobile node detects that it has returned to its home link through
the movement detection algorithm in use (Section 11.5.2), when the
mobile node detects that its home subnet prefix is again on-link. To
be able to send and receive packets using its home address from the
home link, the mobile node MUST send a Binding Update to its home
agent to instruct its home agent to no longer intercept or tunnel
packets for it. Until the mobile node sends such a de-registration
Binding Update, it MUST NOT attempt to send and receive packets using
its home address from the home link. The home agent will continue to
intercept all packets sent to the mobile's home address and tunnel
them to the previously registered care-of address.
In this home registration, the mobile node MUST set the Acknowledge
(A) and Home Registration (H) bits, set the Lifetime field to zero,
and set the care-of address for the binding to the mobile node's own
home address. The mobile node MUST use its home address as the
source address in the Binding Update.
When sending this Binding Update to its home agent, the mobile node
must be careful in how it uses Neighbor Solicitation  (if needed)
to learn the home agent's link-layer address, since the home agent
will be currently configured to intercept packets to the mobile
node's home address using Proxy Neighbor Discovery (Proxy ND). In
particular, the mobile node is unable to use its home address as the
Source Address in the Neighbor Solicitation until the home agent
stops defending the home address.
Neighbor Solicitation by the mobile node for the home agent's address
will normally not be necessary, since the mobile node has already
learned the home agent's link-layer address from a Source Link-Layer
Address option in a Router Advertisement. However, if there are
multiple home agents it may still be necessary to send a
solicitation. In this special case of the mobile node returning
home, the mobile node MUST multicast the packet, and in addition set
the Source Address of this Neighbor Solicitation to the unspecified
address (0:0:0:0:0:0:0:0). The target of the Neighbor Solicitation
MUST be set to the mobile node's home address. The destination IP
address MUST be set to the Solicited-Node multicast address .
The home agent will send a multicast Neighbor Advertisement back to
the mobile node with the Solicited (S) flag set to zero. In any
case, the mobile node SHOULD record the information from the Source
Link-Layer Address option or from the advertisement, and set the
state of the Neighbor Cache entry for the home agent to REACHABLE.
The mobile node then sends its Binding Update to the home agent's
link-layer address, instructing its home agent to no longer serve as
a home agent for it. By processing this Binding Update, the home
agent will cease defending the mobile node's home address for
Duplicate Address Detection and will no longer respond to Neighbor
Solicitations for the mobile node's home address. The mobile node is
then the only node on the link receiving packets at the mobile node's
home address. In addition, when returning home prior to the
expiration of a current binding for its home address, and configuring
its home address on its network interface on its home link, the
mobile node MUST NOT perform Duplicate Address Detection on its own
home address, in order to avoid confusion or conflict with its home
agent's use of the same address. This rule also applies to the
derived link-local address of the mobile node, if the Link Local
Address Compatibility (L) bit was set when the binding was created.
If the mobile node returns home after the bindings for all of its
care-of addresses have expired, then it SHOULD perform DAD.
After the mobile node sends the Binding Update, it MUST be prepared
to reply to Neighbor Solicitations for its home address. Such
replies MUST be sent using a unicast Neighbor Advertisement to the
sender's link-layer address. It is necessary to reply, since sending
the Binding Acknowledgement from the home agent may require
performing Neighbor Discovery, and the mobile node may not be able to
distinguish Neighbor Solicitations coming from the home agent from
other Neighbor Solicitations. Note that a race condition exists
where both the mobile node and the home agent respond to the same
solicitations sent by other nodes; this will be only temporary,
however, until the Binding Update is accepted.
After receiving the Binding Acknowledgement for its Binding Update to
its home agent, the mobile node MUST multicast onto the home link (to
the all-nodes multicast address) a Neighbor Advertisement , to
advertise the mobile node's own link-layer address for its own home
address. The Target Address in this Neighbor Advertisement MUST be
set to the mobile node's home address, and the Advertisement MUST
include a Target Link-layer Address option specifying the mobile
node's link-layer address. The mobile node MUST multicast such a
Neighbor Advertisement for each of its home addresses, as defined by
the current on-link prefixes, including its link-local address. The
Solicited (S) flag in these Advertisements MUST NOT be set, since
they were not solicited by any Neighbor Solicitation. The Override
(O) flag in these Advertisements MUST be set, indicating that the
Advertisements SHOULD override any existing Neighbor Cache entries at
any node receiving them.
Since multicasting on the local link (such as Ethernet) is typically
not guaranteed to be reliable, the mobile node MAY retransmit these
Neighbor Advertisements  up to MAX_NEIGHBOR_ADVERTISEMENT times
to increase their reliability. It is still possible that some nodes
on the home link will not receive any of these Neighbor
Advertisements, but these nodes will eventually be able to recover
through use of Neighbor Unreachability Detection .
Note that the tunnel via the home agent typically stops operating at
the same time that the home registration is deleted.
11.6. Return Routability Procedure
This section defines the rules that the mobile node must follow when
performing the return routability procedure. Section 11.7.2
describes the rules when the return routability procedure needs to be
11.6.1. Sending Test Init Messages
A mobile node that initiates a return routability procedure MUST send
(in parallel) a Home Test Init message and a Care-of Test Init
message. However, if the mobile node has recently received (see
Section 5.2.7) one or both home or care-of keygen tokens, and
associated nonce indices for the desired addresses, it MAY reuse
them. Therefore, the return routability procedure may in some cases
be completed with only one message pair. It may even be completed
without any messages at all, if the mobile node has a recent home
keygen token and has previously visited the same care-of address so
that it also has a recent care-of keygen token. If the mobile node
intends to send a Binding Update with the Lifetime set to zero and
the care-of address equal to its home address -- such as when
returning home -- sending a Home Test Init message is sufficient. In
this case, generation of the binding management key depends
exclusively on the home keygen token (Section 5.2.5).
A Home Test Init message MUST be created as described in
A Care-of Test Init message MUST be created as described in
Section 6.1.4. When sending a Home Test Init or Care-of Test Init
message, the mobile node MUST record in its Binding Update List the
following fields from the messages:
o The IP address of the node to which the message was sent.
o The home address of the mobile node. This value will appear in
the Source Address field of the Home Test Init message. When
sending the Care-of Test Init message, this address does not
appear in the message, but represents the home address for which
the binding is desired.
o The time at which each of these messages was sent.
o The cookies used in the messages.
Note that a single Care-of Test Init message may be sufficient even
when there are multiple home addresses. In this case the mobile node
MAY record the same information in multiple Binding Update List
11.6.2. Receiving Test Messages
Upon receiving a packet carrying a Home Test message, a mobile node
MUST validate the packet according to the following tests:
o The Source Address of the packet belongs to a correspondent node
for which the mobile node has a Binding Update List entry with a
state indicating that return routability procedure is in progress.
Note that there may be multiple such entries.
o The Binding Update List indicates that no home keygen token has
been received yet.
o The Destination Address of the packet has the home address of the
mobile node, and the packet has been received in a tunnel from the
o The Home Init Cookie field in the message matches the value stored
in the Binding Update List.
Any Home Test message not satisfying all of these tests MUST be
silently ignored. Otherwise, the mobile node MUST record the Home
Nonce Index and home keygen token in the Binding Update List. If the
Binding Update List entry does not have a care-of keygen token, the
mobile node SHOULD continue waiting for the Care-of Test message.
Upon receiving a packet carrying a Care-of Test message, a mobile
node MUST validate the packet according to the following tests:
o The Source Address of the packet belongs to a correspondent node
for which the mobile node has a Binding Update List entry with a
state indicating that return routability procedure is in progress.
Note that there may be multiple such entries.
o The Binding Update List indicates that no care-of keygen token has
been received yet.
o The Destination Address of the packet is the current care-of
address of the mobile node.
o The Care-of Init Cookie field in the message matches the value
stored in the Binding Update List.
Any Care-of Test message not satisfying all of these tests MUST be
silently ignored. Otherwise, the mobile node MUST record the Care-of
Nonce Index and care-of keygen token in the Binding Update List. If
the Binding Update List entry does not have a home keygen token, the
mobile node SHOULD continue waiting for the Home Test message.
If after receiving either the Home Test or the Care-of Test message
and performing the above actions, the Binding Update List entry has
both the home and the care-of keygen tokens, the return routability
procedure is complete. The mobile node SHOULD then proceed with
sending a Binding Update as described in Section 11.7.2.
Correspondent nodes from the time before this specification was
published may not support the Mobility Header protocol. These nodes
will respond to Home Test Init and Care-of Test Init messages with an
ICMP Parameter Problem code 1. The mobile node SHOULD take such
messages as an indication that the correspondent node cannot provide
route optimization, and revert back to the use of bidirectional
11.6.3. Protecting Return Routability Packets
The mobile node MUST support the protection of Home Test and Home
Test Init messages as described in Section 10.4.6.
When IPsec is used to protect return routability signaling or payload
packets, the mobile node MUST set the source address it uses for the
outgoing tunnel packets to the current primary care-of address. The
mobile node starts to use a new primary care-of address immediately
after sending a Binding Update to the home agent to register this new