RFC 6252
A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization
A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization 🦋
Part 1 of 15! 🎀 Okay bestie, this RFC is from the IRTF (Internet Research Task Force), so it's a research doc, not a standards-track spec. It's Category: Informational ✨ and it came out in June 2011. The ISSN is 2070-1721. 💅
Who Wrote This 👑
- A. Dutta, Ed. (editor), from NIKSUN
- V. Fajardo, also NIKSUN
- Y. Ohba, from Toshiba
- K. Taniuchi, also Toshiba
- H. Schulzrinne, from Columbia Univ.
The title block has no Obsoletes or Updates entries, so this one doesn't replace or change any older RFC. 🌸
Abstract 🔥
This doc is all about MPA (Media-independent Pre-Authentication), a brand-new handover optimization mechanism. It's built to fix the problems that existing mobility management protocols and mobility optimization mechanisms have when a device switches between domains (inter-domain handover). 😭
MPA is mobile-assisted and secure 🔐, and it works over any link layer and with any mobility management protocol. It's most useful when you're handing over between domains. Its big moves are pre-authentication, pre-configuration, and proactive handover. Those let a lot of the handoff stuff happen before the mobile node has actually moved to the new network. Main character energy, honestly. 🧚
The doc walks through every technique and where each one fits in different scenarios with various mobility protocols during inter-domain handover. The team also implemented MPA for several network-layer and application-layer mobility protocols, and they share a summary of the experimental performance results. 📊
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's published just for information. 🧸
It's a product of the Internet Research Task Force (IRTF), which publishes results from Internet-related research and development. Those results might not be suitable for deployment, so don't just yolo them into production. 🙈 This RFC reflects the consensus of the MOBOPTS Research Group of the IRTF. Documents that the IRSG approves for publication are not candidates for any level of Internet Standard. See Section 2 of RFC 5741 for the details. 📚
For the current status, any errata, and how to give feedback, check out 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) as they stand on the date this document was published. Please actually read these, bestie, because they explain your rights and restrictions for 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
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 ........................541. Introduction ✨
okay bestie, let's get into it 🧚 wireless is EVERYWHERE now, cellular and wifi LANs both, and switching a device between different kinds of access networks, like from wifi over to CDMA or GPRS, is considered a clear challenge 😭 switching between access networks of the same type is honestly even harder, especially when you're crossing IP subnets or administrative domains 💀 so the goal is terminal mobility that doesn't care what link layer you're on, done in an optimized and secure way without the complexity getting out of hand 🫶 this doc is all about a framework for mobility that gives you seamless handovers with low latency and low loss 🦋 what "seamless" actually means in terms of performance is spelled out in Section 1.2. [MPA-WIRELESS] is the accompanying doc that shows how a few MPA-based systems get built, with performance results showing how existing protocols could be used to pull off MPA functionality 🌈
okay so here's the core idea 💜 terminal mobility is handled by a mobility management protocol that keeps a binding between a locator and an identifier of a mobile node, and that binding is called the mobility binding. the locator can change whenever the mobile node moves, and "moves" can mean physically walking somewhere or the network changing under it, which changes its attachment point 🎀 a mobility management protocol could be defined at any layer, but for the rest of this doc, "mobility management protocol" means one that operates at the network layer or higher ✨
there are a bunch of these already, just at different layers 🍓 Mobile IP [RFC5944] and Mobile IPv6 [RFC3775] both work at the network layer. MOBIKE (IKEv2 Mobility and Multihoming) [RFC4555] is an extension to IKEv2 that lets an IKEv2 end-point handle a change of its IP address, which is so cute 🙈 the IETF is also cooking up mobility protocols above the network layer: HIP (Host Identity Protocol) [RFC5201] adds a new protocol layer between network and transport so mobility is transparent to both, and SIP-based mobility [SIPMM] extends SIP to keep the mobility binding of a SIP user agent 💅
here's the tea though 😤 mobility management protocols keep the bindings, but they can't give you seamless handover in their current form. you need an extra optimization mechanism to stop in-flight packets from getting lost during the mobile node's binding update procedure. that's a mobility optimization mechanism 🔥 for example, Mobile IPv4 [RFC4881] and Mobile IPv6 [RFC5568] have mobility optimization mechanisms that let neighboring access routers talk to each other and share info about mobile terminals 👑 there are also "helpers": CARD (Candidate Access Router Discovery) [RFC4066] finds neighboring access routers, and CXTP (Context Transfer Protocol) [RFC4067] carries the state tied to the services for the mobile node (aka its context) between access routers 🧚 Section 4 walks through some fast-handover schemes that try to cut down handover delay 🌸
okay now the issues, and they're kind of a lot 😭 first, existing mobility optimization mechanisms are tightly coupled to specific mobility management protocols. like, you can't just use the Mobile IPv4 or Mobile IPv6 ones with MOBIKE. what everyone actually wants is one unified mobility optimization mechanism that works with any mobility management protocol 💖 second, there isn't an existing one that easily handles handovers across administrative domains without assuming a pre-established security association between those domains 💀 third, it needs to work for terminals with multiple interfaces (where you can have simultaneous connectivity, or connectivity through a single interface) AND for terminals with just one interface 🫠
so this doc describes Media-independent Pre-Authentication (MPA), a brand new handover optimization mechanism that fixes all three of those 🎀 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 🦋 when you've got multiple operators with no roaming relationship and no agreement to join a key management scheme, MPA gives you a framework to do pre-authentication and set up security mechanisms without needing a common source of trust 🫶 MPA takes the idea of IEEE 802.11i pre-authentication and pushes it up to a higher layer, adding ways to get an early IP address from a network the mobile node might move to, plus proactive handover to that network while the mobile node is still on its current one 👑 this doc only covers the MPA framework, so picking the actual protocols for MPA and defining detailed operations is left for future work 🔥 the accompanying doc [MPA-WIRELESS] shows one method that uses existing protocols together to get MPA working 🌈
this doc represents the consensus of the IP Mobility Optimizations (MOBOPTS) Research Group, and Research Group members who are active in this specific area reviewed it ✨
1.1. Specification of Requirements
okay, the vibe here is "read these words very carefully" 🧐 in this document, a bunch of words signal the requirements of the spec, and they're 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
okay bestie, this is where the numbers come in 📊 to get good quality of service for interactive Voice over IP (VoIP) and streaming traffic, you need to keep end-to-end delay, jitter, and packet loss under certain threshold levels 💜 ITU-T and ITU-E standards define what's acceptable for these. for one-way delay, ITU-T G.114 [RG98] recommends 150 ms as the upper limit for most applications, and 400 ms is generally unacceptable 😭 one-way delay tolerance for video conferencing is roughly 200 to 300 ms [ITU98] 🎀 also, if an out-of-order packet shows up after a certain threshold, it counts as lost 🙈 according to ETSI TR 101 [ETSI], a normal voice conversation can tolerate up to 2% packet loss 🍓 but that's the mean packet loss probability, and it may only be applicable when the mobile node gets handed off over and over during a normal conversation 🫠 measurement techniques for delay and jitter are described in [RFC2679], [RFC2680], and [RFC2681] ✨
okay so with interactive VoIP, end-to-end delay affects jitter, which is why it matters so much 🦋 end-to-end delay is made of several pieces: network delay, operating system (OS) delay, codec delay, and application delay. there's a full breakdown in [WENYU] 💖 during a handover, in-flight transient traffic can't reach the mobile node because of the handover delay 😤 those in-flight packets either get lost or get buffered. if they're lost, that loss adds to jitter between the last packet before the handoff and the first packet after it 💀 if they're buffered, packet loss goes down, but the in-flight packets get extra jitter when they're flushed after the handoff 🌈 buffering avoids the loss but costs additional one-way delay 👑 so you have to trade off one-way delay against packet loss depending on the application 🧚 for streaming, for example, you can reduce packet loss by making the playout buffer bigger, which means longer one-way packet delay 🌸
the handover delay comes from a bunch of things: discovery, configuration, authentication, binding update, and media delivery 🫶 a lot of the security procedures, like handover keying and re-authentication, assume there's a single source of trust at the top, and the underlying AAA (Authentication, Authorization, and Accounting) domain elements trust that top source and the keys it generates and distributes 🔥 in that setup, re-establishing link-security parameters like authentication, link key management, and access authorization during inter-domain handover takes an appreciable amount of time ⏳ so this doc focuses on a framework that cuts down the delay from authentication and other handoff-related operations, like configuration and binding update 💜
2. Terminology
okay here are the definitions you'll need 📖✨
- 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 ✨
okay so bestie, handovers come in a few flavors 🍓 depending on the type of movement, the type of access network, and the mobility support involved. you can basically sort them into four buckets: inter-technology, intra-technology, inter-domain, and intra-domain. we'll go through each one briefly, but ngl our main focus is inter-domain handover 💅
- Inter-technology: okay this one is iconic 🦋 a mobile node can have multiple interfaces, and each interface can support a different access technology (like 802.11 or CDMA). to conserve power, it only communicates through one interface at any time 🔋. so when the mobile node moves out of the footprint of one access technology (like 802.11) and into the footprint of a different one (like CDMA), it also has to switch which interface is doing the communicating. people often call this type of inter-technology handover "vertical handover", since the mobile node is moving between two different cell sizes 🌈
- Intra-technology: this is when a mobile node moves around within the same type of access technology, like between 802.11[a,b,n] and 802.11 [a,b,n], or between CDMA1XRTT and CDMA1EVDO 🎀 in this case the mobile node might have just one interface (with multiple PHY types of the same technology) or it might have several interfaces. an intra-technology handover can involve intra-subnet or inter-subnet movement, so depending on the kind of movement, it may or may not need to change its L3 locator 🧚
- Inter-domain: a domain can be defined in a bunch of ways, but for roaming purposes we define "domain" as an administrative domain 👑 made up of networks managed by a single administrative entity, which authenticates and authorizes a mobile node for accessing those networks. that entity can be a service provider, an enterprise, or literally any organization 🫶 so an inter-domain handover is going to be subjected to inter-subnet handover by default, and on top of that it may also be subjected to inter-technology or intra-technology handover. a mobile node goes through inter-subnet handover when it moves from one subnet (broadcast domain) to another subnet (broadcast domain). inter-domain handover goes through all the transition steps a subnet handover does, and it also goes through the authentication and authorization processes 🔐 plus, each administrative domain is likely to have a different type of mobility support. for example, administrative domain A might have Mobile IP version 6 (MIPv6) support, while administrative domain B uses Proxy MIPv6 [RFC5213] 💜
- Intra-domain: when a mobile node's movement is confined to movement within one administrative domain, it's called "intra-domain movement" 🌸 this can involve intra-subnet, inter-subnet, intra-technology, and inter-technology movement too.
okay so here's the vibe: both inter-domain and intra-domain handovers can be subjected to either inter-technology or intra-technology handover, depending on the network access characteristics 🦋 but inter-domain handover is where things get spicy. it requires authorization for acquisition or modification of resources assigned to a mobile node, and that authorization needs to interact with a central authority in a domain 😭 in lots of cases, the authorization procedure follows an authentication procedure, which also needs to interact with a central authority in a domain. that means security associations between network entities (like routers in the neighboring administrative domains) need to be established before any interaction happens between them 🔥 not me being dramatic, this is literally the foundation 💀
and it gets more complicated, because inter-domain mobility can involve different mobility protocols in each domain, like MIPv6 in one and Proxy MIPv6 in another 🙈 so you need a generalized framework to get the optimization during inter-domain handover ✨ the same optimization technique might not work for inter-domain handover even if it works fine within a domain, whether or not both domains use the same mobility protocol. any mobile node can be using a specific mobility protocol and its associated optimization technique during intra-domain movement in either domain, but that doesn't mean the same setup will carry over 🧚♀️
Figure 1 shows a typical example of inter-domain mobility with two domains, domain A and domain B 🗺️ it shows several important components, including an AAA Home server (AAAH), AAA visited servers (like AAAV1 and AAAV2), an Authentication Agent (AA), a layer 3 point of attachment (like an Access Router (AR)), and a layer 2 point of attachment (like an Access Point (AP)) 💖
+-----------------------------+
| +--------+ |
| | | |
| | 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 Mobility4. Related Work ✨
okay so before MPA shows up, we need to talk about everything that came before it, bestie 🧚💅 basic mobility stuff like Mobile IP [RFC5944], Mobile IPv6 [RFC3775], and SIP-Mobility [SIPMM] does keep TCP and RTP traffic going, which is iconic, BUT none of them were built to shrink the handover latency when a mobile node moves between subnets and domains 😭 the delays stack up at several layers, like layer 3 and the application layer, just to update the mobile node's mobility binding, and the layer 2 delay underneath makes it worse. so applications on these protocols end up with real performance degradation. not it 💀
there have been a bunch of optimization techniques that bolt onto current mobility schemes to cut down handover delay and packet loss while a mobile node moves between cells, subnets, and domains 🌸 micro-mobility schemes like [CELLIP] and [HAWAII], and intra-domain schemes like [IDMP], [MOBIP-REG], and [RFC5380], give you fast handover by keeping signaling updates inside a domain, which is very main character energy. Fast Mobile IP protocols for IPv4 and IPv6 networks [RFC4881] [RFC5568] use mobility info that comes from link-layer triggers 🔥 Yokota et al. [YOKOTA] suggest pairing an access point with a dedicated Media Access Control (MAC) bridge to get fast handover without changing the MIPv4 spec, which is so clever. Shin et al. [MACD] came up with a cache-based algorithm that cuts the delay from MAC-layer handoff. the mobile node caches the neighboring channels it has already visited, so it can use a selective scanning method, and that helps shrink the scanning time 🦋
some mobility schemes use dual interfaces, which gives you make-before-break [SUM] 🎀 in a make-before-break setup, communication usually keeps going over one interface while the secondary interface is still getting connected. the IEEE 802.21 working group is digging into these scenarios in detail [802.21] ✨ fast handover on a single interface needs more careful design than on a client with multiple interfaces, ngl. Dutta et al. [SIPFAST] built an optimized handover scheme for SIP-based mobility, where the transient traffic gets forwarded from the old subnet to the new one using application-layer forwarding 💖 [MITH] gives you 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 talks to the Foreign Agent before it actually moves to the new network. BUT MPA isn't limited to MIP 👑 it handles movement between domains too, and it does pre-authentication on top of proactive handover. so MPA brings the overall delay down to something close to link-layer handover delay. iconic, honestly 🌈
most of the mobility optimization work so far is stuck to one specific type of mobility protocol 🙈 and while they support optimization for inter-domain mobility, they assume there's a pre-established security arrangement between the two administrative domains. but that assumption isn't always viable, lowkey a big problem. so we need an optimization mechanism that can support inter-domain mobility without any underlying constraints or security-related assumptions ✨
the HOKEY working group in the IETF has also been working on ways to speed up authentication 🫶 specifically, they've defined pre-authentication [RFC5836] and fast re-authentication [RFC5169] mechanisms to expedite the authentication and security association process. respect 🙌
5. Applicability of MPA
okay so MPA is most applicable where an accurate prediction of movement can be easily made 🔮 for other environments, you have to take special care with stuff like pre-authentication to multiple CTNs (Candidate Target Networks), and with failed switching and switching back, as described in [MPA-WIRELESS] 😭 BUT dealing with those issues in real deployments may not be any easier. some of the deployment issues are described in Appendix C 🍓
the authors of the accompanying document [MPA-WIRELESS] cited a bunch of use cases for how MPA can optimize several network-layer and application-layer mobility protocols 💅 the effectiveness of MPA may be relatively reduced if the network uses network-controlled localized mobility management, where the MN doesn't need to change its IP address while moving within the network. it may also be relatively reduced if signaling for network access authentication is already optimized for movement within the network, for example 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 simultaneous use of multiple interfaces 🦋 and since MPA isn't tied to one mobility protocol, it's also applicable for optimizing inter-domain handover where each domain has a different mobility protocol. so cute 🌸
Figure 1 shows an example of inter-domain mobility where MPA could be applied 🎀 for example, domain A might only support Proxy MIPv6, while domain B supports Client Mobile IPv6. MPA's different functional components can provide the desired optimization techniques proactively, which is giving main character energy ✨
6. MPA Framework
6.1. Overview
okay the big picture 🧚 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 isn't only able to securely obtain an IP address and other configuration parameters for a CTN, it can also send and receive IP packets using that IP address before it actually attaches to the CTN 😭 this makes it possible for the mobile node to finish the binding update of any mobility management protocol and start using the new CoA before doing a handover at the link layer. literally iconic 👑
MPA uses the following basic procedures to get this done 🌈 the first procedure is called "pre-authentication", the second is called "pre-configuration", and the combination of the third and fourth procedures is called "secure proactive handover". the security association set up through pre-authentication is called an "MPA-SA" 🔥
this functionality works by letting a mobile node that has connectivity to its current network, but isn't attached to a CTN yet, do the following:
(i) establish a security association with the CTN to secure the subsequent protocol signaling, then
(ii) securely run a configuration protocol to get an IP address and other parameters from the CTN, and also run a tunnel management protocol to set up 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 sent after the binding update is complete, over the PHT, using the obtained IP address as the tunnel inner address, and finally
(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) is the real MVP 🏆 it makes it possible for the mobile node to finish the higher-layer handover before starting a link-layer handover. that means the mobile node can send and receive data packets sent after the binding update over the tunnel, while data packets sent before the binding update is complete don't use the tunnel 💜
6.2. Functional Elements ✨
okay so, the MPA framework expects three functional elements to hang out in each CTN and chat with a mobile node 💖: an Authentication Agent (AA), a Configuration Agent (CA), and an Access Router (AR). These elements can live in one or more network devices 🎀.
The authentication agent handles pre-authentication 🔐. An authentication protocol runs between the mobile node and the authentication agent to set up 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 💅. It SHOULD also be able to interact with a AAA protocol, such as RADIUS or Diameter, so it can carry authentication credentials to an appropriate authentication server in the AAA infrastructure 🧚. That interaction happens through the authentication agent, such as the PANA Authentication Agent (PAA) 🌸. Then the derived key gets used to derive additional keys that protect the message exchanges used for pre-configuration and secure proactive handover 🦋. Other keys 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 👑.
A configuration agent handles one part of pre-configuration, which is securely running 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 🔑. no cap, this one is a must!
An access router in the MPA framework is a router responsible for the other part of pre-configuration. That means it securely runs 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 💜.
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 Components6.3. Basic Communication Flow ✨
okay so bestie, picture this 🦋 the mobile node is already connected to a point of attachment, called oPoA (old point of attachment), and it's got a care-of address called oCoA (old care-of address). here's how the MPA communication flow goes 💖 the whole time, data packet loss should not occur, except during the switching procedure in Step 5 below. during that moment, it's totally link-layer handover's job to keep packet loss as low as possible 🫶
Step 1 (pre-authentication phase): the mobile node finds a CTN through some discovery process, like IEEE 802.21, and gets the IP addresses of an authentication agent, a configuration agent, and an access router in the CTN (Candidate Target Network) by some means 🔍 discovery mechanisms are covered in Section 7.1. the mobile node does pre-authentication with the authentication agent. as Section 7.2 explains, the mobile node may need to pre-authenticate with multiple candidate target networks 👀 which candidate network it pre-authenticates with depends on factors like signaling overhead, bandwidth requirement (Quality of Service (QoS)), the mobile node's location, communication cost, handover robustness, etc. the policy that picks the target network for pre-authentication is out of scope for this document, so that's a whole other story 💅
if pre-authentication succeeds, an MPA-SA gets created between the mobile node and the authentication agent ✨ two keys get derived from the MPA-SA: an MN-CA key and an MN-AR key. they protect the later signaling messages of a configuration protocol and a tunnel management protocol, respectively 🔐 then the MN-CA key goes securely to the configuration agent, and the MN-AR key goes securely to the access router. so iconic 😭
Step 2 (pre-configuration phase): the mobile node realizes its point of attachment will probably change from oPoA to a new one, called nPoA (new point of attachment) 🌸 so it does pre-configuration with the configuration agent, using the configuration protocol to get some config parameters, like an IP address called nCoA (new care-of address), plus a default router from the CTN. then it talks to the access router with the tunnel management protocol to set up a proactive handover tunnel 🚇 in that tunnel management protocol, the mobile node registers oCoA as the tunnel outer address and nCoA as the tunnel inner address. the pre-configuration signaling messages are protected with the MN-CA key and the MN-AR key 🔑 when the configuration agent and access router live in the same device, the two protocols can be merged into one protocol, such as IKEv2, bestie, which is a whole vibe 🧚 once the tunnel is set up, the mobile node can use both oCoA and nCoA by the end of Step 4 🎀 and a configuration protocol and a tunnel management protocol may be combined into a single protocol or run in different orders, depending on which actual protocols get used for configuration and tunnel management.
Step 3 (secure proactive handover main phase): the mobile node decides to switch to the new point of attachment by some means 🦋 before it actually switches, it starts secure proactive handover. it does this by running the binding update operation of a mobility management protocol and sending later data traffic over the tunnel. that's the main phase 💜 this proactive binding update could be triggered by a local policy on the mobile node's end, once the pre-configuration phase is done. that local policy could be things like Signal-to-Noise Ratio, the mobile node's location, etc. sometimes the mobile node caches multiple nCoA addresses and does simultaneous binding with the Correspondent Node (CN) or Home Agent (HA) 🌈
Step 4 (secure proactive handover pre-switching phase): the mobile node finishes the binding update and gets ready to switch to the new point of attachment ✨ it may run the tunnel management protocol to delete or disable the proactive handover tunnel, and cache the nCoA after the tunnel is deleted or disabled 🍓 this transient tunnel can be deleted before or after the handover. once the tunnel interface is deleted, the buffering module at the next access router starts buffering packets 📦 when the mobile node is actually ready to switch depends on the handover policy, so no pressure bestie 😌
Step 5 (switching): a link-layer handover is expected to happen in this step ⚡
Step 6 (secure proactive handover post-switching phase): the mobile node runs the switching procedure 🏃♀️ once that finishes successfully, 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 wasn't deleted or disabled in Step 4, it gets deleted or disabled now too. after this, data packets can go straight out using the nCoA, with no proactive handover tunnel needed 🎉
Call flow for MPA is shown in Figures 3 and 4. it's giving diagram energy 📊
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)
| | | | | | |
+----------------+ | | | | | |
|(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 give a mobile node that's zooming between subnets and/or domains an optimized handover, we've gotta look at a bunch of operations 🏎️ the 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),
- 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'll walk through each of these issues in detail in the following paragraphs, and show how MPA-based secure proactive handover optimizes them 💜🫶
7.1. Discovery ✨
okay so finding your neighbors early is literally what makes a handover smooth 🧭. once a mobile node has discovered the neighborhood with the coordinates, capabilities, and parameters it wants, it can do a bunch of stuff while it's still in the previous network, like pre-authentication, proactive IP address acquisition, proactive address resolution, and binding update. main character energy 💅
there are a few ways a mobile node can discover neighboring networks. The Candidate Access Router Discovery protocol [RFC4066] helps find the candidate access routers in those neighboring networks. for a given network domain, SLP (Service Location Protocol) [RFC2608] and DNS help give addresses of the networking components for a certain set of services in that domain 🫶. sometimes many of the network-layer and upper-layer parameters can get sent over link-layer management frames, like beacons, once the mobile node gets close to the neighboring networks. IEEE 802.11u is looking into stuff like discovering the neighborhood using info in the link layer 🤓.
BUT here's the tea 🍵: if the link-layer management frames are encrypted by some link-layer security mechanism, the mobile node might not be able to get the info it needs before it sets up link-layer connectivity to the access point 😭. and that can add burden to the bandwidth-constrained wireless medium too. so in those cases a higher-layer protocol is preferred for getting info about the neighboring elements. some proposals, like [802.21], help get info about neighboring networks from a mobility server. when movement is imminent, the mobile node starts discovery by querying a specific server and gets the required parameters, like the IP address of the access point, its characteristics, routers, SIP servers, or authentication servers of the neighboring networks. if there are multiple networks, it may get the required parameters from more than one neighboring network and keep them in a cache 🗂️.
eventually the mobile node finds several CTNs out of many probable networks and starts the pre-authentication process by communicating with the required entities in those CTNs. more details on this scenario are in Section 7.2 🎀.
7.2. Pre-Authentication in Multiple-CTN Environment
okay this one is a little plot twist 🙈. even though a mobile node picks a specific network as its target network, it might actually end up moving into a neighboring network that isn't the target, because of factors that are totally beyond its control 🌪️. so it can be really useful to do pre-authentication with a few probable candidate target networks and set up time-bound transient tunnels with the respective access routers in those networks ✨. that way, if the mobile node moves to a candidate target network other than the one it chose, it won't get hit with packet loss from the authentication and IP address acquisition delay that could happen if it hadn't pre-authenticated with that candidate 🦋.
now, it may seem like pre-authenticating with a bunch of candidates and reserving IP addresses is wasteful, since the mobile node is holding resources it could be using otherwise. but since this happens for a time-limited period, it shouldn't be a big problem 💅. it depends on the mobility pattern and duration, though. the mobile node uses a pre-authentication procedure to proactively get an IP address and set up the time-bound tunnels with the access routers of the candidate target networks. and the MN may hang on to 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). that way it'll receive the tunneled traffic via the target network while it's still in the previous network 🌸. BUT sometimes the mobile node ends up moving to a network that isn't the target network 😬. so there will be a disruption in traffic as it moves to the new network, since it 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 🔥.
solution number one: the mobile node can use the simultaneous mobility binding and send multiple binding updates to the Correspondent Host or HA. then 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, which stops the flow to the other candidate networks 🙌. RFC 5648 [RFC5648] discusses different scenarios of mobility binding with multiple care-of-addresses 📚.
solution number two: if simultaneous binding isn't supported in a specific mobility scheme, forwarding 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
so generally, a mobility management protocol works together 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're talking about the address assignment component used in the co-located address mode here 🎀.
there are several ways a mobile node can get an IP address and configure itself. in some cases, a mobile node can configure itself statically when there's no configuration element, like a server or router, in the network 🧸. in a LAN environment, the mobile node can get an IP address from DHCP servers. with IPv6 networks, the mobile node has the option of getting the IP address using stateless autoconfiguration or DHCPv6 ✨. in some wide-area networking environments, the mobile node uses PPP (Point-to-Point Protocol) to get the IP address by communicating with a NAS (Network Access Server) 📡.
each of these processes takes on the order of a few hundred milliseconds to a few seconds, depending on the type of IP address acquisition process and the operating system of the clients and servers ⏱️. since IP address acquisition is part of the handover process, it adds to the handover delay, so it's desirable to reduce this delay as much as possible 😤. there are a few optimized techniques available, like DHCP Rapid Commit [RFC4039] and GPS-coordinate-based IP address [GPSIP], that try to cut down the handover delay from IP address acquisition time. BUT in all these cases, the mobile node still gets the IP address after it moves to the new subnet, and it takes 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) while it's still present on the Previous Access Router's (pAR's) link. so the latency from new prefix discovery after 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 🤝.
okay so here's the lineup 📋. in the following paragraph, we describe a few ways a mobile node can get the IP address proactively from the CTN, plus the associated tunnel setup procedure. these can broadly be divided into four categories: PANA-assisted proactive IP address acquisition, 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 gets an IP address proactively from a CTN 🌷. the mobile node uses PANA [RFC5191] messages to trigger the IP address acquisition process via a DHCP client that's co-located with the PANA authentication agent in the access router in the CTN, which acts on behalf of the mobile node 🫶. when the authentication agent gets a PANA message from the mobile node, the DHCP client on it runs the normal DHCP message exchanges to get the IP address from the DHCP server in the CTN 💫. this address gets piggy-backed in a PANA message and delivered to the mobile node ✨.
if IPv6 is in play, a Router Advertisement (RA) is carried as part of the PANA message 🧚. with stateless autoconfiguration, the mobile node uses the prefix(es) it got from the RA and its MAC address to construct the unique IPv6 address(es) just as it would have done in the new network 🔥. with 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 both 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 get 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 to get the IP address from the DHCP server in the target network via standard DHCP 🎀. the obtained IP address is sent back to the client in the IKEv2 Configuration Payload exchange 💌.
and yes, 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
Okay bestie, here's another option 💅 DHCP can proactively grab an IP address from a CTN without needing PANA or IKEv2 🦋 The trick is letting the mobile node talk straight to the DHCP relay agent or DHCP server in the CTN. Heads up: this bit only works for DHCPv4 🎀 The mobile node sends a unicast DHCP message to the relay agent or server asking for an address, and it uses the address on its current physical interface as the source address of that request.
When the message goes to a DHCP relay agent, the relay agent bounces the DHCP messages back and forth between the mobile node and the DHCP server. No relay agent? No drama 🧚 The mobile node can also talk directly to the DHCP server in the target network. The broadcast option in the client's unicast DISCOVER message should be set to 0, so the relay agent or DHCP server can send the reply straight back to the mobile node using the mobile node's source address ✨
Now for the security tea 🚨 We definitely don't want shady nodes grabbing addresses from the DHCP server 💀 So DHCP authentication should be used, or the access router should be configured with a filter that blocks 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.
Not gonna lie, skipping this part is how you end up with rogue addresses everywhere. Lock it down, bestie 🔒
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 🌸 Instead, it should be assigned to a virtual interface of the client. So an address acquired this way, through direct DHCP communication with the relay agent or the DHCP server in the CTN, may carry extra information that tells it apart from the addresses on the physical interface. Very organized, very iconic 👑
Once the mobile node enters the new network, it can run DHCP over the physical interface to get other configuration parameters, like the SIP server or DNS server, using DHCP INFORM. This should not affect the ongoing communication between the mobile node and the Correspondent Host 💜 The mobile node can also run DHCP over the physical interface to the new network to extend the lease of the address it proactively obtained before entering the new network.
Last but not least, the DHCP binding has to stay consistent 🍓 To keep track of the dispensed IP address before and after the secure proactive handover, the mobile node must use the same DHCP client identifier for both the proactive IP address acquisition and the DHCP run after it enters the target network. The DHCP client identifier may be the MAC address of the mobile node or some other identifier. Keeping the ID steady is the whole vibe 🫶
7.3.4. Proactive IP Address Acquisition Using Stateless Autoconfiguration
For IPv6, a network address is configured either using DHCPv6 or stateless autoconfiguration ✨ To grab the new IP address early, 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 skips the time it would normally take to obtain an IP address and run Duplicate Address Detection, which is honestly so efficient 🧚
Duplicate Address Detection and address resolution are both part of the IP address acquisition process 🎀 As part of the proactive configuration, these two processes can be done ahead of time. Details on how to do each of them proactively are in Appendix A and Appendix B, respectively.
With stateless autoconfiguration, the mobile node checks the prefix of the router advertisement in the new network and matches it against the prefix of the newly assigned IP address. If the two turn out to be the same, the mobile node does not go through the IP address acquisition phase again 🙈 Shortcut unlocked 🔓
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 this transient tunnel is set up between the nAR and the mobile node in the old PoA 💅 That's different from the transient tunnel in FMIPv6 (Fast MIPv6) [RFC5568], where it's set up between the mobile node's new point of attachment and the old access router.
In the case of inter-domain handoff, any signaling message between the nPoA and the mobile node needs to be secured 🔐 This transient secured tunnel does the job, 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 packets are not sent to the pAR, so a tunnel between the mobile node's new point of attachment and the old access router is not needed.
Also for inter-domain handoff, the pAR and nAR could logically be far from each other 🌈 So the signaling and data during the pre-authentication period will take a longer route, and may be subjected to a longer one-way delay. Hence, MPA gives you a tradeoff: either larger packet loss or larger one-way packet delay for a transient period while the mobile node is preparing for handoff. Pick your poison, babe 💀
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 👑 That way 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 it's still 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.
For the traffic to be directed to the mobile node after it attaches to the target network, the proactive handover tunnel needs to be deleted or disabled ✨ The tunnel management protocol used to establish 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 the PANA update mechanism as soon as the mobile node moves to the target network. A link-layer trigger makes sure the mobile node is actually connected to the target network, and it can also be used as the trigger to delete or disable the tunnel 🧚 Also, a tunnel management protocol triggers the router advertisement (RA) from the next access router to be sent over the tunnel, as soon as the tunnel creation is complete.
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 the 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 📞 Depending 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 don't hit the delay from the binding update at all, since it takes place in the previous network 🙌
So 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. 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, receiving an on-link router advertisement is mandatory for the mobile node to detect movement and trigger the binding update 🦋 So a router advertisement from the next access router needs to be advertised over the tunnel. With 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 it can send the binding update over 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 📚
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 how to prevent them are described below 👀
7.6.1. Packet Loss Prevention in Single-Interface MPA ✨
okay so with single-interface MPA, there can be some stray packets during the link-layer handover that still get sent to the mobile node at its old point of attachment, before the MN is able to attach to the target network 🥺. Those stray packets can get lost. Buffering them at the access router of the old point of attachment can totally stop that loss 💖. Dynamic buffering signals from the MN can temporarily hold the transient traffic during handover, and then those packets get forwarded to the MN once it attaches to the target network. If you want the deep dive on the buffering technique, it's in [PIMRC06] 📚.
An alternative is bicasting 🦋. Bicasting forwards the traffic to two destinations at the same time. But ngl, it doesn't prevent packet loss if the link-layer handover isn't seamless 💀. Buffering also has its own downside: it doesn't reduce packet delay. A playout buffer at the receiver can cover that delay for a streaming app, but it doesn't help much for interactive VoIP, which can't handle big delay jitter 😭. So optimizing the link-layer handover is still super important, no matter what 👑.
7.6.2. Preventing Packet Losses for Multiple Interfaces 🌈
MPA in multi-interface handover scenarios is all about getting the second interface ready to go while the current active interface is still doing its thing 🧚. That prep includes pre-authentication and provisioning at a target network, where the second interface will eventually become the active one. For example, during an inter-technology handover from WiFi to a CDMA network, the pre-authentication at the CDMA network can happen over the WiFi interface. The real handover happens once the CDMA interface becomes the MN's active interface ✨.
Here's the tea 🍵: if handover happens while both interfaces are active, there's generally no packet loss, because transient packets aimed at the old interface still reach the MN. But if the current active interface gets suddenly disconnected to kick off handover to the prepared interface, then transient packets for the disconnected interface get lost while the MN tries to become reachable at the prepared one 😱. In those cases, a specialized form of buffering can save the day. Packets are simply copied at an access router in the current active network before the disconnection happens. If the sudden disconnection does occur, those copied packets can be forwarded to the MN once the prepared interface becomes the active reachable interface 🫶. And the copy-and-forward mechanism isn't limited to multi-interface handover, so it's not just a one-trick pony 🦋.
Now, a notable side-effect: packets might get duplicated while they're being forwarded to the new active interface 🙈. There are a few ways to keep that in check. 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 work. Generally speaking, packet duplication is a well-known issue, and the MN can also handle it locally 💅.
Also, if the MN takes a long time to detect that the current active interface has disconnected, that drags out the whole handover process 🐌. So it becomes necessary to use an optimized scheme for detecting interface disconnection in these scenarios. Sometimes it's preferable to do pre-authentication over the current interface instead of the new one. That can help save battery power, or when the adjacent cells (like WiFi or CDMA) don't overlap, or when the carrier doesn't allow both interfaces to be used at once 🔋. Depending on the type of target network, though, only parts of MPA operations might be possible, such as pre-authentication, pre-configuration, or a proactive binding update 🍓. In one specific WiFi-to-CDMA handoff scenario, some of the PPP context can be set up during the pre-authentication period, which cuts down the time it takes to activate PPP ⏩.
7.6.3. Reachability Test 🔍
On top of the earlier techniques, the MN might also want to make sure the new point of attachment is reachable before it switches away from the old one 👀. It can do that by exchanging link-layer management frames with the new point of attachment. This reachability check should be done as quickly as possible ⚡. To keep packets from being lost during the check, transmission over the link between the MN and the old point of attachment should be suspended, with packets buffered at both ends of the link while the check runs 🛑. How to do that buffering is out of scope for this document, but the accompanying document [MPA-WIRELESS] shares some of the results of using this buffering scheme 📖.
7.7. Security and Mobility 🔐
This section is all about how MPA can help set up layer 2 and layer 3 security associations in the target networks while the mobile node is still hanging out in the previous network 🥰.
7.7.1. Link-Layer Security and Mobility 🛡️
So, using the MPA-SA that's set up between the mobile node and the authentication agent for a CTN during the pre-authentication phase, it's possible to bootstrap link-layer security in the CTN while the MN is still in its current network 💜. Here's how it goes, and Figure 5 shows the sequence of operation 🎀.
(1) The authentication agent and the MN derive a PMK (Pair-wise Master Key) [RFC5247] using the MPA-SA that gets established after successful pre-authentication. Successful operation of EAP and a AAA protocol may be involved during pre-authentication to set up the MPA-SA 🔑. From the PMK, distinct TSKs (Transient Session Keys) [RFC5247] for the mobile node are derived, either directly or indirectly, for each point of attachment in the CTN 🧁.
(2) The authentication agent may install the keys derived from the PMK, which are used for secure association, onto the points of attachment. These derived keys may be TSKs themselves, or intermediary keys that the TSKs get derived from 📦.
(3) Once the mobile node chooses a CTN as the target network and switches to a point of attachment in it (which now becomes its new network), it runs a secure association protocol such as the IEEE 802.11i 4-way handshake [802.11]. It uses the PMK for this to set up PTKs (Pair-wise Transient Keys) and group keys [RFC5247], which protect link-layer packets between the MN and the point of attachment 🤝. No extra EAP authentication is needed here, so no drama 🙌.
(4) While the MN roams around in the new network, it only needs to do a secure association protocol with its point of attachment. Again, no additional EAP authentication is needed 🏃♀️. Integrating MPA with link-layer handover optimization mechanisms, like 802.11r, can be achieved this way ✨.
The MN may need to know the link-layer identities of the points of attachment in the CTN in order to derive TSKs 🪪.
Figure 5 below, for the visual learners 👀:
_________________ ____________________________
| 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 Security7.7.2. IP-Layer Security and Mobility 🌐
IP-layer security is usually kept up between the mobile node and the first-hop router, or any other network element (like a SIP proxy), using IPsec 🔒. This IPsec SA can be set up in either tunnel mode or ESP mode. But here's the catch: as the MN moves, the IP address of the router and the outbound proxy changes in the new network 😵. The MN's own IP address may or may not change, depending on which mobility protocol is in use 🤷♀️. So a new security association between the MN and the desired network entity has to be set up again. In some cases, like a 3GPP/3GPP2 IMS/MMD environment, data traffic isn't allowed through unless there's an IPsec SA between the MN and the outbound proxy. That adds unreasonable delay to real-time communication while the MN is moving 😩. In this scenario, the key exchange happens as part of a SIP registration, which follows a key exchange procedure called AKA (Authentication and Key Agreement) 🗝️.
MPA can be used to bootstrap this security association as part of pre-authentication via the new outbound proxy 🚀. So, before the move, if the MN can pre-register via the new outbound proxy in the target network and completes the pre-authentication procedure, the new SA state between the MN and the new outbound proxy can be set up before the MN moves to the new network 🙌. A similar approach can also be used if a key exchange mechanism other than AKA is used, or if the network element that the security association has to be set up with is something other than an outbound proxy 💫.
Because the security association is set up ahead of time, the MN doesn't need to take part in any exchange to set up the new security association after it moves 🥳. Any further key exchange is only needed to renew the expiry time. That cuts down the delay for real-time communication too ⏱️.
7.8. Authentication in Initial Network Attachment 🪪
When the mobile node first attaches to a network, network access authentication happens no matter whether MPA is used or not 🔓. 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 one, such as PANA 💖.
8. Security Considerations 🔐
okay bestie, this section is the serious one, so let's go 💅. This doc describes a framework for a secure handover optimization mechanism. The mobile node does handover-related signaling with one or more candidate target networks (CTNs) it might move to later ✨. The framework covers getting resources from those CTNs, and redirecting data packets from the CTN to the mobile node while it's still in its current network, before it actually connects to one of them 🦋.
Getting resources from candidate target networks has to go through proper authentication and authorization, or an unauthorized mobile node could grab resources it shouldn't have 😭. That's why MPA needs to do pre-authentication between the mobile node and the candidate target networks 🔒. The MN-CA key and the MN-AR key that come out of a successful pre-authentication can protect the handover signaling packets and data packets that go between the mobile node and the MPA functional elements in the CTNs 💜.
MPA also deals with security when the handover crosses multiple administrative domains 🌈. With MPA, handover signaling can happen through direct communication between the mobile node and routers or mobility agents in the candidate target networks 🧚. That means no need for a context transfer protocol [RFC5247], which has known limitations when it comes to security and authorization 💀. So MPA doesn't require trust relationships among administrative domains or access routers, and that makes the framework way more deployable on the Internet without messing up security in mobile environments 👑.
9. Acknowledgments 🫶
We would like to thank Farooq Anjum and Raziq Yaqub for reviewing this doc, and Subir Das for standardization support in the IEEE 802.21 working group 🌸.
The authors would like to shout out Christian Vogt, Rajeev Koodli, Marco Liebsch, Juergen Schoenwaelder, and Charles Perkins for their thorough review 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 at 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.
[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.10.2. Informative References
Okay, now the bibliography, which is basically the reading list for anyone who wants to go deeper. Every entry is kept exactly as written, so you can look them all up 📚🫶
[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.
[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.
[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.
[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.Appendix A. Proactive Duplicate Address Detection ✨
Okay, this appendix is all about getting your address sorted BEFORE you need it 💅
When a DHCP server hands out an IP address, it writes that address into its lease table, so nobody else gets the same address for that lease period 📝 The client keeps a lease table of its own too, so it knows when to renew 🫶
Now here's where it gets messy 😭 In networks with a mix of DHCP and non-DHCP clients, there's a chance that some other client on the LAN was manually configured with an address from the DHCP pool. In that situation, the server runs a duplicate check using ARP (Address Resolution Protocol) or IPv6 Neighbor Discovery before it assigns the address. That check can take anywhere from 4 sec to 15 sec [MAGUIRE], and it adds to the handover delay. Not ideal, bestie.
With proactive address acquisition, that check happens ahead of time, so it doesn't touch the handover delay at all 🦋 Doing Duplicate Address Detection (DAD) early is how we cut down the IP address acquisition time. It's giving efficiency ✨
Here's the careful bit 🧚 The proactive DAD over the candidate target network should be performed by the nAR on behalf of the mobile node when the proactive handover tunnel is set up, because DAD over a tunnel isn't always performed. For instance, with IPv6, DAD over an IP-IP tunnel interface is turned off in an existing implementation. With IPv6 over PPP [RFC5172], the IP Control Protocol (IPCPv6) negotiates the link-local addresses, so DAD over the tunnel isn't needed there 🌸
Once the mobile node moves to the target network, a DAD procedure may start because the nCoA gets reassigned to the physical interface on that network. In that case, the mobile node should use optimistic DAD [RFC4429] over the physical interface. That way, the nCoA that was already in use inside the proactive handover tunnel can be used right away on that physical interface after the handover 🚀 Main character handover energy, no cap 👑
Last but not least, the schemes for proactive DAD and optimistic DAD work for both stateless and stateful address autoconfiguration when it comes to getting an nCoA 💜
Appendix B. Address Resolution ✨
Okay so address resolution is basically about updating the next access router's neighbor cache 🫶. We'll briefly walk through these two operations below 🦋.
During pre-configuration, the MAC address resolution mappings the mobile node needs to talk to nodes in the target network can already be known, before it even attaches 💜. Those communicating nodes could be the access router, authentication agent, configuration agent, or Correspondent Node. There are several possible ways to do this proactive MAC address resolution 🧚.
- 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 build the database for proactive MAC address resolution 🌸.
- 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 💅.
- 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 live in the target network and are communicating with the mobile node should also update their address resolution mappings for the mobile node as soon as it attaches to the target network 🎀. The proactive address resolution methods above could also be used by those nodes to proactively resolve the MAC address of the mobile node before it attaches. However, this is not useful, since 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 integrating 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 it attaches to the new network. That way, 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 💀
Okay the ping-pong effect is one of the most common problems during handover 😭. It happens when a mobile node is sitting right on the borderline of a cell or decision point, and a handover procedure keeps getting executed over and over. That leads to higher call drop probability, lower connection quality, increased signaling traffic, and wasted resources 🥲. All of these hurt mobility optimization, periodt 💅.
Handoff algorithms are the deciding factors for performing the handoff between networks 🧠. Traditionally, these algorithms use a threshold to compare the values of different metrics and 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 📊. To avoid the ping-pong effect, some additional parameters are used by the decision algorithm, such as hysteresis margin, dwell timers, and averaging window 🌸. For a vehicle moving at high speed, other parameters are also taken into account to reduce the ping-pong effect, such as the distance between the mobile node and the point of attachment, the velocity of the mobile node, its location, and traffic and bandwidth characteristics 🚗. More recently, other handoff algorithms have come out that help reduce the ping-pong effect in a heterogeneous network environment. These are based on techniques such as hypothesis testing, dynamic programming, and pattern recognition 🔥. 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 results in back-and-forth movement of the mobile node between the current network and the target network, and between the candidate target networks 🦋. MPA in its current form is affected by the number of tunnels set up between the mobile node and neighboring access routers, the number of binding updates, and the associated handoff latency that comes 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 help reduce the probability of the ping-pong effect, and we propose several methods for the MPA framework so that it can recover from the packet loss caused by the ping-pong effect ✨.
The MPA framework can take advantage of the mobile node's geo-location with respect to APs in neighboring networks, using GPS 🗺️. To avoid oscillation between networks, a location-aware algorithm can be derived by using a co-relation between the user's location and cached data from previous handover attempts 🧚. In some cases, location may not be the only indicator for a handoff decision. For example, in Manhattan-type grid networks, a mobile node can be close to an AP and still not have enough SNR (Signal-to-Noise Ratio) to make a good connection 🙈. So 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 a good recovery mechanism in place, 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 the security association, the IP address used, and the tunnels established 🔐. Bicasting the data to both the previous network and the new network for a predefined period will also help the mobile node take care of lost packets, in case it 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 state in the authentication agent of each of the neighboring networks for a certain time period 🌸. That way, if the mobile node does move back and forth between neighboring networks, already-maintained authentication state can be helpful ✨. We give some highlights on multiple security association state management below 🧚.
A mobile node that has pre-authenticated with an authentication agent in a candidate target network and has an MPA-SA may need 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 established between the MN and the authentication agent for a certain time period. This way it doesn't have to go through the entire authentication signaling to create an SA from scratch, in case it returns to the previous network 🦋. An SA being held at the authentication agent after the MN's handover to another network is considered 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 only be changed back to the fully authorized state 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 the MN's IP address changes due to a handover, so that the new SA can be re-established 🔄.
C.3. Pre-Allocation of QoS Resources 🎀
In the pre-configuration phase, it is also possible to pre-allocate QoS resources that the mobile node may use 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. Pre-authentication can be used to bootstrap 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 they 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. That's because the paths between the target access router and the mobile node differ 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 ✨
okay bestie, so with multiple CTNs, setting up multiple tunnels to the neighboring target networks is lowkey amazing 🫶 but ngl it also causes some resource utilization issues 💀. pre-authentication with several candidate target networks can happen in a few different ways 🦋
the most basic scheme is authenticating the mobile node with the authentication agents in all the neighboring networks 🎀. the actual pre-configuration and binding update don't happen until layer 2 movement to one specific network is complete 💅
then there's the mobile node doing the pre-configuration while it's still in the previous network, but holding off on the binding update until after it has moved 🌸 same as the last one, the mobile node also doesn't need to set up the pre-configured tunnels 🧚 so pre-authentication and part of the pre-configuration are handled before the move, and the binding update is the part that actually happens after 🦋
the third type of multiple pre-authentication does all three steps while the mobile node is still in the previous networks: authentication, configuration, and binding update 😭 this one uses the highest amount of resources, btw. some of the resources it eats up are:
- Additional signaling for pre-authentication in the neighboring networks
- 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.
- There is an additional cost associated with setting up additional transient tunnels with the target routers in the neighboring networks and the mobile node.
- 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.
but wait, there are pros and cons to sending the binding update after the handover 👑 if it's sent after the mobile node has moved to the new network, it adds delay when the CH or HA is far from the MN 🙈 multiple binding updates can be handled in lots of different ways, so here are a few of those update mechanisms ✨
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's super important to figure out when to send the binding update after the layer 2 handoff 🔥
if a binding update with multiple contact addresses is sent, multiple media streams stem out of the CN using the transient tunnels 🌈 but then you need 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 the other neighboring networks it didn't move to 💜
here's an illustration of this specific case, where 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 lets the CN 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 it has moved. one issue with multiple streams is that they eat up extra bandwidth for a small period of time 😬
alternatively, you 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. the forwarding of data can be triggered by the mobile node either as part of Mobile IP registration or as a separate buffering protocol 🦋
C.5. Systems Evaluation and Performance Results 📊
in this section, we show some of the results from MPA implementation when it's applied to different handover scenarios 🔥 we summarize our experiment results using MPA techniques for two types of handovers: i) intra-technology and intra-domain, and ii) inter-technology and inter-domain. we also show how MPA can bootstrap layer 2 security for both roaming and non-roaming cases 💖 the 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
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 Resultsfor all the measurements, we didn't see any performance degradation during handover in terms of the audio quality of the voice traffic 🎧✨
with buffering during handover, packet loss during the actual L2 and L3 handover is eliminated, as long as the buffering period is set to appropriate and reasonable values, for both MIP6 and SIP mobility 🙌 for MIP6, there isn't a significant difference in results with and without route optimization. just a heads up that more samples would be needed for a more detailed analysis 🤓
for non-MPA-assisted handover, handover delay and the associated packet loss happen from the moment the link-layer handover procedure begins, up until the binding update is successfully processed 😩 during this process, IP address acquisitions via DHCP take the longest, because duplicate IP addresses get detected in the network before the DHCP request completes. the binding update exchange also takes a long time if the CN is too far from the MN 🐢 so the non-MPA-assisted handover took 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 happen in many different ways. we limit the experiment to two interfaces, which results in several possible setup scenarios depending on what the second interface is doing 🦋 in one scenario, the second interface comes up when the link to the first interface goes down. this is a reactive scenario and usually leads to undesirable packet loss and handoff delay 😵 in a second scenario, the second interface is being prepared while the mobile node is still communicating over the old interface. preparing the second interface should include setting up 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 set up ahead of time, it cuts down the time it takes for the secondary interface to attach to the network ⏱️ after preparation, the mobile node decides to use the second interface as the active interface. this results in less packet loss, since it uses make-before-break techniques 🫶 this is a proactive scenario and it can have two "flavors". the first is where both interfaces are up; the second is where only the old interface is up and the prepared interface is brought up only when a handoff is about to happen 🔋 this scenario may be beneficial from a battery management standpoint. devices that run two interfaces at once can drain their batteries really fast 🪫 but by activating the second interface only after an appropriate network has been selected, the client can use battery power effectively ⚡
compared to non-optimized handover, which may cause a delay of up to 18 sec and a 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 needed for link down detection and the 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 from MPA-assisted layer 2 pre-authentication and compare them with EAP authentication and IEEE 802.11i's pre-authentication techniques 🧠 Figure 8 shows the experimental testbed where we ran 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 is reduced to a 4-way handshake only ✨ then the MN moves to the AP and, after association, runs a 4-way handshake using the PSKap (Pre-shared Key at AP) generated during PANA pre-authentication. at this point, the handoff is complete 🎉 the details of this experimental testbed can be found in [MOBIQUIT07] 🫶
Okay so these testbed diagrams are literally the vibe 🧚 Figure 8 is the non-roaming setup, and Figure 9 is the roaming one. ✨
+----------------------------+-----------+ +-------------+----------+
| | | |
| 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)
+-----------------------------+
| +--------+ |
| | | |
| | 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)We ran three movement scenarios, covering both non-roaming and roaming cases, on the testbeds in Figures 8 and 9, respectively. 🦋 In the roaming case, the MN is visiting a domain that isn't its home domain, so it has to contact the AAA server in the home domain (AAAH) from its new domain. 💅 For the non-roaming case, the MN is just moving around inside its home domain, and only the local AAA server (AAAHome), which is the home AAA server for the mobile node, gets contacted. 🏠
The first scenario has no pre-authentication at all. ✨ The MN starts out connected to AP0 and moves to AP1. Since neither network-layer authentication nor IEEE 802.11i pre-authentication is in play, the MN has to do a full EAP authentication with AP1 to get onto the network after the move (post-authentication). 😭 This experiment shows what happens when there's no pre-authentication of any kind. 💀
The second scenario uses 802.11i pre-authentication and involves movement between AP1 and AP2. 🌸 Here the MN starts out connected to AP2 and kicks off IEEE 802.11i pre-authentication with AP1. This is the perfect setup for comparing the numbers from 802.11i pre-authentication against network-layer assisted pre-authentication. 🔥 Both scenarios use RADIUS as the AAA protocol (APs implement a RADIUS client). 🎀
The third scenario is where the network-layer assisted link-layer pre-authentication shines. 👑 It involves movement between two APs (for example, between AP0 and AP1) that sit in two different subnets, where 802.11i pre-authentication isn't possible. 🙈 Here, Diameter is the AAA protocol (PAA implements a Diameter client). 🧚
In that third movement scenario, the MN starts out connected to AP0. 🦋 It kicks off PANA pre-authentication with the PAA, which is co-located on the AR in the new candidate target network (nAR in network A), while it's still associated with the current network (network B). 🌈 Once authentication is done, the PAA proactively installs two keys, PSKap1 and PSKap2, into AP1 and AP2, respectively. 💜 Doing those key installations ahead of time means the PAA skips the trip to the AAA server for the keys after the mobile node has already moved to the new network. 🫶 Finally, since PSKap1 is already installed, AP1 immediately starts the 4-way handshake. ⭐ We used measurement tools such as ethereal and kismet to analyze the measurements for the 4-way handshake and PANA authentication. 🔍 These measurements reflect the different operations involved during network-layer pre-authentication. 📊
In our experiment, as part of the discovery phase, we assume the MN can retrieve the PAA's IP address and all the required information about AP1 and AP2 (for example, channel, security-related parameters, and so on) at some point before the handover. 🍓 This skips the scanning during link-layer handoff. 🌷 We applied this assumption to all three scenarios. 💖 Our focus is on cutting down the time spent on the authentication phase during handoff, so we don't go into the details of how we avoid the scanning. 🤫
Now let's look at the numbers. 👀 Figure 10 shows the timing (rounded off to the most significant number) for some of the handoff operations we measured in the testbed. 🎀 Each timing parameter is described below. 💅
=====================================================================
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-AuthenticationTauth is the time spent running EAP-Transport Layer Security (TLS) authentication. ⏱️ It doesn't care whether that authentication happened during pre-authentication or a regular post-authentication. 🤷♀️
Tconf is the time spent generating and installing the PSK after EAP authentication is done. ✨ When network-layer pre-authentication isn't used, this time doesn't get counted. 🙅♀️
Tassoc+4way is the time for finishing the association and the 4-way handshake with the target AP after the handoff. 🦋
The first two columns show the non-roaming and roaming results when no pre-authentication is used at all. 🌸 The next two columns show the same cases with IEEE 802.11i pre-authentication. 💜 The last two columns show what happens with network-layer-assisted layer 2 pre-authentication. 🧚 When pre-authentication is in use, only Tassoc+4way affects the handoff time. 🎀 When no pre-authentication is used, the handoff time includes Tauth (the complete EAP-TLS authentication) plus Tassoc+4way. 😭🔥
okay so this is the part where the numbers really hit, bestie 📉✨ That's exactly the handoff delay when the MN moves from AP0 to AP1 with no pre-authentication. ngl these delays are way too slow for real-time apps 😭 For the non-roaming case we measured a ~80-ms gap just to re-establish the connection with target AP1. And when the MN moves into a visited domain with a far-away home AAA server, the handoff takes about 600 ms. 💀
Now the glow-up 💅 Network-layer pre-authentication is only affected by Tassoc+4way (~17 ms), and that covers any kind of handoff authentication. IEEE 802.11i pre-authentication gives a comparable benefit (~16 ms) for handoff, but it only works when the APs are in the same Distribution System (DS) 🙃 Network-layer pre-auth is also giving main character energy because one EAP authentication can bootstrap security for several target APs. The MN can roam among APs under the same PAA without running EAP, so it never has to contact the AAA server. This extends the IEEE 802.11r advantages over 802.11i by allowing inter-subnet, inter-domain, and even inter-technology handoffs. literally iconic 🦋
C.6. Guidelines for Handover Preparation ✨
Okay, this section is all about guidelines for roaming clients that use pre-authentication mechanisms to cut down the handoff delay 🎀 These guidelines can help you figure out how much pre-authentication work is needed for a particular type of client movement. IEEE 802.11i and 802.11r both use pre-authentication at layer 2, so a lot of the guidelines for 802.11i-based pre-authentication and 802.11r-based fast roaming could also apply to clients using MPA-based pre-authentication techniques 🌸 BUT MPA operations aren't limited to a specific subnet, and they involve inter-subnet and inter-domain handover. So the guidelines also need to consider other factors, like the movement pattern of the mobile node, cell size, and so on.
The time needed to finish pre-authentication is a big deal 👑 The mobile node needs to know how far ahead it has to start pre-authentication so that everything finishes before the handover to the target network begins. How long this takes depends on how fast the mobile node is moving (for example, pedestrian vs. vehicular) and on the cell sizes (for example, WiFi or Cellular). Cell residence time is the average time the mobile node stays in a cell before the next handoff happens. It depends on the coverage area and the velocity of the mobile node, so it's a super important factor when deciding how much pre-authentication time the mobile node should plan for 🧚
Pre-authentication involves six steps, which are described in Section 6.3, and each step takes some discrete amount of time. Depending on the delay budget that's available, only some of these sub-operations may get finished before handoff 🍓
For example, a mobile node could finish just network discovery and the network-layer authentication process before handoff, then postpone the rest until after the handover is complete. On the other hand, if it's a slow-moving vehicle and the adjacent cells are sparsely spaced, the mobile node could finish all the desired MPA-related operations 🚗💨 Finishing everything ahead of time reduces the handoff delay, but it adds other constraints, like cell residence time.
We're going to do a numerical example here, similar to [MISHRA04] 🧮 First, the variables:
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 APsIf D = 100 ft, Tpsk = 10 ms, and RTT = 100 ms, and the mobile node only needs to run the pre-authentication procedure associated with MPA, then this is what we can calculate for a successful MPA procedure before the handoff is complete 🎯
2RTT + Tpsk < D/v
v = 100 ft/(200 ms + 10 ms) = ~500 ft/secNow, for a similar cell size, say the mobile node is doing both pre-authentication and pre-configuration as part of the MPA procedure, and it takes Tconf = 190 ms to finish 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/secSo compared to only the pre-authentication part of the MPA operation, if you want to finish both pre-authentication and pre-configuration successfully, the mobile node either has to move at a slower pace or has to speed up these operations for this given cell size 🐢⚡ Basically, the types of MPA operations are constrained by the velocity of the mobile node. Lowkey a real tradeoff vibe 💜
Also, if a mobile node finishes all of the pre-authentication procedure well ahead of time, it uses up resources, like an extra IP address, an extra tunnel, and extra bandwidth 💸 So there's always a tradeoff between the performance benefit you get from pre-authentication and network characteristics like movement speed, cell size, and the resources being used. It's a whole balancing act, periodt 🫶🌈
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📦 where this page comes from
- ietf: rfc6252 2011-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms