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  times
the default value of DupAddrDetectTransmits .
The value MinDelayBetweenRAs overrides the value of the protocol
constant MIN_DELAY_BETWEEN_RAS, as specified in RFC 2461 . 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 described 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
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 [27, 34].
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.
In conclusion, there are Denial-of-Service, Man-in-the-Middle,
Confidentiality, and Impersonation threats against the parties
involved in sending legitimate Binding Updates, 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, 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" [36, 32].
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
Section 15.7, Section 15.8, and Section 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.
15.3. Binding Updates to Home Agent
Signaling between the mobile node and the home agent requires message
integrity. This is necessary to assure the home agent that a Binding
Update is from a legitimate mobile node. In addition, correct
ordering and anti-replay protection are optionally needed.
IPsec ESP protects the integrity of the Binding Updates and Binding
Acknowledgements by securing mobility messages between the mobile
node and the home agent.
IPsec can provide anti-replay protection only if dynamic keying is
used (which may not always be the case). IPsec does not guarantee
correct ordering of packets, only that they have not been replayed.
Because of this, sequence numbers within the Mobile IPv6 messages are
used to ensure correct ordering (see Section 5.1). However, if the
16 bit Mobile IPv6 sequence number space is cycled through, or the
home agent reboots and loses its state regarding the sequence
numbers, replay and reordering attacks become possible. The use of
dynamic keying, IPsec anti-replay protection, and the Mobile IPv6
sequence numbers can together prevent such attacks. It is also
recommended that use of non-volatile storage be considered for home
agents, to avoid losing their state.
A sliding window scheme is used for the sequence numbers. The
protection against replays and reordering attacks without a key
management mechanism works when the attacker remembers up to a
maximum of 2**15 Binding Updates.
The above mechanisms do not show that the care-of address given in
the Binding Update is correct. This opens the possibility for
Denial-of-Service attacks against third parties. However, since the
mobile node and home agent have a security association, the home
agent can always identify an ill-behaving mobile node. This allows
the home agent operator to discontinue the mobile node's service, and
possibly take further actions based on the business relationship with
the mobile node's owner.
Note that the use of a single pair of manually keyed security
associations conflicts with the generation of a new home address 
for the mobile node, or with the adoption of a new home subnet
prefix. This is because IPsec security associations are bound to the
used addresses. While certificate-based automatic keying alleviates
this problem to an extent, it is still necessary to ensure that a
given mobile node cannot send Binding Updates for the address of
another mobile node. In general, this leads to the inclusion of home
addresses in certificates in the Subject AltName field. This again
limits the introduction of new addresses without either manual or
automatic procedures to establish new certificates. Therefore, this
specification restricts the generation of new home addresses (for any
reason) to those situations where a security association or
certificate for the new address already exists. (Appendix B.4 lists
the improvement of security for new addresses as one of the future
developments for Mobile IPv6.)
Support for IKE has been specified as optional. The following should
be observed about the use of manual keying:
o As discussed above, with manually keyed IPsec, only a limited form
of protection exists against replay and reordering attacks. A
vulnerability exists if either the sequence number space is cycled
through, or if the home agent reboots and forgets its sequence
numbers (and uses volatile memory to store the sequence numbers).
Assuming the mobile node moves continuously every 10 minutes, it
takes roughly 455 days before the sequence number space has been
cycled through. Typical movement patterns rarely reach this high
o A mobile node and its home agent belong to the same domain. If
this were not the case, manual keying would not be possible ,
but in Mobile IPv6 only these two parties need to know the
manually configured keys. Similarly, we note that Mobile IPv6
employs standard block ciphers in IPsec, and is not vulnerable to
problems associated with stream ciphers and manual keying.
o It is expected that the owner of the mobile node and the
administrator of the home agent agree on the used keys and other
parameters with some off-line mechanism.
The use of IKEv1 with Mobile IPv6 is documented in more detail in
. The following should be observed from the use of IKEv1:
o It is necessary to prevent a mobile node from claiming another
mobile node's home address. The home agent must verify that the
mobile node trying to negotiate the SA for a particular home
address is authorized for that home address. This implies that
even with the use of IKE, a policy entry needs to be configured
for each home address served by the home agent.
It may be possible to include home addresses in the Subject
AltName field of certificate to avoid this. However,
implementations are not guaranteed to support the use of a
particular IP address (care-of address) while another address
(home address) appears in the certificate. In any case, even this
approach would require user-specific tasks in the certificate
o If preshared secret authentication is used, IKEv1 main mode cannot
be used. Aggressive mode or group preshared secrets need to be
used with corresponding security implications instead.
Note that, like many other issues, this is a general IKEv1 issue
related to the ability to use different IP addresses, and not
specifically related to Mobile IPv6. For further information, see
Section 4.4 in .
o Due to the problems outlined in Section 11.3.2, IKE phase 1
between the mobile node and its home agent is established using
the mobile node's current care-of address. This implies that when
the mobile node moves to a new location, it may have to re-
establish phase 1. A Key Management Mobility Capability (K) flag
is provided for implementations that can update the IKE phase 1
endpoints without re-establishing phase 1, but the support for
this behavior is optional.
o When certificates are used, IKE fragmentation can occur as
discussed in Section 7 in .
o Nevertheless, even if per-mobile node configuration is required
with IKE, an important benefit of IKE is that it automates the
negotiation of cryptographic parameters, including the SPIs,
cryptographic algorithms, and so on. Thus, less configuration
information is needed.
o The frequency of movements in some link layers or deployment
scenarios may be high enough to make replay and reordering attacks
possible, if only manual keying is used. IKE SHOULD be used in
such cases. Potentially vulnerable scenarios involve continuous
movement through small cells, or uncontrolled alternation between
available network attachment points.
o Similarly, in some deployment scenarios the number of mobile nodes
may be very large. In these cases, it can be necessary to use
automatic mechanisms to reduce the management effort in the
administration of cryptographic parameters, even if some per-
mobile node configuration is always needed. IKE SHOULD also be
used in such cases.
o Other automatic key management mechanisms exist beyond IKEv1, but
this document does not address the issues related to them. We
note, however, that most of the above discussion applies to IKEv2
 as well, at least as it is currently specified.
15.4. Binding Updates to Correspondent Nodes
The motivation for designing the return routability procedure was to
have sufficient support for Mobile IPv6, without creating significant
new security problems. The goal for this procedure was not to
protect against attacks that were already possible before the
introduction of Mobile IPv6.
The next sections will describe the security properties of the used
method, both from the point of view of possible on-path attackers who
can see those cryptographic values that have been sent in the clear
(Section 15.4.2 and Section 15.4.3) and from the point of view of
other attackers (Section 15.4.6).
The chosen infrastructureless method verifies that the mobile node is
"live" (that is, it responds to probes) at its home and care-of
addresses. Section 5.2 describes the return routability procedure in
detail. The procedure uses the following principles:
o A message exchange verifies that the mobile node is reachable at
its addresses, i.e., is at least able to transmit and receive
traffic at both the home and care-of addresses.
o The eventual Binding Update is cryptographically bound to the
tokens supplied in the exchanged messages.
o Symmetric exchanges are employed to avoid the use of this protocol
in reflection attacks. In a symmetric exchange, the responses are
always sent to the same address the request was sent from.
o The correspondent node operates in a stateless manner until it
receives a fully authorized Binding Update.
o Some additional protection is provided by encrypting the tunnels
between the mobile node and home agent with IPsec ESP. As the
tunnel also transports the nonce exchanges, the ability of
attackers to see these nonces is limited. For instance, this
prevents attacks from being launched from the mobile node's
current foreign link, even when no link-layer confidentiality is
The resulting level of security is in theory the same even without
this additional protection: the return routability tokens are
still exposed only to one path within the whole Internet.
However, the mobile nodes are often found on an insecure link,
such as a public access Wireless LAN. Thus, in many cases, this
addition makes a practical difference.
For further information about the design rationale of the return
routability procedure, see [27, 34, 33, 32]. The mechanisms used
have been adopted from these documents.
15.4.2. Achieved Security Properties
The return routability procedure protects Binding Updates against all
attackers who are unable to monitor the path between the home agent
and the correspondent node. The procedure does not defend against
attackers who can monitor this path. Note that such attackers are in
any case able to mount an active attack against the mobile node when
it is at its home location. The possibility of such attacks is not
an impediment to the deployment of Mobile IPv6 because these attacks
are possible regardless of whether or not Mobile IPv6 is in use.
This procedure also protects against Denial-of-Service attacks in
which the attacker pretends to be mobile, but uses the victim's
address as the care-of address. This would cause the correspondent
node to send the victim some unexpected traffic. This procedure
defends against these attacks by requiring at least the passive
presence of the attacker at the care-of address or on the path from
the correspondent to the care-of address. Normally, this will be the
15.4.3. Comparison to Regular IPv6 Communications
This section discusses the protection offered by the return
routability method by comparing it to the security of regular IPv6
communications. We will divide vulnerabilities into three classes:
(1) those related to attackers on the local network of the mobile
node, home agent, or the correspondent node, (2) those related to
attackers on the path between the home network and the correspondent
node, and (3) off-path attackers, i.e., the rest of the Internet.
We will now discuss the vulnerabilities of regular IPv6
communications. The on-link vulnerabilities of IPv6 communications
include Denial-of-Service, Masquerading, Man-in-the-Middle,
Eavesdropping, and other attacks. These attacks can be launched
through spoofing Router Discovery, Neighbor Discovery and other IPv6
mechanisms. Some of these attacks can be prevented with the use of
cryptographic protection in the packets.
A similar situation exists with on-path attackers. That is, without
cryptographic protection, the traffic is completely vulnerable.
Assuming that attackers have not penetrated the security of the
Internet routing protocols, attacks are much harder to launch from
off-path locations. Attacks that can be launched from these
locations are mainly Denial-of-Service attacks, such as flooding and/
or reflection attacks. It is not possible for an off-path attacker
to become a Man-in-the-Middle.
Next, we will consider the vulnerabilities that exist when IPv6 is
used together with Mobile IPv6 and the return routability procedure.
On the local link, the vulnerabilities are the same as those in IPv6,
but Masquerade and Man-in-the-Middle attacks can now also be launched
against future communications, and not just against current
communications. If a Binding Update was sent while the attacker was
present on the link, its effects remain for the lifetime of the
binding. This happens even if the attacker moves away from the link.
In contrast, an attacker who uses only plain IPv6 generally has to
stay on the link in order to continue the attack. Note that in order
to launch these new attacks, the IP address of the victim must be
known. This makes this attack feasible, mainly in the context of
well-known interface IDs, such as those already appearing in the
traffic on the link or registered in the DNS.
On-path attackers can exploit similar vulnerabilities as in regular
IPv6. There are some minor differences, however. Masquerade, Man-
in-the-Middle, and Denial-of-Service attacks can be launched with
just the interception of a few packets, whereas in regular IPv6 it is
necessary to intercept every packet. The effect of the attacks is
the same regardless of the method, however. In any case, the most
difficult task an attacker faces in these attacks is getting on the
The vulnerabilities for off-path attackers are the same as in regular
IPv6. Those nodes that are not on the path between the home agent
and the correspondent node will not be able to receive the home
address probe messages.
In conclusion, we can state the following main results from this
o Return routability prevents any off-path attacks beyond those that
are already possible in regular IPv6. This is the most important
result, preventing attackers on the Internet from exploiting any
o Vulnerabilities to attackers on the home agent link, the
correspondent node link, and the path between them are roughly the
same as in regular IPv6.
o However, one difference is that in basic IPv6 an on-path attacker
must be constantly present on the link or the path, whereas with
Mobile IPv6, an attacker can leave a binding behind after moving
For this reason, this specification limits the creation of
bindings to at most MAX_TOKEN_LIFETIME seconds after the last
routability check has been performed, and limits the duration of a
binding to at most MAX_RR_BINDING_LIFETIME seconds. With these
limitations, attackers cannot take any practical advantages of
o There are some other minor differences, such as an effect to the
Denial-of-Service vulnerabilities. These can be considered to be
o The path between the home agent and a correspondent node is
typically easiest to attack on the links at either end, in
particular if these links are publicly accessible wireless LANs.
Attacks against the routers or switches on the path are typically
harder to accomplish. The security on layer 2 of the links plays
then a major role in the resulting overall network security.
Similarly, security of IPv6 Neighbor and Router Discovery on these
links has a large impact. If these were secured using some new
technology in the future, this could change the situation
regarding the easiest point of attack.
For a more in-depth discussion of these issues, see .
15.4.4. Replay Attacks
The return routability procedure also protects the participants
against replayed Binding Updates. The attacker is unable replay the
same message due to the sequence number which is a part of the
Binding Update. It is also unable to modify the Binding Update since
the MAC verification would fail after such a modification.
Care must be taken when removing bindings at the correspondent node,
however. If a binding is removed while the nonce used in its
creation is still valid, an attacker could replay the old Binding
Update. Rules outlined in Section 5.2.8 ensure that this cannot
15.4.5. Denial-of-Service Attacks
The return routability procedure has protection against resource
exhaustion Denial-of-Service attacks. The correspondent nodes do not
retain any state about individual mobile nodes until an authentic
Binding Update arrives. This is achieved through the construct of
keygen tokens from the nonces and node keys that are not specific to
individual mobile nodes. The keygen tokens can be reconstructed by
the correspondent node, based on the home and care-of address
information that arrives with the Binding Update. This means that
the correspondent nodes are safe against memory exhaustion attacks
except where on-path attackers are concerned. Due to the use of
symmetric cryptography, the correspondent nodes are relatively safe
against CPU resource exhaustion attacks as well.
Nevertheless, as  describes, there are situations in which it is
impossible for the mobile and correspondent nodes to determine if
they actually need a binding or whether they just have been fooled
into believing so by an attacker. Therefore, it is necessary to
consider situations where such attacks are being made.
Even if route optimization is a very important optimization, it is
still only an optimization. A mobile node can communicate with a
correspondent node even if the correspondent refuses to accept any
Binding Updates. However, performance will suffer because packets
from the correspondent node to the mobile node will be routed via the
mobile's home agent rather than a more direct route. A correspondent
node can protect itself against some of these resource exhaustion
attacks as follows. If the correspondent node is flooded with a
large number of Binding Updates that fail the cryptographic integrity
checks, it can stop processing Binding Updates. If a correspondent
node finds that it is spending more resources on checking bogus
Binding Updates than it is likely to save by accepting genuine
Binding Updates, then it may silently discard some or all Binding
Updates without performing any cryptographic operations.
Layers above IP can usually provide additional information to help
decide if there is a need to establish a binding with a specific
peer. For example, TCP knows if the node has a queue of data that it
is trying to send to a peer. An implementation of this specification
is not required to make use of information from higher protocol
layers, but some implementations are likely to be able to manage
resources more effectively by making use of such information.
We also require that all implementations be capable of
administratively disabling route optimization.
15.4.6. Key Lengths
Attackers can try to break the return routability procedure in many
ways. Section 15.4.2 discusses the situation where the attacker can
see the cryptographic values sent in the clear, and Section 15.4.3
discusses the impact this has on IPv6 communications. This section
discusses whether attackers can guess the correct values without
While the return routability procedure is in progress, 64 bit cookies
are used to protect spoofed responses. This is believed to be
sufficient, given that to blindly spoof a response a very large
number of messages would have to be sent before success would be
The tokens used in the return routability procedure provide together
128 bits of information. This information is used internally as
input to a hash function to produce a 160 bit quantity suitable for
producing the keyed hash in the Binding Update using the HMAC_SHA1
algorithm. The final keyed hash length is 96 bits. The limiting
factors in this case are the input token lengths and the final keyed
hash length. The internal hash function application does not reduce
The 96 bit final keyed hash is of typical size and is believed to be
secure. The 128 bit input from the tokens is broken in two pieces,
the home keygen token and the care-of keygen token. An attacker can
try to guess the correct cookie value, but again this would require a
large number of messages (an the average 2**63 messages for one or
2**127 for two). Furthermore, given that the cookies are valid only
for a short period of time, the attack has to keep a high constant
message rate to achieve a lasting effect. This does not appear
When the mobile node is returning home, it is allowed to use just the
home keygen token of 64 bits. This is less than 128 bits, but
attacking it blindly would still require a large number of messages
to be sent. If the attacker is on the path and capable of seeing the
Binding Update, it could conceivably break the keyed hash with brute
force. However, in this case the attacker has to be on the path,
which appears to offer easier ways for denial-of-service than
preventing route optimization.
15.5. Dynamic Home Agent Address Discovery
The dynamic home agent address discovery function could be used to
learn the addresses of home agents in the home network.
The ability to learn addresses of nodes may be useful to attackers
because brute-force scanning of the address space is not practical
with IPv6. Thus, they could benefit from any means which make
mapping the networks easier. For example, if a security threat
targeted at routers or even home agents is discovered, having a
simple ICMP mechanism to easily find out possible targets may prove
to be an additional (though minor) security risk.
Apart from discovering the address(es) of home agents, attackers will
not be able to learn much from this information, and mobile nodes
cannot be tricked into using wrong home agents, as all other
communication with the home agents is secure.
15.6. Mobile Prefix Discovery
The mobile prefix discovery function may leak interesting information
about network topology and prefix lifetimes to eavesdroppers; for
this reason, requests for this information has to be authenticated.
Responses and unsolicited prefix information needs to be
authenticated to prevent the mobile nodes from being tricked into
believing false information about the prefixes and possibly
preventing communications with the existing addresses. Optionally,
encryption may be applied to prevent leakage of the prefix
15.7. Tunneling via the Home Agent
Tunnels between the mobile node and the home agent can be protected
by ensuring proper use of source addresses, and optional
cryptographic protection. These procedures are discussed in Section
Binding Updates to the home agents are secure. When receiving
tunneled traffic, the home agent verifies that the outer IP address
corresponds to the current location of the mobile node. This acts as
a weak form of protection against spoofing packets that appear to
come from the mobile node. This is particularly useful, if no end-
to-end security is being applied between the mobile and correspondent
nodes. The outer IP address check prevents attacks where the
attacker is controlled by ingress filtering. It also prevents
attacks when the attacker does not know the current care-of address
of the mobile node. Attackers who know the care-of address and are
not controlled by ingress filtering could still send traffic through
the home agent. This includes attackers on the same local link as
the mobile node is currently on. But such attackers could send
packets that appear to come from the mobile node without attacking
the tunnel; the attacker could simply send packets with the source
address set to the mobile node's home address. However, this attack
does not work if the final destination of the packet is in the home
network, and some form of perimeter defense is being applied for
packets sent to those destinations. In such cases it is recommended
that either end-to-end security or additional tunnel protection be
applied, as is usual in remote access situations.
Home agents and mobile nodes may use IPsec ESP to protect payload
packets tunneled between themselves. This is useful for protecting
communications against attackers on the path of the tunnel.
When site local home addresses are used, reverse tunneling can be
used to send site local traffic from another location.
Administrators should be aware of this when allowing such home
addresses. In particular, the outer IP address check described above
is not sufficient against all attackers. The use of encrypted
tunnels is particularly useful for these kinds of home addresses.
15.8. Home Address Option
When the mobile node sends packets directly to the correspondent
node, the Source Address field of the packet's IPv6 header is the
care-of address. Therefore, ingress filtering  works in the
usual manner even for mobile nodes, as the Source Address is
topologically correct. The Home Address option is used to inform the
correspondent node of the mobile node's home address.
However, the care-of address in the Source Address field does not
survive in replies sent by the correspondent node unless it has a
binding for this mobile node. Also, not all attacker tracing
mechanisms work when packets are being reflected through
correspondent nodes using the Home Address option. For these
reasons, this specification restricts the use of the Home Address
option. It may only be used when a binding has already been
established with the participation of the node at the home address,
as described in Section 5.5 and Section 6.3. This prevents
reflection attacks through the use of the Home Address option. It
also ensures that the correspondent nodes reply to the same address
that the mobile node sends traffic from.
No special authentication of the Home Address option is required
beyond the above, but note that if the IPv6 header of a packet is
covered by IPsec Authentication Header, then that authentication
covers the Home Address option as well. Thus, even when
authentication is used in the IPv6 header, the security of the Source
Address field in the IPv6 header is not compromised by the presence
of a Home Address option. Without authentication of the packet, any
field in the IPv6 header, including the Source Address field or any
other part of the packet and the Home Address option can be forged or
modified in transit. In this case, the contents of the Home Address
option is no more suspect than any other part of the packet.
15.9. Type 2 Routing Header
The definition of the type 2 routing header is described in Section
6.4. This definition and the associated processing rules have been
chosen so that the header cannot be used for what is traditionally
viewed as source routing. In particular, the Home Address in the
routing header will always have to be assigned to the home address of
the receiving node; otherwise the packet will be dropped.
Generally, source routing has a number of security concerns. These
include the automatic reversal of unauthenticated source routes
(which is an issue for IPv4, but not for IPv6). Another concern is
the ability to use source routing to "jump" between nodes inside, as
well as outside a firewall. These security concerns are not issues
in Mobile IPv6, due to the rules mentioned above.
In essence the semantics of the type 2 routing header is the same as
a special form of IP-in-IP tunneling where the inner and outer source
addresses are the same.
This implies that a device which implements the filtering of packets
should be able to distinguish between a type 2 routing header and
other routing headers, as required in Section 8.3. This is necessary
in order to allow Mobile IPv6 traffic while still having the option
of filtering out other uses of routing headers.
Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark,
and Michael Thomas worked on the return routability protocols
eventually led to the procedures used in this protocol. The
procedures described in  were adopted in the protocol.
Significant contributions were made by members of the Mobile IPv6
Security Design Team, including (in alphabetical order) Gabriel
Montenegro, Erik Nordmark and Pekka Nikander.
We would like to thank the members of the Mobile IP and IPng Working
Groups for their comments and suggestions on this work. We would
particularly like to thank (in alphabetical order) Fred Baker, Josh
Broch, Samita Chakrabarti, Robert Chalmers, Noel Chiappa, Greg Daley,
Vijay Devarapalli, Rich Draves, Francis Dupont, Thomas Eklund, Jun-
Ichiro Itojun Hagino, Brian Haley, Marc Hasson, John Ioannidis, James
Kempf, Rajeev Koodli, Krishna Kumar, T.J. Kniveton, Joe Lau, Jiwoong
Lee, Aime Le Rouzic, Vesa-Matti Mantyla, Kevin Miles, Glenn Morrow,
Thomas Narten, Karen Nielsen, Simon Nybroe, David Oran, Brett
Pentland, Lars Henrik Petander, Basavaraj Patil, Mohan Parthasarathy,
Alexandru Petrescu, Mattias Petterson, Ken Powell, Phil Roberts, Ed
Remmell, Patrice Romand, Luis A. Sanchez, Jeff Schiller, Pekka
Savola, Arvind Sevalkar, Keiichi Shima, Tom Soderlund, Hesham
Soliman, Jim Solomon, Tapio Suihko, Dave Thaler, Benny Van Houdt,
Jon-Olov Vatn, Carl E. Williams, Vladislav Yasevich, Alper Yegin, and
Xinhua Zhao, for their detailed reviews of earlier versions of this
document. Their suggestions have helped to improve both the design
and presentation of the protocol.
We would also like to thank the participants of the Mobile IPv6
testing event (1999), implementors who participated in Mobile IPv6
interoperability testing at Connectathons (2000, 2001, 2002, and
2003), and the participants at the ETSI interoperability testing
(2000, 2002). Finally, we would like to thank the TAHI project who
has provided test suites for Mobile IPv6.
18.1. Normative References
 Eastlake 3rd., D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
 Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
 Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
 Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
 Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
 Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.
 Maughan, D., Schertler, M., Schneider, M. and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998.
 Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
 Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
 Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
 Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
 Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
 Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
 Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
 Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", RFC 2526, March 1999.
 Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
 Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
 Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
 National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995, <http://
 Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
18.2. Informative References
 Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
 Perkins, C., "IP Encapsulation within IP", RFC 2003, October
 Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
 Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
 Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
 Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", Work in
Progress, March 2002.
 Bellovin, S., "Guidelines for Mandating Automated Key
Management", Work in Progress, August 2003.
 Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Work in
Progress, April 2003.
 Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
 Nikander, P., Aura, T., Arkko, J., Montenegro, G. and E.
Nordmark, "Mobile IP version 6 Route Optimization Security
Design Background", Work in Progress, April 2003.
 Nordmark, E., "Securing MIPv6 BUs using return routability
(BU3WAY)", Work in Progress, November 2001.
 Roe, M., Aura, T., O'Shea, G. and J. Arkko, "Authentication of
Mobile IPv6 Binding Updates and Acknowledgments", Work in
Progress, March 2002.
 Savola, P., "Use of /127 Prefix Length Between Routers
Considered Harmful", RFC 3627, September 2003.
 Savola, P., "Security of IPv6 Routing Header and Home Address
Options", Work in Progress, December 2002.
 Vida, R. and L. Costa, Eds., "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
Appendix A. Future Extensions
This document does not specify how to piggyback payload packets on
the binding related messages. However, it is envisioned that this
can be specified in a separate document when issues such as the
interaction between piggybacking and IPsec are fully resolved (see
also Appendix A.3). The return routability messages can indicate
support for piggybacking with a new mobility option.
A.2. Triangular Routing
Due to the concerns about opening reflection attacks with the Home
Address destination option, this specification requires that this
option be verified against the Binding Cache, i.e., there must be a
Binding Cache entry for the Home Address and Care-of Address.
Future extensions may be specified that allow the use of unverified
Home Address destination options in ways that do not introduce
A.3. New Authorization Methods
While the return routability procedure provides a good level of
security, there exist methods that have even higher levels of
security. Secondly, as discussed in Section 15.4, future
enhancements of IPv6 security may cause a need to also improve the
security of the return routability procedure. Using IPsec as the
sole method for authorizing Binding Updates to correspondent nodes is
also possible. The protection of the Mobility Header for this
purpose is easy, though one must ensure that the IPsec SA was created
with appropriate authorization to use the home address referenced in
the Binding Update. For instance, a certificate used by IKE to
create the security association might contain the home address. A
future specification may specify how this is done.
A.4. Dynamically Generated Home Addresses
A future version of this specification may include functionality that
allows the generation of new home addresses without requiring pre-
arranged security associations or certificates even for the new
A.5. Remote Home Address Configuration
The method for initializing a mobile node's home address upon power-
up or after an extended period of being disconnected from the network
is beyond the scope of this specification. Whatever procedure is
used should result in the mobile node having the same stateless or
stateful (e.g., DHCPv6) home address autoconfiguration information it
would have if it were attached to the home network. Due to the
possibility that the home network could be renumbered while the
mobile node is disconnected, a robust mobile node would not rely
solely on storing these addresses locally.
Such a mobile node could be initialized by using the following
1. Generate a care-of address.
2. Query DNS for an anycast address associated with the FQDN of the
3. Perform home agent address discovery, and select a home agent.
4. Configure one home address based on the selected home agent's
subnet prefix and the interface identifier of the mobile node.
5. Create security associations and security policy database entries
for protecting the traffic between the selected home address and
6. Perform a home registration on the selected home agent.
7. Perform mobile prefix discovery.
8. Make a decision if further home addresses need to be configured.
This procedure is restricted to those situations where the home
prefix is 64 bits and the mobile node knows its own interface
identifier, which is also 64 bits.
A.6. Neighbor Discovery Extensions
Future specifications may improve the efficiency of Neighbor
Discovery tasks, which could be helpful for fast movements. One
factor is currently being looked at: the delays caused by the
Duplicate Address Detection mechanism. Currently, Duplicate Address
Detection needs to be performed for every new care-of address as the
mobile node moves, and for the mobile node's link-local address on
every new link. In particular, the need and the trade-offs of re-
performing Duplicate Address Detection for the link-local address
every time the mobile node moves on to new links will need to be
examined. Improvements in this area are, however, generally
applicable and progress independently from the Mobile IPv6
Future functional improvements may also be relevant for Mobile IPv6
and other applications. For instance, mechanisms that would allow
recovery from a Duplicate Address Detection collision would be useful
for link-local, care-of, and home addresses.
David B. Johnson
Dept. of Computer Science, MS 132
6100 Main Street
Houston TX 77005-1892
Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View CA 94043
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
Funding for the RFC Editor function is currently provided by the