<pre>Network Working Group                                            C. Vogt
Request for Comments: 4651                   Universitaet Karlsruhe (TH)
Category: Informational                                         J. Arkko
                                            Ericsson Research NomadicLab
                                                           February 2007


               <span class="h1">A Taxonomy and Analysis of Enhancements to</span>
                     <span class="h1">Mobile IPv6 Route Optimization</span>

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

IESG Note:

   This RFC is a product of the Internet Research Task Force and is not
   a candidate for any level of Internet Standard.  The IRTF publishes
   the results of Internet-related research and development activities.
   These results might not be suitable for deployment.

Abstract

   This document describes and evaluates strategies to enhance Mobile
   IPv6 Route Optimization, on the basis of existing proposals, in order
   to motivate and guide further research in this context.  This
   document is a product of the IP Mobility Optimizations (MobOpts)
   Research Group.

















<span class="grey">Vogt &amp; Arkko                 Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
      <a href="#section-1.1">1.1</a>. A Note on Public-Key Infrastructures .......................<a href="#page-4">4</a>
      <a href="#section-1.2">1.2</a>. A Note on Source Address Filtering .........................<a href="#page-5">5</a>
   <a href="#section-2">2</a>. Objectives for Route Optimization Enhancement ...................<a href="#page-7">7</a>
      <a href="#section-2.1">2.1</a>. Latency Optimizations ......................................<a href="#page-8">8</a>
      <a href="#section-2.2">2.2</a>. Security Enhancements ......................................<a href="#page-8">8</a>
      <a href="#section-2.3">2.3</a>. Signaling Optimizations ....................................<a href="#page-9">9</a>
      <a href="#section-2.4">2.4</a>. Robustness Enhancements ....................................<a href="#page-9">9</a>
   <a href="#section-3">3</a>. Enhancements Toolbox ............................................<a href="#page-9">9</a>
      <a href="#section-3.1">3.1</a>. IP Address Tests ..........................................<a href="#page-10">10</a>
      <a href="#section-3.2">3.2</a>. Protected Tunnels .........................................<a href="#page-10">10</a>
      <a href="#section-3.3">3.3</a>. Optimistic Behavior .......................................<a href="#page-11">11</a>
      <a href="#section-3.4">3.4</a>. Proactive IP Address Tests ................................<a href="#page-11">11</a>
      <a href="#section-3.5">3.5</a>. Concurrent Care-of Address Tests ..........................<a href="#page-12">12</a>
      <a href="#section-3.6">3.6</a>. Diverted Routing ..........................................<a href="#page-13">13</a>
      <a href="#section-3.7">3.7</a>. Credit-Based Authorization ................................<a href="#page-14">14</a>
      <a href="#section-3.8">3.8</a>. Heuristic Monitoring ......................................<a href="#page-17">17</a>
      <a href="#section-3.9">3.9</a>. Crypto-Based Identifiers ..................................<a href="#page-18">18</a>
      <a href="#section-3.10">3.10</a>. Pre-Configuration ........................................<a href="#page-19">19</a>
      <a href="#section-3.11">3.11</a>. Semi-Permanent Security Associations .....................<a href="#page-20">20</a>
      <a href="#section-3.12">3.12</a>. Delegation ...............................................<a href="#page-21">21</a>
      <a href="#section-3.13">3.13</a>. Mobile Networks ..........................................<a href="#page-21">21</a>
      <a href="#section-3.14">3.14</a>. Location Privacy .........................................<a href="#page-22">22</a>
   <a href="#section-4">4</a>. Discussion .....................................................<a href="#page-22">22</a>
      <a href="#section-4.1">4.1</a>. Cross-Layer Interactions ..................................<a href="#page-23">23</a>
      <a href="#section-4.2">4.2</a>. Experimentation and Measurements ..........................<a href="#page-23">23</a>
      <a href="#section-4.3">4.3</a>. Future Research ...........................................<a href="#page-24">24</a>
   <a href="#section-5">5</a>. Security Considerations ........................................<a href="#page-24">24</a>
   <a href="#section-6">6</a>. Conclusions ....................................................<a href="#page-25">25</a>
   <a href="#section-7">7</a>. Acknowledgments ................................................<a href="#page-25">25</a>
   <a href="#section-8">8</a>. References .....................................................<a href="#page-26">26</a>
      <a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-26">26</a>
      <a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-26">26</a>
















<span class="grey">Vogt &amp; Arkko                 Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   Mobility support for IPv6, or Mobile IPv6, enables mobile nodes to
   migrate active transport connections and application sessions from
   one IPv6 address to another.  The Mobile IPv6 specification, <a href="./rfc3775">RFC 3775</a>
   [<a href="#ref-1" title="&quot;Mobility Support in IPv6&quot;">1</a>], introduces a "home agent", which proxies a mobile node at a
   permanent "home address".  A roaming mobile node connects to the home
   agent through a bidirectional tunnel and can so communicate, from its
   local "care-of address", as if it was present at the home address.
   The mobile node keeps the home agent updated on its current care-of
   address via IPsec-protected signaling messages [<a href="#ref-40" title="&quot;Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents&quot;">40</a>].

   In case the correspondent node lacks appropriate mobility support, it
   communicates with the mobile node's home address, and thus all data
   packets are routed via the home agent.  This mode, Bidirectional
   Tunneling, increases packet-propagation delays.  <a href="./rfc3775">RFC 3775</a> hence
   defines an additional mode for Route Optimization, which allows peers
   to communicate on the direct path.  It requires that the
   correspondent node can cache a binding between the mobile node's home
   address and current care-of address.  The challenge with Route
   Optimization is that an administrative relationship between the
   mobile node and the correspondent node can generally not be
   presupposed.  So how can the two authenticate and authorize the
   signaling messages that they exchange?

   Mobile IPv6 solves this problem by verifying a routing property of
   the mobile node.  Specifically, the mobile node is checked to be
   reachable at its home address and current care-of address in that it
   must prove the reception of a home and care-of keygen token,
   respectively.  This is called the "return-routability procedure".  It
   takes place right before a mobile node registers a new care-of
   address with a correspondent node and is periodically repeated in
   case the mobile node does not move for a while.

   The advantage of the return-routability procedure is that it is
   lightweight and does not require pre-shared authentication material.
   It also requires no state at the correspondent node.  On the other
   hand, the two reachability tests can lead to a handoff delay
   unacceptable for many real-time or interactive applications such as
   Voice over IP (VoIP) and video conferencing.  Also, the security that
   the return-routability procedure guarantees might not be sufficient
   for security-sensitive applications.  And finally, periodically
   refreshing a registration at a correspondent node implies a hidden
   signaling overhead that may prevent mobile nodes from hibernation
   during times of inactivity.

   Manifold enhancements for Route Optimizations have hence been
   suggested.  This document describes and evaluates various strategies



<span class="grey">Vogt &amp; Arkko                 Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   on the basis of existing proposals.  It is meant to provide a
   conceptual framework for further work, which was found to be
   inevitable in the context of Route Optimization.  Many scientists
   volunteered to review this document.  Their names are duly recorded
   in <a href="#section-7">Section 7</a>.  <a href="#section-2">Section 2</a> analyzes the strengths and weaknesses of
   Route Optimization and identifies potential objectives for
   enhancement.  Different enhancement strategies are discussed, based
   on existing proposals, in <a href="#section-3">Section 3</a>.  <a href="#section-4">Section 4</a> discusses the
   different approaches and identifies opportunities for further
   research.  <a href="#section-5">Section 5</a> and <a href="#section-6">Section 6</a> conclude the document.

   This document represents the consensus of the MobOpts Research Group.
   It has been reviewed by the Research Group members active in the
   specific area of work.  At the request of their chairs, this document
   has been comprehensively reviewed by multiple active contributors to
   the IETF MIP6 Working Group.  At the time of this writing, some of
   the ideas presented in this document have been adopted by the
   Mobility for IP: Performance, Signaling and Handoff Optimization
   (mipshop) Working Group in the IETF.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  A Note on Public-Key Infrastructures</span>

   Mobile IPv6 Route Optimization verifies a mobile node's authenticity
   through a routing property.  An alternative is cryptographic
   authentication, which requires a binding between a node's identity
   and some sort of secret information.  Although some proposals suggest
   installing shared secrets into end nodes when possible (see <a href="#section-3.10">Section</a>
   <a href="#section-3.10">3.10</a>), pre-configuration is not an option for general Internet use
   for scalability reasons.  Authentication based on a Public-Key
   Infrastructure (PKI) does not require pair-wise pre-configuration.
   Here, the secret information is the private component of a
   public/private-key pair, and the binding between a node's identity
   and private key exists indirectly through the cryptographic
   properties of public/private-key pairs and a binding between the
   identity and the public key.  An authority trusted by both end nodes
   issues a certificate that effects this latter binding.

   Large-scale use of a PKI, however, was considered unsuitable for
   mobility management due to the following reasons.

   o  There are differing opinions on whether a PKI could scale up to
      hundreds of millions of mobile nodes.  Some people argue they do,
      as there are already examples of certification authorities
      responsible for millions of certificates.  But more important than
      the expected increase in the number of certificates would be a
      shift in application patterns.  Nowadays, public-key cryptography
      is used only for those applications that require strong,
      cryptographic authentication.



<span class="grey">Vogt &amp; Arkko                 Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


      If it was used for mobility management as well, certificate checks
      would become mandatory for any type of application, leading to
      more checks per user.  Busy servers with mobility support might be
      unwilling to spent the processing resources required for this
      depending on the service they provide.

   o  Revoked certificates are identified on Certificate Revocation
      Lists (CRLs), which correspondent nodes with mobility support
      would have to acquire from certification authorities.  CRLs must
      be kept up to date, requiring periodic downloads.  This and the
      act of checking a certificate against a CRL create overhead that
      some correspondent nodes might be unwilling to spend.

   o  Certificate verification may take some time and hence interrupt
      ongoing applications.  This can be disturbing from the user's
      perspective, especially when Route Optimization starts in the
      middle of a session, or the session is very short-term anyway.

   o  The bigger a PKI grows, the more attractive it becomes as an
      attack target, endangering the Internet as a whole.

   o  There is little experience with using home addresses as
      identifiers in certificates.  Although the home address could
      theoretically be placed into a certificate's Subject Alternate
      Name field, the entities responsible for IP-address assignment and
      certification are usually not the same, and it may not be easy to
      coordinate the two.

   For these reasons, this document does not consider direct
   authentication of mobile nodes based on a PKI.  Nevertheless, it does
   evaluate certificate-based techniques that make the problems
   identified above more tractable (see <a href="#section-3.12">Section 3.12</a>).

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  A Note on Source Address Filtering</span>

   <a href="./rfc3775">RFC 3775</a> uses care-of-address tests to probe a mobile node's presence
   at its claimed location.  Alternatively, verification of care-of
   addresses may be based on infrastructure in the mobile node's local
   access network.  For instance, the infrastructure can verify that the
   IP source addresses of all packets leaving the network are correct.
   "Ingress filtering" [<a href="#ref-38" title="&quot;Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing&quot;">38</a>][43] provides this feature to the extent that
   it inspects the prefix of IP source addresses and ensures topological
   correctness.  Network-access providers that use ingress filtering
   normally deploy the technique in their first-hop and site-exit
   routers.  Similarly, ISPs may filter packets originating from a
   downstream network.





<span class="grey">Vogt &amp; Arkko                 Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   Ingress filtering may eventually provide a way to replace care-of-
   address tests.  But there are still a number of uncertainties today:

   o  By definition, ingress filtering can prevent source-address
      spoofing only from those networks that do deploy the technique.
      As a consequence, ingress filtering needs to be widely, preferably
      universally, deployed in order to constitute Internet-wide
      protection.  As long as an attacker can get network access without
      filters, all Internet nodes remain vulnerable.

   o  There is little incentive for ISPs to deploy ingress filtering
      other than conscientiousness.  Legal or regulatory prescription as
      well as financial motivation does not exist.  A corrupt ISP might
      even have a financial incentive not to deploy the technique, if
      redirection-based denial-of-service (DoS) attacks using Route
      Optimization ever become possible and are exploited for financial
      gain.  A similar issue was observed with, for example, email spam.

   o  Ingress filtering is most effective, and easiest to configure, at
      the first-hop router.  However, since only prefixes are checked,
      the filters inevitably get less precise the further upstream they
      are enforced.  This issue is inherent in the technique, so the
      best solution is checking packets as close to the originating
      nodes as possible, preferably in the first-hop routers themselves.

   o  A popular implementation of ingress filtering is "Reverse Path
      Forwarding" (RPF).  This technique relies on routes to be
      symmetric, which is oftentimes the case between edge networks and
      ISPs, but far less often between peering ISPs.  Alternatives to
      RPF are either manually configured access lists or dynamic
      approaches that are more relaxed, and thereby less secure, than
      RPF [<a href="#ref-43" title="&quot;Ingress Filtering for Multihomed Networks&quot;">43</a>].

   o  Another problem with ingress filtering is multi-homing.  When a
      router attempts to forward to one ISP a packet with a source-
      address prefix from another ISP, filters at the second ISP would
      block the packet.  The IETF seeks to find a way around this [<a href="#ref-39" title="&quot;Goals for IPv6 Site- Multihoming Architectures&quot;">39</a>].
      For instance, one could tunnel the packet to the topologically
      correct ISP, or one could allow source-address changes by means of
      a locator-identifier split [<a href="#ref-45" title="&quot;Architectural Approaches to Multi-homing for IPv6&quot;">45</a>].

   o  Finally, <a href="./rfc3775">RFC 3775</a> defines an Alternative Care-of Address option
      that mobile nodes can use to carry a care-of address within a
      Binding Update message outside of the IPv6 header.  Such an
      address is not subject to inspection by ingress filtering and
      would have to be verified through other means [<a href="#ref-14" title="&quot;A Note about 3rd Party Bombing in Mobile IPv6&quot;">14</a>].





<span class="grey">Vogt &amp; Arkko                 Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   Although these problems are expected to get solved eventually, there
   is currently little knowledge on how applicable and deployable, as a
   candidate for care-of-address verification, ingress filtering will
   be.  High investments or administrative hurdles could prevent a
   large, preferably universal deployment of ingress filtering, which
   would hinder Internet-wide protection, as mentioned in the first
   bullet.  For these reasons, this document does not consider ingress
   filtering as a viable alternative to care-of-address tests, although
   things may be different in the future.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Objectives for Route Optimization Enhancement</span>

   Wireless environments with frequently moving nodes feature a number
   of salient properties that distinguish them from environments with
   stationary nodes or nodes that move only occasionally.  One important
   aspect is the efficiency of mobility management.  Nodes may not
   bother about a few round-trip times of handoff latency if they do not
   change their point of IP attachment often.  But the negative impact
   that a mobility protocol can have on application performance
   increases with the level of mobility.  Therefore, in order to
   maximize user satisfaction, it is important to reduce the handoff
   latency that the mobility protocol adds to existing delays in other
   places of the network stack.  A related issue is the robustness of
   the mobility protocol, given that temporary outage of mobility
   support can render mobile nodes incapable of continuing to
   communicate.

   Furthermore, the wireless nature of data transmissions makes it
   potentially easier for an attacker to eavesdrop on other nodes' data
   or send data on behalf of other nodes.  While applications can
   usually authenticate and encrypt their payload if need be, similar
   security measures may not be feasible for signaling packets of a
   mobility protocol, in particular if communicating end nodes have no
   pre-existing relationship.

   Given the typically limited bandwidth in a wireless medium, resources
   ought to be spent in an economic matter.  This is especially
   important for the amount of signaling that a mobility protocol
   requires.

   Endeavors to enhance <a href="./rfc3775">RFC 3775</a> Route Optimization generally strive for
   reduced handoff latency, higher security, lower signaling overhead,
   or increased protocol robustness.  These objectives are herein
   discussed from a requirements perspective; the technical means to
   reach the objectives is not considered, nor is the feasibility of
   achieving them.





<span class="grey">Vogt &amp; Arkko                 Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Latency Optimizations</span>

   One important objective for improving Route Optimization is to reduce
   handoff latencies.  Assuming that the home-address test dominates the
   care-of-address test in terms of latency, a Mobile IPv6 handoff takes
   one round-trip time between the mobile node and the home agent for
   the home registration, a round-trip time between the mobile node and
   the home agent plus a round-trip time between the home agent and the
   correspondent node for the home-address test, and a one-way time from
   the mobile node to the correspondent node for the propagation of the
   Binding Update message.  The first packet sent to the new care-of
   address requires an additional one-way time to propagate from the
   correspondent node to the mobile node.  The mobile node can resume
   communications right after it has dispatched the Binding Update
   message.  But if it requests a Binding Acknowledgment message from
   the correspondent node, communications are usually delayed until this
   is received.

   These delays are additive and are not subsumed by other delays at the
   IP layer or link layer.  They can cause perceptible quality
   degradations for interactive and real-time applications.  TCP bulk-
   data transfers are likewise affected since long handoff latencies may
   lead to successive retransmission timeouts and degraded throughput.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Security Enhancements</span>

   The return-routability procedure was designed with the objective to
   provide a level of security that compares to that of today's non-
   mobile Internet [<a href="#ref-46" title="&quot;Mobile IP Version 6 Route Optimization Security Design Background&quot;">46</a>].  As such, it protects against impersonation,
   denial of service, and redirection-based flooding attacks that would
   not be possible without Route Optimization.  This approach is based
   on an assumption that a mobile Internet cannot become any safer than
   the non-mobile Internet.

   Applications that require a security level higher than what the
   return-routability procedure can provide are generally advised to use
   end-to-end protection such as IPsec or Transport Layer Security
   (TLS).  But even then they are vulnerable to denial of service.  This
   motivates research for stronger Route Optimization security.
   Security enhancements may also become necessary if future
   technological improvements mitigate some of the existing mobility-
   unrelated vulnerabilities.

   One particular issue with Route Optimization is location privacy
   because route-optimized packets carry both home and care-of addresses
   in plaintext.  A standard workaround is to fall back to Bidirectional
   Tunneling when location privacy is needed.  Packets with the care-of
   address are then transferred only between the mobile node and the



<span class="grey">Vogt &amp; Arkko                 Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   home agent, where they can be encrypted through IPsec Encapsulating
   Security Payload (ESP) [<a href="#ref-42" title="&quot;IP Encapsulating Security Payload (ESP)&quot;">42</a>].  But even Bidirectional Tunneling
   requires the mobile node to periodically re-establish IPsec security
   associations with the home agent so as to become untraceable through
   Security Parameter Indexes (SPIs).

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Signaling Optimizations</span>

   Route Optimization requires periodic signaling even when the mobile
   node does not move.  The signaling overhead amounts to 7.16 bits per
   second if the mobile node communicates with a stationary node [<a href="#ref-6" title="&quot;Credit-Based Authorization for Binding Lifetime Extension&quot;">6</a>].
   It doubles if both peers are mobile.  This overhead may be negligible
   when the nodes communicate, but it can be an issue for mobile nodes
   that are inactive and stay at the same location for a while.  These
   nodes typically prefer to go to standby mode to conserve battery
   power.  Also, the periodic refreshes consume a fraction of the
   wireless bandwidth that one could use more efficiently.
   Optimizations for reduced signaling overhead could mitigate these
   issues.

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>.  Robustness Enhancements</span>

   Route Optimization could conceptually enable continued communications
   during periods of temporary home-agent unavailability.  The protocol
   defined in <a href="./rfc3775">RFC 3775</a> does not achieve this independence, however, as
   the home agent plays an active role in the return-routability
   procedure.  Appropriate enhancements could increase the independence
   from the home agent and thus enable robust Route Optimization even in
   the absence of the home agent.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Enhancements Toolbox</span>

   A large body of effort has recently gone into improving Mobile IPv6
   Route Optimization.  Some of the proposed techniques are
   modifications to the return-routability procedure, while others
   replace the procedure by alternative mechanisms.  Some of them
   operate end-to-end; others introduce network-side mobility support.
   In most cases, it is the combination of a set of techniques that is
   required to gain a complete -- that is, efficient and secure --
   route-optimization mechanism.











<span class="grey">Vogt &amp; Arkko                 Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  IP Address Tests</span>

   <a href="./rfc3775">RFC 3775</a> uses IP-address tests to ensure that a mobile node is live
   and on the path to a specific destination address:  The home-address
   test provides evidence that the mobile node is the legitimate owner
   of its home address; the care-of-address test detects spoofed care-of
   addresses and prevents redirection-based flooding attacks.  Both
   tests can be performed in parallel.

   A home-address test should be initiated by the mobile node so that
   the correspondent node can delay state creation until the mobile node
   has authenticated.  The care-of-address test can conceptually be
   initiated by either side.  It originates with the mobile node in <a href="./rfc3775">RFC</a>
   <a href="./rfc3775">3775</a>, but with the correspondent node in [<a href="#ref-16" title="&quot;Care-of Address Test for MIPv6 using a State Cookie&quot;">16</a>] and [<a href="#ref-22" title="&quot;End-Host Mobility and Multihoming with the Host Identity Protocol&quot;">22</a>].  The
   correspondent-node-driven approach suggests itself when
   authentication is done through other means than a home-address test.

   Important advantages of IP-address tests are zero-configurability and
   the independence of ancillary infrastructure.  As a disadvantage,
   IP-address tests can only guarantee that a node is on the path to the
   probed address, not that the node truly owns this address.  This does
   not lead to new security threats, however, because the types of
   attacks that an on-path attacker can do with Route Optimization are
   already possible in the non-mobile Internet [<a href="#ref-46" title="&quot;Mobile IP Version 6 Route Optimization Security Design Background&quot;">46</a>].

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Protected Tunnels</span>

   <a href="./rfc3775">RFC 3775</a> protects certain signaling messages, exchanged between a
   mobile node and its home agent, through an authenticated and
   encrypted tunnel.  This prevents unauthorized nodes on that path,
   including eavesdroppers in the mobile node's wireless access network,
   from listening in on these messages.

   Given that a pre-existing end-to-end security relationship between
   the mobile node and the correspondent node cannot generally be
   assumed, this protection exists only for the mobile node's side.  If
   the correspondent node is immobile, the path between the home agent
   and the correspondent node remains unprotected.  This is a path
   between two stationary nodes, so all types of attacks that a villain
   could wage on this path are already possible in the non-mobile
   Internet.  In case the correspondent node is mobile, it has its own
   home agent, and only the path between the two (stationary) home
   agents remains unprotected.








<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Optimistic Behavior</span>

   Many Mobile IPv6 implementations [<a href="#ref-29" title="&quot;Kame-Shisa&quot;">29</a>][31] defer a correspondent
   registration until the associated home registration has been
   completed successfully.  In contrast to such "conservative" behavior,
   a more "optimistic" approach is to begin the return-routability
   procedure in parallel with the home registration [<a href="#ref-52" title="&quot;Efficient End-to-End Mobility Support in IPv6&quot;">52</a>].  Conservative
   behavior avoids a useless return-routability procedure in case the
   home registration fails.  This comes at the cost of additional
   handoff delay when the home registration is successful.  Optimistic
   behavior saves this delay, but the return-routability procedure will
   be in vain should the corresponding home registration be
   unsuccessful.

   While a parallelization of the home registration and the return-
   routability procedure is feasible within the bounds of <a href="./rfc3775">RFC 3775</a>, the
   specification does not permit mobile nodes to continue with the
   correspondent registration, by sending a Binding Update message to
   the correspondent node, until a Binding Acknowledgment message
   indicating successful home registration has been received.  This is
   usually not a problem because the return-routability procedure is
   likely to take longer than the home registration anyway.  However,
   some optimizations (see <a href="#section-3.4">Section 3.4</a>) reduce the delay caused by the
   return-routability procedure.  A useful improvement is then to allow
   Binding Update messages to be sent to correspondent nodes even before
   the home registration has been acknowledged.

   The drawback of optimistic behavior is that a lost, reordered, or
   rejected Binding Update message can cause data packets to be
   discarded.  Nevertheless, packet loss would have similar negative
   impacts on conservative approaches, so the mobile node needs to be
   prepared for the possible loss of these packets in any case.

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Proactive IP Address Tests</span>

   The critical handoff phase, during which the mobile node and the
   correspondent node cannot fully communicate, spans the home
   registration and the correspondent registration, including the
   return-routability procedure.  One technique to shorten this phase is
   to accomplish part of the signaling proactively before the handoff.
   In particular, the home-address test can be done in advance without
   violating the specifications of <a href="./rfc3775">RFC 3775</a> [<a href="#ref-52" title="&quot;Efficient End-to-End Mobility Support in IPv6&quot;">52</a>][51].

   In order to have a fresh home keygen token ready for a future
   handoff, the mobile node should initiate a proactive home-address
   test at least once per token lifetime, that is, every 3.5 minutes.
   This does at most double the signaling overhead spent on home-address
   tests given that correspondent registrations must be refreshed every



<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   7 minutes even when the mobile node does not move for a while.  An
   optimization is possible where the mobile node's local link layer can
   anticipate handoffs and trigger the home-address test in such a case.
   [<a href="#ref-6" title="&quot;Credit-Based Authorization for Binding Lifetime Extension&quot;">6</a>] or [<a href="#ref-54" title="&quot;Extensions to Return Routability Test in MIP6&quot;">54</a>] reduce the frequency of home-address tests even further.
   Proactive care-of-address tests are possible only if the mobile node
   is capable of attaching to two networks simultaneously.  Dual
   attachment is possible if the link-layer technology enables it with a
   single interface [<a href="#ref-10" title="&quot;MultiNet: Connecting to Multiple IEEE 802.11 Networks Using a Single Wireless Card&quot;">10</a>], or if the mobile node is endowed with multiple
   interfaces [<a href="#ref-7" title="&quot;Reconsidering Wireless Systems With Multiple Radios&quot;">7</a>].

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  Concurrent Care-of Address Tests</span>

   Without the assumption that a mobile node can simultaneously attach
   to multiple networks, proactive care-of-address tests, executed prior
   to handoff, are not an option.  A correspondent node may instead
   authorize a mobile node to defer the care-of-address test until an
   early, tentative binding has been registered [<a href="#ref-52" title="&quot;Efficient End-to-End Mobility Support in IPv6&quot;">52</a>][51].  This in
   combination with a technique to eliminate the handoff delay of home-
   address tests (see <a href="#section-3.4">Section 3.4</a> and <a href="#section-3.9">Section 3.9</a>) facilitates early
   resumption of bidirectional communications subsequent to handoff.
   The care-of address is called "unverified" during the concurrent
   care-of-address test, and it is said to be "verified" once the
   correspondent node has obtained evidence that the mobile node is
   present at the address.  A tentative binding's lifetime can be
   limited to a few seconds.

   Home-address tests must not be accomplished concurrently, however,
   given that they serve the purpose of authentication.  They guarantee
   that only the legitimate mobile node can create or update a binding
   pertaining to a particular home address.





















<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   mobile node              home agent          correspondent node
        |                       |                       |
        |                       |                       |
        |--Home Test Init------&gt;|----------------------&gt;|
        |                       |                       |
        |                       |                       |
        |&lt;----------------------|&lt;-----------Home Test--|
        |                       |                       |
        |                                               |
      ~~+~~ handoff                                     |
        |                                               |
        |--Early Binding Update------------------------&gt;| -+-
        |--Care-of Test Init --------------------------&gt;|  |
        |                                               |  |
        |                                               |  | care-of
        |&lt;----------------Early Binding Acknowledgment--|  | address
        |&lt;-------------------------------Care-of Test---|  | unverified
        |                                               |  |
        |                                               |  |
        |--Binding Update------------------------------&gt;| -+-
        |                                               |
        |                                               |
        |&lt;----------------------Binding Acknowledgment--|
        |                                               |

            Figure 1: Concurrent Care-of Address Tests

   Figure 1 illustrates how concurrent care-of-address tests are used in
   [<a href="#ref-52" title="&quot;Efficient End-to-End Mobility Support in IPv6&quot;">52</a>][51]:  As soon as the mobile node has configured a new care-of
   address after a handoff, it sends to the correspondent node an Early
   Binding Update message.  Only a home keygen token, obtained from a
   proactive home-address test, is required to sign this message.  The
   correspondent node creates a tentative binding for the new,
   unverified care-of address when it receives the Early Binding Update
   message.  This address can be used immediately.  The mobile node
   finally sends a (standard) Binding Update message to the
   correspondent node when the concurrent care-of-address test is
   complete.  Credit-Based Authorization (see <a href="#section-3.7">Section 3.7</a>) prevents
   misuse of care-of addresses while they are unverified.

<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>.  Diverted Routing</span>

   Given that a home registration is faster than a correspondent
   registration in the absence of additional optimizations, the mobile
   node may request its traffic to be routed through the home address
   until a new binding has been set up at the correspondent node
   [<a href="#ref-52" title="&quot;Efficient End-to-End Mobility Support in IPv6&quot;">52</a>][51].  The performance of such diverted routing depends on the
   propagation properties of the involved routes, however.



<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   For packets to be diverted via the home address, signaling is
   necessary with both the home agent and the correspondent node.  The
   home agent must be informed about the new care-of address so that it
   can correctly forward packets intercepted at the home address.  The
   correspondent node continues to send packets to the old care-of
   address until it receives a Binding Update message indicating that
   the current binding is no longer valid and ought to be removed.  This
   request requires authentication through a home-address test in order
   to prevent denial of service by unauthorized nodes.  The test can be
   accomplished in a proactive way (see <a href="#section-3.4">Section 3.4</a>).

   The mobile node may send packets via the home address as soon as it
   has dispatched the Binding Update message to the home agent.  It may
   send outgoing packets along the direct path once a Binding Update
   message for the new care-of address has been sent to the
   correspondent node.

   It depends on the propagation latency on the end-to-end path via the
   home agent relative to the latency on the direct path for how long
   the correspondent node should continue to send packets to the home
   address.  If the former path is slow, it may be better to queue some
   of the packets until the correspondent registration is complete and
   packets can be sent along the direct route.

<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>.  Credit-Based Authorization</span>

   Concurrent care-of-address tests (see <a href="#section-3.5">Section 3.5</a>) require protection
   against spoofed unverified care-of addresses and redirection-based
   flooding attacks.  Credit-Based Authorization [<a href="#ref-50" title="&quot;Credit-Based Authorization for Concurrent IP-Address Tests&quot;">50</a>] is a technique
   that provides such protection based on the following three
   hypotheses:

   1.  A flooding attacker typically seeks to somehow multiply the
       packets it assembles for the purpose of the attack because
       bandwidth is an ample resource for many attractive victims.

   2.  An attacker can always cause unamplified flooding by generating
       bogus packets itself and sending them to its victim directly.

   3.  Consequently, the additional effort required to set up a
       redirection-based flooding attack pays off for the attacker only
       if amplification can be obtained this way.

   On this basis, rather than eliminating malicious packet redirection
   in the first place, Credit-Based Authorization prevents any
   amplification that can be reached through it.  This is accomplished
   by limiting the data a correspondent node can send to an unverified
   care-of address of a mobile node by the data that the correspondent



<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   node has recently received from that mobile node.  (See <a href="#section-3.5">Section 3.5</a>
   for a definition on when a care-of address is verified and when it is
   unverified.)  A redirection-based flooding attack is thus no more
   attractive than pure direct flooding, where the attacker itself sends
   bogus packets to the victim.  It is actually less attractive given
   that the attacker must keep Mobile IPv6 state to coordinate the
   redirection.

         mobile node           correspondent node
              |                        |
              |                        |
      address |--data-----------------&gt;| credit += size(data)
     verified |                        |
              |--data-----------------&gt;| credit += size(data)
              |&lt;-----------------data--| don't change credit
              |                        |
      address + address change         |
   unverified |&lt;-----------------data--| credit -= size(data)
              |--data-----------------&gt;| credit += size(data)
              |&lt;-----------------data--| credit -= size(data)
              |                        |
              |&lt;-----------------data--| credit -= size(data)
              |                        X credit &lt; size(data)
              |                        |     ==&gt; Do not send!
      address |                        |
     verified |&lt;-----------------data--| don't change credit
              |                        |

         Figure 2: Credit-Based Authorization

   Figure 2 illustrates Credit-Based Authorization for an exemplifying
   exchange of data packets:  The correspondent node measures the bytes
   received from the mobile node.  When the mobile node registers a new
   care-of address, the correspondent node labels this address
   "unverified" and sends packets there as long as the sum of the packet
   sizes does not exceed the measured, received data volume.  A
   concurrent care-of-address test is meanwhile performed.  Once the
   care-of address has been verified, the correspondent node relabels
   the address from "unverified" to "verified".  Packets can then be
   sent to the new care-of address without restrictions.  When
   insufficient credit is left while the care-of address is still
   "unverified", the correspondent node stops sending further packets to
   the address until the verification completes.  The correspondent node
   may drop these packets, direct them to the mobile node's home
   address, or buffer them for later transmission when the care-of
   address is verified.  Figure 2 does not show Mobile IPv6 signaling
   packets.




<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   The correspondent node ensures that the mobile node's acquired credit
   gradually decreases over time.  This "aging" prevents the mobile node
   from building up credit over a long time.  A malicious node with a
   slow Internet connection could otherwise provision for a burst of
   redirected packets that does not relate to its own upstream capacity.

   Allocating the mobile node's credit based on the packets that the
   mobile node sends and reducing the credit based on packets that the
   mobile node receives is defined as "Inbound Mode".  (The
   correspondent node is in control of credit allocation, and it
   computes the credit based on inbound packets received from the mobile
   node.)  A nice property of Inbound Mode is that it does not require
   support from the mobile node.  The mobile node neither needs to
   understand that Credit-Based Authorization is effective at the
   correspondent node, nor does it have to have an idea of how much
   credit it has at a particular point in time.

   Inbound Mode works fine with applications that send comparable data
   volumes into both directions.  On the other hand, the mode may
   prevent the mobile node from collecting the amount of credit it needs
   for a handoff when applications with asymmetric traffic patterns are
   in use.  For instance, file transfers and media streaming are
   characterized by high throughput towards the client, typically the
   mobile node, and comparably little throughput towards the serving
   correspondent node.

   An additional "Outbound Mode" was designed to better accommodate
   applications with asymmetric traffic patterns.  In Outbound Mode,
   packets that the correspondent node sends to the mobile node
   determine both, how much the credit increases while the current
   care-of address is verified, and how much the credit shrinks while
   the care-of address is unverified.  This resolves the issue with
   asymmetric traffic patterns.

   The security of Outbound Mode is based on the further hypothesis that
   the mobile node invests comparable effort for packet reception and
   transmission in terms of bandwidth, memory, and processing capacity.
   This justifies why credit, allocated for packets received by the
   mobile node, can be turned into packets that the correspondent node
   sends.  The question is, though, how the correspondent node can
   determine how many of the packets sent to a mobile node are actually
   received and processed by that mobile node.  Relying on transport-
   layer acknowledgments is not an option as such messages can easily be
   faked.  Outbound Mode hence defines its own feedback mechanism,
   Care-of Address Spot Checks, which is robust to spoofing.  The
   correspondent node periodically tags packets that it sends to the
   mobile node with a random, unguessable number, a so-called Spot Check
   Token.  When the mobile node receives a packet with an attached Spot



<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   Check Token, it buffers the token until it sends the next packet to
   the correspondent node.  The Spot Check Token is then included in
   this packet.  Upon reception, the correspondent node verifies whether
   the returned Spot Check Token matches a token recently sent to the
   mobile node.  New credit is allocated in proportion to the ratio
   between the number of successfully returned Spot Check Tokens and the
   total number of tokens sent.  This implies that new credit is
   approximately proportional to the fraction of packets that have made
   their way at least up to the mobile node's IP stack.  The preciseness
   of Care-of Address Spot Checks can be traded with overhead through
   the frequency with which packets are tagged with Spot Check Tokens.

   An interesting question is whether Outbound Mode could be misused by
   an attacker with asymmetric Internet connection.  Widespread digital
   subscriber lines (DSL), for example, typically have a much higher
   download rate than upload rate.  The limited upload rate would render
   most denial-of-service attempts through direct flooding meaningless.
   But the attacker could leverage the strong download rate to build up
   credit at one or multiple correspondent nodes.  It could then
   illegitimately spend the credit on a stronger, redirection-based
   flooding attack.  The reason why this has so far not been considered
   an issue is that, in order to accumulate enough credit at the remote
   end, the attacker would first have to expose itself to the same
   packet flood that it could then redirect towards the victim.

<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a>.  Heuristic Monitoring</span>

   Heuristic approaches to prevent misuse of unverified care-of
   addresses (see <a href="#section-3.5">Section 3.5</a>) are conceivable as well.  A heuristic,
   implemented at the correspondent node and possibly supplemented by a
   restrictive lifetime limit for tentative bindings, can prevent, or at
   least effectually discourage such misuse.  The challenge here seems
   to be a feasible heuristic:  On one hand, the heuristic must be
   sufficiently rigid to quickly respond to malicious intents at the
   other side.  On the other hand, it should not have a negative impact
   on a fair-minded mobile node's communications.

   Another problem with heuristics is that they are usually reactive.
   The correspondent node can only respond to misbehavior after it
   appeared.  If sanctions are imposed quickly, attacks may simply not
   be worthwhile.  Yet premature measures should be avoided.  One must
   also bear in mind that an attacker may be able to use different home
   addresses, and it is in general impossible for the correspondent node
   to see that the set of home addresses belongs to the same node.  The
   attacker may furthermore exploit multiple correspondent nodes for its
   attack in an attempt to amplify the result.





<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


<span class="h3"><a class="selflink" id="section-3.9" href="#section-3.9">3.9</a>.  Crypto-Based Identifiers</span>

   A Crypto-Based Identifier (CBID) is an identifier with a strong
   cryptographic binding to the public component of its owner's
   public/private-key pair [<a href="#ref-33" title="&quot;Crypto-Based Identifiers (CBIDs): Concepts and Applications&quot;">33</a>].  This allows the owner to prove its
   claim on the CBID:  It signs a piece of data with its private key and
   sends this to the verifier along with its public key and the
   parameters necessary to recompute the CBID.  The verifier recomputes
   the CBID and checks the owner's knowledge of the corresponding
   private key.

   CBIDs offer three main advantages:  First, spoofing attacks against a
   CBID are much harder than attacks against a non-cryptographic
   identifier like a domain name or a Mobile IPv6 home address.  Though
   an attacker can always create its own CBID, it is unlikely to find a
   public/private-key pair that produces someone else's.  Second, a CBID
   does not depend on a PKI given its inherent binding to the owner's
   public key.  Third, a CBID can be used to bind a public key to an IP
   address, in which case it is called a Cryptographically Generated
   Address (CGA) [<a href="#ref-44" title="&quot;Cryptographically Generated Addresses (CGA)&quot;">44</a>][34][<a href="#ref-47" title="&quot;Authentication of Mobile IPv6 Binding Updates and Acknowledgments&quot;">47</a>].  A CGA is syntactically just an ordinary
   IPv6 address.  It has a standard routing prefix and an interface
   identifier generated from a hash on the CGA owner's public key and
   additional parameters.

   Many applications are conceivable where CGAs are advantageous.  In
   Mobile IPv6, CGAs can bind a mobile node's home address to its public
   key [<a href="#ref-35" title="&quot;Child-proof Authentication for MIPv6&quot;">35</a>][5] and so avoid the home-address test in most correspondent
   registrations.  This accelerates the registration process and allows
   the peers to communicate independently of home-agent availability.

   Since only the interface identifier of a CGA is cryptographically
   protected, its network prefix can be spoofed, and flooding attacks
   against networks are still an issue.  An initial home-address test is
   hence required to validate the network prefix even when the home
   address is a CGA.  For the same reason, CGAs are rarely used as
   care-of addresses.

   One limitation of CGAs compared to other types of CBIDs is that the
   cryptographically protected portion is only at most 62 bits long.
   The rest of the address is occupied by a 64-bit network prefix as
   well as the universal/local and individual/group bits.  (The
   specification in [<a href="#ref-44" title="&quot;Cryptographically Generated Addresses (CGA)&quot;">44</a>] further hard-codes a 3-bit security parameter
   into the address, reducing the cryptographically protected portion to
   59 bits.)  A brute-force attack might thus reveal a public/private
   key public/private-key pair that produces a certain CGA.  This
   vulnerability can be contained by including the network prefix in the
   hash computation for the interface identifier so that an attacker, in




<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   case it did find the right public/private key public/private-key
   pair, could not form CGAs for multiple networks from it.

   To resolve collisions in generating CGAs, a collision count is part
   of the input to the hash function.  Changing this produces a
   different CGA.  Unfortunately, the collision count also reduces the
   complexity of a brute-force attack against a CGA because it allows
   the same private/public-key pair to be used to generate multiple
   CGAs.  The collision count is therefore limited to a few values only.

   Higher security can be achieved through longer CBIDs.  For example, a
   node's primary identifier in the Host Identity Protocol [<a href="#ref-21" title="&quot;Host Identity Protocol&quot;">21</a>] is a
   128-bit hash on the node's public key.  It is used as an IP-address
   replacement at stack layers above IP.  This CBID is not routable, so
   there needs to be some external localization mechanism if a node
   wants to contact a peer of which it only knows the identifier.

<span class="h3"><a class="selflink" id="section-3.10" href="#section-3.10">3.10</a>.  Pre-Configuration</span>

   Where mobile and correspondent nodes can be pre-configured with a
   shared key, bound to the mobile node's home address, authentication
   through a home-address test can be replaced by a cryptographic
   mechanism.  This has three advantages.  First, cryptography allows
   for stronger authentication than address tests.  Second, strong
   authentication facilitates binding lifetimes longer than the 7-
   minute limit that <a href="./rfc3775">RFC 3775</a> defines for correspondent registrations.
   Third, handoff delays are usually shorter with cryptographic
   approaches because the round-trips of the home-address test can be
   spared.  The disadvantage of pre-configuration is its limited
   applicability.

   Two proposals for pre-configuration are currently under discussion
   within the IETF.  [<a href="#ref-25" title="&quot;Securing Mobile IPv6 Route Optimization Using a Static Shared Key&quot;">25</a>] endows mobile nodes with the information they
   need to compute home and care-of keygen tokens themselves rather than
   having to obtain them through the return-routability procedure. [<a href="#ref-15" title="&quot;Using IPsec between Mobile and Correspondent IPv6 Nodes&quot;">15</a>]
   uses the Internet Key Exchange protocol to establish an IPsec
   security association between the peers.

   From a technical standpoint, pre-configuration can only replace a
   home-address test.  A test of the care-of address is still necessary
   to verify the mobile node's presence at that address.  The problem is
   circumvented in [<a href="#ref-25" title="&quot;Securing Mobile IPv6 Route Optimization Using a Static Shared Key&quot;">25</a>] by postulating that the correspondent node has
   sufficient trust in the mobile node to believe that the care-of
   address is correct.  This assumption discourages the use of pre-
   configuration in scenarios where such trust is unavailable, however.
   For example, a mobile-phone operator may be able to configure
   subscribers with secret keys for authorization to a particular
   service, but it may not be able to vouch that all subscribers use



<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   this service in a responsible manner.  And even if users are
   trustworthy, their mobile nodes may become infected with malware and
   start behaving unreliably.

   Another way to avoid care-of-address verification is to rely on
   access networks to filter out packets with incorrect IP source
   addresses [<a href="#ref-38" title="&quot;Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing&quot;">38</a>][43].  This approach is taken in [<a href="#ref-15" title="&quot;Using IPsec between Mobile and Correspondent IPv6 Nodes&quot;">15</a>].  The problem
   with local filtering is that it can only protect a network from
   becoming the source of an attack, not from falling victim to an
   attack.  The technique is hence potentially unreliable unless
   deployed in access networks worldwide (see <a href="#section-1.2">Section 1.2</a>).

   Care-of-address tests facilitate the use of pre-configuration in
   spite of lacking trust relationships or the existence of access
   networks without local filtering techniques.  For increased
   performance, concurrent care-of-address tests can be used in
   combination with Credit-Based Authorization or heuristic monitoring.

<span class="h3"><a class="selflink" id="section-3.11" href="#section-3.11">3.11</a>.  Semi-Permanent Security Associations</span>

   A compromise between the return-routability procedure and pre-
   configuration are semi-permanent security associations.  A semi-
   permanent security association is established between a mobile node
   and a correspondent node upon first contact, and it is used to
   authenticate the mobile node during subsequent correspondent
   registrations.  Semi-permanent security associations eliminate the
   need for periodic home-address tests and permit correspondent
   registrations with lifetimes longer than the 7-minute limit specified
   in <a href="./rfc3775">RFC 3775</a>.

   It is important to verify a mobile node's home address before a
   security association is bound to it.  An impersonator could otherwise
   create a security association for a victim's IP address and then
   redirect the victim's traffic at will until the security association
   expires.  An initial home-address test mitigates this vulnerability
   because it requires the attacker to be on the path between the victim
   and the victim's peer at least while the security association is
   being established.  Stronger security can be obtained through
   cryptographically generated home addresses (see <a href="#section-3.9">Section 3.9</a>).

   Semi-permanent security associations alone provide no verification of
   care-of addresses and must therefore be supplemented by care-of-
   address tests.  These may be performed concurrently for reduced
   handoff delays.  Semi-permanent security associations were first
   developed in [<a href="#ref-8" title="&quot;A Framework for Purpose-Built Keys (PBK)&quot;">8</a>] where they were called "purpose-built keys".






<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


<span class="h3"><a class="selflink" id="section-3.12" href="#section-3.12">3.12</a>.  Delegation</span>

   <a href="#section-1.1">Section 1.1</a> lists numerous problems of PKIs with respect to
   authentication of mobile nodes.  These problems become more
   tractable, however, if correspondent nodes authenticate home agents
   rather than mobile nodes, and the home agents vouch for the
   authenticity and trustworthiness of the mobile nodes [<a href="#ref-37" title="&quot;Certificate- basedBinding Update Protocol (CBU)&quot;">37</a>].  Such
   delegation of responsibilities solves the scalability issue with PKIs
   given that home agents can be expected to be much less numerous than
   mobile nodes.  Certificate revocation becomes less delicate as well
   because home agents are commonly administrated by a mobility provider
   and should as such be more accountable than mobile nodes.

   Another advantage of delegation is that it avoids public-key
   computations at mobile nodes.  On the other hand, the processing
   overhead at correspondent nodes increases.  This may or may not be an
   issue depending on resources available at the correspondent node
   relative to the services that the correspondent node provides.  The
   correspondent node may also be mobile itself, in which case
   cryptographic operations would be problematic.  Furthermore, the
   increased overhead implies a higher risk to resource-exhaustion
   attacks.

<span class="h3"><a class="selflink" id="section-3.13" href="#section-3.13">3.13</a>.  Mobile Networks</span>

   Mobile nodes may move as a group and attach to the Internet via a
   "mobile router" that stays with the group.  This happens, for
   example, in trains or aircraft where passengers communicate via a
   local wireless network that is globally interconnected through a
   satellite link.

   It is straightforward to support such network mobility [<a href="#ref-41" title="&quot;Network Mobility (NEMO) Basic Support Protocol&quot;">41</a>] with a
   single home agent and a tunnel between the mobile router and this
   home agent.  The mobile nodes themselves then do not have to be
   mobility-aware.  However, Route Optimization for moving networks
   [<a href="#ref-36" title="&quot;Survey on Network Mobility Support&quot;">36</a>][26][<a href="#ref-27" title="&quot;Network Mobility Route Optimization Solution Space Analysis&quot;">27</a>][55] is more complicated.  One possibility is to have the
   mobile router handle Route Optimization on behalf of the mobile
   nodes.  This requires the mobile router to modify incoming and
   outgoing packets such that they can be routed on the direct path
   between the end nodes.  The mobile router would also have to perform
   Mobile IPv6 signaling on behalf of the mobile nodes.  Similarly, a
   network of correspondent nodes can communicate with mobile nodes,
   through a "correspondent router", in a route-optimized way without
   providing mobility support themselves.







<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


<span class="h3"><a class="selflink" id="section-3.14" href="#section-3.14">3.14</a>.  Location Privacy</span>

   <a href="./rfc3775">RFC 3775</a> fails to conceal a mobile node's current position as route-
   optimized packets always carry both home and care-of addresses.  Both
   the correspondent node and a third party can therefore track the
   mobile node's whereabouts.  A workaround is to fall back to
   bidirectional tunneling where location privacy is needed.  Packets
   carrying the mobile node's care-of address are thus only transferred
   between the mobile node and the home agent, where they can be
   encrypted through IPsec ESP [<a href="#ref-42" title="&quot;IP Encapsulating Security Payload (ESP)&quot;">42</a>].  But even then should the mobile
   node periodically re-establish its IPsec security associations so as
   to become untraceable through its SPIs.  Early efforts on location
   privacy in Route Optimization include [<a href="#ref-17" title="&quot;Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem Statement&quot;">17</a>][13][<a href="#ref-24" title="&quot;IP Address Location Privacy and Mobile IPv6: Problem Statement&quot;">24</a>][30].

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Discussion</span>

   Common to the proposals discussed in <a href="#section-3">Section 3</a> is that all of them
   affect a trade-off between effectiveness, on one hand, and economical
   deployability, administrative overhead, and wide applicability, on
   the other.  Effectiveness may be equated with low latency, strong
   security, reduced signaling, or increased robustness.  Economy
   implies no, or only moderate requirements in terms of hardware
   upgrades and software modifications.  Administrative overhead relates
   to the amount of manual configuration and intervention that a
   technique needs.

   The standard return-routability procedure avoids costly pre-
   configuration or new network entities.  This minimizes both
   deployment investments as well as administrative expenses.  Variants
   with optimistic behavior and proactive or concurrent IP-address tests
   have these advantages as well.  CBIDs allow for public-key
   authentication without a PKI.  They constitute a more secure
   alternative to home-address tests and are as such most effective when
   combined with concurrent reachability verification.  CBID-based
   authentication may require nodes to be programmed with a mapping
   between human-readable identifiers and the corresponding CBIDs.
   Pre-configuration is another approach to avoid home-address tests.
   It does without computationally expensive public-key algorithms, but
   requires pair-wise credentials and, therefore, administrative
   maintenance.  Where suitable infrastructure is available, end nodes
   may delegate authentication and encryption tasks to trusted network
   entities which, in turn, vouch for the end nodes.  Delegation could
   resurrect the use of certificates for the purpose of mobility
   support.  But it introduces a dependency on the delegatees, adds the
   provisioning costs for new network entities, and is likely to be
   limited to communities of authorized nodes.





<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Cross-Layer Interactions</span>

   The performance of Route Optimization, as evaluated in this document,
   should be put into perspective of handoff-related activities in other
   parts of the network stack.  These include link-layer attachment
   procedures; link-layer security mechanisms such as negotiation,
   authentication, and key agreement; as well as IPv6 router discovery,
   address configuration, and movement detection.  A complete network
   attachment in a typical IEEE 802.11 commercial deployment requires
   over twenty link- and IP-layer messages.  Current protocol stacks
   also have a number of limitations in addition to long attachment
   delays, such as denial-of-service vulnerabilities, difficulties in
   trusting a set of access nodes distributed to physically insecure
   locations, or the inability to retrieve sufficient information for
   making a handoff decision [<a href="#ref-2" title="&quot;Analysis of Roaming Techniques&quot;">2</a>].

   A number of proposals have been put forth to improve handoff
   performance on different parts of the network stack, mostly focusing
   on handoff performance.  These include link-layer parameter tuning
   [<a href="#ref-49" title="&quot;Techniques to Reduce IEEE 802.11b MAC Layer Handoff Time&quot;">49</a>] and network-access authentication [<a href="#ref-18" title="&quot;IEEE Standard for Local and Metropolitan Area Networks: Port- Based Network Access Control&quot;">18</a>][2][<a href="#ref-32" title="&quot;Proactive Key Distribution Using Neighbor Graphs&quot;">32</a>], as well as IPv6
   router discovery [<a href="#ref-11" title="&quot;Effects of Fast Routers Advertisement on Mobile IPv6 Handovers&quot;">11</a>][12], address configuration [<a href="#ref-23" title="&quot;Optimistic Duplicate Address Detection (DAD) for IPv6&quot;">23</a>], and movement
   detection [<a href="#ref-19" title="&quot;DNA with Unmodified Routers: Prefix List Based Approach&quot;">19</a>][20].  It is uncertain how far this optimization can be
   taken by only looking at the different parts individually.  An
   integrated approach may eventually become necessary [<a href="#ref-4" title="&quot;Secure and Efficient Network Access&quot;">4</a>][53].

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Experimentation and Measurements</span>

   The number and diversity of mobility-related activities within a
   typical network stack oftentimes render theoretical analyses
   insufficient and call for additional, extensive experimentation or
   simulation.  The following is a non-exhaustive list of areas where
   practical experience is likely to yield valuable insight.

   o  Conception of a set of standard scenarios that can be used as a
      reference for comparable measurements and experimentation.
      Ideally, such standard scenarios ought to be derived from real-
      world environments, and they should include all features that
      would likely be needed in a commercial deployment.  These features
      include link-layer access control, for instance.

   o  Measurements of the performance impacts that existing enhancement
      proposals have on the different parts of the stack.

   o  Comparisons of different implementations that are based on the
      same specification.  For instance, it would be valuable to know
      how much implementations differ with regards to the use of
      parallelism that <a href="./rfc3775">RFC 3775</a> allows in home and correspondent
      registrations.



<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   o  Measurements of the impact that network conditions such as packet
      loss can have on existing and new optimizations.

   o  Statistical data collection on the behavior of mobile nodes in
      different networks.  Several Route Optimization techniques behave
      differently depending on the degree of mobility.

   o  Measurements of the performance that Route Optimization schemes
      show under different application scenarios, such as the use of
      applications with symmetric vs. asymmetric traffic patterns.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Future Research</span>

   Future research that goes beyond the techniques discussed in this
   document may consider the following items.

   o  Local mobility support or local route-repair mechanisms that do
      not require expensive configuration.  This includes
      infrastructure-based Route Optimization like [<a href="#ref-48" title="&quot;Agent-Based Route Optimization for Mobile IP&quot;">48</a>].

   o  Care-of-address verification mechanisms that are based on Secure
      Neighbor Discovery.

   o  The introduction of optimizations developed in the context of
      Mobile IPv6 to other mobility protocols, such as the Host Identity
      Protocol, the Stream Control Transmission Protocol, the Datagram
      Congestion Control Protocol, or link-layer mobility solutions.

   o  The extension of the developed mobility techniques to full multi-
      addressing, including multi-homing.

   o  Further strategies that are based on "asymmetric cost wars" [<a href="#ref-3" title="&quot;Weak Authentication: How to Authenticate Unknown Principals without Trusted Parties&quot;">3</a>],
      such as Credit-Based Authorization.

   o  Integrated techniques taking into account both link- and IP-layer
      mobility tasks.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Security Considerations</span>

   Standard Route Optimization enables mobile nodes to redirect IP
   packets at a remote peer from one IP address to another IP address.
   This ability introduces new security issues, which are explained and
   discussed in depth in [<a href="#ref-46" title="&quot;Mobile IP Version 6 Route Optimization Security Design Background&quot;">46</a>].  The alternative Route Optimization
   techniques described in this document may introduce new security
   threats that go beyond those identified in [<a href="#ref-46" title="&quot;Mobile IP Version 6 Route Optimization Security Design Background&quot;">46</a>].  Where such new
   threats exist, they are discussed and analyzed along with the
   description of the respective technique in <a href="#section-3">Section 3</a>.




<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Conclusions</span>

   Mobile IPv6 Route Optimization reduces packet-propagation latencies
   so as to facilitate interactive and real-time applications in mobile
   environments.  Unfortunately, the end-to-end protocol's high handoff
   latencies hinder exactly these applications.  A large body of effort
   has therefore recently been dedicated to Route Optimization
   improvements.  Some of the proposed techniques operate on an end-to-
   end basis, others require new or extended infrastructure in the
   network; some need pre-configuration, others are zero-configurable.
   This document has compared and evaluated the different strategies
   based on a selected set of enhancement proposals.  It stands out that
   all proposals make a trade-off between effectiveness, on one hand --
   be it in terms of reduced handoff latency, increased security, or
   lower signaling overhead -- and pre-configuration costs or requisite
   network upgrades, on the other.  An optimization's investment
   requirements, in turn, are in relation to its suitability for
   widespread deployment.

   However, the real-life performance of end-to-end mobility does not
   only depend on enhancements of Route Optimization, but ultimately on
   all parts of the protocol stack [<a href="#ref-2" title="&quot;Analysis of Roaming Techniques&quot;">2</a>].  Related optimization endeavors
   are in fact gaining momentum, and a comprehensive approach towards
   Route Optimization must incorporate the most suitable solutions
   amongst them [<a href="#ref-4" title="&quot;Secure and Efficient Network Access&quot;">4</a>].  Whichever proposals will eventually reach a
   maturity level sufficient for standardization, any effort should be
   expended to arrive at that point within the foreseeable future.
   Route Optimization requires support from both peers and depends on a
   solid basis of installed implementations in correspondent nodes.
   This should hence be included in emerging IPv6 stacks early on.
   Although IPv6 deployment is yet far away from becoming widespread,
   the sooner efficient Route Optimization will be available, the more
   likely that it will in the end be ubiquitously supported.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Acknowledgments</span>

   This document was thoroughly reviewed, in alphabetical order, by
   Samita Chakrabarti, Francis Dupont, Thierry Ernst, Gerardo Giaretta,
   James Kempf, Rajeev Koodli, Gabriel Montenegro, Vidya Narayanan, and
   Fan Zhao.  The authors wish to thank these folks for their valuable
   comments and suggestions.










<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  References</span>

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Normative References</span>

   [<a id="ref-1">1</a>]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
         IPv6", <a href="./rfc3775">RFC 3775</a>, June 2004.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Informative References</span>

   [<a id="ref-2">2</a>]   Alimian, A. and B. Aboba, "Analysis of Roaming Techniques",
         IEEE Contribution 802.11-04/0377r1, March 2004.

   [<a id="ref-3">3</a>]   Arkko, J. and P. Nikander, "Weak Authentication: How to
         Authenticate Unknown Principals without Trusted Parties",
         Proceedings of Security Protocols Workshop 2002, Cambridge, UK,
         April 2002.

   [<a id="ref-4">4</a>]   Arkko, J., Eronen, P., Nikander, P., and V. Torvinen, "Secure
         and Efficient Network Access", Proceedings of the DIMACS
         Workshop on Mobile and Wireless Security, November 2004.

   [<a id="ref-5">5</a>]   Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
         Optimization for Mobile IPv6", Work in Progress, August 2006.

   [<a id="ref-6">6</a>]   Arkko, J. and C. Vogt, "Credit-Based Authorization for Binding
         Lifetime Extension", Work in Progress, May 2004.

   [<a id="ref-7">7</a>]   Bahl, P., Adya, A., Padhye, J., and A. Walman, "Reconsidering
         Wireless Systems With Multiple Radios", ACM SIGCOMM Computer
         Communication Review, ACM Press, Vol. 34, No. 5, October 2004.

   [<a id="ref-8">8</a>]   Bradner, S., Mankin, A., and J. Schiller, "A Framework for
         Purpose-Built Keys (PBK)", Work in Progress, June 2003.

   [<a id="ref-9">9</a>]   Castellucia, C., Montenegro, G., Laganier, J., and C. Neumann,
         "Hindering Eavesdropping via IPv6 Opportunistic Encryption",
         Proceedings of the European Symposium on Research in Computer
         Security, Lecture Notes in Computer Science, Springer-Verlag,
         September 2004.

   [<a id="ref-10">10</a>]  Chandra, R., Bahl, P., and P. Bahl, "MultiNet: Connecting to
         Multiple IEEE 802.11 Networks Using a Single Wireless Card",
         Proceedings of the IEEE INFOCOM, Vol. 2, August 2004.

   [<a id="ref-11">11</a>]  Daley, G., Pentland, B., and R. Nelson, "Effects of Fast
         Routers Advertisement on Mobile IPv6 Handovers", Proceedings of
         the IEEE International Symposium on Computers and
         Communication, Vol. 1, June 2003.



<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   [<a id="ref-12">12</a>]  Daley, G., Pentland, B., and R. Nelson, "Movement Detection
         Optimizations in Mobile IPv6", Proceedings of the IEEE
         International Conference on Networks, September 2003.

   [<a id="ref-13">13</a>]  Daley, G., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22Location+Privacy+and+Mobile+IPv6%22'>"Location Privacy and Mobile IPv6"</a>, Work in
         Progress, January 2004.

   [<a id="ref-14">14</a>]  Dupont, F., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22A+Note+about+3rd+Party+Bombing+in+Mobile+IPv6%22'>"A Note about 3rd Party Bombing in Mobile IPv6"</a>,
         Work in Progress, July 2006.

   [<a id="ref-15">15</a>]  Dupont, F. and J. Combes, "Using IPsec between Mobile and
         Correspondent IPv6 Nodes", Work in Progress, August 2004.

   [<a id="ref-16">16</a>]  Dupont, F. and J. Combes, "Care-of Address Test for MIPv6 using
         a State Cookie", Work in Progress, July 2006.

   [<a id="ref-17">17</a>]  Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., and B.
         Patil, "Privacy for Mobile and Multi-homed Nodes: MoMiPriv
         Problem Statement", Work in Progress, June 2006.

   [<a id="ref-18">18</a>]  "IEEE Standard for Local and Metropolitan Area Networks: Port-
         Based Network Access Control", IEEE Standard 802.1X, December
         2004.

   [<a id="ref-19">19</a>]  Choi, J. and E. Nordmark, "DNA with Unmodified Routers: Prefix
         List Based Approach", Work in Progress, January 2006.

   [<a id="ref-20">20</a>]  Narayanan, S., Ed., "Detecting Network Attachment in IPv6
         Networks (DNAv6)", Work in Progress, October 2006.

   [<a id="ref-21">21</a>]  Moskowitz, R., Nikander, P., Jokela, Ed., P., and T. Henderson,
         "Host Identity Protocol", Work in Progress, June 2006.

   [<a id="ref-22">22</a>]  Henderson, T., Ed., "End-Host Mobility and Multihoming with the
         Host Identity Protocol", Work in Progress, June 2006.

   [<a id="ref-23">23</a>]  Moore, N., "Optimistic Duplicate Address Detection (DAD) for
         IPv6", <a href="./rfc4429">RFC 4429</a>, April 2006.

   [<a id="ref-24">24</a>]  Koodli, R., "IP Address Location Privacy and Mobile IPv6:
         Problem Statement", Work in Progress, October 2006.

   [<a id="ref-25">25</a>]  Perkins, C., "Securing Mobile IPv6 Route Optimization Using a
         Static Shared Key", <a href="./rfc4449">RFC 4449</a>, June 2006.

   [<a id="ref-26">26</a>]  Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility
         Route Optimization Problem Statement", Work in Progress,
         September 2006.



<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   [<a id="ref-27">27</a>]  Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility
         Route Optimization Solution Space Analysis", Work in Progress,
         September 2006.

   [<a id="ref-28">28</a>]  Arbaugh, W. and B. Aboba, <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22Handoff+Extension+to+RADIUS%22'>"Handoff Extension to RADIUS"</a>, Work
         in Progress, October 2003.

   [<a id="ref-29">29</a>]  "Kame-Shisa", Mobile IPv6 for FreeBSD.

   [<a id="ref-30">30</a>]  Koodli, R., Devarapalli, V., Flinck, H., and C. Perkins,
         "Solutions for IP Address Location Privacy in the Presence of
         IP Mobility", Work in Progress, February 2005.

   [<a id="ref-31">31</a>]  Nuorvala, V., Petander, H., and A. Tuominen, "Mobile IPv6 for
         Linux (MIPL)".

   [<a id="ref-32">32</a>]  Mishra, A., Shin, M., Petroni Jr., N., Clancy, C., and W.
         Arbaugh, "Proactive Key Distribution Using Neighbor Graphs",
         IEEE Wireless Communications, Vol. 11, No. 1, February 2004.

   [<a id="ref-33">33</a>]  Montenegro, G. and Claude. Castelluccia, "Crypto-Based
         Identifiers (CBIDs): Concepts and Applications", ACM
         Transactions on Information and System Security Vol.7, No. 1,
         February 2004.

   [<a id="ref-34">34</a>]  Nikander, P., "Denial-of-Service, Address Ownership, and Early
         Authentication in the IPv6 World", Revised papers from the
         International Workshop on Security Protocols, Springer-Verlag,
         April 2002.

   [<a id="ref-35">35</a>]  O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6",
         ACM SIGCOMM Computer Communication Review, April 2001.

   [<a id="ref-36">36</a>]  Perera, E., Sivaraman, V., and A. Seneviratne, "Survey on
         Network Mobility Support", ACM SIGCOMM Computer Communication
         Review, Vol. 8, No. 2, ACM Press, April 2004.

    [<a id="ref-37">37</a>]  Bao, F., Deng, R., Qiu, Y., and J. Zhou, "Certificate-
         basedBinding Update Protocol (CBU)", Work in Progress, March
         2005.

   [<a id="ref-38">38</a>]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", <a href="https://www.rfc-editor.org/bcp/bcp38">BCP 38</a>, <a href="./rfc2827">RFC 2827</a>, May 2000.

   [<a id="ref-39">39</a>]  Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
         Multihoming Architectures", <a href="./rfc3582">RFC 3582</a>, August 2003.




<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   [<a id="ref-40">40</a>]  Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
         Protect Mobile IPv6 Signaling Between Mobile Nodes and Home
         Agents", <a href="./rfc3776">RFC 3776</a>, June 2004.

   [<a id="ref-41">41</a>]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
         "Network Mobility (NEMO) Basic Support Protocol", <a href="./rfc3963">RFC 3963</a>,
         January 2005.

   [<a id="ref-42">42</a>]  Kent, S., "IP Encapsulating Security Payload (ESP)", <a href="./rfc4303">RFC 4303</a>,
         December 2005.

   [<a id="ref-43">43</a>]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
         Networks", <a href="https://www.rfc-editor.org/bcp/bcp84">BCP 84</a>, <a href="./rfc3704">RFC 3704</a>, March 2004.

   [<a id="ref-44">44</a>]  Aura, T., "Cryptographically Generated Addresses (CGA)", <a href="./rfc3972">RFC</a>
         <a href="./rfc3972">3972</a>, March 2005.

   [<a id="ref-45">45</a>]  Huston, G., "Architectural Approaches to Multi-homing for
         IPv6", <a href="./rfc4177">RFC 4177</a>, September 2005.

   [<a id="ref-46">46</a>]  Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
         Nordmark, "Mobile IP Version 6 Route Optimization Security
         Design Background", <a href="./rfc4225">RFC 4225</a>, December 2005.

   [<a id="ref-47">47</a>]  Roe, M., Aura, T., O'Shea, G., and J. Arkko, "Authentication of
         Mobile IPv6 Binding Updates and Acknowledgments", Work in
         Progress, February 2002.

   [<a id="ref-48">48</a>]  Vadali, R., Li, J., Wu, Y., and G. Cao, "Agent-Based Route
         Optimization for Mobile IP", Proceedings of the IEEE Vehicular
         Technology Conference, October 2001.

   [<a id="ref-49">49</a>]  Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b
         MAC Layer Handoff Time", Laboratory for Communication Networks,
         KTH, Royal Institute of Technology, Stockholm, Sweden, TRITA-
         IMIT-LCN R 03:02, April 2003.

   [<a id="ref-50">50</a>]  Vogt, C., "Credit-Based Authorization for Concurrent IP-Address
         Tests", Proceedings of the IST Mobile and Wireless
         Communications Summit, June 2005.

   [<a id="ref-51">51</a>]  Vogt, C., Bless, R., Doll, M., and T. Kuefner, "Early Binding
         Updates for Mobile IPv6", Proceedings of the IEEE Wireless
         Communications and Networking Conference, IEEE, Vol. 3, March
         2005.






<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


   [<a id="ref-52">52</a>]  Vogt, C. and M. Doll, "Efficient End-to-End Mobility Support in
         IPv6", Proceedings of the IEEE Wireless Communications and
         Networking Conference, April 2006.

   [<a id="ref-53">53</a>]  Vogt, C., "A Comprehensive Delay Analysis for Reactive and
         Proactive Handoffs with Mobile IPv6 Route Optimization",
         Institute of Telematics, Universitaet Karlsruhe (TH),
         Karlsruhe, Germany, TM-2006-1, January 2006.

   [<a id="ref-54">54</a>]  Zhao, F., Wu, F., and S. Jung, "Extensions to Return
         Routability Test in MIP6", Work in Progress, February 2005.

   [<a id="ref-55">55</a>]  Calderon, M., Bernardos, C., Bagnulo, M., Soto, I., and A. de
         la Oliva, "Design and Experimental Evaluation of a Route
         Optimisation Solution for NEMO", IEEE Journal on Selected Areas
         in Communications, Vol. 24, No. 9, September 2006.

Authors' Addresses

   Christian Vogt
   Institute of Telematics
   Universitaet Karlsruhe (TH)
   P.O. Box 6980
   76128 Karlsruhe
   Germany

   EMail: chvogt@tm.uka.de


   Jari Arkko
   Ericsson Research NomadicLab
   FI-02420 Jorvas
   Finland

   EMail: jari.arkko@ericsson.com
















<span class="grey">Vogt &amp; Arkko                 Informational                     [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc4651">RFC 4651</a>          MIP6 Route Optimization Enhancements     February 2007</span>


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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, THE IETF TRUST 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.

Intellectual Property

   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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   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
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   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-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Vogt &amp; Arkko                 Informational                     [Page 31]
</pre>