RFC 4886

Network Mobility Support Goals and Requirements

📅 published July 2007, from ietf

Network Mobility Support Goals and Requirements 🦋

okay bestie, this is RFC 4886 🎀 It's titled "Network Mobility Support Goals and Requirements," written by T. Ernst from INRIA, filed under the Informational category, and dated July 2007. The title block doesn't list any RFCs it obsoletes or updates, so it's a standalone vibe ✨

Status of This Memo 💌

this memo gives info to the Internet community. it does not specify an Internet standard of any kind. distribution of this memo is unlimited, so share it with everyone 🌸

Copyright (C) The IETF Trust (2007). 💜

Abstract 🌈

so network mobility happens when a router that connects a whole network to the Internet changes where it plugs into the Internet, and that moves the whole network's reachability around compared to the fixed Internet topology 🛰️ we call that kind of network a mobile network. with the right mechanisms, sessions between nodes in the mobile network and the global Internet can stay alive even after the mobile router changes its point of attachment ✨ this doc lays out the goals network mobility support should aim for, and defines the requirements that must be met by the NEMO Basic Support solution. literally the blueprint 👑

Table of Contents 📚

1. Introduction ....................................................2
2. NEMO Working Group Objectives and Methodology ...................3
3. NEMO Support Design Goals .......................................5
   3.1. Migration Transparency .....................................5
   3.2. Performance Transparency and Seamless Mobility .............5
   3.3. Network Mobility Support Transparency ......................5
   3.4. Operational Transparency ...................................5
   3.5. Arbitrary Configurations ...................................5
   3.6. Local Mobility and Global Mobility .........................6
   3.7. Scalability ................................................7
   3.8. Backward Compatibility .....................................7
   3.9. Secure Signaling ...........................................7
   3.10. Location Privacy ..........................................8
   3.11. IPv4 and NAT Traversal ....................................8
   3.12. Minimal Impact on Internet Routing ........................8
4. NEMO Basic Support One-Liner Requirements .......................8
5. Security Considerations ........................................10
6. Acknowledgments ................................................11
7. References .....................................................11
   7.1. Normative References ......................................11
   7.2. Informative References ....................................11

1. Introduction ✨

okay so network mobility support (check [1] for the terminology) is all about managing the mobility of an entire network, treated as one single unit that changes where it attaches to the Internet, and therefore its reachability in the Internet topology 🛰️ that network is a mobile network, and it has one or more mobile routers (MRs) connecting it to the global Internet. the nodes behind the MR(s) (MNNs) can be fixed (LFNs) or mobile (VMNs or LMNs) 💅 most of the time the inside of a mobile network is pretty stable (no dynamic topology changes), but that's not always true 🙈

here are some mobile networks you'll actually see:

  • Networks attached to people (Personal Area Networks or PANs) 📱: a cell phone with one cellular interface and one Bluetooth interface, plus a Bluetooth-enabled PDA, is a super simple mobile network. the cell phone is the mobile router, and the PDA is used for web browsing or runs a personal web server 🍓
  • Networks of sensors and computers deployed in vehicles 🚗: vehicles keep getting more processing units for safety and ease of driving, as pushed by ITS (Intelligent Transportation Systems) applications ([4]) 🔥
  • Access networks in public transportation (buses, trains, taxis, aircrafts) 🚌: they give Internet access to IP devices carried by passengers (laptop, camera, mobile phone). they also cover host mobility within network mobility or PANs, and network mobility within network mobility, which is nested mobility (check [1] for the definition of nested mobility) 🪆
  • Ad-hoc networks connected to the Internet via an MR 🚆: think students on a train who need to set up an ad-hoc network among themselves and also get Internet connectivity through the MR connecting the train to the Internet 🎧

so here's the tea: mobility of networks doesn't make MNNs change their own physical point of attachment 🙅‍♀️ but they do change their topological location with respect to the global Internet. if network mobility isn't explicitly supported by some mechanisms, the MR moving makes MNNs lose Internet access and breaks ongoing sessions between arbitrary correspondent nodes (CNs) in the global Internet and those MNNs inside the mobile network 💀 on top of that, the communication path between MNNs and correspondent nodes becomes sub-optimal, and multiple levels of mobility cause extremely sub-optimal routing 😭

mobility-related terms in this doc are defined in [2], and terms specific to network mobility are defined in [1]. here's the layout: Section 2 covers the rough objectives and methodology of the NEMO working group for handling network mobility issues, and it highlights the stepwise approach the working group decided to follow 🪜 Section 3 lists a bunch of desirable design goals 🎯 those design goals then act as guidelines for defining the requirements in Section 4 for basic network mobility support [3] 💖

2. NEMO Working Group Objectives and Methodology 🌸

the IETF didn't have the mechanisms needed for handling network mobility issues when the NEMO working group (WG) got set up at the IETF in 2002 🕰️ back then, the work on mobility support (especially in the Mobile IP working group) was all about giving continuous Internet connectivity and optimal routing to mobile hosts only (host mobility support). the mechanisms in Mobile IPv6 [5] just can't support network mobility, so the NEMO working group was created to deal with issues specific to network mobility 🧚

the primary objective of NEMO work is to specify a solution that lets mobile network nodes (MNNs) stay connected to the Internet and continuously reachable while the mobile router serving the mobile network changes its point of attachment 👑 the secondary goal is to investigate how network mobility affects different parts of Internet communication, like routing protocol changes, the implications for real-time traffic and fast handovers, and optimizations. that secondary work should support the primary goal of reachability for mobile network nodes 💅 security is a big deal too, and efforts should be made to use existing security solutions if they're appropriate. a well-designed solution might include security that's already inherent in other protocols, but mobile networks also bring new challenges 🔐

so to get all this done, the NEMO working group decided on a stepwise approach 🪜 the steps are: standardizing a basic solution to preserve session continuity (NEMO Basic Support, see [3]), and studying the possible approaches and issues with providing more optimal routing with potentially nested mobile networks (NEMO Extended Support, see [6] and [7] for a discussion on routing optimization issues, and [8] for a discussion on multihoming issues). BUT, the working group isn't chartered to actually standardize a solution for Extended Support at this point in time. if it's deemed necessary, the working group will be rechartered based on what the discussions conclude 📝

for NEMO Basic Support, the working group assumes that none of the nodes behind the MR is aware of the network's mobility 🙈 so the network's movement has to be completely transparent to the nodes inside the mobile network. this assumption covers nodes inside the network that generally aren't aware of mobility at all 💜

the Mobile IP working group already produced Mobile IPv4 and Mobile IPv6, which solved host mobility support 🎉 since that work makes enabling mobile networks way less of a challenge, basic network mobility support borrowed the host mobility methods from Mobile IP and extended them in the simplest way possible to hit its goals 🫶 the Basic Support solution, now defined in [3] following the requirements in Section 4 of this document, has each MR with a Home Agent (HA), and uses bi-directional tunneling between the MR and HA to keep sessions continuous while the MR moves 🚇 the MR gets a Care-of Address (CoA) at its attachment point, much like mobile hosts (MHs) do with Mobile IP. this approach allows nested mobile networks, because each MR shows up to its attachment point as a single node 🪆

3. NEMO Support Design Goals 🎯

this section breaks down the fundamental design goals the solutions are meant to achieve 💅 those goals help define the issues and set a list of requirements for future solutions. the actual requirements for NEMO Basic Support are in Section 4, and NEMO Extended Support wasn't being considered yet when this was written 🌈

3.1. Migration Transparency 🦋

permanent connectivity to the Internet has to be provided to all MNNs, since continuous sessions are expected to be maintained while the mobile router changes its point of attachment ✨ to keep those sessions going, MNNs are expected to be reachable via their permanent IP addresses 🫶

3.2. Performance Transparency and Seamless Mobility 🚀

NEMO support is expected to come with limited signaling overhead, and to minimize how much handovers hit applications in terms of packet loss or delay 💖 still, variable delays and losses between MNNs and their respective CNs could be noticed as the network gets displaced, and that wouldn't count as a lack of performance transparency 🙌

3.3. Network Mobility Support Transparency 🫧

MNNs behind the MR(s) don't change their own physical point of attachment just because the mobile network moved in the Internet topology 🙅‍♀️ so NEMO support is expected to be performed only by the MR(s). adding specific support functions on any node other than the MR(s) would be better avoided 🛑

3.4. Operational Transparency 🍓

NEMO support is to be implemented at the IP layer 🧠 it's expected to be transparent to upper layers, so any upper-layer protocol can run unchanged on top of an IP layer extended with NEMO support 🥰

3.5. Arbitrary Configurations 🌸

okay so a mobile network can get SO complicated 😭 at the simplest end it's just one mobile router and one host, but at the most extreme it's multihomed AND a multi-level mess of mobile networks with thousands of mobile routers and hosts together 💀 we can't list every possible setup, but these ones are absolutely desirable ✨

  • Mobile networks of any size, from a single subnet with a few IP devices to a bunch of subnets with a huge number of IP devices.
  • Nodes that switch their point of attachment inside the mobile network.
  • Foreign mobile nodes that attach to the mobile network.
  • Multihomed mobile networks, either when one MR has several attachments to the internet, or when the mobile network connects to the Internet through several MRs (see the definition in [1] and the analysis in [8]).
  • Nested mobile networks, which are mobile networks attaching to other mobile networks (see the definition in [1]). The complexity needs of these nested networks aren't totally clear yet, but it's desirable to support arbitrary levels of recursive networks. The solution SHOULD only impose restrictions on nesting (e.g., path MTU) when that's impractical and protocol concerns rule out such support. 🎀
  • Distinct mobility frequencies (see the mobility factor in [2]).
  • Distinct access media.

to keep things simple, transit networks are excluded from this list 🧚 a transit network is one where data gets forwarded between two endpoints outside of the network, so the network is basically just a pass-through conduit for packets. a stub network (aka a leaf network) is different because it doesn't forward data for anyone else. data on a stub network is either sent by or addressed to a node inside that network 🦋

3.6. Local Mobility and Global Mobility 💜

mobile networks and mobile nodes owned by different administrative entities are expected to get displaced within a domain boundary or between domain boundaries 🚗 multihoming, vertical and horizontal handoffs, and access control mechanisms are all desirable for making that happen 🔥 and honestly the only thing that should limit this kind of mobility is administrative and security policies 🙌

3.7. Scalability 🍓

NEMO support signaling and processing is expected to scale to a potentially large number of mobile networks, no matter what their configuration, mobility frequency, size, or number of CNs are 📈 it has to handle the big crowd 😤

3.8. Backward Compatibility 🌈

NEMO support will have to co-exist with established IPv6 standards and not interfere with them 🫶 standards from other IETF working groups should be reused as much as possible, and only extended if that's really necessary. for example, the following mechanisms from other working groups are expected to work without any modification:

  • Address allocation and configuration mechanisms.
  • Host mobility support. Mobile nodes and correspondent nodes, whether they're inside or outside the mobile network, are expected to keep running the protocols defined by the Mobile IP working group. that covers host mobility support (Mobile IPv6) and seamless mobility (FMIPv6) ✨
  • Multicast support intended for MNNs is expected to stay up while the mobile router changes its point of attachment 📡
  • Access control protocols and mechanisms used by visiting mobile hosts and routers, so they can get authenticated and authorized and gain access to the Internet through the mobile network infrastructure (MRs) 🔑
  • Security protocols and mechanisms. 🔐
  • Mechanisms performed by routers in both visited networks and mobile networks (routing protocols, Neighbor Discovery, ICMP, Router Renumbering) 🧠

3.9. Secure Signaling 🔐

NEMO support will have to follow the usual IETF security policies and recommendations, and it's expected to have its own specific security issues fully addressed 🛡️ realistically, all NEMO support control messages sent across the network will have to be protected with an acceptable level of security, so intruders can't usurp identities or forge data 💀 specifically, these issues have to be considered:

  • Authentication of the sender, to prevent identity usurpation.
  • Authorization, to make sure the sender is actually allowed to perform the operation indicated in the control message.
  • Confidentiality of the data contained in the control message.

3.10. Location Privacy 🙈

location privacy means hiding the actual location of an MNN from third parties other than the HA, and that's desired 👀 but how far this should be enforced isn't clear, because you can always work out the topological location by analyzing IPv6 headers 😅 that would mean some kind of encryption of the IPv6 header, so third parties can't monitor the IPv6 addresses between the MR and the HA. still, it's at the very least desirable to give MNNs a way to hide their real topological location from their CNs 🫣

3.11. IPv4 and NAT Traversal 🧚

IPv4 clouds and NAT are likely to co-exist with IPv6 for a long time, so it's desirable that the mechanisms developed for NEMO can traverse those clouds 🌥️

3.12. Minimal Impact on Internet Routing 🌍

any NEMO solution needs to have minimal negative effect on the global Internet routing system ✨ so the solution MUST limit both the amount of information that MUST be injected into Internet routing and the dynamic changes in the information that gets injected into the global routing system.

here's why that matters 👇 imagine every mobile network advertising its connectivity into BGP, then withdrawing old routes and injecting new ones on every single move. if there were tens of thousands of mobile networks doing that, moving at the speed of an airplane going from one ground station to another, BGP could be hit really badly 😭 in that scenario the total amount of routing information might be acceptable, but the dynamic instability (how many changes happen over time) would be totally unacceptable 💅

4. NEMO Basic Support One-Liner Requirements ✨

for basic network mobility support, the NEMO WG is going to specify one unified, unique "Network Mobility (NEMO) Basic Support" solution, which we'll just call "the solution" from here on 🎀 the goal is that every node in the mobile network stays reachable through permanent IP addresses, and that ongoing sessions survive as the MR changes its point of attachment to the Internet topology 🦋 all of that gets done by keeping a bi-directional tunnel up between an MR and its Home Agent 🚇

after looking into alternatives, the NEMO Working Group decided to reuse and extend the existing Mobile IPv6 [5] mechanisms for tunnel management 💖

here's the list of requirements the NEMO Basic Support solution has to meet. the resulting specification, which you can find in [3], mostly meets them, and the related deployment issues are discussed in [9] 🧁

  • R01: The solution MUST be implemented at the IP layer level.
  • R02: The solution MUST set up a bi-directional tunnel between a mobile router and its Home Agent (MRHA tunnel).
  • R03: All traffic exchanged between an MNN and a CN in the global Internet MUST transit through the bi-directional MRHA tunnel.
  • R04: MNNs MUST be reachable at a permanent IP address and name.
  • R05: The solution MUST maintain continuous sessions (both unicast and multicast) between MNNs and arbitrary CNs after IP handover of (one of) the MRs.
  • R06: The solution MUST NOT require modifications to any node other than MRs and HAs.
  • R07: The solution MUST support fixed nodes, mobile hosts, and mobile routers in the mobile network.
  • R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile network link as either a home link or a foreign link.
  • R09: The solution MUST ensure backward compatibility with other standards defined by the IETF. In particular, this includes the following:
    • R09.1: The solution MUST NOT prevent the proper operation of Mobile IPv6 (i.e., the solution MUST allow MIPv6-enabled MNNs to operate either the CN, HA, or MN operations defined in [5]).
  • R10: The solution MUST be agnostic to the internal configuration. This means the solution will behave the same way if NEMO is nested, comprises one or several subnets, or comprises MNNs that are LFNs, VMNs, LFNs or a mixture of them.
  • R11: The solution MUST support at least 2 levels of nested mobile networks, while, in principle, arbitrary levels of recursive mobile networks SHOULD be supported.
  • R12: The solution MUST function for multihomed MRs and multihomed mobile networks as defined in [1].
  • R13: NEMO support signaling over the bi-directional tunnel MUST be minimized.
  • R14: Signaling messages between the HA and the MR MUST be secured:
    • R14.1: The receiver MUST be able to authenticate the sender.
    • R14.2: The function performed by the sender MUST be authorized for the content carried.
    • R14.3: Anti-replay MUST be provided.
    • R14.4: The signaling messages MAY be encrypted.
  • R15: The solution MUST ensure transparent continuation of routing and management operations over the bi-directional tunnel (this includes, e.g., unicast and multicast routing protocols, router renumbering, Dynamic Host Configuration Protocol (DHCPv6)).
  • R16: When one egress interface fails, the solution MAY preserve sessions established through another egress interface.
  • R17: The solution SHOULD have a minimal impact on the global Internet routing system.

5. Security Considerations 🔒

the security considerations for the NEMO Basic Support solution are covered in [RFC3963] 🛡️

Section 3.9 of this document talks about the security goals for all forms of existing and upcoming NEMO solutions 🫶

6. Acknowledgments 💖

this document takes most of its text from discussions and earlier documents submitted to the NEMO working group 🙏 that includes initial contributions from Motorola, INRIA, Ericsson, and Nokia. huge thanks to Hesham Soliman (Ericsson) and the IETF Area Directors (ADs) at the time (Erik Nordmark and Thomas Narten), who really helped set up the NEMO working group 👑 we're also grateful to everyone else whose comments made this document better: T.J. Kniveton (Nokia), Alexandru Petrescu (Motorola), Christophe Janneteau (Motorola), Pascal Thubert (Cisco), Hong-Yon Lach (Motorola), Mattias Petterson (Ericsson), and everyone who shared their opinions on the NEMO mailing lists (formerly known as MONET) 🌸

Thierry Ernst wants to personally thank INRIA Rhone-Alpes and Motorola Labs Paris for their support and direction in bringing this topic to the IETF in 2001, especially Claude Castelluccia (INRIA) and Hong-Yon Lach (Motorola). he also thanks his past employer, Keio University, Japan, which covered most of the IETF costs during the timelife of previous versions of this document 🇯🇵✨

7. References 📚

7.1. Normative References 📚

  • [1] Ernst, T. and H. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007.
  • [2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
  • [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.

7.2. Informative References 🌸

These are the extra reads for when you want to go deeper, bestie 🧚

  • [4] "CALM - Medium and Long Range, High Speed, Air Interfaces parameters and protocols for broadcast, point to point, vehicle to vehicle, and vehicle to point communication in the ITS sector - Networking Protocol - Complementary Element", ISO Draft ISO/WD 21210, February 2005.
  • [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
  • [6] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007.
  • [7] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007.
  • [8] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", Work in Progress), February 2007.
  • [9] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network Mobility (NEMO) Home Network Models", RFC 4887, July 2007.

Author's Address 🦋

Here's who wrote it, so you know who to thank (or DM 💌):

Thierry Ernst
INRIA
INRIA Rocquencourt
Domaine de Voluceau B.P. 105
78 153 Le Chesnay Cedex
France

Phone: +33 1 39 63 59 30
Fax:   +33 1 39 63 54 91
EMail: thierry.ernst@inria.fr
URI:   http://www-rocq.inria.fr/imara

Okay, the legal bit, but make it cute 🎀 The whole thing is Copyright (C) The IETF Trust (2007). This document is covered by the rights, licenses and restrictions in BCP 78, and apart from what that says, the authors keep all their rights 🔒

Here's the disclaimer, word for word, because it matters:

"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.

Basically: this document and everything in it is handed over "AS IS" 🫠 The contributor, their sponsoring organisation (if they have one), the Internet Society, the IETF Trust and the Internet Engineering Task Force all say no warranties, express or implied. That covers not infringing anyone's rights and being merchantable or fit for a particular purpose 💅

Intellectual Property 🔥

Okay, so about patents and other IP drama: the IETF doesn't take a side on whether any IP rights covering the tech in this document are valid or how far they reach, or whether you can get a license for them. It also hasn't checked for those rights itself 🙈 The rules for rights in RFC documents live in BCP 78 and BCP 79.

Any IPR disclosures made to the IETF Secretariat, plus any license assurances, or the results of trying to get a general license or permission for implementers and users, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.

And if you spot any copyrights, patents, patent applications or other proprietary rights that might cover tech needed to implement this standard, the IETF wants to hear about it! Send it to ietf-ipr@ietf.org 🫶

Acknowledgement 🌈

Huge thanks to the Internet Society, which is currently funding the RFC Editor function ✨

📦 where this page comes from