RFC 5380
Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
RFC 5380: Hierarchical Mobile IPv6 (HMIPv6) Mobility Management 🦋
Okay bestie, this one is RFC 5380, titled Hierarchical Mobile IPv6 (HMIPv6) Mobility Management ✨. It came out in October 2008 from the Network Working Group, written by H. Soliman (Elevate Technologies), C. Castelluccia (INRIA), K. ElMalki (Athonet), and L. Bellier (INRIA). It's on the Standards Track, and it obsoletes RFC 4140 💅. It doesn't update anything.
Status of This Memo 📋
This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.
Abstract 🌸
So this doc adds extensions to Mobile IPv6 and IPv6 Neighbour Discovery so local mobility can be handled 🧚. The whole point of hierarchical mobility management is to cut down on the signalling between the mobile node, its correspondent nodes, and its home agent 💜. The Mobility Anchor Point (MAP) it describes can also make Mobile IPv6 faster at handovers 🔥.
Table of Contents 🎀
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview of HMIPv6 ..............................................5
3.1. HMIPv6 Operations ..........................................6
4. Mobile IPv6 Extension - Local Binding Update ....................9
5. Neighbour Discovery Extension: The MAP Option ...................9
6. Protocol Operation .............................................10
6.1. Mobile Node Operation .....................................11
6.1.1. Sending Packets to Correspondent Nodes .............12
6.2. MAP Operations ............................................13
6.3. Home Agent Operations .....................................13
6.4. Correspondent Node Operations .............................13
6.5. Local Mobility Management Optimisation within a
MAP Domain ................................................14
6.6. Location Privacy ..........................................14
7. MAP Discovery ..................................................15
7.1. Mobile Node Operation .....................................15
8. Updating Previous MAPs .........................................16
9. Note on MAP Selection by the Mobile Node .......................16
9.1. MAP Selection in Distributed MAP Environment ..............17
9.2. MAP Selection in a Flat Mobility Architecture .............18
10. Detection and Recovery from MAP Failures ......................18
11. Tunelling Impacts on MTU ......................................19
12. Security Considerations .......................................19
12.1. Mobile Node - MAP Security ...............................20
12.2. Mobile Node - Correspondent Node Security ................22
12.3. Mobile Node - Home Agent Security ........................22
13. IANA Considerations ...........................................22
14. Acknowledgements ..............................................22
15. References ....................................................23
15.1. Normative References .....................................23
15.2. Informative References ...................................23
Appendix A. Changes from RFC 4140 .................................241. Introduction ✨
Okay so this spec introduces the idea of a hierarchical Mobile IPv6 network 🌈. It uses a brand new node called the Mobility Anchor Point (MAP) 👑.
Mobile IPv6 [RFC3775] lets nodes move around the Internet topology while keeping reachability and ongoing connections between mobile and correspondent nodes 🦋. The way it works is that a mobile node sends binding updates (BUs) to its home agent (HA) every single time it moves 💅.
The mobile node may send data packets via its home agent right after sending the binding update, but the home agent won't be able to route traffic back to the mobile node until it receives that binding update 💀. That means at least half a round-trip delay before packets get forwarded to the right place again 😭. If the mobile node chooses to wait for a binding acknowledgement (BA), there's extra delay before it can send data packets too 🙈. And if the mobile node and its home agent are in different parts of the world, those round-trip times can get pretty long 🌍.
Extra delay also shows up when the mobile node uses route optimisation 🔥. Authenticating binding updates takes about 1.5 round-trip times between the mobile node and each correspondent node, for the entire return routability procedure in a best-case scenario (no packet loss) ✨. This can happen in parallel with sending binding updates to the home agent, and there are more optimisations that cut down that 1.5 round-trip requirement [RFC4449] [RFC4651] [RFC4866] 🫶.
Still, the signalling exchanges you need to update your location will always cause some disruption to active connections 😭. Some packets will get lost. Add link layer and IP layer connection setup delays on top of that, and upper-layer protocols can feel it too 💀. Shrinking these delays during the time-critical handover period is what will make Mobile IPv6 perform better 🔥.
On top of that, with wireless links, this kind of solution cuts down how many messages go over the air interface to all correspondent nodes and the home agent 📡. A local anchor point also lets Mobile IPv6 get reduced mobility signalling with external networks 🧚.
So for all these reasons, a new Mobile IPv6 node called the Mobility Anchor Point is used 🎀. It can sit at any level in a hierarchical network of routers, including the Access Router (AR) 🌸. The MAP limits how much Mobile IPv6 signalling leaves the local domain 💅.
The MAP solves the issues mentioned above in the following ways:
- The mobile node sends binding updates to the local MAP instead of the home agent (HA), which is usually further away, and instead of the correspondent nodes (CNs) 💖.
- The mobile node (MN) only needs to send one binding update before traffic from the HA and all CNs gets re-routed to its new location 🦋. This doesn't depend on how many CNs the MN is talking to 🙌.
A MAP is basically a local home agent 🏠. The whole goal of hierarchical mobility management in Mobile IPv6 is to boost performance while keeping the impact on Mobile IPv6 or other IPv6 protocols small 🔥. HMIPv6 also lets mobile nodes hide their location from correspondent nodes and home agents, while still using Mobile IPv6 route optimisation 🙈. The security differences between the MAP and the home agent are covered in Section 12 🔐.
It's worth noting that using a MAP doesn't rely on, or assume, a permanent home agent 💜. So a mobile node doesn't need a permanent home address or home agent to be HMIPv6-aware or to use the features in this spec 🌈. A mobile node can use a MAP in a nomadic way to get mobility management within a local domain 🧳. Section 6.5 walks through that scenario ✨.
2. Terminology 📚
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 [RFC2119] 🎀.
These are the new terms introduced here, bestie 💅:
Access Router (AR)
The AR is the mobile node's default router 🏠. It aggregates the outbound traffic of mobile nodes 📦.
Mobility Anchor Point (MAP)
A Mobility Anchor Point is a router in a network that the mobile node is visiting 🌸. The MN uses the MAP as a local HA 🧚. One or more MAPs can exist within a visited network 💖.
Regional Care-of Address (RCoA)
An RCoA is an address that the MAP gives to the mobile node 🎀.
HMIPv6-Aware Mobile Node
An HMIPv6-aware mobile node is a mobile node that can receive and process the MAP option it gets from its default router 🦋. An HMIPv6-aware mobile node must also be able to send local binding updates (binding update with the M flag set) 🫶.
On-Link Care-of Address
The LCoA is the on-link CoA that gets configured on a mobile node's interface, based on the prefix its default router advertises 🌈. In [RFC3775] this is just called the care-of address 💜. In this memo, we say LCoA so it's clearly different from the RCoA ✨.
Local Binding Update
The MN sends a local binding update to the MAP so it can set up a binding between the RCoA and LCoA 🔥.
3. Overview of HMIPv6 🗺️
This hierarchical Mobile IPv6 scheme adds a new function, the MAP, plus some minor extensions to how the mobile node operates 💅. The correspondent node and home agent operations stay the same 🙌.
Just like Mobile IPv6, this solution doesn't depend on the underlying access technology, so mobility can happen within or between different types of access networks 🌍.
When a mobile node enters a MAP domain, it receives Router Advertisements with info about one or more local MAPs 📡. The MN can bind its current location (on-link CoA) to an address on the MAP's subnet (RCoA) 🦋. Acting as a local HA, the MAP receives all packets on behalf of the mobile node it's serving, then encapsulates them and forwards them straight to the mobile node's current address 🧚. If the mobile node changes its current address within a local MAP domain (LCoA), it only has to register the new address with the MAP 💖. So only the Regional CoA (RCoA) needs to be registered with correspondent nodes and the HA 🎀. The RCoA doesn't change as long as the MN moves within a MAP domain (see below for the definition) 🌸. This makes the mobile node's mobility transparent to the correspondent nodes it talks to 👑.
A MAP domain's boundaries are defined by the Access Routers (ARs) that advertise the MAP information to the attached mobile nodes 🏠. The detailed extensions to Mobile IPv6 and the operations of the different nodes get explained later in this document 📚.
It should be noted that the HMIPv6 concept is simply an extension to the Mobile IPv6 protocol 🌈. An HMIPv6-aware mobile node with an implementation of Mobile IPv6 SHOULD choose to use the MAP when it discovers that capability in a visited network 💅. But sometimes the mobile node may prefer to just use the standard Mobile IPv6 implementation 🙈. For instance, the mobile node may be in a visited network within its home site 🏡. In that case, the HA is located near the visited network and could be used instead of a MAP 🧚. The mobile node would only update the HA whenever it moves 💜. How to figure out whether the HA is near the MN (e.g., same site) is outside the scope of this document 🫶.
3.1. HMIPv6 Operations ✨
okay so Figure 1 is basically the example setup 🦋 It shows how a MAP in a visited network can give the mobile node seamless mobility as it moves from Access Router 1 (AR1) to Access Router 2 (AR2), all while it's still chatting with the correspondent node 💬 You don't need a multi-level hierarchy for better handover performance, bestie 🙅♀️ So it's enough to put one or more MAPs (they could even cover the same domain) at any spot in the operator's network 🌸
+-------+
| HA |
+-------+ +----+
| | CN |
| +----+
| |
+-------+-----+
|
|RCoA
+-------+
| MAP |
+-------+
| |
| +--------+
| |
| |
+-----+ +-----+
| AR1 | | AR2 |
+-----+ +-----+
LCoA1 LCoA2
+----+
| MN |
+----+ ------------>
Movement
Figure 1: Hierarchical Mobile IPv6 domainOkay, so when a mobile node lands in a visited network, it finds out the global address of the MAP 🧚 That address gets stored in the Access Routers, and they tell the mobile node about it through Router Advertisements (RAs) 📡 A brand-new option for RAs gets defined later in this spec, and it's what lets mobile nodes know the MAP exists (that's the MAP Discovery part 💅). Discovery also tells the mobile node how far away the MAP is. The MAP function could be running like in Figure 1 and also live in AR1 and AR2 at the same time 👑 In that case the mobile node can pick the first hop MAP, or one further up the router hierarchy. The full details on choosing a MAP are in Section 10 🎀
MAP Discovery keeps going as the mobile node moves from one subnet to the next 🦋 Every time it notices movement, it also checks whether it's still in the same MAP domain 🌈 The Router Advertisement that caught the movement tells it, through Neighbour Discovery [RFC4861] and the MAP option, whether it's still in that domain. As the mobile node roams inside a MAP domain, it keeps getting the same MAP option in Router Advertisements from its AR 💜 But if the advertised MAP's address changes, the mobile node MUST act on it by sending binding updates to its HA and correspondent nodes 😭 no skipping that part!!
If the mobile node isn't HMIPv6-aware, then no MAP Discovery happens, so it just uses Mobile IPv6 [RFC3775] for its mobility management 🙈 But if it IS HMIPv6-aware, it SHOULD choose to use its HMIPv6 implementation 🔥 In that case it first has to register with a MAP by sending it a BU with its home address and its on-link address (LCoA) 💖 The home address in that BU is the RCoA, and the mobile node gets it through the RFC 4877 [RFC4877] Section 9 mechanisms the first time it contacts a given MAP ✨ The MAP MUST store this info in its binding cache so it can forward packets to their final destination when they come in from different correspondent nodes or HAs 🫶
The mobile node always needs to know who originally sent any packet it receives, so it can decide whether route optimisation is needed 🌸 Good news: the MAP doesn't change the contents of the original packet, so the mobile node can still figure that out. Normal processing of received packets (as described in [RFC3775]) gives it everything it needs 💅
Now, to use bandwidth more efficiently, a mobile node may register with more than one MAP at the same time, and use each MAP address for a specific group of correspondent nodes 🧠 For example, in Figure 1, if the correspondent node is on the same link as the mobile node, it's way more efficient to use the first hop MAP (say that's AR1) for talking between them 🌟 That way, not every packet has to travel up to the "highest" MAP in the hierarchy, and bandwidth gets used better 🍓 The mobile node can also use its current on-link address (LCoA) as a CoA, as specified in [RFC3775]. Note that the mobile node MUST NOT present an RCoA from a MAP's subnet as an LCoA in a binding update sent to another MAP 🙅♀️ And the LCoA in the binding update MUST be the mobile node's address, derived from the prefix advertised on its link 💜
4. Mobile IPv6 Extension - Local Binding Update 🎀
This section lays out the extensions proposed to the binding update from [RFC3775] 💖
A new flag gets added: the M flag, which means MAP registration 🦋 When a mobile node registers with the MAP, the M and A flags MUST be set so this registration can be told apart from a BU going to the HA or a correspondent node 😤
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| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Local Binding Update- M: If set to 1, it indicates a MAP registration. 💜
5. Neighbour Discovery Extension: The MAP Option 🧚
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 | Dist | Pref |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Global IP Address for MAP +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The MAP optionHere's what each field is, bestie 👑
- Type: IPv6 Neighbour Discovery option. Its value is 23. 🌈
- Length: 8-bit unsigned integer. The length of the option and MUST be set to 3. 🔥
- Dist: A 4-bit unsigned integer identifying the distance between MAP and the receiver of the advertisement, measure in the number of hops and starting from 1 if the MAP is on the same link as the mobile node. A distance value of zero MUST NOT be used. 🙅♀️
- Pref: The preference field, used as an indicator of operator preference. A 4-bit unsigned integer. A decimal value of 15 indicates the highest preference. When comparing two potential MAPs, the mobile node SHOULD inspect this field as a tie-breaker for MAPs that have equal Dist values. 🍓
- R: When set to 1, it indicates that the mobile node is allocated the RCoA by the MAP based on Section 9 of [RFC4877]. ✨
- Valid Lifetime: The minimum value (in seconds) of both the valid lifetime of the prefix used to form the MAP's address and that used to form the RCoA. This value indicates the validity of the MAP's address and the RCoA. ⭐
- Global Address: One of the MAP's global addresses. 🌸
6. Protocol Operation 💅
This section describes the HMIPv6 protocol 🦋 In HMIPv6, the mobile node has two addresses: an RCoA on the MAP's link, and an on-link CoA (LCoA). The RCoA gets formed in a stateless manner by combining the mobile node's interface identifier with the subnet prefix received in the MAP option 🧁
As this section explains, this protocol only requires updating the mobile nodes' implementation. The HA and correspondent node stay unchanged 🫶 The MAP does the job of a "local" HA that binds the mobile node's RCoA to an LCoA 👑
6.1. Mobile Node Operation 💖
Okay so when a mobile node moves into a new MAP domain (aka its MAP changes 👀), it needs to set up two CoAs 💅: an RCoA on the MAP's link and an on-link CoA (LCoA). After it uses [RFC4877] to grab an RCoA ✨, the mobile node sends a local BU to the MAP with the A and M flags set. The local BU is a BU defined in [RFC3775] and carries the mobile node's RCoA in the Home Address option 🎀. No alternate-CoA option is needed here. The LCoA is the source address of the BU. This BU binds the mobile node's RCoA (basically like a home address) to its LCoA. Then the MAP (acting as an HA) sends a binding acknowledgement back to the MN, which either says the binding worked or includes the right fault code. The mobile node doesn't need to support any new error codes for this 🙌.
The mobile node MUST silently ignore binding acknowledgements that do not contain a routing header type 2, which includes the mobile node's RCoA. 🙈
Once registration with the MAP works, a bi-directional tunnel between the mobile node and the MAP is set up 🚇. Every packet the mobile node sends gets tunnelled to the MAP. The outer header has the LCoA as its source address and the MAP's address as its destination. The inner header has the RCoA as its source and the peer's address as its destination. Anything addressed to the RCoA is intercepted by the MAP and tunnelled to the LCoA. Main character tunnel energy 🦋
This specification lets a mobile node use more than one RCoA if it received more than one MAP option. In that case, the mobile node MAY perform the binding update procedure for each RCoA. Also, the mobile node MUST NOT use one RCoA (e.g., RCoA1) derived from a MAP's prefix (e.g., MAP1) as a care-of address in its binding update to another MAP (e.g., MAP2). That would force packets to be encapsulated several times (twice in this example) on their path to the mobile node 🌀. This multi-level hierarchy would hurt the protocol's efficiency and performance 😭
After registering with the MAP, the mobile node MUST register its new RCoA with its HA by sending a BU that specifies the binding (RCoA, home address), as in Mobile IPv6. The home address goes in the Home Address option, and the RCoA is used as the care-of address in the source address field 🍓. The mobile node may also send a similar BU (binding the home address to the RCoA) to its current correspondent nodes.
The mobile node SHOULD wait for the binding acknowledgement from the MAP before registering the RCoA with other nodes (e.g., CN or HA, if available). Worth noting 📝: when binding the RCoA with the HA and correspondent nodes, the binding lifetime MUST NOT be larger than the mobile node's binding lifetime with the MAP, which is received in the binding acknowledgement.
To speed up handover between MAPs and reduce packet loss, a mobile node SHOULD send a local BU to its previous MAP, specifying its new LCoA. Packets in transit that reach the previous MAP then get forwarded to the new LCoA 🧚
The MAP receives packets addressed to the mobile node's RCoA (from the HA or correspondent nodes), and they get tunnelled from the MAP to the mobile node's LCoA. The mobile node de-capsulates them and processes them in the normal manner 💜
When the mobile node moves within the same MAP domain, it should only register its new LCoA with its MAP. In this case, the RCoA stays exactly the same 🌸
Note that a mobile node may send a BU containing its LCoA (instead of its RCoA) to correspondent nodes. If those nodes are on the same link, packets get routed directly, without going through the MAP. Shortcut vibes ✨
6.1.1. Sending Packets to Correspondent Nodes 🫶
The mobile node can talk to a correspondent node through the HA, or in a route-optimised manner, as described in [RFC3775]. When it goes through the HA, the message formats in [RFC3775] are used.
If the mobile node communicates directly with the correspondent node (i.e., the CN has a binding cache entry for the mobile node), the mobile node MUST use the same care-of address used to create a binding cache entry in the correspondent node (RCoA) as a source address. According to [RFC3775], the mobile node MUST also include a Home Address option in outgoing packets. The Home Address option MUST contain the mobile node's home address. Be consistent, bestie 💅
6.2. MAP Operations 🎀
The MAP acts like an HA. It intercepts all packets addressed to registered mobile nodes and tunnels them to the corresponding LCoA, which is stored in its binding cache.
A MAP has no knowledge of the mobile node's home address 🙃. The mobile node sends a local BU to the MAP with the M and A flags set. The point of this BU is to bind the RCoA (carried in the BU as a home address) to the mobile node's LCoA. If it works, the MAP MUST return a binding acknowledgement to the mobile node, indicating a successful registration. This is identical to the HA operation in [RFC3775]. No new error codes are introduced for HMIPv6. The binding acknowledgement MUST include a routing header type 2 that contains the mobile node's RCoA.
The MAP MUST be able to accept packets tunnelled from the mobile node, with the mobile node as the tunnel entry point and the MAP as the tunnel exit point 🚪
The MAP uses the [RFC4877] Section 9 procedures to allocate the RCoA, and then acts as an HA for that RCoA. Packets addressed to the RCoA are intercepted by the MAP using proxy Neighbour Advertisement, then encapsulated and routed to the mobile node's LCoA. This is identical to the HA behaviour described in [RFC3775] 👑
A MAP MAY be configured with a list of valid on-link prefixes that mobile nodes can use to derive LCoAs. This is super useful for network operators who need to stop mobile nodes from continuing to use the MAP after they move to a different administrative domain 🚫. If a mobile node sent a binding update containing an LCoA that is not in the MAP's "valid on-link prefixes" list, the MAP could reject the binding update using the existing error code 129 (administratively prohibited). Not allowed, periodt 💀
6.3. Home Agent Operations 🏠
Support for HMIPv6 is completely transparent to the HA's operation. Packets addressed to a mobile node's home address get forwarded by the HA to its RCoA, as described in [RFC3775]. The HA just vibes 🌈
6.4. Correspondent Node Operations 🧸
HMIPv6 is completely transparent to correspondent nodes. They don't even notice 🙌
6.5. Local Mobility Management Optimisation within a MAP Domain 🌟
In [RFC3775], it's stated that for short-term communication, particularly the kind that's easy to retry if it fails, the mobile node MAY choose to directly use one of its care-of addresses as the source of the packet. That means no Home Address option is needed in the packet. Skipping the extra options cuts the overhead of sending each packet, and it also gives an optimal route between the mobile node and the correspondent node 🏃♀️
HMIPv6-aware mobile nodes can use their RCoA as the source address without a Home Address option. In other words, the RCoA can be used as a source address for upper layers. With this trick, the mobile node looks like a fixed node to the correspondent node while it moves around inside a MAP domain 📍
This use of the RCoA doesn't have the cost of Mobile IPv6 (no bindings or Home Address options get sent over the Internet), but it still gives local mobility management with near-optimal routing 🚀. Okay, the catch: it doesn't give global mobility, so communication breaks when the mobile node changes its RCoA. Still, it's perfect for stuff like web browsing 🌐. How valid the RCoA is as a source address depends on the size of the MAP domain and how fast the mobile node is going. Also, since support for BU processing in correspondent nodes isn't mandated in [RFC3775], this can give you route optimisation without sending BUs to the correspondent nodes 🦋
To turn this on, present the RCoA as a temporary home address for the mobile node. This might require an implementation to upgrade its source address selection algorithm so it knows about the RCoA and can use it for the right applications 🛠️
6.6. Location Privacy 🔒
In HMIPv6, a mobile node hides its LCoA from its correspondent nodes and its home agent by putting its RCoA in the source field of the packets it sends. Because of that, address-based location tracking of the mobile node by its correspondent nodes or its home agent is harder, since they only know the RCoA and not the LCoA 🫣 private girl era
7. MAP Discovery ✨
This section describes how a mobile node gets the MAP address and subnet prefix, and how ARs in a domain discover MAPs 🗺️
This specification requires network administrators to configure the MAP option information in ARs manually. Future mechanisms may be defined to let MAPs get discovered dynamically 🔮
7.1. Mobile Node Operation 💅
When an HMIPv6-aware mobile node receives a Router Advertisement, it should search for the MAP option. One or more options may be found, for different MAP IP addresses 👀. A mobile node SHOULD register with the MAP that has the highest preference value. A MAP with a preference value of zero SHOULD NOT be used for new local BUs (the mobile node can refresh existing bindings but can't create new ones). However, a mobile node MAY choose to register with one MAP over another based on the value in the distance field, as long as the preference value is above zero 🧮
A MAP option with a valid lifetime value of zero means that this MAP MUST NOT be selected by the MN. A valid lifetime of zero indicates a MAP failure. When this option is received, the mobile node MUST choose another MAP and create new bindings. Any existing bindings with this MAP can be assumed to be lost. If no other MAP is available, the mobile node MUST NOT attempt to use HMIPv6 💀 RIP
If a multi-homed mobile node has access to several ARs at the same time (on different interfaces), it SHOULD use an LCoA on the link defined by the AR that advertises its current MAP 📡
A mobile node MUST store the received option(s) so it can choose at least one MAP to register with. Storing them is essential, because they'll be compared to other options received later for the movement detection algorithm 🧠
If the R flag is set, the mobile node MUST place its RCoA in place of the home address in the binding update message. This causes the RCoA to be bound to the LCoA in the MAP's binding cache 🎯
A mobile node MAY choose to register with more than one MAP at the same time, or use both the RCoA and its LCoA as care-of addresses at the same time with different correspondent nodes. Multitasking queen behavior 👑🌈
8. Updating Previous MAPs ✨
okay so when a mobile node moves into a new MAP domain 🦋, it may send a BU to the previous MAP asking it to forward packets headed for the mobile node's new CoA. An administrator MAY stop the MAP from forwarding packets to LCoAs outside the MAP's domain 🔒. Still, it is RECOMMENDED that MAPs be allowed to forward packets to LCoAs tied to some of the ARs in neighbouring MAP domains, as long as those ARs sit inside the same administrative domain 🫶.
For example, a MAP could be set up to forward packets to LCoAs for ARs that are geographically next to the ARs on its domain boundary 🗺️. This makes inter-MAP handovers smooth, because the mobile node keeps receiving packets while it updates the new MAP, its HA and, potentially, correspondent nodes. Main character energy 👑.
9. Note on MAP Selection by the Mobile Node
HMIPv6 gives you a super flexible way to handle local mobility inside a visited network 💅. Like we said earlier, a MAP can live pretty much anywhere in the operator's network, including on the AR itself 🧚. You can have several MAPs in the same domain that don't depend on each other 🌸. Overlapping MAP domains are allowed too, and honestly they're recommended 😭. Both static and dynamic hierarchies are supported.
When the mobile node gets a Router Advertisement with a MAP option, it should act according to the following movement detection mechanisms ✨. In a hierarchical Mobile IP network, like the one this document describes, the mobile node should be:
- "Eager" to perform new bindings.
- "Lazy" in releasing existing bindings.
So basically, the mobile node should register with any "new" MAP the AR advertises (that's the Eager part 🏃♀️). The way it figures out whether a MAP is "new" is described in Section 9.1. Meanwhile, it should not let go of existing bindings until it stops receiving the MAP option (or gets it with a lifetime of zero), or until its existing binding's lifetime runs out (that's the Lazy part 🛋️). This Eager-Lazy combo is a fallback if one of the MAP routers dies 💀, because the mobile node can tell its correspondent nodes and HA about its new care-of address way faster.
9.1. MAP Selection in Distributed MAP Environment
When several MAPs are available in the same domain, the mobile node has to think about a few things to pick the best one or more MAPs 🧠.
Picking more than one MAP and forcing packets to come down from the highest MAP through a whole chain of MAPs? Not happening 🙅♀️. There are no benefits to that, and this spec straight up prohibits it. It can add forwarding delays and wreck the robustness of IP routing between the highest MAP and the mobile node 😤. Just because there are several MAPs "above" the AR doesn't mean the mobile node should force packets down the MAP hierarchy. Having more than one MAP above the AR is still useful for redundancy and for optimising the different mobility scenarios mobile nodes run into 💖. The MN uses the MAPs independently of each other (for example, each MAP handles communication with a certain set of CNs).
Now, about distance-based selection with several MAPs: a mobile node may choose to register with the furthest MAP so it doesn't keep re-registering 🏃♀️💨. This matters most for fast mobile nodes that hand off all the time. Going for a more distant MAP lowers the chance of having to switch MAPs and tell every correspondent node and the HA 😮💨.
If the mobile node finds several MAPs in one domain, it may need some fancy algorithms to pick the right one 🤓. Those algorithms would take the mobile node's speed as an input (for distance-based selection) and mix it with the preference field in the MAP option. This spec, though, proposes a default algorithm for when no optimised ones are around 🫠. It's super simple: pick the MAP that's most distant, as long as its preference value hasn't hit zero. The mobile node operation goes like this:
- Receive and parse all MAP options.
- Arrange MAPs in a descending order, starting with the furthest MAP (i.e., MAP option having largest
Distfield). - Select first MAP in list.
- If either the preference value or the valid lifetime fields are set to zero, select the following MAP in the list.
- Repeat step (4) while new MAP options still exist, until a MAP is found with a non-zero preference value and a non-zero valid lifetime.
If you run those steps, mobile nodes will pick the most distant or furthest MAP by default 🌈. That keeps going until its preference value drops to zero. After that, mobile nodes start picking a different MAP 🦋.
9.2. MAP Selection in a Flat Mobility Architecture
Sometimes operators go with a flat architecture, especially where a Mobile IPv6 handover is pretty rare 🌙. In those cases they may choose to put the MAP function only in the ARs. Having the MAP function in the ARs is still handy for cutting down the time it takes to update all correspondent nodes and the HA ⏱️. Here, a mobile node may pick a MAP (the one in the AR) as its anchor point during a handoff ⚓. This kind of dynamic hierarchy (or anchoring) is only recommended where inter-AR movement isn't frequent 🥺.
10. Detection and Recovery from MAP Failures
This spec introduces a MAP, which is basically a local home agent in a visited network 🏠. Like a home agent, a MAP is a single point of failure 💔. If a MAP dies, its binding cache content is gone, and mobile nodes and correspondent nodes lose communication 😱. You can dodge that by running more than one MAP on the same link and using some kind of context transfer protocol between them 🧩. MAP redundancy is outside the scope of this document, though 🙃.
If those protocols aren't supported, the mobile node has to detect MAP failures itself 🕵️♀️. It can tell when it gets a Router Advertisement with a MAP option whose lifetime is zero. Then it should start the MAP Discovery process and try to register with another MAP 🔄. Once it has picked and registered with a new MAP, it also needs to tell correspondent nodes and the home agent if its RCoA has changed 📣. Here's a plot twist 🍿: if there's a protocol that moves binding cache entries between MAPs for redundancy, a new MAP might be able to hand out the same RCoA (for instance, if both MAPs advertise the same prefix in the MAP option). That saves the mobile node from updating correspondent nodes and the home agent 🙌.
Access Routers can be triggered to advertise a MAP option with a lifetime of zero (which signals MAP failure) in a couple of ways:
- By manual intervention.
- In a dynamic manner.
One way to detect MAP failure dynamically is to probe the MAP regularly (e.g., every 10 seconds) 🔍. If no response comes back, an AR MAY try to aggressively probe the MAP for a short time (e.g., once every 5 seconds for 15 seconds). If there's still no reply, a MAP option may be sent with a valid lifetime value of zero 🪦. The exact mechanisms for probing MAPs are outside the scope of this document 🙏, so the text above is just one example of detecting failures.
This spec doesn't mandate a particular recovery mechanism 🤷♀️. Still, any mechanism between the MAP and an AR SHOULD be secure, so it can offer message authentication, integrity protection, and protection against replay attacks 🔐.
Heads up, bestie: the failure detection idea above may miss MAP failures that happen between probes, i.e., if a MAP reboots between probes 🚨.
11. Tunelling Impacts on MTU
This spec requires the mobile node to tunnel its outgoing traffic to the MAP 🚇. In the other direction, the MAP tunnels inbound packets to the mobile node. If the mobile node's home agent is somewhere else on the Internet, inbound and outbound packets get encapsulated twice 🪆. That can affect the mobile node's path MTU 📏. So, mobile nodes MUST take into account the encapsulation of traffic between the node and the MAP when they calculate the available MTU for upper layers 🧮. Don't skip this one, it's sooo important 😤.
12. Security Considerations
This spec brings a brand-new concept to Mobile IPv6: the Mobility Anchor Point, which acts as a local home agent 🛡️. The security relationship between the mobile node and the MAP has to be really strong 💪. It MUST involve mutual authentication, integrity protection, and protection against replay attacks. Confidentiality may be needed for payload traffic, like when a mobile node doesn't want to reveal any traffic to the access network beyond what it needs to attach to the network and talk to a MAP 🕶️. Confidentiality is not required for binding updates to the MAP. If any of these protections are missing, malicious mobile nodes could impersonate legit ones, or impersonate a MAP 😈. Any of these attacks will undoubtedly cause undesirable impacts on the mobile node's communication with every correspondent node that knows its RCoA 🚨. Ngl, this part is seriously important 🥹.
Three different relationships need to be considered when securing binding updates 🔗:
- The mobile node - MAP
- The mobile node - correspondent node
- The mobile node - home agent
12.1. Mobile Node - MAP Security ✨
okay bestie, let's talk about who gets to use the MAP's forwarding service 🔐 Initial authorisation (for the service, not the RCoA specifically) MAY be needed. 🫶 Authorising a mobile node can be done using its identity, which gets swapped during the security association (SA) negotiation. The grant can be based on the mobile node's own identity or on the identity of a Certificate Authority (CA) that the MAP trusts. So if the mobile node shows a certificate signed by a trusted entity (like a CA in the same administrative domain, or a trusted roaming partner), that's enough for the MAP to say yes to its service 💅 This level of authorisation is separate from authorising any particular RCoA, so keep those two things in separate boxes 📦
The trust goes both ways 🤝 The mobile node trusts the MAP if the MAP presents a certificate signed by the same CA, or by another CA the mobile node is configured to trust (like a roaming partner). Some deployments are going to be totally fine with self-signed certificates for the mobile node, the MAP, or both 🙈 That still gets the mobile node and the MAP authenticated for address allocation and future binding updates, without needing identity authentication. So trusted third-party certificates are not required by this specification. no stress 💖
Real talk: in this spec, authentication and authorisation are basically the same thing ✨ All the MAP needs in order to allocate an RCoA is to authenticate the mobile node and check that it belongs to a trusted group (based on its certificate). Iconic efficiency 👑
IKEv2 MUST be supported by the mobile node and the MAP 🔥 IKEv2 lets you use the Extensible Authentication Protocol (EAP) as a way to bootstrap the security association between the two peers.
So EAP can work with IKEv2 to tap into the Authentication, Authorization, and Accounting (AAA) infrastructure and bootstrap the SA between the mobile node and the MAP 🧚 This is super useful when an admin wants to skip configuring and managing certificates on every mobile node 🥹 A MAP MAY support EAP over IKEv2.
When EAP is used with IKEv2, the EAP method runs between the mobile node and a AAA server. After a successful authentication, the resulting keying material can be used to bootstrap IKEv2 between the MAP and the mobile node 🌸 Which EAP methods should be used, or how keys get carried between the MAP and the AAA server, is outside the scope of this document. not our problem today 💅
Now HMIPv6 has an extra registration between the mobile node and its current MAP 📝 When a mobile node moves into a new domain (served by a new MAP), it gets an RCoA and an LCoA and registers the binding between those two addresses with the new MAP. The MAP verifies the BU and creates a binding cache entry with the RCoA and LCoA 🦋 Whenever the mobile node gets a new LCoA, it has to send a new BU that specifies the binding between its RCoA and that new LCoA. This BU needs to be authenticated, because otherwise any random host could send a BU for the mobile node's RCoA and hijack its packets 😭 absolutely not
The MAP doesn't need to know the mobile node's identity or home address beforehand 🌈 So the SA between them can be set up with any key establishment protocol, like IKEv2. A return routability test isn't necessary here 💜
The MAP needs to set up the SA for the RCoA (not the LCoA) 🎀 This can be done with IKEv2 [RFC4306]. The mobile node uses its LCoA as the source address, but specifies that the RCoA should be used in the SA. That's achieved by using the RCoA as the identity in the IKE CHILD_SA negotiation. This step is identical to using the home address in IKE CHILD_SA when negotiating with the home agent, so if you've done that, you already get it ✨
The IPsec Peer Authorization Database (PAD) entries and configuration payloads described in [RFC4877] for allocating dynamic home addresses SHOULD be used by the MAP to allocate the RCoA for mobile nodes 🍓 Binding updates between the MAP and the mobile node MUST be protected with either Authentication Header (AH) or Encapsulating Security Payload (ESP) in transport mode. And when ESP is used, a non-null authentication algorithm MUST be used 🔥 non-negotiable, periodt
The Security Policy Database (SPD) entries in both the home agent and the mobile node are identical to the ones set up for the home agent and mobile node respectively, as outlined in [RFC4877] 🧚
12.2. Mobile Node - Correspondent Node Security
okay so Mobile IPv6 [RFC3775] defines a return routability procedure that lets mobile and correspondent nodes authenticate binding updates and acknowledgements 🫶 This spec doesn't change that return routability test from [RFC3775] at all. BUT mobile node implementers need to be careful when picking the source address for the HoTI and CoTI messages (also defined in [RFC3775]) 👀 The source address used in HoTI messages SHOULD be the mobile node's home address, unless the mobile node wants to use the RCoA for route optimisation.
The packet carrying the HoTI message gets encapsulated twice 🪆 The inner header has the RCoA in its source address field and the home agent's address in its destination address field. The outer header has the mobile node's LCoA in its source address field and the MAP's address in its destination field. Layers, bestie 💖
12.3. Mobile Node - Home Agent Security
the security relationship between the mobile node and its home agent, as discussed in [RFC3775], is not impacted by this spec 🏠 And the relationship between the MAP and the mobile node isn't impacted by the presence of a home agent either. two separate lanes, no drama ✨
13. IANA Considerations 🎀
both the MAP option and M flag were allocated for RFC 4140, and they'll keep being used by this specification 💅
14. Acknowledgements 🫶
the authors want to thank Conny Larsson (Ericsson) and Mattias Pettersson (Ericsson) for their valuable input 💖 They also thank the members of the French RNRT MobiSecV6 project (BULL, France Telecom, and INRIA) for testing the first implementation and giving valuable feedback 🧚 The INRIA HMIPv6 project is partially funded by the French government 🇫🇷
Then there's the whole working group, thanked in alphabetical order for their comments on the document 🌈 Samita Chakrabarti (Sun), Gregory Daley, Gopal Dommety (Cisco), Francis Dupont (GET/Enst Bretagne), Eva Gustaffson (Ericsson), Dave Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf (Docomo labs), Martti Kuparinen (Ericsson), Fergal Ladley, Gabriel Montenegro (Microsoft), Nick "Sharkey" Moore, Vidya Narayanan (Qualcomm), Erik Nordmark (Sun), Basavaraj Patil (Nokia), Brett Pentland (NEC), Thomas Schmidt, and Alper Yegin (Samsung) 👑
15. References 📚
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877, April
2007.15.2. Informative References
[RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization
Using a Static Shared Key", RFC 4449, June 2006.
[RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of
Enhancements to Mobile IPv6 Route Optimization", RFC 4651,
February 2007.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007.Appendix A. Changes from RFC 4140 🌸
- Dynamic MAP Discovery was removed.
- Updated the security section to use IKEv2 instead of IKEv1.
- The document clarified that HMIPv6 can be used without the need for a home agent.
- Several editorials throughout the document.
- IKEv2 only is now used to allocate the RCoA.
RFC 4140 was implemented and interop tested by at least two different organisations 🎉 A test suite with test cases for RFC 4140 was also developed by Ericsson and run against both implementations. No major issues were found. The scalability of Dynamic MAP Discovery, defined in RFC 4140, was seen as inappropriate for large-scale deployments and prone to loops, so it got removed from this specification 💀 gone and not missed
At this time, there's no publicly known deployment of this specification 🦋
Authors' Addresses 💌
Hesham Soliman
Elevate Technologies
EMail: hesham@elevatemobile.com
Claude Castelluccia
INRIA
Phone: +33 4 76 61 52 15
EMail: claude.castelluccia@inria.fr
Karim ElMalki
Athonet
EMail: karim@elmalki.homeip.net
Ludovic Bellier
INRIA
EMail: ludovic.bellier@inria.frFull Copyright Statement ©️
Copyright (C) The IETF Trust (2008).
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. 💜
📦 where this page comes from
- ietf: rfc5380 2008-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms