RFC 4887
Network Mobility Home Network Models
RFC 4887: Network Mobility Home Network Models ✨
Network Working Group 🌸
- RFC number: 4887
- Title: Network Mobility Home Network Models
- Authors: P. Thubert (Cisco Systems), R. Wakikawa (Keio University and WIDE), V. Devarapalli (Azaire Networks)
- Category: Informational
- Date: July 2007
- Obsoletes / Updates: the header doesn't list anything it obsoletes or updates 🦋
Status of This Memo 💅
Okay so this memo is information only. It is not an Internet standard of any kind, it's just here for the Internet community to read. Distribution is unlimited, so share it with everyone you know 💖
Copyright Notice 📜
Copyright (C) The IETF Trust (2007). Iconic and protected 🔒
Abstract ✨
Bestie, this paper walks through how people actually set up a Home Network for NEMO-enabled Mobile Routers that follow the NEMO Basic Support. The goal is to show some example layouts for the Home Network, the kind that got talked about on NEMO mailing lists. Lowkey the most practical read you'll get on this topic 🎀
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 4
3. General Expectations . . . . . . . . . . . . . . . . . . . . . 4
4. MIP Home Network . . . . . . . . . . . . . . . . . . . . . . . 5
5. NEMO Extended Home Network . . . . . . . . . . . . . . . . . . 5
5.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Returning Home . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Home Address from MNP . . . . . . . . . . . . . . . . . . 7
5.4. Deployment Caveats . . . . . . . . . . . . . . . . . . . . 8
5.4.1. Mobile Router Side . . . . . . . . . . . . . . . . . . 8
5.5. Applicability . . . . . . . . . . . . . . . . . . . . . . 8
6. NEMO Aggregated Home Network . . . . . . . . . . . . . . . . . 8
6.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Returning Home . . . . . . . . . . . . . . . . . . . . . . 9
6.2.1. Returning Home with the Egress Interface . . . . . . . 10
6.2.2. Returning Home with the Ingress Interface . . . . . . 10
6.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Deployment Caveats . . . . . . . . . . . . . . . . . . . . 11
6.4.1. Home Agent Side . . . . . . . . . . . . . . . . . . . 11
6.4.2. Mobile Router Side . . . . . . . . . . . . . . . . . . 11
7. NEMO Virtual Home Network . . . . . . . . . . . . . . . . . . 12
7.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 14
8. NEMO Mobile Home Network . . . . . . . . . . . . . . . . . . . 14
8.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 14
8.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 181. Introduction 🌈
Okay bestie, this doc assumes you already know IPv6 Mobility, the stuff defined by Mobile IPv6 and the Network Mobility (NEMO) Basic Support. Here's the key thing to get: in NEMO, the Home Network can be way bigger than the Home Link. It spans the Home Link and every Link that the Mobile Routers (MRs) carry around with them 🚗💨 How the two ideas line up depends on how the Home Network is organized, and we'll get into that below.
There are five different ways to organize the Home Network, including a hierarchical one:
- MIPv6 Home Network: a quick reminder of what the Home Network looks like with Mobile IP, so you can follow the path over to NEMO 🧸
- NEMO Extended Home Network: here the Home Network is only one subnet inside a bigger aggregation that covers the Mobile Networks. That bigger thing is called the Extended Home Network. When it's home, a Mobile Router does normal routing between the Home Link and the Mobile Networks. More in Section 5.
- NEMO Aggregated Home Network: here the Home Network actually overlaps with the Mobile Networks. When it's home, a Mobile Router acts as a bridge between the Home Link and the Mobile Networks. More in Section 6.
- Virtual Home Network: there is no physical Home Link at all for the Mobile Routers to come back to 👻 More in Section 7.
- NEMO Mobile Home Network: here you get a bitwise hierarchy of Home Networks. A global Home Network gets advertised to the infrastructure by a head Home Agent (HA), and then it's subnetted into Mobile Networks. Each subnet is owned by a Mobile Router that registers it in a NEMO fashion while acting as a Home Agent for that network. More in Section 8.
In every case, the Home Agents collectively advertise only the aggregation of the Mobile Networks. The subnetting stays inside the Home Agents and the Mobile Routers, instead of being advertised to other parties using routing protocols. Very clean, very on brand 💅
The examples here are meant to illustrate the NEMO Basic Support [5], but they don't limit its scope. More cases may show up in the future 🔮
2. Terminology and Concepts 📚
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 [2]. Read those carefully, they're doing the heavy lifting 🫶
Most of the mobility-related terms in this document are defined in the Mobility Related Terminology document [3] and in the Mobile IPv6 (MIP6) specification [4] ✨
Some terms were created or extended specifically for NEMO. Those are defined in the Mobile Network Terminology document [6]:
- Home Link
- Home Network
- Home Address
- MRHA Tunnel
- Mobile Aggregated Prefix
- Aggregated Home Network
- Extended Home Network
- Virtual Home Network
- Mobile Home Network
3. General Expectations 🦋
With Mobile IPv6, the Home Network is usually a physical network that connects the Home Agents and the Mobile Nodes that are at home. NEMO stretches the idea of home. It's no longer just a flat subnet full of Home Addresses. It's an aggregation that is itself subnetted into Mobile and Home Networks. It's still called home, though 🏠
Here's an example. Say the aggregation has a global routing prefix of m = 48 bits (A:B:C::/48), with a subnet ID size of n = 16 bits (n + m = 64):
When a Mobile Router, MR1, uses the Mobile Network Prefix (MNP) A:B:C:1::/64 with the NEMO Basic Support, MR1 may register using a Home Address from the Home network (i.e., A:B:C:0::1) or a Home Address from one of its MNPs (i.e., A:B:C:1::1), depending on the deployment 🌸
In a given deployment, one subnet may be reserved for the Home Link (A:B:C:0::/64), while the others are handed out to Mobile Routers as Mobile Networks (like A:B:C:1::/64 for MR1). Another approach is to configure the aggregation of Mobile Networks as the subnet on the Home Link, and let the Mobile Routers manage the overlapping networks. Finally, the aggregation could live on a virtual network with no physical Home Link at all. In that case, "home" just means topologically and administratively close to the Home Agent that advertises the virtual network 🧚
The next sections give more detail on each of these forms of Home Network.
4. MIP Home Network 🧸
In the Mobile IPv6 (MIP6) specification [4], Mobile Nodes are at home when they're connected to their Home Link. There they recognize their Home Prefix in Router Advertisement messages. Also, a binding is checked using Duplicate Address Detection (DAD) on the Home Link, and Home Agents discover each other through Neighbor Discovery (ND) extensions over that link 💖
The Home Prefix that gets advertized on the Home Link is a final prefix, not an aggregation. Hosts on the Home Link may use it for autoconfiguration purposes ✨
So for Mobile IPv6, the Home Network is really a prefix on a link, served by one or more Home Agents, rather than a routed mesh. The next sections show that NEMO needs extra prefixes for the Mobile Networks, so NEMO grows the Home Network concept into a more complex, aggregated structure. Plot twist, but it makes sense 🎀
5. NEMO Extended Home Network 🌈
5.1. Configuration 🛠️
One simple way to extend the MIP Home Network is to use additional prefixes, contiguous to the Home Link Prefix inherited from MIPv6, as Mobile Network Prefixes. Because this model just extends the MIP Home Network so easily, the result is called a NEMO Extended Home Network. It's shown in Figure 1 🦋
|
route v /48 A:B:C::/48
HA
| /64 Home Link: A:B:C:0::/64
--+-----+--+- . -+- . -+--
| | | |
MR1 MR2 MRi MRN
| | | |
------ ------ ------ ------
/64 /64 /64 /64 MNP: A:B:C:i::/64
Extended Home Network
<----------------------------------------------------------->
Home Net Mobile Net Mobile Net ... Mobile Net
<------------><------------><------------> ... <------------>
Figure 1: Extended Home NetworkSo in that arrangement, here's the vibe:
- There is one physical Home Network and multiple Mobile Networks 🚌
- The Home Prefix and the MNPs are shaped so that IPv6 Stateless Address Autoconfiguration works with the typical interface identifier length for the type of interface (for example, it can be /64) 💅
- The prefix length of the Extended Home Network is shorter than that of the Home Network and the MNPs, since it's an aggregation (for example, it can be /48) 🧩
- Since the Extended Home Network operations inherit trivially from MIPv6, it makes sense that the Mobile Routers get their Home Addresses from the prefix on the Home Link. In that case, a Home Agent can perform DAD on the Home Link, as prescribed by Mobile IPv6 for the Mobile Router Home Addresses (MRHAs). Full circle moment 🫶
5.2. Returning Home ✨
okay so in the Extended Home Network model, the Home Network is set up on a physical interface of the Home Agent, which is called the Home Link 🏠
a Mobile Router goes home by plugging directly into the Home Link and dropping the MRHA tunnel. bye tunnel 👋
once it's home, the Mobile Router keeps the connectivity of the Mobile Network going with standard router operations 💅
in implicit mode, the Home Agent already has what it needs to keep routing to the MNPs without any registration, assuming the Mobile Router is at home. the Mobile Router doesn't have to join the home Interior Gateway Protocol (IGP) for this. it's so clean 🫶
but in explicit mode, or if the Mobile Router uses an IGP over the MRHA tunnel, it needs to restart its IGP operations on the Home Link so it can advertise its Mobile Networks to the HA. the exception is if some other means, like static routes, is deployed to cover the case 🛣️
alternative procedures for keeping the Mobile Networks connected when at home are described in Section 7 🧚
5.3. Home Address from MNP 🎀
we already saw that a natural extension of the MIP procedure is to derive the Home Address of a Mobile Router from the prefix on the Home Link. but NEMO basic support also lets a Mobile Router form its Home Address from one of its Mobile Network Prefixes. main character energy 👑
in that case, the Home Address does not match the Home Link Prefix. so the Home Agent has to be configured in a specific mode with support for the Extended Home Network and the range of the Mobile Network Prefixes. with that new configuration, the Home Agent can accept a Home Address that is not from the Home Link, and it will know it should not perform any DAD 🙈
also, if the Mobile Router uses a Home Address derived from its MNP, it needs some specific support too. to figure out that it's at home, the Mobile Router recognizes the well-known prefix of its Home Agent instead of matching the prefix on the Home Link with its Home Address 🔍
when it connects to the Home Link, the Mobile Router also needs to autoconfigure an address on the Egress interface, rather than assigning its home Address to the interface 🌸
so yeah, this submode of Extended Home Network is not a trivial extension of the MIPv6 Home Model, and it might not be compatible with all implementations. it's giving complicated 💀
5.4. Deployment Caveats 🚧
5.4.1. Mobile Router Side
in explicit mode, the routing to the MNP via the Mobile Router must be restored when the Mobile Router is at home. this is normally done by the Mobile Router through the existing IGP. in that case, the Mobile Router needs specific support to control the routing protocol operation, so it only participates in the IGP if and only if it's at home 🔁
NEMO Basic Support doesn't mandate a specific routing protocol, though many implementations can be expected to support some well-known ones. an implementation might give you an automatic toggle to start or stop routing on an egress interface when the mobile router comes back home or leaves. when there's no such toggle, a specific interface should be reserved for attaching to home, with the right settings for security and routing 🔐
5.5. Applicability 🦋
the Extended Home Network keeps the MIP6 concept of a Home Network that both Mobile Nodes and Mobile Routers take their Home Address from. since there's no overlap between the prefixes assigned to MNPs and the prefix(es) dedicated to the Home Link, it's possible for MNs and Mobile Routers to coexist with that model 🫂
also, when the Home Address is derived from the prefix on the Home Link, the Home Agent behavior on the link trivially extends that of MIP. support for that configuration should be available with all implementations ✨
there are a number of issues with returning home when a Mobile Router configures its Home Address from the MNP, as described in Section 5.3. so we do not recommend this mechanism if the Mobile Routers attach to the Home Network. ngl, that's a hard pass 🙅♀️
6. NEMO Aggregated Home Network 🌈
6.1. Configuration
one other approach is to treat the aggregation of all the MNPs as the Home Link Prefix plainly. in this model, the Home Network is called a NEMO Aggregated Home Network. this means the Mobile Aggregated Prefix is configured on the Home Link and advertised by the Home Agent as a subnet, as shown in Figure 2 🍓
HA
| /56 Aggreg /56
--+-----+--+- . -+- . -+--
| | | |
MR1 MR2 MRi MRN
| | | |
------ ------ ------ ------
/64 /64 /64 /64 Aggreg|i /64 0 < i <= N
Aggregated Home Network == Home Network
<----------------------------------------------------------->
Mobile Net Mobile Net Mobile Net ... Mobile Net
<------------><------------><------------> ... <------------>
Figure 2: Aggregated Home Networkin that model, it seems natural to subnet the whole range of addresses into Mobile Network prefixes, instead of reserving one prefix for the Home Link (which would basically boil down to the Extended Home Network model). if the prefix on the Home Link is really an aggregation and not a final prefix, it should not be allowed for autoconfiguration or Home Address allocation 🚫
note that in that case, it makes sense for a Mobile Router to register using a Home Address from one of its own MNPs. taking the Home Address from its own range guarantees the uniqueness of the suffix. the Mobile Router can check that uniqueness on its Ingress network (see [3]) using DAD 🔎
6.2. Returning Home 🏡
the Aggregated Home Prefix is configured on a physical interface of the Home Agent, the Home Link. so the Home Agent has a connected route to the Aggregated Home Network over the Home Link 🛤️
a Mobile Router goes home by connecting directly to the Home Link and dropping the MRHA tunnel. the Mobile Router recognizes its Home Link by a prefix match with its Home Agent 🫶
when the Mobile Router forms its Home Address out of one of its MNPs, the Home Address actually matches both prefixes, since the Home Network prefix is an aggregation that covers all the MNPs. to properly identify the Home Network as it returns home, the MR must expect a shorter prefix length than the one of the MNP the Home Address was formed from 📏
6.2.1. Returning Home with the Egress Interface 🔌
a Mobile Router coming home via its Egress interface sees overlapping prefixes between the Ingress and the Egress interfaces, so some specific support may be needed:
when a Mobile Router connects to the Home Link using its Egress Interface, it might set up a bridge between its Ingress interface(s) and the Home Link, if the interfaces are compatible 🌉
alternatively, the Mobile Router might perform ND proxying for all addresses in its MNPs, between the Egress interface and the related Ingress interface, as described in [8]. since the prefixes on the Egress and Ingress interfaces overlap, routing is disallowed 🙅
the Mobile Router doesn't need to join the local IGP when it returns home, even if it's using the explicit Prefix Mode. when the Mobile Router is not registered, the Home Agent simply expects that all Mobile Network Nodes (MNNs) will be reachable over the Home Link 🧚
HA
|
-------+--+--- /56
|
Egress |
MR at home
|
--+--- /64
Figure 3: Bridging between Egress and Ingress6.2.2. Returning Home with the Ingress Interface 🧃
alternatively, if the Mobile Router has a single Ingress interface, it may use the NEMO-Link to connect to the Home Link, merging the two links into one consistent network 🤝
HA
|
-------+-+---- /56
|
---+-- /64
|
MR at home
Egress |
Figure 4: Merging the Home and the Mobile Networksthis fits the connected route model, since the Aggregated Home Network is truly located on that network. note that in that case, it makes sense for a Mobile Router to register using a Home Address from one of its own MNPs 💖
6.3. Applicability 🌷
with this model, there's no specific space for independent nodes, since any address in the aggregation belongs to a MNP and therefore to a Mobile Router. this configuration excludes coexisting with MIP6 MNs on the Home Link 🚷
6.4. Deployment Caveats 💅
6.4.1. Home Agent Side
a node on the Home Link that receives a Router Advertisement including the Aggregated Home Network prefix might use that prefix for Address Autoconfiguration. such a node would also install a connected route to the Aggregated Home Network over the Home Link 📡
as a result, unless the node has a better (longest match) route to a given Mobile Network Prefix, it would look up all MNNs on that MNP using Neighbor Discovery over its interface to the Home Link, and fail 😭
thus, on the Home Link, the Home Agent must intercept all the packets for ALL the Mobile Network Nodes on the registered prefixes. that means ALL nodes attached to Mobile Routers that are away from home. this should be a layer 2 operation, rather than layer 3. the Home Agent might, for example, perform some form of ND proxying for all addresses in all registered Mobile Network Prefixes 🕵️♀️
the Home Agent must also protect the MNP space from autoconfiguration by uncontrolled visitors at the Neighbor Discovery level. guard that space like it's your best friend's diary 🔒
there is a need to provide a specific configuration on the Home Agent to specify that it operates in Aggregated Mode. if a Home Agent implementation is simply derived from that of MIP, then the capability to perform the required proxying might not exist, and the Aggregated Mode will not operate properly for nodes on the Home Link. so double-check your HA before you assume it's good to go ✨
6.4.2. Mobile Router Side ✨
okay so if the Mobile Router returns home by Egress, it needs a specific kind of support to control bridging depending on whether it's actually at home or not 💅 this support might not be in every implementation, so keep that in mind 💀
NEMO Basic Support doesn't say anything specific about bridging, though you can expect bridging from a lot of implementations 🌸 an implementation might give you an automatic toggle to start or stop bridging on the Egress interface when the Mobile Router comes back home or leaves. if there's no toggle, then a specific interface should be reserved to attach to home with the right settings for security and bridging 🔐
also, NEMO allows multiple registrations for the same MNP from different Mobile Routers 👀 that's multihoming, and it normally means the Mobile Routers are interconnected by the Ingress network that carries the common MNP. but there's no provision in NEMO Basic Support to test that this condition is met at binding time or to keep checking it over time. no cap, that's a gap 😭
so it's possible for 2 different Mobile Routers to register the same prefix with different Home Addresses, and this will cause a problem nobody notices if the corresponding Ingress interfaces aren't connected 😱
when the Home Address of a Mobile Router is derived from its MNP, there's an extra risk of an undetected misconfiguration if the Home Address is autoconfigured from the Ingress interface, as opposed to statically assigning an address and MNP 🎀
a Mobile Router that's at home must own an address from the aggregation on its Egress interface and an address from its MNP (a subnet of that aggregation) on its Ingress interface. a pure router will reject that configuration, so the Mobile Router needs to act as a bridge to use it 🦋 so if you're deploying the Aggregated Home Network model, check whether that support is available in the Mobile Routers if returning home is required. the bare minimum, bestie 🫶
7. NEMO Virtual Home Network 🧚
7.1. Configuration 💜
the Home Link can be configured on the Home Agent on a virtual link. in that case there's no physical Home Link for Mobile Routers to return home to, or for Home Agents to discover each other and do the ND-level interactions on, as described in Mobile IPv6 [4]. picture it like this 👇
/48 e.g.: A:B:C::/48
HA
| /64 A:B:C::/64
--+-----+--+- . -+- . -+--
| | | |
MR1 MR2 MRi MRN
/64 /64 /64 /64 A:B:C:i::/64 0 < i <= N
Figure 5: Virtual Home Networkthe Extended Home Network and the Aggregated Home Network models can both be adapted for virtual links ✨
just like with a physical link, the Home Address of a Mobile Router can be built from a dedicated subnet of the Home Prefix, or from one of the Mobile Router MNPs 🌈
note that since the Home Address is never checked for DAD, it makes the configuration easier to take it from the MNP instead of a specific subnet 🙈
there are some real perks to making the Home Link virtual 🍓
- a virtual link may not experience any disruption related to physical maintenance or to hardware problems, so it's more available than a physical link. the high availability of the Home Link is critical for the mobility service, and that's the whole point 👑
- the Home Agent doesn't have to defend the Mobile Router's Home Address through Proxy Neighbor Discovery. it also doesn't have to perform Duplicate Address Detection (DAD) for the Mobile Router's Home Address when it receives a Binding Update from the Mobile Router 💅
- the Mobile Router doesn't have to implement the Returning Home procedure (Section 11.5.4 of Mobile IPv6 [4]) 🫧
but there are drawbacks too, so let's be real 😬
- RFC 3775 [4] and RFC 3963 [5] don't provide the specific support for a Mobile Node to emulate returning home on a Virtual Home Network. in particular, in the case of NEMO, the routing information from the Mobile Router being injected on the IGP might adversely affect IPv6 route aggregation on the Home Network 💀
- there can be only one Home Agent, since Mobile IPv6 relies on Neighbor Discovery on the Home Link for other Home Agent discovery and for Duplicate Address Detection 🙃
- the Home Agent must maintain a Binding Cache entry for a Mobile Router, plus forwarding state for its Mobile Network, even when the Mobile Router is directly connected to it. all traffic to and from the Mobile Network goes through the bi-directional tunnel regardless of the Mobile Router location. that means tunneling overhead even though the Mobile Router is connected to the Home Network 😤
suggestions on how to do the equivalent of returning home on a Virtual Home Network have been proposed, but that topic is outside the scope of this document 🤷♀️
7.2. Applicability 🌷
NEMO operations rely on ND extensions over the Home Link for Home Agent to Home Agent communication 🧠
making the Home Link virtual rules out deploying multiple Home Agents, which might be desirable for load balancing reasons. check the NEMO multihoming issues [9] for more on that 🔍
still, for a deployment where a single Home Agent is enough, making the Home Link virtual reduces the vulnerability to some attacks and some hardware failures, while also making the Home Agent operation faster ⚡
and fyi, NEMO basic doesn't mandate support for Virtual Home Networks 🫶
8. NEMO Mobile Home Network 🍓
8.1. Configuration 🎀
so in this setup there's a bitwise hierarchy of Home Networks 🪆 a global Home Network is advertised to the infrastructure by head Home Agent(s), then further subnetted into Mobile Networks. as a result, only the Home Agent(s) responsible for the most global (shortest prefix) aggregation receive all the packets for all the MNPs, which are the leaves in the hierarchy tree 🌳
each subnet is owned by a Mobile Router that registers it in a NEMO fashion while acting as a Home Agent for that network. this Mobile Router is at home at the upper level of the hierarchy. this configuration is called Mobile Home 💜
an example is the Cab Co configuration 🚕 Cab Co is a taxi company that uses a /32 prefix for its Home Network, and that prefix is advertised by the company headquarters (HQ). regional offices are deployed around the country. even though these regional offices are pretty stable in terms of location and prefix requirements (say, that changes every few years), making them mobile allows simpler management when a move has to happen, or should the ISP service change 🙌
to illustrate this, we make up prefixes that reflect their role, like CAB:C0::/32 for the Home Network:
global Home Network CAB:C0::/32 advertised by HQ
<------------------------------------------------------------------>
HQ Extended Home Net Mobile Home for SFO office
(casa)
CAB:C0:CA5A::/48 CAB:C0:5F0::/48
<----------------------------> ... <------------------------------->
|
Home for offices HQ |
CAB:C0:CA5A:CA5A::/64 MN |
<----------------------><----> |
CAB:C0:CA5A:CA5A::CA5A |
CAB:C0:CA5A:CA5A::CA5B |
are HAs on link with for each office a route like |
|
CAB:C0:CA5A:CA5A::5F0 <---------------------- via
is the Home addr
of SFO office
Figure 6: CAB Company HQ Configurationfinally, each regional office owns a bunch of taxis, each one equipped with a mobile router and an associated /64 prefix 🚖
for each Office, say San Francisco (SFO) as an example:
Mobile Home Network CAB:C0:5F0::/48 owned by SFO office
<------------------------------------------------------------------>
SFO Home Network Mobile Networks for taxis
for taxis <---------------------...--------------------->
CAB:C0:5F0:5F0::/64 CAB:C0:5F0:CAB1::/64 CAB:C0:5F0:....::/64
<-------------------><-------------------> ... <------------------->
CAB:C0:5F0:5F0::5F0 |
is HA on link with for |
each taxi a route like |
|
CAB:C0:5F0:5F0::CAB1 <------ via
is the Home Address
of CAB 1
Figure 7: CAB Company regional configurationnote that this is a hierarchy in terms of the MR-HA relationship, which might not match the physical arrangement of nodes at any given moment 🗺️ for instance, in the Cab Co case, some SFO cabs might attach to any hot spot or Cab Co office in a different city, and the SFO office might be at home if it's co-located with the headquarters. but SFO should never attach to one of its own cabs 🚫 that would create a stalemate situation, as documented in the NEMO Route Optimization (RO) problem statement [7] 💀
but it's also possible to reflect the organizational hierarchy in a moving cloud of Mobile Routers 🌩️ if a Mobile Home Agent acts as root-MR for a nested configuration of its own Mobile Routers, then communication between those Mobile Routers stays confined within the nested structure 🧸
this can be shown with a fleet at sea 🚢 say SFO is a communication ship in a fleet, using a satellite link to join the infrastructure, and the cabs are Mobile Routers installed on smaller ships with low-range radios 📡
if SFO is also the root-MR of a nested structure of its own cabs, the communication between cabs is relayed by SFO and doesn't need the satellite link. as for traffic going outside the nested NEMO, SFO recursively terminates the nested tunnels from its cabs and reencapsulates all the packets between the nested cloud and correspondents in the infrastructure into a single tunnel to CA5A. so the unwanted effect of nesting tunnels is avoided over the Internet part of the packet path 🙌
8.2. Applicability 💅
this complex topology applies to a large distributed fleet, especially if there's a single interchange point with the Internet (e.g., a Network Address Transition (NAT) or a SOCKS [1] server farm) where the super Home Agent could be located 🌐
one specific benefit: when 2 Mobile Routers travel together with a common Home Agent, the traffic between the 2 isn't necessarily routed via the infrastructure. it can stay confined within the mobile cloud, with the Mobile Home Agent acting as a rendezvous point between the Mobile Routers 🫂 this works especially well for a fleet at sea, where long-haul access can be as expensive as a satellite link 💸
9. Security Considerations 🔐
this document only explains how a Home Network can be deployed to support Mobile Routers, and it doesn't introduce any additional security concerns. please see RFC 3963 [5] for security considerations for the NEMO Basic Support protocol. take those seriously, bestie 🚨
10. Acknowledgements 🫶
the authors wish to thank Erik Nordmark, Jari Arkko, Henrik Levkowetz, Scott Hollenbeck, Ted Hardie, David Kessens, Pekka Savola, Kent Leung, Thierry Ernst, TJ Kniveton, Patrick Wetterwald, Alexandru Petrescu, and David Binet for their contributions 💖
11. References ✨
Okay bestie, last stop! 🧚 This is the reading list. Every paper trail the spec leans on lives here, sorted into the stuff you must have read and the stuff that's just extra credit. 💅
11.1. Normative References
Normative references are the ones the spec actually depends on, the load-bearing ones 🏗️:
- [1] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [3] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
- [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [5] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
- [6] Ernst, T. and H. Lach, "Network Mobility Support Terminology", July 2007.
11.2. Informative References
These ones are the bonus content 🎀 nice to read, not strictly required:
- [7] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007.
- [8] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
- [9] Ng, C., "Analysis of Multihoming in Network Mobility Support", Work in Progress, February 2007.
Authors' Addresses 🦋
Meet the squad who wrote this! 🫶
Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3, Biot - Sophia Antipolis 06410 FRANCE
Phone: +33 4 97 23 26 34 EMail: pthubert@cisco.com
Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 JAPAN
EMail: ryuji@sfc.wide.ad.jp
Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 94054 USA
EMail: vijay.devarapalli@azairenet.com
Full 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. Thank you to everyone keeping the lights on! ✨👑
📦 where this page comes from
- ietf: rfc4887 2007-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms