RFC 4888
Network Mobility Route Optimization Problem Statement
RFC 4888: Network Mobility Route Optimization Problem Statement 🎀
okay bestie, this one's a July 2007 Informational doc, so it's not a standard, it's a "here's the problem, please fix it" memo ✨ It's written by C. Ng (Panasonic Singapore Labs), P. Thubert (Cisco Systems), M. Watari (KDDI R&D Labs), and F. Zhao (UC Davis). It doesn't list any RFCs it obsoletes or updates in its title block 🦋
Status of This Memo 💅
this memo is just giving info to the Internet community. it's not specifying an Internet standard of any kind, and distribution of it is unlimited 🫶
Copyright Notice 🔥
Copyright (C) The IETF Trust (2007).
Abstract 🌸
okay so with current Network Mobility (NEMO) Basic Support, every single thing going to and from Mobile Network Nodes has to take the bi-directional tunnel between the Mobile Router and Home Agent whenever the mobile network is away. that's sub-optimal routing, and it's giving slow delays and bottleneck links that cause traffic congestion 😭 which can totally wreck all communication to and from those nodes. and it gets worse with nested mobile networks, because the inefficiencies stack up and you can end up in stalemate conditions 💀 this doc digs into all that and explains why Route Optimization (RO) for NEMO is needed 🧚
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. NEMO Route Optimization Problem Statement . . . . . . . . . . 3
2.1. Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4
2.2. Bottleneck in the Home Network . . . . . . . . . . . . . . 6
2.3. Amplified Sub-Optimality in Nested Mobile Networks . . . . 6
2.4. Sub-Optimality with Combined Mobile IPv6 Route
Optimization . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Security Policy Prohibiting Traffic from Visiting Nodes . 9
2.6. Instability of Communications within a Nested Mobile
Network . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7. Stalemate with a Home Agent Nested in a Mobile Network . . 10
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative Reference . . . . . . . . . . . . . . . . . . . 12
6.2. Informative Reference . . . . . . . . . . . . . . . . . . 12
Appendix A. Various Configurations Involving Nested Mobile
Networks . . . . . . . . . . . . . . . . . . . . . . 13
A.1. CN Located in the Fixed Infrastructure . . . . . . . . . . 13
A.1.1. Case A: LFN and Standard IPv6 CN . . . . . . . . . . . 14
A.1.2. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 14
A.1.3. Case C: VMN and Standard IPv6 CN . . . . . . . . . . . 14
A.2. CN Located in Distinct Nested NEMOs . . . . . . . . . . . 15
A.2.1. Case D: LFN and Standard IPv6 CN . . . . . . . . . . . 16
A.2.2. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 16
A.2.3. Case F: VMN and Standard IPv6 CN . . . . . . . . . . . 16
A.3. MNN and CN Located in the Same Nested NEMO . . . . . . . . 17
A.3.1. Case G: LFN and Standard IPv6 CN . . . . . . . . . . . 18
A.3.2. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 18
A.3.3. Case I: VMN and Standard IPv6 CN . . . . . . . . . . . 19
A.4. CN Located Behind the Same Nested MR . . . . . . . . . . . 19
A.4.1. Case J: LFN and Standard IPv6 CN . . . . . . . . . . . 20
A.4.2. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 20
A.4.3. Case L: VMN and Standard IPv6 CN . . . . . . . . . . . 21
Appendix B. Example of How a Stalemate Situation Can Occur . . . 221. Introduction ✨
okay so with current Network Mobility (NEMO) Basic Support [1], all communications to and from nodes in a mobile network have to go through the bi-directional tunnel between the Mobile Router and its Home Agent (aka the MRHA tunnel) whenever the mobile network is away 🫶 the setup does let Mobile Network Nodes reach and be reached by any node on the Internet, which is cute, but the limits of the base protocol drag down overall network performance and can ultimately block all communication to and from those nodes 😭
some of these problems already exist in Mobile IPv6 [4], and they got fixed by a mechanism called Route Optimization, which is part of the base protocol 💜 with Mobile IPv6, Route Optimization mostly improves the end-to-end path between the Mobile Node and Correspondent Node. it also reduces the load on the Home Network, which is where the name comes from 🌈
NEMO Basic Support has a bunch more issues that make the problem way more complex, so the group decided to handle Route Optimization separately 🦋 the expected benefits are more dramatic here, and a Route Optimization mechanism could enable connectivity that would otherwise be broken. so yeah, Route Optimization is even more important for NEMO Basic Support than it is for Mobile IPv6 👑
this doc looks at the limits built into NEMO Basic Support and how they affect communications between a Mobile Network Node and its corresponding peer. that's all laid out in Section 2. readers are expected to already know the general mobility terms from [4][2], the NEMO-related terms defined in [3], and the NEMO goals and requirements in [5] 🧚
2. NEMO Route Optimization Problem Statement 💖
okay so with NEMO Basic Support, all data packets to and from Mobile Network Nodes have to go through the Home Agent, even when there's a shorter path between the Mobile Network Node and its Correspondent Node 🙈 and when Mobile Routers are nested, those packets have to bounce through multiple Home Agents and several layers of encapsulation, which could have been avoided 😭 that causes all kinds of inefficiencies and packet delivery problems, which can ultimately disrupt all communication to and from the Mobile Network Nodes.
the subsections go through the effects of a pinball route with NEMO Basic Support, how it can form a bottleneck in the Home Network, and how nesting makes all of that worse 🔥 we'll also look at the sub-optimality you get even when Mobile IPv6 Route Optimization is running on top of NEMO Basic Support. then there's the home network security policy that might forbid transit traffic from Visiting Mobile Nodes in mobile networks 💀 we'll also dig into how the MRHA tunnel affects communication between two Mobile Network Nodes on different links of the same mobile network. and finally, we'll give more reasons for Route Optimization by looking at the possible stalemate when a Home Agent is part of a mobile network 🍓
2.1. Sub-Optimality with NEMO Basic Support 🦋
with NEMO Basic Support, every packet between a Mobile Network Node and its Correspondent Node gets forwarded through the MRHA tunnel, so you end up with a pinball route between the two nodes 🎀 that causes these sub-optimal effects:
- Longer Route Leading to Increased Delay and Additional Infrastructure Load 🐢
okay so a packet has to go from the mobile network to the Home Agent and then to the Correspondent Node, which means it usually takes longer than if it just went straight from the mobile network to the Correspondent Node 😭 if the Correspondent Node (or the mobile network) is near the Home Agent, the extra delay can be really small. but if the mobile network and the Correspondent Node are close to each other and far from the Home Agent on the Internet, the extra delay is huge 💀 real-time multimedia streaming might not be able to handle that much extra packet delay. and in general, the extra delay can also hurt transport protocols like TCP, since TCP's sending rate is partly set by the round-trip time (RTT) the communication peers see ✨
on top of that, a longer route means the total resource utilization for the traffic is way higher than if the packets went on a direct path between the Mobile Network Node and Correspondent Node 🫶 that adds extra load to the infrastructure.
- Increased Packet Overhead 📦
the MRHA tunnel encapsulates packets, which adds an outer header and makes packets bigger 😤 that lowers bandwidth efficiency, because an IPv6 header can be super big compared to the payload for stuff like voice samples 🙈 for example, say a voice app uses an 8 kbps algorithm (e.g., G.729) and takes a voice sample every 20 ms (as in RFC 1889 [6]). then the packet transmission rate is 50 packets per second. each extra IPv6 header is 320 bits per packet (i.e., 16 kbps), which is literally twice the actual payload! 💅
- Increased Processing Delay ⏳
encapsulating packets in the MRHA tunnel also adds processing delay at the points of encapsulation and decapsulation 🌸 that extra processing can include encryption/decryption, topological correctness verifications, MTU computation, fragmentation, and reassembly.
- Increased Chances of Packet Fragmentation 🧩
the bigger packets from encapsulation can raise the chances of getting fragmented along the MRHA tunnel 😬 that can happen if no path MTU discovery was done beforehand, or if the MTU discovery mechanism didn't account for the encapsulation. and fragmentation means even more packet delay and even less bandwidth efficiency 💔
- Increased Susceptibility to Link Failure 🔗
assuming each link has the same chance of failing, a longer routing path is more likely to hit a link failure 🥺 so packets going through the MRHA tunnel might have a higher chance of being lost or delayed by a link failure, compared to packets that travel directly between the Mobile Network Node and its Correspondent Node 🌧️
2.2. Bottleneck in the Home Network 🏠✨
okay so forget latency for a sec 💅 forwarding everything through the Home Agent can also turn the Home Agent or the Home Link into a bottleneck for ALL the aggregated traffic going to and from every Mobile Network Node 😭 if home gets congested you get extra packet delay or even straight-up packet loss, which is not the vibe. and the Home Agent doesn't always handle the fancy stuff (security checks, packet interception, tunneling) as efficiently as it handles plain forwarding, so its capacity for data can get squeezed even more 🫠 on top of that, every single packet has to pass through the Home Link, so the Home Link becomes a single point of failure for the whole mobile network. main character problem, but make it a liability 💀
data packets that get delayed or dropped because of congestion at the Home Network take a real hit on app performance 📉 and signaling packets like Binding Update messages are even more sensitive. if those get delayed or discarded at home, they can mess up setting up or updating the bi-directional tunnels, and then ALL the traffic riding through those tunnels gets disrupted 😵💫
a NEMO Route Optimization mechanism lets Mobile Network Nodes talk to their Correspondent Nodes over a path that's different from the MRHA tunneling, so the Home Agent gets skipped 🦋 that could ease or even prevent congestion at the Home Agent or Home Link. honestly, a whole glow-up for the home side 🌸
2.3. Amplified Sub-Optimality in Nested Mobile Networks 🪆
okay so mobile nodes can join a mobile network, especially mobile routers, which means you can get arbitrary levels of nesting 🤯 and with nesting, NEMO Basic Support makes the routing sub-optimality even worse. we call this the amplification effect of nesting: the gross pinball route effects from NEMO Basic Support get amplified at every single level of nesting. this is way easier to see with the example in Figure 1 👀
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +------------------------------+
| MR1_HA |----| Internet |-----CN1
+--------+ +------------------------------+
|
+---+---+
root-MR | MR1 |
+-------+
| |
+-------+ +-------+
sub-MR | MR2 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR3 | | MR5 |
+---+---+ +---+---+
| |
----+---- ----+----
MNN CN2Figure 1: An Example of a Nested Mobile Network
so with NEMO Basic Support, packets between a Mobile Network Node (MNN) and a Correspondent Node (CN1) have to go through three separate tunnels, as shown in Figure 2 🧵
----------.
---------/ /----------.
-------/ | | /-------
MNN -----( - - | - - - | - - - | - - - | - - (------ CN1
MR3-------\ | | \-------MR3_HA
MR2--------\ \----------MR2_HA
MR1---------MR1_HAFigure 2: Nesting of Bi-Directional Tunnels
and this causes some real problems 😩
- Pinball Route
both inbound and outbound packets bounce through the Home Agents of every Mobile Router on their path inside the mobile network. result: more latency, less resilience, and more bandwidth eaten up 🎈 Appendix A breaks down exactly what the routes look like under different nesting setups for the Mobile Network Nodes.
- Increased Packet Size
every level of nesting adds an extra IPv6 header to ALL the packets 📦 the header compression suggested in [7] can't be applied, because the source and destination (the intermediate Mobile Router and its Home Agent) are different hop to hop. not it 🙅♀️
nesting also makes it more likely that the Home Networks of the upstream Mobile Routers get congested 📈 and the Home Link of each upstream Mobile Router is a single point of failure for the nested Mobile Router too. so many weak links, bestie 💔
2.4. Sub-Optimality with Combined Mobile IPv6 Route Optimization 🔁
when a Mobile IPv6 host joins a mobile network, it becomes a Visiting Mobile Node of that mobile network 🧚 packets to and from it don't just go through its own Home Agent, they also have to go through the Home Agent of the Mobile Router in the mobile network. this has the same amplification effect of nested mobile networks we talked about in Section 2.3. ugh 😤
even though Mobile IPv6 [4] lets a mobile host do Route Optimization with its Correspondent Node to skip tunneling with its Home Agent, that "optimized" route is no longer optimized once the mobile host is attached to a mobile network 🙃 the route between the mobile host and its Correspondent Node still gets hit by the sub-optimality from the MRHA tunnel. if you want examples of how routes look with nested Mobile IPv6 hosts in mobile networks, check out Appendix A 📚
and the readers should know the same sub-optimality applies when the mobile host is outside the mobile network while its Correspondent Node is inside it 💅
2.5. Security Policy Prohibiting Traffic from Visiting Nodes 🔐
NEMO Basic Support says all traffic from visitors has to be tunneled to the Mobile Router's Home Agent 😬 this could be a breach of Home Network security (some specific attacks against the Mobile Router's binding by rogue visitors have been documented in [8][9]). admins might be scared that malicious packets could sneak into the Home Network through the bi-directional tunnel. so, in lots of deployments, policies get put in place to stop unauthorized Visiting Mobile Nodes from attaching to the Mobile Router 🚫
BUT there are also deployments where letting unauthorized Visiting Mobile Nodes in is actually desirable ✨ for example, when Mobile Routers attach to other Mobile Routers and form a nested NEMO, they rely on each other to reach the Internet 🫶 if Mobile Routers don't know each other beforehand (no security association, Authentication, Authorization, and Accounting (AAA), Public-Key Infrastructure (PKI), etc.), it could still be fine to forward their packets, as long as those packets aren't tunneled back to the Home Networks.
a Route Optimization mechanism that lets traffic from Mobile Network Nodes skip the bi-directional tunnel between a Mobile Router and its Home Agent would be a necessary first step toward a Tit for Tat model 🤝 where MRs get reciprocal altruism, based on anonymity and innocuousness, to dynamically extend the Internet infrastructure. this is giving cooperative internet energy 🌈
2.6. Instability of Communications within a Nested Mobile Network 🫨
inside a nested mobile network, two Mobile Network Nodes can talk to each other 💬 take the Figure 1 example where MNN and CN2 are sharing a session. with NEMO Basic Support, a packet from MNN to CN2 has to be forwarded to the Home Agent of each Mobile Router before it reaches CN2 😩 but a packet on the direct path between them doesn't even need to leave the mobile network. Appendix A.3 has the detailed routing paths if you want the full tea ☕
besides the increased delay and packet size we already covered, there are two more undesirable effects 👇
- when the nested mobile network gets disconnected from the Internet (e.g., MR1 loses its egress connectivity), MNN and CN2 can't communicate with each other anymore, even though the direct path from MNN to CN2 is totally fine 💀
- the egress link(s) of the root Mobile Router (i.e., MR1) becomes a bottleneck for all the traffic coming in and going out of the nested mobile network 🚧
a Route Optimization mechanism could let traffic between two Mobile Network Nodes nested in the same mobile network take a direct path between them, without leaving the mobile network 🦋 this might also take some processing load off the upstream Mobile Routers when the direct path between the two Mobile Network Nodes doesn't go through them. big relief for those routers 🙌
2.7. Stalemate with a Home Agent Nested in a Mobile Network 🥴
several Home Network configurations are described in [10] 📖 there's a mobile home scenario where a (parent) Mobile Router is also a Home Agent for its own mobile network. basically, the mobile network is an aggregation of Mobile Network Prefixes assigned to (child) Mobile Routers 🪆
now here's the stalemate 😭 the parent Mobile Router visits one of its children. the child Mobile Router can't find its Home Agent on the Internet, so it can't set up its MRHA tunnel and forward the visitor's traffic. the parent's traffic gets stuck and can't reach the Internet, so it never binds to its own (grandparent) Home Agent. Appendix B has a detailed walkthrough of how this can happen 🕵️♀️
BUT a Route Optimization mechanism that bypasses the nested tunnel might let the parent's traffic reach the Internet and bind 🙏 then the child Mobile Router could reach its parent and bind in turn. some extra nested Route Optimization solutions might even let the child find its Home Agent inside the nested structure and bind whether or not the Internet is reachable 🔓 the plot twist we needed 🎉
3. Conclusion 📝
with current NEMO Basic Support, every communication to and from Mobile Network Nodes has to go through the MRHA tunnel while the mobile network is away 🧳 that causes a bunch of packet delivery inefficiencies. this document looks into those inefficiencies and gives the motivation behind Route Optimization for NEMO 💖
we covered how the sub-optimal effects of pinball routes with NEMO Basic Support can create a bottleneck in the Home Network, and how they get amplified as mobile networks nest 🪆 these effects still show up even when Mobile IPv6 Route Optimization runs over NEMO Basic Support. we also explored other nesting issues that give more reasons for a NEMO Route Optimization mechanism: forwarding traffic from a Visiting Mobile Node through an MRHA tunnel is prohibited for security reasons, the MRHA tunnel affects communications between two Mobile Network Nodes on different links of the same mobile network, and a stalemate can happen when Home Agents are nested within a mobile network 🫶
4. Security Considerations ✨
okay bestie, this doc is basically spilling the tea on NEMO Basic Support's limitations 🫶 some security concerns could block really cool apps from happening, and we go into that in Section 2.5 💅
also, Route Optimization for RFC 3963 [1] might bring NEW threats 😭 but it might also fix some existing ones. honestly this is gonna be a key criterion when we evaluate the proposed solutions, no cap 🔥
5. Acknowledgments 🌸
the authors wanna give a huge shoutout to the co-authors of the earlier versions this doc came from: Marco Molteni, Paik Eun-Kyoung, Hiroyuki Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung 💖 Masafumi Watari did early work on the extracted appendix while still at Keio University ✨ and sincere thanks also go to Jari Arkko, Carlos Bernardos, Greg Daley, T.J. Kniveton, Henrik Levkowetz, Erik Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa, and Patrick Wetterwald for all their contributions 🧚
6. References 📚
6.1. Normative Reference
- [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
- [2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
- [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
6.2. Informative Reference
- [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [5] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007.
- [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
- [7] Deering, S. and B. Zill, "Redundant Address Deletion when Encapsulating IPv6 in IPv6", Work in Progress, November 2001.
- [8] Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach, "Threats for Basic Network Mobility Support (NEMO threats)", Work in Progress, January 2004.
- [9] Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat Analysis on NEMO Basic Operations", Work in Progress, July 2004.
- [10] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network Mobility Home Network Models", RFC RFC4887, July 2007.
- [11] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
Appendix A. Various Configurations Involving Nested Mobile Networks 🦋
okay so this appendix is where it gets SO good 😭 we're gonna look at different communication models that involve a nested mobile network and untangle the issues for each one 🧶 we trace the path packets take if nodes only use Mobile IPv6 and NEMO Basic Support mechanisms. we cover cases where the Correspondent Node is in the fixed infrastructure, in a separate nested mobile network as the Mobile Network Node, or in the very same nested mobile network as the Mobile Network Node 🌈 we also check whether the CN and MNN are standard IPv6 nodes or Mobile IPv6 nodes.
and per [3], standard IPv6 nodes are nodes with zero mobility functions, meaning they're not Mobile IPv6 or NEMO enabled 💀 they can't move around keeping connections open, and they can't process Binding Updates sent by peers.
A.1. CN Located in the Fixed Infrastructure 🏢
the most typical setup is when a Mobile Network Node talks to a Correspondent Node attached to the fixed infrastructure ✨ here's an example topology:
+--------+ +--------+ +--------+
| MR1_HA | | MR2_HA | | MR3_HA |
+---+----+ +---+----+ +---+----+
| | |
+-------------------------+
| Internet |----+ CN
+-------------------------+
| |
+---+---+ +--+-----+
root-MR | MR1 | | VMN_HA |
+---+---+ +--------+
|
+---+---+
sub-MR | MR2 |
+---+---+
|
+---+---+
sub-MR | MR3 |
+---+---+
|
----+----
MNN
Figure 3: CN Located at the InfrastructureA.1.1. Case A: LFN and Standard IPv6 CN 🎀
the simplest case is when both MNN and CN are fixed nodes with no mobility functions 💅 so MNN is a Local Fixed Node and CN is a standard IPv6 node. packets get encapsulated between each Mobile Router and its own Home Agent (HA) 🌸 in this case the path between the two nodes goes through:
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
LFN IPv6 Node
The digits represent the number of IPv6 headers.
Figure 4: MNN and CN Are Standard IPv6 Nodes(the digits just show how many IPv6 headers there are at each hop, fyi 🙈)
A.1.2. Case B: VMN and MIPv6 CN 🦋
in this second case, both end nodes are Mobile IPv6-enabled, so MNN is a Visiting Mobile Node 💜 Mobile IPv6 Route Optimization may be started between the two, and packets would NOT go through the Home Agent of the Visiting Mobile Node or the Home Agent of the Correspondent Node (not shown in the figure) 👑 BUT packets still get tunneled between each Mobile Router and its own Home Agent, in both directions 😭 the path between MNN and CN goes through:
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
VMN MIPv6
Figure 5: MNN and CN Are MIPv6 Mobile NodesA.1.3. Case C: VMN and Standard IPv6 CN 🍓
when the communication involves a Mobile IPv6 node, either as a Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 Route Optimization can't happen 💀 the reason is the standard IPv6 Correspondent Node can't process Mobile IPv6 signaling. so MNN ends up setting up a bi-directional tunnel with its HA, which makes the flow leave the nested NEMO 🚪 packets between MNN and CN go through MNN's own Home Agent (VMN_HA) 🌈 the path looks like Figure 6:
2 3 4 5 4
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA
VMN |
| 3
1 2 |
CN --- VMN_HA --- MR3_HA
IPv6 Node
Figure 6: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Nodeand providing Route Optimization involving a Mobile IPv6 node may require optimization among the Mobile Routers and the Mobile IPv6 node too 🧠
A.2. CN Located in Distinct Nested NEMOs 🌍
the Correspondent Node might be in another nested mobile network, one that's different from the one MNN is attached to ✨ see Figure 7 below. we call this setup "distinct nested mobile networks" 💖
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
| |
+---+---+ +---+---+
root-MR | MR1 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR2 | | MR5 |
+---+---+ +---+---+
| |
+---+---+ ----+----
sub-MR | MR3 | CN
+---+---+
|
----+----
MNN
Figure 7: MNN and CN Located in Distinct Nested NEMOsA.2.1. Case D: LFN and Standard IPv6 CN 💫
just like Case A, we start with the case where neither end node has any mobility functions 🫶 packets get encapsulated at every Mobile Router on the way out of the nested mobile network, decapsulated by the Home Agents, and then encapsulated again on their way down the nested mobile network 🌸
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
IPv6 Node
Figure 8: MNN and CN Are Standard IPv6 NodesA.2.2. Case E: VMN and MIPv6 CN 🧚
similar to Case B, when both end nodes are Mobile IPv6 nodes, the two can start Mobile IPv6 Route Optimization 💜 again, packets will NOT go through the Home Agent of the MNN or the Home Agent of the Mobile IPv6 Correspondent Node (not shown in the figure) 🙈 but packets still get tunneled for each Mobile Router to its Home Agent and back again 😭 so the path between MNN and CN goes through:
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 1
1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
MIPv6 Node
Figure 9: MNN and CN Are MIPv6 Mobile NodesA.2.3. Case F: VMN and Standard IPv6 CN 🌈
similar to Case C, when the communication involves a Mobile IPv6 node, either as a Visiting Mobile Node or as a Correspondent Node, MIPv6 Route Optimization can't be done 💀 because the standard IPv6 Correspondent Node can't process Mobile IPv6 signaling. so MNN ends up setting up a bi-directional tunnel with its Home Agent 🚇 packets between MNN and CN go through MNN's own Home Agent, as shown in Figure 10:
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
1 2 3 2 1 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA
IPv6 Node
Figure 10: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 NodeA.3. MNN and CN Located in the Same Nested NEMO
Okay bestie, Figure 11 is the one where both communicating nodes sit behind different Mobile Routers, but those routers are in the same nested mobile network 💅 So they're both behind the same root Mobile Router. 🌸 Route Optimization can stop packets from getting tunneled outside the nested mobile network, which is iconic ✨
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
|
+---+---+
root-MR | MR1 |
+-------+
| |
+-------+ +-------+
sub-MR | MR2 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR3 | | MR5 |
+---+---+ +---+---+
| |
----+---- ----+----
MNN CN
Figure 11: MNN and CN Located in the Same Nested NEMOA.3.1. Case G: LFN and Standard IPv6 CN
Okay so, we start with the case where neither end node has any mobility functions 🦋 Packets get encapsulated at every Mobile Router on the way out of the nested mobile network via the root Mobile Router, then they're decapsulated and encapsulated again by the Home Agents, and then they make their way back into the nested mobile network through that same root Mobile Router 🔥 So the path between MNN and CN goes through:
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node
Figure 12: MNN and CN Are Standard IPv6 nodesA.3.2. Case H: VMN and MIPv6 CN
Similar to Case B and Case E 🎀 when both end nodes are Mobile IPv6 nodes, the two of them may start Mobile IPv6 Route Optimization, which avoids the packets going through the Home Agent of MNN or the Home Agent of the Mobile IPv6 CN (not shown in the figure). 💜 Buuut packets still get tunneled between each Mobile Router and its own Home Agent in both directions 😭 So the path ends up being the same as Case G, going through:
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
MIPv6 Node
Figure 13: MNN and CN Are MIPv6 Mobile NodesA.3.3. Case I: VMN and Standard IPv6 CN
Same energy as Case C and Case F 🧚 When the communication involves a Mobile IPv6 node, either as a Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 Route Optimization can't be performed 💀 So MNN sets up a bi-directional tunnel with its Home Agent, and packets between MNN and CN go through MNN's own Home Agent. The path looks like Figure 14:
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
|
VMN_HA
|
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node
Figure 14: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 NodeA.4. CN Located Behind the Same Nested MR
Figure 15 is the case where both communicating nodes are connected behind the same nested Mobile Router 👑 The optimization is required when the communication involves MIPv6-enabled nodes 🌈
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
|
+---+---+
root-MR | MR1 |
+---+---+
|
+-------+
sub-MR | MR2 |
+---+---+
|
+---+---+
sub-MR | MR3 |
+---+---+
|
-+--+--+-
MNN CN
Figure 15: MNN and CN Located Behind the Same Nested MRA.4.1. Case J: LFN and Standard IPv6 CN
If both end nodes are Local Fixed Nodes, no special function is needed for optimizing their communication 🍓 The path between the two nodes goes through:
1
MNN --- CN
LFN IPv6 Node
Figure 16: MNN and CN Are Standard IPv6 NodesA.4.2. Case K: VMN and MIPv6 CN
Similar to Case H 🦋 when both end nodes are Mobile IPv6 nodes, the two nodes may initiate Mobile IPv6 Route Optimization. Few packets leave the nested mobile network for the Return Routability initialization, but unlike Case B and Case E, packets do not get tunneled outside the nested mobile network 🙈 So packets between MNN and CN eventually go through:
1
MNN --- CN
VMN MIPv6 Node
Figure 17: MNN and CN are MIPv6 Mobile Nodes⚠️ If the root Mobile Router gets disconnected while the nodes exchange keys for the Return Routability procedure, they may not be able to communicate even though they're on the same link 😭
A.4.3. Case L: VMN and Standard IPv6 CN
When the communication involves a Mobile IPv6 node, either as a Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6 Route Optimization can't be performed 🌸 So even though the two nodes are on the same link, MNN sets up a bi-directional tunnel with its Home Agent, which makes the flow go out the nested mobile network. The path between MNN and CN would need another Home Agent (VMN_HA) for this Mobile IPv6 node, like so:
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
|
VMN_HA
|
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
IPv6 Node
Figure 18: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 NodeHowever, MNN may also decide to use its Care-of Address (CoA) as the source address of the packets 🧚 That way it skips the tunneling with the MNN's Home Agent, which is especially handy for short-term communications that can easily be retried if they fail ✨ Default Address Selection [11] has some mechanisms for controlling how the source address gets chosen 💖
Appendix B. Example of How a Stalemate Situation Can Occur ✨
okay so this one is the example for the stalemate situation from Section 2.7 🎀. it's where a Home Agent of a Mobile Router ends up nested behind that same Mobile Router, and we're gonna walk through a super simple setup where it actually happens 🦋
Picture the setup in Figure 19 below. MR1 is served by HA1/BR and MR2 is served by HA2. the BR part just means HA1 is a border router 💅 Both MR1 and MR2 start out at home. HA2 is tucked inside the first mobile network, so it's basically a "mobile" Home Agent 🧚
/-----CN
+----------+
home link 1 +--------+ | |
----+-----------------| HA1/BR |---| Internet |
| +--------+ | |
| +----------+
+--+--+ +-----+
| MR1 | | HA2 |
+--+--+ +--+--+
| |
-+--------+-- mobile net 1 / home link 2
|
+--+--+ +--+--+
| MR2 | | LFN |
+--+--+ +--+--+
| |
-+--------+- mobile net 2
Figure 19: Initial DeploymentFigure 19: Initial Deployment 🌸 so in this setup, CN and LFN talk over a direct path for as long as both MR1 and MR2 are chilling at home. no encapsulation involved, super clean ✨
next up, MR2's mobile network leaves home and goes visiting a foreign network under an Access Router (AR), like in Figure 20 below 🧳
/-----CN
+----------+
home link 1 +--------+ | |
--+-----------| HA1/BR |---| Internet |
| +--------+ | |
+--+--+ +-----+ +----------+
| MR1 | | HA2 | \
+--+--+ +--+--+ +-----+
| | | AR |
-+--------+- mobile net 1 +--+--+
home link 2 |
+--+--+ +-----+
| MR2 | | LFN |
+--+--+ +--+--+
| |
mobile net 2 -+--------+-
Figure 20: Mobile Network 2 Leaves HomeFigure 20: Mobile Network 2 Leaves Home 🦋
once MR2 gets a Care-of Address under AR, the tunnel setup happens between MR2 and HA2. MR2 sends a Binding Update to HA2, and HA2 replies with a Binding Acknowledgement to MR2 🫶 The bi-directional tunnel has MR2 and HA2 as its tunnel endpoints. after the MR2HA2 tunnel is up, the route a packet takes from CN to LFN looks like this:
CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN.so basically non-encapsulated packets get marked ->, and encapsulated packets get marked => 💜
now let's say the first mobile network attaches under the second mobile network, like in Figure 21 below 👑
after that move, MR1 gets a Care-of Address that's valid in the second mobile network. then it sends a Binding Update (BU) message addressed to HA1. this BU gets encapsulated by MR2 and sent toward HA2, which is expected to sit in mobile net 1 and expected to be at home. once HA1/BR gets this encapsulated BU, it tries to deliver it to MR1. but MR1 isn't at home, and there's no tunnel between MR1 and HA1 yet, so HA1 can't route the packet and just drops it 💀 that means the tunnel establishment between MR1 and HA1 isn't possible, because the tunnel between MR2 and HA2 was already torn down when mobile net 1 left home. so the CN and LFN communication stops, even though both mobile networks are connected to the Internet 😭
/-----CN
+----------+
+--------+ | |
| HA1/BR |---| Internet |
+--------+ | |
+----------+
\
+-----+
| AR |
+--+--+
|
+--+--+ +-----+
| MR2 | | LFN |
+--+--+ +--+--+
| |
mobile net 2 -+--------+-
|
+--+--+ +-----+
| MR1 | | HA2 |
+--+--+ +--+--+
| |
mobile net 1 -+--------+-
Figure 21: Stalemate Situation OccursFigure 21: Stalemate Situation Occurs 🔥 this is the stalemate, fr fr
so here's the "crossed over" drama 🍓 if both the tunnel between MR1 and HA1 and the tunnel between MR2 and HA2 were up at the same time, they'd cross over each other. if you drew the MR1-HA1 and MR2-HA2 tunnels onto Figure 21, you'd notice the path of the MR1-HA1 tunnel only includes one endpoint of the MR2-HA2 tunnel, which is the MR2 endpoint. two MR-HA tunnels are crossing over each other if the IP path between the two endpoints of one tunnel includes one and only one endpoint of the other tunnel (assuming both tunnels are up). and when both endpoints of one tunnel are included in the path of the other tunnel, the tunnels are just encapsulating each other 🌈
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.comPascal Thubert
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3, Biot - Sophia Antipolis 06410
FRANCE
EMail: pthubert@cisco.comMasafumi Watari
KDDI R&D Laboratories Inc.
2-1-15 Ohara
Fujimino, Saitama 356-8502
JAPAN
EMail: watari@kddilabs.jpFan Zhao
UC Davis
One Shields Avenue
Davis, CA 95616
US
Phone: +1 530 752 3128
EMail: fanzhao@ucdavis.eduFull 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 🧠
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society.
📦 where this page comes from
- ietf: rfc4888 2007-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms