RFC 6301
A Survey of Mobility Support in the Internet
RFC 6301: A Survey of Mobility Support in the Internet 🌸
okay bestie, this is RFC 6301 💖 It came out in July 2011, and the authors are Z. Zhu (UCLA), R. Wakikawa (Toyota ITC), and L. Zhang (UCLA) 👑. It's Category: Informational 🦋, which means it's a survey for info and NOT a standards-track spec. The ISSN is 2070-1721 ✨. The header doesn't list anything it obsoletes or updates, so there's no drama there 💅
Abstract ✨
so for the last two decades, people have been putting SO much work into mobility support over the global Internet 🌍 which means there are a lot of different solutions out there 🧚 these authors did a systematic survey of all the earlier efforts to get the big picture of the solution space 🔥 this doc shares what they found and points out the issues that are still unsolved for providing ubiquitous and efficient Internet mobility support at global scale 🫶
Status of This Memo 🎀
ok so first off, this is NOT an Internet Standards Track spec ❌ it's published just for information 💅
it's a product of the Internet Engineering Task Force (IETF) 🌈 it represents the consensus of the IETF community ✨ it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 but not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the deets 🤓
info about the current status of this doc, any errata, and how to send feedback is over at http://www.rfc-editor.org/info/rfc6301 🦋
Copyright Notice 💜
the copyright is 2011 IETF Trust and the persons identified as the document authors 💖 all rights reserved 🔒
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info (as in effect on the date of publication) 📜 please actually read those, bestie, because they explain your rights and restrictions for this doc 🙈 also, any Code Components pulled out of this doc have to include Simplified BSD License text, like Section 4.e of the Trust Legal Provisions says, and they come with no warranty, same as the Simplified BSD License 🫶
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Components in Mobility Support Protocols . . . . . . . . 4
4. Existing Mobility Support Protocols . . . . . . . . . . . . . 5
4.1. Columbia Protocol . . . . . . . . . . . . . . . . . . . . 6
4.2. VIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Loose Source Routing (LSR) Protocol . . . . . . . . . . . 9
4.4. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. HMIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. FMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7. NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.8. Mobility Support Using Multicast in IP (MSM-IP) . . . . . 13
4.9. Cellular IP, HAWAII, and TIMIP . . . . . . . . . . . . . . 14
4.10. E2E and M-SCTP . . . . . . . . . . . . . . . . . . . . . . 15
4.11. Host Identity Protocol . . . . . . . . . . . . . . . . . . 16
4.12. MOBIKE . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.13. Connexion and WINMO . . . . . . . . . . . . . . . . . . . 17
4.14. ILNPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.15. Global HAHA . . . . . . . . . . . . . . . . . . . . . . . 18
4.16. Proxy Mobile IP . . . . . . . . . . . . . . . . . . . . . 19
4.17. Back to My Mac . . . . . . . . . . . . . . . . . . . . . . 20
4.18. LISP-Mobility . . . . . . . . . . . . . . . . . . . . . . 21
5. Different Directions towards Mobility Support . . . . . . . . 21
5.1. Routing-Based Approach versus Mapping-Based Approach . . . 22
5.2. Mobility-Aware Entities . . . . . . . . . . . . . . . . . 23
5.3. Operator-Controlled Approach versus User-Controlled
Approach . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.4. Local and Global-Scale Mobility . . . . . . . . . . . . . 25
5.5. Other Mobility Support Efforts . . . . . . . . . . . . . . 26
6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Deployment Issues . . . . . . . . . . . . . . . . . . . . 27
6.2. Session Continuity and Simultaneous Movements . . . . . . 28
6.3. Trade-Offs of Design Choices on Mobility Awareness . . . . 29
6.4. Interconnecting Heterogeneous Mobility Support Systems . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8. Informative References . . . . . . . . . . . . . . . . . . . . 301. Introduction 🦋
so this doc shares what we found in a historical survey of Internet mobility research and standards work since the early 1990s 📚 we did it for two big reasons 💅
first, mobility support over the Internet has been a super active research area that has produced a bunch of solutions, and some of them became Internet standards 🏆 but new issues keep popping up and new solutions keep getting built to handle them 🤯 which makes you wonder how much more there is to learn about both the problem space AND the solution space 🌀
second, more and more people are getting on the Internet from mobile devices, which is going to lead to new Internet apps in the coming years and make Internet mobility support even MORE important 📱✨
we think a historical review of every proposed solution on the table can help us spot what they have in common and how they differ, plus figure out the leftover issues and get some insight for future work 🧠💜
in this doc, we give an overview of mobility support solutions from the early results all the way to the newest proposals 🌸 along the way we also talk about the essential components of mobility support and look at the design space 🗺️ our goal is to share where the state of the art is right now and kick off an open discussion about the general direction for future mobility support 🫶
note that the solutions in this doc are proposed designs 📝 a bunch of them have been implemented, but only a few have actually been widely deployed on the Internet 🌍
2. Terminology 🎀
okay so this doc uses the following terms for the entities or functions that are required in mobility support 💅 you're expected to already know RFC 3753 "Mobility Related Terminology" [RFC3753] before you read this, bestie 📖
- Identifier: a stable value that can identify a mobile node 🪪 any unique value can be an Identifier as long as it's topologically and geographically independent, i.e., it stays the same when the mobile node roams around 🧳
- Locator: the IP address that shows the mobile node's current attachment point to the Internet 📍 it could be the IP address of the mobile node itself, or the IP address of the network entity that's currently serving the mobile node 🛰️
- Mapping: in this doc, mapping specifically means the mapping between a mobile's Identifier and its Locator 🔗
- Rendezvous Point (RP): the place where the mapping is held 🏠 other functions, like data forwarding, may also be co-located on the rendezvous point 📦
- Global Mobility Management: a system that keeps track of each mobile's reachability while it's moving, whether geographically or topologically, on a global scale 🌐
- Local Mobility Management: a system that keeps track of each mobile's reachability inside a topologically scoped local domain 🏘️ it keeps the mobile's local movements transparent to all entities outside the local scope 🫥
- Operator-Controlled Mobility Management: the mobile node itself is unaware of mobility management 🙈 instead, certain network entities, which are controlled by the network operators, do all the mobility-related signaling on behalf of the mobile node 🤖
- User-Controlled Mobility Management: the mobile node participates in the mobility management 🙋 typically, the mobile updates its reachability information after it changes locations, and it refreshes its reachability at a user-defined frequency ⏰
3. Basic Components in Mobility Support Protocols 💜
the basic question in Internet mobility support is how to send data to a moving receiver (a mobile, for short) 🏃♀️ note that here we don't distinguish between mobile nodes and mobile subnets 💅 we call the host that sends data to a mobile the Correspondent Node (CN) 📨 so to send data to a moving receiver M, the CN must have a way to get M's latest IP address (solution type-1), or be able to reach M using a piece of stable information, where "stable" means the info doesn't change as the mobile moves (solution type-2) 🎯
so among the existing solutions, a few are type-1, and most of them use DNS to give the CN the mobile's most current IP address 🌐 the rest are type-2, which must provide a function to reach the mobile's constantly changing location using the unchanged Identifier of the mobile that the CN knows 🧩 we can sum up all the mobility support solutions as basically having three core components 👑
- a stable Identifier for a mobile;
- a Locator, which is usually an IP address representing the mobile's current location; and
- a mapping between the two.
ok the tea ☕ different mobility support designs are basically just different ways of providing the mapping between the Identifiers and the mobiles' current IP addresses 🫖 in type-1 solutions, the stable Identifier of a mobile is its DNS name, the Locator is its current IP address, and the DNS server provides the mapping function 🗂️ in type-2 solutions, the CN has to be able to reach the mobile using the stable Identifier, so the Identifier is usually an IP address itself 🪄 either the network can dynamically find a path to the mobile, or the IP address leads to the mobile's "home" which knows its current Locator and can forward the CN's packets to it 🏡
all type-2 solutions face two shared issues 🚨 the first is how to do that forwarding job, since the original packet the CN sent has the mobile's "home address" as its destination 📦 the second is how to avoid triangle routing between the CN, the home location, and the mobile 🔺 bestie this is the stuff that makes or breaks a mobility design 💀
Part 1 of 8
4. Existing Mobility Support Protocols ✨
okay so now we're doing a little tour of the mobility support protocols that already exist 🧚 we're going roughly in time order, with a few closely related ones grouped together so it's easier to follow 💅 for each one we'll check how it handles those three basic mobility support components from the last section 🎀
Figure 1 is basically the guest list 🌸 it shows which protocol showed up and what year it was first proposed
+----------------+-----+---------------+-----+
| Protocol Name |Year | Protocol Name |Year |
+----------------+-----+---------------+-----+
| Columbia |1991 | TIMIP |2001 |
+----------------+-----+---------------+-----+
| VIP |1991 | M-SCTP |2002 |
+----------------+-----+---------------+-----+
| LSR |1993 | HIP |2003 |
+----------------+-----+---------------+-----+
| Mobile IP |1996 | MOBIKE |2003 |
+----------------+-----+---------------+-----+
| MSM-IP |1997 | Connexion |2004 |
+----------------+-----+---------------+-----+
| Cellular IP |1998 | ILNPv6 |2005 |
+----------------+-----+---------------+-----+
| HMIP |1998 | Global HAHA |2006 |
+----------------+-----+---------------+-----+
| FMIP |1998 | PMIP |2006 |
+----------------+-----+---------------+-----+
| HAWAII |1999 | BTMM |2007 |
+----------------+-----+---------------+-----+
| NEMO |2000 | WINMO |2008 |
+----------------+-----+---------------+-----+
| E2E |2000 | LISP-Mobility |2009 |
+----------------+-----+---------------+-----+
Figure 14.1. Columbia Protocol
this one was built for campus life 🏫 the [Columbia] protocol was originally designed to give mobility support on a campus. every wireless cell gets a router called a Mobile Support Station (MSS) 📡 it's the default access router for all the mobile nodes in that cell, and a mobile node uses the same IP address no matter which cell it's wandering into 💖 that address is an IP address derived from a special IP prefix, btw
each MSS keeps a tracking list of the mobile nodes currently in its cell 👀 it finds them by periodically broadcasting beacons. when a mobile hears a beacon from a new MSS, it replies to that MSS with a message containing its stable Identifier and its previous MSS. the new MSS is responsible for notifying the old MSS that the mobile has left its cell 🫶 every MSS also knows how to reach the other MSSs too (e.g., all MSSs could be in one multicast group, or a list of IP addresses of all MSSs could be statically configured for each MSS) 🌈
so when a CN sends a packet to a mobile node, it goes to the MSS nearest to the CN (MC) 🎯 that MSS either already has the mobile in the same cell and can deliver directly, or it broadcasts a query to all the other MSSs and gets a reply from the MSS (MM) that has the mobile. if it's the second case, MC tunnels the packet to MM, and MM finally delivers it to the mobile node 🚀
so the CN uses the Identifier to reach the mobile 🧡 this scheme largely avoids triangle routing, because the router next to the CN is mobility-aware. it can intercept the CN's data destined for the mobile and forward it to the destination MSS 🙌 and since a mobile keeps the same IP address no matter how it moves, mobility doesn't affect TCP connections 💜
An illustration of the Columbia Protocol is shown in Figure 2.
+---------+
| |
.------>| MSS |
| | |
| +---------+
| query
|
+--------+ query +--------+
| | -------------->| |
| MSS | <------------- | MSS |
| | reply | |
+--------+ ==============>+--------+
/\ data ||
|| ||
|| \/
+--------+ +---------+
| | | |
| CN | | MN |
| | | |
+--------+ +---------+
===>: data packets
--->: signaling packets
Figure 24.2. VIP
the Virtual Internet Protocol [VIP] has two big ideas 🦋 first, a packet carries both an Identifier and a Locator. second, the Identifier is an IP address that leads to the home network, where the mapping is kept 🏠
the IP header gets modified so that packets sent by a mobile can carry two IP addresses: a Virtual IP address (Identifier) and a regular IP address (Locator) 🤯 every time the mobile node changes location, it tells the home network its latest IP address. the mobile's virtual address never changes, so it can be used to support TCP connections no matter the mobility 🌸
to deliver data to a mobile, the CN first uses the mobile's Virtual IP address as the destination IP address. so the Locator is set to be the same as the Identifier 😌 the packet heads to the home network, and the Home Agent redirects it to the mobile's current location by swapping the regular IP destination address field for the mobile's current address 🧚
to cut down on triangle routing, the design lets CNs and routers learn and cache the Identifier-Locator mapping carried in packets from mobile nodes 👀 when a CN receives a packet from the mobile, it learns the mobile's current location from the regular IP source address field. the CN keeps that mapping and uses the Locator as the destination in future exchanges with the mobile 💅 similarly, if a router along the data path to a mobile sees that the mapping in the packet differs from the mapping it has cached, it changes the destination IP address field to its cached value 🙈 this router-caching solution is expected to increase the chance that packets for the mobile get forwarded straight to its current location. the cost is that all routers have to examine and cache all the mobile's Identifier-Locator mappings 💀
Figure 3 shows how the VIP Protocol works.
,---. +-------+
/ \ | CN |
( Router)<====| |
+---------+ // \ / | |
| | // `---' +-------+
| | ,---. //
| | / \ //
| Home |<--+ Router)
| Network | \ /
| | `-+-'\\
| | | \\ ,---. +-------+
| | | \\ / \=======>| |
| | +------( Router)<------+ MN |
| | \ / | |
| | `---' +-------+
+---------+
===>: data packet
--->: location update message
Figure 34.3. Loose Source Routing (LSR) Protocol
in the Loose Source Routing (LSR) Protocol [LSR], every mobile has a designated router called a Mobile Router that manages its mobility 🎀 the Mobile Router assigns an IP address (used as an Identifier) to each mobile it manages, and it announces reachability to those IP addresses 📣 another entity in the LSR design is the Mobile Access Station (MAS), which is how a mobile gets its connectivity to the Internet. the mobile node reports the IP address of its current serving MAS (Locator) to its Mobile Router 🫶
the CN uses the Identifier to reach the mobile node in the first place 🧭 if the CN and the mobile node are attached to the same MAS, the MAS just forwards packets between the two (in this case the CN is also mobile). otherwise, the packet from the CN is routed to the mobile's Mobile Router 🚦 the Mobile Router looks up the mappings to find the serving MAS of the mobile node, then inserts the loose source routing (LSR) option into the IP header of the packet, with the IP address of the MAS on it. that way the packet gets redirected to the MAS, which then delivers it to the mobile 💖 by this point the Locator of the mobile node is already included in the LSR option, so the two parties can talk directly by reversing the LSR option in the incoming packet 🔁
so the path for the first packet from the CN to the mobile is CN->Mobile Router->MAS->mobile node, and then the bidirectional path for the following packets is mobile node <->MAS<->CN ✨
triangle routing gets avoided by revealing the mobile's Locator to the CN in the LSR option 🙌
Figure 4 shows the basic operation of the LSR Protocol.
+---------+
| |
___________________| CN |
| | |
| +---------+
V /\
+-------+ ||
|Mobile | ||
|Router | ||
| | || Reversing LSR
+---+---+ ||
| \/
| +---------+ +----------+
| LSR Inserted | |<====>| |
+------------------->| MAS | | MN |
| |----->| |
+---------+ +----------+
-->: first data packet
==>: following data packets
Figure 44.4. Mobile IP ✨
okay so the IETF started working on mobility support pretty much right after those three protocols 🦋 The first version of the Mobile IP standard came out in 1996. Then they made Mobile IPv4 [RFC3344] and Mobile IPv6 [RFC3775] in 2002 and 2004, respectively. Mobile IPv4 got a glow-up in 2010 with [RFC5944] 💅 And in 2009, Dual-Stack Mobile IPv4 [RFC5454] was standardized, so a dual-stack node can use both IPv4 and IPv6 home addresses and move between IPv4 and dual-stack network infrastructures. iconic 🌈
ngl the three documents differ in the details, but the big-picture design is pretty much the same 🫶 Here we use Mobile IPv6 as our example. Every mobile node has a Home Agent (HA), and it gets its Home Address (HoA) from that HA. The HoA is the Identifier 🆔 The mobile node also picks up its Locator, a Care-of Address (CoA), from its current access router. Whenever the mobile node gets a new CoA, it sends a Binding Update message to tell the Home Agent about it. Conceptually, Mobile IPv6 looks a lot like the VIP Protocol 🧚 The mobile's HoA is like the Virtual IP Address in VIP, and the CoA is like the regular IP address.
The CN uses the mobile's HoA as the destination IP address when it sends data to a mobile. The packets get forwarded to the Home Agent, and then the Home Agent encapsulates them to the mobile node's CoA based on the mapping 📬
To cut down on triangle routing 📐, the CN keeps the mapping between the mobile's HoA and CoA too, if it supports Route Optimization. That means the CN can encapsulate packets to the mobile directly, skipping the Home Agent entirely 🚀 Just note that in this case, the mobile also has to update its CoA with the CNs. periodt 💜
Figure 5 shows the data path of Mobile IPv6 without Route Optimization 👀
+---+-----+
|HoA|DATA |
+---+-----+ +-------+
+----------------------| CN |
| +------------------->| |
| | +-------+
| |
V |
+--------+
| Home | Mapping: HoA <=> CoA
| Agent |
| |
+--------+
|| /\
|| || +-------+
|| +====================| |
|| | MN |
+=======================>| |
+-----+---+---+ +-------+
|DATA |HoA|CoA|
+-----+---+---+
==>: Tunnel
-->: regular IP
Figure 54.5. HMIP 🌸
okay this one is giving efficiency 😭 Hierarchical Mobile IP (HMIP) [RFC5380] is a simple extension to Mobile IP. It makes Mobile IP perform better by handling mobility within a local region locally, so the moves stay nearby instead of going all the way home. It adds a level of hierarchy in this way: a Mobility Anchor Point (MAP) takes care of a mobile's movements inside a local region. Simply speaking, the MAP is the local Home Agent for the mobile node 🏠
If the mobile node supports HMIP, it gets a Regional CoA (RCoA) and registers it with its Home Agent as its current CoA. The RCoA is the Locator for the mobile in Mobile IP, and it's also the regional Identifier used in HMIP 🫧 At the same time, the mobile grabs a Local CoA (LCoA) from the subnet it's attached to. When it roams inside the region, the mobile only updates the MAP with the mapping between its RCoA and LCoA. This usually makes handoffs better, since the round-trip time between the mobile and the MAP is shorter than the delay between the mobile and its HA ⚡ It also takes some load off the Home Agents because they get fewer updates.
4.6. FMIPv6 🦋
Fast Handover for Mobile IPv6 (FMIPv6) [RFC5568] is another extension to Mobile IP, and its whole thing is cutting down the Binding Update latency as well as the IP connectivity latency 🏃♀️ It's not a fully fledged mobility support protocol, though. Its only purpose is to optimize the performance of Mobile IP. no more, no less 💅
This goal is achieved with three mechanisms. First, a mobile node can detect that it has moved to a new subnet while it's still connected to the current one, because it gets the new access point and the corresponding subnet prefix information 👀 Second, a mobile node can formulate a prospective New Care-of Address (NCoA) while it's still on the previous link, so the address is ready to use right after it attaches to the new subnet link 🎀 Third, to reduce the Binding Update interruption, FMIP specifies a tunnel between the Previous Care-of Address (PCoA) and the NCoA. After the handoff, the mobile node sends a Fast Binding Update to the previous access router (PAR), and the PAR starts tunneling packets with PCoA as the destination over to the NCoA. Those packets would've been dropped if the tunnel weren't set up 😭 In the reverse direction, the mobile node also tunnels packets to the PAR until it finishes the Binding Update process. Until then, it can only use the PCoA, because the binding in the HA or the correspondent nodes may not have been updated yet 🫶
4.7. NEMO 🚢
it's conceivable to have a whole group of hosts moving together 🚆 Think ships, trains, or airplanes that might host a network with multiple hosts inside. Because Mobile IP handles mobility per host, it's not efficient for these scenarios. So Network Mobility (NEMO) [RFC3963] came along. It's a backward-compatible extension to Mobile IP, introduced in 2000 to give efficient support for network mobility 🌈
NEMO brings in a new entity called a Mobile Router (note that this is different from the "Mobile Router" in the LSR Protocol 🙈). Every mobile network has at least one Mobile Router. A Mobile Router is similar to a mobile node in Mobile IP, but instead of having a single HoA, it has one or more IP prefixes as the Identifier. After it sets up a bidirectional tunnel with the Home Agent, the Mobile Router sends its mobile network's prefixes (the Mobile Prefixes) through the tunnel to the Home Agent 📦 The Mobile Prefix of a mobile network doesn't leak to its access router. The access router never knows it can reach the Mobile Prefixes via the Mobile Router. The Home Agent then announces the reachability to the Mobile Prefix. Packets to and from the mobile network flow through the bidirectional tunnel between the Mobile Router and the Home Agent on their way to their destinations ✨ And the best part is that mobility is transparent to the nodes in the moving network 🧚
4.8. Mobility Support Using Multicast in IP (MSM-IP) 💜
MSM-IP [MSM-IP] stands for Mobility Support using Multicast in IP 🎀 As the name suggests, MSM-IP uses IP multicast routing for mobility support. In IP multicast, a host can join a group no matter which network it's attached to, and it receives packets sent to the group after its join. So mobility is naturally supported in domains where IP multicast is deployed 🌸 Note that MSM-IP doesn't address whether supporting mobility through IP multicast is feasible. It just shows that IP multicast could provide mobility support once/if IP multicast is universally deployed. a vision, bestie 🔮
MSM-IP [MSM-IP] gives each mobile node a unique multicast IP address as the Identifier 🆔 When the mobile node moves into a new network, it starts a join to its own address. That makes the multicast router in that subnet join the multicast distribution tree. Whoever wants to talk to the mobile node just sends data to the mobile's multicast IP address, and the multicast routing takes care of the rest 🪄
Note that, because of how multicast routing works, the mobile node can have the new multicast router join the group and cache packets in advance, before it detaches from the old one. That results in a smoother handoff 🫧
4.9. Cellular IP, HAWAII, and TIMIP ✨
okay so this group of protocols all share the same big idea 🦋 they each set up a host route for every mobile in the local domain. The mobile keeps a stable IP address as long as it stays inside that local domain, and that address works as a regional Identifier. The gateway router of the local domain uses this Identifier to reach the mobile node. All three are meant to pair with Mobile IP as a local mobility management protocol. We're doing them together because it's way easier to see how they differ when you compare them side by side 💜
Cellular IP [CIP] handles local mobility inside a network made of Cellular IP routers 🌸 A mobile reports the IP address of the local network's gateway as the RCoA to its Home Agent, and it keeps its locally assigned IP address (the regional Identifier) while it roams around the Cellular IP network. The routers watch the packets coming from mobile nodes and keep a distributed, hop-by-hop reverse path for each one. Cellular IP borrows paging from cellular networks to track where each mobile is. Idle mobile nodes send dummy packets to the gateway router pretty infrequently so they can refresh their reverse paths in the routers 🍓 An outdated path isn't cleared explicitly after the mobile moves. Instead, the routers flush it once the paging timer runs out before the next dummy packet shows up. To keep paging costs down, only a subset of the routers sets up a reverse path for idle mobile nodes. so efficient, honestly 😭
When a packet from the CN reaches the gateway, the gateway starts a controlled flooding query 🧚 If a router already knows where to forward a packet, it forwards it right away. If it doesn't, it sends the packet out all of its interfaces except the one it came in on. Because of the paging technique, this doesn't turn into a broadcast 🙈 Once the mobile gets the query, it answers with a route-update message to the gateway, and then a much more precise reverse path gets maintained by all the routers along the data path. The gateway uses that path to forward packets from the CN to the mobile. The timer for this precise data path is way shorter than the paging timer. The reason is to avoid sending duplicate data packets to multiple places if the mobile moves during the data communication 💅
Handoff-Aware Wireless Access Internet Infrastructure (HAWAII) [HAWAII] is also all about efficient local mobility support 🎀 Unlike Cellular IP, the route between the gateway router and the mobile is always maintained. When the mobile moves, HAWAII changes the route by installing a host-based forwarding entry on the routers along the shortest path between the mobile's old and new base stations. A longer, suboptimal routing path can end up getting built (e.g., gateway router->old base station->new base station->mobile). Or a new sub-path can be set up between the mobile and the cross-over router instead 🦋 The cross-over router is the router sitting at the intersection of two paths: one between the gateway and the old base station, and one between the old base station and the new base station. In HAWAII, the mobile only sends refresh messages to its base station now and then. The base station, along with the other routers, handles the path maintenance from there ✨
TIMIP [TIMIP], which stands for Terminal Independent Mobile IP, basically combined the designs of Cellular IP and HAWAII 👑 On one hand, it refreshes the routing paths with dummy packets when the mobile node is idle. On the other hand, a handoff within a domain changes the routing tables in the routers. Also, the IP layer is coupled with layer 2 handoff mechanisms, and special nodes can act as Mobile IP proxies for legacy mobiles that don't support Mobile IP 🫶 So as long as the mobile roams within the domain, a legacy node gets the same degree of mobility support as a Mobile-IP-capable node. iconic 🌈
4.10. E2E and M-SCTP 💖
E2E (End-to-End) communication [E2E] gets its name from its end-to-end architecture, and it's the first proposal to use the existing DNS service to track a mobile node's current location 🧚 The stable Identifier here is the domain name of the mobile. The mobile uses Dynamic DNS to update its current IP address in DNS servers. To keep an ongoing TCP connection unaffected by mobility, a TCP Migrate option was introduced. It lets both ends replace the IP addresses and ports in the TCP 4-tuple on the fly 🔥 So the CN can query DNS to get the mobile's current Locator, and once the TCP connection is up, the mobile takes charge of updating its Locator for that session. main character energy, literally 👑
Inspired by E2E, Mobile Stream Control Transmission Protocol (M-SCTP) [M-SCTP] was proposed in 2002 🌸 It works similarly: it uses Dynamic DNS to track mobile nodes, and it lets both ends add and delete the IP addresses used in Stream Control Transmission Protocol (SCTP) associations during a move 🦋
4.11. Host Identity Protocol 🔐
The Host Identity Protocol (HIP) [RFC5201] gives each host an Identifier made of cryptographic keys, and it adds a brand new Host Identity layer between the transport and network layers 💜 Host Identities, which are basically public keys, are used to identify the mobile nodes. IP addresses are only used for routing purposes. To reuse existing code, a Host Identity Tag (HIT) gets used in transport and other upper-layer protocols. The HIT is a 128-bit hash value of the Host Identity 🍓
HIP can use DNS as the rendezvous point that holds the mappings between HITs and IP addresses 🎀 By default, though, HIP uses its own static infrastructure Rendezvous Servers, because it expects better rendezvous service that way ✨ Each mobile node has a designated Rendezvous Server (RVS) that tracks where the mobile node currently is. When a CN wants to talk to a mobile node, it queries DNS with the mobile node's HIT to get the IP address of that node's RVS, and then it sends out the first packet. After getting this first packet, the RVS relays it to the mobile node. From there, the mobile node and the correspondent node can start talking on the direct path 🧚 If the mobile node moves to a new address, it tells the CN by sending HIP UPDATE with a LOCATOR parameter that shows its new IP address (Locator). It also updates the mapping in the RVS at the same time 💅
4.12. MOBIKE 🌊
IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555] is an extension to Internet Key Exchange (IKEv2) that adds support for mobility and multihoming 💖 Its main purpose is to let roaming devices keep their existing IKE and IPsec Security Associations (SAs) even when their IP addresses change 🦋 MOBIKE's mobility support lets both parties move, but it doesn't offer a rendezvous mechanism. In other words, simultaneous movement of both parties is not supported 🙈
In MOBIKE, both parties can have a set of addresses, and the party that initiated the IKE_SA is the one who decides which pair of addresses gets used 👑 During the session, if the initiator wants to change addresses because it moved, it updates the IKE_SA with the new IP addresses and also updates the IPsec SAs tied to this IKE_SA. Then it sends an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification to the other party. The responder checks its local policy and updates the IP addresses in the IKE_SA using the values from the IP header. Then it replies to the initiator with an INFORMATIONAL response. If it wants to, it can start a return routability check, and it also updates the IPsec SAs tied to this IKE_SA 🫶
MOBIKE isn't a fully fledged mobility protocol, and it doesn't plan to become one 🥺 Still, through IPsec tunnel mode, MOBIKE partially supports mobility, since it can dynamically update the tunnel endpoint addresses ✨
4.13. Connexion and WINMO ✈️
Connexion [Boeing] was a mobility support service from Boeing that used BGP to support network mobility 🌈 Every mobile network gets assigned a /24 IP address prefix (its stable Identifier), and the CN uses that Identifier to reach the moving network. That means the global routing system is responsible for finding a path to the mobile network 💜 When an airplane moves between its access routers on the ground, it withdraws its prefix from the previous access router and announces the prefix through the new access point. As a result, the plane's location change gets propagated to the rest of the world. But if the number of moving networks gets large, the amount of BGP updates grows right along with it, which causes severe global routing dynamics 💀
WINMO [WINMO] (short for Wide-Area IP Network Mobility) came out in 2008 to fix the routing update overhead problem of Connexion 🍓 Like Connexion, WINMO gives each mobile network a stable prefix. But WINMO uses two new approaches, and with them it can cut the BGP update overhead for mobile networks by orders of magnitude compared to Connexion 🎀 First, WINMO uses various heuristics to shrink the propagation scope of routing updates caused by mobile movements. The side effect is that not every router may know every mobile's current location. Dealing with that problem led to the second, more fundamental approach: WINMO borrows the basic idea from Mobile IP and gives each mobile network a "home" 🏠 WINMO assigns each mobile network a prefix out of a small set of well-defined Mobile Prefixes. These Mobile Prefixes are announced by a small set of Aggregation Routers, which also keep track of where each mobile network currently is. So these Aggregation Routers play a similar role to Home Agents in Mobile IP, and they can be counted on as a last resort for reaching mobile networks globally 🧚
To prevent frequent Interior Border Gateway Protocol (iBGP) routing updates when mobile networks move within an Autonomous System (AS), WINMO also introduces a Home Agent for the Mobile Prefixes 🫶 Only a Designated BGP-speaking Router (DBR) acts as the origin of Mobile Prefixes. Mobile networks always update the addresses of their access routers (intra-AS Locators) with the DBR, which is similar to the binding updates in Mobile IP. So packets destined for mobile networks get forwarded to the DBR once they enter the border of an AS, and then the DBR tunnels them to the current locations of the mobile networks 💅
A new BGP community attribute gets defined to fix the triangle-routing problem that the DBR causes 🔥 This attribute includes the mobile network's intra-AS Locator in each packet. Using it, the border routers of the AS can tunnel packets directly to the mobile network, no detour needed 🌸 slay 💖
4.14. ILNPv6 ✨
okay so ILNPv6 [ILNP] is short for Identifier-Locator Network Protocol for IPv6 🦋 the packet header was deliberately made to look a lot like the IPv6 header, which is so smart 🫶 basically it splits an IPv6 address into two halves: the high-order 64 bits are the Locator and the low-order 64 bits are the Identifier. the Identifier names a host (not an interface!) and upper-layer protocols like TCP and FTP use it. the Locator is the part that changes when the mobile node moves, and one Identifier can be linked to a whole set of Locators 💜
it also needs some new DNS resource records (RRs), and the two big ones are I (Identifier Record) and L (Locator Record) 🌸 just like today's Internet, the CN asks DNS about the mobile's domain name to figure out where to send the packet. while the mobile is moving, it uses Secure Dynamic DNS update so the Locator values in DNS stay current, and it also sends Locator Update messages to the CNs it's currently talking to 🧚 as an optimization, ILNPv6 supports soft-handoff, which lets it use multiple Locators at the same time for a smooth transition ✨ and yes, it supports mobile networks too 💅
4.15. Global HAHA 🌈
Global Home Agent to Home Agent (HAHA) [HAHA] was first proposed in 2006 as an extension to Mobile IP 🎀 its whole goal is to kill the triangle-routing problem in Mobile IP and NEMO by spreading multiple Home Agents around the globe 🌍 all the Home Agents join an IP anycast group and form an overlay network, and the same home prefix gets announced by every one of them from different locations. each mobile node can register with whichever Home Agent is closest to it 💖
when a Home Agent H accepts the binding request from a mobile node M, it becomes the primary Home Agent for M and tells all the other Home Agents about the binding [M, H]. this keeps the binding information databases for all the mobiles synced across every Home Agent 🫶 when the mobile moves, it can switch its primary Home Agent to whichever one is now closest to it 🦋
so a correspondent node sends packets to the mobile's Home Address 😭 because of anycast routing, those packets land at the nearest Home Agent. that Home Agent encapsulates them toward the IP address of the primary Home Agent currently serving the mobile node, and that one delivers them to the mobile node after stripping off the encapsulation headers ✨ going the other way works exactly like Mobile IP does 💅 and if the Home Agents are spread out widely, the triangle-routing problem gets mostly fixed without Route Optimization. no notes 👑
the data flow in Global HAHA is shown in Figure 6 🍓
+------+ +------+ +-----+
| HA |-------------| HA | | |
| | | | | CN |
+--+---+ +------+++----+ +-----+
| | || /\
| | || ||
| | || ||
| | || ||
+--+---+------+ || ||
| |<==============+ ||
| HA |==============================+
+-++---+
|| /\
\/ ||
+---++-+ ===>: data flow
| | ----: HA overlay network
| MN |
+------+Figure 6 💜
4.16. Proxy Mobile IP 🧚
Proxy Mobile IP (PMIP) [RFC5213] showed up in 2006 for mobile network operators who wanted mobility handled inside their own network instead of on the devices, with tighter control over it 🎀 the mobility is totally transparent to the mobile devices, and legacy IP devices get it too. PMIP adds two new kinds of network nodes, the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG), and together they support mobility inside an operator's network with zero action from the mobile node 💖
the LMA acts as a local Home Agent and hands out a local Home Network Prefix for each mobile node. that prefix is the mobile node's Identifier inside the PMIP domain 🌸 the MAGs watch for attach and detach events from the mobile node and send Proxy Binding Updates to the LMA on the mobile node's behalf during a handoff. once the binding succeeds, the LMA updates the mobile node's Proxy-CoA (its Locator in the PMIP domain) with the IP address of the MAG currently serving it ✨ then the MAG copies the mobile node's local Home Link by advertising the local Home Network Prefix in Router Advertisement 🦋 so when the mobile node roams around the PMIP domain, it always gets its local Home Prefix and thinks it's still on its local Home Link, which is honestly iconic 👑 inside the domain it's reached by the Identifier, and the LMA tunnels packets to it based on the mapping 🫶
4.17. Back to My Mac 💻
Back to My Mac (BTMM) [RFC6281] is an engineering approach to mobility support that has been around since 2007 with the Mac OS Leopard release 🍎 every user gets a MobileMe account (which includes BTMM service), and Apple, Inc. runs the DNS service for all BTMM users. the reachability info for a user's machine gets published in DNS 🌈
a mobile uses secure DNS update to refresh its current location dynamically 💅 each host generates an IPv6 Unique Local Address (ULA) [RFC4193] at boot, and that gets stored in the DNS database as its topologically independent Identifier 🧚 the host's current IPv4 address (which is the IPv4 address of the NAT box if the host is behind a NAT) goes into an SRV resource record [RFC2782], along with a transport port number needed for NAT traversal 💖 every node sets up a long-lived query (LLQ) session with the DNS server so the server can instantly tell each node when its answer changes ✨ a host uses its Identifier in transport protocols and applications, and it uses UDP/IPv4 encapsulation to deliver data packets based on what it learned from the SRV RR 🦋
quick clarity moment 🎀 the Locator here is the IPv4 address plus the transport port number, and the IPv6 address is only for identification. honestly it could be any kind of Identifier (like a domain name) 💜 BTMM just picked IPv6 addresses so its implementation could reuse existing code 🫶
BTMM is used by millions of subscribers right now and it's simple and easy to deploy 🌸 however, current applications use BTMM in a "stop-and-reconnect" fashion 😭 it's still unclear how well BTMM can keep up continuous communication while hosts are moving, like for voice calls 🙈
Figure 7 shows the basic architecture of BTMM 🍓
DDNS update +--------+ DDNS update
+--------------->| |<-------+
| | DNS | |
| LLQ | | LLQ |
| +---------->| |<----+ |
| | | | | |
| | +--------+ | |
| | | | +---------+
| V +---+--+----+ | |
++-------+ | +-------| |
|Endhost1| Tunnel | NAT +------>|Endhost2 |
| |<=====================================>| |
+--------+ | | | |
+-----------+ +---------+Figure 7 💜
4.18. LISP-Mobility 🌺
LISP-Mobility [LISP-Mobility] is a relatively new design 🆕 its designers want to use the functions and services of the Locator/ID Separation Protocol (LISP) [LISP], which was built for Internet routing scalability, to support mobility too 🧠 conceptually it might seem similar to some protocols we've already covered, like ILNPv6 and Mobile IP 👀 Lightweight Ingress Tunnel Router and Egress Tunnel Router functions run on each mobile node, and every packet to and from the mobile node gets processed by those two router functions (so the mobile node looks like a LISP site) ✨
each mobile node gets a static Endpoint ID plus a preconfigured Map-Server 🎀 when it roams into a network and gets a new Routing Locator, it updates its Routing Locator set in the Map-Server, and it also clears the cached Routing Locator in the Ingress Tunnel Routers or Proxy Tunnel Routers of the CNs 💅 that means the CN can always find the mobile node's up-to-date location by resolving its Endpoint ID, either because it asked itself or because it got a notification from the mobile node about a stale cache 🦋 the data always travels the shortest path 🚀 and note that both Endpoint IDs and Routing Locators are basically IP addresses 💖
5. Different Directions towards Mobility Support 🧭
After studying various existing protocols, we identified several different directions for mobility support 🌈 okay, next up we get into those directions 👑
5.1. Routing-Based Approach versus Mapping-Based Approach
okay so bestie, every existing mobility design basically falls into one of two big buckets 🦋. Bucket one is doing mobility through dynamic routing. The mobile keeps its IP address no matter where it wanders, so that one address does double duty: it identifies the mobile AND it's how packets find it 💖. That means there's no explicit mapping function. Instead, the routing system has to keep track of every move and reflect the mobile's current position in its routing table, so that packets carrying that stable receiver address can land in the right place at any given moment ✨.
Routing-based designs have two sub-classes 🌸. In the broadcast-based one, either the mobile's location gets actively broadcast to the whole network, or a proactive broadcast query is needed to get the location (Columbia and Connexion, for example). In the path-based one, the routing system maintains a host-based path instead (Cellular IP, HAWAII, and TIMIP, for example).
Supporting mobility through dynamic routing is conceptually simple 💅, and it can give robust and efficient data delivery, as long as the routing system can keep up with the mobile movements. BUT, because either the whole network has to be told about every movement by every mobile, or a host-based path has to be kept for every mobile host, this approach is only feasible in small-scale networks with a small number of mobiles. It does not scale well in large networks or for a large number of mobiles 😭.
The second approach is to provide a mapping between a mobile's stable Identifier and its dynamically changing IP address 🧚. Instead of notifying the world on every movement, the mobile only needs to update a single binding location about its location changes. Here's the catch: if one level of indirection at the IP layer is used, like in Mobile IP, it has a potential side effect of introducing triangle routing 🙈. Otherwise, if the two end nodes are aware of each other's movement, both ends have to support the same mobility protocol.
Then there's the third case, where protocols combine the two approaches to keep the pros and get rid of some of the cons of each 👑. WINMO is a typical example of this.
Figure 8 shows how the existing protocols are classified according to all of that 🎀.
+---------------+-------------------------------------------+
| | VIP, LSR, Mobile IP, HMIP, NEMO, E2E, |
| Mapping-based | M-SCTP, ILNPv6, HIP, FMIP, PMIP, |
| | BTMM, GLOBAL HAHA, LISP-Mobility |
+---------------+-------------------------------------------+
| | Columbia, Connexion |
| Routing-based +-------------------------------------------+
| | Cellular IP, HAWAII, TIMIP, MSM-IP |
+---------------+-------------------------------------------+
| Combination | WINMO |
+---------------+-------------------------------------------+
Figure 85.2. Mobility-Aware Entities
Okay, now let's talk about who actually needs to be mobility-aware 🎀, because this is a HUGE design choice. There are four parties that might be involved in a conversation with a mobile: the mobile itself, the CN, the network, and the Home Agent or its equivalent (the extra component in the existing IP network that holds the mapping) 🧚. We're mainly focusing on the mapping-based approach here.
Design choice one is to hide the mobility from the CN 🙈. The idea is that the CN might be a legacy node that doesn't support mobility at all. In this setup, the IP address used as the mobile's Identifier points to the Home Agent or its equivalent, which keeps track of where the mobile currently is. When a correspondent node wants to send packets to a mobile node, it puts the mobile's Identifier in the destination field of the IP header 💅. The packets get delivered to wherever the mapping information is kept, and then they're forwarded to the mobile's current location, either through encapsulation or destination address translation. Mobile IP and most of its extensions, along with several other protocols, fall into this design.
Design choice two is to hide the mobility from both the mobile AND the CN 🌸. This one is based on a more conservative assumption, that neither the mobile nor the CN supports mobility. Protocols like PMIP and TIMIP take this route. The operations here look a lot like the first category, but the big difference is that the mobility-related signaling (like sending the update Locator to the Home Agent) is handled by entities in the network instead of by the mobile itself. So the mobile just blissfully assumes it's always in the same subnet 😭✨.
Design choice three is to let both the mobile AND the CN be mobility-aware 💖. The network isn't aware of the mobility at all, and no extra component is needed. As more and more mobile devices connect to the Internet (why hide mobility from them?), this design is looking more and more appealing 👑. One common approach here is to use DNS to keep track of mobiles' current locations. Mobiles use dynamic DNS updates to keep their DNS servers updated with where they are now. This re-uses the DNS infrastructure, which is ubiquitous and quite reliable, and it makes the mobility support protocol simple and easy to deploy 🦋. Protocols like E2E, ILNP, and BTMM fall into this design. HIP also goes in this category, even though it adds special-purpose rendezvous servers to the network to take over the role of DNS, because both the mobile and the CN are still mobility-aware 🫶.
Figure 9 shows the three categories of protocols 🌈.
+-------------+----------------------------------+
| Design 1 | VIP, LSR, Mobile IP, HMIP, NEMO, |
| | Global HAHA |
+-------------+----------------------------------+
| Design 2 | PMIP, TIMIP |
+-------------+----------------------------------+
| Design 3 | E2E, M-SCTP, ILNPv6, HIP, |
| | BTMM, LISP-Mobility |
+-------------+----------------------------------+
Figure 95.3. Operator-Controlled Approach versus User-Controlled Approach
So right now, cellular networks provide the largest operational global mobility support 📱✨. They bundle together device control, network access control, and mobility support in one service model. The huge success of the cellular market is a loud sign that this model is viable and will probably keep going for the foreseeable future 💅. That's why there's a strong advocate in the IETF who wants to keep the cellular way of handling mobility: instead of letting mobile devices take part in the mobility-related signaling themselves, the network entities deployed by operators should take care of all of the signaling for mobility support 🎀. A typical example of this direction is Proxy Mobile IP, where the LMA works together with MAGs to keep the mobile reachable using its Home Prefixes, as long as it roams within the same provider's domain.
One main reason for this approach is backward compatibility 🫶. Since the mobile doesn't have to participate in the control signaling, no changes are needed on mobile nodes, so they can stay simple, and all the legacy nodes can get the same level of mobility services as the latest mobile devices. According to 3G vendors and operators, transparent mobility support is a key aspect for success, based on what they've learned from their deployment experience 🧚.
On the other hand, most of the mobility support protocols surveyed in this document only focus on mobility support, assuming the mobiles have already obtained network access 🌸. Mobile nodes typically update their locations themselves to rendezvous points chosen by the users, and, of course, only nodes implementing one of these solutions can benefit from mobility support 🙈. BUT this class of protocols does give users and mobile devices more flexibility and freedom 🦋. For example, they can choose whatever mobility services are available, as long as their software supports that protocol, and they can also tune the parameters to get the services that suit them best 💖.
5.4. Local and Global-Scale Mobility
Mobility management work can also be split into two categories by scale: local mobility management and global mobility management 🗺️✨.
Global mobility management is typically supposed to support the mobility of an unlimited number of nodes across an area that is geographically AND topologically large 🌍. So it pays a lot of attention to scalability. It also tries to avoid a single point of failure, for availability's sake 💅.
Local mobility management, on the other hand, is designed to work together with global mobility management 🫶. It focuses more on performance issues, like handoff delay, handoff loss, local data path, and so on. Because it's typically used on a small scale with a not-so-large number of mobile nodes, designers can sometimes use fine-tuned mechanisms that don't scale to large networks (like host routes) to improve performance 🎀. As a side effect, the number of location updates that mobile nodes send to their global rendezvous points is substantially reduced. So local mobility management also helps the scalability of global mobility management 👑.
One problem with local mobility management is that it often needs infrastructure support, like MAGs in PMIP or MAPs in HMIP. These kinds of local devices are essentially required in all small domains, and that can be a huge investment 😭.
Still, having mobility management at two scales makes it possible for designers to build protocols that fit specific user requirements 🌈. It also allows gradual deployment of local enhancements without losing the ability to roam globally 🦋. The coexistence of the two seems to be the right choice for the foreseeable future 💖.
Figure 10 shows how the studied protocols are classified by their serving scale 🧚.
+-----------+-----------------------------------------+
| | VIP, LSR, Mobile IP, NEMO, E2E, M-SCTP, |
| Global | HIP, ILNPv6, Connexion, WIMO, BTMM, |
| | MSM-IP, Global HAHA, LISP-Mobility |
+-----------+-----------------------------------------+
| Local | Columbia, HMIP, FMIP, Cellular IP, |
| | HAWAII, TIMIP, PMIP |
+-----------+-----------------------------------------+
Figure 105.5. Other Mobility Support Efforts
Okay so even after all that mobility tour 🧚, the list of mobility protocols is NOT exhaustive 💅 there's always more out there, bestie 🌈
The General Packet Radio Service (GPRS) Tunneling Protocol [GTP] is a network-based mobility support solution that's super widely used in cellular networks 📱 Its implementation only involves the Gateway GPRS Support Node (GGSN) and the Serving GPRS Support Node (SGSN) ✨ It lets end users of a Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS) network move from place to place while staying connected to the Internet as if they were still at one location, the GGSN 🦋 It does this by carrying the subscriber's data from the subscriber's current SGSN to the GGSN that's handling the subscriber's session. Lowkey it's the non-IETF cousin of PMIP, with GGSN acting like LMA and SGSN acting like MAG, respectively 🫶
There's also work on application-layer mobility support, most notably SIP-based mobility support [ALM-SIP] 👀 SIP was originally designed as an application signaling protocol for multimedia, and later researchers noticed its potential for mobility support too. When the mobile starts a session with CN, the normal SIP-signaling procedure runs to set it up. When the mobile moves to a new network while the session is ongoing, it sends a RE-INVITE message with the existing session but reveals the new IP address to the CN. The home SIP server also gets updated with the mobile's latest location after the move. BUT the SIP-based approach cannot maintain TCP connections when the mobile's IP address changes 💀
A lot of enhancements to Mobile IPv6 Route Optimization have also been developed. A comprehensive taxonomy and analysis of these efforts can be found in [RFC4651] 📚✨
6. Discussions 🎀
In the last section, we talked about the different directions towards mobility support. Now we're turning our attention to spotting both new opportunities and remaining open issues in providing global-scale mobility support for an unlimited number of online mobility devices 🌸 We're not trying to identify the solutions to these issues. The goal is to share our opinions and kick off an open discussion 🫶
6.1. Deployment Issues
Among the various protocols we discussed in this document, few have been deployed in commercial networks. There are several reasons for this situation 🙈
First, although the research community started developing mobility support protocols 20 years ago, the number of mobiles has only soared in recent years. Hence, operators didn't see the incentive to deploy mobility support protocols several years back. As of today, the number of mobiles is still growing by leaps and bounds, and there's enough user demand for operators to seriously consider deploying mobility support protocols 📈🔥
Second, the complexity of most mobility support protocols gets in the way of implementation and, therefore, deployment in commercial networks 😭 The complexity comes from multiple aspects. One is the optimizations on performance. The other is the problem with the use of security protocols such as IPsec and IKE. The discussions regarding these two problems are still ongoing in the MEXT Working Group. Some researchers argue that the research community should design a "barely work" version of a mobility support protocol first, without considering nice performance features and complex security mechanisms, roll it out in the real world, and improve it afterwards. However, there are different views on what the essential features are and which security mechanisms are better 🤷♀️
Third, almost all the mobility support protocols assume that mobile nodes have network connectivity anywhere, anytime. In reality, though, this isn't always the case. Nevertheless, wireless access is showing up in more and more places, and it's foreseeable that in the near future, the coverage of wireless access in different forms (WiFi, Wimax, 3G/4G) will be ubiquitous 🌈📶
6.2. Session Continuity and Simultaneous Movements
For users to benefit from mobility support, it's important to keep TCP sessions uninterrupted by the mobility 💖 If the sessions are short (e.g., web browsing), the probability is high that they finish before the handover happens. Even if a short TCP session does get interrupted by the handover, the cost is usually low (e.g., refreshing the web page) 🙃 However, if the TCP sessions are typically long (e.g., downloading large files and voice calls), the interruptions during the handover become unacceptable 😤
It's hard to predict tomorrow's applications, but most mobility support protocols try to keep sessions up during movements ✨ For routing-based protocols, session continuity isn't a problem, since the IP address of the mobile never changes 🦋 For other protocols, either a stable IP address (e.g., HoA) or an equivalent (e.g., HIT) is used in the transport layer so that the mobility is hidden, or TCP is modified so that both ends can change IP addresses while keeping the established session (e.g., E2E) 🧩
Another concern is supporting simultaneous movements. In some scenarios, only one end is mobile and the other end is always static. Moreover, the communication between the two is always initiated by the mobile end. A lot of applications today fall into this category 📱 Typically, the server side is static and the client is mobile, and usually the client contacts the server first. So in these scenarios, supporting simultaneous movements isn't a requirement 😌 However, in other scenarios, both ends may be moving at the same time. For example, during a voice call, two mobile nodes may experience handovers simultaneously 📞😱 In this case, a rendezvous point is necessary to keep the current locations of the mobiles so they can find each other after a simultaneous movement. Besides, if a static server wants to push information to a mobile client, a rendezvous point is also required 📍
It's clear that the number of mobile devices is rapidly growing, and more mobiles are going to provide content in the near future 📈 Hence, the simultaneous-movement scenarios are considered important. In fact, almost all the mobility support protocols are equipped with rendezvous points, either by adding dedicated components or by leveraging the existing DNS systems 🧚
6.3. Trade-Offs of Design Choices on Mobility Awareness
The mobility awareness at two communicating ends is closely related to the backward-compatibility problem 👯 The Internet has been running for more than two decades, and it's grown so large that it's impossible to upgrade the whole system overnight 🌙 As a result, a mobility support system designer can't overlook this problem either: how do you decide the mobility awareness in the protocol design, and how important is backward compatibility? 🤔
In the following text, we discuss the trade-offs of the design choices mentioned in Section 5.2 💅
The advantage of the first design choice is that the mobile doesn't lose the ability to communicate with legacy nodes while roaming around, i.e., the mobile can benefit from unilateral deployment of mobility support 🙌 Another potential advantage is that the static nodes don't need to be bothered by the mobility of the mobiles, which saves resources and could be desirable if the CN is a busy server 🖥️ The disadvantage of this design is also well known: it introduces triangle routing, which significantly increases the delays in the worst cases 😩 There are ways to remedy the problem, e.g., Route Optimization in Mobile IP if a CN is mobility-capable, and distribution of Home Agents as Global HAHA does, at the expense of increasing complexity 🌀
The second design caters to the inertness of the Internet (and the users) by keeping everything status quo from the user's point of view 🛋️ It's like the cellular network, with the smart network and dumb terminals 📞 The advantage is that legacy nodes can benefit from mobility support without upgrading. However, the cost isn't trivial either: the users lose their freedom of control in terms of mobility management, and a large number of entities in the network need to be upgraded 🥲
The third design assumes that the other end is likely mobility-capable too (as of today, more people access the Internet via mobile devices than a desktop) and thus doesn't provide backward compatibility at all 📱💅 However, as a trade-off, the system design becomes much simpler, and the data path is always the shortest one 🏃♀️💨
We all know that backward compatibility is important in system design. But how important is it? How much effort should we put into this issue? At least for now, the answer isn't clear yet 🫠
6.4. Interconnecting Heterogeneous Mobility Support Systems
As our survey suggests, multiple solutions for mobility support already exist, and it's almost for sure that mobility support systems in the future are going to be heterogeneous 🌈 However, as of today, the interoperation between different protocols is still problematic 🚧 For example, when a mobile node supporting Mobile IP only wants to communicate with another mobile with only HIP support, neither of them can benefit from mobility support 😵💫
This situation reminds us of the days before IP was adopted. Back then, hosts in different networks couldn't communicate with each other. IP merged the networks and created the Internet, where each host can freely communicate with any other host 🌐👑 So is it necessary to introduce something like IP to mobility support in the future? Is it possible to design an architecture that glues all the mobility support systems together? We believe the answers to both of these questions are "yes" 🙋♀️✨
The basic idea for the solution is simple. As the famous quote says, "Every problem in Computer Science can be solved by adding a level of indirection". However, the devil is in the details, and we still need to figure that out 😈🧐
7. Security Considerations 🔐
Since mobility means that the location of a mobile may change at any time, how to secure such dynamic location updates is a very important consideration for all mobility support solutions 🚨 This document examines a wide range of solution proposals, so the security aspects also vary greatly. For example, Home-Agent-based solutions call for secure communications between the mobile and its Home Agent(s). On the other hand, for routing-based solutions, such as Connexion, the issue becomes one of global-routing security 🌍💀 Similarly, for those solutions that use DNS to provide mapping between Identifiers and Locators, the issue is essentially converted to how to secure DNS dynamic updates as well as queries 🕵️♀️ To keep this survey document both comprehensive and reasonably sized, we chose to focus it on describing and comparing the solutions to the center piece of all mobility support -- the resolution between Identifiers and Locators 👑🔥
8. Informative References ✨
okay bestie, this is the reading list 📚 every reference the mobility story leans on, and yes I'm keeping every single detail 💅
- [ALM-SIP] Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility Using SIP", Mobile Computing and Communications Review, 2010.
- [Boeing] Andrew, L., "A Border Gateway Protocol 4 (BGP-4)", Boeing White Paper, 2006.
- [CIP] Valko, A., "Cellular IP: A New Approach to Internet Host Mobility", ACM SIGCOMM, 1999.
- [Columbia] Ioannidis, J., Duchamp, D., and G. Maguire, "IP-based Protocols for Mobile Internetworking", ACM SIGCOMM CCR, 1991.
- [E2E] Snoeren, A. and H. Balakrishnan, "An End-to-End Approach to Host Mobility", ACM Mobicom, 2000.
- [GTP] "GPRS Tunneling Protocol Across Gn and Gp Interface", 3G TS 29.060 v3.5.0.
- [HAHA] Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home Agents Towards Internet-scale Mobility Deployment", ACM CoNEXT, 2006.
- [HAWAII] Ramjee, R., Varadhan, K., and L. Salgarelli, "HAWAII: A Domain-based Approach for Supporting Mobility in Wide-area Wireless Networks", IEEE/ACM Transcations on Networking, 2002.
- [ILNP] Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal for Unifying Mobility with Multi-Homing, NAT, and Security", MobiWAC 2007.
- [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, March 2009.
- [LISP-Mobility] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", Work in Progress, May 2011.
- [LSR] Bhagwat, P. and C. Perkins, "A Mobile Networking System Based on Internet Protocol (IP)", Mobile and Location-Independent Computing Symposium, 1993.
- [M-SCTP] Xing, W., Karl, H., and A. Wolisz, "M-SCTP: Design and Prototypical Implementation of An End-to-End Mobility Concept", 5th Intl. Workshop on the Internet Challenge, 2002.
- [MSM-IP] Mysore, J. and V. Bharghavan, "A New Multicast-based Architecture for Internet Host Mobility", ACM Mobicom, 1997.
- [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
- [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
- [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
- [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
- [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
- [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
- [RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", RFC 4651, February 2007.
- [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
- [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
- [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
- [RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile IPv4", RFC 5454, March 2009.
- [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
- [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
- [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, June 2011.
- [TIMIP] Grilo, A., Estrela, P., and M. Nunes, "Terminal Independent Mobility For IP (TIMIP)", IEEE Communications Magazine, 2001.
- [VIP] Teraoka, F., Yokote, Y., and M. Tokoro, "A Network Architecture Providing Host Migration Transparency", ACM SIGCOMM CCR, 1991.
- [WINMO] Hu, X., Li, L., Mao, Z., and Y. Yang, "Wide-Area IP Network Mobility", IEEE INFOCOM, 2008.
Authors' Addresses 💖
the authors, with their contact deets 🫶
Zhenkai Zhu
UCLA
4805 Boelter Hall, UCLA
Los Angeles, CA 90095
USA
Phone: +1 310 993 7128
EMail: zhenkai@cs.ucla.edu
Ryuji Wakikawa
Toyota ITC
465 Bernardo Avenue
Mountain View, CA 94043
USA
EMail: ryuji.wakikawa@gmail.com
Lixia Zhang
UCLA
3713 Boelter Hall, UCLA
Los Angeles, CA 90095
USA
Phone: +1 310 825 2695
EMail: lixia@cs.ucla.eduand that's the whole spec, bestie 🌈👑 the end!!
📦 where this page comes from
- ietf: rfc6301 2011-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms