Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next

RFC 6275

Mobility Support in IPv6

Pages: 169
Group: MEXT
Proposed STD
Obsoletes:  3775
Part 8 of 8 – Pages 150 to 169
First   Prev   None

Top   ToC   RFC6275 - Page 150   prevText
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 [21]
   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
Top   ToC   RFC6275 - Page 151
   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.

   Support for IKEv2 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 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
      frequency today.

   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 [42],
      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 IKEv2 with Mobile IPv6 is documented in more detail in
   [20].  The following should be observed regarding the use of IKEv2:

   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 IKEv2, 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
Top   ToC   RFC6275 - Page 152
   o  Due to the problems outlined in Section 11.3.2, the IKEv2 SA
      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 an IKEv2 security association.  A Key Management
      Mobility Capability (K) flag is provided for implementations that
      can update the IKEv2 endpoints without re-establishing an IKEv2
      security association, but the support for this behavior is

   o  Nevertheless, even if per-mobile node configuration is required
      with IKEv2, an important benefit of IKEv2 is that it automates the
      negotiation of cryptographic parameters, including the Security
      Parameter Indices (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.  IKEv2 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.  IKEv2 SHOULD also be
      used in such cases.

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
   (Sections 15.4.2 and 15.4.3) and from the point of view of other
   attackers (Section 15.4.6).
Top   ToC   RFC6275 - Page 153
15.4.1.  Overview

   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 from which the request was sent.

   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 [28] [35] [34] [43].  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
Top   ToC   RFC6275 - Page 154
   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
   mobile node.

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
Top   ToC   RFC6275 - Page 155
   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
   right path.

   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
      this vulnerability.
Top   ToC   RFC6275 - Page 156
   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 [43].

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 that 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.
Top   ToC   RFC6275 - Page 157
   Nevertheless, as [28] 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
   determine whether 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
   seeing them.

   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
Top   ToC   RFC6275 - Page 158
   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 entropy.

   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 that 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.

   This document does not define any authentication mechanism for
   dynamic home agent address discovery messages.  Therefore, the home
   agent cannot verify the home address of the mobile node that
   requested the list of home agents.
Top   ToC   RFC6275 - Page 159
   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.

   In cases where additional security is needed, one may consider
   instead the use of MIPv6 bootstrapping [22], (based on DNS SRV
   Resource Records [10]) in conjunction with security mechanisms
   suggested in these specifications.  In that solution, security is
   provided by the DNS Security (DNSSEC) [13] framework.  The needed
   pre-configured data on the mobile node for this mechanism is the
   domain name of the mobile service provider, which is marginally
   better than the home subnet prefix.  For the security, a trust anchor
   that dominates the domain is needed.

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 have 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 5.5.

   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
Top   ToC   RFC6275 - Page 160
   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 a unique-local address (ULA, RFC 4193 [15]) is used as a home
   address, reverse tunneling can be used to send 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 [27] 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 Sections 5.5 and 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
Top   ToC   RFC6275 - Page 161
   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

   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 that 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.

15.10.  SHA-1 Secure Enough for Mobile IPv6 Control Messages

   This document relies on hash-based message authentication codes
   (HMAC) computed using the SHA-1 [11] hash algorithm for the home
   keygen token and care-of keygen token, as well as the authentication
   fields in the binding update and binding authorization data (see
   Section 5.2.4).  While SHA-1 has been deprecated for some
   cryptographic mechanisms, SHA-1 is considered secure for the
   foreseeable future when used as specified here.  For additional
   details, see [39].
Top   ToC   RFC6275 - Page 162
16.  Contributors

   Work done by Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik
   Nordmark, and Michael Thomas shaped the return routability protocols
   described in [35].

   Significant contributions were made by members of the Mobile IPv6
   Security Design Team, including (in alphabetical order) Gabriel
   Montenegro, Pekka Nikander, and Erik Nordmark.

17.  Acknowledgements

   We would like to thank the members of the Mobile IP, Mobility
   Extensions for IPv6, 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, Jean-Michel Combes, Greg Daley, Vijay
   Devarapalli, Rich Draves, Francis Dupont, Ashutosh Dutta, Arnaud
   Ebalard, Wesley Eddy, Thomas Eklund, Jun-Ichiro Itojun Hagino, Brian
   Haley, Marc Hasson, John Ioannidis, James Kempf, Rajeev Koodli,
   Suresh Krishnan, Krishna Kumar, T.J. Kniveton, Joe Lau, Aime Le
   Rouzic, Julien Laganier, Jiwoong Lee, Benjamin Lim, Vesa-Matti
   Mantyla, Kevin Miles, Glenn Morrow, Ahmad Muhanna, Thomas Narten,
   Karen Nielsen, Simon Nybroe, David Oran, Mohan Parthasarathy,
   Basavaraj Patil, Brett Pentland, Lars Henrik Petander, Alexandru
   Petrescu, Mattias Petterson, Ken Powell, Ed Remmell, Phil Roberts,
   Patrice Romand, Luis A. Sanchez, Pekka Savola, Jeff Schiller, Arvind
   Sevalkar, Keiichi Shima, Tom Soderlund, Hesham Soliman, Jim Solomon,
   Tapio Suihko, Dave Thaler, Pascal Thubert, Benny Van Houdt, Jon-Olov
   Vatn, Ryuji Wakikawa, Kilian Weniger, 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), implementers 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 that
   has provided test suites for Mobile IPv6.

18.  References

18.1.  Normative References

   [1]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
         for Message Authentication", RFC 2104, February 1997.
Top   ToC   RFC6275 - Page 163
   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [3]   Kent, S. and K. Seo, "Security Architecture for the Internet
         Protocol", RFC 4301, December 2005.

   [4]   Kent, S., "IP Authentication Header", RFC 4302, December 2005.

   [5]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303,
         December 2005.

   [6]   Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
         Specification", RFC 2460, December 1998.

   [7]   Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
         Specification", RFC 2473, December 1998.

   [8]   Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
         Addresses", RFC 2526, March 1999.

   [9]   Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
         Discovery (MLD) for IPv6", RFC 2710, October 1999.

   [10]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.

   [11]  National Institute of Standards and Technology, "Secure Hash
         Standard", FIPS PUB 180-1, April 1995,

   [12]  Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
         Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
         Agents", RFC 3776, June 2004.

   [13]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "DNS Security Introduction and Requirements", RFC 4033,
         March 2005.

   [14]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
         Requirements for Security", BCP 106, RFC 4086, June 2005.

   [15]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
         Addresses", RFC 4193, October 2005.

   [16]  Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 4291, February 2006.
Top   ToC   RFC6275 - Page 164
   [17]  Conta, A., Deering, S., and M. Gupta, "Internet Control Message
         Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
         Specification", RFC 4443, March 2006.

   [18]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
         "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
         September 2007.

   [19]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address
         Autoconfiguration", RFC 4862, September 2007.

   [20]  Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
         IKEv2 and the Revised IPsec Architecture", RFC 4877,
         April 2007.

   [21]  Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions
         for Stateless Address Autoconfiguration in IPv6", RFC 4941,
         September 2007.

   [22]  Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
         Bootstrapping in Split Scenario", RFC 5026, October 2007.

   [23]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

   [24]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key
         Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.

18.2.  Informative References

   [25]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
         October 1996.

   [26]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
         October 1996.

   [27]  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.

   [28]  Aura, T. and J. Arkko, "MIPv6 BU Attacks and Defenses", Work
         in Progress, March 2002.

   [29]  Krishnan, S. and G. Tsirtsis, "MIPv6 Home Link Detection", Work
         in Progress, March 2008.

   [30]  Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-
         line Database", RFC 3232, January 2002.
Top   ToC   RFC6275 - Page 165
   [31]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
         Carney, "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", RFC 3315, July 2003.

   [32]  Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944,
         November 2010.

   [33]  Draves, R., "Default Address Selection for Internet Protocol
         version 6 (IPv6)", RFC 3484, February 2003.

   [34]  Nordmark, E., "Securing MIPv6 BUs using return routability
         (BU3WAY)", Work in Progress, November 2001.

   [35]  Roe, M., "Authentication of Mobile IPv6 Binding Updates and
         Acknowledgments", Work in Progress, March 2002.

   [36]  Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
         Integrated Scenario", Work in Progress, April 2008.

   [37]  Savola, P., "Use of /127 Prefix Length Between Routers
         Considered Harmful", RFC 3627, September 2003.

   [38]  Savola, P., "Security of IPv6 Routing Header and Home Address
         Options", Work in Progress, March 2002.

   [39]  Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
         Considerations for the SHA-0 and SHA-1 Message-Digest
         Algorithms", RFC 6194, March 2011.

   [40]  Manner, J. and M. Kojo, "Mobility Related Terminology",
         RFC 3753, June 2004.

   [41]  Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
         (MLDv2) for IPv6", RFC 3810, June 2004.

   [42]  Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key
         Management", BCP 107, RFC 4107, June 2005.

   [43]  Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
         Nordmark, "Mobile IP Version 6 Route Optimization Security
         Design Background", RFC 4225, December 2005.

   [44]  Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket
         API for Source Address Selection", RFC 5014, September 2007.

   [45]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of
         Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
Top   ToC   RFC6275 - Page 166
Appendix A.  Future Extensions

A.1.  Piggybacking

   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
   security issues.

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.  Second, 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 IKEv2 to create the
   security association might contain the home address.  A future
   specification may specify how this is done.

A.4.  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
Top   ToC   RFC6275 - Page 167
   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.

Appendix B.  Changes since RFC 3775

   The following issues were identified during the evolution of the
   current document.  Discussion about most of the issues can be found
   on the [mext] working group page

   Issue #1  Last Accepted SQN [Ahmad Muhanna]

      Solution: specify that the mobile node update its binding sequence
      number to match the sequence number given in the Binding
      Acknowledgement (if the Binding Acknowledgement correctly passes
      authentication and the status is 135 (Sequence Number out of
      window).  See Section 11.7.3.

   Issue #4  Remove references to site-local addresses [George


   Issue #5  Wrong protocol number (2 instead of 135) used in discussion
      about checksum pseudo-header.

      Fixed.  See Section 6.1.1.

   Issue #8  Application using the care-of address [Julien Laganier]

      Cite IPv6 Socket API for Source Address Selection specification
      [44].  See Section 11.3.4.

   Issue #10  The usage of "HA lifetime" [Ryuji Wakikawa]

      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.  See
      Section 11.4.1.
Top   ToC   RFC6275 - Page 168
   Issue #11  De-registration when returning home [Vijay Devarapalli]

      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.  See
      Section 11.5.5.

   Issue #12  BErr sent by HA too, not only by CN [Alexandru Petrescu]

      Fixed.  See Section 4.2.

   Issue #13  Home Link Detection [Suresh Krishnan]

      Proposal: Add Section 11.5.2 for Home Link Detection, drawing on
      "MIPv6 Home Link Detection" [29].

   Issue #14  References to bootstrapping [Vijay Devarapalli]

      Cite "Mobile IPv6 Bootstrapping in Split Scenario" [22] and "MIP6-
      bootstrapping for the Integrated Scenario" [36].  See Section 4.1.

   Issue #17  Multi-homed mobile node can cause routing loop between
      home agents [Benjamin Lim]

      Added security advisory in Section 15.1, to highlight risk of
      routing loop among HAs (e.g., in 3GPP):

      A malicious mobile node associated to multiple home agents could
      create a routing loop amongst them.  This would happen when a
      mobile node binds one home address located on a first home agent
      to another home address on a second home agent.

   Issue #18  Subject: Issues regarding Home Address Option and ICMP /
      Binding Errors [Fabian Mauchle]

      Proposal: Use the value in the Next Header field {50 (ESP), 51
      (AH), 135 (Mobility Header)} to determine, if a Binding Cache
      entry is required.  See Section 9.3.1.

      Proposal: 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.  See Section 11.3.6.
Top   ToC   RFC6275 - Page 169
   Issue #19  BU de-registration race condition [Kilian Weniger]

      Problem arises if de-registration arrives at home agent before an
      immediately preceding Binding Update.

      Solution: Home agent defers BCE removal after sending the Binding
      Acknowledgement.  See Section 10.3.2.

   Issue #6  Minor editorial corrections and updates.

      Update IPsec and IKE references to the revised IPsec architecture
      and IKEv2.

      Update HMAC_SHA1 [1] to Normative instead of Informational.

      Include discussion (see Section 15.10) to inform implementers that
      HMAC_SHA1 is considered to offer sufficient protection for control
      messages as required by Mobile IPv6.

Authors' Addresses

   Charles E. Perkins (editor)
   Tellabs, Inc.
   4555 Great America Parkway, Suite 150
   Santa Clara  CA 95054


   David B. Johnson
   Rice University
   Dept. of Computer Science, MS 132
   6100 Main Street
   Houston  TX 77005-1892


   Jari Arkko
   Jorvas  02420