RFC 4881
Low-Latency Handoffs in Mobile IPv4
RFC 4881: Low-Latency Handoffs in Mobile IPv4 🦋
Okay bestie, here's the header facts first. This is Request for Comments 4881, from the Network Working Group. The editor is K. El Malki (Ed.) from Athonet. It's an Experimental doc, dated June 2007. The header has no Obsoletes or Updates line, so it doesn't replace or change any other RFC 🫶
Status of This Memo 📜
This memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind. The community is invited to discuss it and suggest improvements, and anyone can distribute it with no limits. 💖
Copyright Notice ©️
Copyright (C) The IETF Trust (2007). 🌸
Abstract ✨
Mobile IPv4 lets a Mobile Node move between subnets served by different Foreign Agents, all at the IPv4 layer. Sometimes the handoff takes so long that it's too slow for delay-sensitive or real-time stuff like calls and games 😭 This doc lays out two methods for low-latency Mobile IPv4 handoffs, plus a combo of both. The goal is better real-time support on a Mobile IPv4 network by shrinking the stretch of time where the Mobile Node can't send or receive IPv4 packets, which happens because the Mobile IPv4 Registration process is slow. 🚀
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. The Techniques .............................................5
1.3. L2 Triggers ................................................7
1.4. Requirements Language ......................................9
2. Requirements ....................................................9
3. The PRE-REGISTRATION Handoff Method ............................10
3.1. Operation .................................................11
3.2. Network-Initiated Handoff .................................13
3.3. Mobile-Initiated Handoff ..................................15
3.4. Obtaining and Proxying nFA Advertisements .................17
3.4.1. Inter-FA Solicitation ..............................17
3.4.2. Tunneled nFA Advertisements ........................18
3.5. Caching Router Advertisements .............................19
3.6. Movement Detection, MN, and FA Considerations .............19
3.7. L2 Address Considerations .................................21
3.8. Applicability of PRE-REGISTRATION Handoff .................21
4. The POST-REGISTRATION Handoff Method ...........................23
4.1. Two-Party Handoff .........................................24
4.2. Three-Party Handoff .......................................28
4.3. Renewal or Termination of Tunneling Service ...............34
4.4. When Will the MN Perform a Mobile IPv4 Registration? ......34
4.5. Handoff Request (HRqst) Message Format ....................36
4.6. Handoff Reply (HRply) Message Format ......................38
4.7. Handoff to Third (HTT) Message Format .....................40
4.8. Applicability of POST-REGISTRATION Handoff Method .........40
5. Combined Handoff Method ........................................41
6. Layer 2 and Layer 3 Handoff Timing Considerations ..............42
7. Reverse Tunneling Support ......................................42
8. Handoff Signaling Failure Recovery .............................43
8.1. PRE-REGISTRATION Signaling Failure Recovery ...............43
8.1.1. Failure of PrRtSol and PrRtAdv .....................43
8.1.2. Failure of Inter-FA Solicitation and
Advertisement ......................................44
8.2. POST-REGISTRATION Signaling Failure Recovery ..............44
8.2.1. HRqst Message Dropped ..............................44
8.2.2. HRply Message Dropped ..............................45
9. Generalized Link Layer and IPv4 Address (LLA) Extension ........46
9.1. 3GPP2 IMSI Link Layer Address and Connection ID
Extension .................................................47
9.2. 3GPP IMSI Link Layer Address Extension ....................48
9.3. Ethernet Link Layer Address Extension .....................49
9.4. IEEE 64-Bit Global Identifier (EUI-64) Address Extension ..50
9.5. Solicited IPv4 Address Extension ..........................51
9.6. Access Point Identifier Extension .........................52
9.7. FA IPv4 Address Extension .................................53
10. IANA Considerations ...........................................53
10.1. New Extension Values .....................................53
10.2. Generalized Link Layer and IP Address Identifier (LLA) ...54
10.3. New Message Type and Code ................................54
11. Security Considerations .......................................55
12. Acknowledgements ..............................................57
13. References ....................................................57
13.1. Normative References .....................................57
13.2. Informative References ...................................58
Appendix A - Gateway Foreign Agents................................59
Appendix B - Low Latency Handoffs for Multiple-Interface MNs.......60
Appendix C - PRE_REGISTRATION Message Summary......................611. Introduction 🌈
Okay so, Mobile IPv4 [1] is how a Mobile Node (MN) does an IPv4-layer handoff when it moves between subnets run by different Foreign Agents (FAs). Sometimes that handoff is slow enough to be above the threshold that delay-sensitive or real-time services can handle, and that's the problem this doc is here to fix 💅
The aim is to present two techniques for low-latency Mobile IPv4 handoff while an MN moves between FAs, plus a further combination of them. These techniques help real-time services run better over Mobile IPv4 by cutting down the time an MN can't send or receive IPv4 packets because the Mobile IPv4 Registration process is taking forever ⏳
One or more of these techniques might be needed to get fast Mobile IPv4 handoffs across different wireless technologies, like WLAN, Cellular, WiMAX, Flash-OFDM, and so on. Each wireless technology has its own layer 2 handoff procedures, so the best low-latency technique for each scenario should be used to optimize handoff performance 🎀
More deployment and experimentation is needed to figure out which technique fits which wireless technology, in terms of implementation and performance. So the authors are calling for more performance measurements and work on low-latency-over-foo specifications, done together with the right wireless technology fora, to describe how this applies to different wireless layer 2s 🧚
Here's the rest of the section. We'll go over the terminology, briefly describe the handoff techniques, and outline how link-layer information gets used. Section 2 gives a short rundown of requirements. Section 3 digs into the PRE-REGISTRATION handoff technique, and Section 4 digs into POST-REGISTRATION. Section 5 covers the combined method that uses both together. Section 6 talks about layer 2 and layer 3 handoff timing. Section 7 covers reverse tunneling support, Section 8 describes how to recover when messages fail, and Section 9 covers the protocol extensions these handoff techniques need. Sections 10 and 11 are the IANA and security considerations. Last but not least, the three appendices cover extra stuff: Appendix A gives a short intro to Regional Registrations [11], which can be used alongside low-latency handoffs. Appendix B covers low-latency handoff when an MN has multiple wireless L2 interfaces, and in that case the techniques in this document may not be necessary. Appendix C summarises the messages used in PRE-REGISTRATION 📋
1.1. Terminology 🔤
This section introduces a few terms that get used all over the doc:
- oFA: old Foreign Agent (FA), the FA handling the care-of address (CoA) of a Mobile Node (MN) before a layer 3 (L3) handoff.
- nFA: new Foreign Agent, the FA expected to handle an MN's care-of address once the L3 handoff is done.
- aFA: anchor Foreign Agent, the FA currently handling the network end of the tunnel in POST-REGISTRATION.
- L2 handoff: when an MN's layer 2 (L2) connection moves from one wireless access point to another.
- L3 handoff: when an MN moves between FAs and its care-of address changes at layer 3 (L3).
- L2 trigger: info from L2 that tells L3 about particular events before and after an L2 handoff. The L2 trigger descriptions in this doc aren't tied to any one L2. They're generalisations of L2 info you'd find across lots of different L2 protocols ✨
- L2-MT: an L2 trigger that happens at the MN, telling you it's moving to a certain nFA (Mobile Trigger).
- L2-ST or source trigger: an L2 trigger that happens at the oFA, telling the oFA that an L2 handoff is about to happen.
- L2-TT or target trigger: an L2 trigger that happens at the nFA, telling the nFA that an MN is about to be handed off to it.
- L2-LU: an L2 trigger that happens at the MN or the nFA, saying the L2 link between the MN and nFA is up.
- L2-LD: an L2 trigger that happens at the oFA, saying the L2 link between the MN and oFA has been lost.
- low-latency handoff: an L3 handoff where the time the MN can't receive packets is kept as short as possible ⚡
- low-loss handoff: an L3 handoff where the number of packets dropped or delayed is kept as low as possible. This is often called smooth handoff.
- seamless handoff: an L3 handoff that's both low latency and low loss 💖
- bidirectional edge tunnel (BET): a bidirectional tunnel set up between two FAs to temporarily route an MN's traffic to and from it on a new subnet, without the MN having to change its CoA 🦋
- ping-pong: rapid back-and-forth movement between two wireless access points, often caused by a failed L2 handoff. Ping-pong can happen when radio conditions for both the old and new access points are about equal and not good enough to set up a solid, low-error L2 connection 🏓
- network-initiated handoff: an L3 handoff where the oFA or nFA starts the handoff.
- mobile-initiated handoff: an L3 handoff where the MN starts the handoff.
- MN or FA identifier: an IPv4 address of an MN or FA, or an L2 identifier that can be resolved to the IPv4 address of an MN or FA. If it's an L2 identifier, it might be specific to the L2 technology 🌸
1.2. The Techniques ✨
Okay bestie, so Mobile IPv4 was originally designed to not assume anything about the link layers underneath it, so it could work pretty much anywhere 🌈. That's great for keeping L2 and L3 cleanly separated, but it's kinda rough for handoff latency 😭. Because of that strict L2/L3 split, there are two built-in sources of delay:
- The MN can only talk to a directly connected FA. So an MN can only start the registration process after the L2 handoff to nFA (new FA) is finished. 🙈
- Registration takes a little bit of time because the Registration Requests have to travel through the network. During that window, the MN can't send or receive IPv4 packets. 💀
This document has techniques to shrink those two delay chunks of Mobile IPv4 🦋. They fall into two big categories, depending on which problem they're going after:
- Let the MN talk to the nFA while it's still connected to the oFA. 💜
- Get data delivered to the MN at the nFA even before the formal registration is done. ✨
The first category lets the MN "pre-build" its registration state on the nFA before the underlying L2 handoff happens 🧚. The second category keeps service running smoothly while the network handles the handoff, and the MN doesn't have to be involved at all 👑.
This document shows off three methods for low-latency L3 handoff: one for each category, and one that combines both 🎀:
- PRE-REGISTRATION handoff method,
- POST-REGISTRATION handoff method, and
- combined handoff method.
The PRE-REGISTRATION method is for when the MN is involved in an anticipated IPv4-layer handoff. The network helps the MN do its L3 handoff before the L2 handoff is complete 🌸. The L3 handoff can be started by the network or by the mobile, and L2 triggers get used in both the MN and the FA to kick off specific L3 handoff events 🔥. Paired with L2 mobility, this method helps get seamless handoffs between FAs 💅. The usual Mobile IPv4 advertisement-then-registration idea is still there, and the PRE-REGISTRATION method leans on Mobile IPv4 security too 🔐. Nothing new is invented, except for an extension to the Agent Solicitation message in the mobile-initiated case 🍓.
The POST-REGISTRATION method adds extensions to Mobile IPv4 so the oFA (old FA) and nFA (new FA) can use L2 triggers to build a bidirectional tunnel between them 🫶. That way the MN can keep using its oFA while it's already on the nFA's subnet. It's super quick to get service going at the new point of attachment, which is great news for real-time apps ⭐. The MN has to eventually do a formal Mobile IPv4 Registration once L2 communication with the new FA is set up, but the MN or FA can push that back if they need to 💖. Until the MN registers, the FAs will set up and move those bidirectional tunnels as needed so the MN stays connected 🦋.
The combined method runs a PRE-REGISTRATION and a POST-REGISTRATION handoff at the same time 👑. If the PRE-REGISTRATION handoff can finish before the L2 handoff does, the combined method just turns into a PRE-REGISTRATION handoff 🌈. But if the PRE-REGISTRATION handoff hasn't finished within an access-technology-dependent time period, the oFA starts forwarding the MN's traffic to the nFA, the same way the POST-REGISTRATION method describes 🧚. It's a handy backup, since finishing the PRE-REGISTRATION handoff can't always be guaranteed before the L2 handoff completes 🙌.
Also, the methods here can be used on MNs with a single interface (like a Wireless LAN interface) or with multiple interfaces (like one WLAN and one cellular interface) ✨. Heads up though: multiply-interfaced MNs need special thought, because the handoff methods in this document might not be needed in every case (see Appendix B) 👀.
1.3. L2 Triggers
An L2 trigger is basically a signal that an L2 event happened 🔔. In this document, the L2 events are all about the L2 handoff process 💅. One possible event is an early heads-up that the mobile node's L2 point of attachment to the access network is about to change 🌸. Another is when the mobile node's L2 point of attachment has finished moving over to a new L2 access point 🎀. That info can come straight from L2, solicited or unsolicited, or it can be worked out from L2 messages 📩. The protocols here do use specific L2 info, but Mobile IPv4 should stay independent of any particular L2 🧚. L2 triggers are an abstraction for a technology-specific trigger, so any L2 trigger handed to the Mobile IPv4 stack is treated as generic and technology independent 💜. This document doesn't cover the exact format of these triggers, but it does spell out the info that low-latency handoffs need inside them ✨.
To abstract away from L2 properly, it's assumed that one of the three entities (the MN, oFA, or nFA) knows an L2 handoff is needed, and the nFA or MN can optionally also be told when an L2 handoff has finished 🫶. Which entity gets the trigger often depends on the specific L2 🌈. Some L2s give advance triggers on the network side, while others give them on the MN 🦋. The timing of the trigger relative to the actual L2 handoff also varies by technology 🙈. For example, some wireless links send a trigger way ahead of the handoff, while other L2s give little or no heads-up beforehand 💀.
An L2 trigger can be grouped by whether the MN, oFA, or nFA receives it 💖. Table 1 shows that grouping, along with the info each trigger carries 🍓. The methods in this document work with the different L2 trigger types shown in Table 1 🔥. Once an L2 trigger is received, the handoff processes described later get started 🚀. The three triggers, L2-ST, L2-TT, and L2-MT, don't depend on each other and aren't expected to show up together, because each one kicks off a different kind of handoff behaviour 👑.
+-------------+----------------------+------------------------------+
| L2 Trigger | Mobile | Source |
| | Trigger | Trigger |
| | (L2-MT) | (L2-ST) |
+-------------+----------------------+------------------------------+
| Recipient | MN | oFA |
+-------------+----------------------+--------------+---------------+
| Method | PRE | PRE | POST |
| | mobile-initiated | network- | source |
| | | initiated | trigger |
+-------------+----------------------+--------------+---------------+
| When? | sufficiently before | sufficiently | sufficiently |
| | the L2 handoff | before L2 | before L2 |
| | so that MN can | handoff for | handoff for |
| | solicit PrRtAdv | FA to send | oFA & nFA to |
| | from oFA | PrRtAdv | exchange |
| | | to MN | HRqst/HRply |
+-------------+----------------------+--------------+---------------+
| Parameters | nFA identifier | nFA identifier, MN identifier|
+-------------+----------------------+------------------------------+
Table 1 - L2 Trigger
(continued on next page) +------------+----------------------+---------------+---------------+
| L2 Trigger | Target | Link-Up | Link-Down |
| | Trigger | (L2-LU) | (L2-LD) |
| | (L2-TT) | | |
|------------+----------------------+---------------+---------------+
| Recipient | nFA | MN or nFA | oFA |
|------------+-----------+----------+---------------+---------------+
| Method | PRE | POST | PRE & POST | POST |
| | network- | target | | |
| | initiated | trigger | | |
|------------+----------------------+---------------+---------------+
| When? | | when radio | when radio |
| | same as | link between | link between |
| | source trigger | MN & nFA is | MN and oFA |
| | | established | is lost |
|------------+----------------------+---------------+---------------+
| Parameters | oFA identifier | @MN: nFA IPv4 | MN identifier |
| | MN identifier | or L2 addr. | |
| | | @nFA: MN IPv4 | |
| | | or L2 addr. | |
+------------+----------------------+---------------+---------------+
Table 1 - L2 Trigger1.4. Requirements Language
In this document, the key words "MAY", "MUST", "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT" are to be interpreted as described in [2] 📖💖.
2. Requirements 🎀
The following requirements apply to low-latency handoff techniques, and the methods in this document support them ✨:
- provide low-latency and low-loss handoff for real-time services,
- have no dependence on a wireless L2 technology,
- support inter- and intra-access technology handoffs, and
- limit wireless bandwidth usage. 🌸
3. The PRE-REGISTRATION Handoff Method ✨
okay so bestie, PRE-REGISTRATION is built on the normal Mobile IPv4 handoff procedure from [1] 🦋 The basic flow goes like this:
- an advertisement for an FA gets received by an MN 📡
- that advertisement lets the MN do movement detection 👀
- and then the MN registers with the FA 💌
The basic messages from [1] get extended to carry the extra info needed for fast handoffs. ⚡ PRE-REGISTRATION lets both the MN and the FA kick off the layer 3 handoff, and it can use L2 triggers on either side, depending on whether the network starts the handoff or the mobile does. It's giving flexibility, periodt 💅
PRE-REGISTRATION supports the normal Mobile IPv4 model from [1] and, optionally, the Regional Registration model from [11] 🌸 Pairing [11] with low-latency handoff can be really worth it, especially when the Home Agent (HA) is far away (delay-wise) from the nFA 🌍 The handoff can finish faster by using a closer local HA, which [11] calls a Gateway Foreign Agent (GFA) 🏃♀️💨 Still, PRE-REGISTRATION doesn't require implementing [11], so it's not mandatory. It also handles movement where a brand new Authentication, Authorization, and Accounting (AAA) transaction has to happen to authenticate the MN with a new domain 🔐
3.1. Operation
Here's the big picture of the PRE-REGISTRATION handoff, summarized in Figure 1 🧚
+---------+
| HA (GFA)|<---------+
+---------+ | 4. (Reg)RegReq
| 5. (Reg)RegReply
v
+-----+ 1a. PrRtSol +-----+
| | -----------------> | nFA |
| oFA | 1b. PrRtAdv | |
+-----+ <----------------- +-----+
^ | ^
(2a. PrRtSol)| | 2b |
| | PrRtAdv | 3. (Reg)RegReq
| | |
| v --------------------+
+-----+ /
| MN |
+-----+ - - - - - ->
Movement
Figure 1 - PRE-REGISTRATION Handoff ProtocolNow for the step-by-step tea ☕
- Message 1a is a Proxy Router (Agent) Solicitation (PrRtSol) going from oFA to nFA 💫 It's a Mobile IP agent solicitation that carries an identifier for the nFA (an IP address or an L2 address) inside a Generalized Link Layer and IP Address Extension (see Section 9). When the nFA gets message 1a with its own correct identifier in the LLA extension, the nFA MUST return the Proxy Router Advertisement (Agent Advertisement) in message 1b 💖 Message 1b is basically the nFA's Agent Advertisement, with the nFA layer 2 address inside a Generalized Link Layer and IP Address (LLA) Extension (see Section 9.3). Messages 1a and 1b SHOULD happen ahead of the PRE-REGISTRATION handoff so they don't slow it down ⏰ So the oFA SHOULD solicit and cache advertisements from neighboring nFAs using messages 1a and 1b, which unhooks this exchange from the rest of the PRE-REGISTRATION handoff 🧠✨ And when an L2 trigger at the nFA starts the L3 handoff (that's the target L2 trigger, or L2-TT), message 1b is message 2b. It gets sent unsolicited straight to the MN (tunneled by the nFA to the MN through the oFA) instead of being relayed by the oFA 🚇
- Message 2a is a Proxy Router Solicitation (PrRtSol) from the MN to the oFA 🙋♀️ It's not a normal Router (Agent) Solicitation, because it's asking for an advertisement from a router that is different from the one receiving it. It's a Mobile IP Agent Solicitation carrying an identifier for the nFA (an IP address or L2 address) inside a Generalized Link Layer and IP Address Extension (see Section 9). Here's the tea: if message 2a is there, the handoff is mobile-initiated; if it's missing, the handoff is network-initiated 👀 In a mobile-initiated handoff, message 2a shows up when the MN has an L2 trigger that wants a Proxy Router Advertisement (PrRtAdv). When the oFA receives message 2a, it MUST return the Proxy Router Advertisement (Agent Advertisement) in message 2b 🎀 That's the nFA's Agent Advertisement again, with the nFA layer 2 address inside a Generalized Link Layer and IP Address (LLA) Extension (see Section 9.3). In a network-initiated source-triggered handoff, the L2 trigger happens at the oFA, and the oFA MUST relay the Agent Advertisement in message 2b without the MN having to ask for it 🪄 It's also possible for the nFA to advertise straight to the MN in the network-initiated target-triggered case (see Section 3.2) 🌈
- The MN does movement detection as soon as it gets a solicited or unsolicited Agent Advertisement, and if it's needed, it sends a Registration Request (RegReq) message [1] as message 3 to the nFA 💌 When a local Gateway Foreign Agent (GFA) is around, this message can optionally be a Regional Registration Request (RegRegReq) [11] 🏡 Message 3 goes through the oFA, because the MN isn't directly connected to the nFA yet before the L2 handoff 🙃
- Messages 4 and 5 finish up the standard Mobile IPv4 Registration [1], or the optional Regional Registration [11], that got kicked off with message 3 🎉 The Registration Request MUST contain the MN's layer 2 address inside a Generalized Link Layer and IP Address Extension (see Sections 3.7 and 9) 🆔 That identifier can be a plain Ethernet address or something specific to the wireless tech. If the MN isn't connected to the nFA yet, the Registration Reply in message 5 MUST be buffered by the nFA and unicast to the MN on-link as soon as the MN connects to the nFA 📬 (That's the L2-LU trigger at the nFA, which the MN can set off by sending an Agent Solicitation, or by using special layer 2 techniques that are outside the scope of this document 🙈) This matters because the MN may have to detach from the oFA because of the wireless L2 connection before it gets the reply 😭 The MN's L2 address is obtained using the extensions in Section 9, as described in Section 3.7. Figures 2 and 3 illustrate this procedure 🦋
- If the registration succeeds, packets meant for the MN get tunneled from the HA (or GFA) to the nFA and then on to the MN 🚀
PRE-REGISTRATION doesn't depend on [11] 💅 But if the HA is far from the nFA (delay-wise), using a local GFA may cut down how long the handoff takes to finish ⏱️
Timing is everything, bestie 🕰️ The moment the L2 trigger hits the oFA or MN (which kicks off the PRE-REGISTRATION handoff), compared to when the actual L2 handoff happens, really matters for how well the low-latency handoff performs 💜 In the ideal case, the L2 trigger arrives and the four messaging steps of PRE-REGISTRATION described above all finish (meaning up until the Registration Request gets processed by the HA or GFA) before the MN moves 🏃♀️ Ideally, the Registration Reply and the first packet redirected by the HA (or GFA) to the nFA reach the MN right when the MN's L2 link to the nFA is fully set up, so the MN doesn't feel any disruption from the L3 handoff ✨ This can't always be guaranteed unless particular implementation techniques are used 😬 To ease some of this timing trouble, the MN MAY set the S bit [1] in low-latency Registration Requests it sends 🍓 That lets the MN receive packets at both the oFA and the nFA during the short layer 2 handoff time 🫶 Other techniques may be needed, like L2 techniques or buffering, but those are outside the scope of this document 🌸 Also, further handoff smoothing considerations may be needed to stop packets that are still in flight between the HA (or GFA) and the oFA from getting lost while the MN does a PRE-REGISTRATION handoff 💀 Those are outside the scope of this document too 🙌
Figures 2, 3, and 4 have the message timing diagrams for the network-initiated and mobile-initiated PRE-REGISTRATION handoff procedures 📊🌈
3.2. Network-Initiated Handoff 🎀
Okay so, as Table 1 shows, a PRE-REGISTRATION handoff can be kicked off at oFA by a source trigger or at nFA by a target trigger 🦋 Figures 2 and 3 are the message timing diagrams for the source and target trigger versions, and they're giving clarity ✨
A source-triggered, network-initiated handoff starts when oFA gets an L2 trigger saying a certain MN is about to move from oFA to nFA 🏃♀️ That trigger carries the MN's identifier (the IPv4 address itself, or an identifier that can be resolved to the IPv4 address) plus the nFA's identifier. An identifier can be an IPv4 address or something specific to the wireless technology, like a Base Station or Access Point Identifier 📡 A target-triggered, network-initiated handoff starts when nFA gets an L2 trigger saying a certain MN is about to move from oFA. That trigger is also in Table 1, and it carries the MN's identifier and the oFA's identifier 💜
MN oFA nFA HA/GFA
| |<~~~~~~ L2-Source | |
| | Trigger | |
|<--------------------| | |
| PrRtAdv | | |
| | | |
|---------------------------------------->| |
| RegReq or | | |
| RegRegReq (routed via oFA) |------------------->|
| | RegReq or RegRegReq|
| | |
| Buffered ~~~~~>|<-------------------|
|---------------------------------------->| (Reg)RegReply |
| Agent Solicitation | |
| (sent when MN connects to nFA) | |
| | |
|<----------------------------------------| |
| (Reg)RegReply | |
| (sent when nFA receives Solicitation or L2-LU) |
Figure 2 - PRE-REGISTRATION Handoff Message Timing Diagram
(Network-Initiated, Source Trigger)Okay, the source-trigger version 🔥 When oFA receives the trigger (L2-ST), it MUST send message 2b, the Proxy Router Advertisement (PrRtAdv), to the MN. The PrRtAdv is nFA's Agent Advertisement [1] with one of the link-layer extensions from Section 9. How that extension's contents get used is covered in Section 3.7. Messages 1a and 1b SHOULD be exchanged by oFA and nFA before the L2 trigger shows up (see Section 3.4.1). Message 2a is not used 🙈
MN oFA nFA HA/GFA
| | L2-Target~~~~~~~~>| |
| | Trigger | |
| |...................| |
|<--------------------------------------- | |
| (PrRtAdv) |...................| |
| | Tunneled Agent Advertisement |
| | | |
|---------------------------------------->| |
| RegReq. or | | |
| RegRegReq (routed via oFA) |------------------->|
| | RegReq or RegRegReq|
| | |
| Buffered ~~~~~>|<-------------------|
|---------------------------------------->| (Reg)RegReply |
| Agent Solicitation | |
| (sent when MN connects to nFA) | |
| | |
|<----------------------------------------| |
| (Reg)RegReply | |
| (sent when nFA receives Solicitation or L2-LU) |
Figure 3 - PRE-REGISTRATION Handoff Message Timing Diagram
(Network-Initiated, Target Trigger)Now the target-triggered version 🧚 When nFA receives the trigger (L2-TT), it MUST tunnel an Agent Advertisement to the MN through oFA to kick off the L3 handoff. The inner advertisement is unicast by nFA to the MN, so nFA treats the target trigger like a Router (Agent) Solicitation 🌸 That advertisement gets tunneled to oFA, which acts like a normal router: it decapsulates the advertisement and forwards it to the MN. This message MUST be authenticated to prevent attacks (see Section 3.4.2). Main character energy, but make it secure 🔐
3.3. Mobile-Initiated Handoff 💅
So here's the mobile-initiated version 📱 As shown in Table 1, this handoff happens when an L2 trigger hits the MN and tells it that it's about to move to nFA. That trigger carries info like the nFA's identifier (the nFA's IPv4 address, or an identifier that can be resolved to it). For example, a Wireless LAN MN might scan to grab the Base Station Identifier (BSSID) of an access point that's a possible handoff target, meaning its signal is getting stronger 📶 The message timing diagram is in Figure 4.
MN oFA nFA HA/GFA
|<~~~~~ L2-Trigger | | |
| | | |
|-------------------->| | |
| PrRtSol | | |
| | | |
|<--------------------| | |
| PrRtAdv | | |
| | | |
|---------------------------------------->| |
| RegReq or | | |
| RegRegReq (routed via oFA) |------------------->|
| | RegReq or RegRegReq|
| | |
| Buffered ~~~~~>|<-------------------|
|---------------------------------------->| (Reg)RegReply |
| Agent Solicitation | |
| (sent when MN connects to nFA) | |
| | |
|<----------------------------------------| |
| (Reg)RegReply | |
| (sent when nFA receives Solicitation or L2-LU) |
Figure 4 - PRE-REGISTRATION Handoff Message Timing Diagram
(Mobile-Initiated)As a result of the L2 trigger (L2-MT), the MN MUST send message 1a, the Proxy Router Solicitation (PrRtSol) 📨 This message is a unicast Agent Solicitation to oFA asking for a Proxy Router Advertisement (PrRtAdv). This solicitation MUST have a TTL=1 as in [1]. The PrRtSol unicast to oFA is an Agent Solicitation with a special extension. The solicitation MUST have an extension that contains an FA identifier (i.e., an IPv4 address or an L2 address carried in an LLA extension, see Section 9), because the MN is asking oFA for the advertisement of one specific FA, and that FA is the MN's nFA 🎯 The identifier is nFA's IPv4 address or another identifier that oFA can resolve to nFA's IPv4 address. If the identifier isn't an IPv4 address, it MAY be specific to the underlying wireless technology, like an access point or Base Station Identifier (e.g., WLAN BSSID) that oFA can map to the nFA IPv4 address as described in Section 3.4.1. The extension carrying the identifier is a sub-type of the Generalized Link Layer Address Extension from Section 9.
There are two extension sub-types for carrying nFA's IPv4 address and an access point identifier. They're called the Solicited Agent IPv4 Address Extension and the Access Point Identifier Extension, and they're described in Sections 9.5 and 9.6. These two extensions SHOULD NOT be present in the same PrRtSol message 🙅♀️
When oFA receives the PrRtSol message, it MUST reply to the MN with the Proxy Router Advertisement (PrRtAdv, message 2b) 🫶 The PrRtAdv is basically the Agent Advertisement for the requested nFA, proxied by oFA. To speed up the handoff, the actual nFA advertisement SHOULD be cached by oFA after an earlier exchange with nFA, shown in messages 1a and 1b, as specified in Section 3.5. The PrRtAdv message MUST contain nFA's L2 address (using the LLA extension in Section 9.3). There's more on this in Section 3.7 ✨
3.4. Obtaining and Proxying nFA Advertisements 🧚
Since L2 triggers are involved in starting a PRE-REGISTRATION handoff, the trigger timing SHOULD be arranged so a full L3 PRE-REGISTRATION handoff can finish before the L2 handoff process wraps up ⏰ In other words, the L2 handoff should complete after the MN's registration with nFA is done (message 3 in Figure 1). The registration MAY be sent in more than one copy (default recommendation: 2) to lower the chance that it gets lost to errors on the wireless link 🔁 This doesn't apply to reliable wireless links, where retransmissions happen at layer 2 if there's an error, so delivery is guaranteed 💖
A PRE-REGISTRATION handoff in this case requires the MN to receive an Agent Advertisement from nFA through the old wireless access point 📶 How to pull that off is covered in the subsections below. Messages exchanged between FAs MUST be authenticated to prevent impersonation attacks 🔒 The bare minimum is that every FA involved in low-latency handoffs MUST support manual pre-configuration of security associations with other neighboring FAs, involving shared keys and the default algorithms of [1] (see the Security Considerations of this document). Security is not a vibe to skip, bestie 💀
3.4.1. Inter-FA Solicitation 💖
okay so this bit is only for the network-initiated source-triggered (L2-ST) and mobile-initiated (L2-MT) cases, so check which one you're in 🎀 inter-FA solicitation assumes oFA already knows the IPv4 address of the nFA 🧚 oFA gets that address from an L2 trigger at oFA in the network-initiated case (see Section 3.2), or from the extension to the Proxy Router Solicitation (PrRtSol) that comes from the MN in the mobile-initiated case (see Section 3.3).
that PrRtSol extension can hold an IPv4 address, or it can hold some other identifier, like the identifier of a Wireless Base Station such as the WLAN BSSID 🌸 if it's the second one, oFA has to figure out the IPv4 address from the Base Station Identifier. the default way to do this is a configured table of neighboring Base Station Identifiers (e.g., BSSID) mapped to FA IPv4 addresses, stored in each FA. other automated discovery mechanisms may also be used ✨
okay, now the important part 🔥 if oFA doesn't cache advertisements (see Section 3.5) once it gets an L2 trigger and has the nFA's address for a specific MN, it MUST send a unicast Agent Solicitation (PrRtSol) to nFA. then nFA unicasts an Agent Advertisement with the right extensions back to oFA (PrRtAdv). this method gets rid of the TTL limitation from [1] for Mobile IPv4 messages (i.e., TTL=1 is not applicable here) 🦋 the TTL limit can't be applied because oFA and nFA might be more than one hop away, and it's also unnecessary for a secured unicast message. the ICMP solicitations and advertisements MUST be authenticated and integrity protected. these messages MUST be protected using Encapsulating Security Payload (ESP) [10] to prevent attacks (see the Security Considerations section of this document). an FA MUST NOT accept ICMP solicitations or advertisements from sources that aren't authenticated 🙅♀️
as a practical matter, oFA SHOULD pre-solicit and cache advertisements from known neighboring FAs (see section 3.5) so it doesn't have to do the solicitation during an actual handoff 💅
3.4.2. Tunneled nFA Advertisements ✨
this one only applies to the network-initiated target-triggered (L2-TT) case 🫶 following a target trigger (L2-TT), the nFA MUST send a tunneled Agent Advertisement to the MN through oFA. tunneling nFA advertisements assumes nFA knows the IPv4 addresses of oFA and the MN. those addresses come from the FA and MN identifiers in an L2 trigger that nFA receives in the network-initiated case (see Section 3.2). but the TTL in [1] has to be 1 on Agent Advertisements from the nFA, so tunneling advertisements only works if the TTL limitation of [1] is relaxed 😭 for that, a pre-established security association between oFA and nFA MUST be in place to authenticate this message and relax the TTL limitation. if the implementation needs it, a tunnel SHOULD be configured when the inter-FA security association is set up. the tunneled ICMP advertisement MUST be secured using tunnel mode ESP [10] between nFA and oFA. and an FA MUST NOT accept tunneled ICMP packets destined to it from sources that aren't authenticated 🔐
3.5. Caching Router Advertisements 🧚
in the mobile-initiated (L2-MT) case and the network-initiated source-triggered (L2-ST) case, message exchange 1 in Figure 1 could add extra latency to the L3 handoff if it's done as part of the handoff procedure 🥲 to get rid of that latency, the inter-FA Router (Agent) Solicitation and Advertisement exchange SHOULD be performed ahead of the handoff. a process SHOULD be in place at oFA to solicit its neighboring nFAs at a predefined time interval (MIN_SOLICITATION_INTERVAL). this interval SHOULD NOT be set too small, so you don't waste network bandwidth and nFA processing resources 💀 the minimum value of MIN_SOLICITATION_INTERVAL is 1 second.
if the FA Challenge/Response mechanism in [7] is used, then MIN_SOLICITATION_INTERVAL MUST be set to a value smaller then the window of time in which a challenge stays valid, so the nFA challenge doesn't expire before the MN sends the Registration Request ⏳ so the recommended default value for MIN_SOLICITATION_INTERVAL in oFA is (0.5 * nFA's CHALLENGE_WINDOW * nFA's Agent Advertisement interval). CHALLENGE_WINDOW and the Agent Advertisement interval are defined in [7] and [1] respectively. the minimum requirement is that MIN_SOLICITATION_INTERVAL MUST be manually configurable. possible autoconfiguration mechanisms are outside the scope of this document, so we're not going there 🙈 to allow advertisement caching in some implementations, and when the nFA advertisement interval is really small, it MAY be necessary for the nFA implementation to allow different CHALLENGE_WINDOW and Agent Advertisement interval settings on its nFA-oFA interface 💜
the oFA SHOULD cache the most recent advertisement from its neighboring nFAs. this advertisement MUST be sent to the MN in message 2b with a TTL=1 🎀 oFA SHOULD also have a mechanism in place to build a list of neighboring nFAs. the minimum requirement for each FA is that it SHOULD allow manual configuration of a list of nFA addresses that an MN could possibly do an L3 handoff to. which FA addresses go on that list depends on the deployment and radio coverage. it's also possible to specify another protocol for nFA discovery, but that's outside the scope of this document ✨
3.6. Movement Detection, MN, and FA Considerations 🦋
when the MN receives an Agent Advertisement with a Mobility Agent extension, it does stuff according to this movement detection mechanism: the MN SHOULD be "Eager" to perform new bindings 🏃♀️ that means the MN SHOULD perform registrations with any new FA it gets an advertisement from (i.e., MN is Eager), as long as the MN doesn't have any locally-defined policies that discourage using the discovered FA. for example, the MN could have a policy based on the cost of service 💸 the way the MN figures out whether an FA is new is described in [1], and it MAY use an FA-NAI extension [11]. being "Eager" about registrations cuts down latency times, which is so iconic 👑
the MN also needs to switch its default router from oFA to nFA 🌈 the MN MUST change its default router to nFA as soon as the PRE-REGISTRATION procedure finishes (i.e., Registration Reply is received by MN) as described in [1].
overall, the MN acts like [1] describes, with these changes: the movement detection mechanism above, and the ability to use L2-MT to start an Agent Solicitation with a special extension (PrRtSol) ✨ also, when the MN gets an L2-LU trigger (i.e., new interface or link is up), it MUST immediately send an Agent Solicitation [1] on that interface 🧚 an nFA that gets an Agent Solicitation [1] treats it as an L2-LU trigger event, and according to [1] it records the MN's IPv4/layer 2 addresses (i.e., the Address Resolution Protocol (ARP) entry). at that point nFA starts delivering data to the MN, including the Registration Reply it was holding onto 🫶 the nFA MAY also use other L2 mechanisms to notice earlier that the MN has attached to the new link, and start forwarding data to it. the MN SHOULD NOT try to retransmit a low-latency Registration Request (i.e., Registration Request containing an LLA extension described in Section 9.) if it doesn't get the Registration Reply 🙈
when the MN moves from a PRE-REGISTRATION network to a normal Mobile IPv4 [1] network, it stops getting PrRtAdv messages (i.e., Agent Advertisements with the LLA extension) 🥀 if the MN still gets L2-MTs, it'll try sending PrRtSol messages, and the normal FA will reply with a normal Agent Advertisement [1]. if the MN doesn't get a PrRtAdv back for its PrRtSol, it MAY retransmit the PrRtSol message once after PRE_SOL_INTERVAL seconds, and then for another PRE_SOL_ATTEMPTS times with exponential backoff of the transmission interval. if a PrRtAdv still isn't received within PRE_SOL_INTERVAL seconds after the last PrRtSol attempt, the MN MUST stop sending PrRtSol messages until it does a registration with a new FA 😤 the default value for PRE_SOL_ATTEMPTS is 2, and for PRE_SOL_INTERVAL it's 1 second.
it should be noted that the movement detection mandated in PRE-REGISTRATION (i.e., eager to register) may have sub-optimal behaviour in a standard Mobile IPv4 [1] network 💅 so standard movement detection mechanisms [1] should be used in plain Mobile IPv4 networks. instead, when the MN moves from a normal Mobile IPv4 [1] network into a PRE-REGISTRATION network, it starts receiving L2-MT triggers or PrRtAdv messages. when it gets those L2-MT triggers or PrRtAdv messages, the MN SHOULD follow the PRE-REGISTRATION procedure 🎀
if there's uncertainty about which mode to pick (e.g., the MN gets messages from both PRE-REGISTRATION and normal FAs), the MN decides based on its registration status with the current FA 🔍 if the MN already has a valid normal Mobile IPv4 Registration [1] with the advertising FA, it SHOULD give priority to the PRE-REGISTRATION procedure. otherwise it SHOULD give priority to the normal Mobile IPv4 [1] Registration procedure. and the MN SHOULD NOT try to do PRE-REGISTRATION and standard Mobile IPv4 [1] Registrations in parallel 🙅♀️
3.7. L2 Address Considerations 🌸
some special considerations should be taken for the wireless system this handoff method runs on 📡 think about an Ethernet-like system such as IEEE 802.11, for example. in PRE-REGISTRATION, the MN is registering with an FA (nFA) that isn't its current first-hop router. so the L2 address on the Ethernet frame carrying the MN's Registration Request when it reaches nFA is not the MN's address 🤯 which means the FA MUST NOT use the Ethernet address of the incoming Registration Request as the MN's L2 address, as specified in [1]. this applies when the wireless access points are bridges or routers, and no matter whether the FA is implemented in the access points themselves 🫶
in that case, the MN's Registration Request (or Regional Registration Request) MUST use an L2 address extension to the registration message. that L2 address is either the same L2 address that stays constant as the MN moves, or it's the MN's L2 address at nFA. to share its L2 address, the MN includes a Generalized Link Layer and IP Address Extension (see Section 9) with its Registration Request (or Regional Registration Request) message 💖 if that extension is there, the FA MUST use the L2 address in the extension to talk to the MN. if a particular wireless L2 technology has a special interface to the wireless network that lets the FA map an MN's IPv4 address to its L2 address without needing the extension, the L2 address extension contents may be discarded 🧚
for the same reasons as above, the MN MUST NOT use the source L2 address of the Agent Advertisement message (PrRtAdv) as its default router's L2 address 🙈 so the nFA MUST include a Generalized Link Layer and IP Address Extension (see Section 9.3) with its Agent Advertisement (PrRtAdv) messages ✨
3.8. Applicability of PRE-REGISTRATION Handoff 🦋
okay so PRE-REGISTRATION handoff is the move when a layer 3 gap would be totally unacceptable, like real-time communications, which means you need to see the layer 3 handoff coming ahead of time 🫶. Security here is based on the same security model as [1], AAA included 🔐. Big prerequisite: the FA or MN has to be able to get an L2 trigger that says an L2 handoff is pending 🚨. The target of that L2 handoff is another access point or radio network sitting in the coverage area of a new FA. The L2 trigger might arrive as identifiers that need resolving into IPv4 addresses, using methods that are specific to the wireless network (not covered here, bestie 💅). Quick vibe check: if the oFA or MN finds that the new FA's IPv4 address matches oFA's address, then PRE-REGISTRATION handoff SHOULD NOT be initiated 💀. Not worth it, periodt.
The L2 trigger has to give enough time for the whole PRE-REGISTRATION procedure to happen ⏰. With lots of wireless L2 technologies, the L2 handoff does a bunch of message exchanges before the actual L2 handoff goes through. For those, PRE-REGISTRATION can kick off at the very start of the L2 handoff and finish before the L2 handoff is complete ✨. It's super efficient to engineer the network so this order of events is guaranteed, iykyk 👑.
The PRE-REGISTRATION handoff is applicable in the following cases:
- when the MN has locally defined policies that prefer one access over another 🌸, for example because of service cost within the same or different technology. In that case the MN needs to be able to pick the right FA to connect to 💜.
- when L2 security between the MN and the FA is either not present or can't be relied on to provide adequate security 🔒.
- when the trigger to start the handoff is received at the MN 🧚.
In the first case, the MN's eventual local policies need to be part of the movement detection procedure, as described in Section 3.6 🎀.
4. The POST-REGISTRATION Handoff Method ✨
okay the POST-REGISTRATION handoff method is giving low-latency L2 point of attachment changes for the MN 🚀. It does this with bidirectional edge tunnels (BETs) or unidirectional tunnels, and the MN doesn't have to be involved at all 🙈. Figure 5 shows the basic vibe:
+------+
| CN |
+------+
|
...
|
+------+ BET +------+
| aFA |==========| nFA |
+------+ +------+
| wireless link
|
movement +------+
---------> | MN |
+------+Figure 5 - POST-REGISTRATION Concept
So once the MN has a successful Mobile IPv4 Registration with the oFA, the oFA becomes its mobility anchor point, called the anchor FA (aFA) 👑. When the MN moves from oFA to nFA, the MN doesn't have to send signaling over the wireless link to register with nFA. It can put off the L3 handoff and keep using its aFA (which is oFA in this case) 💅. If the MN moves to a third FA before it registers with nFA, then in certain cases described later, that third FA tells aFA to move the wireless link end of the BET over from nFA to itself 🦋. The network end of the BET stays anchored at aFA until the MN does the Mobile IPv4 Registration 🌈.
Messages between oFA/aFA and nFA MUST be authenticated 🔐. The minimal requirement is that every FA involved in low-latency handoffs MUST support manual pre-configuration of security associations with other neighboring FAs, using shared keys and the default algorithms of [1] 🫶. POST-REGISTRATION FAs MUST implement the inter-FA authentication extension (FA-FA authentication extension) specified in [11] 💜, and they MAY additionally use other security mechanisms ✨.
4.1. Two-Party Handoff 🎀
Okay bestie, two-party handoff is what happens when the MN moves from oFA to nFA 🦋 Normally that move would kick off a brand new Mobile IPv4 Registration at nFA. But in POST-REGISTRATION, the MN and nFA MAY delay that 💅 and keep the MN connected through the BET (or, alternatively, a unidirectional tunnel) between oFA and nFA. Here's the whole protocol in Figure 6 ✨
1a) L2-ST ~~~~> +------+ 2) HRqst +------+ <~~~ 1b) L2-TT
| oFA |<-------->| nFA |
4a) L2-LD~> +------+ 3) HRply +------+ <~~~ 4b) L2-LU
^ ^
old L2 | | new L2
+-------+ +-----+
| |
| |
V V
+------+ movement
4c) L2-LU ---> | MN | --------->
+------+
Figure 6 - Two-Party Handoff (POST-REGISTRATION)Okay so, here's the step-by-step 🧚 The numbered items point at the steps in Figure 6. The source-triggered HRqst/HRply pair for tunnel creation gets the suffix (s), the target-triggered pair for tunnel creation gets (t), and the HRqst/HRply used to extend or terminate a BET (or unidirectional tunnel) gets (r). Easy peasy 🌸
- Either the oFA or the nFA gets an L2 trigger saying a certain MN is about to move from oFA to nFA. There are two cases:
- a) The L2 trigger is a source trigger (L2-ST) at oFA. It carries the MN's L2 address and an identifier for the nFA (either the IPv4 address itself or an L2 address that can be resolved to the nFA's IPv4 address).
- b) The L2 trigger is a target trigger (L2-TT) at nFA. It carries the MN's L2 address and an identifier for the oFA (either the IPv4 address itself or an L2 address that can be resolved to the oFA's IPv4 address).
- The FA that gets the trigger sends a Handoff Request (HRqst) to the other FA. There are two cases:
- a) If the oFA is the one sending it, the
Hbit is set and theNbit is unset, which marks it as an HRqst(s). The HRqst(s) carries the lifetime of the tunnel the oFA is willing to support, the MN's IPv4 home address, the MN's HA address, and an LLA option with the MN's L2 address. If the lifetime is zero and theTbit is not set, the oFA is not willing to tunnel any packets for the MN. A positive lifetime with theTbit set means the oFA is willing to tunnel for that amount of time. Section 4.5 covers the HRqst(s), and Section 9 covers the LLA option 💖 - b) If the nFA is the one sending it, the
Nbit is set and theHbit is unset, which marks it as an HRqst(t). If theTbit is set, the nFA has asked for a reverse tunnel, and the HRqst(t) carries the lifetime of the tunnel the nFA is requesting. The HRqst(t) also carries an LLA option with the MN's L2 address. The MN's IPv4 home address and HA address are not sent, unless they're discovered some other way that's outside the scope of this document (for example, as part of the L2-TT). Section 4.5 covers the HRqst(t).
- a) If the oFA is the one sending it, the
- The FA that gets the HRqst sends a Handoff Reply (HRply) back to the other FA. There are two cases:
- a) If the oFA is the one sending it, the
Nbit is set and theHandRbits are unset, which shows the reply is answering an HRqst(t), so it's an HRply(t). If theTbit is set, the HRply(t) carries the tunnel lifetime the oFA is willing to provide. Otherwise the tunnel lifetime is set to zero, meaning the oFA isn't willing to provide tunnel service. If both the HRply(t) and the HRqst(t) have theTbit set and a non-zero lifetime, a BET is established. The HRply(t) also carries the MN's home subnet IPv4 address, the MN's HA address, and an LLA option with the MN's L2 address. Section 4.6 covers the HRply(t) 🫶 - b) If the nFA sends the HRply, the
Hbit is set and theNandRbits are unset, which shows it's answering an HRqst(s), so it's an HRply(s). If theTbit is set, the nFA is asking for a reverse tunnel, and the lifetime field holds the tunnel lifetime it requested. TheTbit can only be set in an HRply if the oFA had set theTbit in the matching HRqst, or if the nFA is required to reverse tunnel incoming packets to the oFA because ingress filtering is enabled on its network. This sets up a BET. The tunnel lifetime the nFA requests must be less than or equal to the tunnel lifetime the oFA offered in the HRqst(s). Section 4.6 covers the HRply(s) ✨
- a) If the oFA is the one sending it, the
- The moment the MN stops being connected on a given link gets signaled by an L2-LD trigger at the oFA and the MN. Finishing the L2 handoff gets signaled by an L2-LU trigger at the nFA and the MN. Here's how each trigger gets handled:
- a) When the oFA gets the L2-LD trigger, it starts forwarding MN-bound packets through the forward tunnel to the nFA 🚀
- b) When the nFA gets the L2-LU trigger, it starts delivering packets tunneled from the oFA to the MN, and it forwards outbound packets from the MN using normal routing or through a reverse tunnel to the oFA or HA. At this point the nFA may not yet be the MN's default router (see Section 4.4). So, to receive all of the MN's outbound packets, the nFA has to send a unicast proxy ARP message (used in [1]) to the MN as soon as it gets the L2-LU trigger. This proxy ARP message is an ARP Reply [5] that the nFA sends on behalf of the oFA. It puts the nFA's link-layer address in the Sender Hardware Address field and the oFA's IPv4 address in the Target Protocol Address field 🧠
- c) When the MN gets the L2-LU, it MAY start the Mobile IPv4 Registration process by soliciting an Agent Advertisement as described in [1]. If the registration works, the nFA takes over the anchor FA (aFA) role from the oFA. Alternatively, the MN MAY defer the Mobile IPv4 Registration (see Section 4.4) 🌈
- The oFA turns into an aFA if the MN moves to a third FA before doing a Mobile IPv4 Registration with the nFA 🦋
- Okay, so if the L2 handoff fails in Step 4 (for L2 reasons) and a ping-pong situation pops up, the oFA may be able to figure that out from the trigger mechanism. It would see successive L2-ST/L2-TT triggers, followed by L2-LD and then L2-LU 👀 In that case, the FA that started the HRqst can cancel the tunnel by sending an HRqst(r) with lifetime zero to the other FA. After that it just keeps delivering packets to the MN exactly like no handoff was ever pending. Section 4.5 covers the HRqst(r) 💅
If the oFA sets the B bit in an HRqst/HRply and the nFA hasn't asked for a reverse tunnel by setting the T bit, the nFA SHOULD tunnel outgoing packets from the MN to the HA. That's because the MN asked the oFA for this service. The nFA SHOULD offer this service only if no security between the nFA and the MN's HA is required, or if there's already an nFA-HA security association 🔐
The timing of the BET or unidirectional tunnel setup depends on which L2 triggers are available, so it's a bit of a vibe check 😭
The forward tunnel from the oFA to the nFA is built with one of the tunneling procedures described in [1] for the HA-to-FA tunnel. The only difference is that the two ends of the tunnel are at the oFA and the nFA. The reverse tunnel from the nFA to the oFA is built as described in [3], except the network end of the tunnel is at the oFA instead of the HA. If both the forward and reverse tunnels get set up, a BET exists 🎀 With optimal L2 trigger info, like described above, the FAs can set up the BET right when the L2 handoff starts. They can start tunneling MN-bound data when the link to the MN goes down, and the nFA can use the link-up trigger to start delivering packets. Without optimal L2 trigger info, the HRply can act as the trigger to start tunneling MN-bound data. But in that case, the packet delivery disruption to the MN could still happen, and extra measures may be required to keep service uninterrupted 🥺 Some implementation and deployment scenarios could need techniques to smooth the handoff, like a way to convey packets that arrive during the L2 handoff. The exact techniques are outside the scope of this document 🍓
Figures 7 and 8 show the timing diagrams for the source trigger (L2-ST) and target trigger (L2-TT) two-party handoffs, respectively ⏱️
MN nFA oFA
| | |
| | HRqst(s) |<~~~ L2-ST
| |<------------------|
| | HRply(s) |
| |------------------>|
| | |
--------------------------------------------<~~~ L2-LD
L2 Handoff
--------------------------------------------<~~~ L2-LU
| | |
|<------------------->| |
| MN's traffic | |
Figure 7 - Two-Party Source Trigger Handoff Timing MN nFA oFA
| | |
| L2-TT ~~~>| HRqst(t) |
| |------------------>|
| | HRply(t) |
| |<------------------|
| | |
--------------------------------------------<~~~ L2-LD
L2 Handoff
--------------------------------------------<~~~ L2-LU
| | |
|<------------------->| |
| MN's traffic | |
Figure 8 - Two-Party Target Trigger Handoff TimingOnce the tunnel between the aFA and the current FA is in place, it gets torn down by one of these events 🧹
- The aFA decides to stop tunneling because the lifetime it sent expires and doesn't get renewed. Or the aFA or current FA decides to end tunnel service early for some other reason (refer to Section 4.3) ⏰
- The MN finishes the process by doing a Mobile IPv4 Registration with the current FA. This can be started by the FA sending an Agent Advertisement, or by the MN soliciting an Agent Advertisement as in [1] 🫶
- The MN moves to a third FA (see Section 4.2) 🦋
4.2. Three-Party Handoff ✨
okay so three-party handoff is for when an MN already has an aFA and is getting tunneled packets through its current FA 🦋, and then it moves to a new FA without doing a Mobile IPv4 Registration. no cap, it's a whole plot twist 😭
The need for this depends on the wireless system where POST-REGISTRATION is being implemented 🌸. For radio L2 protocols where the MN can zoom from one FA to another so fast that the Mobile IPv4 Registration with nFA might not finish before it moves on, HTT (Handoff to Third) SHOULD be implemented 💅. Some wireless systems and implementations don't let MNs move that fast between FAs and may force the Mobile IPv4 Registration to happen soon after L2 handoff. In that case, three-party handoff isn't applicable 🙈. If this feature isn't implemented, the FA SHOULD send an Agent Advertisement to the MN after L2 handoff has completed (L2-LU at nFA), and/or the MN SHOULD solicit an Agent Advertisement after L2 handoff (L2-LU at MN) ✨.
+------+
+--->| aFA |<---+
| +------+ |
4b) HRqst(r) | | 3) HRqst(t)
HRply(r) | | HRply(t)
| |
v 2a) HRqst v
1a) L2-ST ~~~> +------+ HTT +------+ <~~~ 1b) L2-TT
| oFA |<-------->| nFA |
4a) L2-LD ~~~> +------+ 2b) HTT +------+ <~~~ 5a) L2-LU
^ HRply ^
old L2 | | new L2
+-------+ +-----+
| |
| |
V V
+------+ movement
5b) L2-LU ~~~> | MN | --------->
+------+
Figure 9 - Three-Party HandoffThe L3 handoff can get deferred either because the MN/FA decided to skip it (i.e., the MN doesn't send Agent Solicitations and the FA doesn't send Agent Advertisements), or because the MN moves so quickly between oFA and nFA that there isn't enough time for registration to finish 🍓. That's the scenario in Figure 9. Here, oFA must tell nFA (i.e., the third FA) to contact aFA about moving the radio end of the tunnel. It does this with the HTT message 💜.
The big idea: oFA gives nFA the same info it would have gotten from an L2-TT if the handoff had happened from aFA to nFA. Then nFA does an HRqst(t)/HRply(t) exchange with aFA to move the BET over to nFA 🧚. Once L2 handoff is done, oFA sends an HRqst(r) to aFA to end the old BET. Iconic teamwork 👑.
Here's how a three-party handoff goes. The numbers match the steps in Figure 9 🎀.
- Either oFA or nFA gets an L2 trigger saying a certain MN is about to be moved. There are two possible cases:
- a) The L2 trigger is a source trigger (L2-ST) at oFA. It contains the MN's L2 address and an identifier for nFA (either the IPv4 address itself, or an L2 address that can be mapped to nFA's IPv4 address).
- b) The L2 trigger is a target trigger (L2-TT) at nFA. It contains the MN's L2 address and an identifier for oFA (either the IPv4 address itself, or an L2 address that can be resolved to oFA's IPv4 address).
- oFA and nFA swap an HTT/HRply or HRqst/HTT pair. HTT is shown by setting both the H and N bits in the HRqst or HRply. The HTT message MUST NOT have any tunnel flag bits set, because the tunnel is negotiated between aFA and nFA, not oFA and nFA 🫶. There are two cases:
- a) The L2 trigger is an L2-ST. oFA sends HTT to nFA with the MN's home IPv4 address, the MN's HA address, an LLA containing aFA's IPv4 address, and an LLA containing the MN's L2 address. That's enough for nFA to do a target-triggered handoff with aFA. nFA replies with an HRply(s). Section 4.7 describes the HTT 🌈.
- b) The L2 trigger is an L2-TT. nFA sends HRqst(t) to oFA, exactly like a two-party handoff would. oFA responds with HTT containing the same info as in a) above. That's enough for nFA to do a target-triggered handoff with aFA 💖.
- When nFA gets the HTT, it first checks its Visitor Cache to see if it's already tunneling for the MN. If it is, Step 6 happens. If not, nFA does a target-triggered handoff with aFA, exactly as in Section 4.1, swapping an HRqst(t)/HRply(t) pair. Since aFA doesn't get an L2 trigger telling it when L2 handoff starts, it may start tunneling to nFA as soon as it sends the HRply(t) ✨.
- Once L2 handoff is underway and the MN gets disconnected at L2, aFA and oFA exchange messages to cancel the tunnel service between aFA and oFA, and let aFA start the tunnel with nFA 🦋.
- a) The moment the MN gets disconnected from oFA during L2 handoff is signaled at oFA by L2-LD.
- b) oFA swaps an HRqst(r)/HRply(r) pair with aFA, with lifetime zero. This cancels the tunnel service between oFA and aFA. If aFA hasn't already set up a tunnel to nFA, it must do so immediately when it gets the HRqst(r). aFA provides tunneling service exactly as described in Section 4.1, Step 4a.
- L2 handoff completion is signaled by an L2-LU trigger at nFA and/or the MN. nFA and the MN handle the trigger like this:
- a) nFA provides packet delivery service to the MN exactly as described in Section 4.1, Step 4b.
- b) When the MN gets the L2-LU, it either defers or starts Mobile IPv4 Registration, as in Section 4.1 🍓.
- Special case time! If nFA and aFA are the same (i.e., the MN is moving back to its original anchor FA), aFA notices that it's already tunneling to oFA when it checks its Visitor Cache in Step 3 🙈. So aFA doesn't need to send the HRqst(t)/HRply(t) from Step 3. When the L2-LU trigger arrives on handoff completion, aFA starts routing packets to the MN and the tunnel to nFA gets torn down. oFA still does the HRqst(r)/HRply(r) exchange with aFA from Step 4b, because oFA can't know ahead of time that aFA and nFA are the same. They're just redundant 🧚.
Figures 10 and 11 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) three-party handoff, in that order 💅.
MN nFA oFA aFA
| | L2-ST ~~~> | |
| | | |
| |<-------------| |
| | HTT | |
| |------------->| |
| | HRply(s) | |
| |------------------------------>|
| | HRqst(t) | |
| |<------------------------------|
| | HRply(t) | |
| | | |
----------------------------------<~~~ L2-LD |
|--------------->|
L2 Handoff | HRqst(r) |
| |
|<---------------|
| HRply(r) |
| |
----------------------------------<~~~ L2-LU |
| MN's traffic | | |
|<-------------->| | |
Figure 10 - Three-Party Source Trigger Handoff Timing MN nFA oFA aFA
| | | |
| |<~~~ L2-TT | |
| |------------->| |
| | HRqst(t) | |
| |<-------------| |
| | HTT | |
| |------------------------------>|
| | HRqst(t) | |
| |<------------------------------|
| | HRply(t) | |
| | | |
----------------------------------<~~~ L2-LD |
|--------------->|
L2 Handoff | HRqst(r) |
| |
|<---------------|
| HRply(r) |
| |
----------------------------------<~~~ L2-LU |
| MN's traffic | | |
|<-------------->| | |
Figure 11 - Three-Party Target Trigger Handoff TimingHere's the big difference from two-party handoff 🌸: the timing of BET setup between aFA and nFA can't fully depend on L2 trigger info, because aFA never gets an L2 trigger saying L2 handoff is happening. So there are two timing extremes for when aFA can set up the BET with nFA 🦋:
- At the earliest, aFA MAY start tunneling packets using the BET to nFA after it sends the HRply(t) to nFA in response to the target-triggered handoff request.
- At the latest, aFA MAY start tunneling packets using the BET to nFA and tear down the BET with oFA when it gets the HRqst(r) from oFA saying the MN has disconnected.
Also, aFA MAY keep tunneling to oFA if option 1 is picked, until the HRqst(r) arrives. The catch is that the MN might get duplicated packets, since it'll keep receiving packets through oFA on the old L2 until it disconnects (L2-LD) 🙈. If option 2 is picked, the extra latency adds to the MN's L3 service disruption period 💀. Of course, aFA can pick a time somewhere between 1 and 2 if there are reliable bounds on how long it takes from L2-ST/L2-TT until the MN disconnects (L2-LD) ✨. Exactly when to set up the BET is probably going to depend on network engineering and implementation stuff, including whether a handoff smoothing solution is used. That's out of scope for this spec, bestie 🫶.
4.3. Renewal or Termination of Tunneling Service
Okay so, bestie, to stop a BET from expiring when its lifetime runs out, the MN's current FA signals the aFA to either renew or terminate it 🎀. This can happen when the MN defers Mobile IPv4 Registration. If no such signal arrives, the aFA terminates the BET when the lifetime expires. The current FA or aFA might also need to kill the BET before the lifetime runs out. To stop tunnels from hanging around forever after the MN they belong to is unreachable, FAs SHOULD set the tunnel lifetime field to some value other than 0xffff, which means "good until canceled" 💅.
Figure 12 shows the exchange between the FA that needs to terminate or extend the tunnel (FA(1)) and the other FA (FA(2)). The HRqst(r)/HRply(r) is marked by setting the R bit in the HRqst/HRply messages. If the HRqst(r) is renewing a BET, it carries a non-zero lifetime. If the lifetime is zero, it means terminate 💀. The aFA is totally in charge of whether the tunnel gets extended or terminated, and it MAY reply to an extension request with a shorter lifetime than the one that was asked for 🙈.
HRqst(r)
+------+ <-------- +------+
| FA(2)| ---------> | FA(1)|
+------+ HRply(r) +------+Figure 12 - BET Renewal or Termination
4.4. When Will the MN Perform a Mobile IPv4 Registration?
The MN and FA get to decide when to do the Mobile IPv4 Registration ✨. The MN/FA can choose to defer it for a while, but there are three events that can force the issue and mean the tunneling service has to be terminated. When one of these happens, the MN MUST perform the Mobile IPv4 Registration. Here they are:
- The end of life for the BET is pending, and the current FA's request to the aFA for renewal has been denied. Or the current FA or aFA needs to terminate the BET early. The FA in this case MUST initiate the Mobile IPv4 Registration by sending an Agent Advertisement to the MN as in [1].
- The MN itself decides to do a Mobile IPv4 Registration and starts it by sending an Agent Solicitation as in [1].
- During a source-triggered handoff, the oFA tries to do BET handoff but the nFA can't handle it. The FA in this case MUST initiate the Mobile IPv4 Registration by sending the MN an Agent Advertisement as in [1]. Note that this situation will never happen during target-triggered handoff, because an nFA that doesn't support POST-REGISTRATION won't send an HRqst(t) to the oFA. 🧚
Some detailed scenarios for case 2) come up later. According to [1], when the FA care-of address is in use, the MN MAY use the FA as its default router. Otherwise, it MUST choose its default router from the ones advertised in the ICMP Router Advertisement portion of the Agent Advertisement. For this part we assume the FA router is also the MN's default router. In POST-REGISTRATION, once a tunnel is set up between oFA and nFA and the MN has moved to nFA, the oFA MUST NOT send Agent Advertisements to the MN. So it's possible the MN won't get any Agent Advertisements for a long stretch of time 😭. According to [8], hosts drop default router entries when the Router Advertisement lifetime runs out and no new advertisements show up. The ICMP Router Advertisement lifetime isn't related to the Registration Lifetime in the Mobility Agent Advertisement extension [1], so keep that straight. To avoid this disruption, the MN MUST solicit the default router (i.e., FA) before the lifetime of its active default router entry runs out. Or, alternatively, the FA MUST advertise as soon as the MN-nFA link is up (L2-LU). This basically means the MN can only put off its Mobile IPv4 Registration for as long as the active default router has left, as set in the ICMP Router Advertisements 🌸. The MN MUST perform a Mobile IPv4 Registration [1] when it receives an Agent Advertisement following a POST-REGISTRATION handoff.
4.5. Handoff Request (HRqst) Message Format
This is a brand new Mobile IPv4 message that rides on UDP (destination port 434) [1] 🦋. The UDP header is followed by the fields below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |H|N|R|M|G|T|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-Here's the field breakdown, bestie 🎀:
Type: 16 (Handoff Request).H: Source-triggered handoff request. When it's set and the N bit is unset, it means the request came from an L2-ST at oFA.N: Target-triggered handoff request. When it's set and the H bit is unset, it means the request came from an L2-TT at nFA.R: Set if the request is an HRqst(r), meaning a request to renew the tunnel. The H and N bits must be unset.M: The FA issuing the HRqst will use Minimal Encapsulation as defined in [1,5] for the tunnel.G: The FA issuing the HRqst will use Generic Routing Encapsulation (GRE) [4] as defined in [1,5] for the tunnel. Extensions of HRqst containing GRE type and key fields are outside the scope of this document.T: For an HRqst(s), it means the oFA is willing to support both forward and reverse tunnel service. For an HRqst(t), it means the nFA is asking for reverse tunnel service.B: When sent in an HRqst(s), it means the MN has asked for a reverse tunnel to the HA, and the nFA SHOULD use a reverse tunnel to the HA if it won't be reverse tunneling to the oFA ✨.Lifetime: The lifetime of the tunnel in seconds. On an HRqst(t), the lifetime is the nFA's request for a reverse tunnel. On an HRqst(s), it's the maximum time the oFA is willing to keep both forward and reverse tunnels going. On an HRqst(r), it's the amount of time requested to renew the tunnel's lifetime. A value of 0 on an HRqst(s) means the oFA won't grant tunnel service. A value of 0 on an HRqst(t) means the nFA doesn't need reverse tunnel service. A value of 0 on an HRqst(r) means the tunnel should be terminated. A value of 0xffff means infinity ♾️.MN Home Address: For HRqst(s), the home address of the MN.HA Addr: For HRqst(s), the HA address of the mobile node.Identification: As defined in [1].Extensions: The message MUST include an LLA (see Section 9) that contains the MN's L2 address and an L2 address that can be mapped to an IPv4 address for the FA. This message MUST contain the FA-FA Authentication Extension [11], which is used to secure the HRqst message. Don't skip this one, it's a big deal 🔥
4.6. Handoff Reply (HRply) Message Format 💅
okay so this is the new Mobile IPv4 message 🦋 it rides on UDP, destination port 434, and the UDP header is followed by these fields:
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 |H|N|R|M|G|T|B| Reserved | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-Type: it's always17(Handoff Reply) 🎀Code: this is how the result of the Handoff Request gets shared 👑 Only two codes are supported right now:0means success, and1means the handoff can't be performed. Everything else is reserved for later 🌸Lifetime: this is how many seconds the bidirectional tunnel for the MN will hang around 🧚 The meaning shifts depending on which kind of reply it is:- In an HRply(s), it's a request from the nFA, and it can be anything up to the max that was sent in the HRqst(s). Bigger numbers just default to the oFA's maximum.
- In an HRply(t), it's the most time the oFA will grant the nFA.
- In an HRply(r), it's how much the tunnel life gets extended by.
- If the Code says the handoff failed, the Lifetime gets ignored, and it SHOULD be set to zero 🙈
- A
0means different things by type: on an HRply(t) the oFA is unwilling to grant service, on an HRply(s) the nFA doesn't need service, and on an HRply(r) the tunnel gets terminated. 0xffffmeans infinite lifetime, so the tunnel literally never expires ♾️
H: source-triggered handoff reply. If it's set andNis unset, the reply is answering an HRqst(s) ✨N: target-triggered handoff reply. If it's set andHis unset, the reply is answering an HRqst(t) 💜R: set if the reply is an HRply(r). In that case neitherHnorNis set 🦋M: the FA that issued the HRqst is going to use Minimal Encapsulation, as defined in [1,5], for the tunnel 🍓G: the FA that issued the HRqst is going to use GRE [4] Encapsulation, as defined in [1,5], for the tunnel. When this bit is set, the HRply might need extensions carrying the GRE type and key fields, but those are outside the scope of this document 🧚T: on an HRply(s), it means the nFA is asking for reverse tunnel service. On an HRply(t), it means the oFA is willing to give both forward and reverse tunnel service 💅B: when it shows up in an HRply(t), the MN has asked for a reverse tunnel to the HA, and the nFA SHOULD use a reverse tunnel to the HA if it won't be reverse tunneling to the oFA. This bit can only be set in an HRply(t) if theTbit was unset in the matching HRqst(t) 🫶MN Home Address: for an HRply(t), this is the home IPv4 address of the MN 🌈HA Addr: for an HRply(t), this is the IPv4 address of the MN's HA ⭐Identification: defined in [1] 🎀Extensions: this message MUST contain the FA-FA Authentication Extension [11], which is what secures the HRply message 🔥
4.7. Handoff to Third (HTT) Message Format 🧚
the Handoff to Third message basically looks like a Handoff Request and a Handoff Reply had a baby 👶 It has the same format as both of them, except the H and N bits are both set ✨
If the HTT is answering an L2-ST and is sent to kick off a handoff, then (apart from the H and N bits) it has the same fields set and the same extensions as an HRqst(s). If the HTT is sent in response to an HRqst(t), then (again, apart from H and N) it has the same fields set and the same extensions as an HRply(t). The tunnel bits MUST NOT be set in the HTT message, because BET construction isn't negotiated between oFA and nFA. It's negotiated between nFA and aFA in the HRqst(t)/HRply(t) that comes after 🙅♀️
On top of that, the HTT MUST contain the following extensions, in this exact order:
Solicited IPv4 Address Option: containing aFA's Address 🌸LLA Option: containing the L2 address of the MN 🍓
4.8. Applicability of POST-REGISTRATION Handoff Method 🦋
so POST-REGISTRATION is the handoff approach where the FAs just talk to each other directly about a pending handoff 🗣️ No IPv4-layer messages have to go to or from the MN before the L2 handoff happens, which means it kills a possible source of handoff latency. Iconic 👑 This can be really needed when the link layer has hard deadlines for when the handoff has to happen, like when an MN is zooming out of a radio coverage area 🏃♀️💨 Because of that, POST-REGISTRATION is mainly interesting for handoffs between FAs that support the same radio access technology. Handoffs between totally different radio technologies will, by necessity, need the MN and the network to interact, so POST-REGISTRATION is not the domain it's built for 🙅♀️
Now, a POST-REGISTRATION handoff gets triggered by some unspecified mechanism that tells the oFA or nFA that an L2 handoff is coming up. So POST-REGISTRATION only works on networks where that kind of mechanism exists 🔍 For example, an L2 might give out radio signal quality indications that make the oFA or nFA send the POST-REGISTRATION handoff messages. Any indications like that also have to tell each FA involved in the handoff who the other one is, so the messages land in the right place. That can mean mapping L2 information onto FA IPv4 addresses 🗺️ The FAs involved in a handoff also need pre-provisioned security arrangements so the POST-REGISTRATION messages can be authenticated 🔐 And if the handoff is going to be completed as a result of the POST-REGISTRATION messaging, any L2 handoff indications must also be securely authenticated, so that traffic to the old point of attachment doesn't get improperly halted. Nobody wants that drama 😭
POST-REGISTRATION handoff is appropriate in these cases:
- L2 triggers are available on the network to indicate that an L2 handoff is pending ⭐
- Pre-provisioned security mechanisms are in place, allowing fast and secure messaging between the FAs and between the MN and an FA 💜
- Access point choice by the MN isn't a concern, or the choice requires user intervention and so isn't on the critical path for handoff 🫶
5. Combined Handoff Method 🌈
okay the combined method is the best of both worlds 💖 It uses both PRE-REGISTRATION and POST-REGISTRATION handoff. If PRE-REGISTRATION hasn't finished before a timer on the nFA runs out, the POST-REGISTRATION mechanism gets used to build the tunnel between oFA and nFA. This protects the MN from delays caused by errors like a lost Mobile IPv4 Registration Reply message during PRE-REGISTRATION, for the mobile-initiated and network-initiated source-triggered cases. It also protects the MN from delays caused by errors or lost Mobile IPv4 messages in PRE-REGISTRATION for the network-initiated target-triggered case 🛡️✨
When the nFA gets a target trigger, it follows the PRE-REGISTRATION procedure. When the combined method is used, the nFA MUST also start a timer when it receives a target trigger. The timer should be set to a small value (the default for the target trigger case is 1 second) ⏱️
According to PRE-REGISTRATION, the nFA will receive the Registration Request from the MN. When the combined method is used, this Registration Request MUST contain the IPv4 address of the oFA in an FA IPv4 address LLA extension (see Section 9.7). That same Registration Request will also contain multiple LLA extensions, since it carries the MN's layer 2 address in an LLA extension too, as described for PRE-REGISTRATION (see Sections 3.7 and 9) 🧚 When the nFA hasn't started the handoff procedure using a target trigger (that's the mobile-initiated or network-initiated target-triggered cases), the nFA MUST start a timer as soon as it receives the low-latency Registration Request from the MN. This timer should be set to a small value (default: 1 second) 💅
In every case, the timer MUST be reset when the nFA receives the Registration Reply message. If the timer expires before the Registration Reply is received, the nFA MUST initiate the POST-REGISTRATION procedure 🚨 The nFA uses the oFA IPv4 address (the one it got earlier in the extension to the Registration Request message) as the destination of the POST-REGISTRATION HRqst message, so it can create the tunnel between nFA and oFA 🎀 The nFA MAY tear down this tunnel when it receives and forwards a successful Registration Reply for that MN 🦋
6. Layer 2 and Layer 3 Handoff Timing Considerations ⏱️
okay so in the optimal cases we covered for PRE-REGISTRATION and POST-REGISTRATION handoffs, we were assuming a timely L2 trigger shows up, so packets can reach the MN through its nFA the moment it connects 🦋. That way the MN doesn't get wrecked by the L3 handoff. 💅
ngl though, that perfect timing isn't going to happen in every wireless system. It depends on the implementation techniques people use 🙈 So there can be some uncertainty at L3 about exactly when the L2 connection between the MN and the nFA is fully up and ready for L3 traffic. Traffic might get re-routed a little too early or a little too late compared to when that connection is actually established 😭
The things that can fix this and let the MN receive traffic no matter when the L2 handoff happens are buffering and simultaneous bindings (aka bicasting, where you set the S bit [1] in Registration Requests) 🫶 But these are optional, and nobody is forcing anyone to use them.
7. Reverse Tunneling Support 🔁
all the handoff methods support reverse tunneling ✨ The MN can request reverse tunneling [3] by setting the T bit in its Registration Request. For POST-REGISTRATION, if the MN already asked for reverse tunneling at oFA, the handoff message from oFA (see Section 4) has the T bit turned on so nFA knows to set up a BET for the visitor entry 🌸
Typically the T bit is always set, so any delay in the MN getting its new care-of address doesn't hold up uplink packets coming from the MN 🚀 Local policies and certain L2 technologies might still let the reverse tunnel get switched off, though.
8. Handoff Signaling Failure Recovery 🛟
in general, and even more so in wireless networks, packets carrying handoff signaling can get dropped or lost because of link errors 😩 So in this section we look at how to recover when handoff signaling fails 💖
8.1. PRE-REGISTRATION Signaling Failure Recovery 🧚
PRE-REGISTRATION signaling failures break down into three cases:
- Loss of the messages PrRtSol and PrRtAdv on the air link.
- Loss of the solicitation sent by an FA to get another neighboring FA's Advertisement, or loss of that neighboring FA's advertisement.
- Failure of the standard Mobile IPv4 Registration.
Case 3 is handled by the standard Mobile IPv4 mechanisms described in [1] 🎀 Case 2 is expected to be super rare, because spontaneous packet drops on the fixed network are caused by congestion or router failure. Since bit error rates on wireless links are higher than on fixed links, case 1 is way more likely to happen 🥺 The next subsections look at cases 1 and 2 ✨
8.1.1. Failure of PrRtSol and PrRtAdv 💌
PRE-REGISTRATION handoff can fail in a network-initiated handoff when the PrRtAdv that oFA sends in response to the source trigger (L2-ST), or the advertisement that nFA sends in response to the target trigger (L2-TT), doesn't reach the MN 😭 It can also fail in a mobile-initiated handoff when either the PrRtSol sent from the MN or the return PrRtAdv sent from oFA gets dropped.
To lower the chances that PrRtAdv and PrRtSol get lost, the MN and FA MAY transmit multiple copies of these messages 🌈 If these messages fail anyway, the MN connects to nFA in both cases without having received any prior signaling 🙈 Then the MN solicits an FA Advertisement when it connects to nFA at L2 (L2-LU), as described in Section 3.6, and does a standard Mobile IPv4 Registration with nFA as specified in [1] 💅
8.1.2. Failure of Inter-FA Solicitation and Advertisement 📡
The solicitation from one FA to another neighboring FA can fail, or the matching advertisement from that neighboring FA can get lost. To lower the odds of losing these messages, the FAs MAY transmit multiple copies of them ✨ If a failure happens anyway, the FA that's soliciting the Agent Advertisement can't send a PrRtAdv in response to a source trigger or to a mobile-initiated PrRtSol 😩 In those cases, when the MN doesn't get a notification or confirmation of a PRE-REGISTRATION handoff, the MN MUST perform a standard Mobile IPv4 Registration as soon as it connects to nFA (L2-LU), as described in Section 8.1.1 🫶
8.2. POST-REGISTRATION Signaling Failure Recovery 🎬
POST-REGISTRATION failure happens when either the HRqst or HRply message gets dropped. The effects and the recovery procedure depend on which message was dropped and on whether the handoff was source or target triggered 👀 Since all the POST-REGISTRATION signaling goes over the fixed network, spontaneous drops without congestion or router failure should be pretty rare 🦋 Still, failure recovery mechanisms SHOULD be implemented 💜
8.2.1. HRqst Message Dropped 🙅♀️
If the HRqst message gets dropped, the result is the same for source- and target-triggered handoffs ✨ Either way, the FA the HRqst was headed to will never reply with an HRply message 😭 If the handoff is source triggered, then nFA never finds out about the handoff, and oFA never gets confirmation. If the handoff is target triggered, then oFA never finds out about the handoff, and nFA never gets confirmation.
Here's the recovery plan for this case 📋 oFA MUST NOT construct a forward tunnel when the MN moves off-link (L2-LD) if the handoff is source triggered, and nFA MUST NOT construct a reverse tunnel if the handoff is target triggered. If nFA wasn't told about the handoff by an HRqst message (which means the source-triggered handoff failed), or if the handoff wasn't confirmed by an HRply message (which means the target-triggered handoff failed), nFA MUST unicast an Agent Advertisement to the MN as soon as its L2 connection is established (L2-LU at nFA) 🌸
8.2.2. HRply Message Dropped 🫠
If the HRply message gets dropped, the FA that sent the HRply thinks the handoff is confirmed, but the FA that was waiting for the HRply never gets confirmation 😬 Recovery is different for source- and target-triggered handoffs, so let's do both 💖
In a target-triggered handoff, oFA assumes the handoff is confirmed because it sent the HRply, but nFA never got it, so nFA doesn't have confirmation 🙈 oFA starts tunneling packets to nFA when the MN moves off its link (L2-LD). nFA MUST send an FA Advertisement to the MN as soon as its L2 link is up (L2-LU at nFA), and nFA MAY drop the tunneled packets. nFA SHOULD send an ICMP Destination Unreachable [9] message to oFA. When oFA gets this message, it terminates the tunnel and stops forwarding packets ✨ If reverse tunneling was requested, nFA MUST NOT reverse tunnel, because it never received handoff confirmation 🛑
In a source-triggered handoff, nFA assumes the handoff is confirmed because it sent the HRply, but oFA never received it, so oFA doesn't have confirmation 😩 Without failure recovery, the MN could move over to nFA before oFA gets the forward tunnel started for the MN's packets. And the MN couldn't start a Mobile IPv4 Registration, because it wouldn't know the handoff failed 💀 So in this situation, oFA MUST send out an HRqst message to nFA with lifetime zero as soon as the MN leaves its link (L2-LD). oFA SHOULD keep retransmitting the HRqst message with exponential backoff for CONFIG-HFAIL seconds, or until it receives an HRply acknowledging the request to cancel the tunnel 🔁 The default value for CONFIG-HFAIL is 10 seconds ⏰ When nFA receives the HRqst, it MUST immediately send an Agent Advertisement to the MN, just like it does whenever a tunnel gets canceled ✨ On top of that, oFA MUST also drop any packets received through the reverse tunnel from nFA. oFA SHOULD NOT send the ICMP Destination Unreachable message to nFA, because the HRqst already told nFA to cancel the tunnel 🙅♀️ But if nFA gets an ICMP Destination Unreachable message for the tunnel before it receives the HRqst canceling the tunnel, nFA MUST send an FA Advertisement to the MN and cancel the tunnel 🎀
9. Generalized Link Layer and IPv4 Address (LLA) Extension 🪪
this section defines the Generalized Link Layer and IPv4 Address (LLA) Extension, which any node that needs to communicate link layer and IPv4 addresses can use 🌈 The format of the extension depends on sub-types, and each sub-type defines its own sub-structure. This document defines six sub-types. Future RFCs should allocate their own sub-type and define their own address formats 💜
Here's the layout:
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 | Sub-Type | LLA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
138 (skippable) [1] - when used in Registration Requests
140 (skippable) [1] - when used in Agent Advertisements
Length
The length of the Link Layer Address + the one-octet Sub-Type
field
Sub-Type
This field contains the Link Layer sub-type identifier
LLA
Contains the Link Layer AddressIn this document, seven sub-types are defined:
1 3GPP2 International Mobile Station Identity and
Connection ID [13]
2 3GPP International Mobile Subscriber Identity [15]
3 Ethernet 48-bit MAC address [5]
4 64-bit Global ID, EUI-64 [6]
5 Solicited IPv4 Address
6 Access Point Identifier
7 FA IPv4 AddressThe following subsections describe the extensions 🦋
9.1. 3GPP2 IMSI Link Layer Address and Connection ID Extension 💖
the IMSI Link Layer Address Extension carries the International Mobile Station Identity (IMSI) 🪄
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 | Sub-Type | IMSI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
1 (skippable) [1]
Length
The length of the IMSI field + the one-octet Sub-Type field
Sub-Type
1
IMSI
Contains the IMSI, in the form:
<IMSI>:<Connection Id>
Where the <IMSI> is an ASCII-based representation of the
International Mobile Station Identity, most significant
digit first, ":" is ASCII 0x3a, and the Connection ID is the
ASCII representation of a small, decimal number used for
distinguishing different link-layer connections from the
same mobile device.9.2. 3GPP IMSI Link Layer Address Extension ✨
okay bestie, this one carries the IMSI (International Mobile Station Identity) 📱 and it's giving very organized. Here's how it's laid out:
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 | Sub-Type | IMSI ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type
2 (skippable) [1]
- Length
- The length of the IMSI field + the one-octet Sub-Type field 🎀
- Sub-Type
2
- IMSI
- Contains the IMSI, a number composed of 15 digits or less, coded as described in [15]. 🌸
9.3. Ethernet Link Layer Address Extension 🦋
the Ethernet one is literally the 48-bit Ethernet MAC Address as defined in [5], so no surprises here. same shape, different payload 💅
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 | Sub-Type | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type
3 (skippable) [1]
- Length
7(includes the Sub-Type field)
- Sub-Type
3
- MAC
- Contains the 48-bit Ethernet MAC Address. 🍓
9.4. IEEE 64-Bit Global Identifier (EUI-64) Address Extension 🧚
this one holds the 64-bit Global Identifier (EUI-64) address, as defined in [6]. it's the bigger sibling of the MAC one, and honestly iconic ✨
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 | Sub-Type | MAC ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type
4 (skippable) [1]
- Length
9(includes the Sub-Type field)
- Sub-Type
4
- MAC
- Contains the 64-bit Global Identifier Address. 💜
9.5. Solicited IPv4 Address Extension 🌈
the 32-bit Solicited IPv4 Address Extension holds the IPv4 address of the agent (FA) being solicited. this one MAY show up in an ICMP Agent Solicitation, as explained in Section 3.3. the vibes are very "I'm looking for YOU" 🙈
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 | Sub-Type | IPv4 addr ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type
5 (skippable) [1]
- Length
5(includes the Sub-Type field)
- Sub-Type
5
- IPv4 Address
- Contains the 32-bit IPv4 Address of the solicited node.
9.6. Access Point Identifier Extension 📶
the 32-bit Access Point Identifier Extension carries an identifier of the access point the MN will move to. this may be a wireless L2 identifier. with this extension in Agent Solicitations (see Section 3.3), the MN is able to solicit an advertisement from the FA servicing a certain access point. main character move, no cap 👑
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 | Sub-Type | AP ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type
6 (skippable) [1]
- Length
5(includes the Sub-Type field)
- Sub-Type
6
- AP ID
- Contains the 32-bit Access Point Identifier.
9.7. FA IPv4 Address Extension 🎀
the 32-bit FA IPv4 Address Extension holds the IPv4 address of the agent (FA). this extension MAY be in a Registration Request message to identify the oFA, as explained in Section 5. it's the name tag that says "hi, it's me" 💖
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 | Sub-Type | IPv4 addr ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type
7 (skippable) [1]
- Length
5(includes the Sub-Type field)
- Sub-Type
7
- IPv4 Address
- Contains the 32-bit IPv4 Address of the FA node.
10. IANA Considerations 📋
okay so IANA gets a little homework here 🫶 this document defines one new extension to Mobile IPv4 Control messages and one new extension to Mobile IPv4 Router Discovery messages that IANA already maintains. it also defines a new Mobile IPv4 Control message type to be used between FAs. to make sure interoperation actually works based on this spec, IANA must reserve values in the Mobile IPv4 number space for two new extensions and one new message type. IANA must also manage the numbering spaces created by the two new extensions, the message type, and its associated Code field. very organized, very iconic 💅
10.1. New Extension Values ✨
Section 9 introduces two extensions:
- Generalized Link Layer and IPv4 Address (LLA) Extension for Router Discovery messages: a new Mobile IPv4 extension that follows after Mobile IPv4 ICMP Router Discovery messages (e.g., Mobile IP Agent Advertisements). its type value belongs to the Mobile IPv4 number space for Router Discovery messages that IANA maintains, and the value assigned by IANA is 140. this new extension uses the Link Layer and IPv4 Address Identifier (LLA) sub-type numbering space, which requires IANA management (see Section 10.2). 🌸
- Generalized Link Layer and IPv4 Address (LLA) Extension for Mobile IP Control messages: a new Mobile IPv4 extension appended to Mobile IP Control messages (e.g., Registration Request). its type value belongs to the Mobile IPv4 number space for extensions to Mobile IPv4 Control messages that IANA maintains. it MUST be in the skippable (128-255) range as defined in [1]. the value assigned is 138 by IANA. this new extension uses the Link Layer and IP Address Identifier (LLA) sub-type numbering space, which requires IANA management (see Section 10.2). 🦋
10.2. Generalized Link Layer and IP Address Identifier (LLA) Sub-type Values 🌈
this section covers the sub-type values that apply to both the Generalized LLA Extensions for Mobile IP Control and Router Discovery messages. this specification uses sub-type values 1-7, and every other value besides zero (reserved) is available for assignment via IETF consensus [14]. the seven sub-type values defined in this specification are:
1 3GPP2 International Mobile Station Identity and
Connection ID [13]
2 3GPP International Mobile Subscriber Identity [15]
3 Ethernet 48-bit MAC address [5]
4 64-bit Global ID, EUI-64 [6]
5 Solicited IPv4 Address
6 Access Point Identifier
7 FA IPv4 Address10.3. New Message Type and Code 🧚
Sections 4.5 and 4.6 define two new Mobile IPv4 message types: Handoff Request and Handoff Reply. these need two type numbers assigned by IANA from the Mobile IPv4 Control message type address space. the Handoff Reply message also brings its own Code field, which means IANA has to manage a new Code address space for it. this specification uses the Code values 0-1, where 0 identifies a successful handoff and 1 defines a generic handoff failure. every other value is available for assignment via IETF consensus [14]. 💖
Code Values for Mobile IP Handoff Reply Messages:
0 Successful Handoff
1 Generic Handoff Failure
2-255 Unallocated11. Security Considerations 🔐💅
okay bestie, this section is serious 😭 but we're gonna get through it together 🫶
So for PRE-REGISTRATION (the one from Section 3.8 🎀), the oFA and nFA MUST share a security association so they can authenticate and integrity protect the messages going between them ✨ Also, the oFA has to be authorized to solicit the nFA based on that security association. The bare minimum to set one up is that both FAs support manual pre-configuration of security associations using shared keys 🔑 Other ways to set one up with IKE [16], based on shared secrets or public keys, can be used too. The inter-FA ICMP messages (solicitations and advertisements) MUST be authenticated and integrity protected using ESP [10]. The default ESP authentication algorithm for this spec is HMAC-SHA1-96 [12]. Without all this, malicious nodes at any distance from the FA could launch denial-of-service attacks 🙅 To secure Registration Request and Reply messages, PRE-REGISTRATION uses the security mechanisms already described in [1] and optionally [11].
POST-REGISTRATION is giving new twist 🌀 It's the possibility that an MN gets packets from an FA it hasn't done a Mobile IPv4 Registration with yet. It is not recommended that the MN drop packets from unknown FAs, since that would basically wipe out the perks of POST-REGISTRATION 🙃 Security-wise, dropping them wouldn't really protect the MN from any attack. Any malicious host can use the MN's home address to send packets to the MN through its current known FA, so handling packets from unknown FAs isn't any less secure than normal Mobile IPv4 🛡️
Same energy as PRE-REGISTRATION here: in POST-REGISTRATION, oFA and nFA MUST share a security association required to protect the Handoff Request and Reply messages. The minimal requirement is that the FAs support manual pre-configuration of security associations involving shared keys. Other IKE [16] mechanisms based on shared secrets or public keys may also be used. The Handoff Request and Reply messages MUST be authenticated using the FA-FA authentication extension [11] that uses the default algorithm specified in [7]. Without this, impersonation attacks and denial-of-service attacks would be possible 😱
The minimal requirement is that all FAs involved in low latency handoffs MUST support manual pre-configuration of peer-to-peer security associations with neighboring FAs, involving shared secrets, and are already required to support the default algorithms of [1]. Other IKE [16] mechanisms based on shared or public keys may also be used 💜
Since the techniques in this doc depend on particular L2 information (triggers) to optimize performance, some level of L2 security is assumed 🔒 Both PRE- and POST-REGISTRATION depend on L2 triggers, but the L2 security implications are different for the two.
In POST-REGISTRATION specifically, the L2 triggers start setting up tunnels that route IPv4 packets for the MN to its new location. So the L2 triggers MUST be secured against any tampering by malicious nodes, whether they're mobile or sitting in the wired network 🚨 The L2 addresses or IPv4 addresses for the MN and the FAs that appear in the L2 triggers MUST correspond to the actual nodes participating in the handoff. If tampering is possible at all, the recipient of an L2 trigger MUST have some way of authenticating the L2 information. Wireless networks without these features are open to impersonation attacks, where malicious nodes could make FAs think an MN has moved to other service areas, or let a bogus MN get unauthorized service from an FA before doing a Mobile IPv4 Registration. In POST-REGISTRATION, L2 triggers would typically be sent between a wireless base station and the FA. No standard protocol exists yet to communicate L2 trigger information, but it's important that any future one provides adequate security 🛠️ If the wireless base station and FA were integrated, this threat wouldn't apply. Also, the layer 2 control messages on the wireless link must be secured appropriately, so a malicious node can't run impersonation attacks and cause unwanted L2 triggers to be generated. Integrity and replay protection would be required to avoid impersonation threats and resource consumption threats, where a malicious node replays old messages to eat up resources. This depends on the type of L2 security on the wireless link. For example, in cellular technologies the control messages are secured, although the type of security varies by cellular standard. This is typically not the case in WLAN IEEE 802.11 networks.
In PRE-REGISTRATION, the security of L2 triggers has different implications. PRE-REGISTRATION depends on Mobile IPv4 security between MN and FA, so the same security considerations in [1] apply. Should malicious nodes be able to generate or modify L2 trigger information (i.e., L2-ST or L2-TT), this would cause advertisements to be sent to the MN. They would consume wireless resources and processing in the MN, but would not allow an impersonation attack. To prevent such denial-of-service attacks, there should be a limit on the number of advertisements that an FA (oFA) will relay to the MN as a result of receiving L2 triggers. This number depends on the L2 technology, and the default limit is 10 per second.
12. Acknowledgements 🌸
The authors want to thank Lennart Bang, Bryan Hartwell, Joel Hortelius, Gianluca Verin, and Jonathan Wood for valuable comments and suggestions on the whole document 💖 The authors also thank the Mobile IPv4 WG chairs, Phil Roberts and Basavaraj Patil, for their input 🧚
13. References 📚
13.1. Normative References
- [1] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [3] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
- [4] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
- [5] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
- [6] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority",
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. - [7] Perkins, C., Calhoun, P., and J. Bharatia, "Mobile IPv4 Challenge/Response Extensions (Revised)", RFC 4721, January 2007.
- [8] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
- [9] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
- [10] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [11] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 Regional Registration", RFC 4857, June 2007.
- [12] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
13.2. Informative References
- [13] TIA/EIA/IS-2000.
- [14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [15] 3GPP TS 23.003 (www.3gpp.org).
- [16] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
Appendix A - Gateway Foreign Agents 🧚✨
The Mobile IPv4 Regional Registration specification [11] introduces the Gateway Foreign Agent (GFA). It's a mobility agent that two FAs providing service to an MN have in common 🌈 Figure A.1 shows an example of an MN's initial registration through the GFA. If this is the first registration message, the message MUST be forwarded to the HA. All packets sent to the MN will be delivered to the GFA, which in turn forwards them to the FA servicing the MN.
RegReq +-----+ RegReq
+----------->| oFA |--------------+
| +-----+ |
| v
+----+ +-----+ RegReq +----+
| MN | | GFA |<------->| HA |
+----+ +-----+ +----+
+-----+
| nFA |
+-----+Figure A.1 - Initial Registrations through GFA
If the MN moves to an nFA that is serviced by a GFA common with oFA, the MN MAY issue a Regional Registration Request (see Figure A.2). The Regional Registration message doesn't need to be forwarded to the HA, since the MN's traffic can still be delivered to the same GFA. This optimized approach effectively reduces the latency involved in the registration process 🦋
+-----+
| oFA |
+-----+
+----+ +-----+ +----+
| MN | | GFA | | HA |
+----+ +-----+ +----+
| ^
| +-----+ |
+------------>| nFA |-------------+
RegRegReq +-----+ RegRegReqFigure A.2 - Regional Registration through GFA
Note that the GFA may also be the MN's first-hop router. 💜
Appendix B - Low-Latency Handoffs for Multiple-Interface MNs ✨
okay so this one's for MNs with two wireless interfaces 📱📱 (same network or different L2 techs, doesn't matter). if the Mobile IPv4 stack lets you switch an IPv4 address binding between interfaces, the stuff in this doc may be unnecessary 💅 this appendix is about how multiple interfaces can help with low-latency handoff. main character energy 🦋
+------+ +---------+
| HA |--------| (GFA) |
+------+ +---------+
/ \
... ...
/ \
/ \
+------+ +------+
| oFA | | nFA |
+------+ +------+
| |
+------+ +------+
| RN1 | | RN2 |
+------+ +------+
+------+
| MN | --------->
+------+
Movement
Figure B.1 - Network Model for Mobile IPv4 with Multi-AccessFigure B.1 shows the normal and hierarchical MIPv4 models 🌸 so picture this: the MN is hooked up to Radio Network 1 (RN1) and registered with oFA, which is the one actually delivering its traffic. then the MN wanders into the coverage area of RN2 and nFA 🚶♀️ and it prefers that network for reasons outside this doc's scope (user prefs, cost, available QoS, whatever). the MN turns on the RN2 interface but keeps talking through RN1 🎀 it can ask nFA for advertisements through the RN1 interface to speed things up, as long as there's no TTL restriction. or it can ask through the RN2 interface if that's been configured for IPv4 traffic.
once the MN is registered with nFA and sending and receiving over the new network ✨ it tears down the RN1 interface. if it has enough time to do all that without degraded service or getting disconnected, it gets a seamless multi-access handoff 🫶 but that's not guaranteed everywhere, because of network coverage or other reasons 😭 and if multiple-interface handoff works out, the low-latency methods in this doc aren't needed at all 💖
btw, to protect against the new connection (RN2/nFA) failing in the short window right after handoff 🙈 the MN may use the S bit in its Mobile IPv4 Registration Request to keep simultaneous bindings alive: the existing one (HA or GFA) with oFA, and a new one with nFA. backup plan era 👑
Appendix C - PRE-REGISTRATION Message Summary 🧚
this appendix is your cheat sheet 📝 for which IPv4 and layer 2 addresses go in PRE-REGISTRATION messages.
Proxy Router Advertisement (PrRtAdv) 📢
This is a standard Router/Agent Advertisement [1] with the following characteristics:
- Source IPv4 Address: nFA IPv4 Address
- Source Layer 2 Address: oFA L2 Address
- Destination IPv4 Address: MN IPv4 Address (from PrRtSol)
- Destination Layer 2 Address: MN L2 Address (from PrRtSol)
- LLA Extension (defined in this spec): containing nFA Layer 2 Address.
Proxy Router Solicitation (PrRtSol) 🙋♀️
This is a standard Router/Agent Solicitation [1] with the following characteristics:
- Source IPv4 Address: MN Address
- Source Layer 2 Address: MN Address
- Destination IPv4 Address: oFA Address (from source address of previous Router Advertisement or PrRtAdv)
- Destination Layer 2 Address: oFA Address (from source address of previous Router Advertisement or PrRtAdv LLA)
- LLA Extension (defined in this spec): depends on the layer 2 technology (e.g., typically for WLAN, this would be the BSSID of the new WLAN Access Point)
Registration Request (as seen on MN-oFA link) 📨
This is a Mobile IPv4 Registration Request message [1] with the following characteristics:
- Source IPv4 Address: MN Address
- Source Layer 2 Address: MN Address
- Destination IPv4 Address: nFA Address (from source addr of PrRtAdv)
- Destination Layer 2 Address: Default Router (i.e., oFA Address)
- LLA Extension (defined in this spec): containing the MN's L2 address that must be used by nFA. This will typically be an Ethernet MAC address but other types can be used as specified in Section 9 of this document.
it's not mandated 🤷♀️ but an MN implementation may set the S bit (see Section 6) in Registration Request messages. that can help the handoff and dodge problems from failed layer 2 handoffs and layer 2 ping-pong effects between two base stations 🏓
Registration Reply (as seen on oFA-MN link) 💌
This is a Mobile IPv4 Registration Reply message [1] with the following characteristics:
- Source IPv4 Address: nFA Address
- Source Layer 2 Address: oFA Address
- Destination IPv4 Address: MN Address (from source of Registration Request)
- Destination Layer 2 Address: MN Address (from source of Registration Request)
Contributing Authors 🫶
Pat Calhoun Cisco Systems EMail: pcalhoun@cisco.com
Tom Hiller Lucent Technologies EMail: tom.hiller@lucent.com
James Kempf NTT DoCoMo USA Labs EMail: kempf@docomolabs-usa.com
Peter J. McCann Motorola Labs EMail: pete.mccann@motorola.com
Ajoy Singh Motorola EMail: asingh1@email.mot.com
Hesham Soliman Elevate Technologies EMail: Hesham@elevatemobile.com
Sebastian Thalanany US Cellular EMail: Sebastian.thalanany@uscellular.com
Editor's Address 💅
Karim El Malki Athonet EMail: karim@athonet.com
Full Copyright Statement ⭐
the legal bit, kept complete 📜
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🌈
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🍓
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc4881 2007-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms