doc: Add RFC documents

1 files changed, 3195 insertions, 0 deletions

diff --git a/doc/rfc/rfc6252.txt b/doc/rfc/rfc6252.txt
new file mode 100644
index 0000000..4a92311
--- /dev/null
+++ b/doc/rfc/rfc6252.txt
@@ -0,0 +1,3195 @@
+
+
+
+
+
+
+Internet Research Task Force (IRTF)                        A. Dutta, Ed.
+Request for Comments: 6252                                    V. Fajardo
+Category: Informational                                           NIKSUN
+ISSN: 2070-1721                                                  Y. Ohba
+                                                             K. Taniuchi
+                                                                 Toshiba
+                                                          H. Schulzrinne
+                                                          Columbia Univ.
+                                                               June 2011
+
+
+     A Framework of Media-Independent Pre-Authentication (MPA) for
+                   Inter-Domain Handover Optimization
+
+Abstract
+
+   This document describes Media-independent Pre-Authentication (MPA), a
+   new handover optimization mechanism that addresses the issues on
+   existing mobility management protocols and mobility optimization
+   mechanisms to support inter-domain handover.  MPA is a mobile-
+   assisted, secure handover optimization scheme that works over any
+   link layer and with any mobility management protocol, and is most
+   applicable to supporting optimization during inter-domain handover.
+   MPA's pre-authentication, pre-configuration, and proactive handover
+   techniques allow many of the handoff-related operations to take place
+   before the mobile node has moved to the new network.  We describe the
+   details of all the associated techniques and their applicability for
+   different scenarios involving various mobility protocols during
+   inter-domain handover.  We have implemented the MPA mechanism for
+   various network-layer and application-layer mobility protocols, and
+   we report a summary of experimental performance results in this
+   document.
+
+   This document is a product of the IP Mobility Optimizations (MOBOPTS)
+   Research Group.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Research Task Force
+   (IRTF).  The IRTF publishes the results of Internet-related research
+   and development activities.  These results might not be suitable for
+   deployment.  This RFC represents the consensus of the MOBOPTS
+   Research Group of the Internet Research Task Force (IRTF).  Documents
+   approved for publication by the IRSG are not a candidate for any
+   level of Internet Standard; see Section 2 of RFC 5741.
+
+
+
+Dutta, et al.                 Informational                     [Page 1]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6252.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Specification of Requirements ..............................5
+      1.2. Performance Requirements ...................................5
+   2. Terminology .....................................................7
+   3. Handover Taxonomy ...............................................7
+   4. Related Work ...................................................11
+   5. Applicability of MPA ...........................................12
+   6. MPA Framework ..................................................13
+      6.1. Overview ..................................................13
+      6.2. Functional Elements .......................................14
+      6.3. Basic Communication Flow ..................................16
+   7. MPA Operations .................................................20
+      7.1. Discovery .................................................21
+      7.2. Pre-Authentication in Multiple-CTN Environment ............22
+      7.3. Proactive IP Address Acquisition ..........................23
+           7.3.1. PANA-Assisted Proactive IP Address Acquisition .....24
+           7.3.2. IKEv2-Assisted Proactive IP Address Acquisition ....24
+           7.3.3. Proactive IP Address Acquisition Using
+                  DHCPv4 Only ........................................24
+           7.3.4. Proactive IP Address Acquisition Using Stateless
+                  Autoconfiguration ..................................26
+      7.4. Tunnel Management .........................................26
+      7.5. Binding Update ............................................28
+      7.6. Preventing Packet Loss ....................................29
+           7.6.1. Packet Loss Prevention in Single-Interface MPA .....29
+           7.6.2. Preventing Packet Losses for Multiple Interfaces ...29
+           7.6.3. Reachability Test ..................................30
+
+
+
+
+
+
+Dutta, et al.                 Informational                     [Page 2]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+      7.7. Security and Mobility .....................................31
+           7.7.1. Link-Layer Security and Mobility ...................31
+           7.7.2. IP-Layer Security and Mobility .....................32
+      7.8. Authentication in Initial Network Attachment ..............33
+   8. Security Considerations ........................................33
+   9. Acknowledgments ................................................34
+   10. References ....................................................34
+      10.1. Normative References .....................................34
+      10.2. Informative References ...................................36
+   Appendix A. Proactive Duplicate Address Detection .................40
+   Appendix B. Address Resolution ....................................41
+   Appendix C. MPA Deployment Issues .................................42
+     C.1. Considerations for Failed Switching and Switch-Back ........42
+     C.2. Authentication State Management ............................43
+     C.3. Pre-Allocation of QoS Resources ............................44
+     C.4. Resource Allocation Issue during Pre-Authentication ........45
+     C.5. Systems Evaluation and Performance Results .................47
+       C.5.1. Intra-Technology, Intra-Domain .........................47
+       C.5.2. Inter-Technology, Inter-Domain .........................49
+       C.5.3. MPA-Assisted Layer 2 Pre-Authentication ................49
+     C.6. Guidelines for Handover Preparation ........................54
+
+1.  Introduction
+
+   As wireless technologies, including cellular and wireless LANs, are
+   becoming popular, supporting terminal handovers across different
+   types of access networks, such as from a wireless LAN to CDMA or to
+   General Packet Radio Service (GPRS), is considered a clear challenge.
+   On the other hand, supporting seamless terminal handovers between
+   access networks of the same type is still more challenging,
+   especially when the handovers are across IP subnets or administrative
+   domains.  To address those challenges, it is important to provide
+   terminal mobility that is agnostic to link-layer technologies in an
+   optimized and secure fashion without incurring unreasonable
+   complexity.  In this document, we discuss a framework to support
+   terminal mobility that provides seamless handovers with low latency
+   and low loss.  Seamless handovers are characterized in terms of
+   performance requirements as described in Section 1.2.  [MPA-WIRELESS]
+   is an accompanying document that describes implementation of a few
+   MPA-based systems, including performance results to show how existing
+   protocols could be leveraged to realize the functionalities of MPA.
+
+   Terminal mobility is accomplished by a mobility management protocol
+   that maintains a binding between a locator and an identifier of a
+   mobile node, where the binding is referred to as the mobility
+   binding.  The locator of the mobile node may dynamically change when
+   there is a movement of the mobile node.  The movement that causes a
+
+
+
+
+Dutta, et al.                 Informational                     [Page 3]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   change of the locator may occur when there is a change in attachment
+   point due to physical movement or network change.  A mobility
+   management protocol may be defined at any layer.  In the rest of this
+   document, the term "mobility management protocol" refers to a
+   mobility management protocol that operates at the network layer or
+   higher.
+
+   There are several mobility management protocols at different layers.
+   Mobile IP [RFC5944] and Mobile IPv6 [RFC3775] are mobility management
+   protocols that operate at the network layer.  Similarly, MOBIKE
+   (IKEv2 Mobility and Multihoming) [RFC4555] is an extension to the
+   Internet Key Exchange Protocol (IKEv2) that provides the ability to
+   deal with a change of an IP address of an IKEv2 end-point.  There are
+   several ongoing activities in the IETF to define mobility management
+   protocols at layers higher than the network layer.  HIP (Host
+   Identity Protocol) [RFC5201] defines a new protocol layer between the
+   network layer and transport layer to provide terminal mobility in a
+   way that is transparent to both the network layer and transport
+   layer.  Also, SIP-based mobility is an extension to SIP to maintain
+   the mobility binding of a SIP user agent [SIPMM].
+
+   While mobility management protocols maintain mobility bindings, these
+   cannot provide seamless handover if used in their current form.  An
+   additional optimization mechanism is needed to prevent the loss of
+   in-flight packets transmitted during the mobile node's binding update
+   procedure and to achieve seamless handovers.  Such a mechanism is
+   referred to as a mobility optimization mechanism.  For example,
+   mobility optimization mechanisms for Mobile IPv4 [RFC4881] and Mobile
+   IPv6 [RFC5568] are defined to allow neighboring access routers to
+   communicate and carry information about mobile terminals.  There are
+   protocols that are considered as "helpers" of mobility optimization
+   mechanisms.  The CARD (Candidate Access Router Discovery) protocol
+   [RFC4066] is designed to discover neighboring access routers.  CXTP
+   (Context Transfer Protocol) [RFC4067] is designed to carry state that
+   is associated with the services provided for the mobile node, or
+   context, among access routers.  In Section 4, we describe some of the
+   fast-handover schemes that attempt to reduce the handover delay.
+
+   There are several issues in existing mobility optimization
+   mechanisms.  First, existing mobility optimization mechanisms are
+   tightly coupled with specific mobility management protocols.  For
+   example, it is not possible to use mobility optimization mechanisms
+   designed for Mobile IPv4 or Mobile IPv6 with MOBIKE.  What is
+   strongly desired is a single, unified mobility optimization mechanism
+   that works with any mobility management protocol.  Second, there is
+   no existing mobility optimization mechanism that easily supports
+   handovers across administrative domains without assuming a
+   pre-established security association between administrative domains.
+
+
+
+Dutta, et al.                 Informational                     [Page 4]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   A mobility optimization mechanism should work across administrative
+   domains in a secure manner only based on a trust relationship between
+   a mobile node and each administrative domain.  Third, a mobility
+   optimization mechanism needs to support not only terminals with
+   multiple interfaces where simultaneous connectivity through multiple
+   interfaces or connectivity through a single interface can be
+   expected, but also terminals with a single interface.
+
+   This document describes a framework of Media-independent
+   Pre-Authentication (MPA), a new handover optimization mechanism that
+   addresses all those issues.  MPA is a mobile-assisted, secure
+   handover optimization scheme that works over any link layer and with
+   any mobility management protocol, including Mobile IPv4, Mobile IPv6,
+   MOBIKE, HIP, and SIP mobility.  In cases of multiple operators
+   without a roaming relationship or without an agreement to participate
+   in a key management scheme, MPA provides a framework that can perform
+   pre-authentication to establish the security mechanisms without
+   assuming a common source of trust.  In MPA, the notion of IEEE
+   802.11i pre-authentication is extended to work at a higher layer,
+   with additional mechanisms to perform early acquisition of an IP
+   address from a network where the mobile node may move, as well as
+   proactive handover to the network while the mobile node is still
+   attached to the current network.  Since this document focuses on the
+   MPA framework, it is left to future work to choose the protocols for
+   MPA and define detailed operations.  The accompanying document
+   [MPA-WIRELESS] provides one method that describes usage and
+   interactions between existing protocols to accomplish MPA
+   functionality.
+
+   This document represents the consensus of the IP Mobility
+   Optimizations (MOBOPTS) Research Group.  It has been reviewed by
+   Research Group members active in the specific area of work.
+
+1.1.  Specification of Requirements
+
+   In this document, several words are used to signify the requirements
+   of the specification.  These words are often capitalized.  The key
+   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
+   are to be interpreted as described in [RFC2119].
+
+1.2.  Performance Requirements
+
+   In order to provide desirable quality of service for interactive
+   Voice over IP (VoIP) and streaming traffic, one needs to limit the
+   value of end-to-end delay, jitter, and packet loss to a certain
+   threshold level.  ITU-T and ITU-E standards define the acceptable
+   values for these parameters.  For example, for one-way delay, ITU-T
+
+
+
+Dutta, et al.                 Informational                     [Page 5]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   G.114 [RG98] recommends 150 ms as the upper limit for most of the
+   applications, and 400 ms as generally unacceptable delay.  One-way
+   delay tolerance for video conferencing is in the range of 200 to
+   300 ms [ITU98].  Also, if an out-of-order packet is received after a
+   certain threshold, it is considered lost.  According to ETSI TR 101
+   [ETSI], a normal voice conversation can tolerate up to 2% packet
+   loss.  But this is the mean packet loss probability and may be
+   applicable to a scenario when the mobile node is subjected to
+   repeated handoff during a normal conversation.  Measurement
+   techniques for delay and jitter are described in [RFC2679],
+   [RFC2680], and [RFC2681].
+
+   In the case of interactive VoIP traffic, end-to-end delay affects the
+   jitter value, and thus is an important issue to consider.  An end-to-
+   end delay consists of several components, such as network delay,
+   operating system (OS) delay, codec delay, and application delay.  A
+   complete analysis of these delays can be found in [WENYU].  During a
+   mobile node's handover, in-flight transient traffic cannot reach the
+   mobile node because of the associated handover delay.  These
+   in-flight packets could either be lost or buffered.  If the in-flight
+   packets are lost, this packet loss will contribute to jitter between
+   the last packet before handoff and the first packet after handoff.
+   If these packets are buffered, packet loss is minimized, but there is
+   additional jitter for the in-flight packets when these are flushed
+   after the handoff.  Buffering during handoff avoids the packet loss,
+   but at the cost of additional one-way delay.  A tradeoff between one-
+   way delay and packet loss is desired based on the type of
+   application.  For example, for a streaming application, packet loss
+   can be reduced by increasing the playout buffer, resulting in longer
+   one-way packet delay.
+
+   The handover delay is attributed to several factors, such as
+   discovery, configuration, authentication, binding update, and media
+   delivery.  Many of the security-related procedures, such as handover
+   keying and re-authentication procedures, deal with cases where there
+   is a single source of trust at the top, and the underlying
+   Authentication, Authorization, and Accounting (AAA) domain elements
+   trust the top source of trust and the keys it generates and
+   distributes.  In this scenario, there is an appreciable delay in
+   re-establishing link-security-related parameters, such as
+   authentication, link key management, and access authorization during
+   inter-domain handover.  The focus of this document is the design of a
+   framework that can reduce the delay due to authentication and other
+   handoff-related operations such as configuration and binding update.
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                     [Page 6]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+2.  Terminology
+
+   Mobility Binding:  A binding between a locator and an identifier of a
+      mobile terminal.
+
+   Mobility Management Protocol (MMP):  A protocol that operates at the
+      network layer or above to maintain a binding between a locator and
+      an identifier of a mobile node.
+
+   Binding Update (BU):  A procedure to update a mobility binding.
+
+   Media-independent Pre-Authentication Mobile Node (MN):  A mobile node
+      using Media-independent Pre-Authentication (MPA).  MPA is a
+      mobile-assisted, secure handover optimization scheme that works
+      over any link layer and with any mobility management protocol.  An
+      MPA mobile node is an IP node.  In this document, the term "mobile
+      node" or "MN" without a modifier refers to "MPA mobile node".  An
+      MPA mobile node usually has a functionality of a mobile node of a
+      mobility management protocol as well.
+
+   Candidate Target Network (CTN):  A network to which the mobile node
+      may move in the near future.
+
+   Target Network (TN):  The network to which the mobile node has
+      decided to move.  The target network is selected from one or more
+      candidate target networks.
+
+   Proactive Handover Tunnel (PHT):  A bidirectional IP tunnel [RFC2003]
+      [RFC2473] that is established between the MPA mobile node and an
+      access router of a candidate target network.  In this document,
+      the term "tunnel" without a modifier refers to "proactive handover
+      tunnel".
+
+   Point of Attachment (PoA):  A link-layer device (e.g., a switch, an
+      access point, or a base station) that functions as a link-layer
+      attachment point for the MPA mobile node to a network.
+
+   Care-of Address (CoA):  An IP address used by a mobility management
+      protocol as a locator of the MPA mobile node.
+
+3.  Handover Taxonomy
+
+   Based on the type of movement, type of access network, and underlying
+   mobility support, one can primarily define the handover as inter-
+   technology, intra-technology, inter-domain, and intra-domain.  We
+   describe briefly each of these handover processes.  However, our
+   focus of the discussion is on inter-domain handover.
+
+
+
+
+Dutta, et al.                 Informational                     [Page 7]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   Inter-technology:  A mobile node may be equipped with multiple
+      interfaces, where each interface can support a different access
+      technology (e.g., 802.11, CDMA).  A mobile node may communicate
+      with one interface at any time in order to conserve power.  During
+      the handover, the mobile node may move out of the footprint of one
+      access technology (e.g., 802.11) and move into the footprint of a
+      different access technology (e.g., CDMA).  This will warrant
+      switching of the communicating interface on the mobile node as
+      well.  This type of inter-technology handover is often called
+      "vertical handover", since the mobile node moves between two
+      different cell sizes.
+
+   Intra-technology:  An intra-technology handover is defined as when a
+      mobile node moves within the same type of access technology, such
+      as between 802.11[a,b,n] and 802.11 [a,b,n] or between CDMA1XRTT
+      and CDMA1EVDO.  In this scenario, a mobile node may be equipped
+      with a single interface (with multiple PHY types of the same
+      technology) or with multiple interfaces.  An intra-technology
+      handover may involve intra-subnet or inter-subnet movement and
+      thus may need to change its L3 locator, depending upon the type of
+      movement.
+
+   Inter-domain:  A domain can be defined in several ways.  But for the
+      purposes of roaming, we define "domain" as an administrative
+      domain that consists of networks managed by a single
+      administrative entity that authenticates and authorizes a mobile
+      node for accessing the networks.  An administrative entity may be
+      a service provider, an enterprise, or any organization.  Thus, an
+      inter-domain handover will by default be subjected to inter-subnet
+      handover, and in addition it may be subjected to either inter-
+      technology or intra-technology handover.  A mobile node is
+      subjected to inter-subnet handover when it moves from one subnet
+      (broadcast domain) to another subnet (broadcast domain).  Inter-
+      domain handover will be subjected to all the transition steps a
+      subnet handover goes through, and it will be subjected to
+      authentication and authorization processes as well.  It is also
+      likely that the type of mobility support in each administrative
+      domain will be different.  For example, administrative domain A
+      may have Mobile IP version 6 (MIPv6) support, while administrative
+      domain B may use Proxy MIPv6 [RFC5213].
+
+   Intra-domain:  When a mobile node's movement is confined to movement
+      within an administrative domain, it is called "intra-domain
+      movement".  An intra-domain movement may involve intra-subnet,
+      inter-subnet, intra-technology, and inter-technology as well.
+
+
+
+
+
+
+Dutta, et al.                 Informational                     [Page 8]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   Both inter-domain and intra-domain handovers can be subjected to
+   either inter-technology or intra-technology handover based on the
+   network access characteristics.  Inter-domain handover requires
+   authorization for acquisition or modification of resources assigned
+   to a mobile node, and the authorization needs interaction with a
+   central authority in a domain.  In many cases, an authorization
+   procedure during inter-domain handover follows an authentication
+   procedure that also requires interaction with a central authority in
+   a domain.  Thus, security associations between the network entities,
+   such as routers in the neighboring administrative domains, need to be
+   established before any interaction takes place between these
+   entities.  Similarly, an inter-domain mobility may involve different
+   mobility protocols, such as MIPv6 and Proxy MIPv6, in each of its
+   domains.  In that case, one needs a generalized framework to achieve
+   the optimization during inter-domain handover.  Figure 1 shows a
+   typical example of inter-domain mobility involving two domains,
+   domain A and domain B.  It illustrates several important components,
+   such as a AAA Home server (AAAH); AAA visited servers (e.g., AAAV1
+   and AAAV2); an Authentication Agent (AA); a layer 3 point of
+   attachment, such as an Access Router (AR); and a layer 2 point of
+   attachment, such as an Access Point (AP).  Any mobile node may be
+   using a specific mobility protocol and associated mobility
+   optimization technique during intra-domain movement in either domain.
+   But the same optimization technique may not be suitable to support
+   inter-domain handover, independent of whether it uses the same or a
+   different mobility protocol in either domain.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                     [Page 9]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+                        +-----------------------------+
+                        |      +--------+             |
+                        |      |        |             |
+                        |      | AAAH   ------------------|
+                        |      |        |             |   |
+                        |      +|-------+             |   |
+                        |       |                     |   |
+                        |       |  Home Domain        |   |
+                        |       |                     |   |
+                        +-------|---------------------+   |
+                                |                         |
+                                |                         |
+                                |                         |
+   +----------------------------|---------+ +-------------|------------+
+   | Domain A                   |         | | Domain B    |            |
+   |                            |         | |            +|-------+    |
+   |                    +-------|+        | | +-----+    |        |    |
+   |                    |        |        | | |     ------ AAAV2  |    |
+   |                    | AAAV1  |        | | | AA  |    |        |    |
+   |      +--------------        |        | | +|----+    +--------+    |
+   |      |     |       +--------+        | |  |                       |
+   |      |AA   |                         | |  |---         ----       |
+   |      +--|--+                         | | /    \       /    \      |
+   |         |              /----\        | || AR   |-----| AR   |     |
+   |        -|--           /      \       | | \    /       \    /      |
+   |       /    \         | AR     |      | |  -|--         --|-       |
+   |      | AR   -----------      /       | |+--|---+  +------|------+ |
+   |       \    /           \--|-/        | || AP4  |  |  L2 Switch  | |
+   |        -/--         +-----|------+   | ||      |  +-|---------|-+ |
+   |        /            |  L2 Switch |   | |+------+    |         |   |
+   |       /             +-|-------|--+   | |        +---|--+ +----|-+ |
+   | +----/-+         +----|-+   +-|----+ | |        |      | |      | |
+   | |      |         |      |   |      | | |        | AP5  | |AP6   | |
+   | | AP1  |         | AP2  |   | AP3  | | |        +----|-+ +------+ |
+   | +------+         +------+   +--|---+ | |             |            |
+   +--------------------------------|-----+ +------------ |------------+
+                                  --|---------            |
+                              ////            \\\\   -----|-----
+                            //    +------+       ////  +------+ \\\\
+                            |     | MN   ------------->|MN  |     \\\
+                           |      |      |    |     |  |      |       |
+                            |     +------+   |     |   +------+        |
+                            \\                |   //                  |
+                              \\\\            \\\/                  ///
+                                  ------------   \\\\------------- ////
+
+                      Figure 1: Inter-Domain Mobility
+
+
+
+
+Dutta, et al.                 Informational                    [Page 10]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+4.  Related Work
+
+   While basic mobility management protocols such as Mobile IP
+   [RFC5944], Mobile IPv6 [RFC3775], and SIP-Mobility [SIPMM] provide
+   continuity to TCP and RTP traffic, these are not optimized to reduce
+   the handover latency during a mobile node's movement between subnets
+   and domains.  In general, these mobility management protocols
+   introduce handover delays incurred at several layers, such as layer 3
+   and the application layer, for updating the mobile node's mobility
+   binding.  These protocols are affected by underlying layer 2 delay as
+   well.  As a result, applications using these mobility protocols
+   suffer from performance degradation.
+
+   There have been several optimization techniques that apply to current
+   mobility management schemes that try to reduce handover delay and
+   packet loss during a mobile node's movement between cells, subnets,
+   and domains.  Micro-mobility management schemes such as [CELLIP] and
+   [HAWAII], and intra-domain mobility management schemes such as
+   [IDMP], [MOBIP-REG], and [RFC5380], provide fast handover by limiting
+   the signaling updates within a domain.  Fast Mobile IP protocols for
+   IPv4 and IPv6 networks [RFC4881] [RFC5568] utilize mobility
+   information made available by link-layer triggers.  Yokota et
+   al. [YOKOTA] propose the joint use of an access point and a dedicated
+   Media Access Control (MAC) bridge to provide fast handover without
+   altering the MIPv4 specification.  Shin et al. [MACD] propose a
+   scheme that reduces the delay due to MAC-layer handoff by providing a
+   cache-based algorithm.  In this scheme, the mobile node caches the
+   neighboring channels that it has already visited and thus uses a
+   selective scanning method.  This helps to reduce the associated
+   scanning time.
+
+   Some mobility management schemes use dual interfaces, thus providing
+   make-before-break [SUM].  In a make-before-break situation,
+   communication usually continues with one interface when the secondary
+   interface is in the process of getting connected.  The IEEE 802.21
+   working group is discussing these scenarios in detail [802.21].
+   Providing fast handover using a single interface needs more careful
+   design than for a client with multiple interfaces.  Dutta et
+   al. [SIPFAST] provide an optimized handover scheme for SIP-based
+   mobility management, where the transient traffic is forwarded from
+   the old subnet to the new one by using an application-layer
+   forwarding scheme.  [MITH] provides a fast-handover scheme for the
+   single-interface case that uses mobile-initiated tunneling between
+   the old Foreign Agent and a new Foreign Agent.  [MITH] defines two
+   types of handover schemes: Pre-MIT (Mobile Initiated Tunneling) and
+   Post-MIT (Media Initiated Tunneling).  The proposed MPA scheme is
+   very similar to Mobile Initiated Tunneling Handoff's (MITH's)
+   predictive scheme, where the mobile node communicates with the
+
+
+
+Dutta, et al.                 Informational                    [Page 11]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   Foreign Agent before actually moving to the new network.  However,
+   the MPA scheme is not limited to MIP; this scheme takes care of
+   movement between domains and performs pre-authentication in addition
+   to proactive handover.  Thus, MPA reduces the overall delay to a
+   period close to that of link-layer handover delay.  Most of the
+   mobility optimization techniques developed so far are restricted to a
+   specific type of mobility protocol only.  While supporting
+   optimization for inter-domain mobility, these protocols assume that
+   there is a pre-established security arrangement between two
+   administrative domains.  But this assumption may not always be
+   viable.  Thus, there is a need to develop an optimization mechanism
+   that can support inter-domain mobility without any underlying
+   constraints or security-related assumptions.
+
+   Recently, the HOKEY working group within the IETF has been defining
+   ways to expedite the authentication process.  In particular, it has
+   defined pre-authentication [RFC5836] and fast re-authentication
+   [RFC5169] mechanisms to expedite the authentication and security
+   association process.
+
+5.  Applicability of MPA
+
+   MPA is more applicable where an accurate prediction of movement can
+   be easily made.  For other environments, special care must be taken
+   to deal with issues such as pre-authentication to multiple CTNs
+   (Candidate Target Networks), and failed switching and switching back
+   as described in [MPA-WIRELESS].  However, addressing those issues in
+   actual deployments may not be easier.  Some of the deployment issues
+   are described in Appendix C.
+
+   The authors of the accompanying document [MPA-WIRELESS] have cited
+   several use cases of how MPA can be used to optimize several network-
+   layer and application-layer mobility protocols.  The effectiveness of
+   MPA may be relatively reduced if the network employs network-
+   controlled localized mobility management in which the MN does not
+   need to change its IP address while moving within the network.  The
+   effectiveness of MPA may also be relatively reduced if signaling for
+   network access authentication is already optimized for movements
+   within the network, e.g., when simultaneous use of multiple
+   interfaces during handover is allowed.  In other words, MPA is more
+   viable as a solution for inter-administrative domain predictive
+   handover without the simultaneous use of multiple interfaces.  Since
+   MPA is not tied to a specific mobility protocol, it is also
+   applicable to support optimization for inter-domain handover where
+   each domain may be equipped with a different mobility protocol.
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 12]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   Figure 1 shows an example of inter-domain mobility where MPA could be
+   applied.  For example, domain A may support just Proxy MIPv6, whereas
+   domain B may support Client Mobile IPv6.  MPA's different functional
+   components can provide the desired optimization techniques
+   proactively.
+
+6.  MPA Framework
+
+6.1.  Overview
+
+   Media-independent Pre-Authentication (MPA) is a mobile-assisted,
+   secure handover optimization scheme that works over any link layer
+   and with any mobility management protocol.  With MPA, a mobile node
+   is not only able to securely obtain an IP address and other
+   configuration parameters for a CTN, but also able to send and receive
+   IP packets using the IP address obtained before it actually attaches
+   to the CTN.  This makes it possible for the mobile node to complete
+   the binding update of any mobility management protocol and use the
+   new CoA before performing a handover at the link layer.
+
+   MPA adopts the following basic procedures to provide this
+   functionality.  The first procedure is referred to as
+   "pre-authentication", the second procedure is referred to as
+   "pre-configuration", and the combination of the third and fourth
+   procedures is referred to as "secure proactive handover".  The
+   security association established through pre-authentication is
+   referred to as an "MPA-SA".
+
+   This functionality is provided by allowing a mobile node that has
+   connectivity to the current network, but is not yet attached to a
+   CTN, to
+
+      (i) establish a security association with the CTN to secure the
+      subsequent protocol signaling, then
+
+      (ii) securely execute a configuration protocol to obtain an IP
+      address and other parameters from the CTN as well as execute a
+      tunnel management protocol to establish a Proactive Handover
+      Tunnel (PHT) [RFC2003] between the mobile node and an access
+      router of the CTN, then
+
+      (iii) send and receive IP packets, including signaling messages
+      for the binding update of an MMP and data packets transmitted
+      after completion of the binding update, over the PHT, using the
+      obtained IP address as the tunnel inner address, and finally
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 13]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+      (iv) delete or disable the PHT immediately before attaching to the
+      CTN when it becomes the target network, and then re-assign the
+      inner address of the deleted or disabled tunnel to its physical
+      interface immediately after the mobile node is attached to the
+      target network through the interface.  Instead of deleting or
+      disabling the tunnel before attaching to the target network, the
+      tunnel may be deleted or disabled immediately after being attached
+      to the target network.
+
+   Step (iii) above (i.e., the binding update procedure), in particular,
+   makes it possible for the mobile node to complete the higher-layer
+   handover before starting a link-layer handover.  This means that the
+   mobile node is able to send and receive data packets transmitted
+   after completing the binding update over the tunnel, while data
+   packets transmitted before completion of the binding update do not
+   use the tunnel.
+
+6.2.  Functional Elements
+
+   In the MPA framework, the following functional elements are expected
+   to reside in each CTN to communicate with a mobile node: an
+   Authentication Agent (AA), a Configuration Agent (CA), and an Access
+   Router (AR).  These elements can reside in one or more network
+   devices.
+
+   An authentication agent is responsible for pre-authentication.  An
+   authentication protocol is executed between the mobile node and the
+   authentication agent to establish an MPA-SA.  The authentication
+   protocol MUST be able to establish a shared key between the mobile
+   node and the authentication agent and SHOULD be able to provide
+   mutual authentication.  The authentication protocol SHOULD be able to
+   interact with a AAA protocol, such as RADIUS or Diameter, to carry
+   authentication credentials to an appropriate authentication server in
+   the AAA infrastructure.  This interaction happens through the
+   authentication agent, such as the PANA Authentication Agent (PAA).
+   In turn, the derived key is used to derive additional keys that will
+   be applied to protecting message exchanges used for pre-configuration
+   and secure proactive handover.  Other keys that are used for
+   bootstrapping link-layer and/or network-layer ciphers MAY also be
+   derived from the MPA-SA.  A protocol that can carry the Extensible
+   Authentication Protocol (EAP) [RFC3748] would be suitable as an
+   authentication protocol for MPA.
+
+
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 14]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   A configuration agent is responsible for one part of
+   pre-configuration, namely securely executing a configuration protocol
+   to deliver an IP address and other configuration parameters to the
+   mobile node.  The signaling messages of the configuration protocol
+   (e.g., DHCP) MUST be protected using a key derived from the key
+   corresponding to the MPA-SA.
+
+   An access router in the MPA framework is a router that is responsible
+   for the other part of pre-configuration, i.e., securely executing a
+   tunnel management protocol to establish a proactive handover tunnel
+   to the mobile node.  IP packets transmitted over the proactive
+   handover tunnel SHOULD be protected using a key derived from the key
+   corresponding to the MPA-SA.  Details of this procedure are described
+   in Section 6.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 15]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   Figure 2 shows the basic functional components of MPA.
+
+                                        +----+
+                                        | CN |
+                                        +----+
+                                         /
+                              (Core Network)
+                             /              \
+                            /                \
+          +----------------/--------+    +----\-----------------+
+          | +-----+                 |    |+-----+               |
+          | |     |        +-----+  |    ||     |       +-----+ |
+          | | AA  |        |CA   |  |    ||AA   |       | CA  | |
+          | +--+--+        +--+--+  |    |+--+--+       +--+--+ |
+          |    |   +------+   |     |    |   | +-----+     |    |
+          |    |   | pAR  |   |     |    |   | |nAR  |     |    |
+          | ---+---+      +---+-----+----+---+-+     +-----+    |
+          |        +---+--+         |    |     +-----+          |
+          |            |            |    |                      |
+          |            |            |    |                      |
+          |            |            |    |                      |
+          +------------+------------+    +--------|-------------+
+          Current      |                 Candidate| Target Network
+          Network      |                          |
+                    +------+                  +------+
+                    | oPoA |                  | nPoA |
+                    +--.---+                  +--.---+
+                       .                         .
+                       .                         .
+                    +------+
+                    |  MN  |  ---------->
+                    +------+
+
+                    Figure 2: MPA Functional Components
+
+6.3.  Basic Communication Flow
+
+   Assume that the mobile node is already connected to a point of
+   attachment, say oPoA (old point of attachment), and assigned a
+   care-of address, say oCoA (old care-of address).  The communication
+   flow of MPA is described as follows.  Throughout the communication
+   flow, data packet loss should not occur except for the period during
+   the switching procedure in Step 5 below, and it is the responsibility
+   of link-layer handover to minimize packet loss during this period.
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 16]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   Step 1 (pre-authentication phase):  The mobile node finds a CTN
+      through some discovery process, such as IEEE 802.21, and obtains
+      the IP addresses of an authentication agent, a configuration
+      agent, and an access router in the CTN (Candidate Target Network)
+      by some means.  Details about discovery mechanisms are discussed
+      in Section 7.1.  The mobile node performs pre-authentication with
+      the authentication agent.  As discussed in Section 7.2, the mobile
+      node may need to pre-authenticate with multiple candidate target
+      networks.  The decision regarding with which candidate network the
+      mobile node needs to pre-authenticate will depend upon several
+      factors, such as signaling overhead, bandwidth requirement
+      (Quality of Service (QoS)), the mobile node's location,
+      communication cost, handover robustness, etc.  Determining the
+      policy that decides the target network with which the mobile node
+      should pre-authenticate is out of scope for this document.
+
+      If the pre-authentication is successful, an MPA-SA is created
+      between the mobile node and the authentication agent.  Two keys
+      are derived from the MPA-SA, namely an MN-CA key and an MN-AR key,
+      which are used to protect subsequent signaling messages of a
+      configuration protocol and a tunnel management protocol,
+      respectively.  The MN-CA key and the MN-AR key are then securely
+      delivered to the configuration agent and the access router,
+      respectively.
+
+   Step 2 (pre-configuration phase):  The mobile node realizes that its
+      point of attachment is likely to change from the oPoA to a new
+      one, say nPoA (new point of attachment).  It then performs
+      pre-configuration with the configuration agent, using the
+      configuration protocol to obtain several configuration parameters
+      such as an IP address, say nCoA (new care-of address), and a
+      default router from the CTN.  The mobile node then communicates
+      with the access router using the tunnel management protocol to
+      establish a proactive handover tunnel.  In the tunnel management
+      protocol, the mobile node registers the oCoA and the nCoA as the
+      tunnel outer address and the tunnel inner address, respectively.
+      The signaling messages of the pre-configuration protocol are
+      protected using the MN-CA key and the MN-AR key.  When the
+      configuration agent and the access router are co-located in the
+      same device, the two protocols may be integrated into a single
+      protocol, such as IKEv2.  After completion of the tunnel
+      establishment, the mobile node is able to communicate using both
+      the oCoA and the nCoA by the end of Step 4.  A configuration
+      protocol and a tunnel management protocol may be combined in a
+      single protocol or executed in different orders depending on the
+      actual protocol(s) used for configuration and tunnel management.
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 17]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   Step 3 (secure proactive handover main phase):  The mobile node
+      decides to switch to the new point of attachment by some means.
+      Before the mobile node switches to the new point of attachment, it
+      starts secure proactive handover by executing the binding update
+      operation of a mobility management protocol and transmitting
+      subsequent data traffic over the tunnel (main phase).  This
+      proactive binding update could be triggered based on certain local
+      policy at the mobile node end, after the pre-configuration phase
+      is over.  This local policy could be Signal-to-Noise Ratio,
+      location of the mobile node, etc.  In some cases, it may cache
+      multiple nCoA addresses and perform simultaneous binding with the
+      Correspondent Node (CN) or Home Agent (HA).
+
+   Step 4 (secure proactive handover pre-switching phase):  The mobile
+      node completes the binding update and becomes ready to switch to
+      the new point of attachment.  The mobile node may execute the
+      tunnel management protocol to delete or disable the proactive
+      handover tunnel and cache the nCoA after deletion or disabling of
+      the tunnel.  This transient tunnel can be deleted prior to or
+      after the handover.  The buffering module at the next access
+      router buffers the packets once the tunnel interface is deleted.
+      The decision as to when the mobile node is ready to switch to the
+      new point of attachment depends on the handover policy.
+
+   Step 5 (switching):  It is expected that a link-layer handover occurs
+      in this step.
+
+   Step 6 (secure proactive handover post-switching phase):  The mobile
+      node executes the switching procedure.  Upon successful completion
+      of the switching procedure, the mobile node immediately restores
+      the cached nCoA and assigns it to the physical interface attached
+      to the new point of attachment.  If the proactive handover tunnel
+      was not deleted or disabled in Step 4, the tunnel is deleted or
+      disabled as well.  After this, direct transmission of data packets
+      using the nCoA is possible without using a proactive handover
+      tunnel.
+
+   Call flow for MPA is shown in Figures 3 and 4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 18]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+                                                         IP address(es)
+                                                          Available for
+                                                             Use by MN
+                                                                   |
+                           +-----------------------------------+   |
+                           |     Candidate Target Network      |   |
+                           |     (Future Target Network)       |   |
+             MN       oPoA | nPoA     AA        CA        AR   |   |
+             |         |   |  |       |         |         |    |   |
+             |         |   +-----------------------------------+   |
+             |         |      |       |         |         |        .
+    +---------------+  |      |       |         |         |        .
+    |(1) Found a CTN|  |      |       |         |         |        .
+    +---------------+  |      |       |         |         |        |
+             |   Pre-authentication   |         |         |        |
+             |   [authentication protocol]      |         |        |
+             |<--------+------------->|MN-CA key|         |        |
+             |         |      |       |-------->|MN-AR key|        |
+   +-----------------+ |      |       |------------------>|        |
+   |(2) Increased    | |      |       |         |         |     [oCoA]
+   |chance to switch | |      |       |         |         |        |
+   |     to CTN      | |      |       |         |         |        |
+   +-----------------+ |      |       |         |         |        |
+             |         |      |       |         |         |        |
+             |   Pre-configuration    |         |         |        |
+             |   [configuration protocol to get nCoA]     |        |
+             |<--------+----------------------->|         |        |
+             |   Pre-configuration    |         |         |        |
+             |   [tunnel management protocol to establish PHT]     V
+             |<--------+--------------------------------->|
+             |         |      |       |         |         |        ^
+   +-----------------+ |      |       |         |         |        |
+   |(3) Determined   | |      |       |         |         |        |
+   |to switch to CTN | |      |       |         |         |        |
+   +-----------------+ |      |       |         |         |        |
+             |         |      |       |         |         |        |
+             |   Secure proactive handover main phase     |        |
+             |   [execution of binding update of MMP and  |        |
+             |    transmission of data packets through AR | [oCoA, nCoA]
+             |    based on nCoA over the PHT]   |         |        |
+             |<<=======+================================>+--->...  |
+             .         .      .       .         .         .        .
+             .         .      .       .         .         .        .
+             .         .      .       .         .         .        .
+
+                Figure 3: Example Communication Flow (1/2)
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 19]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+             |         |      |       |         |         |        |
+   +----------------+  |      |       |         |         |        |
+   |(4) Completion  |  |      |       |         |         |        |
+   |of MMP BU and   |  |      |       |         |         |        |
+   |ready to switch |  |      |       |         |         |        |
+   +----------------+  |      |       |         |         |        |
+             |   Secure proactive handover pre-switching phase     |
+             |   [tunnel management protocol to delete PHT]        V
+             |<--------+--------------------------------->|
+    +---------------+         |       |         |         |
+    |(5)Switching   |         |       |         |         |
+    +---------------+         |       |         |         |
+             |                |       |         |         |
+    +---------------+         |       |         |         |
+    |(6) Completion |         |       |         |         |
+    |of switching   |         |       |         |         |
+    +---------------+         |       |         |         |
+             o<- Secure proactive handover post-switching phase ^
+             |   [Re-assignment of Tunnel Inner Address   |        |
+             |                 to the physical I/F]       |        |
+             |                |       |         |         |        |
+             |   Transmission of data packets through AR  |     [nCoA]
+             |   based on nCoA|       |         |         |        |
+             |<---------------+---------------------------+-->...  |
+             |                |       |         |         |        .
+
+                Figure 4: Example Communication Flow (2/2)
+
+7.  MPA Operations
+
+   In order to provide an optimized handover for a mobile node
+   experiencing rapid movement between subnets and/or domains, one needs
+   to look into several operations.  These issues include:
+
+      i) discovery of neighboring networking elements,
+
+      ii) connecting to the right network based on certain policy,
+
+      iii) changing the layer 2 point of attachment,
+
+      iv) obtaining an IP address from a DHCP or PPP server,
+
+      v) confirming the uniqueness of the IP address,
+
+      vi) pre-authenticating with the authentication agent,
+
+      vii) sending the binding update to the Correspondent Host (CH),
+
+
+
+
+Dutta, et al.                 Informational                    [Page 20]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+      viii) obtaining the redirected streaming traffic to the new point
+      of attachment,
+
+      ix) ping-pong effect, and
+
+      x) probability of moving to more than one network and associating
+      with multiple target networks.
+
+   We describe these issues in detail in the following paragraphs and
+   describe how we have optimized these issues in the case of MPA-based
+   secure proactive handover.
+
+7.1.  Discovery
+
+   Discovery of neighboring networking elements such as access points,
+   access routers, and authentication servers helps expedite the
+   handover process during a mobile node's movement between networks.
+   After discovering the network neighborhood with a desired set of
+   coordinates, capabilities, and parameters, the mobile node can
+   perform many of the operations, such as pre-authentication, proactive
+   IP address acquisition, proactive address resolution, and binding
+   update, while in the previous network.
+
+   There are several ways a mobile node can discover neighboring
+   networks.  The Candidate Access Router Discovery protocol [RFC4066]
+   helps discover the candidate access routers in the neighboring
+   networks.  Given a certain network domain, SLP (Service Location
+   Protocol) [RFC2608] and DNS help provide addresses of the networking
+   components for a given set of services in the specific domain.  In
+   some cases, many of the network-layer and upper-layer parameters may
+   be sent over link-layer management frames, such as beacons, when the
+   mobile node approaches the vicinity of the neighboring networks.
+   IEEE 802.11u is considering issues such as discovering the
+   neighborhood using information contained in the link layer.  However,
+   if the link-layer management frames are encrypted by some link-layer
+   security mechanism, then the mobile node may not be able to obtain
+   the requisite information before establishing link-layer connectivity
+   to the access point.  In addition, this may add burden to the
+   bandwidth-constrained wireless medium.  In such cases, a higher-layer
+   protocol is preferred to obtain the information regarding the
+   neighboring elements.  Some proposals, such as [802.21], help obtain
+   information about the neighboring networks from a mobility server.
+   When the movement is imminent, the mobile node starts the discovery
+   process by querying a specific server and obtains the required
+   parameters, such as the IP address of the access point, its
+   characteristics, routers, SIP servers, or authentication servers of
+   the neighboring networks.  In the event of multiple networks, it may
+   obtain the required parameters from more than one neighboring network
+
+
+
+Dutta, et al.                 Informational                    [Page 21]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   and keep these in a cache.  At some point, the mobile node finds
+   several CTNs out of many probable networks and starts the pre-
+   authentication process by communicating with the required entities in
+   the CTNs.  Further details of this scenario are in Section 7.2.
+
+7.2.  Pre-Authentication in Multiple-CTN Environment
+
+   In some cases, although a mobile node selects a specific network to
+   be the target network, it may actually end up moving into a
+   neighboring network other than the target network, due to factors
+   that are beyond the mobile node's control.  Thus, it may be useful to
+   perform the pre-authentication with a few probable candidate target
+   networks and establish time-bound transient tunnels with the
+   respective access routers in those networks.  Thus, in the event of a
+   mobile node moving to a candidate target network other than that
+   chosen as the target network, it will not be subjected to packet loss
+   due to authentication and IP address acquisition delay that could
+   occur if the mobile node did not pre-authenticate with that candidate
+   target network.  It may appear that by pre-authenticating with a
+   number of candidate target networks and reserving the IP addresses,
+   the mobile node is reserving resources that could be used otherwise.
+   But since this happens for a time-limited period, it should not be a
+   big problem; it depends upon the mobility pattern and duration.  The
+   mobile node uses a pre-authentication procedure to obtain an IP
+   address proactively and to set up the time-bound tunnels with the
+   access routers of the candidate target networks.  Also, the MN may
+   retain some or all of the nCoAs for future movement.
+
+   The mobile node may choose one of these addresses as the binding
+   update address and send it to the CN (Correspondent Node) or HA (Home
+   Agent), and will thus receive the tunneled traffic via the target
+   network while in the previous network.  But in some instances, the
+   mobile node may eventually end up moving to a network that is other
+   than the target network.  Thus, there will be a disruption in traffic
+   as the mobile node moves to the new network, since the mobile node
+   has to go through the process of assigning the new IP address and
+   sending the binding update again.  There are two solutions to this
+   problem.  As one solution to the problem, the mobile node can take
+   advantage of the simultaneous mobility binding and send multiple
+   binding updates to the Correspondent Host or HA.  Thus, the
+   Correspondent Host or HA forwards the traffic to multiple IP
+   addresses assigned to the virtual interfaces for a specific period of
+   time.  This binding update gets refreshed at the CH after the mobile
+   node moves to the new network, thus stopping the flow to the other
+   candidate networks.  RFC 5648 [RFC5648] discusses different scenarios
+   of mobility binding with multiple care-of-addresses.  As the second
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 22]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   solution, in case simultaneous binding is not supported in a specific
+   mobility scheme, forwarding of traffic from the previous target
+   network will help take care of the transient traffic until the new
+   binding update is sent from the new network.
+
+7.3.  Proactive IP Address Acquisition
+
+   In general, a mobility management protocol works in conjunction with
+   the Foreign Agent or in the co-located address mode.  The MPA
+   approach can use both the co-located address mode and the Foreign
+   Agent address mode.  We discuss here the address assignment component
+   that is used in the co-located address mode.  There are several ways
+   a mobile node can obtain an IP address and configure itself.  In some
+   cases, a mobile node can configure itself statically in the absence
+   of any configuration element such as a server or router in the
+   network.  In a LAN environment, the mobile node can obtain an IP
+   address from DHCP servers.  In the case of IPv6 networks, a mobile
+   node has the option of obtaining the IP address using stateless
+   autoconfiguration or DHCPv6.  In some wide-area networking
+   environments, the mobile node uses PPP (Point-to-Point Protocol) to
+   obtain the IP address by communicating with a NAS (Network Access
+   Server).
+
+   Each of these processes takes on the order of few hundred
+   milliseconds to a few seconds, depending upon the type of IP address
+   acquisition process and operating system of the clients and servers.
+   Since IP address acquisition is part of the handover process, it adds
+   to the handover delay, and thus it is desirable to reduce this delay
+   as much as possible.  There are a few optimized techniques available,
+   such as DHCP Rapid Commit [RFC4039] and GPS-coordinate-based IP
+   address [GPSIP], that attempt to reduce the handover delay due to IP
+   address acquisition time.  However, in all these cases, the mobile
+   node also obtains the IP address after it moves to the new subnet and
+   incurs some delay because of the signaling handshake between the
+   mobile node and the DHCP server.
+
+   In Fast MIPv6 [RFC5568], through the RtSolPr and PrRtAdv messages,
+   the MN also formulates a prospective new CoA (nCoA) when it is still
+   present on the Previous Access Router's (pAR's) link.  Hence, the
+   latency due to new prefix discovery subsequent to handover is
+   eliminated.  However, in this case, both the pAR and the Next Access
+   Router (nAR) need to cooperate with each other to be able to retrieve
+   the prefix from the target network.
+
+   In the following paragraph, we describe a few ways that a mobile node
+   can obtain the IP address proactively from the CTN, and the
+   associated tunnel setup procedure.  These can broadly be divided into
+   four categories: PANA-assisted proactive IP address acquisition,
+
+
+
+Dutta, et al.                 Informational                    [Page 23]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   IKE-assisted proactive IP address acquisition, proactive IP address
+   acquisition using DHCP only, and stateless autoconfiguration.  When
+   DHCP is used for address configuration, a DHCP server is assumed to
+   be serving one subnet.
+
+7.3.1.  PANA-Assisted Proactive IP Address Acquisition
+
+   In the case of PANA-assisted proactive IP address acquisition, the
+   mobile node obtains an IP address proactively from a CTN.  The mobile
+   node makes use of PANA [RFC5191] messages to trigger the IP address
+   acquisition process via a DHCP client that is co-located with the
+   PANA authentication agent in the access router in the CTN acting on
+   behalf of the mobile node.  Upon receiving a PANA message from the
+   mobile node, the DHCP client on the authentication agent performs
+   normal DHCP message exchanges to obtain the IP address from the DHCP
+   server in the CTN.  This address is piggy-backed in a PANA message
+   and is delivered to the mobile node.  In the case of IPv6, a Router
+   Advertisement (RA) is carried as part of the PANA message.  In the
+   case of stateless autoconfiguration, the mobile node uses the
+   prefix(es) obtained as part of the RA and its MAC address to
+   construct the unique IPv6 address(es) as it would have done in the
+   new network.  In the case of stateful address autoconfiguration, a
+   procedure similar to DHCPv4 can be applied.
+
+7.3.2.  IKEv2-Assisted Proactive IP Address Acquisition
+
+   IKEv2-assisted proactive IP address acquisition works when an IPsec
+   gateway and a DHCP relay agent [RFC3046] are resident within each
+   access router in the CTN.  In this case, the IPsec gateway and DHCP
+   relay agent in a CTN help the mobile node acquire the IP address from
+   the DHCP server in the CTN.  The MN-AR key established during the
+   pre-authentication phase is used as the IKEv2 pre-shared secret
+   needed to run IKEv2 between the mobile node and the access router.
+   The IP address from the CTN is obtained as part of the standard IKEv2
+   procedure, using the co-located DHCP relay agent for obtaining the IP
+   address from the DHCP server in the target network using standard
+   DHCP.  The obtained IP address is sent back to the client in the
+   IKEv2 Configuration Payload exchange.  In this case, IKEv2 is also
+   used as the tunnel management protocol for a proactive handover
+   tunnel (see Section 7.4).  Alternatively, a VPN gateway can dispense
+   the IP address from its IP address pool.
+
+7.3.3.  Proactive IP Address Acquisition Using DHCPv4 Only
+
+   As another alternative, DHCP may be used for proactively obtaining an
+   IP address from a CTN without relying on PANA or IKEv2-based
+   approaches by allowing direct DHCP communication between the mobile
+   node and the DHCP relay agent or DHCP server in the CTN.  The
+
+
+
+Dutta, et al.                 Informational                    [Page 24]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   mechanism described in this section is applicable to DHCPv4 only.
+   The mobile node sends a unicast DHCP message to the DHCP relay agent
+   or DHCP server in the CTN requesting an address, while using the
+   address associated with the current physical interface as the source
+   address of the request.
+
+   When the message is sent to the DHCP relay agent, the DHCP relay
+   agent relays the DHCP messages back and forth between the mobile node
+   and the DHCP server.  In the absence of a DHCP relay agent, the
+   mobile node can also directly communicate with the DHCP server in the
+   target network.  The broadcast option in the client's unicast
+   DISCOVER message should be set to 0 so that the relay agent or the
+   DHCP server can send the reply directly back to the mobile node using
+   the mobile node's source address.
+
+   In order to prevent malicious nodes from obtaining an IP address from
+   the DHCP server, DHCP authentication should be used, or the access
+   router should be configured with a filter to block unicast DHCP
+   messages sent to the remote DHCP server from mobile nodes that are
+   not pre-authenticated.  When DHCP authentication is used, the DHCP
+   authentication key may be derived from the MPA-SA established between
+   the mobile node and the authentication agent in the candidate target
+   network.
+
+   The proactively obtained IP address is not assigned to the mobile
+   node's physical interface until the mobile node has moved to the new
+   network.  The IP address thus obtained proactively from the target
+   network should not be assigned to the physical interface but rather
+   to a virtual interface of the client.  Thus, such a proactively
+   acquired IP address via direct DHCP communication between the mobile
+   node and the DHCP relay agent or the DHCP server in the CTN may be
+   carried with additional information that is used to distinguish it
+   from other addresses as assigned to the physical interface.
+
+   Upon the mobile node's entry to the new network, the mobile node can
+   perform DHCP over the physical interface to the new network to get
+   other configuration parameters, such as the SIP server or DNS server,
+   by using DHCP INFORM.  This should not affect the ongoing
+   communication between the mobile node and Correspondent Host.  Also,
+   the mobile node can perform DHCP over the physical interface to the
+   new network to extend the lease of the address that was proactively
+   obtained before entering the new network.
+
+   In order to maintain the DHCP binding for the mobile node and keep
+   track of the dispensed IP address before and after the secure
+   proactive handover, the same DHCP client identifier needs to be used
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 25]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   for the mobile node for both DHCP for proactive IP address
+   acquisition and for DHCP performed after the mobile node enters the
+   target network.  The DHCP client identifier may be the MAC address of
+   the mobile node or some other identifier.
+
+7.3.4.  Proactive IP Address Acquisition Using Stateless
+        Autoconfiguration
+
+   For IPv6, a network address is configured either using DHCPv6 or
+   stateless autoconfiguration.  In order to obtain the new IP address
+   proactively, the router advertisement of the next-hop router can be
+   sent over the established tunnel, and a new IPv6 address is generated
+   based on the prefix and MAC address of the mobile node.  Generating a
+   CoA from the new network will avoid the time needed to obtain an IP
+   address and perform Duplicate Address Detection.
+
+   Duplicate Address Detection and address resolution are part of the IP
+   address acquisition process.  As part of the proactive configuration,
+   these two processes can be done ahead of time.  Details of how these
+   two processes can be done proactively are described in Appendix A and
+   Appendix B, respectively.
+
+   In the case of stateless autoconfiguration, the mobile node checks to
+   see the prefix of the router advertisement in the new network and
+   matches it with the prefix of the newly assigned IP address.  If
+   these turn out to be the same, then the mobile node does not go
+   through the IP address acquisition phase again.
+
+7.4.  Tunnel Management
+
+   After an IP address is proactively acquired from the DHCP server in a
+   CTN, or via stateless autoconfiguration in the case of IPv6, a
+   proactive handover tunnel is established between the mobile node and
+   the access router in the CTN.  The mobile node uses the acquired IP
+   address as the tunnel's inner address.
+
+   There are several reasons why this transient tunnel is established
+   between the nAR and the mobile node in the old PoA, unlike the
+   transient tunnel in FMIPv6 (Fast MIPv6) [RFC5568], where it is set up
+   between the mobile node's new point of attachment and the old access
+   router.
+
+   In the case of inter-domain handoff, it is important that any
+   signaling message between the nPoA and the mobile node needs to be
+   secured.  This transient secured tunnel provides the desired
+   functionality, including securing the proactive binding update and
+   transient data between the end-points before the handover has taken
+   place.  Unlike the proactive mode of FMIPv6, transient handover
+
+
+
+Dutta, et al.                 Informational                    [Page 26]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   packets are not sent to the pAR, and thus a tunnel between the mobile
+   node's new point of attachment and the old access router is not
+   needed.
+
+   In the case of inter-domain handoff, the pAR and nAR could logically
+   be far from each other.  Thus, the signaling and data during the
+   pre-authentication period will take a longer route, and thus may be
+   subjected to longer one-way delay.  Hence, MPA provides a tradeoff
+   between larger packet loss or larger one-way packet delay for a
+   transient period, when the mobile node is preparing for handoff.
+
+   The proactive handover tunnel is established using a tunnel
+   management protocol.  When IKEv2 is used for proactive IP address
+   acquisition, IKEv2 is also used as the tunnel management protocol.
+   Alternatively, when PANA is used for proactive IP address
+   acquisition, PANA may be used as the secure tunnel management
+   protocol.
+
+   Once the proactive handover tunnel is established between the mobile
+   node and the access router in the candidate target network, the
+   access router also needs to perform proxy address resolution (Proxy
+   ARP) on behalf of the mobile node so that it can capture any packets
+   destined to the mobile node's new address.
+
+   Since the mobile node needs to be able to communicate with the
+   Correspondent Node while in the previous network, some or all parts
+   of the binding update and data from the Correspondent Node to the
+   mobile node need to be sent back to the mobile node over a proactive
+   handover tunnel.  Details of these binding update procedures are
+   described in Section 7.5.
+
+   In order for the traffic to be directed to the mobile node after the
+   mobile node attaches to the target network, the proactive handover
+   tunnel needs to be deleted or disabled.  The tunnel management
+   protocol used for establishing the tunnel is used for this purpose.
+   Alternatively, when PANA is used as the authentication protocol, the
+   tunnel deletion or disabling at the access router can be triggered by
+   means of the PANA update mechanism as soon as the mobile node moves
+   to the target network.  A link-layer trigger ensures that the mobile
+   node is indeed connected to the target network and can also be used
+   as the trigger to delete or disable the tunnel.  A tunnel management
+   protocol also triggers the router advertisement (RA) from the next
+   access router to be sent over the tunnel, as soon as the tunnel
+   creation is complete.
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 27]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+7.5.  Binding Update
+
+   There are several kinds of binding update mechanisms for different
+   mobility management schemes.
+
+   In the case of Mobile IPv4 and Mobile IPv6, the mobile node performs
+   a binding update with the Home Agent only, if route optimization is
+   not used.  Otherwise, the mobile node performs the binding update
+   with both the Home Agent (HA) and Correspondent Node (CN).
+
+   In the case of SIP-based terminal mobility, the mobile node sends a
+   binding update using an INVITE to the Correspondent Node and a
+   REGISTER message to the Registrar.  Based on the distance between the
+   mobile node and the Correspondent Node, the binding update may
+   contribute to the handover delay.  SIP-fast handover [SIPFAST]
+   provides several ways of reducing the handover delay due to binding
+   update.  In the case of secure proactive handover using SIP-based
+   mobility management, we do not encounter the delay due to the binding
+   update at all, as it takes place in the previous network.
+
+   Thus, this proactive binding update scheme looks more attractive when
+   the Correspondent Node is too far from the communicating mobile node.
+   Similarly, in the case of Mobile IPv6, the mobile node sends the
+   newly acquired CoA from the target network as the binding update to
+   the HA and CN.  Also, all signaling messages between the MN and HA
+   and between the MN and CN are passed through this proactive tunnel
+   that is set up.  These messages include Binding Update (BU); Binding
+   Acknowledgement (BA); and the associated return routability messages,
+   such as Home Test Init (HoTI), Home Test (HoT), Care-of Test Init
+   (CoTI), and Care-of Test (CoT).  In Mobile IPv6, since the receipt of
+   an on-link router advertisement is mandatory for the mobile node to
+   detect the movement and trigger the binding update, a router
+   advertisement from the next access router needs to be advertised over
+   the tunnel.  By proper configuration on the nAR, the router
+   advertisement can be sent over the tunnel interface to trigger the
+   proactive binding update.  The mobile node also needs to make the
+   tunnel interface the active interface, so that it can send the
+   binding update using this interface as soon as it receives the router
+   advertisement.
+
+   If the proactive handover tunnel is realized as an IPsec tunnel, it
+   will also protect these signaling messages between the tunnel end-
+   points and will make the return routability test secured as well.
+   Any subsequent data will also be tunneled through, as long as the
+   mobile node is in the previous network.  The accompanying document
+   [MPA-WIRELESS] talks about the details of how binding updates and
+   signaling for return routability are sent over the secured tunnel.
+
+
+
+
+Dutta, et al.                 Informational                    [Page 28]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+7.6.  Preventing Packet Loss
+
+   In the MPA case, packet loss due to IP address acquisition, secured
+   authentication, and binding update does not occur.  However,
+   transient packets during link-layer handover can be lost.  Possible
+   scenarios of packet loss and its prevention are described below.
+
+7.6.1.  Packet Loss Prevention in Single-Interface MPA
+
+   For single-interface MPA, there may be some transient packets during
+   link-layer handover that are directed to the mobile node at the old
+   point of attachment before the mobile node is able to attach to the
+   target network.  Those transient packets can be lost.  Buffering
+   these packets at the access router of the old point of attachment can
+   eliminate packet loss.  Dynamic buffering signals from the MN can
+   temporarily hold transient traffic during handover, and then these
+   packets can be forwarded to the MN once it attaches to the target
+   network.  A detailed analysis of the buffering technique can be found
+   in [PIMRC06].
+
+   An alternative method is to use bicasting.  Bicasting helps to
+   forward the traffic to two destinations at the same time.  However,
+   it does not eliminate packet loss if link-layer handover is not
+   seamlessly performed.  On the other hand, buffering does not reduce
+   packet delay.  While packet delay can be compensated by a playout
+   buffer at the receiver side for a streaming application, a playout
+   buffer does not help much for interactive VoIP applications that
+   cannot tolerate large delay jitters.  Thus, it is still important to
+   optimize the link-layer handover anyway.
+
+7.6.2.  Preventing Packet Losses for Multiple Interfaces
+
+   MPA usage in multi-interface handover scenarios involves preparing
+   the second interface for use via the current active interface.  This
+   preparation involves pre-authentication and provisioning at a target
+   network where the second interface would be the eventual active
+   interface.  For example, during inter-technology handover from a WiFi
+   to a CDMA network, pre-authentication at the CDMA network can be
+   performed via the WiFi interface.  The actual handover occurs when
+   the CDMA interface becomes the active interface for the MN.
+
+   In such scenarios, if handover occurs while both interfaces are
+   active, there is generally no packet loss, since transient packets
+   directed towards the old interface will still reach the MN.  However,
+   if sudden disconnection of the current active interface is used to
+   initiate handover to the prepared interface, then transient packets
+   for the disconnected interface will be lost while the MN attempts to
+   be reachable at the prepared interface.  In such cases, a specialized
+
+
+
+Dutta, et al.                 Informational                    [Page 29]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   form of buffering can be used to eliminate packet loss where packets
+   are merely copied at an access router in the current active network
+   prior to disconnection.  If sudden disconnection does occur, copied
+   packets can be forwarded to the MN once the prepared interface
+   becomes the active reachable interface.  The copy-and-forward
+   mechanism is not limited to multi-interface handover.
+
+   A notable side-effect of this process is the possible duplication of
+   packets during forwarding to the new active interface.  Several
+   approaches can be employed to minimize this effect.  Relying on
+   upper-layer protocols such as TCP to detect and eliminate duplicates
+   is the most common approach.  Customized duplicate detection and
+   handling techniques can also be used.  In general, packet duplication
+   is a well-known issue that can also be handled locally by the MN.
+
+   If the mobile node takes a longer amount of time to detect the
+   disconnection event of the current active interface, this can also
+   have an adverse effect on the length of the handover process.  Thus,
+   it becomes necessary to use an optimized scheme of detecting
+   interface disconnection in such scenarios.  Use of the current
+   interface to perform pre-authentication instead of the new interface
+   is desirable in certain circumstances, such as to save battery power,
+   or in cases where the adjacent cells (e.g., WiFi or CDMA) are
+   non-overlapping, or in cases when the carrier does not allow the
+   simultaneous use of both interfaces.  However, in certain
+   circumstances, depending upon the type of target network, only parts
+   of MPA operations can be performed (e.g., pre-authentication,
+   pre-configuration, or proactive binding update).  In a specific
+   scenario involving handoff between WiFi and CDMA networks, some of
+   the PPP context can be set up during the pre-authentication period,
+   thus reducing the time for PPP activation.
+
+7.6.3.  Reachability Test
+
+   In addition to previous techniques, the MN may also want to ensure
+   reachability of the new point of attachment before switching from the
+   old one.  This can be done by exchanging link-layer management frames
+   with the new point of attachment.  This reachability check should be
+   performed as quickly as possible.  In order to prevent packet loss
+   during this reachability check, transmission of packets over the link
+   between the MN and the old point of attachment should be suspended by
+   buffering the packets at both ends of the link during the
+   reachability check.  How to perform this buffering is out of scope of
+   this document.  Some of the results of using this buffering scheme
+   are explained in the accompanying document [MPA-WIRELESS].
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 30]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+7.7.  Security and Mobility
+
+   This section describes how MPA can help establish layer 2 and layer 3
+   security association in the target networks while the mobile node is
+   in the previous network.
+
+7.7.1.  Link-Layer Security and Mobility
+
+   Using the MPA-SA established between the mobile node and the
+   authentication agent for a CTN, during the pre-authentication phase,
+   it is possible to bootstrap link-layer security in the CTN while the
+   mobile node is in the current network, as described in the following
+   steps.  Figure 5 shows the sequence of operation.
+
+   (1)  The authentication agent and the mobile node derive a PMK (Pair-
+        wise Master Key) [RFC5247] using the MPA-SA that is established
+        as a result of successful pre-authentication.  Successful
+        operation of EAP and a AAA protocol may be involved during
+        pre-authentication to establish the MPA-SA.  From the PMK,
+        distinct TSKs (Transient Session Keys) [RFC5247] for the mobile
+        node are directly or indirectly derived for each point of
+        attachment of the CTN.
+
+   (2)  The authentication agent may install the keys derived from the
+        PMK and used for secure association to points of attachment.
+        The derived keys may be TSKs or intermediary keys from which
+        TSKs are derived.
+
+   (3)  After the mobile node chooses a CTN as the target network and
+        switches to a point of attachment in the target network (which
+        now becomes the new network for the mobile node), it executes a
+        secure association protocol such as the IEEE 802.11i 4-way
+        handshake [802.11], using the PMK in order to establish PTKs
+        (Pair-wise Transient Keys) and group keys [RFC5247] used for
+        protecting link-layer packets between the mobile node and the
+        point of attachment.  No additional execution of EAP
+        authentication is needed here.
+
+   (4)  While the mobile node is roaming in the new network, the mobile
+        node only needs to perform a secure association protocol with
+        its point of attachment, and no additional execution of EAP
+        authentication is needed either.  Integration of MPA with link-
+        layer handover optimization mechanisms such as 802.11r can be
+        archived this way.
+
+   The mobile node may need to know the link-layer identities of the
+   points of attachment in the CTN to derive TSKs.
+
+
+
+
+Dutta, et al.                 Informational                    [Page 31]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+          _________________        ____________________________
+         | Current Network |      |           CTN              |
+         |   ____          |      |                 ____       |
+         |  |    |      (1) pre-authentication     |    |      |
+         |  | MN |<------------------------------->| AA |      |
+         |  |____|         |      |                |____|      |
+         |    .            |      |                  |         |
+         |    .            |      |                  |         |
+         |____.____________|      |                  |         |
+              .movement           |                  |(2) Keys |
+          ____.___________________|                  |         |
+         |   _v__                      _____         |         |
+         |  |    |(3) secure assoc.   |     |        |         |
+         |  | MN |<------------------>| AP1 |<-------+         |
+         |  |____|                    |_____|        |         |
+         |    .                                      |         |
+         |    .movement                              |         |
+         |    .                                      |         |
+         |    .                                      |         |
+         |   _v__                      _____         |         |
+         |  |    |(4) secure assoc.   |     |        |         |
+         |  | MN |<------------------>| AP2 |<-------+         |
+         |  |____|                    |_____|                  |
+         |_____________________________________________________|
+
+                Figure 5: Bootstrapping Link-Layer Security
+
+7.7.2.  IP-Layer Security and Mobility
+
+   IP-layer security is typically maintained between the mobile node and
+   the first-hop router, or any other network element such as SIP proxy
+   by means of IPsec.  This IPsec SA can be set up either in tunnel mode
+   or in ESP mode.  However, as the mobile node moves, the IP address of
+   the router and outbound proxy will change in the new network.  The
+   mobile node's IP address may or may not change, depending upon the
+   mobility protocol being used.  This will warrant re-establishing a
+   new security association between the mobile node and the desired
+   network entity.  In some cases, such as in a 3GPP/3GPP2 IMS/MMD
+   environment, data traffic is not allowed to pass through unless there
+   is an IPsec SA established between the mobile node and outbound
+   proxy.  This will of course add unreasonable delay to the existing
+   real-time communication during a mobile node's movement.  In this
+   scenario, key exchange is done as part of a SIP registration that
+   follows a key exchange procedure called AKA (Authentication and Key
+   Agreement).
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 32]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   MPA can be used to bootstrap this security association as part of
+   pre-authentication via the new outbound proxy.  Prior to the
+   movement, if the mobile node can pre-register via the new outbound
+   proxy in the target network and completes the pre-authentication
+   procedure, then the new SA state between the mobile node and new
+   outbound proxy can be established prior to the movement to the new
+   network.  A similar approach can also be applied if a key exchange
+   mechanism other than AKA is used or the network element with which
+   the security association has to be established is different than an
+   outbound proxy.
+
+   By having the security association established ahead of time, the
+   mobile node does not need to be involved in any exchange to set up
+   the new security association after the movement.  Any further key
+   exchange will be limited to renew the expiry time.  This will reduce
+   the delay for real-time communication as well.
+
+7.8.  Authentication in Initial Network Attachment
+
+   When the mobile node initially attaches to a network, network access
+   authentication would occur regardless of the use of MPA.  The
+   protocol used for network access authentication when MPA is used for
+   handover optimization can be a link-layer network access
+   authentication protocol such as IEEE 802.1X, or a higher-layer
+   network access authentication protocol such as PANA.
+
+8.  Security Considerations
+
+   This document describes a framework for a secure handover
+   optimization mechanism based on performing handover-related signaling
+   between a mobile node and one or more candidate target networks to
+   which the mobile node may move in the future.  This framework
+   involves acquisition of the resources from the CTN as well as data
+   packet redirection from the CTN to the mobile node in the current
+   network before the mobile node physically connects to one of those
+   CTNs.
+
+   Acquisition of the resources from the candidate target networks must
+   be done with appropriate authentication and authorization procedures
+   in order to prevent an unauthorized mobile node from obtaining the
+   resources.  For this reason, it is important for the MPA framework to
+   perform pre-authentication between the mobile node and the candidate
+   target networks.  The MN-CA key and the MN-AR key generated as a
+   result of successful pre-authentication can protect subsequent
+   handover signaling packets and data packets exchanged between the
+   mobile node and the MPA functional elements in the CTNs.
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 33]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   The MPA framework also addresses security issues when the handover is
+   performed across multiple administrative domains.  With MPA, it is
+   possible for handover signaling to be performed based on direct
+   communication between the mobile node and routers or mobility agents
+   in the candidate target networks.  This eliminates the need for a
+   context transfer protocol [RFC5247] for which known limitations exist
+   in terms of security and authorization.  For this reason, the MPA
+   framework does not require trust relationships among administrative
+   domains or access routers, which makes the framework more deployable
+   in the Internet without compromising the security in mobile
+   environments.
+
+9.  Acknowledgments
+
+   We would like to thank Farooq Anjum and Raziq Yaqub for their review
+   of this document, and Subir Das for standardization support in the
+   IEEE 802.21 working group.
+
+   The authors would like to acknowledge Christian Vogt, Rajeev Koodli,
+   Marco Liebsch, Juergen Schoenwaelder, and Charles Perkins for their
+   thorough review of the document and useful feedback.
+
+   Author and Editor Ashutosh Dutta would like to thank Telcordia
+   Technologies, and author Victor Fajardo would like to thank Toshiba
+   America Research and Telcordia Technologies, for supporting the
+   development of their document while they were employed in their
+   respective organizations.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC5944]  Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
+              RFC 5944, November 2010.
+
+   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+              Levkowetz, Ed., "Extensible Authentication Protocol
+              (EAP)", RFC 3748, June 2004.
+
+   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
+              in IPv6", RFC 3775, June 2004.
+
+   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
+              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+              Functional Specification", RFC 2205, September 1997.
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 34]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   [RFC5380]  Soliman, H., Castelluccia, C., El Malki, K., and L.
+              Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
+              Management", RFC 5380, October 2008.
+
+   [RFC5568]  Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568,
+              July 2009.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
+              (MOBIKE)", RFC 4555, June 2006.
+
+   [RFC4881]  El Malki, K., Ed., "Low-Latency Handoffs in Mobile IPv4",
+              RFC 4881, June 2007.
+
+   [RFC4066]  Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D.,
+              and E. Shim, "Candidate Access Router Discovery (CARD)",
+              RFC 4066, July 2005.
+
+   [RFC4067]  Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli,
+              "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
+
+   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
+              Authentication Protocol (EAP) Key Management Framework",
+              RFC 5247, August 2008.
+
+   [RFC5191]  Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
+              and A. Yegin, "Protocol for Carrying Authentication for
+              Network Access (PANA)", RFC 5191, May 2008.
+
+   [RG98]     ITU-T, "General Characteristics of International Telephone
+              Connections and International Telephone Circuits: One-Way
+              Transmission Time", ITU-T Recommendation G.114, 1998.
+
+   [ITU98]    ITU-T, "The E-Model, a computational model for use in
+              transmission planning", ITU-T Recommendation G.107, 1998.
+
+   [ETSI]     ETSI, "Telecommunications and Internet Protocol
+              Harmonization Over Networks (TIPHON) Release 3; End-to-end
+              Quality of Service in TIPHON systems; Part 1: General
+              aspects of Quality of Service (QoS)", ETSI TR 101
+              329-1 V3.1.2, 2002.
+
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 35]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+10.2.  Informative References
+
+   [RFC5201]      Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
+                  Henderson, "Host Identity Protocol", RFC 5201,
+                  April 2008.
+
+   [RFC2679]      Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
+                  Delay Metric for IPPM", RFC 2679, September 1999.
+
+   [RFC2680]      Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
+                  Packet Loss Metric for IPPM", RFC 2680,
+                  September 1999.
+
+   [RFC2681]      Almes, G., Kalidindi, S., and M. Zekauskas, "A
+                  Round-trip Delay Metric for IPPM", RFC 2681,
+                  September 1999.
+
+   [RFC2003]      Perkins, C., "IP Encapsulation within IP", RFC 2003,
+                  October 1996.
+
+   [RFC2608]      Guttman, E., Perkins, C., Veizades, J., and M. Day,
+                  "Service Location Protocol, Version 2", RFC 2608,
+                  June 1999.
+
+   [RFC2473]      Conta, A. and S. Deering, "Generic Packet Tunneling in
+                  IPv6 Specification", RFC 2473, December 1998.
+
+   [RFC3046]      Patrick, M., "DHCP Relay Agent Information Option",
+                  RFC 3046, January 2001.
+
+   [RFC4039]      Park, S., Kim, P., and B. Volz, "Rapid Commit Option
+                  for the Dynamic Host Configuration Protocol version 4
+                  (DHCPv4)", RFC 4039, March 2005.
+
+   [RFC5172]      Varada, S., Ed., "Negotiation for IPv6 Datagram
+                  Compression Using IPv6 Control Protocol", RFC 5172,
+                  March 2008.
+
+   [RFC5648]      Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G.,
+                  Ernst, T., and K. Nagami, "Multiple Care-of Addresses
+                  Registration", RFC 5648, October 2009.
+
+   [RFC4429]      Moore, N., "Optimistic Duplicate Address Detection
+                  (DAD) for IPv6", RFC 4429, April 2006.
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 36]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   [RFC5836]      Ohba, Y., Ed., Wu, Q., Ed., and G. Zorn, Ed.,
+                  "Extensible Authentication Protocol (EAP) Early
+                  Authentication Problem Statement", RFC 5836,
+                  April 2010.
+
+   [RFC5213]      Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
+                  Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
+                  RFC 5213, August 2008.
+
+   [RFC5974]      Manner, J., Karagiannis, G., and A. McDonald, "NSIS
+                  Signaling Layer Protocol (NSLP) for Quality-of-Service
+                  Signaling", RFC 5974, October 2010.
+
+   [RFC5169]      Clancy, T., Nakhjiri, M., Narayanan, V., and L.
+                  Dondeti, "Handover Key Management and
+                  Re-Authentication Problem Statement", RFC 5169,
+                  March 2008.
+
+   [SIPMM]        Schulzrinne, H. and E. Wedlund, "Application-Layer
+                  Mobility Using SIP", ACM MC2R, July 2000.
+
+   [CELLIP]       Campbell, A., Gomez, J., Kim, S., Valko, A., Wan, C.,
+                  and Z. Turanyi, "Design, Implementation, and
+                  Evaluation of Cellular IP", IEEE Personal
+                  Communications, August 2000.
+
+   [MOBIQUIT07]   Lopez, R., Dutta, A., Ohba, Y., Schulzrinne, H., and
+                  A.  Skarmeta, "Network-layer assisted mechanism to
+                  optimize authentication delay during handoff in 802.11
+                  networks", IEEE Mobiquitous, June 2007.
+
+   [MISHRA04]     Mishra, A., Shin, M., Petroni, N., Clancy, T., and W.
+                  Arbaugh, "Proactive key distribution using neighbor
+                  graphs", IEEE Wireless Communications Magazine,
+                  February 2004.
+
+   [SPRINGER07]   Dutta, A., Das, S., Famolari, D., Ohba, Y., Taniuchi,
+                  K., Fajardo, V., Lopez, R., Kodama, T., Schulzrinne,
+                  H., and A. Skarmeta, "Seamless proactive handover
+                  across heterogeneous access networks", Wireless
+                  Personal Communications, November 2007.
+
+   [HAWAII]       Ramjee, R., La Porta, T., Thuel, S., Varadhan, K., and
+                  S.  Wang, "HAWAII: A Domain-based Approach for
+                  Supporting Mobility in Wide-area Wireless networks",
+                  International Conference on Network Protocols ICNP'99.
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 37]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   [IDMP]         Das, S., McAuley, A., Dutta, A., Misra, A.,
+                  Chakraborty, K., and S. Das, "IDMP: An Intra-Domain
+                  Mobility Management Protocol for Next Generation
+                  Wireless Networks", IEEE Wireless Communications
+                  Magazine, October 2000.
+
+   [MOBIP-REG]    Gustafsson, E., Jonsson, A., and C. Perkins, "Mobile
+                  IPv4 Regional Registration", Work in Progress,
+                  June 2004.
+
+   [YOKOTA]       Yokota, H., Idoue, A., Hasegawa, T., and T. Kato,
+                  "Link Layer Assisted Mobile IP Fast Handoff Method
+                  over Wireless LAN Networks", Proceedings of ACM
+                  MobiCom02, 2002.
+
+   [MACD]         Shin, S., Forte, A., Rawat, A., and H. Schulzrinne,
+                  "Reducing MAC Layer Handoff Latency in IEEE 802.11
+                  Wireless LANs", MobiWac Workshop, 2004.
+
+   [SUM]          Dutta, A., Zhang, T., Madhani, S., Taniuchi, K.,
+                  Fujimoto, K., Katsube, Y., Ohba, Y., and H.
+                  Schulzrinne, "Secured Universal Mobility for Wireless
+                  Internet", WMASH'04, October 2004.
+
+   [SIPFAST]      Dutta, A., Madhani, S., Chen, W., Altintas, O., and H.
+                  Schulzrinne, "Fast-handoff Schemes for Application
+                  Layer Mobility Management", PIMRC 2004.
+
+   [PIMRC06]      Dutta, A., Berg, E., Famolari, D., Fajardo, V., Ohba,
+                  Y., Taniuchi, K., Kodama, T., and H. Schulzrinne,
+                  "Dynamic Buffering Control Scheme for Mobile Handoff",
+                  Proceedings of PIMRC 2006, 1-11.
+
+   [MITH]         Gwon, Y., Fu, G., and R. Jain, "Fast Handoffs in
+                  Wireless LAN Networks using Mobile initiated Tunneling
+                  Handoff Protocol for IPv4 (MITHv4)", Wireless
+                  Communications and Networking 2003, January 2005.
+
+   [WENYU]        Jiang, W. and H. Schulzrinne, "Modeling of Packet Loss
+                  and Delay and their Effect on Real-Time Multimedia
+                  Service Quality", NOSSDAV 2000, June 2000.
+
+   [802.21]       "IEEE Standard for Local and Metropolitan Area
+                  Networks: Media Independent Handover Services, IEEE
+                  802.21-2008", a contribution to IEEE 802.21 WG,
+                  January 2009.
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 38]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   [802.11]       "IEEE Wireless LAN Edition A compilation based on IEEE
+                  Std 802.11-1999(R2003)", Institute of Electrical and
+                  Electronics Engineers, September 2003.
+
+   [GPSIP]        Dutta, A., Madhani, S., Chen, W., Altintas, O., and H.
+                  Schulzrinne, "GPS-IP based fast-handoff approaches for
+                  Mobiles", IEEE Sarnoff Symposium 2006.
+
+   [MAGUIRE]      Vatn, J. and G. Maguire, "The effect of using
+                  co-located care-of addresses on macro handover
+                  latency", 14th Nordic Teletraffic Seminar 1998.
+
+   [MPA-MOBIKE]   El Mghazli, Y., Bournelle, J., and J. Laganier, "MPA
+                  using IKEv2 and MOBIKE", Work in Progress, June 2006.
+
+   [MPA-WIRELESS] Dutta, A., Famolari, D., Das, S., Ohba, Y., Fajardo,
+                  V., Taniuchi, K., Lopez, R., and H. Schulzrinne,
+                  "Media- Independent Pre-authentication Supporting
+                  Secure Interdomain Handover Optimization", IEEE
+                  Wireless Communications Magazine, April 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 39]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+Appendix A.  Proactive Duplicate Address Detection
+
+   When the DHCP server dispenses an IP address, it updates its lease
+   table, so that this same address is not given to another client for
+   that specific period of time.  At the same time, the client also
+   keeps a lease table locally so that it can renew when needed.  In
+   some cases where a network consists of both DHCP and non-DHCP-enabled
+   clients, there is a probability that another client in the LAN may
+   have been configured with an IP address from the DHCP address pool.
+   In such a scenario, the server detects a duplicate address based on
+   ARP (Address Resolution Protocol) or IPv6 Neighbor Discovery before
+   assigning the IP address.  This detection procedure may take from 4
+   sec to 15 sec [MAGUIRE] and will thus contribute to a larger handover
+   delay.  In the case of a proactive IP address acquisition process,
+   this detection is performed ahead of time and thus does not affect
+   the handover delay at all.  By performing the Duplicate Address
+   Detection (DAD) ahead of time, we reduce the IP address acquisition
+   time.
+
+   The proactive DAD over the candidate target network should be
+   performed by the nAR on behalf of the mobile node at the time of
+   proactive handover tunnel establishment, since DAD over a tunnel is
+   not always performed.  For example, in the case of IPv6, DAD over an
+   IP-IP tunnel interface is turned off in an existing implementation.
+   In the case of IPv6 over PPP [RFC5172], the IP Control Protocol
+   (IPCPv6) negotiates the link-local addresses, and hence DAD over the
+   tunnel is not needed.  After the mobile node has moved to the target
+   network, a DAD procedure may be started because of reassignment of
+   the nCoA to the physical interface to the target network.  In that
+   case, the mobile node should use optimistic DAD [RFC4429] over the
+   physical interface so that the nCoA that was used inside the
+   proactive handover tunnel before handover can be immediately used
+   over that physical interface after handover.  The schemes used for
+   the proactive DAD and optimistic DAD are applicable to both stateless
+   and stateful address autoconfiguration schemes used for obtaining a
+   nCoA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 40]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+Appendix B.  Address Resolution
+
+   Address resolution involves updating the next access router's
+   neighbor cache.  We briefly describe these two operations below.
+
+   During the process of pre-configuration, the MAC address resolution
+   mappings needed by the mobile node to communicate with nodes in the
+   target network after attaching to the target network can also be
+   known, where the communicating nodes may be the access router,
+   authentication agent, configuration agent, or Correspondent Node.
+   There are several possible ways of performing such proactive MAC
+   address resolution.
+
+   o  One can use an information service mechanism [802.21] to resolve
+      the MAC addresses of the nodes.  This might require each node in
+      the target network to be involved in the information service so
+      that the server of the information service can construct the
+      database for proactive MAC address resolution.
+
+   o  One can extend the authentication protocol used for pre-
+      authentication or the configuration protocol used for
+      pre-configuration to support proactive MAC address resolution.
+      For example, if PANA is used as the authentication protocol for
+      pre-authentication, PANA messages may carry attribute-value pairs
+      (AVPs) used for proactive address resolution.  In this case, the
+      PANA authentication agent in the target network may perform
+      address resolution on behalf of the mobile node.
+
+   o  One can also make use of DNS to map the MAC address of the
+      specific interface associated with a specific IP address of the
+      network element in the target network.  One may define a new DNS
+      resource record (RR) to proactively resolve the MAC addresses of
+      the nodes in the target network.  But this approach may have its
+      own limitations, since a MAC address is a resource that is bound
+      to an IP address, and not directly to a domain name.
+
+   When the mobile node attaches to the target network, it installs the
+   proactively obtained address resolution mappings without necessarily
+   performing address resolution queries for the nodes in the target
+   network.
+
+   On the other hand, the nodes that reside in the target network and
+   that are communicating with the mobile node should also update their
+   address resolution mappings for the mobile node as soon as the mobile
+   node attaches to the target network.  The above proactive address
+   resolution methods could also be used for those nodes to proactively
+   resolve the MAC address of the mobile node before the mobile node
+   attaches to the target network.  However, this is not useful, since
+
+
+
+Dutta, et al.                 Informational                    [Page 41]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   those nodes need to detect the attachment of the mobile node to the
+   target network before adopting the proactively resolved address
+   resolution mapping.  A better approach would be integration of
+   attachment detection and address resolution mapping update.  This is
+   based on gratuitously performing address resolution [RFC5944],
+   [RFC3775] in which the mobile node sends an ARP Request or an ARP
+   Reply in the case of IPv4, or a Neighbor Advertisement in the case of
+   IPv6, immediately after the mobile node attaches to the new network,
+   so that the nodes in the target network can quickly update the
+   address resolution mapping for the mobile node.
+
+Appendix C.  MPA Deployment Issues
+
+   In this section, we describe some of the deployment issues related to
+   MPA.
+
+C.1.  Considerations for Failed Switching and Switch-Back
+
+   The ping-pong effect is one of the common problems found during
+   handover.  The ping-pong effect arises when a mobile node is located
+   at the borderline of the cell or decision point and a handover
+   procedure is frequently executed.  This results in higher call drop
+   probability, lower connection quality, increased signaling traffic,
+   and waste of resources.  All of these affect mobility optimization.
+   Handoff algorithms are the deciding factors for performing the
+   handoff between the networks.  Traditionally, these algorithms employ
+   a threshold to compare the values of different metrics to decide on
+   the handoff.  These metrics include signal strength, path loss,
+   Carrier-to-Interference Ratio (CIR), Signal-to-Interference Ratio
+   (SIR), Bit Error Rate (BER), and power budget.  In order to avoid the
+   ping-pong effect, some additional parameters are employed by the
+   decision algorithm, such as hysteresis margin, dwell timers, and
+   averaging window.  For a vehicle moving at a high speed, other
+   parameters, such as the distance between the mobile node and the
+   point of attachment, velocity of the mobile node, location of the
+   mobile node, traffic, and bandwidth characteristics are also taken
+   into account to reduce the ping-pong effect.  More recently, there
+   are other handoff algorithms available that help reduce the ping-pong
+   effect in a heterogeneous network environment and that are based on
+   techniques such as hypothesis testing, dynamic programming, and
+   pattern recognition techniques.  While it is important to devise
+   smart handoff algorithms to reduce the ping-pong effect, it is also
+   important to devise methods to recover from this effect.
+
+   In the case of the MPA framework, the ping-pong effect will result in
+   the back-and-forth movement of the mobile node between the current
+   network and target network, and between the candidate target
+   networks.  MPA in its current form will be affected because of the
+
+
+
+Dutta, et al.                 Informational                    [Page 42]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   number of tunnels set up between the mobile node and neighboring
+   access routers, the number of binding updates, and associated handoff
+   latency resulting from the ping-pong situation.  The mobile node's
+   handoff rate may also contribute to delay and packet loss.  We
+   propose a few techniques that will help reduce the probability of the
+   ping-pong effect and propose several methods for the MPA framework so
+   that it can recover from the packet loss resulting from the ping-pong
+   effect.
+
+   The MPA framework can take advantage of the mobile node's geo-
+   location with respect to APs in the neighboring networks using GPS.
+   In order to avoid the oscillation between the networks, a location-
+   aware algorithm can be derived by using a co-relation between the
+   user's location and cached data from the previous handover attempts.
+   In some cases, location may not be the only indicator for a handoff
+   decision.  For example, in Manhattan-type grid networks, although a
+   mobile node is close to an AP, it may not have enough SNR (Signal-to-
+   Noise Ratio) to make a good connection.  Thus, knowledge of the
+   mobility pattern, dwell time in a call, and path identification will
+   help avoid the ping-pong problem to a great extent.
+
+   In the absence of a good handoff algorithm that can avoid the ping-
+   pong effect, it may be required to put in place a good recovery
+   mechanism so as to mitigate the effect of ping-pong.  It may be
+   necessary to keep the established context in the current network for
+   a period of time, so that it can be quickly recovered when the mobile
+   node comes back to the network where the context was last used.  This
+   context may include security association, IP address used, and
+   tunnels established.  Bicasting the data to both the previous network
+   and the new network for a predefined period will also help the mobile
+   node to take care of the lost packets in case the mobile node moves
+   back and forth between the networks.  The mobile node can also take
+   certain action, after it determines that it is in a stable state with
+   respect to a ping-pong situation.
+
+   When the MPA framework takes advantage of a combination of IKEv2 and
+   MOBIKE, the ping-pong effect can be reduced further [MPA-MOBIKE].
+
+C.2.  Authentication State Management
+
+   In the case of pre-authentication with multiple target networks, it
+   is useful to maintain the state in the authentication agent of each
+   of the neighboring networks for a certain time period.  Thus, if the
+   mobile node does move back and forth between neighboring networks,
+   already-maintained authentication state can be helpful.  We provide
+   some highlights on multiple security association state management
+   below.
+
+
+
+
+Dutta, et al.                 Informational                    [Page 43]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   A mobile node that has pre-authenticated with an authentication agent
+   in a candidate target network and has an MPA-SA may need to continue
+   to keep the MPA-SA while it continues to stay in the current network
+   or even after it makes a handover to a network that is different from
+   the candidate target network.
+
+   When an MN that has been authenticated and authorized by an
+   authentication agent in the current network makes a handover to a
+   target network, it may want to hold the SA that has been established
+   between the MN and the authentication agent for a certain time period
+   so that it does not have to go through the entire authentication
+   signaling to create an SA from scratch, in case it returns to the
+   previous network.  Such an SA being held at the authentication agent
+   after the MN's handover to another network is considered as an
+   MPA-SA.  In this case, the authentication agent should change the
+   fully authorized state for the MN to an unauthorized state.  The
+   unauthorized state can be changed to the fully authorized state only
+   when the MN comes back to the network and provides proof of
+   possession of a key associated with the MPA-SA.
+
+   While an MPA-SA is being held at an authentication agent, the MN will
+   need to keep updating the authentication agent when an IP address of
+   the MN changes due to a handover, to re-establish the new SA.
+
+C.3.  Pre-Allocation of QoS Resources
+
+   In the pre-configuration phase, it is also possible to pre-allocate
+   QoS resources that may be used by the mobile node not only after
+   handover but also before handover.  When pre-allocated QoS resources
+   are used before handover, they are used for application traffic
+   carried over a proactive handover tunnel.
+
+   It is possible that QoS resources are pre-allocated in an end-to-end
+   fashion.  One method to achieve this proactive end-to-end QoS
+   reservation is to execute the NSIS Signaling Layer Protocol (NSLP)
+   [RFC5974] or the Resource Reservation Protocol (RSVP) [RFC2205] over
+   a proactive handover tunnel where pre-authentication can be used for
+   bootstrapping a security association for the proactive handover
+   tunnel to protect the QoS signaling.  In this case, QoS resources are
+   pre-allocated on the path between the Correspondent Node and a target
+   access router and can be used continuously before and after handover.
+   On the other hand, duplicate pre-allocation of QoS resources between
+   the target access router and the mobile node is necessary when using
+   pre-allocated QoS resources before handover, due to differences in
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 44]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   paths between the target access router and the mobile node before and
+   after handover.  QoS resources to be used for the path between the
+   target access router and the mobile node after handover may be
+   pre-allocated by extending NSLP to work for off-path signaling (Note:
+   this path can be viewed as off-path before handover) or by
+   media-specific QoS signaling at layer 2.
+
+C.4.  Resource Allocation Issue during Pre-Authentication
+
+   In the case of multiple CTNs, establishing multiple tunnels with the
+   neighboring target networks provides some additional benefits.  But
+   it contributes to some resource utilization issues as well.  A
+   pre-authentication process with multiple candidate target networks
+   can happen in several ways.
+
+   The very basic scheme involves authenticating the mobile node with
+   the multiple authentication agents in the neighboring networks, but
+   actual pre-configuration and binding update take place only after
+   layer 2 movement to a specific network is complete.
+
+   Similarly, in addition to pre-authentication, the mobile node can
+   also complete the pre-configuration while in the previous network,
+   but can postpone the binding update until after the mobile node has
+   moved.  Like the previous case, in this case the mobile node also
+   does not need to set up the pre-configured tunnels.  While the pre-
+   authentication process and part of the pre-configuration process are
+   taken care of before the mobile node has moved to the new network,
+   the binding update is actually done after the mobile node has moved.
+
+   The third type of multiple pre-authentication involves all the three
+   steps while the mobile node is in the previous networks, such as
+   authentication, configuration, and binding update.  But, this
+   specific process utilizes the highest amount of resources.  Some of
+   the resources that get used during this process are as follows:
+
+   (1)  Additional signaling for pre-authentication in the neighboring
+        networks
+
+   (2)  Holding the IP address of the neighboring networks in the mobile
+        node's cache for a certain amount of time.  Additional
+        processing in the mobile node is needed for storing these IP
+        addresses.  In addition, this caching of addresses also uses up
+        the temporary IP addresses from the neighboring routers.
+
+   (3)  There is an additional cost associated with setting up
+        additional transient tunnels with the target routers in the
+        neighboring networks and the mobile node.
+
+
+
+
+Dutta, et al.                 Informational                    [Page 45]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   (4)  In the case of a binding update with multiple IP addresses
+        obtained from the neighboring networks, multiple transient
+        streams flow between the CN and mobile node using these
+        transient tunnels.
+
+   However, there are pros and cons related to sending the binding
+   update after the handover.  If the binding update is sent after the
+   mobile node has moved to the new network, this will contribute to the
+   delay if the CH or HA is far from the MN.  Multiple binding updates
+   can be taken care of in many different ways.  We describe a few of
+   these update mechanisms below.
+
+   When only pre-authentication and pre-configuration are done ahead of
+   time with multiple networks, the mobile node sends one binding update
+   to the CN.  In this case, it is important to find out when to send
+   the binding update after the layer 2 handoff.
+
+   In case a binding update with multiple contact addresses is sent,
+   multiple media streams stem out of the CN, using the transient
+   tunnels.  But in that case, one needs to send another binding update
+   after the handover, with the contact address set to the new address
+   (only one address) where the mobile node has moved.  This way, the
+   mobile node stops sending media to other neighboring networks where
+   the mobile node did not move.
+
+   The following is an illustration of this specific case that takes
+   care of multiple binding streams, when the mobile node moves only to
+   a specific network, but sends multiple binding updates in the
+   previous network.  The MN sends a binding update to the CH with
+   multiple contact addresses, such as c1, c2, and c3, that were
+   obtained from three neighboring networks.  This allows the CN to send
+   transient multiple streams to the mobile node over the pre-
+   established tunnels.  After the mobile node moves to the actual
+   network, it sends another binding update to the CN with the care-of
+   address of the mobile node in the network where the mobile node has
+   moved.  One issue with multiple streams is consumption of extra
+   bandwidth for a small period of time.
+
+   Alternatively, one can apply the buffering technique at the target
+   access router or at the Home Agent.  Transient data can be forwarded
+   to the mobile node after it has moved.  Forwarding of data can be
+   triggered by the mobile node either as part of Mobile IP registration
+   or as a separate buffering protocol.
+
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 46]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+C.5.  Systems Evaluation and Performance Results
+
+   In this section, we present some of the results from MPA
+   implementation when applied to different handover scenarios.  We
+   present the summary of results from our experiments using MPA
+   techniques for two types of handovers: i) intra-technology and
+   intra-domain, and ii) inter-technology and inter-domain.  We also
+   present the results of how the MPA can bootstrap layer 2 security for
+   both roaming and non-roaming cases.  Detailed procedures and results
+   are explained in [MOBIQUIT07] and [SPRINGER07].
+
+C.5.1.  Intra-Technology, Intra-Domain
+
+   The results for MIPv6 and SIP mobility involving intra-domain
+   mobility are shown in Figures 6 and 7, respectively.
+
+                         Buffering    Buffering   Buffering   Buffering
+                         (disabled)   (enabled)   (disabled)  (enabled)
+                          & RO         & RO        & RO        & RO
+                         (disabled)   (disabled)  (enabled)   (enabled)
+    -------------------------------------------------------------------
+    L2 handoff (ms)         4.00        4.33        4.00        4.00
+
+    L3 handoff (ms)         1.00        1.00        1.00        1.00
+
+    Avg. packet loss        1.33           0        0.66           0
+
+    Avg. inter-packet      16.00       16.00       16.00       16.00
+    arrival interval
+        (ms)
+
+    Avg. inter-packet       n/a        45.33        n/a        66.60
+    arrival time during
+      handover
+        (ms)
+
+    Avg. packet jitter      n/a        29.33        n/a        50.60
+        (ms)
+
+    Buffering Period        n/a        50.00        n/a        50.00
+        (ms)
+
+    Buffered Packets        n/a         2.00        n/a         3.00
+
+
+   RO = Router Optimization
+
+                  Figure 6: Mobile IPv6 with MPA Results
+
+
+
+Dutta, et al.                 Informational                    [Page 47]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+                                      Buffering      Buffering
+                                      disabled       enabled
+               -----------------------------------------------
+               L2 handoff (ms)           4.00          5.00
+
+               L3 handoff (ms)           1.00          1.00
+
+               Avg. packet loss          1.50             0
+
+               Avg. inter-packet        16.00         16.00
+               arrival interval
+                   (ms)
+
+               Avg. inter-packet         n/a          29.00
+               arrival time during
+                 handover
+                   (ms)
+
+               Avg. packet jitter        n/a          13.00
+                   (ms)
+
+               Buffering Period          n/a          20.00
+                   (ms)
+
+               Buffered Packets          n/a           3.00
+
+                  Figure 7: SIP Mobility with MPA Results
+
+   For all measurements, we did not experience any performance
+   degradation during handover in terms of the audio quality of the
+   voice traffic.
+
+   With the use of buffering during handover, packet loss during the
+   actual L2 and L3 handover is eliminated with appropriate and
+   reasonable settings of the buffering period for both MIP6 and SIP
+   mobility.  In the case of MIP6, there is not a significant difference
+   in results with and without route optimization.  It should be noted
+   that results with more samples would be necessary for a more detailed
+   analysis.
+
+   In the case of non-MPA-assisted handover, handover delay and
+   associated packet loss occur from the moment the link-layer handover
+   procedure begins, up to successful processing of the binding update.
+   During this process, IP address acquisitions via DHCP incur the
+   longest delay.  This is due to the detection of duplicate IP
+   addresses in the network before the DHCP request completes.  The
+   binding update exchange also experiences a long delay if the CN is
+   too far from the MN.  As a result, the non-MPA-assisted handover took
+
+
+
+Dutta, et al.                 Informational                    [Page 48]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   an average of 4 seconds to complete, with an approximate packet loss
+   of about 200 packets.  The measurement is based on the same traffic
+   rate and traffic source as the MPA-assisted handover.
+
+C.5.2.  Inter-Technology, Inter-Domain
+
+   Handoff involving heterogeneous access can take place in many
+   different ways.  We limit the experiment to two interfaces, and
+   therefore results in several possible setup scenarios, depending upon
+   the activity of the second interface.  In one scenario, the second
+   interface comes up when the link to the first interface goes down.
+   This is a reactive scenario and usually gives rise to undesirable
+   packet loss and handoff delay.  In a second scenario, the second
+   interface is being prepared while the mobile node still communicates
+   using the old interface.  Preparation of the second interface should
+   include setup of all the required state and security associations
+   (e.g., PPP state, the Link Control Protocol (LCP), the Challenge
+   Handshake Authentication Protocol (CHAP)).  If such a lengthy process
+   is established ahead of time, it reduces the time taken for the
+   secondary interface to be attached to the network.  After
+   preparation, the mobile node decides to use the second interface as
+   the active interface.  This results in less packet loss, as it uses
+   make-before-break techniques.  This is a proactive scenario and can
+   have two "flavors".  The first is where both interfaces are up; the
+   second is when only the old interface is up and the prepared
+   interface is brought up only when handoff is about to occur.  This
+   scenario may be beneficial from a battery management standpoint.
+   Devices that operate two interfaces simultaneously can rapidly
+   deplete their batteries.  However, by activating the second interface
+   only after an appropriate network has been selected, the client may
+   utilize battery power effectively.
+
+   As compared to non-optimized handover that may result in a delay of
+   up to 18 sec and loss of 1000 or more packets during the handover
+   from the wireless LAN (WLAN) to CDMA, we observed 0 packet loss and a
+   50-ms handoff delay between the last pre-handoff packet and the first
+   in-handoff packet.  This handoff delay includes the time due to link
+   down detection and time needed to delete the tunnel after the mobile
+   node has moved.  However, we observed about 10 duplicate packets
+   because of the copy-and-forward mechanism at the access routers.  But
+   these duplicate packets are usually handled easily by the upper-layer
+   protocols.
+
+C.5.3.  MPA-Assisted Layer 2 Pre-Authentication
+
+   In this section, we discuss the results obtained from MPA-assisted
+   layer 2 pre-authentication and compare these with EAP authentication
+   and IEEE 802.11i's pre-authentication techniques.  Figure 8 shows the
+
+
+
+Dutta, et al.                 Informational                    [Page 49]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   experimental testbed where we have conducted the MPA-assisted
+   pre-authentication experiment for bootstrapping layer 2 security as
+   explained in Section 7.  By pre-authenticating and pre-configuring
+   the link, the security association procedure during handoff reduces
+   to a 4-way handshake only.  Then the MN moves to the AP and, after
+   association, runs a 4-way handshake by using the PSKap (Pre-shared
+   Key at AP) generated during PANA pre-authentication.  At this point,
+   the handoff is complete.  Details of this experimental testbed can be
+   found in [MOBIQUIT07].
+
+   +----------------------------+-----------+ +-------------+----------+
+   |                                        | |                        |
+   |  Home Domain       +-------++          | |                        |
+   |                    |        |          | |                        |
+   |                    |AAAHome |          | |                        |
+   |                    +        |          | |                        |
+   |                    +-----+--+          | |                        |
+   |                          |             | |  Network B             |
+   |   Network A              |             | |                        |
+   |                        /----\          | |            /---\       |
+   |                       /nAR   \         | |           /     \      |
+   |                      | PAA    |--------+-+----------+ pAR   |     |
+   |                       \      /         | |           \     /      |
+   |                        \----/          | |            \-+-/       |
+   |                           |            | |              |         |
+   |             +-------------------|      | |              |         |
+   |             |       IEEE 802.11i|      | |              |         |
+   |           +------+          +------+   | |          +---+--+      |
+   |           |      |          |      |   | |          |      |      |
+   |           |AP2   |          |AP1   |   | |          |AP0   |      |
+   |           +------+          +------+   | |          +------+      |
+   |           +------+            +-----+  | |           +-----+      |
+   |           |      |            |     |  | |           |     |      |
+   |           |MN    +----------->|MN   |<+------------- |MN   |      |
+   |           +------+            +-----+  | |           ++----+      |
+   |----------------------------------------+ +------------+-----------+
+
+              Figure 8: Experimental Testbed for MPA-Assisted
+                    L2 Pre-Authentication (Non-Roaming)
+
+
+
+
+
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 50]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+                        +-----------------------------+
+                        |      +--------+             |
+                        |      |        |             |
+                        |      | AAAH   +             |
+                        |      |        |             |
+                        |      ++-------+             |
+                        |       |                     |
+                        |       |  Home AAA Domain    |
+                        |       |                     |
+                        +-------+---------------------+
+                                |
+                                |
+                                |
+                       RADIUS/  |
+                       Diameter |
+                                |
+                                |
+   +----------------------------+-----------+ +-------------+----------+
+   |                            |           | |                        |
+   | Roaming            +-------++          | |                        |
+   | AAA Domain A       |        |          | |                        |
+   |                    | AAAV   |          | |                        |
+   |                    +        |          | |                        |
+   | Network A          +-----+--+          | |  Network B             |
+   |                          |             | |                        |
+   |                          |             | |                        |
+   |                        /----\          | |            /---\       |
+   |                       /nAR   \         | |           /     \      |
+   |                      | PAA    |--------+-+----------+ pAR   |     |
+   |                       \      /         | |           \     /      |
+   |                        \----/          | |            \-+-/       |
+   |                           |            | |              |         |
+   |             +-------------------|      | |              |         |
+   |             |       IEEE 802.11i|      | |              |         |
+   |           +------+          +------+   | |          +---+--+      |
+   |           |      |          |      |   | |          |      |      |
+   |           |AP2   |          |AP1   |   | |          |AP0   |      |
+   |           +------+          +------+   | |          +------+      |
+   |           +------+            +-----+  | |           +-----+      |
+   |           |      |            |     |  | |           |     |      |
+   |           |MN    +----------->|MN   |<---------------| MN  |      |
+   |           +------+            +-----+  | |           ++----+      |
+   -----------------------------------------+ +------------+-----------+
+
+              Figure 9: Experimental Testbed for MPA-Assisted
+                      L2 Pre-Authentication (Roaming)
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 51]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   We have experimented with three types of movement scenarios involving
+   both non-roaming and roaming cases, using the testbeds shown in
+   Figures 8 and 9, respectively.  In the roaming case, the MN is
+   visiting in a domain different than its home domain.  Consequently,
+   the MN needs to contact the AAA server in the home domain (AAAH) from
+   its new domain.  For the non-roaming case, we assume the MN is moving
+   within its home domain, and only the local AAA server (AAAHome),
+   which is the home AAA server for the mobile node, is contacted.
+
+   The first scenario does not involve any pre-authentication.  The MN
+   is initially connected to AP0 and moves to AP1.  Because neither
+   network-layer authentication nor IEEE 802.11i pre-authentication is
+   used, the MN needs to engage in a full EAP authentication with AP1 to
+   gain access to the network after the move (post-authentication).
+   This experiment shows the effect of the absence of any kind of
+   pre-authentication.
+
+   The second scenario involves 802.11i pre-authentication and involves
+   movement between AP1 and AP2.  In this scenario, the MN is initially
+   connected to AP2, and starts IEEE 802.11i pre-authentication with
+   AP1.  This is an ideal scenario to compare the values obtained from
+   802.11i pre-authentication with that of network-layer assisted
+   pre-authentication.  Both scenarios use RADIUS as the AAA protocol
+   (APs implement a RADIUS client).  The third scenario takes advantage
+   of network-layer assisted link-layer pre-authentication.  It involves
+   movement between two APs (e.g., between AP0 and AP1) that belong to
+   two different subnets where 802.11i pre-authentication is not
+   possible.  Here, Diameter is used as the AAA protocol (PAA implements
+   a Diameter client).
+
+   In the third movement scenario, the MN is initially connected to AP0.
+   The MN starts PANA pre-authentication with the PAA, which is
+   co-located on the AR in the new candidate target network (nAR in
+   network A) from the current associated network (network B).  After
+   authentication, the PAA proactively installs two keys, PSKap1 and
+   PSKap2, in AP1 and AP2, respectively.  By doing the key installations
+   proactively, the PAA preempts the process of communicating with the
+   AAA server for the keys after the mobile node moves to the new
+   network.  Finally, because PSKap1 is already installed, AP1
+   immediately starts the 4-way handshake.  We have used measurement
+   tools such as ethereal and kismet to analyze the measurements for the
+   4-way handshake and PANA authentication.  These measurements reflect
+   different operations involved during network-layer pre-
+   authentication.
+
+   In our experiment, as part of the discovery phase, we assume that the
+   MN is able to retrieve the PAA's IP address and all required
+   information about AP1 and AP2 (e.g., channel, security-related
+
+
+
+Dutta, et al.                 Informational                    [Page 52]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   parameters, etc.) at some point before the handover.  This avoids the
+   scanning during link-layer handoff.  We have applied this assumption
+   to all three scenarios.  Because our focus is on reducing the time
+   spent on the authentication phase during handoff, we do not discuss
+   the details of how we avoid the scanning.
+
+   =====================================================================
+   Types    |802.11i            | 802.11i           | MPA-assisted
+            |Post-              | Pre-              | Layer 2
+            |authentication     | authentication    | Pre-authentication
+   =====================================================================
+   Operation| Non-    | Roaming | Non-    | Roaming |Non-   | Roaming|
+            | Roaming |         | Roaming |         |Roaming|        |
+   ===================================================================
+   Tauth    | 61 ms   |  599 ms | 99 ms   | 638 ms  | 177 ms| 831 ms |
+   -------------------------------------------------------------------
+   Tconf    | --      |  --     | --      | --      | 16 ms | 17ms   |
+   -------------------------------------------------------------------
+   Tassoc+  |         |         |         |         |       |        |
+   4way     | 18 ms   |  17 ms  | 16 ms   | 17 ms   | 16 ms | 17 ms  |
+   ------------------------------------------------------------------|
+   Total    | 79 ms   |  616 ms | 115 ms  | 655 ms  | 208 ms| 865 ms |
+   ------------------------------------------------------------------|
+   Time     |         |         |         |         |       |        |
+   affecting| 79 ms   |  616 ms | 16 ms   | 17 ms   | 15 ms | 17 ms  |
+   handover |         |         |         |         |       |        |
+   ------------------------------------------------------------------|
+
+                Figure 10: Results of MPA-Assisted Layer 2
+                       Pre- and Post-Authentication
+
+   Figure 10 shows the timing (rounded off to the most significant
+   number) associated with some of the handoff operations we have
+   measured in the testbed.  We describe each of the timing parameters
+   below.
+
+   "Tauth" refers to the execution of EAP-Transport Layer Security (TLS)
+   authentication.  This time does not distinguish whether this
+   authentication was performed during pre-authentication or a typical
+   post-authentication.
+
+   "Tconf" refers to the time spent during PSK generation and
+   installation after EAP authentication is complete.  When network-
+   layer pre-authentication is not used, this time is not considered.
+
+   "Tassoc+4way" refers to the time dedicated to the completion of the
+   association and the 4-way handshake with the target AP after the
+   handoff.
+
+
+
+Dutta, et al.                 Informational                    [Page 53]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   The first two columns in the figure show the results for non-roaming
+   and roaming cases, respectively, when no pre-authentication is used
+   at all.  The second two columns depict the same cases when IEEE
+   802.11i pre-authentication is used.  The last two columns show when
+   we used network-layer-assisted layer 2 pre-authentication.  When pre-
+   authentication is used, only the factor Tassoc+4way affects the
+   handoff time.  When no pre-authentication is used, the time affecting
+   the handoff includes Tauth (the complete EAP-TLS authentication) plus
+   Tassoc+4way.
+
+   That is precisely the time affecting the handoff in the case where
+   the MN moves from AP0 to AP1 in the absence of pre-authentication.
+   As it is seen, these delays are not suitable for real-time
+   applications.  Indeed, for the non-roaming case, we obtained a ~80-ms
+   delay for re-establishing the connection with target AP1.  It takes
+   about 600 ms to complete the handoff when the MN moves to a visited
+   domain and the home AAA server is located far away.  However,
+   network-layer pre-authentication is only affected by Tassoc+4way
+   (~17 ms) involving any kind of handoff authentication.  As is
+   evident, IEEE 802.11i pre-authentication provides a comparable
+   benefit (~16 ms) in terms of handoff but is limited to cases when APs
+   are in the same Distribution System (DS).  Additionally, network-
+   layer pre-authentication leverages a single EAP authentication to
+   bootstrap security in several target APs by allowing the MN to move
+   among APs under the same PAA without running EAP and consequently
+   without contacting the AAA server.  In this sense, it extends IEEE
+   802.11r advantages over IEEE 802.11i by allowing inter-subnet and
+   inter-domain and even inter-technology handoffs.
+
+C.6.  Guidelines for Handover Preparation
+
+   In this section, we provide some guidelines for the roaming clients
+   that use pre-authentication mechanisms to reduce the handoff delay.
+   These guidelines can help determine the extent of the
+   pre-authentication operation that is needed based on a specific type
+   of movement of the client.  IEEE 802.11i and 802.11r take advantage
+   of the pre-authentication mechanism at layer 2.  Thus, many of the
+   guidelines observed for 802.11i-based pre-authentication and 802.11r-
+   based fast roaming could also be applicable to the clients that use
+   MPA-based pre-authentication techniques.  However, since MPA
+   operations are not limited to a specific subnet and involve inter-
+   subnet and inter-domain handover, the guidelines need to take into
+   account other factors, such as movement pattern of the mobile node,
+   cell size, etc.
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 54]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   The time needed to complete the pre-authentication mechanism is an
+   important parameter, since the mobile node needs to determine how
+   much ahead of time the mobile node needs to start the
+   pre-authentication process so that it can finish the desired
+   operations before the handover to the target network starts.  The
+   pre-authentication time will vary, depending upon the speed of the
+   mobile node (e.g., pedestrian vs. vehicular) and cell sizes (e.g.,
+   WiFi, Cellular).  Cell residence time is defined as the average time
+   the mobile node stays in the cell before the next handoff takes
+   place.  Cell residence time is dependent upon the coverage area and
+   velocity of the mobile node.  Thus, cell residence time is an
+   important factor in determining the desirable pre-authentication time
+   that a mobile node should consider.
+
+   Since the pre-authentication operation involves six steps as
+   described in Section 6.3 and each step takes some discrete amount of
+   time, only part of these sub-operations may be completed before
+   handoff, depending upon the available delay budget.
+
+   For example, a mobile node could complete only network discovery and
+   the network-layer authentication process before the handoff and
+   postpone the rest of the operations until after the handover is
+   complete.  On the other hand, if it is a slow-moving vehicle and the
+   adjacent cells are sparsely spaced, a mobile node could complete all
+   the desired MPA-related operations.  Finishing all the MPA-related
+   operations ahead of time reduces the handoff delay but adds other
+   constraints, such as cell residence time.
+
+   We give a numerical example here, similar to [MISHRA04].
+
+      D = Coverage diameter
+
+      v = Mobile node's velocity
+
+      RTT = round trip time from AP to AAA server, including processing
+      time for authentication (Tauth)
+
+      Tpsk = Time spent to install keys proactively on the target APs
+
+   If for a given value of D = 100 ft, Tpsk = 10 ms, and RTT = 100 ms, a
+   mobile node needs to execute only the pre-authentication procedure
+   associated with MPA, then the following can be calculated for a
+   successful MPA procedure before the handoff is complete.
+
+      2RTT + Tpsk < D/v
+
+      v = 100 ft/(200 ms + 10 ms) = ~500 ft/sec
+
+
+
+
+Dutta, et al.                 Informational                    [Page 55]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+   Similarly, for a similar cell size, if the mobile node is involved in
+   both pre-authentication and pre-configuration operations as part of
+   the MPA procedure, and it takes an amount of time Tconf = 190 ms to
+   complete the layer 3 configuration including IP address
+   configuration, then for a successful MPA operation,
+
+      2RTT + Tpsk + Tconf < D/v
+
+      v = 100 ft/(200 ms + 10 ms + 190 ms) = ~250 ft/sec
+
+   Thus, compared to only the pre-authentication part of the MPA
+   operation, in order to be able to complete both pre-authentication
+   and pre-configuration operations successfully, either the mobile node
+   needs to move at a slower pace or it needs to expedite these
+   operations for this given cell size.  Thus, types of MPA operations
+   will be constrained by the velocity of the mobile node.
+
+   As an alternative, if a mobile node does complete all of the
+   pre-authentication procedure well ahead of time, it uses up the
+   resources accordingly by way of an extra IP address, tunnel, and
+   extra bandwidth.  Thus, there is always a tradeoff between the
+   performance benefit obtained from the pre-authentication mechanism
+   and network characteristics, such as movement speed, cell size, and
+   resources utilized.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dutta, et al.                 Informational                    [Page 56]
+
+RFC 6252                      MPA Framework                    June 2011
+
+
+Authors' Addresses
+
+   Ashutosh Dutta (editor)
+   NIKSUN
+   100 Nassau Park Blvd.
+   Princeton, NJ  08540
+   USA
+
+   EMail: ashutosh.dutta@ieee.org
+
+
+   Victor Fajardo
+   NIKSUN
+   100 Nassau Park Blvd.
+   Princeton, NJ  08540
+   USA
+
+   EMail: vf0213@gmail.com
+
+
+   Yoshihiro Ohba
+   Corporate R&D Center, Toshiba Corporation
+   1 Komukai-Toshiba-cho, Saiwai-ku
+   Kawasaki, Kanagawa  212-0001
+   Japan
+
+   EMail: yoshihiro.ohba@toshiba.co.jp
+
+
+   Kenichi Taniuchi
+   Toshiba Corporation
+   2-9 Suehiro-cho
+   Ome, Tokyo  198-8710
+   Japan
+
+   EMail: kenichi.taniuchi@toshiba.co.jp
+
+
+   Henning Schulzrinne
+   Columbia University
+   Department of Computer Science
+   450 Computer Science Building
+   New York, NY  10027
+   USA
+
+   Phone: +1 212 939 7004
+   EMail: hgs@cs.columbia.edu
+
+
+
+
+Dutta, et al.                 Informational                    [Page 57]
+