11.7. Processing Bindings
11.7.1. Sending Binding Updates to the Home Agent
In order to change its primary care-of address as described in
Sections 11.5.1 and 11.5.3, a mobile node MUST register this care-of
address with its home agent in order to make this its primary care-of
Also, if the mobile node wants the services of the home agent beyond
the current registration period, the mobile node should send a new
Binding Update to it well before the expiration of this period, even
if it is not changing its primary care-of address. However, if the
home agent returned a Binding Acknowledgement for the current
registration with the Status field set to 1 (accepted but prefix
discovery necessary), the mobile node should not try to register
again before it has learned the validity of its home prefixes through
mobile prefix discovery. This is typically necessary every time this
Status value is received, because information learned earlier may
To register a care-of address or to extend the lifetime of an
existing registration, the mobile node sends a packet to its home
agent containing a Binding Update, with the packet constructed as
o The Home Registration (H) bit MUST be set in the Binding Update.
o The Acknowledge (A) bit MUST be set in the Binding Update.
o The packet MUST contain a Home Address destination option, giving
the mobile node's home address for the binding.
o The care-of address for the binding MUST be used as the Source
Address in the packet's IPv6 header, unless an Alternate Care-of
Address mobility option is included in the Binding Update. This
option MUST be included in all home registrations, as the ESP
protocol will not be able to protect care-of addresses in the IPv6
header. (Mobile IPv6 implementations that know they are using
IPsec AH to protect a particular message might avoid this option.
For brevity the usage of AH is not discussed in this document.)
o If the mobile node's link-local address has the same interface
identifier as the home address for which it is supplying a new
care-of address, then the mobile node SHOULD set the Link-Local
Address Compatibility (L) bit.
o If the home address was generated using RFC 4941 , then the
link local address is unlikely to have a compatible interface
identifier. In this case, the mobile node MUST clear the Link-
Local Address Compatibility (L) bit.
o If the IPsec security associations between the mobile node and the
home agent have been established dynamically, and the mobile node
has the capability to update its endpoint in the used key
management protocol to the new care-of address every time it
moves, the mobile node SHOULD set the Key Management Mobility
Capability (K) bit in the Binding Update. Otherwise, the mobile
node MUST clear the bit.
o The value specified in the Lifetime field MUST be non-zero and
SHOULD be less than or equal to the remaining valid lifetime of
the home address and the care-of address specified for the
Mobile nodes that use dynamic home agent address discovery should
be careful with long lifetimes. If the mobile node loses the
knowledge of its binding with a specific home agent, registering a
new binding with another home agent may be impossible as the
previous home agent is still defending the existing binding.
Therefore, to ensure that mobile nodes using home agent address
discovery do not lose information about their binding, they SHOULD
de-register before losing this information, or use small
The Acknowledge (A) bit in the Binding Update requests the home agent
to return a Binding Acknowledgement in response to this Binding
Update. As described in Section 6.1.8, the mobile node SHOULD
retransmit this Binding Update to its home agent until it receives a
matching Binding Acknowledgement. Once reaching a retransmission
timeout period of MAX_BINDACK_TIMEOUT, the mobile node SHOULD restart
the process of delivering the Binding Update, but trying instead the
next home agent returned during dynamic home agent address discovery
(see Section 11.4.1). If there was only one home agent, the mobile
node instead SHOULD continue to periodically retransmit the Binding
Update at this rate until acknowledged (or until it begins attempting
to register a different primary care-of address). See Section 11.8
for information about retransmitting Binding Updates.
With the Binding Update, the mobile node requests the home agent to
serve as the home agent for the given home address. Until the
lifetime of this registration expires, the home agent considers
itself the home agent for this home address.
Each Binding Update MUST be authenticated as coming from the right
mobile node, as defined in Section 5.1. The mobile node MUST use its
home address -- either in the Home Address destination option or in
the Source Address field of the IPv6 header -- in Binding Updates
sent to the home agent. This is necessary in order to allow the
IPsec policies to be matched with the correct home address.
When sending a Binding Update to its home agent, the mobile node MUST
also create or update the corresponding Binding Update List entry, as
specified in Section 11.7.2.
The last Sequence Number value sent to the home agent in a Binding
Update is stored by the mobile node. If the sending mobile node has
no knowledge of the correct Sequence Number value, it may start at
any value. If the home agent rejects the value, it sends back a
Binding Acknowledgement with a status code 135, and the last accepted
sequence number in the Sequence Number field of the Binding
Acknowledgement. The mobile node MUST store this information and use
the next Sequence Number value for the next Binding Update it sends.
If the mobile node has additional home addresses, then the mobile
node SHOULD send an additional packet containing a Binding Update to
its home agent to register the care-of address for each such other
The home agent will only perform DAD for the mobile node's home
address when the mobile node has supplied a valid binding between its
home address and a care-of address. If some time elapses during
which the mobile node has no binding at the home agent, it might be
possible for another node to autoconfigure the mobile node's home
address. Therefore, the mobile node MUST treat the creation of a new
binding with the home agent using an existing home address, the same
as creation of a new home address. In the unlikely event that the
mobile node's home address is autoconfigured as the IPv6 address of
another network node on the home network, the home agent will reply
to the mobile node's subsequent Binding Update with a Binding
Acknowledgement containing a Status of 134 (Duplicate Address
Detection failed). In this case, the mobile node MUST NOT attempt to
re-use the same home address. It SHOULD continue to register the
care-of addresses for its other home addresses, if any. Mechanisms
outlined in "Mobile IPv6 Bootstrapping in Split Scenario"  allow
mobile nodes to acquire new home addresses to replace the one for
which Status 134 was received.
11.7.2. Correspondent Registration
When the mobile node is assured that its home address is valid, it
can initiate a correspondent registration with the purpose of
allowing the correspondent node to cache the mobile node's current
care-of address. This procedure consists of the return routability
procedure followed by a registration.
This section defines when the correspondent registration is to be
initiated and the rules to follow while it is being performed.
After the mobile node has sent a Binding Update to its home agent,
registering a new primary care-of address (as described in
Section 11.7.1), the mobile node SHOULD initiate a correspondent
registration for each node that already appears in the mobile node's
Binding Update List. The initiated procedures can be used to either
update or delete binding information in the correspondent node.
For nodes that do not appear in the mobile node's Binding Update
List, the mobile node MAY initiate a correspondent registration at
any time after sending the Binding Update to its home agent.
Considerations regarding when (and if) to initiate the procedure
depend on the specific movement and traffic patterns of the mobile
node and are outside the scope of this document.
In addition, the mobile node MAY initiate the correspondent
registration in response to receiving a packet that meets all of the
o The packet was tunneled using IPv6 encapsulation.
o The Destination Address in the tunnel (outer) IPv6 header is equal
to any of the mobile node's care-of addresses.
o The Destination Address in the original (inner) IPv6 header is
equal to one of the mobile node's home addresses.
o The Source Address in the tunnel (outer) IPv6 header differs from
the Source Address in the original (inner) IPv6 header.
o The packet does not contain a Home Test, Home Test Init, Care-of
Test, or Care-of Test Init message.
If a mobile node has multiple home addresses, it becomes important to
select the right home address to use in the correspondent
registration. The used home address MUST be the Destination Address
of the original (inner) packet.
The peer address used in the procedure MUST be determined as follows:
o If a Home Address destination option is present in the original
(inner) packet, the address from this option is used.
o Otherwise, the Source Address in the original (inner) IPv6 header
of the packet is used.
Note that the validity of the original packet is checked before
attempting to initiate a correspondent registration. For instance,
if a Home Address destination option appeared in the original packet,
then rules in Section 9.3.1 are followed.
A mobile node MAY also choose to keep its topological location
private from certain correspondent nodes, and thus need not initiate
the correspondent registration.
Upon successfully completing the return routability procedure, and
after receiving a successful Binding Acknowledgement from the home
agent, a Binding Update MAY be sent to the correspondent node.
In any Binding Update sent by a mobile node, the care-of address
(either the Source Address in the packet's IPv6 header or the Care-of
Address in the Alternate Care-of Address mobility option of the
Binding Update) MUST be set to one of the care-of addresses currently
in use by the mobile node or to the mobile node's home address. A
mobile node MAY set the care-of address differently for sending
Binding Updates to different correspondent nodes.
A mobile node MAY also send a Binding Update to such a correspondent
node, instructing it to delete any existing binding for the mobile
node from its Binding Cache, as described in Section 6.1.7. Even in
this case a successful completion of the return routability procedure
is required first.
If the care-of address is not set to the mobile node's home address,
the Binding Update requests that the correspondent node create or
update an entry for the mobile node in the correspondent node's
Binding Cache. This is done in order to record a care-of address for
use in sending future packets to the mobile node. In this case, the
value specified in the Lifetime field sent in the Binding Update
SHOULD be less than or equal to the remaining lifetime of the home
registration and the care-of address specified for the binding. The
care-of address given in the Binding Update MAY differ from the
mobile node's primary care-of address.
If the Binding Update is sent to the correspondent node, requesting
the deletion of any existing Binding Cache entry it has for the
mobile node, the care-of address is set to the mobile node's home
address and the Lifetime field set to zero. In this case, generation
of the binding management key depends exclusively on the home keygen
token (Section 5.2.5). The care-of nonce index SHOULD be set to zero
in this case. In keeping with the Binding Update creation rules
below, the care-of address MUST be set to the home address if the
mobile node is at home, or to the current care-of address if it is
away from home.
If the mobile node wants to ensure that its new care-of address has
been entered into a correspondent node's Binding Cache, the mobile
node needs to request an acknowledgement by setting the Acknowledge
(A) bit in the Binding Update.
A Binding Update is created as follows:
o The current care-of address of the mobile node MUST be sent either
in the Source Address of the IPv6 header or in the Alternate
Care-of Address mobility option.
o The Destination Address of the IPv6 header MUST contain the
address of the correspondent node.
o The Mobility Header is constructed according to rules in Sections
6.1.7 and 5.2.6, including the Binding Authorization Data
(calculated as defined in Section 6.2.7) and possibly the Nonce
Indices mobility options.
o The home address of the mobile node MUST be added to the packet in
a Home Address destination option, unless the Source Address is
the home address.
Each Binding Update MUST have a Sequence Number greater than the
Sequence Number value sent in the previous Binding Update to the same
destination address (if any). The sequence numbers are compared
modulo 2**16, as described in Section 9.5.1. There is no
requirement, however, that the Sequence Number value strictly
increase by 1 with each new Binding Update sent or received, as long
as the value stays within the window. The last Sequence Number value
sent to a destination in a Binding Update is stored by the mobile
node in its Binding Update List entry for that destination. If the
sending mobile node has no Binding Update List entry, the Sequence
Number SHOULD start at a random value. The mobile node MUST NOT use
the same Sequence Number in two different Binding Updates to the same
correspondent node, even if the Binding Updates provide different
The mobile node is responsible for the completion of the
correspondent registration, as well as any retransmissions that may
be needed (subject to the rate limitation defined in Section 11.8).
11.7.3. Receiving Binding Acknowledgements
Upon receiving a packet carrying a Binding Acknowledgement, a mobile
node MUST validate the packet according to the following tests:
o The packet meets the authentication requirements for Binding
Acknowledgements defined in Sections 6.1.8 and 5. That is, if the
Binding Update was sent to the home agent, the underlying IPsec
protection is used. If the Binding Update was sent to the
correspondent node, the Binding Authorization Data mobility option
MUST be present and have a valid value.
o The Binding Authorization Data mobility option, if present, MUST
be the last option and MUST NOT have trailing padding.
o The Sequence Number field matches the Sequence Number sent by the
mobile node to this destination address in an outstanding Binding
Update, and the Status field is not 135.
Any Binding Acknowledgement not satisfying all of these tests MUST be
When a mobile node receives a packet carrying a valid Binding
Acknowledgement, the mobile node MUST examine the Status field as
o If the Status field indicates that the Binding Update was accepted
(the Status field is less than 128), then the mobile node MUST
update the corresponding entry in its Binding Update List to
indicate that the Binding Update has been acknowledged; the mobile
node MUST then stop retransmitting the Binding Update. In
addition, if the value specified in the Lifetime field in the
Binding Acknowledgement is less than the Lifetime value sent in
the Binding Update being acknowledged, the mobile node MUST
subtract the difference between these two Lifetime values from the
remaining lifetime for the binding as maintained in the
corresponding Binding Update List entry (with a minimum value for
the Binding Update List entry lifetime of 0). That is, if the
Lifetime value sent in the Binding Update was L_update, the
Lifetime value received in the Binding Acknowledgement was L_ack,
and the current remaining lifetime of the Binding Update List
entry is L_remain, then the new value for the remaining lifetime
of the Binding Update List entry should be
max((L_remain - (L_update - L_ack)), 0)
where max(X, Y) is the maximum of X and Y. The effect of this
step is to correctly manage the mobile node's view of the
binding's remaining lifetime (as maintained in the corresponding
Binding Update List entry) so that it correctly counts down from
the Lifetime value given in the Binding Acknowledgement, but with
the timer countdown beginning at the time that the Binding Update
Mobile nodes SHOULD send a new Binding Update well before the
expiration of this period in order to extend the lifetime. This
helps to avoid disruptions in communications that might otherwise
be caused by network delays or clock drift.
o If the Binding Acknowledgement correctly passes authentication and
the Status field value is 135 (Sequence Number out of window),
then the mobile node MUST update its binding sequence number
appropriately to match the sequence number given in the Binding
Acknowledgement. Otherwise, if the Status field value is 135 but
the Binding Acknowledgement does not pass authentication, the
message MUST be silently ignored.
o If the Status field value is 1 (accepted but prefix discovery
necessary), the mobile node SHOULD send a Mobile Prefix
Solicitation message to update its information about the available
o If the Status field indicates that the Binding Update was rejected
(the Status field is greater than or equal to 128), then the
mobile node can take steps to correct the cause of the error and
retransmit the Binding Update (with a new Sequence Number value),
subject to the rate limiting restriction specified in
Section 11.8. If this is not done or it fails, then the mobile
node SHOULD record in its Binding Update List that future Binding
Updates SHOULD NOT be sent to this destination.
The treatment of a Binding Refresh Advice mobility option within the
Binding Acknowledgement depends on where the acknowledgement came
from. This option MUST be ignored if the acknowledgement came from a
correspondent node. If it came from the home agent, the mobile node
uses the Refresh Interval field in the option as a suggestion that it
SHOULD attempt to refresh its home registration at the indicated
If the acknowledgement came from the home agent, the mobile node
examines the value of the Key Management Mobility Capability (K) bit.
If this bit is not set, the mobile node SHOULD discard key management
protocol connections, if any, to the home agent. The mobile node MAY
also initiate a new key management connection.
If this bit is set, the mobile node SHOULD move its own endpoint in
the key management protocol connections to the home agent, if any.
The mobile node's new endpoint should be the new care-of address.
11.7.4. Receiving Binding Refresh Requests
When a mobile node receives a packet containing a Binding Refresh
Request message, if the mobile node has a Binding Update List entry
for the source of the Binding Refresh Request, and the mobile node
wants to retain its Binding Cache entry at the correspondent node,
then the mobile node should start a return routability procedure. If
the mobile node wants to have its Binding Cache entry removed, it can
either ignore the Binding Refresh Request and wait for the binding to
time out, or at any time, it can delete its binding from a
correspondent node with an explicit Binding Update with a zero
lifetime and the care-of address set to the home address. If the
mobile node does not know if it needs the Binding Cache entry, it can
make the decision in an implementation-dependent manner, such as
based on available resources.
Note that the mobile node should be careful not to respond to Binding
Refresh Requests for addresses not in the Binding Update List to
avoid being subjected to a denial of service attack.
If the return routability procedure completes successfully, a Binding
Update message SHOULD be sent, as described in Section 11.7.2. The
Lifetime field in this Binding Update SHOULD be set to a new
lifetime, extending any current lifetime remaining from a previous
Binding Update sent to this node (as indicated in any existing
Binding Update List entry for this node), and the lifetime SHOULD
again be less than or equal to the remaining lifetime of the home
registration and the care-of address specified for the binding. When
sending this Binding Update, the mobile node MUST update its Binding
Update List in the same way as for any other Binding Update sent by
the mobile node.
11.8. Retransmissions and Rate Limiting
The mobile node is responsible for retransmissions and rate limiting
in the return routability procedure, in registrations, and in
solicited prefix discovery.
When the mobile node sends a Mobile Prefix Solicitation, Home Test
Init, Care-of Test Init, or Binding Update for which it expects a
response, the mobile node has to determine a value for the initial
o If the mobile node is sending a Mobile Prefix Solicitation, it
SHOULD use an initial retransmission interval of
INITIAL_SOLICIT_TIMER (see Section 12).
o If the mobile node is sending a Binding Update and does not have
an existing binding at the home agent, it SHOULD use
InitialBindackTimeoutFirstReg (see Section 13) as a value for the
initial retransmission timer. This long retransmission interval
will allow the home agent to complete the Duplicate Address
Detection procedure mandated in this case, as detailed in
o Otherwise, the mobile node should use the specified value of
INITIAL_BINDACK_TIMEOUT for the initial retransmission timer.
If the mobile node fails to receive a valid matching response within
the selected initial retransmission interval, the mobile node SHOULD
retransmit the message until a response is received.
The retransmissions by the mobile node MUST use an exponential back-
off process in which the timeout period is doubled upon each
retransmission, until either the node receives a response or the
timeout period reaches the value MAX_BINDACK_TIMEOUT. The mobile
node MAY continue to send these messages at this slower rate
The mobile node SHOULD start a separate back-off process for
different message types, different home addresses, and different
care-of addresses. However, in addition an overall rate limitation
applies for messages sent to a particular correspondent node. This
ensures that the correspondent node has a sufficient amount of time
to respond when bindings for multiple home addresses are registered,
for instance. The mobile node MUST NOT send Mobility Header messages
of a particular type to a particular correspondent node more than
MAX_UPDATE_RATE times within a second.
Retransmitted Binding Updates MUST use a Sequence Number value
greater than that used for the previous transmission of this Binding
Update. Retransmitted Home Test Init and Care-of Test Init messages
MUST use new cookie values.
12. Protocol Constants
DHAAD_RETRIES 4 retransmissions
INITIAL_BINDACK_TIMEOUT 1 second
INITIAL_DHAAD_TIMEOUT 3 seconds
INITIAL_SOLICIT_TIMER 3 seconds
MAX_BINDACK_TIMEOUT 32 seconds
MAX_DELETE_BCE_TIMEOUT 10 seconds
MAX_NONCE_LIFETIME 240 seconds
MAX_TOKEN_LIFETIME 210 seconds
MAX_RO_FAILURE 3 retries
MAX_RR_BINDING_LIFETIME 420 seconds
MAX_UPDATE_RATE 3 times
PREFIX_ADV_RETRIES 3 retransmissions
PREFIX_ADV_TIMEOUT 3 seconds
13. Protocol Configuration Variables
MaxMobPfxAdvInterval Default: 86,400 seconds
MinDelayBetweenRAs Default: 3 seconds,
Min: 0.03 seconds
MinMobPfxAdvInterval Default: 600 seconds
InitialBindackTimeoutFirstReg Default: 1.5 seconds
Home agents MUST allow the first three variables to be configured by
system management, and mobile nodes MUST allow the last variable to
be configured by system management.
The default value for InitialBindackTimeoutFirstReg has been
calculated as 1.5 times the default value of RetransTimer, as
specified in Neighbor Discovery (RFC 4861 ) times the default
value of DupAddrDetectTransmits, as specified in Stateless Address
Autoconfiguration (RFC 4862 ).
The value MinDelayBetweenRAs overrides the value of the protocol
constant MIN_DELAY_BETWEEN_RAS, as specified in Neighbor Discovery
(RFC 4861 ). This variable SHOULD be set to MinRtrAdvInterval,
if MinRtrAdvInterval is less than 3 seconds.
14. IANA Considerations
This document defines a new IPv6 protocol, the Mobility Header,
described in Section 6.1. This protocol has been assigned protocol
This document also creates a new name space "Mobility Header Type",
for the MH Type field in the Mobility Header. The current message
types are described starting from Section 6.1.2, and are the
0 Binding Refresh Request
1 Home Test Init
2 Care-of Test Init
3 Home Test
4 Care-of Test
5 Binding Update
6 Binding Acknowledgement
7 Binding Error
Future values of the MH Type can be allocated using Standards Action
or IESG Approval .
Furthermore, each mobility message may contain mobility options as
described in Section 6.2. This document defines a new name space
"Mobility Option" to identify these options. The current mobility
options are defined starting from Section 6.2.2 and are the
2 Binding Refresh Advice
3 Alternate Care-of Address
4 Nonce Indices
5 Authorization Data
Future values of the Option Type can be allocated using Standards
Action or IESG Approval .
Finally, this document creates a third new name space "Status Code"
for the Status field in the Binding Acknowledgement message. The
current values are listed in Section 6.1.8 and are the following:
0 Binding Update accepted
1 Accepted but prefix discovery necessary
128 Reason unspecified
129 Administratively prohibited
130 Insufficient resources
131 Home registration not supported
132 Not home subnet
133 Not home agent for this mobile node
134 Duplicate Address Detection failed
135 Sequence number out of window
136 Expired home nonce index
137 Expired care-of nonce index
138 Expired nonces
139 Registration type change disallowed
174 Invalid Care-of Address
Future values of the Status field can be allocated using Standards
Action or IESG Approval .
All fields labeled "Reserved" are only to be assigned through
Standards Action or IESG Approval.
This document also defines a new IPv6 destination option, the Home
Address option, described in Section 6.3. This option has been
assigned the Option Type value 0xC9.
This document also defines a new IPv6 type 2 routing header,
described in Section 6.4. The value 2 has been allocated by IANA.
In addition, this document defines four ICMP message types, two used
as part of the dynamic home agent address discovery mechanism, and
two used in lieu of Router Solicitations and Advertisements when the
mobile node is away from the home link. These messages have been
assigned ICMPv6 type numbers from the informational message range:
o The Home Agent Address Discovery Request message, described in
o The Home Agent Address Discovery Reply message, described in
o The Mobile Prefix Solicitation, described in Section 6.7; and
o The Mobile Prefix Advertisement, described in Section 6.8.
This document also defines two new Neighbor Discovery  options,
which have been assigned Option Type values within the option
numbering space for Neighbor Discovery messages:
o The Advertisement Interval option, described in Section 7.3; and
o The Home Agent Information option, described in Section 7.4.
15. Security Considerations
Any mobility solution must protect itself against misuses of the
mobility features and mechanisms. In Mobile IPv6, most of the
potential threats are concerned with false bindings, usually
resulting in denial-of-service attacks. Some of the threats also
pose potential for man-in-the-middle, hijacking, confidentiality, and
impersonation attacks. The main threats this protocol protects
against are the following:
o Threats involving Binding Updates sent to home agents and
correspondent nodes. For instance, an attacker might claim that a
certain mobile node is currently at a different location than it
really is. If a home agent accepts such spoofed information sent
to it, the mobile node might not get traffic destined to it.
Similarly, a malicious (mobile) node might use the home address of
a victim node in a forged Binding Update sent to a correspondent
These pose threats against confidentiality, integrity, and
availability. That is, an attacker might learn the contents of
packets destined to another node by redirecting the traffic to
itself. Furthermore, an attacker might use the redirected packets
in an attempt to set itself as a man in the middle between a
mobile and a correspondent node. This would allow the attacker to
impersonate the mobile node, leading to integrity and availability
A malicious (mobile) node might also send Binding Updates in which
the care-of address is set to the address of a victim node. If
such Binding Updates were accepted, the malicious node could lure
the correspondent node into sending potentially large amounts of
data to the victim; the correspondent node's replies to messages
sent by the malicious mobile node will be sent to the victim host
or network. This could be used to cause a distributed denial-of-
service attack. For example, the correspondent node might be a
site that will send a high-bandwidth stream of video to anyone who
asks for it. Note that the use of flow-control protocols such as
TCP does not necessarily defend against this type of attack,
because the attacker can fake the acknowledgements. Even keeping
TCP initial sequence numbers secret does not help, because the
attacker can receive the first few segments (including the ISN) at
its own address, and only then redirect the stream to the victim's
address. These types of attacks may also be directed to networks
instead of nodes. Further variations of this threat are described
elsewhere  .
An attacker might also attempt to disrupt a mobile node's
communications by replaying a Binding Update that the node had
sent earlier. If the old Binding Update was accepted, packets
destined for the mobile node would be sent to its old location as
opposed to its current location.
A malicious mobile node associated to multiple home agents could
create a routing loop amongst them. This can be achieved when a
mobile node binds one home address located on a first home agent
to another home address on a second home agent. This type of
binding will force the home agents to route the same packet among
each other without knowledge that a routing loop has been created.
Such looping problem is limited to cases where a mobile node has
multiple home agents and is permitted to be associated with the
multiple home agents. For the single home agent case, a policy at
the home agent would prevent the binding of one home address to
another home address hosted by the same home agent.
The potential problems caused by such routing loops in this
scenario can be substantially reduced by use of the Tunnel-Limit
Option specified in RFC 2473 .
In conclusion, there are denial-of-service, man-in-the-middle,
confidentiality, and impersonation threats against the parties
involved in sending legitimate Binding Updates, the threat of
routing loops when there are multiple home agents, and denial-of-
service threats against any other party.
o Threats associated with payload packets: Payload packets exchanged
with mobile nodes are exposed to similar threats as that of
regular IPv6 traffic. However, Mobile IPv6 introduces the Home
Address destination option and a new routing header type (type 2),
and uses tunneling headers in the payload packets. The protocol
must protect against potential new threats involving the use of
Third parties become exposed to a reflection threat via the Home
Address destination option, unless appropriate security
precautions are followed. The Home Address destination option
could be used to direct response traffic toward a node whose IP
address appears in the option. In this case, ingress filtering
would not catch the forged "return address"  .
A similar threat exists with the tunnels between the mobile node
and the home agent. An attacker might forge tunnel packets
between the mobile node and the home agent, making it appear that
the traffic is coming from the mobile node when it is not. Note
that an attacker who is able to forge tunnel packets would
typically also be able to forge packets that appear to come
directly from the mobile node. This is not a new threat as such.
However, it may make it easier for attackers to escape detection
by avoiding ingress filtering and packet tracing mechanisms.
Furthermore, spoofed tunnel packets might be used to gain access
to the home network.
Finally, a routing header could also be used in reflection
attacks, and in attacks designed to bypass firewalls. The
generality of the regular routing header would allow circumvention
of IP-address based rules in firewalls. It would also allow
reflection of traffic to other nodes. These threats exist with
routing headers in general, even if the usage that Mobile IPv6
requires is safe.
o Threats associated with dynamic home agent and mobile prefix
o Threats against the Mobile IPv6 security mechanisms themselves: An
attacker might, for instance, lure the participants into executing
expensive cryptographic operations or allocating memory for the
purpose of keeping state. The victim node would have no resources
left to handle other tasks.
As a fundamental service in an IPv6 stack, Mobile IPv6 is expected to
be deployed in most nodes of the IPv6 Internet. The above threats
should therefore be considered as being applicable to the whole
It should also be noted that some additional threats result from
movements as such, even without the involvement of mobility
protocols. Mobile nodes must be capable to defend themselves in the
networks that they visit, as typical perimeter defenses applied in
the home network no longer protect them.
This specification provides a series of features designed to mitigate
the risk introduced by the threats listed above. The main security
features are the following:
o Reverse tunneling as a mandatory feature.
o Protection of Binding Updates sent to home agents.
o Protection of Binding Updates sent to correspondent nodes.
o Protection against reflection attacks that use the Home Address
o Protection of tunnels between the mobile node and the home agent.
o Closing routing header vulnerabilities.
o Mitigating denial-of-service threats to the Mobile IPv6 security
The support for encrypted reverse tunneling (see Section 11.3.1)
allows mobile nodes to defeat certain kinds of traffic analysis.
Protecting those Binding Updates that are sent to home agents and
those that are sent to arbitrary correspondent nodes requires very
different security solutions due to the different situations. Mobile
nodes and home agents are naturally expected to be subject to the
network administration of the home domain.
Thus, they can and are supposed to have a security association that
can be used to reliably authenticate the exchanged messages. See
Section 5.1 for the description of the protocol mechanisms, and
Section 15.3 below for a discussion of the resulting level of
It is expected that Mobile IPv6 route optimization will be used on a
global basis between nodes belonging to different administrative
domains. It would be a very demanding task to build an
authentication infrastructure on this scale. Furthermore, a
traditional authentication infrastructure cannot be easily used to
authenticate IP addresses because IP addresses can change often. It
is not sufficient to just authenticate the mobile nodes;
authorization to claim the right to use an address is needed as well.
Thus, an "infrastructureless" approach is necessary. The chosen
infrastructureless method is described in Section 5.2, and
Section 15.4 discusses the resulting security level and the design
rationale of this approach.
Specific rules guide the use of the Home Address destination option,
the routing header, and the tunneling headers in the payload packets.
These rules are necessary to remove the vulnerabilities associated
with their unrestricted use. The effect of the rules is discussed in
Sections 15.7, 15.8, and 15.9.
Denial-of-service threats against Mobile IPv6 security mechanisms
themselves concern mainly the Binding Update procedures with
correspondent nodes. The protocol has been designed to limit the
effects of such attacks, as will be described in Section 15.4.5.