RFC 3963
Network Mobility (NEMO) Basic Support Protocol
RFC 3963: Network Mobility (NEMO) Basic Support Protocol ✨
okay bestie, this is RFC 3963 and it's giving main character energy 🎀 It's a Standards Track doc from the Network Working Group, dated January 2005. The authors are V. Devarapalli (Nokia), R. Wakikawa (Keio University), A. Petrescu (Motorola), and P. Thubert (Cisco Systems). The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there 🦋
Status of This Memo 📮
okay so this doc is an Internet standards track protocol spec for the Internet community, and it's literally asking for discussion and suggestions for improvements 💬 If you want to know where this protocol stands, check the current edition of "Internet Official Protocol Standards" (STD 1), which is the official source for standardization state and status 📚 Distribution of this memo is unlimited, so share it with everyone 💖
Copyright Notice ©️
Copyright (C) The Internet Society (2005).
Abstract 🌸
so the big idea here is the Network Mobility (NEMO) Basic Support protocol, which lets Mobile Networks hop between different points in the Internet 🧚 It's an extension of Mobile IPv6, and it keeps sessions going for every node in the Mobile Network while the network moves. Every node inside can also stay reachable while everything's on the move ✨ The Mobile Router is the device that connects the network to the Internet, and it runs the NEMO Basic Support protocol with its Home Agent 💜 The whole point is that the movement stays transparent to the nodes inside the Mobile Network, so they don't have to do anything fancy 🙈
Table of Contents 📑
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the NEMO Protocol. . . . . . . . . . . . . . . . 4
4. Message Formats. . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Binding Update. . . . . . . . . . . . . . . . . . . . . 7
4.2. Binding Acknowledgement . . . . . . . . . . . . . . . . 7
4.3. Mobile Network Prefix Option. . . . . . . . . . . . . . 8
5. Mobile Router Operation. . . . . . . . . . . . . . . . . . . 9
5.1. Data Structures . . . . . . . . . . . . . . . . . . . . 10
5.2. Sending Binding Updates . . . . . . . . . . . . . . . . 10
5.3. Receiving Binding Acknowledgements. . . . . . . . . . . 11
5.4. Error Processing . . . . . . . . . . . . . . . . . . . 12
5.4.1. Implicit Mode. . . . . . . . . . . . . . . . . . 12
5.4.2. Explicit Mode. . . . . . . . . . . . . . . . . . 12
5.5. Establishment of Bi-directional Tunnel . . . . . . . . 13
5.6. Neighbor Discovery for Mobile Router . . . . . . . . . 13
5.7. Multicast Groups for Mobile Router . . . . . . . . . . 14
5.8. Returning Home . . . . . . . . . . . . . . . . . . . . 14
6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . 15
6.1. Data Structures . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Binding Cache. . . . . . . . . . . . . . . . . . 15
6.1.2. Prefix Table . . . . . . . . . . . . . . . . . . 15
6.2. Mobile Network Prefix Registration . . . . . . . . . . 16
6.3. Advertising Mobile Network Reachability . . . . . . . . 17
6.4. Establishment of Bi-directional Tunnel . . . . . . . . 18
6.5. Forwarding Packets . . . . . . . . . . . . . . . . . . 18
6.6. Sending Binding Acknowledgements . . . . . . . . . . . 19
6.7. Mobile Network Prefix De-Registration . . . . . . . . . 19
7. Modifications to Dynamic Home Agent Address Discovery. . . . 20
7.1. Modified Dynamic Home Agent Discovery Request . . . . . 20
7.2. Modified Dynamic Home Agent Discovery Address Request . 20
7.3. Modified Home Agent Information Option . . . . . . . . 21
8. Support for Dynamic Routing Protocols. . . . . . . . . . . . 22
9. Security Considerations. . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 24
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
A. Examples of NEMO Basic Support Operation. . . . . . . . . 27
B. Running Link State Routing Protocol with NEMO Basic
Support . . . . . . . . . . . . . . . . . . . . . . . . . 30
B.1. Tunnel Interface Considerations. . . . . . . . . . . 30
B.2. OSPF Area Considerations . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 331. Introduction 🦋
okay so this doc describes protocol extensions to Mobile IPv6 (MIPv6) [1] that add support for network mobility 💅 The extensions are backward compatible with Mobile IPv6, which is so iconic. Specifically, a NEMO-compliant Home Agent can operate as a Mobile IPv6 Home Agent 👑 The solution here meets the goals and requirements listed in [11] for network mobility ✨
NEMO Basic Support keeps sessions going for all the nodes in the Mobile Network, even when the Mobile Router changes where it attaches to the Internet 🫶 It also gives connectivity and reachability to every node in the Mobile Network while it moves. It works for both mobile nodes and hosts that don't support mobility inside the Mobile Network, so nobody gets left out 🌈
Quick vocab check: a Mobile Router is basically a Mobile IPv6 [1] Mobile Node, but with an upgrade, because it adds routing between its point of attachment (its Care-of Address) and a subnet that moves along with it 🧚
The solution in this document proposes a bi-directional tunnel between the Mobile Router and its Home Agent 🔥 The tunnel gets set up when the Mobile Router sends a successful Binding Update to its Home Agent, which tells the Home Agent where it's currently attached 💜
All traffic between the nodes in the Mobile Network and Correspondent Nodes goes through the Home Agent 🍓 This document doesn't describe route optimization for that traffic, so that's a plot for another day 🙈
The terminology document [10] describes Nested Mobility, where a Mobile Router lets another Mobile Router attach to its Mobile Network 🌸 You can have arbitrary levels of nested mobility. Each Mobile Router works the same way whether it attaches to another Mobile Router or to a fixed Access Router on the Internet. The solution here doesn't put any restriction on the number of nesting levels. But heads up, this might add a lot of overhead to data packets, since every level of nesting adds another IPv6 header encapsulation 😭
This document doesn't discuss multihoming for Mobile Routers 💀
2. Terminology 💅
okay the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get interpreted as described in BCP 14, RFC 2119 [7] 🎀
Network Mobility related terminology is defined in [9] and [10]. This doc also defines the following terms, and these are the ones you need to know 🦋
Mobile Network Prefix
An IPv6 prefix delegated to a Mobile Router and advertised in the Mobile Network 🧚 More than one Mobile Network Prefix could be advertised in a Mobile Network, so the vibes can get pretty layered ✨
Prefix Table
A list of Mobile Network Prefixes, indexed by the Home Address of a Mobile Router 💜 The Home Agent manages and uses the Prefix Table to figure out which Mobile Network Prefixes belong to a particular Mobile Router 👑
3. Overview of the NEMO Protocol 🚗💨
Okay so a Mobile Network is a network segment or subnet that can move and attach to arbitrary points in the routing infrastructure 🧚 It can only be reached through special gateways called Mobile Routers, which manage all that moving around. Every Mobile Network has at least one Mobile Router serving it. A Mobile Router does not push the Mobile Network routes out to the infrastructure at its point of attachment (aka the visited network) 🙈 Instead, it keeps a bi-directional tunnel open to a Home Agent, and the Home Agent advertises an aggregation of Mobile Networks to the infrastructure. The Mobile Router is also the default gateway for its Mobile Network. Main character energy 👑
A Mobile Network can also be made of multiple, nested subnets 🪆 A router without mobility support can be permanently attached to a Mobile Network for local distribution. Mobile Routers can also attach to Mobile Networks owned by other Mobile Routers, and together they can form a graph. With Basic NEMO Support specifically, each Mobile Router is attached to another Mobile Network by a single interface. If loops are avoided, that graph ends up being a tree 🌳
A Mobile Router has a unique Home Address, and that's how it can be reached whenever it's registered with its Home Agent 💖 The Home Address is configured from a prefix that the Home Agent aggregates and advertises. That prefix could be the one advertised on the home link, or a prefix delegated to the Mobile Router. If there are multiple prefixes on the home link, the Mobile Router can have more than one Home Address ✨ The Mobile Router also advertises one or more prefixes in the Mobile Network attached to it. How those prefixes actually get assigned to a given Mobile Router is outside the scope of this specification 🤷♀️
When the Mobile Router moves away from the home link and attaches to a new access router, it picks up a Care-of Address from the visited link 🌸 At any time, the Mobile Router can act either as a Mobile Host or as a Mobile Router. It acts as a Mobile Host, as defined in [1], for the sessions it originates, and it provides connectivity to the Mobile Network. The moment it gets a Care-of Address, it immediately sends a Binding Update to its Home Agent, as described in [1] 🏃♀️💨 When the Home Agent gets that Binding Update, it creates a cache entry that binds the Mobile Router's Home Address to its Care-of Address at the current point of attachment. Bestie, the bond is official 💍
If the Mobile Router wants to act as a Mobile Router and provide connectivity to nodes in the Mobile Network, it lets the Home Agent know by setting a flag (R) in the Binding Update 🎀 It MAY also include information about the Mobile Network Prefix in the Binding Update, using one of the modes described in section 5.2. That way the Home Agent can forward packets meant for nodes in the Mobile Network over to the Mobile Router 🫶 There's a new Mobility Header Option for carrying prefix information, described in section 4.3. If the Mobile Network has more than one IPv6 prefix and wants the Home Agent to set up forwarding for all of them, it includes multiple prefix information options in a single Binding Update 🌈 The Home Agent then sets up forwarding for each of those prefixes to the Mobile Router's Care-of Address. Sometimes the Home Agent already knows which prefixes belong to a Mobile Router, maybe through static configuration or some other alternate mechanism 🧠 In that case the Mobile Router doesn't include any prefix information in the Binding Update. The Home Agent sets up forwarding for all prefixes owned by the Mobile Router as soon as it receives a Binding Update from the Mobile Router with the Mobile Router Flag (R) set.
The Home Agent acknowledges the Binding Update by sending a Binding Acknowledgement back to the Mobile Router 💅 A positive acknowledgement with the Mobile Router Flag (R) set means the Home Agent has set up forwarding for the Mobile Network. Once the binding process finishes, a bi-directional tunnel exists between the Home Agent and the Mobile Router 🔥 Its tunnel endpoints are the Mobile Router's Care-of Address and the Home Agent's address. If a packet with a source address belonging to the Mobile Network Prefix comes in from the Mobile Network, the Mobile Router reverse-tunnels it to the Home Agent through this tunnel. That reverse tunneling is done with IP-in-IP encapsulation [3] 📦 The Home Agent decapsulates the packet and forwards it to the Correspondent Node. For traffic the Mobile Router itself originates, it can use either reverse tunneling or route optimization, as specified in [1] 💜
When a Correspondent Node sends a data packet to a node in the Mobile Network, the packet gets routed to whichever Home Agent currently holds the binding for the Mobile Router 🦋 The Mobile Router's network prefix gets aggregated at the Home Agent, which then advertises the resulting aggregation. Alternatively, the Home Agent may receive the data packets destined for the Mobile Network by advertising routes to the Mobile Network Prefix. How those routes get advertised is outside the scope of this document 🙃 When the Home Agent gets a data packet meant for a node in the Mobile Network, it tunnels the packet to the Mobile Router's current Care-of Address. The Mobile Router decapsulates the packet and forwards it onto the interface where the Mobile Network is connected.
Before it decapsulates the tunneled packet, the Mobile Router has to check whether the Source address on the outer IPv6 header is the Home Agent's address. This check isn't necessary if the packet is protected by IPsec in tunnel mode 🔐 The Mobile Router also has to make sure the destination address on the inner IPv6 header belongs to a prefix used in the Mobile Network before forwarding the packet into it. If it doesn't, the Mobile Router should drop the packet 🗑️
The Mobile Network could include nodes that don't support mobility, as well as nodes that do 🌟 A node in the Mobile Network can also be a fixed router or a Mobile Router. The protocol described here ensures complete transparency of network mobility to the nodes in the Mobile Network, so they don't have to know anything's going on 🫧 Mobile Nodes that attach to the Mobile Network treat it as a normal IPv6 access network and run the Mobile IPv6 protocol 🎀
The Mobile Router and the Home Agent can run a routing protocol through the bi-directional tunnel 🛣️ In that case, the Mobile Router doesn't need to include prefix information in the Binding Update. Instead, the Home Agent uses the routing protocol updates to set up forwarding for the Mobile Network. When a routing protocol is running, the bi-directional tunnel must be treated as a tunnel interface, and that tunnel interface gets included in the list of interfaces where the routing protocol is active. The Mobile Router should also be configured not to send any routing protocol messages on its egress interface while it's away from the home link and connected to a visited link 🙅♀️
Finally, the Home Agent may be configured with static routes to the Mobile Network Prefix via the Mobile Router's Home Address 🧚♀️ In that case, the routes are set independently of the binding flows and of the Mobile Router returning home. The benefit is that this movement doesn't cause extra signalling in the form of routing updates in the home network ✨ The drawback is that the routes are present even when the related Mobile Routers aren't reachable (at home or bound) at a given point in time 😬
4. Message Formats 💌
4.1. Binding Update
A new flag (R) is included in the Binding Update so the Home Agent can tell whether the Binding Update is coming from a Mobile Router rather than a mobile node 🎀 The rest of the Binding Update format stays the same as defined in [1].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Mobile Router Flag (R)
The Mobile Router Flag is set to indicate to the Home Agent that the Binding Update is from a Mobile Router 🚐 If the flag is set to 0, the Home Agent assumes the Mobile Router is behaving as a Mobile Node, and it MUST NOT forward packets destined for the Mobile Network to the Mobile Router 🙅♀️
Mobility Options
This is a variable length field that can include zero or more mobility options 🧁 This document defines a new mobility option in addition to what's defined in [1].
For descriptions of the other fields in the message, see [1] 📖
4.2. Binding Acknowledgement
A new flag (R) is included in the Binding Acknowledgement to show that the Home Agent that processed the corresponding Binding Update supports Mobile Routers 🌷 The flag is only set if the corresponding Binding Update had the Mobile Router Flag (R) set to 1. The rest of the Binding Acknowledgement format stays the same, as defined in [1].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Mobile Router Flag (R)
The Mobile Router Flag is set to indicate that the Home Agent that processed the Binding Update supports Mobile Routers 🛸 It is set to 1 only if the corresponding Binding Update had the Mobile Router Flag set to 1.
For descriptions of the other fields in the message, see [1] 📖
This document also introduces the following new Binding Acknowledgement status values. The values shown below are decimal values 🔢
140 Mobile Router Operation not permitted
141 Invalid Prefix
142 Not Authorized for Prefix
143 Forwarding Setup failed (prefixes missing)Status values less than 128 mean the Binding Update was processed successfully by the receiving nodes ✅ Values greater than 128 mean the Binding Update was rejected by the Home Agent 🙅♀️
4.3. Mobile Network Prefix Option 💖
Okay so the Mobile Network Prefix Option is included in the Binding Update to tell the Home Agent about the prefix info for the Mobile Network 🌸. There could be multiple Mobile Network Prefix Options if the Mobile Router has more than one IPv6 prefix in the Mobile Network and wants the Home Agent to forward packets for each of these prefixes to the Mobile Router's current location ✨. Bestie, that's giving multi-prefix main character energy 👑.
The Mobile Network Prefix Option has an alignment requirement of 8n+4. Its format is shown below 🎀.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Mobile Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 🦋
6
Length 🧚
Eight-bit unsigned integer indicating the length in octets of the option, excluding the type and length fields. Set to 18.
Reserved 🙈
This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. 😭
Prefix Length 🍓
Eight-bit unsigned integer indicating the prefix length of the IPv6 prefix contained in the option.
Mobile Network Prefix 💜
A sixteen-byte field containing the Mobile Network Prefix.
5. Mobile Router Operation ✨
Okay bestie, Mobile Router operation is mostly a mix of the behaviors of a host, of a router [5], and of a Mobile Node [1] 💅.
A Mobile Node can act in two ways 🦋. (1) As a Mobile Host, where the Home Agent doesn't keep any prefix info related to the Mobile Host's Home Address, but it does keep a binding cache entry for that Home Address. (2) As a Mobile Router, where, on top of the binding cache entry for the Mobile Router Home Address, the Home Agent keeps forwarding info for prefixes assigned to the Mobile Network 🌈. The difference between the two modes is shown by the value of the Mobile Router Flag (R) 🎀.
A Mobile Router MUST implement all requirements for IPv6 Mobile Nodes as described in section 8.5 of [1] 🫶.
5.1. Data Structures 🌸
Like a Mobile Host, a Mobile Router also keeps a Binding Update List, described in section 11.1 of the Mobile IPv6 specification [1] ✨. The Binding Update list is a conceptual data structure that records info sent in the Binding Updates. There is one entry per each destination the Mobile Router is currently sending Binding Updates to 💖.
This document introduces a new Prefix Information field in the Binding Update list structure 🧚. This field stores any prefix info the Mobile Router includes in the Binding Update. If the Mobile Router sets the Mobile Router Flag (R) in the Binding Update but doesn't include any prefix info in it, this field is set to null 🙈. The Mobile Router does not include prefix info in the Binding Update in the implicit mode, or when it runs a dynamic routing protocol with its Home Agent 💀.
Just like a Mobile Host, a Mobile Router stores the status of the flags of the Binding Update in the matching Binding Update List entry 💜. This document introduces a new Mobile Router Flag (R) for this entry. The status of this flag is stored in the Binding Update list whenever a Binding Update is sent 🍓.
A Mobile Router also keeps a Home Agent list, populated using the same procedure as a Mobile Host 🦋.
5.2. Sending Binding Updates 🎀
A Mobile Router sends Binding Updates to its Home Agent, as described in [1] 💅. If the Mobile Router isn't running a routing protocol as described in section 8, it uses one of the following modes to tell the Home Agent which prefixes belong to the Mobile Router 👑. In both modes, the Mobile Router sets the Mobile Router Flag (R) 🌈.
Implicit: 🌸
In this mode, the Mobile Router does not include a Mobile Network Prefix Option in the Binding Update. The Home Agent can use any mechanism (not defined in this document) to figure out the Mobile Network Prefix(es) owned by the Mobile Router and set up forwarding for the Mobile Network. One example would be manual configuration at the Home Agent mapping the Mobile Router's Home Address to the info required for setting up forwarding for the Mobile Network ✨.
Explicit: 🧚
In this mode, the Mobile Router includes one or more Mobile Network Prefix Options in the Binding Update. These options contain info about the Mobile Network Prefix(es) configured on the Mobile Network 💖.
A Mobile Router MUST implement at least one mode and MAY implement both. In the latter case, local configuration on the Mobile Router decides which mode to use. This is out of scope for this document 🫶.
If the Mobile Router Flag is set, the Home Registration Flag (H) MUST be set 🔥.
If the Mobile Router has a valid binding cache entry at the Home Agent, subsequent Binding Updates for the same Home Address SHOULD have the same value as the value in the binding cache for the Mobile Router Flag (R) 💜. In explicit mode, the Mobile Router MUST include prefix info in all Binding Updates, including those sent to refresh existing binding cache entries, if it wants forwarding enabled for the corresponding Mobile Network Prefixes 😭.
5.3. Receiving Binding Acknowledgements 🌈
The Mobile Router receives Binding Acknowledgements from the Home Agent that correspond to the Binding Updates it sent 💅. If the Binding Acknowledgement status is set to 0 (Binding Update accepted) and the Mobile Router Flag (R) is set to 1, the Mobile Router assumes the Home Agent successfully processed the Binding Update and has set up forwarding for the Mobile Network 🎀. The Mobile Router can then start using the bi-directional tunnel to reverse-tunnel traffic from the Mobile Network 🦋. If the Mobile Router Flag (R) is not set, the Mobile Router concludes that its current Home Agent does not support Mobile Routers and performs Dynamic Home Agent Address Discovery again to find Home Agents that do 🙈. The Mobile Router MUST also de-register with the Home Agent that did not support it before attempting registration with another 💀.
5.4. Error Processing 🍓
If the Binding Acknowledgement status is set to a value between 128 and 139, the Mobile Router takes the necessary actions described in the Mobile IPv6 specification [1] 🌸. For the Binding Acknowledgement status values defined in this document, the following sections explain the Mobile Router's behavior 💖.
5.4.1. Implicit Mode 🧚
In Implicit mode, the Mobile Router only interprets error statuses 140 (Mobile Router Operation not permitted) and 143 (Forwarding Setup failed) 🦋. The Mobile Router MUST treat Binding Acknowledgements with statuses '141' and '142' as fatal errors, since they should not be sent by the Home Agent in implicit mode 😭.
If the Binding Acknowledgement from the Home Agent has the status 140, the Mobile Router SHOULD send a Binding Update to another Home Agent on the same home link. If no Home Agent replies positively, the Mobile Router MUST refrain from sending Binding Updates with the Mobile Router Flag set to any Home Agent on the home link, and it must log the info 💅.
If the Binding Acknowledgement has the status 143, the Mobile Router SHOULD send a Binding Update to another Home Agent on the same home link. If no Home Agent replies positively, the Mobile Router SHOULD refrain from sending this Binding Update to any Home Agent on the home link, and MAY send Binding Updates in Explicit mode to a Home Agent on the same home link 👑.
5.4.2. Explicit Mode 🌈
If the Mobile Router sent a Binding Update to the Home Agent in explicit mode, the Mobile Router only interprets error statuses 140 (Mobile Router Operation not permitted), 141 (Invalid Prefix), and 142 (Not Authorized for Prefix) 🎀. The Mobile Router MUST treat Binding Acknowledgements with status '143' as a fatal error, since it should not be sent by the Home Agent in explicit mode 🔥.
If the Binding Acknowledgement from the Home Agent has the status 140, the Mobile Router SHOULD send a Binding Update to another Home Agent on the same home link. If no Home Agent replies positively, then the Mobile Router MUST refrain from sending Binding Updates with the Mobile Router Flag set to any Home Agent on the home link, and it must log the info 🫶.
If the Binding Acknowledgement has the status 141 or 142, the Mobile Router SHOULD send a Binding Update to another Home Agent on the same home link. If no Home Agent replies positively, then the Mobile Router SHOULD refrain from sending Binding Updates to any Home Agent on the home link 🦋. The Mobile Router MUST also stop advertising the prefix in the Mobile Network and try to get new IPv6 prefix info for the Mobile Network 🌸. It would do this by the same means that it originally got assigned the current Mobile Network Prefix 🧚. Alternatively, the Mobile Router MAY send Binding Updates in Implicit mode to a Home Agent on the same home link 💜.
If, by the end of this Error Processing procedure (as described in sections 5.4.1 and 5.4.2), the Mobile Router has tried every available mode and still hasn't received a positive Binding Acknowledgement, the Mobile Router MUST stop sending Binding Updates with the Mobile Router Flag set for this Home Address, and it must log the info 😭.
In all cases above, the Mobile Router MUST conclude that the Home Agent did not create a binding cache entry for the Mobile Router's Home Address 💀.
5.5. Establishment of Bi-directional Tunnel 🍓
When a successful Binding Acknowledgement is received, the Mobile Router sets up its endpoint of the bi-directional tunnel ✨.
The bi-directional tunnel between the Mobile Router and the Home Agent lets packets flow in both directions while the Mobile Router is connected to a visited link 🌈. It's made by merging two unidirectional tunnels, as described in RFC 2473 [3] 💅. The tunnel from the Mobile Router to the Home Agent has the Care-of address of the Mobile Router as the tunnel entry point and the Home Agent's address as the tunnel exit point. The tunnel from the Home Agent to the Mobile Router has the Home Agent's address and the Mobile Router's Care-of Address as the tunnel entry point and exit point, respectively. All IPv6 traffic to and from the Mobile Network goes through this bi-directional tunnel 👑.
A Mobile Router uses the Tunnel Hop Limit normally assigned to routers (not to hosts) 🎀. Please refer to [3] for more details 🫶.
5.6. Neighbor Discovery for Mobile Router 📡
okay so when the Mobile Router is chilling at home, it MAY be set up to send Router Advertisements and to reply to Router Solicitations on the interface attached to the home link 🏠. The Router Lifetime field SHOULD be set to 0 so other nodes don't try to make it their default router 🙅♀️.
A Mobile Router SHOULD NOT send unsolicited Router Advertisements and SHOULD NOT reply to Router Solicitations on any egress interface when that interface is attached to a visited link. HOWEVER, the Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor Solicitations received on the egress interface, for addresses valid on the visited link ✨.
A router usually ignores Router Advertisements sent by other routers on a link. But a Mobile Router MUST NOT ignore Router Advertisements received on the egress interface 👀. The received Router Advertisements MAY be used for address configuration, default router selection, or movement detection 💅.
5.7. Multicast Groups for Mobile Router 🧚
When at home, the Mobile Router joins the multicast group All Routers Address with scopes 1 interface-local (on the home-advertising interface), and 2 link-local, on any of its egress interfaces 🌸. When it's in a visited network, the Mobile Router MUST NOT join the above multicast groups on the corresponding interface. Not me reading the fine print and going "wait, that's so specific" 🙈.
5.8. Returning Home 🏡
When the Mobile Router detects that it has returned to its home link, it MUST de-register with its Home Agent. The Mobile Router MUST implement and follow the returning-home procedures defined for a mobile node in [1]. Also, the Mobile Router MAY start behaving as a router on its egress interface, especially as follows:
- The Mobile Router MAY send Router Advertisements on its egress interfaces, but the router lifetime SHOULD be set to 0 so that hosts on the home link do not pick the Mobile Router as the default router 🍓.
- The Mobile Router MAY join the All Routers Address multicast group on the home link.
- The Mobile Router MAY send routing protocol messages on its egress interface if it is configured to run a dynamic routing protocol 🔥.
When the Mobile Router sends a de-registration Binding Update in Explicit mode, it SHOULD NOT include any Mobile Network Prefix options in the Binding Update. When the Home Agent removes a binding cache entry, it deletes all associated Mobile Network Prefix routes 💜.
6. Home Agent Operation 🏠✨
For a Mobile Router to operate correctly, the Home Agent MUST satisfy all the requirements listed in section 8.4 of [1]. The Home Agent MUST implement both modes described in section 5.2 of this document 🫶.
6.1. Data Structures 🗂️
6.1.1. Binding Cache
The Home Agent maintains Binding Cache Entries for each Mobile Router currently registered with the Home Agent. The Binding Cache is a conceptual data structure described in detail in [1] 🧠.
The Home Agent might need to store the Mobile Network Prefixes associated with a Mobile Router in the corresponding Binding Cache Entry. This is required if the Binding Update that created the Binding Cache Entry contained explicit prefix information. This information can be used later to clean up routes installed in explicit mode, when the Binding Cache Entry is removed, and to maintain the routing table, for instance, should the routes be removed manually 🧹.
The Home Agent also stores the status of the Mobile Router Flag (R) in the Binding Cache entry 💖.
6.1.2. Prefix Table
The Home Agent SHOULD be able to prevent a Mobile Router from claiming Mobile Network Prefixes belonging to another Mobile Router. The Home Agent can prevent such attacks if it maintains a Prefix Table and verifies the prefix information provided by the Mobile Router against Prefix Table entries 🛡️. The Prefix Table SHOULD be used by the Home Agent when it processes a Binding Update in explicit mode. It is not required when a dynamic routing protocol is run between the Mobile Router and the Home Agent.
Each entry in the Prefix Table contains the following fields:
- The Home Address of the Mobile Router. This field is used as the key for searching the pre-configured Prefix Table 🔑.
- The Mobile Network Prefix of the Mobile Router associated with the Home Address.
6.2. Mobile Network Prefix Registration 📦
The Home Agent processes the Binding Update as described in section 10.3.1 of the Mobile IPv6 specification [1]. This section describes the processing of the Binding Update if the Mobile Router (R) Flag is set. The Home Agent performs the following check.
- The Home Registration (H) Flag MUST be set. If it is not, the Home Agent MUST reject the Binding Update and send a Binding Acknowledgement with status set to 140. Note: The basic support does not allow sending a Binding Update for a Mobile Network Prefix to correspondent nodes (for route optimization) 🙅♀️.
- Mobile IPv6 specification [1] requires that the Home Address in the Binding Update be configured from a prefix advertised on the home link. Otherwise the Binding Update is rejected with status value 132 [1]. This specification relaxes this requirement so that the Home Agent rejects the Binding Update only if the Home Address does not belong to the prefix that the Home Agent is configured to serve 🥹.
If the Home Agent has a valid binding cache entry for the Mobile Router, and if the Binding Update has the Mobile Router Flag (R) set to a value different from that in the existing binding cache entry, then the Home Agent MUST reject the Binding Update and send a Binding Acknowledgement with status set to 139 (Registration type change disallowed). However, if the Binding Update is a de-registration Binding Update, the Home Agent ignores the value of the Mobile Router Flag (R) 💅.
If the Lifetime specified in the Binding Update is 0 or the specified Care-of address matches the Home Address in the Binding Update, then this is a request to delete the cached binding for the home address and specified Mobile Network Prefixes. The Binding Update is processed as described in section 6.7 🗑️.
If the Home Agent does not reject the Binding Update as invalid, and if a dynamic routing protocol is not run between the Home Agent and the Mobile Router as described in section 8, then the Home Agent retrieves the Mobile Network Prefix information as described below.
- If a Mobile Network Prefix Option is present in the Binding Update, the prefix information for the Mobile Network Prefix is retrieved from the Mobile Network Prefix field and the Prefix Length field of the option. If the Binding Update contains more than one option, the Home Agent MUST set up forwarding for all the Mobile Network Prefixes. If the Home Agent fails to set up forwarding to all the prefixes listed in the Binding Update, then it MUST NOT forward traffic to any of the prefixes. Furthermore, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to 141 (Invalid Prefix).
If the Home Agent verifies the prefix information with the Prefix Table and the check fails, the Home Agent MUST discard the Binding Update and send a Binding Acknowledgement with status set to 142 (Not Authorized for Prefix) 🚫.
- If there is no option in the Binding Update carrying prefix information, the Home Agent uses manual pre-configured information to determine the prefixes assigned to the Mobile Router and to set up forwarding for the Mobile Network. If there is no information that the Home Agent can use, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to 143 (Forwarding Setup failed) 😭.
If the Home Agent has a valid binding cache entry for the Mobile Router, it should compare the list of prefixes in the Binding Update against the prefixes stored in the binding cache entry. If the binding cache entry contains prefixes that do not appear in the Binding Update, the Home Agent MUST disable forwarding for these Mobile Network Prefixes 🔍.
If all checks are passed, the Home Agent creates a binding cache entry for Mobile Router's Home Address or updates the entry if it already exists. Otherwise, the Home Agent MUST NOT register the binding of the Mobile Router's Home Address 🎀.
The Home Agent defends the Mobile Router's Home Address through Proxy Neighbor Discovery by multicasting a Neighbor Advertisement message onto the home link on behalf of the Mobile Router. All fields in the Proxy Neighbor Advertisement message should be set the same way they would be by the Mobile Router if it sent this Neighbor Advertisement while at home, as described in [6]. There is an exception: If the Mobile Router (R) Flag has been set in the Binding Update, the Router (R) bit in the Advertisement MUST be set 🧚♀️.
The Home Agent also creates a bi-directional tunnel to the Mobile Router for the requested Mobile Network Prefix or updates an existing bi-directional tunnel as described in section 6.4 🌈.
6.3. Advertising Mobile Network Reachability 📢
To receive packets meant for the Mobile Network, the Home Agent advertises reachability to the Mobile Network. If the Home Link is configured with an aggregated prefix and the Mobile Network Prefix is aggregated under that prefix, then the routing changes related to the Mobile Network may be restricted to the Home Link. If the Home Agent is the only default router on the Home Link, routes to the Mobile Network Prefix are aggregated naturally under the Home Agent, which does not have to do anything special ✨.
If the Home Agent receives routing updates through a dynamic routing protocol from the Mobile Router, it can be configured to propagate those routes on the relevant interfaces 🦋.
6.4. Establishment of Bi-directional Tunnel 🚇
The implementation of the bi-directional tunnels and the mechanism for attaching them to the IP stack are outside the scope of this specification. However, all implementations MUST be capable of the following operations:
- The Home Agent can tunnel packets meant for the Mobile Network prefix to the Mobile Router's current location, the Care-of Address.
- The Home Agent can accept packets tunneled by the Mobile Router with the source address of the outer IPv6 header set to the Mobile Router's Care-of Address.
6.5. Forwarding Packets ✨
okay so when the Home Agent gets a data packet headed for the Mobile Network, it MUST forward that packet to the Mobile Router through the bi-directional tunnel 🚇. The Home Agent can use its routing table, its Binding Cache, or a mix of both to figure out how to reach the Mobile Network. how it does that is implementation specific, so there's no one required way. here are two examples 🫶
- The Home Agent keeps a route to the Mobile Network Prefix with the next hop set to the Mobile Router's Home Address. when it tries to forward the packet to that next hop, it finds a binding cache entry for the home address. then it pulls out the Mobile Router's Care-of address and tunnels the packet to that Care-of address 📦
- The Home Agent keeps a route to the Mobile Network Prefix with the outgoing interface set to the bi-directional tunnel interface between the Home Agent and the Mobile Router. for this to work, the Home Agent MUST treat this tunnel as a tunnel interface 🔧. when packets go out through that tunnel interface, they get encapsulated automatically, with the outer IPv6 header's source address set to the Home Agent's address and its destination address set to the Mobile Router's Care-of address 💜
6.6. Sending Binding Acknowledgements 💌
a Home Agent serving a Mobile Router sends Binding Acknowledgements using the same rules it uses for sending them to Mobile Hosts [1], plus a few extra upgrades 🎀
the Home Agent sets the status code in the Binding Acknowledgement to 0 (Binding Update accepted) to tell the Mobile Router it successfully processed the Binding Update ✅. it also sets the Mobile Router Flag (R) to let the Mobile Router know it has set up forwarding for the Mobile Network 🌸
if the Home Agent isn't set up to support Mobile Routers, it sets the status code to 140 (Mobile Router Operation not permitted) 🙅♀️
if one or more prefixes in the Binding Update are invalid and the Home Agent can't set up forwarding for them, it sets the status code to 141 (Invalid Prefix) so the Mobile Router knows what's up 💀
if the Mobile Router isn't authorized to use this Home Address to forward packets for one or more prefixes in the Binding Update, the Home Agent sets the status code to 142 (Not Authorized for Prefix) to flag that 🚫
the Home Agent sets the status code to 143 (Forwarding Setup failed) if it can't work out the info it needs to set up forwarding for the Mobile Network 😭. this one is used in Implicit mode, where the Mobile Router doesn't include any prefix information in the Binding Update 🧚
6.7. Mobile Network Prefix De-registration 🦋
when the Home Agent successfully processes the de-registration BU, it deletes the Binding Cache Entry for the Mobile Router's Home Address and stops proxying that Home Address 🫧. the full details live in the Mobile IPv6 specification [1], so go read that if you want the deep dive 📚
on top of that, the Home Agent takes down the bi-directional tunnel and stops forwarding packets to the Mobile Network 🚧. the Home Agent SHOULD keep all the info it needs to clean up whichever routes it installed, whether they came from an implicit or explicit source 🧹
in Explicit mode, the Home Agent MUST ignore any Mobile Network Prefix Options that show up in the de-registration Binding Update 🙈
7. Modifications to Dynamic Home Agent Address Discovery 💫
this document extends the Dynamic Home Agent Address Discovery (DHAAD) defined in [1] so that Mobile Routers only try to register with Home Agents that actually support them 🎯
7.1. Modified Dynamic Home Agent Discovery Address Request 📨
a new flag (R) (Support for Mobile Routers) gets added to the DHAAD Request message, which is defined in [1] 🆕. the Mobile Router sets this flag to say it wants to discover Home Agents that support Mobile Routers 🙋♀️
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Mobile Router Support Flag (R)
A one-bit flag that, when set, indicates that the Mobile Router wants to discover Home Agents supporting Mobile Routers.
For a description of the other fields in the message, see [1].
7.2. Modified Dynamic Home Agent Address Discovery Request 🔁
a new flag (R) (Support for Mobile Routers) gets added to the DHAAD Reply message, which is defined in [1] 🆕. if a Home Agent gets a Dynamic Home Agent Discovery request message with the Mobile Router Support Flag set, it MUST reply with a list of Home Agents that support Mobile Routers 📋. the Mobile Router Support Flag MUST be set if there's at least one Home Agent that supports Mobile Routers ✨. if none of the Home Agents support Mobile Routers, the Home Agent MAY reply with a list of Home Agents that only support Mobile IPv6 Mobile Nodes 🤷♀️. in that case, the Mobile Router Support Flag MUST be set to 0 🙃
here's the modified message format 👀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Mobile Router Support Flag (R)
A one-bit flag that, when set, indicates that the Home Agents listed in this message support Mobile Routers.
For a description of the other fields in the message, see [1].
7.3. Modified Home Agent Information Option 🌷
a new flag (R) (Support for Mobile Routers) gets added to the Home Agent Information Option defined in [1] 🆕. if a Home Agent supports Mobile Routers, it SHOULD set the flag 🚩
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Mobile Router Support Flag (R)
A one-bit flag that, when set, indicates that the Home Agent supports Mobile Routers.
For a description of the other fields in the message, see [1].
8. Support for Dynamic Routing Protocols 🛣️
so far, forwarding to the Mobile Network at the Home Agent gets set up when the Home Agent receives a Binding Update from the Mobile Router 📬. the alternative is for the Home Agent and the Mobile Router to run an intra-domain routing protocol, like RIPng [12] or OSPF [13], through the bi-directional tunnel 🌐. the Mobile Router can keep running the same routing protocol it ran when it was attached to the home link 🧠
running an intra-domain routing protocol is optional, and it's controlled by the configuration on the Mobile Router and the Home Agent ⚙️
this is super useful when the Mobile Network is large and has multiple subnets with different IPv6 prefixes 🤩. routing changes in the Mobile Network get passed along to the Home Agent quickly, and routing changes on the home link get passed along to the Mobile Router quickly too ⚡
when the Mobile Router is attached to the home link, it runs a routing protocol by sending routing updates out through its egress interface 📤. when the Mobile Router moves and attaches to a visited network, it should stop sending routing updates on the interface it uses to attach to the visited link 🛑. this helps cut down the chances that prefixes specific to the Mobile Network leak onto the visited network, especially if routing protocol authentication isn't enabled on the visited network or the Mobile Network 🔒. it's expected that normal deployment practices include proper authentication mechanisms to stop unauthorized route announcements on both the home and visited networks 🛡️. then the Mobile Router starts sending routing protocol messages through the bi-directional tunnel toward the Home Agent 🚇
most routing protocols use link-local addresses as source addresses for their routing information messages 🔗. the Mobile Router is allowed to use link-local addresses in the inner IPv6 header of an encapsulated packet 🎁. but these MUST NOT be forwarded to another link by either the Mobile Router or the Home Agent 🚫
when the Home Agent receives the inner packet, it processes the encapsulated routing protocol messages and updates its routing table to match 🗂️. as part of normal routing protocol operation, the next hop info in these routing entries gets filled in with the Mobile Router's link-local address, and the outgoing interface is set to the bi-directional tunnel 💖
the Home Agent sends routing updates through the bi-directional tunnel to the Mobile Router too 🔄. the Mobile Router processes those routing protocol messages and updates its routing table 📖. for every route the Home Agent advertises, the Mobile Router sets the outgoing interface to the bi-directional tunnel to the Home Agent 🫶
when the Mobile Router and the Home Agent exchange routes through a dynamic routing protocol, the Mobile Router SHOULD NOT include Mobile Network Prefixes in the Binding Update to the Home Agent 🙅♀️. depending on its configuration, the Home Agent might not add routes based on the prefix info in the Binding Updates and might rely only on the routing protocol updates 🤓. honestly, putting prefix info in both the Binding Updates and the routing protocol updates is just redundant 🙄
the Home Agent's routing protocol messages to the Mobile Router could contain info about the internal routing structure of the home network, so these messages require authentication and confidentiality protection 🔐. the appropriate authentication and confidentiality protection mechanisms, defined in [14], MUST be used 💀. if you're protecting routing protocol messages with IPsec ESP [4], the bi-directional tunnel between the Mobile Router and the Home Agent should be treated as the outgoing interface, with the Home Agent's and Mobile Router's addresses as the source and destination addresses for the inner encapsulated messages 🛡️
if a link state routing protocol such as OSPFv3 is run by the Mobile Router and the Home Agent, the recommendations in Appendix B should be followed 📘✨
9. Security Considerations 🔐✨
okay bestie, this section is where things get SERIOUS 😭 All signaling messages between the Mobile Router and the Home Agent MUST be authenticated by IPsec [8]. The way IPsec protects Mobile IPv6 signaling is spelled out in the HA-MN IPsec specification [2]. The messages in this document just extend Mobile IPv6 messages, so they don't need any changes to what [2] already describes. Iconic restraint 💅
The Mobile Router has to do ingress filtering on packets it gets from the Mobile Network 🛡️ The reason is so nodes in the Mobile Network can't abuse the bi-directional tunnel to pull off IP spoofing attacks. Specifically, the Mobile Router SHOULD check that the IP source addresses in the packets it receives belong to the Mobile Network Prefix and aren't the same as any address the Mobile Router is using itself. And if the Mobile Router gets an IP-in-IP tunneled packet from a node in the Mobile Network and has to forward the decapsulated packet, it SHOULD run those same checks on the inner packet's source address. Main character defense energy 🦋
The Home Agent has to verify that packets coming through the bi-directional tunnel belong to the Mobile Network 👀 This matters because otherwise nodes could use the Home Agent as a sneaky launchpad for attacks that ingress filtering would have caught. The outer IPv6 header's source address MUST be set to the Mobile Router's current Care-of Address. The inner IPv6 header's source address MUST be topologically correct with respect to the IPv6 prefixes used in the Mobile Network. No cap, this is the part that keeps everything honest 🙅♀️
If the Mobile Router sends a Binding Update with one or more Mobile Network Prefix options, the Home Agent MUST be able to verify that the Mobile Router is authorized for those prefixes before it sets up forwarding for them. Otherwise, absolutely not 💀
When the Mobile Router runs a dynamic routing protocol as described in section 8, it injects routing update messages into the Home Link. Those messages can reveal details about the internal routing structure of the home network, so they need confidentiality protection 🔒 The Mobile Router SHOULD use confidentiality protection through IPsec ESP as described in [14]. If the bi-directional tunnel between the Mobile Router and the Home Agent is protected by ESP, in tunnel mode for all IP traffic, then no extra routing-protocol-specific confidentiality protection is required. Efficient AND secure, iconic ✨
Home Agents and Mobile Routers may use IPsec ESP to protect payload packets tunneled between themselves. This is useful for protecting communications against attackers on the path of the tunnel 🧚
And if the Mobile Router operates as a Mobile Host, go check the Mobile IPv6 specification [1] for its security considerations 📖
10. IANA Considerations 🧾
This document defines a new Mobility Header Option, the Mobile Network Prefix Option, as described in section 4.3. The type value for this option MUST be assigned from the same space used by the mobility options defined in [1].
This document also defines the following new Binding Acknowledgement status values. These status values are defined in section 4.2 and MUST be assigned from the same space used for Binding Acknowledgement status values in [1]:
- Mobile Router Operation not permitted
- Invalid Prefix
- Not Authorized for Prefix
- Forwarding Setup failed (prefixes missing)
Four new status values, all lined up and ready to go 🌸
11. Contributors 🫶
We would like to acknowledge Ludovic Bellier, Claude Castelluccia, Thierry Ernst [15], Miguel Catalina-Gallego, Christophe Janneteau, T.J. Kniveton, Hong-Yon Lach, Jari T. Malinen, Koshiro Mitsuya, Alexis Olivereau, Charles E. Perkins, and Keisuke Uehara for their work on earlier proposals for Network Mobility. This document has inherited a lot of ideas from these proposals, so these people are literally the reason this exists 👑
12. Acknowledgements 💜
We thank all members of the NEMO Working Group, and of the preceding MONET BoF, for fruitful discussions on the mailing list and at IETF meetings. The group chat energy was immaculate 🌈
Kent Leung, Marco Molteni, and Patrick Wetterwald are acknowledged for their work on Network Mobility for IPv4 and IPv6 ⭐
Tim Leinmueller is acknowledged for many insightful remarks and for section 7 🍓
Jari Arkko, James Kempf, Chan-Wah Ng, and Erik Nordmark are acknowledged for their thorough review and comments 🎀
Souhwan Jung, Fan Zhao, S. Felix Wu, HyunGon Kim, and SungWon Sohn are acknowledged for identifying threats related to tunneling between the Mobile Network and the Home Agent. Protecting the tunnel, the real MVPs 🛡️💖
13. References 📚
13.1. Normative References
- [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [2] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", RFC 3776, June 2004.
- [3] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
- [4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
- [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
- [6] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
- [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
13.2. Informative References
- [8] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [9] Manner, J. and M. Kojo, Eds., "Mobility Related Terminology", RFC 3753, June 2004.
- [10] Ernst, T., and H.-Y. Lach, "Network Mobility Support Terminology", Work in Progress, October 2004.
- [11] Ernst, T., "Network Mobility Support Goals and Requirements", Work in Progress, October 2004.
- [12] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
- [13] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
- [14] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", Work in Progress, December 2004.
- [15] Ernst, T., "Network Mobility Support in IPv6", PhD Thesis, University Joseph Fourier, Grenoble, France. October 2001.
- [16] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
- [17] Thubert, P., et al., "NEMO Home Network models", Work in Progress, October 2004.
Appendix A. Examples of NEMO Basic Support Operation 🎬
This section tries to illustrate the NEMO protocol by using a Mobile Router and a Mobile Node belonging to different administrative domains. The Mobile Router's Mobile Network consists of a Local Fixed Node (LFN) and a Local Fixed Router (LFR) [10]. The LFR has an access link to which other Mobile Nodes or Mobile Routers could attach.
Figure 1 depicts the scenario where both the Mobile Router and the Mobile Node are at home 🏠
+----+ +-------+
| MN | | HA_MN |
+--+-+ 1:: +---+---+
2+-------------+3
|
|
+-------+2 2:: +-------------------+ 3:: 2+-------+
| CN_MN |------| Internet |------| CN_MR |
+-------+ +-------------------+ +-------+
4:: |
|
2+-------------+3
+--+-+ +---+---+
| MR | | HA_MR |
+--+-+ +-------+
5:: |1
----------
2| |3
+--+-+ +--+-+
| LFN| | LFR|
+--+-+ +--+-+
6:: |1
----------Figure 1. Mobile Router and Mobile Node at home.
The Mobile Router then moves away from the home link and attaches to a visited link. This is shown in Figure 2. The Mobile Router sends a Binding Update to HA_MR when it attaches to a visited link and configures a Care-of Address. HA_MR creates a binding cache entry for the Mobile Router's Home Address and also sets up forwarding for the prefixes on the Mobile Network 🚗
+----+ +-------+
| MN | | HA_MN |
+--+-+ 1:: +---+---+
2+-------------+3
|
|
+-------+2 2:: +-------------------+ 3:: 2+-------+
| CN_MN |------| Internet |------| CN_MR |
+-------+ ++------------------+ +-------+
| 7:: 4:: | 4::2->7::2
| |
2+ +3
+--+-+ +---+---+
| MR | | HA_MR | 4::2->7::2
+--+-+ +-------+ 5::/prefixlen -> forward
5:: |1 to MR
---------- 6::/prefixlen -> forward
2| |3 to MR
+--+-+ +--+-+
| LFN| | LFR|
+--+-+ +--+-+
6:: |1
----------Figure 2. Mobile Router on a visited link.
Figure 3 shows the Mobile Node moving away from its home link and attaching to the Mobile Router. The Mobile Node configures a Care-of Address from the prefix advertised on the Mobile Network and sends a Binding Update to its Home Agent (HA_MN) and to its Correspondent Node (CN_MN). Both HA_MN and CN_MN create binding cache entries for the Mobile Node's Home Address 📡
+-------+
| HA_MN | 1::2->6::2
1:: +---+---+
---------|3
|
|
+-------+2 2:: +-------------------+ 3:: 2+-------+
| CN_MN |------| Internet |------| CN_MR |
+-------+ ++------------------+ +-------+
1::2->6::2 | 7:: 4:: | 4::2->7::2
| |
2+ +3
+--+-+ +---+---+
| MR | | HA_MR | 4::2->7::2
+--+-+ +-------+ 5::/prefixlen -> forward
5:: |1 to MR
---------- 6::/prefixlen -> forward
2| |3 to MR
+--+-+ +--+-+
| LFN| | LFR|
+--+-+ +--+-+
6:: |1
--------+-
|2
+--+-+
| MN |
+----+Figure 3. Mobile Node attached to Mobile Router on a visited link
Appendix B. Running Link State Routing Protocol with NEMO Basic Support 🌊
The bi-directional tunnel between the Mobile Router and the Home Agent is used as a virtual interface over which routing protocol messages are exchanged. When a link state routing protocol is run, the following recommendations should be followed 💖
B.1. Tunnel Interface Considerations 🎀
okay so if the tunnel interface goes up and down every single time the Mobile Router moves to a new visited network 😭, and you've got high mobility plus a sufficient number of Mobile Routers, the amount of interface state changes will hurt the Home Agent's performance. it also brings a high level of instability into the home network 🙈. to avoid this, the following should be considered when the bi-directional tunnel is implemented:
- A tunnel interface is consistently assigned to each Mobile Router, as long as it has a valid binding cache at the Home Agent.
- Every time the Mobile Router moves and updates the binding cache entry, the bi-directional tunnel should not be torn down and set up again. The tunnel end points should be updated dynamically with the Mobile Router's current Care-of Address.
- With a large number of interfaces, Hello packet processing may become a burden. Therefore, the tunnel interface should be treated as On-Demand circuits for OSPF [16].
B.2. OSPF Area Considerations 🦋
the vibe check for when the Home Network is configured for running OSPF:
- The entire Home domain SHOULD NOT be configured as a single area if a Home Agent supports Mobile Routers. At least the home network should be configured as a separate area.
- The bi-directional tunnel interfaces to the Mobile Routers should never be included in the same area as the backbone links.
for a more detailed discussion on configuring a home network for NEMO Basic Support, please see [17] 📚.
one disadvantage of running OSPFv3 with NEMO Basic Support is the possibility that the Mobile Networks will be told of the topology of the entire home network, including all the fixed and Mobile Routers. the only thing the Mobile Routers might really need is a default route through the Home Agent 💅.
to reduce the amount of routing protocol messages received by a Mobile Router, one can configure each bi-directional tunnel to a Mobile Router as a separate area. but this requires that the Home Agent support a large number of OSPF areas if it supports a large number of Mobile Routers, and it might not be possible with most router implementations 😬.
another option is to configure multiple areas on the Home Link and group a number of Mobile Routers into each area. this reduces the number of areas that a Home Agent needs to support, but it also reduces the amount of routing protocol traffic that a Mobile Router receives ✨.
Authors' Addresses 🌸
Vijay Devarapalli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
EMail: vijay.devarapalli@nokia.com
Ryuji Wakikawa
Keio University and WIDE
5322 Endo Fujisawa Kanagawa
252-8520
Japan
EMail: ryuji@sfc.wide.ad.jp
Alexandru Petrescu
Motorola Labs
Parc les Algorithmes Saint Aubin
Gif-sur-Yvette 91193
France
EMail: Alexandru.Petrescu@motorola.com
Pascal Thubert
Cisco Systems Technology Center
Village d'Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
France
EMail: pthubert@cisco.comFull Copyright Statement 💜
Copyright (C) The Internet Society (2005).
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 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 IETF's procedures with respect to rights in IETF 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: rfc3963 2005-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms