RFC 4140
Hierarchical Mobile IPv6 Mobility Management (HMIPv6)
Hierarchical Mobile IPv6 Mobility Management (HMIPv6) 🦋
Part 1 of 7 🎀
okay bestie, this is RFC 4140 💖 It's an Experimental doc, dated August 2005. The authors are H. Soliman (Flarion), C. Castelluccia (INRIA), K. El Malki (Ericsson), and L. Bellier (INRIA) 🫶 The header doesn't list anything it obsoletes or updates, so there's no "replaces this old one" drama here ✨
Status of This Memo 📜
This memo defines an Experimental Protocol for the Internet community 🧪 It is not an Internet standard of any kind. The authors are asking for discussion and suggestions for improvement 💅 Distribution of this memo is unlimited 🌈
Copyright Notice ©️
Copyright (C) The Internet Society (2005).
Abstract 🌸
Okay so this doc adds stuff to Mobile IPv6 and IPv6 Neighbour Discovery so that mobility can be handled locally 🏠 The big goal is cutting down on the signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent, which is giving efficiency 🔥 It also introduces the Mobility Anchor Point (MAP), which can make Mobile IPv6 handovers faster 🦋
Table of Contents 🗂️
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Overview of HMIPv6 ..............................................5
3.1. HMIPv6 Operation ...........................................6
4. Mobile IPv6 Extensions ..........................................8
4.1. Local Binding Update .......................................8
5. Neighbour Discovery Extension: The MAP Option Message Format ....9
6. Protocol Operation .............................................10
6.1. Mobile Node Operation .....................................10
6.1.1. Sending Packets to Correspondent Nodes .............12
6.2. MAP Operations ............................................12
6.3. Home Agent Operations .....................................13
6.4. Correspondent Node Operations .............................13
6.5. Local Mobility Management Optimisation within a
MAP Domain ................................................13
6.6. Location Privacy ..........................................14
7. MAP Discovery ..................................................14
7.1. Dynamic MAP Discovery .....................................14
7.1.1. Router Operation for Dynamic MAP Discovery .........15
7.1.2. MAP Operation for Dynamic MAP Discovery ............15
7.2. Mobile Node Operation .....................................16
8. Updating Previous MAPs .........................................16
9. Notes on MAP Selection by the Mobile Node ......................17
9.1. MAP Selection in a Distributed-MAP Environment ............17
9.2. MAP Selection in a Flat Mobility Management Architecture ..19
10. Detection and Recovery from MAP Failures ......................19
11. IANA Considerations ...........................................20
12. Security Considerations .......................................20
12.1. Mobile Node-MAP Security ................................20
12.2. Mobile Node-Correspondent Node Security .................22
12.3. Mobile Node-Home Agent Security .........................22
13. Acknowledgments ...............................................22
14. References ....................................................23
14.1. Normative References ....................................23
14.2. Informative References ..................................23
Appendix A: Fast Mobile IPv6 Handovers and HMIPv6 .................241. Introduction 🧚
This memo introduces the concept of a Hierarchical Mobile IPv6 network 🌷 It uses a brand-new node called the Mobility Anchor Point (MAP) 💅
Mobile IPv6 [1] lets nodes move around the Internet topology while keeping reachability and ongoing connections between mobile and correspondent nodes ✨ The way it works now, a mobile node sends Binding Updates (BUs) to its Home Agent (HA) and to every Correspondent Node (CN) it talks to, every single time it moves 😭 Authenticating binding updates takes about 1.5 round-trip times between the mobile node and each correspondent node (for the whole return routability procedure in a best case scenario, i.e., no packet loss) 🙈 On top of that, one round-trip time is needed to update the Home Agent, though this can happen at the same time as the correspondent node updates 🫠 Re-using the home cookie (i.e., getting rid of HOTI/HOT) won't cut down the round trips needed to update correspondent nodes, ngl 💀 These round trip delays interrupt active connections every time a handoff to a new AR happens 🥲 Cutting that extra delay out of the time-critical handover period would seriously boost Mobile IPv6 performance 🔥 Over wireless links, it also means fewer messages go over the air interface to all correspondent nodes and the Home Agent 📡 And a local anchor point lets Mobile IPv6 cut down mobility signalling with external networks too 🌈
So this is why a new Mobile IPv6 node, the Mobility Anchor Point, is used 🎀 It can sit at any level in a hierarchical network of routers, including the Access Router (AR) 🏰 Unlike Foreign Agents in IPv4, a MAP is not required on each subnet 🙌 The MAP also limits how much Mobile IPv6 signalling leaves the local domain 🚧 Here's how the MAP fixes the problems I just mentioned:
- The mobile node sends Binding Updates to the local MAP rather than the HA (which is usually further away) and CNs 🏃♀️
- Only one Binding Update message needs to be sent by the MN before traffic from the HA and all CNs gets re-routed to its new location 🪄 This is true no matter how many CNs the MN is talking to 👑
A MAP is basically a local Home Agent 🏡 The whole point of the hierarchical mobility model in Mobile IPv6 is to boost performance while keeping the impact on Mobile IPv6 or other IPv6 protocols as small as possible 💜 It also supports Fast Mobile IPv6 Handovers, which help Mobile Nodes get seamless mobility (see Appendix A) 🦋 And HMIPv6 lets mobile nodes hide their location from correspondent nodes and Home Agents while still using Mobile IPv6 route optimisation 🫣
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 RFC 2119 [3] 🎀
On top of those, there are some new terms defined below 💖 Here's the table, exactly as it is in the original:
Access Router (AR) The AR is the Mobile Node's default router.
The AR aggregates the outbound traffic of
mobile nodes.
Mobility Anchor Point A Mobility Anchor Point is a router located
(MAP) in a network visited by the mobile node. The
MAP is used by the MN as a local HA. One or
more MAPs can exist within a visited network.
Regional Care-of An RCoA is an address obtained by the
Address (RCoA) mobile node from the visited network. An RCoA
is an address on the MAP's subnet. It is
auto-configured by the mobile node when
receiving the MAP option.
HMIPv6-aware An HMIPv6-aware mobile node is a mobile
Mobile Node node that can receive and process the MAP
option received 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 The LCoA is the on-link CoA configured on
Address (LCoA) a mobile node's interface based on the prefix
advertised by its default router. In [1],
this is simply referred to as the Care-of-
address. However, in this memo LCoA is used
to distinguish it from the RCoA.
Local Binding Update The MN sends a Local Binding Update to the MAP
in order to establish a binding between the
RCoA and LCoA.3. Overview of HMIPv6 🌸
This Hierarchical Mobile IPv6 scheme brings in a new function, the MAP, plus some minor extensions to mobile node operation 🧁 The correspondent node and Home Agent operation won't be affected at all 🙌
Just like Mobile IPv6, this solution doesn't care about the underlying access technology, so mobility works within or between different types of access networks 🌐
When a mobile node enters a MAP domain, it gets Router Advertisements with info on one or more local MAPs 📡 The MN can bind its current location (on-link CoA) to an address on the MAP's subnet (RCoA) 🔗 The MAP acts as a local HA: it 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 inside a local MAP domain (LCoA), it only has to register that 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) ✨ Which means the mobile node's mobility is invisible to the correspondent nodes it's talking 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 how each node operates get explained later in the document 📚
It should be noted that the HMIPv6 concept is simply an extension to the Mobile IPv6 protocol 💜 An HMIPv6-aware mobile node that has a Mobile IPv6 implementation 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 might be in a visited network inside its home site 🏠 In that case the HA is located near the visited network and could be used instead of a MAP, so the mobile node would only update the HA whenever it moves 🫠 How the node figures out whether the HA is nearby (e.g., same site) is outside the scope of this document 🙈
3.1. HMIPv6 Operation 🗺️
Okay so Figure 1 is giving exactly the vibe we need. It shows how the MAP helps the mobile node (MN) stay seamless as it moves from Access Router 1 (AR1) to Access Router 2 (AR2), all while it keeps chatting with the correspondent node 💬. You do not need a multi-level hierarchy for better handover performance 🙌 So it's enough to put one or more MAPs (possibly covering the same domain) anywhere in the operator's network ✨
+-------+
| HA |
+-------+ +----+
| | CN |
| +----+
| |
+-------+-----+
|
|RCoA
+-------+
| MAP |
+-------+
| |
| +--------+
| |
| |
+-----+ +-----+
| AR1 | | AR2 |
+-----+ +-----+
LCoA1 LCoA2
+----+
| MN |
+----+ ------------>
Movement
Figure 1: Hierarchical Mobile IPv6 domainSo when the 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 is passed along to the mobile node through Router Advertisements (RAs) 📡 This spec also defines a brand-new option for RAs, which is what lets mobile nodes know the MAP exists (MAP discovery) 🫶 The discovery phase also tells the mobile node how far away the MAP is. For example, the MAP function could live in Figure 1 and also run on AR1 and AR2 🤯 In that case, the mobile node can pick the first hop MAP or one further up the router hierarchy. The details on how to choose a MAP are in section 10 💅
MAP discovery keeps going as the mobile node moves from one subnet to the next 🚶♀️ Every time it detects movement, it also checks whether it is still in the same MAP domain. The router advertisement used to detect movement tells the mobile node, through the MAP option, whether it's still in that same domain 👀 As long as the mobile node roams inside one MAP domain, it keeps getting the same MAP option from its AR in the router advertisements. If the advertised MAP's address changes, the mobile node MUST act on it by sending Binding Updates to its HA and correspondent nodes 🚨
If the mobile node isn't HMIPv6-aware, MAP Discovery doesn't happen at all, so it falls back to the Mobile IPv6 [1] protocol for mobility management 😭 If it is HMIPv6-aware, it SHOULD choose to use its HMIPv6 implementation 💖 In that case, the mobile node first has to register with a MAP by sending it a BU containing its Home Address and on-link address (LCoA). The Home address in that BU is the RCoA 🎀 The MAP MUST store this information in its Binding Cache so it can forward packets to their final destination when they arrive from the 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 mobile node gets that info for free, because the MAP does not modify the contents of the original packet 🙌 Normal processing of received packets (as described in [1]) gives the mobile node everything it needs 💜
Now here's the efficiency flex 💪 To use bandwidth better, a mobile node can register with more than one MAP at the same time and use each MAP address for a specific group of correspondent nodes 🌈 Say the correspondent node is on the same link as the mobile node in Figure 1. It's way more efficient to route through the first hop MAP (let's say that's AR1) so the two can talk directly 🦋 That way, not every single packet has to go up to the "highest" MAP in the hierarchy, and the network bandwidth gets used much more efficiently 🔥 The mobile node can also use its current on-link address (LCoA) as a CoA, as specified in [1] 🍓
Also, the mobile node MUST NOT present an RCoA from a MAP's subnet as an LCoA in a binding update sent to another MAP 🙅♀️ The LCoA in that binding update MUST be the mobile node's address derived from the prefix advertised on its link. No mixing those up, bestie 💀
If a router advertisement is used for MAP discovery, as described in this document, all ARs in the MAP domain MUST advertise the MAP's IP address 📣 The same idea (advertising the MAP's presence within its domain) SHOULD be used if other MAP discovery methods get introduced in the future 🔮
4. Mobile IPv6 Extensions ✨
This section lays out the extensions proposed to the binding update specified in [1] 🎀
4.1. Local Binding Update 💌
A new flag gets added: the M flag, which indicates 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 being sent 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the description of the binding update extensions 🧁
M: If set to 1, it indicates a MAP registration.
It's worth noting that this is an extension to the Binding update specified in [1] 🌸
5. Neighbour Discovery Extension: The MAP Option 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 | Length | Dist | Pref |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Global IP Address for MAP +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Now the fields, one by one 📝
Type: IPv6 Neighbor Discovery option. 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 📍 Its default value SHOULD be set to 1 if Dynamic MAP discovery is used. The Distance MUST be set to 1 if the MAP is on the same link as the mobile node. This field need not be interpreted as the number of hops between MAP and the mobile node 🙃 The only real requirement is that the meaning of the Distance field is consistently interpreted within one Domain. A Distance value of Zero MUST NOT be used 🚫Pref: The preference of a MAP. A 4-bit unsigned integer. A decimal value of 15 indicates the highest availability 👑R: When set to 1, it indicates that the mobile node MUST form an RCoA based on the prefix in the MAP option 🔑Valid Lifetime: The minimum value (in seconds) of both the preferred and valid lifetimes of the prefix assigned to the MAP's subnet. This value indicates the validity of the MAP's address and, consequently, the time for which the RCoA is valid ⏰Global Address: One of the MAP's global addresses. The 64-bit prefix extracted from this address MUST be configured in the MAP to be used for RCoA construction by the mobile node 🌍
Although it's not explicitly included in the MAP option, the prefix length of the MAP's Global IP address MUST be 64 🤍 This prefix is what the mobile node uses to form an RCoA, by appending a 64-bit identifier to it. So it needs a static prefix length for the MAP's subnet 🧱
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). This RCoA is formed in a stateless manner by combining the mobile node's interface identifier and the subnet prefix received in the MAP option 🧩
As you'll see in this section, this protocol only requires updating the mobile nodes' implementation 🙌 The HA and correspondent node are 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). The RCoA gets formed in a stateless manner ✨. After forming it from the prefix it got in the MAP option, the mobile node sends a local BU to the MAP with the A and M flags set. This local BU is a BU defined in [1], and it carries the mobile node's RCoA in the Home Address Option. No alternate-CoA option is needed in this message 💅. The LCoA is used as the source address of the BU, and this BU binds the RCoA (kinda like a Home Address) to the LCoA 🦋.
The MAP (acting as a HA) then performs DAD (when a new binding is being created) for the mobile node's RCoA on its link, and sends back a Binding Acknowledgement to the MN. That ack says whether the binding worked or includes the right fault code 🫶. No new error codes need to be supported by the mobile node for this, which is so chill. The mobile node MUST silently ignore binding acknowledgements that do not contain a routing header type 2, which includes the mobile node's RCoA. Ignore the rest, bestie 🙈
Once the registration with the MAP is successful, a bi-directional tunnel between the mobile node and the MAP is established 🌈. All packets sent by the mobile node get tunnelled to the MAP. The outer header has the mobile node's LCoA in the source address field and the MAP's address in the destination address field. The inner header has the mobile node's RCoA in the source address field and the peer's address in the destination address field. Similarly, every packet addressed to the mobile node's RCoA gets intercepted by the MAP and tunnelled to the mobile node's LCoA. Iconic tunnel energy 🚇✨
This spec lets a mobile node use more than one RCoA if it received more than one MAP option 👑. In that case, the mobile node MUST 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) 🙅♀️. Why? Because it would force packets to be encapsulated several times (twice in this example) on their way to the mobile node. That kind of multi-level hierarchy will reduce the protocol's efficiency and performance, so we do not do that, periodt 💀
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 mobile node's 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 (the one that specifies the binding between the Home Address and the RCoA) to its current correspondent nodes 💜.
The mobile node SHOULD wait for the binding acknowledgement from the MAP before registering with its HA ⭐. Also worth knowing: 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. Don't overshoot it, girlie 🎀
To speed up handovers between MAPs and cut down on packet loss, a mobile node SHOULD send a local BU to its previous MAP, specifying its new LCoA 🚀. That way, packets in transit that reach the previous MAP get forwarded to the new LCoA. Lowkey genius 🧠
The MAP will receive packets addressed to the mobile node's RCoA (from the HA or correspondent nodes). Those packets get tunnelled from the MAP to the mobile node's LCoA, and 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 unchanged, so it's giving stability 🦋
Also, a mobile node may send a BU containing its LCoA (instead of its RCoA) to correspondent nodes that are connected to its same link. In that case, packets get routed directly without going through the MAP 🧚♀️ Short and sweet, no detour needed.
6.1.1. Sending Packets to Correspondent Nodes ✨
The mobile node can communicate with a correspondent node through the HA, or in a route-optimised manner, as described in [1]. When it's communicating through the HA, the message formats in [1] can be re-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 that was used to create the binding cache entry in the correspondent node (RCoA) as a source address 🫶. According to [1], the mobile node MUST also include a Home Address option in outgoing packets. And the Home address option MUST contain the mobile node's home address. Main character energy, every single time 👑
6.2. MAP Operations 🌸
The MAP acts like a 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, so the mobile node sends a local BU to the MAP with the M and A flags set 💌. The aim of this BU is to tell the MAP that the mobile node has formed an RCoA (carried in the BU as a Home address). If it works out, the MAP MUST return a binding acknowledgement to the mobile node, indicating a successful registration. This is identical to the HA operation in [1], so it's not new drama. 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 being the tunnel entry point and the MAP being the tunnel exit point 🚪
The MAP acts as a HA for the RCoA. Packets addressed to the RCOA are intercepted by the MAP, using proxy Neighbour Advertisement, and then encapsulated and routed to the mobile node's LCoA. This operation is identical to that of the HA described in [1] 🦋
A MAP MAY be configured with the list of valid on-link prefixes that mobile nodes can use to derive LCoAs. This is super useful for network operators, because it stops mobile nodes from continuing to use the MAP after they've moved into a different administrative domain 🛑. If a mobile node sends 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 on the list? Not today, sweetie 💅
6.3. Home Agent Operations 🏠
The support of 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 [1]. The HA doesn't even notice, which is honestly so iconic 💖
6.4. Correspondent Node Operations 💜
HMIPv6 is completely transparent to correspondent nodes. They literally don't have to do anything different 🙈✨
6.5. Local Mobility Management Optimisation within a MAP Domain 🧚♀️
In [1], it's stated that for short-term communication (especially the kind that can easily be retried if it fails), the mobile node MAY choose to directly use one of its care-of addresses as the source of the packet, so it doesn't need a Home Address option in the packet 🎀. This cuts down on overhead for each packet because there are fewer extra options. It also gives an optimal route between the mobile node and the correspondent node. Efficient and cute 🌈
In HMIPv6, a mobile node can use its RCoA as the source address without a Home Address option. In other words, the RCoA can be a potential source address for upper layers 🫶. With this feature, the correspondent node sees the mobile node as a fixed node while it moves around within a MAP domain. Stationary vibes while moving, it's giving magic 🪄
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 provides local mobility management to the mobile nodes 🚲. It doesn't give global mobility, though. If a mobile host moves to a new MAP, communication breaks. Still, it's useful for a bunch of stuff (web browsing, for example) 🌐. How well the RCoA works as a source address for applications depends on the size of the MAP domain and how fast the mobile node is moving. Also, because support for BU processing in correspondent nodes isn't mandated in [1], this mechanism can be a way to get route optimisation without sending BUs to the correspondent nodes ✨
To turn this on, you present the RCoA as a temporary home address for the mobile node 🦋. This may require an implementation to augment its source address selection algorithm with knowledge of the RCoA, so it can use it for the right applications 🔧
6.6. Location Privacy 🕵️♀️
In HMIPv6, a mobile node hides its LCoA from its corresponding nodes and its home agent by putting its RCoA in the source field of the packets it sends 🙈. As a result, tracking a mobile node by its corresponding nodes or its home agent is hard, since they only know its RCoA and never its LCoA. Privacy served, no crumbs left 💅🌸
7. MAP Discovery 🗺️
This section is all about how a mobile node gets the MAP address and subnet prefix, and how ARs in a domain discover MAPs 🧭. Two different methods for MAP discovery are defined below.
Dynamic MAP Discovery is based on propagating the MAP option in Router Advertisements from the MAP to the mobile node, through certain (configured) router interfaces within the routers in an operator's network 📡. This requires manual configuration of the MAP, and the routers receiving the MAP option have to allow them to propagate the option on certain interfaces. To keep communication between routers secure, router advertisements sent between routers for Dynamic MAP discovery SHOULD be authenticated (e.g., using AH, ESP, or SEND) 🔐. If that authentication isn't possible (e.g., third party routers exist between the MAP and ARs), a network operator may prefer to manually configure all the ARs to send the MAP option, as described in this document 🛠️
Manual configuration of the MAP option information in ARs and other MAPs in the same domain is the default mechanism 💖. It should also be possible to configure ARs and MAPs to enable dynamic mechanisms for MAP Discovery 🌈
7.1. Dynamic MAP Discovery 🦋
There's more than one way to do MAP discovery 💫. Router advertisements are used for Dynamic MAP Discovery by introducing a new option. The access router is required to send the MAP option in its router advertisements. This option includes the distance vector from the mobile node (which may not imply the real distance in terms of the number of hops), the preference for this particular MAP, the MAP's global IP address and subnet prefix
7.1.1. Router Operation for Dynamic MAP Discovery ✨
okay so ARs inside a MAP domain can get their MAP info dynamically, and the trick is just listening for RAs that carry MAP options 👂🦋 each MAP in the network needs a default preference, the right interfaces to send its option out on, and the IP address to be sent. the starting Distance value MAY be set to a default of 1, but it MUST NOT be set to zero 🙅♀️ and routers in the MAP domain should be set up to re-send the MAP option on certain interfaces.
when a router gets an RA with the MAP option, it MUST copy the option and re-send it after bumping the Distance field up by one 💅 if that router is also a MAP, it MUST send its own option along with the received one, in the same advertisement 🫶 and if a router hears about the same MAP more than once (i.e., the same IP address in the MAP option) coming in from two different interfaces, it MUST choose the option with the smallest Distance field 🔥
this is lowkey genius because info about one or more MAPs can get passed along to a mobile node 🌈 and by doing discovery this way, MAP nodes can change their preferences on the fly based on local policies, node overload, or other load-sharing protocols 👑 main character energy for the whole network ✨
7.1.2. MAP Operation for Dynamic MAP Discovery
so a MAP gets configured to send its own option, or relay MAP options belonging to other MAPs, out onto certain interfaces 🧚 the network admin picks those interfaces by hand (i.e., manual configuration) and it depends on the network topology 🍓 a default preference value of 10 may be assigned to each MAP, and ngl a MAP can change its preference at any time because of stuff like node overload or load sharing 💜 a preference value of zero means the MAP SHOULD NOT be chosen by new mobile nodes 💀 this can happen with node overload or partial node failures.
the MAP option gets propagated toward the ARs in its domain, and each router along the path to an AR bumps the Distance field up by one 🦋 if a router that is also a MAP hears advertisements from other MAPs, it MUST add its own MAP option and pass both options along to the next router, or straight to the AR if it's directly connected to it 🎀
7.2. Mobile Node Operation
when an HMIPv6-aware mobile node gets a router advertisement, it should go hunting for the MAP option 🔍 one or more options may show up 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 (i.e., the mobile node can refresh existing bindings but can't create new ones) 🙈 still, 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 of zero means that MAP MUST NOT be selected by the MN 💔 a valid lifetime of zero signals a MAP failure. when a mobile node gets that option, it MUST choose another MAP and create new bindings, and any existing bindings with the failed MAP can be assumed lost 😭 if no other MAP is available, the mobile node MUST revert to using the Mobile IPv6 protocol, as specified in [1] 🫶
if a multihomed 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 get compared to options received later for the movement detection algorithm 🦋
if no MAP options show up in the router advertisement, the mobile node MUST use the Mobile IPv6 protocol, as specified in [1] 🍓
if the R flag is set, the mobile node MUST use its RCoA as the Home Address when doing the MAP registration 🎀 the RCoA then gets bound to the LCoA in the MAP's Binding Cache 🧚
and a mobile node MAY choose to register with more than one MAP at once, or use both the RCoA and its LCoA as care-of addresses at the same time with different correspondent nodes 💅🔥
8. Updating Previous MAPs ✨
when a mobile node moves into a new MAP domain, it may send a BU to the previous MAP asking it to forward packets addressed to the mobile node's new CoA 🦋 an administrator MAY restrict the MAP from forwarding packets to LCoAs outside the MAP's domain 🙅♀️ but 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 they're in the same administrative domain 🌸
for example, a MAP could be set up to forward packets to LCoAs on ARs that are geographically next to ARs on the edge of its domain 🗺️ this keeps inter-MAP handovers smooth, because the mobile node keeps receiving packets while it updates the new MAP, its HA, and potentially its correspondent nodes 💖
9. Notes on MAP Selection by the Mobile Node
HMIPv6 gives you a flexible way to handle local mobility management inside a visited network 🌈 like we covered, a MAP can live anywhere in the operator's network (including the AR) 🧚 several MAPs can sit in the same domain independently of each other, and overlapping MAP domains are allowed and even 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 described in this document, 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 advertised by the AR (that's the Eager part) 🔥 the way it figures out whether a MAP is "new" is described in section 9.1 🦋 the mobile node should not release existing bindings until it stops receiving the MAP option (or gets it with a lifetime of zero), or until its existing binding expires (that's the Lazy part) 🫶 this Eager-Lazy combo gives you a fallback if one of the MAP routers fails, since it cuts down the time a mobile node takes to tell its correspondent nodes and HA about its new care-of address 😭💜
9.1. MAP Selection in a Distributed-MAP Environment
the mobile node needs to weigh several factors to pick the best MAP (or MAPs) when several are available in the same domain 🍓
there are no benefits foreseen in selecting more than one MAP and forcing packets to travel from the higher MAP down through a hierarchy of MAPs 🙅♀️ that can add forwarding delays and wreck the robustness of IP routing between the highest MAP and the mobile node, so this specification prohibits it 🚫 having more than one MAP "above" the AR shouldn't mean the mobile node forces packets down the MAP hierarchy 💅 instead, placing more than one MAP "above" the AR can be used for redundancy and as an optimisation for different mobility scenarios 🌈 the MN uses each MAP independently of the others (e.g., each MAP is used for communication with a certain set of CNs) 🦋
for distance-based selection with several MAPs, a mobile node may choose to register with the furthest MAP to avoid frequent re-registrations 🏃♀️ this matters most for fast mobile nodes that do lots of handoffs, since picking a more distant MAP lowers the chance of having to change MAPs and tell every correspondent node and the HA 💖 this specification doesn't give an algorithm for distance-based MAP selection 🙈 but one could be added in future extensions that use speed-of-mobility info from lower layers 🧚
when several MAPs are discovered in one domain, the mobile node might need some sophisticated algorithms to pick the right MAP ✨ those would take the mobile node speed as an input (for distance-based selection) combined with the preference field in the MAP option 🔥 but this specification proposes that the mobile node uses the following algorithm as a default, for when no optimised algorithms are available 💅 it's simply based on picking the most distant MAP, 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 away 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 mobile nodes follow those steps, they'll default to selecting the most distant or furthest available MAP 🦋 they keep doing that until its preference value drops to zero, and then they start selecting another MAP 🌸
9.2. MAP Selection in a Flat Mobility Management Architecture
network operators may pick a flat architecture in some cases, where a Mobile IPv6 handover is considered a rare event 🌈 in those scenarios, operators may choose to include the MAP function in ARs only 🧚 including it in ARs can still help cut the time needed to update all correspondent nodes and the HA 💜 here, a mobile node may choose a MAP (in the AR) as an anchor point when it does a handoff 🫶 this kind of dynamic hierarchy (or anchoring) is only recommended for cases where inter-AR movement isn't frequent 🍓
10. Detection and Recovery from MAP Failures ✨
okay so this spec brings in a MAP, which is basically a local Home Agent chilling in the visited network 🏠. And just like a Home Agent, a MAP is a single point of failure 😭. If a MAP dies, its binding cache content is gone, and then the mobile and correspondent nodes lose their connection 💀. To avoid that, you can run more than one MAP on the same link and use some kind of context transfer protocol between them 🫶. Or future versions of the Virtual Router Redundancy Protocol [4] or HA redundancy protocols might let networks recover from MAP failures on their own ✨.
If those protocols aren't supported, the mobile node has to notice the MAP failure itself 👀. It can tell something's wrong when it receives a router advertisement containing a MAP option with a lifetime of zero. Then the mobile node 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 the lowkey clutch part: if there's a protocol moving binding cache entries between MAPs for redundancy, the new MAP may be able to give the mobile node the same RCoA (for example, if both MAPs advertise the same prefix in the MAP option) 🧚. That means the mobile node doesn't have to update correspondent nodes or the Home Agent. Iconic 💅.
ARs can be triggered to advertise a MAP option with a lifetime of zero (the "this MAP is gone" signal 💀) in a couple of different ways:
- By manual intervention.
- In a dynamic manner.
ARs can do dynamic detection of MAP failure by sending ICMP Echo request messages to the MAP regularly (for example, every ten seconds) 🏓. If no response comes back, the AR can get a bit more aggressive and send echo requests to the MAP for a short while (for example, 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 🙈.
This spec does not mandate one particular recovery mechanism 🤷♀️. But any similar mechanism between the MAP and an AR SHOULD be secure, so it can allow for message authentication, integrity protection, and protection against replay attacks 🔐.
11. IANA Considerations 🏷️
Section 4 adds a new flag (M) to the Binding Update that's specified in RFC 3775 🎀.
Section 5 adds a brand-new IPv6 Neighbour Discovery Option called the MAP Option. IANA has assigned the Option Type value 23 for the MAP Option within the option numbering space for IPv6 Neighbour Discovery messages 🎟️.
12. Security Considerations 🔐
This part is seriously important, bestie, so read it twice 🚨
This spec brings a totally new concept to Mobile IPv6: a Mobility Anchor Point that acts as a local Home Agent 🏰. It is crucial that the security relationship between the mobile node and the MAP is strong. It MUST involve mutual authentication, integrity protection, and protection against replay attacks 🔒. Confidentiality may be needed for payload traffic, but it is not required for binding updates to the MAP 🤓. If any of these protections are missing, malicious mobile nodes could impersonate other legit mobile nodes or impersonate a MAP 😱. Any of these attacks will undoubtedly cause undesirable impacts to the mobile node's communication with all correspondent nodes that know the mobile node's RCoA 💀.
Three different relationships (all about securing binding updates) need to be considered 👀:
- The mobile node - MAP
- The mobile node - Home Agent
- The mobile node - correspondent node
12.1. Mobile Node-MAP Security 🔐
To let a mobile node use the MAP's forwarding service, initial authorisation (specifically for the service, not for the RCoA) MAY be needed 🚪. Authorising a mobile node to use the MAP service can be done based on the identity of the mobile node exchanged during the SA negotiation process. The authorisation may be granted based on the mobile node's identity, or based on the identity of a Certificate Authority (CA) that the MAP trusts. For instance, if the mobile node presents a certificate signed by a trusted entity (for example, a CA in the same administrative domain, or another trusted roaming partner), that's enough for the MAP to authorise use of its service ✨. Note that this level of authorisation is independent of authorising the use of a particular RCoA. Similarly, the mobile node would trust the MAP if it presents a certificate signed by the same CA, or by another CA that the mobile node is configured to trust (for example, a roaming partner) 🤝.
HMIPv6 uses an additional registration between the mobile node and its current MAP 📝. As explained in this document, when a mobile node moves into a new domain (so, served by a new MAP), it gets an RCoA and an LCoA, and registers the binding between these two addresses with the new MAP. The MAP then checks whether the RCoA has been registered yet and, if it hasn't, creates a binding cache entry with the RCoA and LCoA. Whenever the mobile node gets a new LCoA, it needs to send a new BU that specifies the binding between the RCoA and its new LCoA. This BU needs to be authenticated, otherwise any host could send a BU for the mobile node's RCoA and hijack the mobile node's packets 😈. However, because the RCoA is temporary and isn't bound to a particular node, a mobile node does not have to prove that it owns its RCoA before the first binding update (unlike the requirement on home addresses in Mobile IPv6) when it establishes a Security Association with its MAP 🌸. A MAP only needs to make sure that a BU for a particular RCoA was issued by the same mobile node that established the Security Association for that RCoA 🔑.
The MAP doesn't need prior knowledge of the mobile node's identity or its Home Address 🙌. So the SA between the mobile node and the MAP can be established using any key establishment protocol, such as IKE. A return routability test is not necessary.
The MAP needs to set the SA for the RCoA (not the LCoA) 🎯. This can be done with IKE [2]. The mobile node uses its LCoA as the source address, but specifies that the RCoA should be used in the SA. This is achieved by using the RCoA as the identity in IKE Phase 2 negotiation. This step is identical to the use of the home address in IKE phase 2 🧩.
If a binding cache entry exists for a given RCoA, the MAP's IKE policy check MUST point to the SA used to install the entry 📌. If the mobile node's credentials stored in the existing SA don't match the ones in the current negotiation, the MAP MUST reject the new SA establishment request for that RCoA with an INVALID-ID-INFORMATION notification [2] 🚫. This stops two different mobile nodes from registering (on purpose or by accident) the same RCoA 🙅♀️. When the mobile node gets this notification, it SHOULD generate a new RCoA and restart the IKE negotiation 🔄. Alternatively, a MAP may decide that, if a binding cache entry already exists for a particular RCoA, no new security association should be established for that RCoA, no matter what the mobile node's credentials are. This stops the mobile node from re-establishing a security association for the same RCoA (in other words, changing session keys). That's not a major problem, though, because the SA will typically only protect signalling traffic when a MN moves, and not the actual data traffic sent to arbitrary nodes 💅.
Binding updates between the MAP and the mobile node MUST be protected with either AH or ESP in transport mode 🛡️. When ESP is used, a non-null authentication algorithm MUST be used 💜.
12.2. Mobile Node-Correspondent Node Security 🤝
Mobile IPv6 [1] defines a return routability procedure that lets mobile and correspondent nodes authenticate binding updates and acknowledgements 🦋. This specification doesn't change the return routability test defined in [1]. Still, it's important to know that mobile node implementers need to be careful when picking the source address of the HOTI and COTI messages, which are defined in [1] ⚠️. The source address used in HOTI messages MUST be the mobile node's home address 🏡. The packet carrying the HOTI message is encapsulated twice. The inner encapsulating header has the RCoA in the source address field and the home agent's address in the destination address field. The outer encapsulating header has the mobile node's LCoA in the source address field and the MAP's address in the destination field 🪆.
12.3. Mobile Node-Home Agent Security 🏠
The security relationship between the mobile node and its Home Agent, as discussed in [1], isn't affected by this specification 🫡.
13. Acknowledgments 🫶
The authors want to give a huge thank you to Conny Larsson (Ericsson) and Mattias Pettersson (Ericsson) for their super valuable input on this document 💖. They also want to thank the members of the French RNRT MobiSecV6 project (BULL, France Telecom and INRIA) for testing the first implementation and for their valuable feedback 🇫🇷. The INRIA HMIPv6 project is partly funded by the French Government 🌷.
The authors also want to thank the following working group members, listed alphabetically, for their comments on the document 📣: Samita Chakrabarti (Sun), Gregory Daley (Monash University), Francis Dupont (GET/Enst Bretagne), Gopal Dommety (Cisco), Eva Gustaffson (Ericsson), Dave Johnson (Rice University), Annika Jonsson (Ericsson), James Kempf (Docomo labs), Martti Kuparinen (Ericsson) Fergal Ladley, Gabriel Montenegro (Sun), Nick "Sharkey" Moore (Monash University) Erik Nordmark (Sun), Basavaraj Patil (Nokia), Brett Pentland (Monash University), and Alper Yegin (Samsung) 🌈.
14. References 📚
14.1. Normative References
- [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [2] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
- [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References
- [4] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
- [5] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
- [6] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
Appendix A: Fast Mobile IPv6 Handovers and HMIPv6 🦋
okay so Fast Handovers are required to keep the layer 3 (Mobile IP) handover delay as small as possible 💨. That also shrinks, and maybe even kills, the service disruption that normally happens when a mobile node moves between two ARs 💀. The disruption usually comes from the time the mobile node needs to update its HA with Binding Updates after it moves, and until that's done it can't resume or continue communications 😭. The mechanism for Fast Handovers with Mobile IPv6 is described in [5], and here's the quick version 🧚: it lets you anticipate the layer 3 handover, so data traffic can be redirected to the mobile node's new location before it even gets there ✨.
While the mobile node is still connected to its previous Access Router (PAR) and is about to move to a new Access Router (NAR), Fast Handovers in Mobile IPv6 need these steps, in order 👑:
- The mobile node obtains a new care-of address at the NAR while connected to the PAR.
- New CoA to be used at NAR case: the mobile node sends an F-BU (Fast BU) to its previous anchor point (i.e., PAR) to update its binding cache with the mobile node's new CoA while it's still attached to PAR.
- The previous anchor point (i.e., PAR) starts forwarding packets destined for the mobile node to the mobile node's new CoA at NAR (or the old CoA tunnelled to NAR, if the new CoA doesn't apply).
- Old CoA to be used at NAR case: the mobile node sends an F-BU (Fast BU) to its previous anchor point (i.e., PAR), after it has moved and attached to NAR, to update its binding cache with the mobile node's new CoA.
The mobile node or PAR can kick off the Fast Handover procedure using wireless link-layer information or link-layer triggers that say the mobile node will soon be handed off between two wireless access points attached to PAR and NAR 📡. If the "trigger" hits the mobile node, the mobile node starts the layer-3 handover by sending a Proxy Router Solicitation message to PAR 🙋♀️. If the "trigger" hits PAR instead, PAR transmits a Proxy Router Advertisement to the right mobile node, no solicitations needed 🌸. The basic Fast Handover message exchanges are shown in Figure A.1 💖.
+-----------+ 1a. HI +-----+
| | ---------------->| NAR |
| PAR | 1b. HAck | |
+-----------+ <--------------- +-----+
^ | ^
(2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU)
| | RtAdv | 4. Fast BA (F-BACK)
| v v
+------------+
| MN |
+------------+ - - - - - ->
Movement
Figure A.1: Fast Mobile IPv6 Handover ProtocolThe mobile node gets a new care-of address while connected to PAR through router advertisements carrying information from the NAR (a Proxy Router Advertisement, which may be sent in response to a Proxy Router Solicitation) 📨. PAR validates the mobile node's new CoA by sending a Handover Initiate (HI) message to the NAR 🔍. The new CoA in the HI message is formed by appending the mobile node's current interface identifier to the NAR's prefix. Based on the response in the Handover Acknowledge (HAck) message, PAR either builds a tunnel to the mobile node's new CoA (if the address was valid) or builds a tunnel to the NAR's address (if the address was already in use on the new subnet) 🚇. If the address was already in use on the new subnet, it's assumed there won't be time to try configuring the mobile node with a CoA on the new link again 😬. So the NAR generates a host route for the mobile node using its old CoA. Also, message 1a may come before message 2b or happen at the same time ⏱️.
In [5], the ARs act as local Home Agents, which hold binding caches for the mobile nodes and receive Binding Updates 🏠. That makes these ARs work like the MAP specified in this document 💅. It's also quite possible that the ARs aren't directly connected and instead talk through an aggregation router 🛜. So such an aggregation router is also an ideal spot for the MAP functionality 🎀. There are two ways to integrate HMIPv6 and the Fast Handover mechanisms. The first puts MAPs in place of the ARs, which is a natural step 🍓. The second puts the MAP in an aggregation router "above" the ARs. In this case, [5] specifies forwarding packets between PAR and NAR, which could be inefficient in terms of delay and bandwidth, because packets traverse the MAP-PAR link twice and arrive out of order at the mobile node 😭. Using the MAP in the aggregation router would improve the efficiency of Fast Handovers, since the MAP can redirect traffic and save delay and bandwidth between the aggregation router and the PAR 🙌.
+---------+
| MAP |
+-------------->| |
| +---------+
| | ^
| 1a. HI | |
| | |
| | | 1b. HAck
| v |
+---------+ | +---------+
| | | | NAR |
| PAR | | | |
+---------+ | +---------+
^ | |
(2a. RtSolPr) | | 2b |
| | Pr | 3. Fast BU (F-BU) from mobile node to
| | MAP
| | RtAdv | 4. Fast BA (F-BACK) from MAP to
| | | mobile node
| v v
+------------+
| MN | Movement
+------------+ - - - - - ->
Figure A.2: Fast Mobile IPv6 Handover Protocol using HMIPv6In Figure A.2, the HI/HAck messages now go between the MAP and NAR, to check whether the newly requested care-of address is valid and to set up a temporary tunnel if it isn't 🧐. So the same Fast Handover functionality is kept, but the anchor point moves from PAR to the MAP 🦋.
As in the earlier Fast Handover procedure, in the network-determined case the layer-2 "triggers" at PAR make PAR send a Proxy Router Advertisement with the MAP option to the mobile node 📶. In the mobile-determined case, that's preceded by a Proxy Router Solicitation from the mobile node 🙋♀️. The same layer-2 trigger at PAR in the network-determined case could independently start Context Transfer (e.g., QoS) between PAR and NAR 🎁. In the mobile-determined case, the trigger at PAR could be replaced by receiving a Proxy Router Solicitation or F-BU 🔁. Context Transfer is being worked on in the IETF Seamoby WG 🧑💻.
Combining Fast Handover and HMIPv6 lets you anticipate the layer 3 handoff, so data traffic can be efficiently redirected to the mobile node's new location before it moves there 💜. However, it's not easy to pick the right moment to start forwarding traffic from the MAP to the mobile node's new location, and that timing affects how smooth the handoff is 😩. The same issues come up in [5] for when to start forwarding between PAR and NAR. Packet loss happens if forwarding starts too late or too early relative to when the mobile node detaches from PAR and attaches to NAR 📉. That loss is likely if the MAP updates its binding cache when it gets the anticipated F-BU, because it isn't known exactly when the mobile node will perform or complete the layer-2 handover to NAR, relative to when the mobile node sends the F-BU 🤷♀️. Some measure is also needed for when the mobile node's layer-2 handover unexpectedly fails (after Fast Handover has started), or when the mobile node bounces quickly back and forth between ARs (ping-pong) 🏓. Simultaneous bindings [6] solve these problems 🎉. In [6], a new Simultaneous Bindings Flag is added to the Fast Binding Update (F-BU) message, and a new Simultaneous Bindings suboption is defined for the Fast Binding Acknowledgement (F-BAck) message 💌. With this enhanced mechanism, upon layer-3 handover, traffic for the mobile node is sent from the MAP to both PAR and NAR for a certain period. That isolates the mobile node from layer-2 effects such as handover timing, ping-pong, or handover failure, and gives it uninterrupted layer-3 connectivity 👑✨.
Authors' Addresses
Hesham Soliman
Flarion Technologies
EMail: h.soliman@flarion.com
Claude Castelluccia
INRIA Rhone-Alpes
655 avenue de l'Europe
38330 Montbonnot Saint-Martin
France
EMail: claude.castelluccia@inria.fr
Phone: +33 4 76 61 52 15
Karim El Malki
Ericsson AB
LM Ericssons Vag. 8
126 25 Stockholm
Sweden
EMail: karim@elmalki.homeip.net
Ludovic Bellier
INRIA Rhone-Alpes
655 avenue de l'Europe
38330 Montbonnot Saint-Martin
France
EMail: ludovic.bellier@inria.frFull 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 ✨
okay so the IETF is being super clear here, bestie 🫶 It takes no position on whether any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology in this document are valid or in scope. It also doesn't say whether a license under those rights might or might not be available, and it doesn't claim it has made any independent effort to find those rights. 💅 If you want the procedures for rights in RFC documents, check BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use those proprietary rights can all be found in the IETF's online 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. Send that info to ietf-ipr@ietf.org. 🎀
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society. 🌸💜
📦 where this page comes from
- ietf: rfc4140 2005-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms