RFC 4889
Network Mobility Route Optimization Solution Space Analysis
RFC 4889: Network Mobility Route Optimization Solution Space Analysis 🦋 (Part 1 of 9)
Okay bestie, this one is from the Network Working Group 🌸 It was written by four people: C. Ng from Panasonic Singapore Labs, F. Zhao from UC Davis, M. Watari from KDDI R&D Labs, and P. Thubert from Cisco Systems. It's dated July 2007 and its category is Informational, so it's a "here's what we found" doc, not an official standard 💅 The header doesn't have any "Obsoletes" or "Updates" line, so it doesn't replace or change any other RFC.
Status of This Memo ✨
This memo gives information to the Internet community. It does not specify an Internet standard of any kind, and anyone can share it freely because distribution is unlimited 💖
Copyright Notice 🎀
Copyright (C) The IETF Trust (2007).
Abstract 🌈
Okay so, with current Network Mobility (NEMO) Basic Support, every communication to and from Mobile Network Nodes has to go through the Mobile Router and Home Agent (MRHA) tunnel while the mobile network is away 🙈 In most cases that makes the packet route longer and the packet delay bigger. To fix that, people might need to look at Route Optimization (RO) for NEMO. This memo documents the different kinds of Route Optimization in NEMO and looks at the benefits and tradeoffs of each one 🔥
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Benefits of NEMO Route Optimization . . . . . . . . . . . . . 4
3. Different Scenarios of NEMO Route Optimization . . . . . . . . 6
3.1. Non-Nested NEMO Route Optimization . . . . . . . . . . . . 6
3.2. Nested Mobility Optimization . . . . . . . . . . . . . . . 8
3.2.1. Decreasing the Number of Home Agents on the Path . . . 8
3.2.2. Decreasing the Number of Tunnels . . . . . . . . . . . 9
3.3. Infrastructure-Based Optimization . . . . . . . . . . . . 9
3.4. Intra-NEMO Optimization . . . . . . . . . . . . . . . . . 10
4. Issues of NEMO Route Optimization . . . . . . . . . . . . . . 11
4.1. Additional Signaling Overhead . . . . . . . . . . . . . . 11
4.2. Increased Protocol Complexity and Processing Load . . . . 12
4.3. Increased Delay during Handoff . . . . . . . . . . . . . . 12
4.4. Extending Nodes with New Functionalities . . . . . . . . . 13
4.5. Detection of New Functionalities . . . . . . . . . . . . . 14
4.6. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Mobility Transparency . . . . . . . . . . . . . . . . . . 14
4.8. Location Privacy . . . . . . . . . . . . . . . . . . . . . 15
4.9. Security Consideration . . . . . . . . . . . . . . . . . . 15
4.10. Support of Legacy Nodes . . . . . . . . . . . . . . . . . 15
5. Analysis of Solution Space . . . . . . . . . . . . . . . . . . 16
5.1. Which Entities Are Involved? . . . . . . . . . . . . . . . 16
5.1.1. Mobile Network Node and Correspondent Node . . . . . . 16
5.1.2. Mobile Router and Correspondent Node . . . . . . . . . 17
5.1.3. Mobile Router and Correspondent Router . . . . . . . . 17
5.1.4. Entities in the Infrastructure . . . . . . . . . . . . 18
5.2. Who Initiates Route Optimization? When? . . . . . . . . . 18
5.3. How Is Route Optimization Capability Detected? . . . . . . 19
5.4. How is the Address of the Mobile Network Node
Represented? . . . . . . . . . . . . . . . . . . . . . . . 20
5.5. How Is the Mobile Network Node's Address Bound to
Location? . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5.1. Binding to the Location of Parent Mobile Router . . . 21
5.5.2. Binding to a Sequence of Upstream Mobile Routers . . . 23
5.5.3. Binding to the Location of Root Mobile Router . . . . 24
5.6. How Is Signaling Performed? . . . . . . . . . . . . . . . 26
5.7. How Is Data Transmitted? . . . . . . . . . . . . . . . . . 27
5.8. What Are the Security Considerations? . . . . . . . . . . 28
5.8.1. Security Considerations of Address Binding . . . . . . 28
5.8.2. End-to-End Integrity . . . . . . . . . . . . . . . . . 30
5.8.3. Location Privacy . . . . . . . . . . . . . . . . . . . 30
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . . 331. Introduction 💫
So the Network Mobility Route Optimization Problem Statement [1] explains the operational limits and extra overhead you get when you deploy Network Mobility (NEMO) Basic Support [2]. A set of NEMO Route Optimization techniques, which haven't been defined yet, could help with that 🦋 The phrase "Route Optimization" is used more loosely here than in [3], where it's for IPv6 Host Mobility. In this doc it means any approach that makes packets move more efficiently between a Mobile Network Node and a Correspondent Node ✨
People have been pitching solutions that fit that description since the early days of NEMO, even before the Working Group was formed 💅 This document sorts that whole solution space into generic categories, looking at the possible approaches to the Route Optimization problems for NEMO. It analyzes the scope of each solution, its benefits, and how it affects existing implementations and deployments. The goal is for this work to be the foundation for the NEMO WG to decide where to focus its Route Optimization effort, with a clear picture of how each approach's strengths and weaknesses compare 🌈
Keep the NEMO design requirements [4] in mind while you read, too 💜 Also, since this document is about Route Optimization, assume a mobile network or a mobile host is away whenever it's mentioned, unless the text specifically says it's at home 🏠
1.1. Terminology 🎀
You're expected to already know the mobility terms in [3] and [5], plus the NEMO-related terms defined in [6]. On top of that, this document uses these Route Optimization-specific terms:
- Correspondent Router (CR) This is the router that can end a Route Optimization session on behalf of a Correspondent Node 🧚
- Correspondent Entity (CE) This is the entity that a Mobile Router or Mobile Network Node tries to set up a Route Optimization session with. Depending on the Route Optimization approach, the Correspondent Entity could be a Correspondent Node or a Correspondent Router 🌸
2. Benefits of NEMO Route Optimization 🍓
Okay, main character energy 👑 NEMO Route Optimization deals with the problems described in [1]. There isn't a standardized NEMO Route Optimization solution yet, but you can expect it to bring some of these benefits:
- Shorter Delay ⭐ Route Optimization means picking and using a route with lower cost, which is usually shorter and faster, for traffic between a Mobile Network Node and its Correspondent Node. So Route Optimization should improve the latency between the two end nodes. That can lead to better overall Quality of Service, like less jitter and fewer lost packets 🫶
- Reduced Consumption of Overall Network Resources 💜 If you choose a shorter route, the total link utilization for every link used by traffic between the two end nodes should be a lot lower than it would be without Route Optimization. That means a lighter network load and less congestion 🌈
- Reduced Susceptibility to Link Failure 😭 If a link along the bi-directional tunnel breaks, all traffic to and from the mobile network gets affected until IP routing recovers. An optimized route would probably use fewer links between the two end nodes, so the chance of losing connectivity from one failed link should be lower than on the longer, non-optimized route 💀
- Greater Data Efficiency 🧚 Depending on the actual NEMO Route Optimization solution, the data packets between the two end nodes might not need as many layers of encapsulation as NEMO Basic Support uses. That means less packet overhead and better data efficiency 💖 Avoiding the packet fragmentation that can come from multiple layers of tunneling is especially important for end-to-end efficiency, from the buffering and transport protocol point of view 🔥
- Reduced Processing Delay ⚡ In a nested mobile network, Route Optimization may get rid of the multiple encapsulations NEMO Basic Support needs. That could mean less processing delay at the encapsulation and decapsulation points 🌸
- Avoiding a Bottleneck in the Home Network 🏡 NEMO Route Optimization lets traffic skip the Home Agents. Besides being a more direct route, this also stops traffic from going through the home network, which could otherwise be a bottleneck 🦋
- Avoid the Security Policy Issue 🔐 Security policy might forbid a Mobile Router from tunneling the traffic of Visiting Mobile Nodes into the Mobile Router's home network. Route Optimization can get around this by sending traffic from Visiting Mobile Nodes straight to their destinations, without going through the Mobile Router's home network 🙈
⚠️ Bestie, don't skip this part! A Route Optimization mechanism might not be the right fix, because the Mobile Router can still be held responsible for illegal traffic sent from its Mobile Network Nodes even when Route Optimization is in use. Plus, there can be lots of different policies that conflict with deploying Route Optimization for Visiting Mobile Nodes. Since this is a policy issue, it might be better solved with a protocol at the policy plane 👑
- Avoid the Instability and Stalemate 🌀 [1] describes a possible stalemate when a Home Agent is nested inside a mobile network. Route Optimization may get out of these stalemates by sending traffic directly upstream. But some Route Optimization schemes need signaling packets to go through the Home Agent first, before they can set up an optimized route. In those cases, a Route Optimization solution can't avoid the stalemate 😤
3. Different Scenarios of NEMO Route Optimization 🌟
There are a bunch of proposals for different kinds of Route Optimization in the NEMO context 💅 In the following subsections, we go over the different scenarios that would need a Route Optimization mechanism and list the potential solutions that have been proposed for each area ✨ Let's keep going! ✨
3.1. Non-Nested NEMO Route Optimization
okay bestie, first up is the non-nested flavour 💅 this one is when a Mobile Router sends binding information to a Correspondent Entity. There's no nesting of Mobile Routers or Visiting Mobile Nodes, so it's giving simple ✨ The Correspondent Entity can be a Correspondent Node or a Correspondent Router, but the most iconic case is when it's a Correspondent Router 👑 With a Correspondent Router, the Route Optimization session gets terminated at the CR on behalf of the CN. As long as the CR is "closer" to the CN than the Mobile Router's Home Agent, the route between the Mobile Network Node and the CN can be said to be optimized 🦋 So CRs may be deployed to give an optimal route, see Figure 1 below.
************************** HAofMR
* #*#
* #*# +---------------------+
CN #*# | LEGEND |
o #*# +---------------------+
o ############### #*# | #: Tunnel |
CR ooooooooooooooo MR | *: NEMO Basic route |
############### | | o: Optimized route |
MNN +---------------------+
Figure 1: MR-CR OptimizationThis form of optimization can carry traffic in both directions, or independently for the two directions of traffic 🎀
- From MNN to CN: The Mobile Router locates the Correspondent Router, establishes a tunnel with that Correspondent Router and sets up a route to the Correspondent Node via the Correspondent Router over the tunnel. Traffic to the Correspondent Node would no longer flow through the Home Agent anymore 🙈
- From CN to MNN: The Correspondent Router is on the path of the traffic from the Correspondent Node to the Home Agent. In addition, it has an established tunnel with the current Care-of Address (CoA) of the Mobile Router and is aware of the Mobile Network Prefix(es) managed by the Mobile Router. So the Correspondent Router can intercept packets going to the mobile network and forward them to the Mobile Router over the established tunnel 🧚
A straightforward approach to Route Optimization in NEMO is for the Mobile Router to attempt Route Optimization with a Correspondent Entity. This is basically a logical extension to NEMO Basic Support, where the Mobile Router sends Binding Updates containing one or more Mobile Network Prefix options to the Correspondent Entity. The Correspondent Entity, after receiving the Binding Update, can then set up a bi-directional tunnel with the Mobile Router at the current Care-of Address of the Mobile Router, and inject a route into its routing table so that packets destined for addresses in the Mobile Network Prefix get routed through the bi-directional tunnel 💜
The definition of Correspondent Router doesn't limit it to be a fixed router. Here we consider the case where the Correspondent Router is a Mobile Router. So Route Optimization is initiated and performed between a Mobile Router and its peer Mobile Router. Such solutions are often posed with a requirement to leave the Mobile Network Nodes untouched, as with the NEMO Basic Support protocol, so Mobile Routers handle the optimization management on behalf of the Mobile Network Nodes. Because of that, providing Route Optimization for a Visiting Mobile Node is often out of scope for this scenario, since such interaction would require extensions to the Mobile IPv6 protocol. This scenario is illustrated in Figure 2 below 🌸
HAofCR ********************************** HAofMR
#*# #*#
#*# #*# +---------------------+
#*# #*# | LEGEND |
#*# #*# +---------------------+
#*# ############### #*# | #: Tunnel |
CR ooooooooooooooo MR | *: NEMO Basic route |
| ############### | | o: Optimized route |
MNN2 MNN1 +---------------------+
Figure 2: MR-MR OptimizationThis form of optimization can carry traffic for both directions identically 🔥
- MNN1 to/from MNN2: The Mobile Router locates the Correspondent Router, establishes a tunnel with that Correspondent Router, and sets up a route to the Mobile Network Node via the Correspondent Router over the tunnel. Traffic to the Mobile Networks Nodes would no longer flow through the Home Agents.
Examples of this approach include Optimized Route Cache (ORC) [7][8] and Path Control Header (PCH) [9] ✨
3.2. Nested Mobility Optimization
okay so optimization in Nested Mobility targets scenarios where a nesting of mobility management protocols is created 🪆 (like a Mobile IPv6-enabled host inside a mobile network, or multiple Mobile Routers attached behind one another to create a nested mobile network). Note that because Mobile IPv6 defines its own Route Optimization mechanism in its base protocol suite as a standard, collaborating between this and NEMO protocols brings various complexities 😭
There are two main aspects in providing optimization for Nested Mobility, and they're discussed in the following sub-sections 💖
3.2.1. Decreasing the Number of Home Agents on the Path
the aim here is to remove the sub-optimality of paths caused by multiple tunnels established between multiple Mobile Nodes and their Home Agents. A solution like this seeks to minimize the number of Home Agents along the path, by bypassing some of the Home Agent(s) from the original path. Unlike the scenario where no nesting is formed and only a single Home Agent exists along the path, bypassing one of the many Home Agents can still be effective 🦋
Solutions for Nested Mobility scenarios can usually be split into two cases, based on whether the nesting involves Mobile IPv6 hosts or only involves Mobile Routers. Since Mobile IPv6 defines its own Route Optimization mechanism, providing an optimal path for such hosts will require interaction with the protocol, and may require altering the messages exchanged during the Return Routability procedure with the Correspondent Node 🫶
An example of this approach includes Reverse Routing Header (RRH) [10].
3.2.2. Decreasing the Number of Tunnels
the aim is to reduce the amplification effect of nested tunnels, which happens because of the nesting of tunnels between the Visiting Mobile Node and its Home Agent within the tunnel between the parent Mobile Router and the parent Mobile Router's Home Agent 🌈 A solution like this seeks to minimize the number of tunnels, possibly by collapsing the amount of tunnels required through some form of signaling between Mobile Nodes, or between Mobile Nodes and their Home Agents, or by using routing headers to route packets through a discovered path. These limit the consequences of the amplification effect of nested tunnels, and at best, the performance of a nested mobile network will be the same as though there were no nesting at all ⭐
Honestly this is the part that makes nested mobility feel less like a mess and more like a glow-up 💅
Examples of this approach include the Reverse Routing Header (RRH) [10], Access Router Option (ARO) [11], and Nested Path Info (NPI) [12].
3.3. Infrastructure-Based Optimization
so infrastructure-based optimization is an approach where the optimization is carried out fully in the infrastructure 🏢 One example is to use Mobility Anchor Points (MAPs), such as those defined in HMIPv6 [13], to optimize routes between themselves. Another example is to use a proxy Home Agent, such as the one defined in the global Home Agent to Home Agent (HAHA) protocol [14] 🧁 A proxy Home Agent acts as a Home Agent for the Mobile Node, and acts as a Mobile Node for the Home Agent, Correspondent Node, Correspondent Router, and other proxies. In particular, the proxy Home Agent terminates the MRHA tunnel and the associated encryption, extracts the packets, and re-encapsulates them to the destination. In this case, proxy Home Agents are distributed in the infrastructure and each Mobile Router binds to the closest proxy. The proxy, in turn, performs a primary binding with a real Home Agent for that Mobile Router. Then, the proxy might establish secondary bindings with other Home Agents or proxies in the infrastructure, in order to improve the end-to-end path 🍓 In this case, the proxies discover each other using some form of Next Hop Resolution Protocol, establish a tunnel, and exchange the relevant Mobile Network Prefix information in the form of explicit prefix routes.
Alternatively, another approach is to use prefix delegation. Here, each Mobile Router in a nested mobile network is delegated a Mobile Network Prefix from the access router using DHCP Prefix Delegation [15]. Each Mobile Router also autoconfigures its Care-of Address from this delegated prefix. This way, the Care-of Addresses of each Mobile Router are all formed from an aggregatable address space starting from the access router. This may be used to eliminate the multiple tunnels caused by nesting of Mobile Nodes 🎀
3.4. Intra-NEMO Optimization 🧚
okay so this one is about two Mobile Network Nodes that are both hanging out inside the same nested mobile network 🫶. A Route Optimization solution might try to improve their chat so the traffic doesn't have to leave the nested network, go all the way out, and come back. no cap, that detour is so unnecessary 💀. The example is the optimized route between MNN1 and MNN2 in Figure 3 below 🌸.
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +------------------------------+
| MR1_HA |----| Internet |-----CN
+--------+ +--------------+---------------+
|
+----+----+
| MR1 |
+----+----+
|
---+-----------+-----------+---
| | |
+---+---+ +---+---+ +---+---+
| MR5 | | MR2 | | MR4 |
+---+---+ +---+---+ +---+---+
| | |
---+--- +---+---+ ---+---
MNN2 | MR3 | MNN3
+---+---+
|
----+----
MNN1
Figure 3: An Example of a Nested Mobile Networkokay and here's the lowkey clever bit 👑. You could maybe stretch a well-designed NEMO Route Optimization into "Nested Mobility Optimization" (see Section 3.2) to handle this kind of Intra-NEMO optimization. In Figure 3, MNN1 gets treated as a Correspondent Node by MR5/MNN2, and MNN2 gets treated as a Correspondent Node by MR3/MNN1 ✨. it's giving "everyone is a CN to everyone" 🙈.
Another option is to use the "Non-Nested NEMO Route Optimization" technique (see Section 3.1) here 🦋. Same MNN1-to-MNN2 chat as before: both MR3 and MR2 can treat MR5 as Correspondent Routers for MNN2, and MR5 treats MR3 and MR2 as Correspondent Routers for MNN1 💜. One example of this approach is [16], where the Mobile Routers announce their Mobile Network Prefixes to other Mobile Routers in the same nested Mobile Network 🎀.
And then there's the glow-up option 🌈: flatten the whole nested Mobile Network so that every nested Mobile Network Node looks like it's virtually on the same link. Ways to do that include delegating a single prefix to the nested Mobile Network, having Mobile Routers do Neighbor Discovery on behalf of their Mobile Network Nodes, and exposing a single prefix across the entire mobile network using a Mobile Ad-Hoc (MANET) protocol 🧚. Something I'm obsessed with: it might be useful to build a brand new kind of MANET, specialized for the NEMO problem, called a MANET for NEMO (MANEMO) 😭. The MANEMO would optimize how the nested NEMO forms and keep the inner connectivity working, whether or not a connection to the infrastructure can be made 💅.
4. Issues of NEMO Route Optimization ⚠️
okay real talk bestie 🫶: Route Optimization can bring the benefits from Section 2, but the scenarios in Section 3 come with some tradeoffs 💀. This section goes through some general issues that might affect a NEMO Route Optimization mechanism 🔍.
4.1. Additional Signaling Overhead 📨
the nodes doing Route Optimization would be expected to swap extra signaling messages to set it up 🫠. How much signaling depends on the solution, but it's likely to be more than the home Binding Update procedure defined in NEMO Basic Support 📈. The amount grows as the number of Mobile Network Nodes and/or Correspondent Nodes grows, and it can get amplified when mobile networks are nested 🪆. It can scale to unacceptable heights, especially for the resource-scarce mobile node, which usually has limited power, memory, and processing capacity 🪫.
this can lead to a problem that hits NEMO Route Optimization, known as the "Binding Update Storm", or more generally, "Signaling Storm" 🌪️. It happens when the mobile network changes its point of attachment and a sudden burst of signaling messages comes along with it, causing temporary congestion, packet delays, or even packet loss 😬. This effect is especially big in wireless environments, where bandwidth is relatively limited 📶.
you can kinda moderate the Signaling Storm by using mechanisms like spreading the burst of signaling messages out over a longer period of time, or by aggregating the signaling messages 🧁.
even so, the amount of signaling might be overwhelming 😵💫. Large mobile networks (like the ones on a train or a plane) may have lots of flows with lots of Correspondent Nodes 🚆✈️. That might suggest a need for some adaptive behavior, depending on how much signaling is required versus the effort needed to tunnel home 🏠.
4.2. Increased Protocol Complexity and Processing Load 🧠
it's expected that NEMO Route Optimization will be more complicated than NEMO Basic Support 🤯. So the nodes that need new functionality to support NEMO Route Optimization would be more complex than the ones needed for NEMO Basic Support 🛠️.
on top of that, the nodes involved in setting up and maintaining Route Optimization will have to carry an increased processing load 💪. If those nodes are mobile, that can be a big cost, since these devices usually have limited power and processing resources 🔋.
4.3. Increased Delay during Handoff ⏳
because the different nodes that a Mobile Network Node may signal with are spread all over the place, and because the NEMO Route Optimization procedure can need several rounds of signaling messages, it may take longer to finish a handoff than it does in NEMO Basic Support 🐢. That can make the overall handoff delay worse, and it can further hurt the performance of applications running on Mobile Network Nodes 📉.
there's another NEMO-specific delay during handoff too 🫣. In a nested mobile network, a child Mobile Network Node may need to detect, or be notified of, the handoff of its parent Mobile Router, so it can start signaling its own Correspondent Entities 🧸. Besides compromising mobility transparency and location privacy (see Section 4.7 and Section 4.8), this mechanism also adds delay during handoffs 🙃.
some of the Mobile IPv6 solutions, like Fast Handovers for Mobile IPv6 [17], might be able to ease the increase in handoff delay 🌷.
4.4. Extending Nodes with New Functionalities 🔧
to support NEMO Route Optimization, some nodes need to be changed or upgraded 🛠️. A smaller number of nodes that need changing makes it easier for the solution to be adopted across the Internet, and creates less impact on the existing Internet infrastructure 🌍. The number and types of nodes with new functionalities also affect how much of the route gets optimized 🛣️. Plus, it may be beneficial to reuse existing protocols (like Mobile IPv6) as much as possible ♻️.
here are the nodes that might need changing 👇:
- Local Fixed Nodes
it may be tricky to add new functionality at Local Fixed Nodes, since by definition, any IPv6 node can be a Local Fixed Node 🙈. That might mean only the Local Fixed Nodes that get modified can enjoy the benefits of Route Optimization 😔.
- Visiting Mobile Nodes
Visiting Mobile Nodes should already implement Mobile IPv6 functionalities in general 📱. And since Mobile IPv6 is a relatively new standard, there's still a pretty big window for mobile devices to add new functionalities 🪟✨.
- Mobile Routers
it's expected that Mobile Routers will implement new functionalities to support Route Optimization 🛜.
- Access Routers
some approaches need access routers, or nodes in the access network, to implement some new functionalities 🏢. That might be hard to pull off, since access routers are, in general, standard IPv6 routers 😅.
- Home Agents
it's relatively easier for new functionalities to be implemented in Home Agents 🏡💖.
- Correspondent Nodes
it may be tricky to add new functionalities at Correspondent Nodes, since by definition, any IPv6 node can be a Correspondent Node 🫠. That might mean only the Correspondent Nodes that get modified can enjoy the benefits of Route Optimization 💔.
- Correspondent Routers
Correspondent Routers are brand new entities made for Route Optimization, so new functionalities can be defined as needed 🥳. Main character energy 👑.
4.5. Detection of New Functionalities 🔍
this ties into the need for new functionalities from Section 4.4: we need a way to detect whether those functionalities exist 🕵️♀️. A detection mechanism might help the initiator of Route Optimization figure out whether support for the new functionalities is available 🎯. It might also be a good idea to have a graceful fallback procedure in case the required functionalities are unavailable 🫶.
4.6. Scalability 📈
given the same number of nodes, there would usually be more Route Optimization sessions than NEMO Basic Support tunnels 🤯. If one node (like the Mobile Router) maintains all the Route Optimization sessions of a mobile network, that node has to keep track of the state of every single one 🗂️. That can cause scalability issues, especially when that node is a mobile device with limited memory and processing resources 📱💀.
a Correspondent Entity may run into a similar scalability issue if it maintains many route-optimized sessions on behalf of Correspondent Node(s) with a large number of Mobile Routers 🌐.
4.7. Mobility Transparency 🫥
one perk of NEMO Basic Support is that the Mobile Network Nodes don't need to know the actual location and mobility of the mobile network 🥷. With some Route Optimization approaches, though, it might be necessary to reveal the point of attachment of the Mobile Router to the Mobile Network Nodes 📍. That can mean a tradeoff between mobility transparency and Route Optimization ⚖️💅.
4.8. Location Privacy 🦋
Okay bestie, so without Route Optimization, the Correspondent Nodes are literally not aware of where the mobile network is or how it's moving, and that goes for its Mobile Network Nodes too 🙈. To get Route Optimization, it might be necessary to reveal the point of attachment of the Mobile Router to the Correspondent Nodes. So this may mean a tradeoff between location privacy [18] and Route Optimization. It's giving "pick your fighter" 😭
In Mobile IPv6, a mobile node can decide whether or not to perform Route Optimization with a given Correspondent Node. So the mobile node is in control of whether to trade location privacy for an optimized route ✨ That's such a main character move. In NEMO Route Optimization, though, if the decision to perform Router Optimization is made by the Mobile Router, it will be difficult for Mobile Network Nodes to control the decision of having this tradeoff. Not me being like "wait, the router is deciding for everyone?" 💅
4.9. Security Consideration 🔥
Okay, this one is serious, so listen up 👀. Mobile Router and Home Agent usually belong to the same administration domain, so it's likely that there exists a security association between them. NEMO Basic Support leverages that association to send the home Binding Update in a secure way 🔐. However, NEMO Route Optimization usually involves nodes from different domains (for example, Mobile Router and Correspondent Entity). So the existence of such a security association is not a valid assumption in many deployment scenarios 💀. For this reason, the security protection of NEMO Route Optimization signaling message is considered "weaker" than that in NEMO Basic Support. It is expected that some additional security mechanisms are needed to achieve the same or similar level of security as in NEMO Basic Support. Basically, the bar is higher and we need backup 🫶.
When considering security issues of NEMO Route Optimization, it might be useful to keep in mind some of the security issues considered when Mobile IPv6 Route Optimization was designed as documented in [19]. Think of it as studying from the notes that already exist 📚✨.
4.10. Support of Legacy Nodes 🌸
NEMO Basic Support is designed so that all legacy Mobile Network Nodes (such as those that are not aware of the mobility of the network they are in, and those that do not understand any mobility protocols) can still reach and be reached from the Internet. It's so inclusive 🥹. Some Route Optimization schemes, however, require that all Mobile Routers implement the same Route Optimization scheme in order for them to operate. So a nested Mobile Router may not be able to achieve Route Optimization if it is attached to a legacy Local Fixed Router. Lowkey the group chat has to be on the same app for this to work 📱💔.
5. Analysis of Solution Space 🧠
As described in Section 3, there are various different approaches to achieve Route Optimization in Network Mobility Support. So in this section, we're going to analyze the vast solution space of NEMO Route Optimization by asking the following questions:
- Which entities are involved?
- Who initiates Route Optimization? When?
- How is Route Optimization capabilities detected?
- How is the address of the Mobile Network Node represented?
- How is the Mobile Network Node's address bound to location?
- How is signaling performed?
- How is data transmitted?
- What are the security considerations?
5.1. Which Entities Are Involved? 👑
There are many combinations of entities involved in Route Optimization. When you think about the role each entity plays, you have to keep in mind the considerations described in Section 4.4 and Section 4.5 🎀. Below is a list of combinations that we'll go through in the following sub-sections:
- Mobile Network Node and Correspondent Node
- Mobile Router and Correspondent Node
- Mobile Router and Correspondent Router
- Entities in the Infrastructure
5.1.1. Mobile Network Node and Correspondent Node 💜
A Mobile Network Node can establish Route Optimization with its Correspondent Node, possibly the same way as a Mobile Node establishes Route Optimization with its Correspondent Node in Mobile IPv6. This would achieve the most optimal route, since the entire end-to-end path is optimized 🔥. However, there might be scalability issues, since both the Mobile Network Node and the Correspondent Node may need to maintain many Route Optimization sessions. Also, new functionalities would be required for both of them. The Mobile Network Node needs to be able to manage its mobility, and possibly be aware of the mobility of its upstream Mobile Router(s). The Correspondent Node, meanwhile, needs to be able to maintain the bindings sent by the Mobile Network Nodes. That's a lot of juggling, bestie 🤹♀️.
5.1.2. Mobile Router and Correspondent Node 🍓
Alternatively, the Mobile Router can establish Route Optimization with a Correspondent Node on behalf of the Mobile Network Node. Since all packets to and from the Mobile Network Node must transit the Mobile Router, this effectively achieves an optimal route for the entire end-to-end path as well ✨. Compared with Section 5.1.1, the scalability issue here may be remedied, since it is possible for the Correspondent Node to maintain only one session with the Mobile Router if it communicates with many Mobile Network Nodes associated with the same Mobile Router. Furthermore, with the Mobile Router handling Route Optimization, there is no need for Mobile Network Nodes to implement new functionalities. However, new functionality is likely to be required on the Correspondent Node. Another point to consider is the amount of state information the Mobile Router is required to maintain. Traditionally, it has been generally avoided having state information in the routers increase proportionally with the number of pairs of communicating peers. Routers hate growing state, so this is a big deal 🙈.
5.1.3. Mobile Router and Correspondent Router 🦋
Approaches involving Mobile Routers and Correspondent Routers are described in Section 3.1. The advantage here is that no additional functionality is required for the Correspondent Node and Mobile Network Nodes. Location privacy is also relatively preserved, since the current location of the mobile network is only revealed to the Correspondent Router and not to the Correspondent Node (please refer to Section 5.8.3 for more discussions) 🫶. Furthermore, if the Mobile Router and Correspondent Router exchange prefix information, this approach may scale well. A single Route Optimization session between the Mobile Router and Correspondent Router can achieve Route Optimization between any Mobile Network Node in the mobile network, and any Correspondent Node managed by the Correspondent Router. That's efficient, periodt 💅.
The main concern with this approach is the need for a mechanism to allow the Mobile Router to detect the presence of the Correspondent Router (see Section 5.3 for details), and its security impact. Both the Mobile Router and the Correspondent Router need some means to verify the validity of each other. This is discussed in greater detail in Section 5.8 🔐.
A deployment consideration with respect to the use of Correspondent Router is the location of the Correspondent Router relative to the Correspondent Node. On one hand, deploying the Correspondent Router nearer to the Correspondent Node would result in a more optimal path. On the other hand, a Correspondent Router that is placed farther away from the Correspondent Node can perform Route Optimization on behalf of more Correspondent Nodes. So it's a whole vibe check on placement 🧚.
5.1.4. Entities in the Infrastructure 🌈
Approaches using entities in the infrastructure are described in Section 3.3. The advantages of this approach include, firstly, not requiring new functionalities to be implemented on the Mobile Network Nodes and Correspondent Nodes, and secondly, having most of the complexity shifted to nodes in the infrastructure. However, one main issue is how the Mobile Router can detect the presence of such entities, and why the Mobile Router should trust these entities. This may be easily addressed if such entity is a Home Agent of the Mobile Router (such as in the global Home Agent to Home Agent protocol [14]) ⭐. Another concern is that the resulting path may not be a true optimized one, since it depends on the relative positions of the infrastructure entities with respect to the mobile network and the Correspondent Node.
5.2. Who Initiates Route Optimization? When? ⏰
Having figured out the entities involved in the previous sub-section, the next question is which of these entities should initiate the Route Optimization session. Usually, the node that is moving (i.e., Mobile Network Node or Mobile Router) is in the best position to detect its mobility. So, in general, it is better for the mobile node to initiate the Route Optimization session, in order to handle the topology changes in any kind of mobility pattern and achieve the optimized route promptly 🚀. However, when the mobile node is within a nested mobile network, the detection of the mobility of upstream Mobile Routers may need to be conveyed to the nested Mobile Network Node. This might incur longer signaling delay, as discussed in Section 4.3 🙃.
Some solutions may enable the node on the correspondent side to initiate the Route Optimization session in certain situations. For instance, when the Route Optimization state that is already established on the Correspondent Entity is about to expire but the communication is still active, the Correspondent Entity may initiate a Route Optimization request with the mobile node side, depending on the policy 🍓.
There is also the question of when Route Optimization should be initiated. Because Route Optimization would certainly incur tradeoffs of various forms, it might not be desirable for Route Optimization to be performed for any kind of traffic. This is, however, implementation specific and policy driven 🎀.
A related question is how often signaling messages should be sent to maintain the Route Optimization session. Typically, signaling messages are likely to be sent whenever there are topological changes, and the discussion in Section 4.1 should be considered. In addition, a Lifetime value is often used to indicate the period of validity for the Route Optimization session. Signaling messages would have to be sent before the Lifetime value expires in order to maintain the Route Optimization session. The choice of Lifetime value needs to balance different considerations. On one hand, a short Lifetime value would increase the amount of signaling overhead 😩. On the other hand, a long Lifetime value may expose the Correspondent Entity to the risk of having an obsolete binding cache entry, which creates an opportunity for an attacker to exploit 🚨. So you can't just pick the vibe you like, you gotta balance it 💖.
5.3. How Is Route Optimization Capability Detected? 🔍
Okay bestie, the big question here is how the initiator of Route Optimization even knows if the Correspondent Entity can do what's needed to set up a Route Optimization session 🤔. The usual move is to just... try it! The initiator attempts Route Optimization with the Correspondent Entity, and depending on the protocol details it can get one of three things: (i) a reply from the Correspondent Entity saying what it's capable of, (ii) an error message from the Correspondent Entity, or (iii) no response from the Correspondent Entity within a certain time period. That's the signal for whether the Correspondent Entity supports the functionality needed to establish Route Optimization. The catch (ngl, kinda annoying 😩) is that this "just try it" method can add extra delay as a penalty when the Correspondent Entity can't do Route Optimization, especially when the mechanism uses in-band signaling.
When the Correspondent Entity is not the Correspondent Node but a Correspondent Router, the first thing everyone wonders is how its presence can be detected 👀. One approach is for the initiator to send an Internet Control Message Protocol (ICMP) message containing the address of the Correspondent Node to a well-known anycast address reserved for all Correspondent Routers [7][8]. Only the Correspondent Router that is capable of terminating the Route Optimization session on behalf of the Correspondent Node will respond. 🙌
Another way is to insert a Router Alert Option (RAO) into a packet sent to the Correspondent Node [9]. Any Correspondent Router en route will process the Router Alert Option and send a response to the Mobile Router. Iconic. 🦋
Both approaches need to consider the possibility of multiple Correspondent Routers responding to the initiator, and both approaches will generate additional traffic or processing load to other routers. 😬 Furthermore, both approaches have yet to consider how the initiator can verify the authenticity of the Correspondent Routers that responded. Not me noticing this gap in the security story 💀✨
5.4. How is the Address of the Mobile Network Node Represented? 🏠
Normally, Route Optimization would mean that a binding between the address of a Mobile Network Node and the location of the mobile network gets registered at the Correspondent Entity. 💖 Before exploring the different ways of binding (see Section 5.5), we have to ask how the address of the Mobile Network Node is represented. Basically, there are two ways to do it:
- inferred by the use of the Mobile Network Prefix, or
- explicitly specifying the address of the Mobile Network Node.
Using the Mobile Network Prefix usually means that the initiator is the Mobile Router, and the perk is that it can bind numerous Mobile Network Nodes with one signaling message. 🌸 The tradeoff: if location privacy is compromised, the location privacy of an entire Mobile Network Prefix is compromised too. Yikes 🙈
On the other hand, using the Mobile Network Node's address means either the initiator is the Mobile Network Node itself, or the Mobile Router is initiating Route Optimization on behalf of the Mobile Network Node. Initiation by the Mobile Network Node itself means that the Mobile Network Node must have new functionalities implemented, while initiation by the Mobile Router means that the Mobile Router must maintain some Route Optimization states for each Mobile Network Node. Two different vibes, both valid 💅
5.5. How Is the Mobile Network Node's Address Bound to Location? 📍
In order for the route to be optimized, it's generally necessary for the Correspondent Entity to create a binding between the address and the location of the Mobile Network Node. ✨ This can be done in the following ways:
- binding the address to the location of the parent Mobile Router,
- binding the address to a sequence of upstream Mobile Routers, and
- binding the address to the location of the root Mobile Router.
These are described in the following sub-sections. Let's gooo 🚀
5.5.1. Binding to the Location of Parent Mobile Router
By binding the address of the Mobile Network Node to the location of its parent Mobile Router, the Correspondent Entity knows how to reach the Mobile Network Node through the current location of the parent Mobile Router. 🗺️ This can be done in a few ways:
- Binding Update with Mobile Network Prefix
This one is giving NEMO Basic Support extension energy 🧩. The Mobile Router sends binding updates containing one or more Mobile Network Prefix options to the Correspondent Entity. Once the Correspondent Entity has received the Binding Update, it can set up a bi-directional tunnel with the Mobile Router at the current Care-of Address of the Mobile Router, and inject a route into its routing table so that packets destined for addresses in the Mobile Network Prefix get routed through the bi-directional tunnel.
Note that in this case, the address of the Mobile Network Node is implied by the Mobile Network Prefix (see Section 5.4). 📌
- Sending Information of Parent Mobile Router
This is where the Mobile Network Node sends the information about its Mobile Router to the Correspondent Entity, so the Correspondent Entity can bind the address of the Mobile Network Node to the location of the parent Mobile Router. An example of this approach is [11]. 💜
- Mobile Router as a Proxy
Another approach is for the parent Mobile Router to act as a "proxy" for its Mobile Network Nodes. Here the Mobile Router uses the standard Mobile IPv6 Route Optimization procedure to bind the address of a Mobile Network Node to the Mobile Router's Care-of Address. For instance, when the Mobile Network Node is a Local Fixed Node without Mobile IPv6 Route Optimization functionality, the Mobile Router may initiate the Return Routability procedure with a Correspondent Node on behalf of the Local Fixed Node. Examples of this approach are [20][21][22]. 🎀
On the other hand, if the Mobile Network Node is a Visiting Mobile Node, it might be necessary for the Visiting Mobile Node to delegate the rights of Route Optimization signaling to the Mobile Router (see [23] for an example of such delegation). With this delegation, either the Visiting Mobile Network Node or the Mobile Router can initiate the Return Routability procedure with the Correspondent Node. 🧚
For the case where the Visiting Mobile Node initiates the Return Routability procedure, the Mobile Router has to transparently alter the content of the Return Routability signaling messages, so that packets sent from the Correspondent Node to the Visiting Node get routed to the Care-of Address of the Mobile Router once Route Optimization is established. The case where the Mobile Router initiates the Return Routability procedure is similar to the case where the Mobile Network Node is a Local Fixed Node. 🫶
For all of the approaches listed above, when the Mobile Network Node is deeply nested within a Mobile Network, the Correspondent Entity would need to gather Binding Updates from all the upstream Mobile Routers in order to build the complete route to reach the Mobile Network Node. 🌀 This makes the Correspondent Entity more complex, since it may need to perform multiple binding cache look-ups before it can construct the complete route.
Nesting gets messy fast. Each extra layer of Mobile Router adds more work for the Correspondent Entity, so the deeper the nest, the more the whole thing starts to lag. 😩
Beyond making the Correspondent Entity more complex, these approaches may add extra signaling overhead and delay for a nested Mobile Network Node. For instance, every Mobile Router upstream of the Mobile Network Node needs to send Binding Updates to the Correspondent Entity. If the upstream Mobile Routers do this independently, it may add extra signaling overhead. Also, since each Binding Update takes a finite amount of time to reach and be processed by the Correspondent Entity, the delay from the moment an optimized route changes until the change is registered on the Correspondent Entity increases proportionally with the number of Mobile Routers upstream of the Mobile Network Node (i.e., the level of nesting of the Mobile Network Node). ⏳
For "Binding Update with Mobile Network Prefix" and "Sending Information of Parent Mobile Router", new functionality is required at the Correspondent Entity. "Mobile Router as a Proxy", on the other hand, keeps the functionality of the Correspondent Entity the same as a Mobile IPv6 Correspondent Node. 🤝 But this comes at an expense to the Mobile Routers, because in "Mobile Router as a Proxy", the Mobile Router has to maintain state information for every Route Optimization session its Mobile Network Nodes have. Plus, in some cases, the Mobile Router needs to look beyond the standard IPv6 headers for ingress and egress packets and alter the packet contents appropriately. This may impact end-to-end integrity (see 5.8.2). 🥺
One advantage shared by all the approaches listed here is that only the mobility protocol is affected. In other words, no modification is required on other existing protocols (such as Neighbor Discovery). There's also no additional requirement on existing infrastructure (such as the access network). Low-key the best part 🌈
In addition, having upstream Mobile Routers send Binding Updates independently means the Correspondent Entity can reuse the same binding cache entries of upstream Mobile Routers to construct the complete route to two Mobile Network Nodes that have common upstream Mobile Routers. This may translate to lower memory consumption, since the Correspondent Entity doesn't need to store one complete route per Mobile Network Node when it has Route Optimization sessions with multiple Mobile Network Nodes from the same mobile network. Smart, efficient, and honestly kind of iconic 👑✨
5.5.2. Binding to a Sequence of Upstream Mobile Routers ✨
okay so for a nested Mobile Network Node, binding its address to the whole sequence of points of attachment of its upstream Mobile Routers might be the better move 🧚 that way the Correspondent Entity can build a complete sequence of points of attachment from a single transmission of the binding info. examples using this approach are [10] and [12] 💅
this is different from Section 5.5.1 bc it builds the complete route to a specific Mobile Network Node on the mobile network side, so there's a chance to cut down on signaling overhead 📉 and since the complete route gets conveyed to the Correspondent Entity in one go, the delay from the moment an optimized route changes to the moment that change is registered on the Correspondent Entity can be reduced to its minimum ⏱️ literally so smart
okay but the obvious question is how the Mobile Network Node even gets the sequence of locations of its upstream Mobile Routers 🤔 usually it's done by having that info inserted as special options in the Router Advertisement messages sent by the upstream Mobile Routers 📨 so a Mobile Router has to advertise its current location to its Mobile Network Nodes, and it ALSO has to relay the info embedded in the Router Advertisement messages it got from its upstream Mobile Routers 🔁 this might compromise the mobility transparency of a mobile network (see Section 4.7) 😬 and also, whenever an upstream Mobile Router changes its point of attachment, every downstream Mobile Network Node has to do Route Optimization signaling again, which could lead to a "Signaling Storm" (see Section 4.1) 🌩️ not it
a different way to convey the locations of upstream Mobile Routers (like the one used in [10]) is for each upstream Mobile Router to insert its current point of attachment into a Reverse Routing Header embedded within a packet sent by the Mobile Network Node 🧩 this may raise security concerns, which will be discussed later in Section 5.8.2 🔐 ngl that's a whole vibe
for a Correspondent Entity to bind the address of a Mobile Network Node to a sequence of locations of upstream Mobile Routers, new functionality needs to be implemented on the Correspondent Entity 🛠️ the Correspondent Entity also has to store the complete sequence of locations of upstream Mobile Routers for every Mobile Network Node 🗂️ this may need more memory than Section 5.5.1 if the same Correspondent Entity has a lot of Route Optimization sessions with Mobile Network Nodes from the same nested Mobile Network 📦 plus, some modifications or extensions to existing protocols are also required, like a new type of IPv6 routing header or a new option in the Router Advertisement message 🎀
5.5.3. Binding to the Location of Root Mobile Router 🌳
the third approach is binding the address of the Mobile Network Node to the location of the root Mobile Router, no matter how deeply nested the Mobile Network Node is inside a nested Mobile Network 🪆 whenever the Correspondent Entity needs to forward a packet to the Mobile Network Node, it only has to forward it to this one point of attachment ✈️ the mobile network figures out how to get the packet to the Mobile Network Node by itself 🧠 this kind of approach is basically flattening the nested structure, so it looks to the Correspondent Entity like every node in the Mobile Network is attached to the Internet on the same network segment 🫶
there are a few ways to pull this off:
- Prefix Delegation
so here, each Mobile Router in a nested mobile network gets delegated a Mobile Network Prefix from the access router (for example using Dynamic Host Configuration Protocol (DHCP) Prefix Delegation [15]) 🍰 each Mobile Router also autoconfigures its Care-of Address from that delegated prefix 🏠 so the Care-of Addresses of all the Mobile Routers come from one aggregatable address space starting at the access router 🌈 a Mobile Network Node with Mobile IPv6 functionality can also autoconfigure its Care-of Address from this delegated prefix, and use the standard Mobile IPv6 mechanisms to bind its Home Address to that Care-of Address 💜
examples of this approach include [24], [25], and [26] 🦋
this approach keeps the implementations of Correspondent Nodes unchanged, which is a huge win 👑 BUT it requires the access router (or some other entity in the access network) and the Mobile Router to have prefix delegation functionality, and it also means keeping track of which prefix is delegated to which node 📋 figuring out how to efficiently assign a subset of the Mobile Network Prefix to child Mobile Routers could be an issue, because Mobile Network Nodes may join and leave dynamically in unpredictable patterns 🎢 and a change in the point of attachment of the root Mobile Router will make every nested Mobile Router (and possibly Visiting Mobile Nodes) change their Care-of Addresses and delegated prefixes 😵💫 that causes a burst of Binding Updates and prefix delegation activity, where every Mobile Router and every Visiting Mobile Node starts sending Binding Updates to their Correspondent Entities 💀
- Neighbor Discovery Proxy
this approach (like [27] and [28]) achieves Route Optimization by having the Mobile Router act as a Neighbor Discovery [29] proxy for its Mobile Network Nodes 🪞 the Mobile Router configures a Care-of Address from the network prefix advertised by its access router, and also relays this prefix to its subnets 📡 when a Mobile Network Node configures an address from this prefix, the Mobile Router acts as a Neighbor Discovery proxy on its behalf 🫧 this way, the entire mobile network and its access network form one logical multilink subnet, which gets rid of any nesting 🌸
this approach keeps the implementations of Correspondent Nodes unchanged too 💖 but the root Mobile Router has to act as a Neighbor Discovery proxy for ALL the Mobile Network Nodes directly or indirectly attached to it, which piles on processing load 🥵 and a change in the point of attachment of the root Mobile Router will make every nested Mobile Router (and possibly Visiting Mobile Nodes) change their Care-of Addresses 😩 that means a burst of Binding Updates from every Mobile Router and Visiting Mobile Node to their Correspondent Entities, PLUS a burst of Duplicate Address Discovery messages exchanged between the mobile network and the access network 📬 and on top of all that, Route Optimization for Local Fixed Nodes isn't possible without new functionality implemented on the Local Fixed Nodes 🙈
- Hierarchical Registrations
Hierarchical Registration means Mobile Network Nodes (including nested Mobile Routers) register themselves with either their parent Mobile Routers or the root Mobile Router itself 🗂️ after registering, Mobile Network Nodes tunnel packets directly to the upstream Mobile Router they registered with ⬆️ at the root Mobile Router, packets tunneled from sub-Mobile Routers or Mobile Network Nodes get tunneled directly to the Correspondent Entities, so nested tunneling is avoided 🚀
one form of this uses the principle of Hierarchical Mobile IPv6 [13], where the root Mobile Router acts as a Mobility Anchor Point 🏰 it's also possible for each parent Mobile Router to act as a Mobility Anchor Point for its child Mobile Routers, forming a hierarchy of Mobility Anchor Points 🪜 you can also think of these Mobility Anchor Points as local Home Agents, which forms a cascade of mobile Home Agents 🎀 this way, each Mobile Router terminates its tunnel at its parent Mobile Router 🧁 so although there are as many tunnels as there are levels of nesting, no tunnel is encapsulated within another one ✨
examples of this approach include [30], [31], [32], and [33] 🦋
an advantage here is that the functionality of the Correspondent Nodes stays unchanged 🫶
- Mobile Ad-Hoc Routing
it's possible for nodes within a mobile network to use Mobile Ad-hoc routing to forward packets between nodes in the same mobile network 🕸️ one way to do this involves a router acting as a gateway that connects the nodes in the mobile network to the global Internet 🌐 all the nodes in the mobile network would configure their Care-of Addresses from one or more prefixes advertised by that gateway, while their parent Mobile Routers use Mobile Ad-hoc routing to forward packets to that gateway or to other destinations inside the mobile network 🧚
one advantage common to ALL the approaches above is that local mobility of a Mobile Network Node within a nested mobile network is hidden from the Correspondent Entity 🙈💜
5.6. How Is Signaling Performed? 📡
okay so Route Optimization signaling can be done in-plane, off-plane, or both 🎀 in-plane signaling means embedding signaling info into the headers of data packets 🧩 a really good example is the Reverse Routing Header [10] 💅 off-plane signaling uses dedicated signaling packets instead of stuffing signaling info into data packet headers 📨 anything involving sending Binding Updates falls into this category 🫧
the upside of in-plane signaling is that any change in the mobile network topology can be propagated to the Correspondent Entity super fast, as long as there's a continuous stream of data being transmitted ⚡ BUT this might rack up a substantial overhead on the data packets 😬 off-plane signaling, on the other hand, sends signaling messages independently from the data packets 🌊 this helps cut the signaling overhead when there are relatively few topological changes to the mobile network 📉 the catch is that data packet transmission may get disrupted while off-plane signaling is happening 💀
there's also a totally different method that uses upper-layer protocols to establish the bindings between the address of a Mobile Network Node and the location of the mobile network 🌈 that binding info can then be passed down to the IP layer to insert the right entry in the Binding Cache or routing table 🍓 an example of this is [34], which uses the Session Initiation Protocol (SIP) to relay binding information 🧚♀️
5.7. How Is Data Transmitted? 📦
Okay bestie, so Route Optimization is all set up 🎉 but there's one last big question: how do the actual data packets follow that fancy optimized route? There are three possible approaches, and I'm spilling all of them 🫶
- Encapsulations 🎁
One way to send packets down the optimized path is IP-in-IP encapsulation [35]. The original packet gets tucked inside another packet and tunneled to the location bound to the Mobile Network Node's address, using the normal routing infrastructure. How many encapsulations you need can vary depending on how that location is bound to the address, so it's very much a "depends on the setup" situation 🙈
For instance, if the Correspondent Entity knows the full sequence of points of attachment, it might need multiple encapsulations so the data packet can be forwarded through each point of attachment. That can mean multiple tunnels and extra packet header overhead 😭 The fix? Robust Header Compression techniques [36][37][38] can be used to compress those multiple tunnel packet headers ✨
- Routing Headers 🛤️
Second option: use routing headers 🧚 This is especially useful when the Correspondent Entity knows the sequence of locations of upstream Mobile Routers (see Section 5.5.2), because one routing header can hold multiple intermediate destinations. Each intermediate destination corresponds to a point of attachment bound to the Mobile Network Node's address.
This requires a new Routing Header type, or possibly an extension of the Type 2 Routing Header as defined by Mobile IPv6, so it can contain multiple addresses instead of only one 💅
- Routing Entries in Parent Mobile Routers 🗺️
Last but not least, parent Mobile Routers can install routing entries in their routing table so that Route Optimized packets get routed differently, most likely based on source address routing 👑 This usually applies to the approaches in Section 5.5.3. For instance, the Prefix Delegation approach [24][25][26] would require parent Mobile Routers to route packets differently if the source address belongs to the prefix delegated from the access network 🌸
5.8. What Are the Security Considerations? 🔐
5.8.1. Security Considerations of Address Binding
Okay, this part is super important 😭 The biggest security consideration in Route Optimization is definitely the risk a Correspondent Entity is exposed to when it creates a binding between the address of a Mobile Network Node and the specified location(s) of the mobile network. Generally, it's assumed that the Correspondent Entity and Mobile Network Node don't share any pre-existing security association. However, the Correspondent Entity must have some way of verifying the authenticity of the binding specified, or else it will be susceptible to various attacks described in [19], such as snooping (sending packets meant for a Mobile Network Node to an attacker) or denial-of-service (DoS) (flooding a victim with packets meant for a Mobile Network Node) attacks 💀
When the binding is between the address of the Mobile Network Node and one Care-of Address (possibly of the Mobile Router; see Section 5.5.1 and Section 5.5.3), the standard Return Routability procedure specified in Mobile IPv6 might be enough to give the Correspondent Entity a reasonable degree of assurance 🦋 This also lets the Correspondent Entity re-use existing implementations. But in other situations, an extension to the Return Routability procedure might be necessary.
Here's an example 🙈 Say the Mobile Router sends a Binding Update containing Mobile Network Prefix information to the Correspondent Entity (see Section 5.5.1). The Return Routability procedure lets the Correspondent Entity verify that the Care-of and Home Addresses of the Mobile Router are indeed collocated, but it does not let it verify the validity of the Mobile Network Prefix. If the Correspondent Entity accepts the binding without verifying it, it's open to attacks where an attacker tricks it into forwarding packets destined for a mobile network to the attacker (snooping) or to a victim (DoS). [39] discusses this threat further 😱
The need to verify network prefixes isn't limited to Correspondent Entities, either. In approaches involving Correspondent Routers (see Section 5.1.3), there have been suggestions that a Correspondent Router advertise the network prefix(es) of Correspondent Nodes it can terminate Route Optimization on behalf of for Mobile Network Nodes. In those cases, the Mobile Network Nodes also need a mechanism to check the authenticity of such claims. Even if Correspondent Routers don't advertise the network prefix, Mobile Network Nodes still need to verify that the Correspondent Router really is a valid Correspondent Router for a given Correspondent Node 🫠
In Section 5.5.2, the registration signaling involves sending information about one or more upstream Mobile Routers. The Correspondent Entity (or Home Agent) must also have the means to verify that information. Again, the standard Return Routability procedure defined in [3] isn't good enough here, because it wasn't designed to verify the reachability of an address over a series of upstream routers. An extension, such as attaching a routing header to the Care-of Test (CoT) message to verify the authenticity of the locations of upstream Mobile Routers, is likely to be needed 🧩 The risk isn't limited to Correspondent Entities, though. Mobile Network Nodes are also under threat of receiving false information from their upstream Mobile Routers, which they might then pass on to Correspondent Entities. (This also implies that Correspondent Entities can't rely on any security associations they have with the Mobile Network Nodes to establish the validity of address bindings.) There are some considerations suggesting this kind of on-path threat exists in the current Internet anyway, especially when no (or weak) end-to-end protection is used 👀
All these authenticity concerns might suggest that a more radical and robust approach is needed 🌈 That's currently under extensive study in various IETF Working Groups, and lots of related documents might be of interest. For instance, in Secure Neighbor Discovery (SEND) [40], Cryptographically Generated Addresses (CGAs) [41] could be used to establish ownership of Care-of Addresses. [42] uses the Home Agent to check the signaling messages sent by Mobile Routers, giving Correspondent Entities a way to verify the authenticity of the Mobile Network Prefixes specified. [18] documents various proposed enhancements to the Mobile IPv6 Route Optimization mechanism that might also apply to NEMO Route Optimization, such as [43], which lets a Correspondent Entity authenticate a certain operator's Home Agent by verifying the associated certificate. The Host Identity Protocol (HIP) [44], with its end-host mobility considerations [45], may also be extended for NEMO Route Optimization 🦋
If you want to go deeper, [46] discusses the general problem of making Route Optimization in NEMO secure and explores some possible solution schemes 📚 There's also a proposed mechanism in [23] for Mobile Network Nodes to delegate some rights to their Mobile Routers. That could let Mobile Routers prove their authenticity to Correspondent Entities when establishing Route Optimization sessions on behalf of the Mobile Network Nodes 💜
5.8.2. End-to-End Integrity
Okay, next up is end-to-end integrity, and it's a whole vibe 😭 In some approaches, such as "Mobile Router as a Proxy" in Section 5.5.1, the Mobile Router sends messages using the Mobile Network Node's address as the source address. This is mainly done to require zero new functionality at the Correspondent Entities and Mobile Network Nodes ✨ However, this strategy may interfere with existing or future protocols, most especially security-related ones. It's especially true when the Mobile Router needs to change packets sent by Mobile Network Nodes. In a sense, these approaches break the end-to-end integrity of packets 💔 A related concern is that this kind of approach may also require the Mobile Router to inspect the packet contents sent to or from Mobile Network Nodes. That may prove difficult or impossible if those contents are encrypted 🔒
The end-to-end integrity concern also comes up with a Reverse Routing Header (see Section 5.5.2), since Mobile Routers would insert new content into the header of packets sent by downstream Mobile Network Nodes. That makes it hard for Mobile Network Nodes to protect the end-to-end integrity of that information with security associations 🫣
5.8.3. Location Privacy
Another security-related concern is location privacy 🕵️♀️ This document currently doesn't consider the location privacy threats caused by an on-path eavesdropper. For more on that, please refer to [18]. Instead, we look at the following three aspects of location privacy:
- Revelation of Location to Correspondent Entity 📍
Route optimization works by creating a binding between the address of the Mobile Network Node and the current location of the Mobile Network, so it's inevitable that the location of the Mobile Network Node gets revealed to the Correspondent Entity 😬 The concern may be eased if the Correspondent Entity is not the Correspondent Node, since that means the actual traffic endpoint (i.e., the Correspondent Node) would stay in the dark about the current location of the Mobile Network Node 🙈
- Degree of Revelation 🌡️
With network mobility, how much location gets exposed varies, especially with nested mobile networks. For instance, for approaches that bind the address of the Mobile Network Node to the location of the root Mobile Router (see Section 5.5.3), only the topmost point of attachment of the mobile network is revealed to the Correspondent Entity. For approaches such as those in Section 5.5.1 and Section 5.5.2, more information is revealed, such as Mobile Network Prefixes and the current locations of upstream Mobile Routers. Techniques like exposing only locally-scoped addresses of intermediate upstream mobile routers to Correspondent Entities may be used to reduce the degree of revelation 🎀
- Control of the Revelation 👑
When Route Optimization is initiated by the Mobile Network Node itself, the Mobile Network Node is in control of whether to sacrifice location privacy for an optimized route. However, if the Mobile Router initiates Route Optimization (e.g., "Binding Update with Mobile Network Prefix" and "Mobile Router as a Proxy" in Section 5.5.1), then that control is taken away from the Mobile Network Node 😤 An additional signaling mechanism between the Mobile Network Node and its Mobile Router can be used in this case to stop the Mobile Router from attempting Route Optimization for a given traffic stream 🛑
6. Conclusion 🎀
okay so the NEMO Route Optimization problem space is honestly multifold 💅 and it can be split into several work areas. What really matters is that a solution for one piece of the puzzle has to play nicely and fit smoothly with the others 🫶. With that in mind, this document takes a detailed, in-depth look at the NEMO Route Optimization solution space. First it covers the benefits a Route Optimization solution is expected to bring ✨, then it shows the different scenarios where one applies 🗺️, and then it walks through some issues a solution might run into 😭. We also asked ourselves some of the basic questions about a Route Optimization solution, and by exploring different possible answers we got to see lots of different aspects of it 🧠. The whole goal is to help us all have a better shared understanding of the Route Optimization problem and solution space 💜.
7. Security Considerations 🔐
this is an informational document that analyzes the solution space of NEMO Route Optimization 📚. The security considerations for each approach are described in the relevant sections throughout the document, so keep an eye out 👀. If you want the quick version of the security concern around Route Optimization in general, check out Section 4.9 🔍. For the full, more detailed breakdown of the various Route Optimization approaches, go to Section 5.8 💀. Seriously, don't skip these, they're the stuff that keeps the whole thing from falling apart 🚨.
8. Acknowledgments 🌸
the authors want to thank the co-authors of the previous versions this document grew out of: Marco Molteni, Paik Eun-Kyoung, Hiroyuki Ohnishi, Felix Wu, and Souhwan Jung 🫶. They also want to send sincere appreciation to Jari Arkko, Carlos Jesus Bernardos, Greg Daley, Thierry Ernst, T.J. Kniveton, Erik Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa, and Patrick Wetterwald for all their various contributions 💖. Iconic group effort, honestly 👑.
9. References 📖
9.1. Normative References
- [1] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007.
- [2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
- [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [4] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007.
- [5] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
- [6] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
9.2. Informative References
- [7] Wakikawa, R., Koshiba, S., Uehara, K., and J. Murai, "ORC: Optimized Route Cache Management Protocol for Network Mobility", 10th International Conference on Telecommunications, vol 2, pp 1194-1200, February 2003.
- [8] Wakikawa, R. and M. Watari, "Optimized Route Cache Protocol (ORC)", Work in Progress, November 2004.
- [9] Na, J., Cho, S., Kim, C., Lee, S., Kang, H., and C. Koo, "Route Optimization Scheme based on Path Control Header", Work in Progress, April 2004.
- [10] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its application to Mobile Networks", Work in Progress, February 2007.
- [11] Ng, C. and T. Tanaka, "Securing Nested Tunnels Optimization with Access Router Option", Work in Progress, July 2004.
- [12] Na, J., Cho, S., Kim, C., Lee, S., Kang, H., and C. Koo, "Secure Nested Tunnels Optimization using Nested Path Information", Work in Progress, September 2003.
- [13] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.
- [14] Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA to HA protocol", Work in Progress, September 2006.
- [15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
- [16] Baek, S., Yoo, J., Kwon, T., Paik, E., and M. Nam, "Routing Optimization in the same nested mobile network", Work in Progress, October 2005.
- [17] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
- [18] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization", RFC 4651, February 2007.
- [19] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
- [20] Bernardos, C., Bagnulo, M., and M. Calderon, "MIRON: MIPv6 Route Optimization for NEMO", 4th Workshop on Applications and Services in Wireless Network, Online: http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf, August 2004.
- [21] Calderon, M., Bernardos, C., Bagnulo, M., Soto, I., and A. Oliva, "Design and Experimental Evaluation of a Route Optimisation Solution for NEMO", IEEE Journal on Selected Areas in Communications (J-SAC), vol 24, no 9, September 2006.
- [22] Bernardos, C., Bagnulo, M., Calderon, M., and I. Soto, "Mobile IPv6 Route Optimisation for Network Mobility (MIRON)", Work in Progress, July 2005.
- [23] Ylitalo, J., "Securing Route Optimization in NEMO", Workshop of 12th Network and Distributed System Security Syposuim, NDSS Workshop 2005, online: http://www.isoc.org/isoc/conferences/ndss/05/workshop/ylitalo.pdf, February 2005.
- [24] Perera, E., Lee, K., Kim, H., and J. Park, "Extended Network Mobility Support", Work in Progress, July 2003.
- [25] Lee, K., Park, J., and H. Kim, "Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation", 58th IEEE Vehicular Technology Conference, vol 3, pp 2035-2038, October 2003.
- [26] Lee, K., Jeong, J., Park, J., and H. Kim, "Route Optimization for Mobile Nodes in Mobile Network based on Prefix Delegation", Work in Progress, February 2004.
- [27] Jeong, J., Lee, K., Park, J., and H. Kim, "Route Optimization based on ND-Proxy for Mobile Nodes in IPv6 Mobile Network", 59th IEEE Vehicular Technology Conference, vol 5, pp 2461-2465, May 2004.
- [28] Jeong, J., Lee, K., Kim, H., and J. Park, "ND-Proxy based Route Optimization for Mobile Nodes in Mobile Network", Work in Progress, February 2004.
- [29] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
- [30] Kang, H., Kim, K., Han, S., Lee, K., and J. Park, "Route Optimization for Mobile Network by Using Bi-directional Between Home Agent and Top Level Mobile Router", Work in Progress, June 2003.
- [31] Lee, D., Lim, K., and M. Kim, "Hierarchical FRoute Optimization for Nested Mobile Network", 18th Int'l Conf on Advance Information Networking and Applications, vol 1, pp 225-229, 2004.
- [32] Takagi, Y., Ohnishi, H., Sakitani, K., Baba, K., and S. Shimojo, "Route Optimization Methods for Network Mobility with Mobile IPv6", IEICE Trans. on Comms, vol E87-B, no 3, pp 480-489, March 2004.
- [33] Ohnishi, H., Sakitani, K., and Y. Takagi, "HMIP based Route optimization method in a mobile network", Work in Progress, October 2003.
- [34] Lee, C., Zheng, J., and C. HUang, "SIP-based Network Mobility (SIP-NEMO) Route Optimization (RO)", Work in Progress, October 2006.
- [35] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
- [36] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
- [37] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
- [38] Minaburo, A., Paik, E., Toutain, L., and J. Bonnin, "ROHC (Robust Header Compression) in NEMO network", Work in Progress, July 2005.
- [39] Ng, C. and J. Hirano, "Extending Return Routability Procedure for Network Prefix (RRNP)", Work in Progress, October 2004.
- [40] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
- [41] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
- [42] Zhao, F., Wu, F., and S. Jung, "Extensions to Return Routability Test in MIP6", Work in Progress, February 2005.
- [43] Bao, F., Deng, R., Qiu, Y., and J. Zhou, "Certificate-based Binding Update Protocol (CBU)", Work in Progress, March 2005.
- [44] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", Work in Progress, April 2007.
- [45] Henderson, T., "End-Host Mobility and Multihoming with the Host Identity Protocol", Work in Progress, March 2007.
- [46] Calderon, M., Bernardos, C., Bagnulo, M., and I. Soto, "Securing Route Optimization in NEMO", Third International Symposium on Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks, WIOPT 2005, pages 248-254, April 2005.
Authors' Addresses 📮
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate, Singapore 534415
SG
Phone: +65 65505420
EMail: chanwah.ng@sg.panasonic.com
Fan Zhao
University of California Davis
One Shields Avenue
Davis, CA 95616
US
Phone: +1 530 752 3128
EMail: fanzhao@ucdavis.edu
Masafumi Watari
KDDI R&D Laboratories Inc.
2-1-15 Ohara
Fujimino, Saitama 356-8502
JAPAN
EMail: watari@kddilabs.jp
Pascal Thubert
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3, Biot - Sophia Antipolis 06410
FRANCE
EMail: pthubert@cisco.comFull Copyright Statement ⚖️
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
Okay bestie, this part is all about who owns what 💅 The IETF is NOT picking a side on whether any intellectual property rights or patents might apply to the tech in this doc, or whether you can get a license for them. They also haven't gone digging to find any of that stuff 🙈 If you want the rules on rights in RFC documents, check out BCP 78 and BCP 79 ✨
Copies of IPR disclosures that were sent to the IETF Secretariat are available, along with any licensing assurances, and the outcome of any attempt to get a general license or permission for implementers or users to use proprietary rights. You can find all of that on the IETF on-line IPR repository at http://www.ietf.org/ipr 🗂️🦋
The IETF also invites anyone to tell them about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌 Honestly it's giving transparency 🌈
Acknowledgement
Quick shoutout 🫶 The RFC Editor function is currently funded by the Internet Society. The IETF is grateful for that support 💖
📦 where this page comes from
- ietf: rfc4889 2007-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms