RFC 5568
Mobile IPv6 Fast Handovers
RFC 5568: Mobile IPv6 Fast Handovers 🦋
Okay bestie, let's do the paperwork first 📜. This is RFC 5568, Mobile IPv6 Fast Handovers, from the Network Working Group. R. Koodli, Ed. of Starent Networks wrote it, and it was published in July 2009 as a Standards Track doc 💅. It obsoletes RFC 5268, so 5268 is officially retired 🙈. It also updates the packet formats for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages, switching them over to the Mobility Header Type ✨.
Abstract 🌸
Okay so Mobile IPv6 lets a mobile node (MN) stay connected to the Internet when it moves from one Access Router to another, and that move is called a handover 🚗. The thing is, during a handover there's a window where the mobile node can't send or receive packets, because of link-switching delay and IP protocol operations 😭. That "handover latency" comes from the standard Mobile IPv6 steps: movement detection, new Care-of Address configuration, and Binding Update. It's often way too slow for real-time traffic like Voice over IP (VoIP) 📞. Non-real-time, throughput-sensitive apps would also feel the difference if the latency went down ✨.
This doc specifies a protocol that cuts down the handover latency caused by Mobile IPv6 procedures 🔥. It does not try to fix the link-switching latency, so keep that in mind 🙈.
It also updates the packet formats for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages to the Mobility Header Type 🦋.
Status of This Memo 💅
This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.
Copyright Notice 🫶
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved ✨.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they're in effect on the date of publication. You can find them at http://trustee.ietf.org/license-info. Please read these carefully, because they spell out your rights and restrictions for this document 📜.
Table of Contents 🦋
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Protocol Overview ...............................................6
3.1. Addressing the Handover Latency ............................6
3.2. Protocol Operation .........................................8
3.3. Protocol Operation during Network-Initiated Handover ......11
4. Protocol Details ...............................................12
5. Other Considerations ...........................................16
5.1. Handover Capability Exchange ..............................16
5.2. Determining New Care-of Address ...........................16
5.3. Prefix Management .........................................17
5.4. Packet Loss ...............................................17
5.5. DAD Handling ..............................................19
5.6. Fast or Erroneous Movement ................................19
6. Message Formats ................................................20
6.1. New Neighborhood Discovery Messages .......................20
6.1.1. Router Solicitation for Proxy Advertisement
(RtSolPr) ..........................................20
6.1.2. Proxy Router Advertisement (PrRtAdv) ...............22
6.2. New Mobility Header Messages ..............................26
6.2.1. Inter - Access Router Messages .....................26
6.2.2. Fast Binding Update (FBU) ..........................29
6.2.3. Fast Binding Acknowledgment (FBack) ................31
6.3. Unsolicited Neighbor Advertisement (UNA) ..................33
6.4. New Options ...............................................34
6.4.1. IP Address/Prefix Option ...........................34
6.4.2. Mobility Header IP Address/Prefix Option ...........35
6.4.3. Link-Layer Address (LLA) Option ....................36
6.4.4. Mobility Header Link-Layer Address (MH-LLA)
Option .............................................37
6.4.5. Binding Authorization Data for FMIPv6 (BADF) .......38
6.4.6. Neighbor Advertisement Acknowledgment (NAACK) ......39
7. Related Protocol and Device Considerations .....................40
8. Evolution from and Compatibility with RFC 4068 .................40
9. Configurable Parameters ........................................41
10. Security Considerations .......................................42
10.1. Peer Authorization Database Entries When Using IKEv2 .....44
10.2. Security Policy Database Entries .........................44
11. IANA Considerations ...........................................45
12. Acknowledgments ...............................................47
13. References ....................................................47
13.1. Normative References .....................................47
13.2. Informative References ...................................48
Appendix A. Contributors ..........................................50
Appendix B. Changes since RFC 5268 ................................50
Appendix C. Changes since RFC 4068 ................................501. Introduction 💖
Okay so Mobile IPv6 [RFC3775] lays out how a mobile node keeps its Internet connection while it hands over from one access router to another 🚗. All of that involves link-layer procedures, movement detection, IP address configuration, and location updates 📍. Put together, the handover latency is often enough to mess with real-time apps 😭. Throughput-sensitive apps can also get a boost from less latency ✨. This doc describes a protocol to reduce that handover latency 🔥.
This spec tackles two problems. First, how to let a mobile node send packets as soon as it detects a new subnet link. Second, how to deliver packets to a mobile node as soon as the new access router notices it's attached 🦋. The protocol defines the IP protocol messages it needs no matter what link technology is in use 💅. It doesn't depend on specific link-layer features, but it still allows link-specific customizations 🌈. By definition, this spec covers handovers that interwork with Mobile IP 🧚. Once the MN is attached to its new access router, it goes through its usual Mobile IP operations, including Return Routability [RFC3775] 🫶. Nothing special is needed here, since the mobile node doesn't have to act differently from its standard Mobile IP behavior 🌸.
This spec applies when a mobile node has to do IP-layer operations because of handovers 💫. It does not address improving the link-switching latency 🙈. It also doesn't change or optimize the signaling with the mobile node's home agent 🏠. Even though it's aimed at Mobile IPv6, it could work with any mechanism that keeps communication going despite movement 🔥. Last but not least, this spec doesn't cover bulk movement of nodes using aggregate prefixes 💅.
This document updates the protocol header format for the Handover Initiate (HI) and Handover Acknowledge (HAck) messages defined in [RFC5268] ✨. Both the Proxy Mobile IPv6 (PMIPv6) protocol [RFC5213] and the Mobile IPv6 protocol use the Mobility Header (MH) type for carrying signaling related to route updates 📡. Here's the twist: the Fast Handover protocol uses the Mobility Header for mobile node signaling, but it has been using ICMP for inter - access router communication 🙃. Specifying the Mobility Header for the HI and HAck messages lets this protocol be deployed alongside PMIP6 and MIP6 🦋. The reasons behind that change are in Appendix B 📖. So this document specifies the Mobility Header formats for HI and HAck messages (Section 6.2.1), and the Mobility Header option format for the IPv6 Address/Prefix option (Section 6.4.2) 💖. It also deprecates using ICMP for HI and HAck messages 🚫.
Heads up, this part is important 🚨: Implementations of this specification MUST NOT send ICMPv6 HI and HAck messages as defined in [RFC5268] 🙅♀️. If implementations of this specification receive ICMPv6 HI and HAck messages as defined in [RFC5268], they MAY interpret the messages as defined in [RFC5268] 🫶. Translation: don't send the old ICMP version, but if you get one, you're allowed to read it the old way 🌈.
2. Terminology ✨
Okay bestie, first up is the vocab, and it's a whole thing 💅. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The phrase "silently ignore" isn't defined in RFC 2119 🙈. But it shows up in this document, so it should be read in a similar way.
The terms and abbreviations below are used in this document on top of the ones defined in [RFC3775]. The reference handover scenario is in Figure 1 🦋.
v +--------------+
+-+ | Previous | <
| | ------------ | Access | ------- >-----\
+-+ | Router | < \
MN | (PAR) | \
| +--------------+ +---------------+
| ^ IP | Correspondent |
| | Network | Node |
V | +---------------+
v /
v +--------------+ /
+-+ | New | < /
| | ------------ | Access | ------- >-----/
+-+ | Router | <
MN | (NAR) |
+--------------+
Figure 1: Reference Scenario for HandoverMobile Node (MN): A Mobile IPv6 host 📱
Access Point (AP): A Layer 2 device connected to an IP subnet that offers wireless connectivity to an MN. An Access Point Identifier (AP-ID) refers to the AP's L2 address. Sometimes, AP-ID is also referred to as a Basic Service Set IDentifier (BSSID) 🌸
Access Router (AR): The MN's default router 🧚
Previous Access Router (PAR): The MN's default router prior to its handover 🌙
New Access Router (NAR): The MN's anticipated default router subsequent to its handover ☀️
Previous CoA (PCoA): The MN's Care-of Address valid on PAR's subnet 🎀
New CoA (NCoA): The MN's Care-of Address valid on NAR's subnet 💜
Handover: A process of terminating existing connectivity and obtaining new IP connectivity. It's giving glow-up 🦋
Router Solicitation for Proxy Advertisement (RtSolPr): A message from the MN to the PAR requesting information for a potential handover 💌
Proxy Router Advertisement (PrRtAdv): A message from the PAR to the MN that provides information about neighboring links, facilitating expedited movement detection. The message can also act as a trigger for network-initiated handover ✨
[AP-ID, AR-Info] tuple: Contains an access router's L2 and IP addresses, and the prefix valid on the interface to which the Access Point (identified by AP-ID) is attached. The triplet [Router's L2 address, Router's IP address, and Prefix] is called "AR-Info". See also Section 5.3 🍓
Neighborhood Discovery: The process of resolving neighborhood AP-IDs to AR-Info 🗺️
Assigned Addressing: A particular type of NCoA configuration in which the NAR assigns an IPv6 address for the MN. The method by which the NAR manages its address pool is not specified in this document 🫶
Fast Binding Update (FBU): A message from the MN instructing its PAR to redirect its traffic (toward NAR) 🚀
Fast Binding Acknowledgment (FBack): A message from the PAR in response to an FBU 💖
Predictive Fast Handover: The fast handover in which an MN is able to send an FBU when it is attached to the PAR, which then establishes forwarding for its traffic (even before the MN attaches to the NAR). Predictive is giving planner energy 🗓️
Reactive Fast Handover: The fast handover in which an MN is able to send the FBU only after attaching to the NAR 🏃♀️
Unsolicited Neighbor Advertisement (UNA): The message in [RFC4861] with the 'O' bit cleared 🔥
Fast Neighbor Advertisement (FNA): This message from RFC 4068 [RFC4068] is deprecated. The UNA message above is the preferred message in this specification. So FNA is retired, UNA is the main character now 👑
Handover Initiate (HI): A message from the PAR to the NAR regarding an MN's handover 📨
Handover Acknowledge (HAck): A message from the NAR to the PAR as a response to HI 📬
3. Protocol Overview 🌈
3.1. Addressing the Handover Latency
Okay so the big question is how fast can the MN actually send packets from a brand new subnet. That depends on the "IP connectivity" latency, which depends on the movement detection latency plus the new CoA configuration latency 😭. Once an MN is IP-capable on the new subnet link, it can send a Binding Update to its Home Agent and one or more correspondents. Once its correspondents process the Binding Update successfully (which typically involves the Return Routability procedure), the MN can receive packets at the new CoA. So being able to receive packets from correspondents directly at the new CoA depends on the Binding Update latency as well as the IP connectivity latency 💅.
The protocol lets an MN quickly figure out that it has moved to a new subnet, by handing it the new access point and the associated subnet prefix information while it's still connected to its current subnet (i.e., PAR in Figure 1) ✨. For instance, an MN may discover available access points using link-layer-specific mechanisms (e.g., a "scan" in a Wireless Local Area Network (WLAN)) and then request subnet information for one or more of those discovered access points. The MN may do this after performing router discovery, or at any time while connected to its current router 🔍. The result of resolving an identifier associated with an access point is an [AP-ID, AR-Info] tuple, which an MN can use to detect movement pretty easily. When attachment to an access point with AP-ID takes place, the MN knows the corresponding new router's coordinates, including its prefix, IP address, and L2 address 📍. The "Router Solicitation for Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement (PrRtAdv)" messages in Section 6.1 are used for aiding movement detection.
Through the RtSolPr and PrRtAdv messages, the MN also formulates a prospective new CoA (NCoA) while it's still on the PAR's link 🧠. So the latency from new prefix discovery after the handover is eliminated, which is iconic 🙌. Also, this prospective address can be used right after attaching to the new subnet link (i.e., NAR's link) when the MN has received a "Fast Binding Acknowledgment (FBack)" (see Section 6.2.3) message before it moved 🎯. If it moves without receiving an FBack, the MN can still start using NCoA after announcing its attachment through an unsolicited Neighbor Advertisement message (with the 'O' bit set to zero) [RFC4861]. The NAR responds to this UNA message in case it wants to provide a different IP address to use 🔄. This way, NCoA configuration latency gets reduced 🌸.
The information in the PrRtAdv message can still be used even when DHCP [RFC3315] is used to configure an NCoA on the NAR's link 🎀. In this case, the protocol supports forwarding using PCoA, and the MN performs DHCP once it attaches to the NAR's link. The MN still formulates an NCoA for FBU processing; however, it MUST NOT send data packets using the NCoA in the FBU 🚫. Not that deep, but it's important!
To reduce the Binding Update latency, the protocol specifies a binding between the Previous CoA (PCoA) and NCoA 🔗. An MN sends a "Fast Binding Update" (see Section 6.2.2) message to its Previous Access Router to establish this tunnel. When feasible, the MN SHOULD send an FBU from the PAR's link. Otherwise, the MN should send the FBU immediately after detecting attachment to the NAR 🏃♀️. An FBU message MUST contain the Binding Authorization Data for FMIPv6 (BADF) option (see Section 6.4.5) so that only a legitimate MN that owns the PCoA is able to establish a binding 🔐. Later sections describe the protocol mechanics. Either way, the result is that the PAR begins tunneling packets arriving for PCoA to NCoA 💫. That tunnel stays active until the MN completes the Binding Update with its correspondents. In the opposite direction, the MN SHOULD reverse tunnel packets to the PAR, again until it completes the Binding Update. And the PAR MUST forward the inner packet in the tunnel to its destination (i.e., to the MN's correspondent) 📦. This reverse tunnel makes sure packets with a PCoA as their source IP address don't get dropped due to ingress filtering 🛡️. Even though the MN is IP-capable on the new link, it can't use the NCoA directly with its correspondents until they first set up a binding cache entry (for the NCoA). So forwarding support for the PCoA is provided through a reverse tunnel between the MN and the PAR 🤝.
Setting up a tunnel alone doesn't guarantee the MN gets packets as soon as it's attached to a new subnet link, unless the NAR can detect the MN's presence 👀. A neighbor discovery operation involving address resolution (i.e., Neighbor Solicitation and Neighbor Advertisement) typically causes a lot of delay, sometimes lasting multiple seconds 😩. For instance, when arriving packets trigger the NAR to send Neighbor Solicitation before the MN attaches, the retransmissions of address resolution are separated by a default period of one second each. To get around this delay, an MN announces its attachment right away with a UNA message, which lets the NAR forward packets to the MN immediately 🚀. Between the tunnel setup for PCoA and the fast advertisement, the protocol provides expedited forwarding of packets to the MN 💖.
The protocol also provides some other important functionalities 🌟. The access routers can exchange messages to confirm that a proposed NCoA is acceptable. For instance, when an MN sends an FBU from the PAR's link, FBack can be delivered after the NAR considers the NCoA acceptable for use. This is especially useful when addresses are assigned by the access router 🏠. The NAR can also rely on its trust relationship with the PAR before providing forwarding support for the MN. That is, it may create a forwarding entry for the NCoA, subject to "approval" from the PAR, which it trusts 🤍. Buffering for handover traffic at the NAR may also be desirable 🧺. Even though the Neighbor Discovery protocol provides a small buffer (typically one or two packets) for packets awaiting address resolution, this buffer may be inadequate for traffic already in progress, such as VoIP 📞. The routers may also wish to maintain a separate buffer for servicing the handover traffic. Finally, the access routers could transfer network-resident contexts, such as access control, Quality of Service (QoS), and header compression, in conjunction with handover (although the context transfer process itself is not specified in this document) 🎁. For all these operations, the protocol provides "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages (see Section 6.2.1). Both of these messages SHOULD be used. The access routers MUST have the necessary security association established by means outside the scope of this document 🔒.
3.2. Protocol Operation ✨
okay bestie, so the whole thing kicks off when an MN sends an RtSolPr message to its access router 🎀 to resolve one or more Access Point Identifiers into subnet-specific info. The access router (like the PAR in Figure 1) answers with a PrRtAdv message holding one or more [AP-ID, AR-Info] tuples 💅. The MN can send an RtSolPr whenever it wants, like when some link-specific event happens (a "trigger") or just after doing router discovery 🦋. BUT the expectation is that before the MN sends an RtSolPr, it has already found the available APs using link-specific methods, so it's not just guessing 🙈. And the RtSolPr and PrRtAdv messages don't create any state at the access router, which is so clean 🫶. Their packet formats are in Section 6.1.
Next, with the info from the PrRtAdv, the MN comes up with a prospective NCoA and sends an FBU message to the PAR 💖. The whole point of the FBU is to authorize the PAR to bind the PCoA to the NCoA, so arriving packets can get tunneled to the MN's new location 🌸. The FBU SHOULD be sent from the PAR's link whenever that's feasible 🌈. For example, an internal link-specific trigger could make the FBU go out from the previous link ✨.
When that's NOT feasible, the FBU gets sent from the new link 🧚.
The FBU processing format and semantics are specified in Section 6.2.2 💜. The FBU MUST contain the BADF option (see Section 6.4.5) to secure the message 🔒✨.
Now, depending on whether an FBack gets received on the previous link (which obviously depends on whether the FBU was sent in the first place 💀), there are two modes of operation 👑.
- The MN receives the FBack on the previous link. This means packet tunneling is already in progress by the time the MN handovers to the NAR 🔥. The MN SHOULD send the UNA immediately after attaching to the NAR, so arriving AND buffered packets can be forwarded to the MN right away 🦋. Before sending FBack to the MN, the PAR can figure out whether the NCoA is acceptable to the NAR through the exchange of HI and HAck messages 🎀. When Assigned Addressing (meaning the router assigns the addresses) is used, the proposed NCoA in the FBU is carried in an HI message (from PAR to NAR), and the NAR MAY assign the proposed NCoA 💅. An assigned NCoA MUST be returned in HAck (from NAR to PAR), and the PAR MUST in turn provide the assigned NCoA in FBack 🫶. If there is an assigned NCoA returned in FBack, the MN MUST use the assigned address (and NOT the proposed address in the FBU) upon attaching to the NAR 😭.
- The MN does NOT receive the FBack on the previous link, because either the MN never sent the FBU, or it left the link after sending the FBU (which itself might get lost) but before receiving an FBack 🙈. Without an FBack in that second case, the MN can't tell whether the PAR processed the FBU successfully 💀. So the MN (re)sends the FBU to the PAR immediately after sending the UNA message 🌸. If the NAR decides to supply a different IP address to use than the NCoA, it MAY send a Router Advertisement with the "Neighbor Advertisement Acknowledge (NAACK)" option, including an alternate IP address for the MN to use 🧚. Detailed UNA processing rules are in Section 6.3 💖.
The scenario where an MN sends an FBU and receives an FBack on the PAR's link is shown in Figure 2 🦋. For convenience, we call this the "predictive" mode of operation ✨. The scenario where the MN sends an FBU from the NAR's link is shown in Figure 3 🎀. We call this the "reactive" mode of operation 👑. Note that the reactive mode also covers the case where an FBU was sent from the PAR's link but no FBack has been received yet 🫶. The figure is meant to show that the FBU is forwarded through the NAR, but it's only processed by the PAR 💅.
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|----------HI--------->|
| |<--------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets ===============>|
| | |
| | |
connect | |
| | |
|------------UNA --------------------------->|
|<=================================== deliver packets
| |
Figure 2: Predictive Fast Handover MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|-------UNA-----------|--------------------->|
|-------FBU-----------|---------------------)|
| |<-------FBU----------)|
| |----------HI--------->|
| |<-------HAck----------|
| |(HI/HAck if necessary)|
| forward |
| packets(including FBAck)=====>|
| | |
|<=================================== deliver packets
| |
Figure 3: Reactive Fast HandoverFinally, the PrRtAdv message may be sent unsolicited, meaning without the MN sending an RtSolPr first 🌈. This mode is described in Section 3.3 🧚.
3.3. Protocol Operation during Network-Initiated Handover 🌸
In some wireless technologies, the handover control may live in the network, even though the decision to hand over may be mutually reached by the MN and the network 💜. In those networks, the PAR can send an unsolicited PrRtAdv containing the link-layer address, IP address, and subnet prefix of the NAR when the network decides a handover is imminent ✨. The MN MUST process this PrRtAdv to configure a new Care-of Address on the new subnet, and MUST send an FBU to the PAR prior to switching to the new link 🎀. After transmitting PrRtAdv, the PAR MUST continue to forward packets to the MN on its current link until the FBU is received 💅. The rest of the operation is the same as what's described in Section 3.2 🫶.
The unsolicited PrRtAdv also lets the network tell the MN about geographically adjacent subnets without the MN having to explicitly ask for that info 🦋. This can cut down on the amount of wireless traffic the MN needs to get a neighborhood topology map of links and subnets 🌈. Usage like this is decoupled from the actual handover, so see Section 6.1.2 🔥.
4. Protocol Details ✨
All descriptions refer to Figure 1, so keep it open in another tab, bestie 🗺️
Okay so, after the MN spots one or more nearby access points 📡, it sends RtSolPr to the PAR so it can turn those access point identifiers into subnet router info 🔍. A convenient time to do this is right after router discovery, but the MN can send RtSolPr at any time, like when new access points pop up ✨. It can even send RtSolPr more than once while it's attached to the PAR. The trigger can come from a link-specific event, like another access point promising a stronger signal while the current one's quality is fading 📉. These events are often called "L2 triggers." They're outside the scope of this document, but they still kick off this protocol 💅. For example, when a "link up" indication shows up on the new link, protocol messages (e.g., UNA) can go out immediately 🚀. Implementations SHOULD make use of such triggers whenever available.
RtSolPr carries one or more AP-IDs 🧾, and a wildcard asks for all the available tuples 🌈.
The PAR answers RtSolPr with a PrRtAdv, which tells the MN one of these possible things 👑:
- If the PAR doesn't have an entry for the new access point 🙈, it MUST reply that the new access point is unknown. The MN MUST stop fast handover protocol operations on the current link. The MN MAY send an FBU from its new link 💖.
- If the new access point is connected to the PAR's current interface (the one the MN is attached to), the PAR MUST respond with a Code value saying the new access point is connected to the current interface, but it won't send any prefix information. This could happen, for example, when several wireless access points are bridged into a wired network 🌉. No further protocol action is necessary.
- If the new access point is known and the PAR has info about it, then the PAR MUST respond that the new access point is known and supply the
[AP-ID, AR-Info]tuple 🎀. If the new access point is known but doesn't support fast handover, the PAR MUST indicate this with Code 3 (see Section 6.1.2) 🙅♀️. - If a wildcard is supplied as the identifier for the new access point, the PAR SHOULD supply neighborhood
[AP-ID, AR-Info]tuples that are subject to path MTU restrictions. In other words, it should provide any'n'tuples without going over the link MTU 📏.
When further protocol action is necessary, some implementations MAY choose to start buffering copies of incoming packets at the PAR 📦. If that First In First Out (FIFO) buffering is used, the PAR MUST keep forwarding the packets to the PCoA (i.e., buffer and forward). The protocol doesn't forbid this kind of implementation support, but care must be taken to make sure the PAR keeps forwarding packets to the PCoA (i.e., uses a buffer and forward approach) 🫶. The PAR SHOULD stop buffering once it starts forwarding packets to the NCoA.
The method by which access routers swap info about their neighbors, so they can build Proxy Router Advertisements with details about neighboring subnets, is outside the scope of this document 🧚.
The RtSolPr and PrRtAdv messages MUST be implemented by an MN and by an access router that supports fast handovers. However, when the parameters the MN needs to send packets right after attaching to the NAR are supplied by the link-layer handover mechanism itself, using the messages above is optional on those links 🌸.
After a PrRtAdv is processed, the MN sends an FBU at a time decided by link-specific events, and includes the proposed NCoA 💜. The MN SHOULD send the FBU from the PAR's link whenever "anticipation" of the handover is feasible. When anticipation isn't feasible, or when no FBack has been received, the MN sends an FBU immediately after attaching to the NAR's link 🏃♀️. In response to the FBU, the PAR sets up a binding between the PCoA ("Home Address") and the NCoA, and sends the FBack to the MN 🦋. Before setting up this binding, the PAR SHOULD send an HI message to the NAR and receive a HAck in response. To figure out the NAR's address for the HI message, the PAR can do the longest prefix match of the NCoA (in the FBU) against the prefix list of neighboring access routers 🔎. When the source IP address of the FBU is the PCoA, i.e., the FBU was sent from the PAR's link, the HI message MUST have a Code value set to 0; see Section 6.2.1.1. When the source IP address of the FBU is not the PCoA, i.e., the FBU was sent from the NAR's link, the HI message MUST have a Code value of 1; see Section 6.2.1.1.
The HI message contains the PCoA, link-layer address, and NCoA of the MN 🎁. When an HI message with Code 0 is processed, the NAR:
- figures out whether the NCoA in the HI message is unique before it starts defending it 🕵️♀️. It sends a Duplicate Address Detection (DAD) probe [RFC4862] for the NCoA to check uniqueness. However, in deployments where the chance of address collisions is considered extremely low (so it's not really an issue), the parameter
DupAddrDetectTransmits(see [RFC4862]) is set to zero on the NAR, so it can skip DAD on the NCoA 😌. The NAR does the same thing, settingDupAddrDetectTransmitsto zero, in other deployments where DAD isn't a concern. Once the NCoA is confirmed unique, the NAR starts proxying the address [RFC4861] forPROXY_ND_LIFETIME, which is how long the MN is expected to connect to the NAR ⏳. If there's already an NCoA in its data structure (for instance, because it processed an HI message earlier), the NAR MAY verify whether the LLA is the same as its own or the MN's own. If it is, the NAR MAY allow the use of the NCoA ✅. - allocates the NCoA for the MN when Assigned Addressing is used, creates a proxy neighbor cache entry, and begins defending it 🛡️. The NAR MAY allocate the NCoA proposed in the HI.
- MAY create a host route entry for the PCoA (on the interface the MN is attaching to) in case the NCoA can't be accepted or assigned 🛤️. This host route entry SHOULD be implemented so that, until the MN's presence is detected (through an explicit announcement by the MN or by other means), arriving packets don't invoke neighbor discovery. The NAR SHOULD also set up a reverse tunnel to the PAR in this case 🚇.
- reports the status of the handover request in the Handover Acknowledge (HAck) message to the PAR 📬.
When the Code value in the HI is 1, the NAR MUST skip the operations above 🙅♀️. Sending an HI message with Code 1 lets the NAR validate the neighbor cache entry it creates for the MN during UNA processing. In other words, the NAR can rely on the fact that its trusted peer (the PAR) has a trust relationship with the MN 🤝.
If the HAck contains an assigned NCoA, the FBack MUST include it, and the MN MUST use the address provided in the FBack 🎯. The PAR MAY also send the FBack to the previous link, to help it arrive faster in case the MN is still there 🏃. The result of the FBU and FBack processing is that the PAR starts tunneling the MN's packets to the NCoA 🎈. If the MN doesn't receive an FBack even after retransmitting the FBU for FBU_RETRIES, it must assume that fast handover support isn't available and stop the protocol operation 😭.
As soon as the MN establishes link connectivity with the NAR, it:
- sends an UNA message (see Section 6.3). If the MN hasn't received an FBack by the time the UNA goes out, it SHOULD send an FBU message right after the UNA 💌.
- joins the all-nodes multicast group and the solicited-node multicast group corresponding to the NCoA 🧑🤝🧑.
- starts a DAD probe for the NCoA; see [RFC4862] 🔬.
When a NAR receives an UNA message, it:
- deletes its proxy neighbor cache entry (if one exists), updates the state to STALE [RFC4861], and forwards arriving and buffered packets 💨.
- updates an entry in INCOMPLETE state [RFC4861] (if one exists) to STALE, and forwards arriving and buffered packets 🔄. This is the case if the NAR had previously sent a Neighbor Solicitation that went unanswered, perhaps because the MN hadn't attached to the link yet 🫠.
The buffer for handover traffic should be linked to this UNA processing. The exact mechanism is implementation dependent 🧩.
The NAR may choose to give the MN a different IP address than the NCoA. This is possible when it's proxying the NCoA. In that case, it:
- MAY send a Router Advertisement with the NAACK option, including an alternate IP address for use 💫. This message MUST be sent to the source IP address present in the UNA, using the same Layer 2 address present in the UNA.
If the MN receives an IP address in the NAACK option, it MUST use it and send an FBU using the new CoA 🙌. As a special case, the address supplied in the NAACK could be the PCoA itself. In that case, the MN MUST NOT send any more FBUs 🛑. The Status codes for the NAACK option are specified in Section 6.4.6.
Once the MN has confirmed its NCoA (either through DAD or when the NAR provided it), it SHOULD send a Neighbor Advertisement message with the 'O' bit set to the all-nodes multicast address 📣. This lets the MN's neighbors update their neighbor cache entries 💅.
For data forwarding, the PAR tunnels packets using its global IP address that's valid on the interface the MN was attached to 🌐. The MN reverse tunnels its packets to that same global address of the PAR. The tunnel end-point addresses must be configured accordingly 🔧. When the PAR receives a reverse-tunneled packet, it must verify whether a secure binding exists for the MN (identified by the PCoA in the tunneled packet) before forwarding the packet 🔐.
5. Other Considerations 🌷
5.1. Handover Capability Exchange
The MN expects a PrRtAdv in response to its RtSolPr message 💭. If the MN doesn't receive a PrRtAdv even after RTSOLPR_RETRIES, it must assume that the PAR doesn't support the fast handover protocol, and it stops sending any more RtSolPr messages 🙃.
Even if an MN's current access router can provide fast handover support, the new access router the MN attaches to may be incapable of fast handover 🥲. The MN finds this out during "runtime," through a PrRtAdv with Code 3 (see Section 6.1.2) 🚩.
5.2. Determining New Care-of Address ✨
Okay so typically the MN cooks up its prospective NCoA using the info from a PrRtAdv message, and then sends the FBU 💅. The PAR MUST use the NCoA present in the FBU in its HI message. The NAR MUST verify if the NCoA present in HI is already in use 👀. In any case, the NAR MUST respond to HI using a HAck, and in it the NAR may include another NCoA to use, especially when assigned address configuration is used. If there is a CoA present in the HAck, the PAR MUST include it in the FBack message. But the MN doesn't have to wait around on the PAR's link for this exchange, bestie 🫶. It can handover any time after sending the FBU message, and sometimes it may be forced to handover without sending the FBU at all. Either way, it can still confirm using the NCoA from the NAR's link by sending the UNA message.
If a PrRtAdv message carries an NCoA, the MN MUST use it as its prospective NCoA. 🎯
When DHCP is used, the protocol supports forwarding for the PCoA only. In this case, the MN MUST perform DHCP operations once it attaches to the NAR, even though it formulates an NCoA for transmitting the FBU. This is indicated in the PrRtAdv message with Code 5 🎀.
5.3. Prefix Management 🌸
As defined in Section 2, the Prefix part of "AR-Info" is the prefix valid on the interface to which the AP is attached. This document doesn't specify how this Prefix is managed, its length, or its assignment policies. The protocol operation specified in this document works regardless of these considerations, which is so iconic 💖. Often, but not necessarily always, this Prefix may be the aggregate prefix (such as /48) valid on the interface. In some deployments, each MN may have its own per-mobile prefix (such as a /64) used for generating the NCoA. Some point-to-point links may use such a deployment 🦋.
When per-mobile prefix assignment is used, the "AR-Info" advertised in PrRtAdv still includes the (aggregate) prefix valid on the interface to which the target AP is attached, unless the access routers communicate with each other (using HI and HAck messages) to manage the per-mobile prefix. The MN still formulates an NCoA using the aggregate prefix. However, an alternate NCoA based on the per-mobile prefix is returned by NAR in the HAck message. This alternate NCoA is provided to the MN in either the FBack message or in the NAACK option ✨.
5.4. Packet Loss 💧
Handover involves link switching, which may not be exactly coordinated with fast handover signaling. Furthermore, the arrival pattern of packets is dependent on many factors, including application characteristics, network queuing behaviors, etc. Hence, packets may arrive at the NAR before the MN is able to establish its link there. These packets will be lost unless they are buffered by the NAR. Similarly, if the MN attaches to the NAR and then sends an FBU message, packets arriving at the PAR until the FBU is processed will be lost unless they are buffered. This protocol provides an option to indicate a request for buffering at the NAR in the HI message. When the PAR requests this feature (for the MN), it SHOULD also provide its own support for buffering 🫧.
Whereas buffering can enable a smooth handover, the buffer size and the rate at which buffered packets are eventually forwarded are important considerations when providing buffering support. There are a number of aspects to consider:
- Some applications transmit less data over a given period of data than others, and this implies different buffering requirements. For instance, Voice over IP typically needs smaller buffers compared to high-resolution streaming video, as the latter has larger packet sizes and higher arrival rates 📞.
- When the mobile node appears on the new link, having the buffering router send a large number of packets in quick succession may overtax the resources of the router, the mobile node itself, or the path between these two 😭.
In particular, transmitting a large amount of buffered packets in succession can congest the path between the buffering router and the mobile node. Furthermore, nodes (such as a base station) on the path between the buffering router and the mobile node may drop such packets. If a base station buffers too many such packets, they may contribute to additional jitter for packets arriving behind them, which is undesirable for real-time communication 💀.
- Since routers are not involved in end-to-end communication, they have no knowledge of transport conditions 🙈.
- The wireless connectivity of the mobile node may vary over time. It may achieve a smaller or higher bandwidth on the new link, signal strength may be weak at the time it just enters the area of this access point, and so on 📶.
As a result, it is difficult to design an algorithm that would transmit buffered packets at appropriate spacing under all scenarios. The purpose of fast handovers is to avoid packet loss. Yet, draining buffered packets too fast can, by itself, cause loss of the packets, as well as blocking or loss of following packets meant for the mobile node. Main character problem, fr 😤.
This specification does not restrict implementations from providing specialized buffering support for any specific situation. However, attention must be paid to the rate at which buffered packets are forwarded to the MN once attachment is complete. Routers implementing this specification MUST implement at least the default algorithm, which is based on the original arrival rates of the buffered packets. A maximum of 5 packets MAY be sent one after another, but all subsequent packets SHOULD use a sending rate that is determined by metering the rate at which packets have entered the buffer, potentially using smoothing techniques such as recent activity over a sliding time window and weighted averages [RFC3290] 📊.
It should be noted, however, that this default algorithm is crude and may not be suitable for all situations. Future revisions of this specification may provide additional algorithms, once enough experience of the various conditions in deployed networks is attained 🌈.
5.5. DAD Handling 🧚
Duplicate Address Detection (DAD) was defined in [RFC4862] to avoid address duplication on links when stateless address auto-configuration is used. The use of DAD to verify the uniqueness of an IPv6 address configured through stateless auto-configuration adds delays to a handover. The probability of an interface identifier duplication on the same subnet is very low; however, it cannot be ignored 🥺. Hence, the protocol specified in this document SHOULD only be used in deployments where the probability of such address collisions is extremely low or it is not a concern (because of the address management procedure deployed). The protocol requires the NAR to send a DAD probe before it starts defending the NCoA. However, this DAD delay can be turned off by setting DupAddrDetectTransmits to zero on the NAR ([RFC4862]) ⏱️.
This document specifies messages that can be used to provide duplicate-free addresses, but the document does not specify how to create or manage such duplicate-free addresses. In some cases, the NAR may already have the knowledge required to assess whether or not the MN's address is a duplicate before the MN moves to the new subnet. For example, in some deployments, the NAR may maintain a pool of duplicate-free addresses in a list for handover purposes. In such cases, the NAR can provide this disposition in the HAck message (see Section 6.2.1.2) or in the NAACK option (see Section 6.4.6) 🗂️.
5.6. Fast or Erroneous Movement 🏃♀️
Although this specification is for fast handover, the protocol is limited in terms of how fast an MN can move. A special case of fast movement is ping-pong, where an MN moves between the same two access points rapidly. Another instance of the same problem is erroneous movement, i.e., the MN receives information prior to a handover that it is moving to a new access point, but it either moves to a different one or it aborts movement altogether. All of the above behaviors are usually the result of link-layer idiosyncrasies and thus are often resolved at the link layer itself 🔗.
IP layer mobility, however, introduces its own limits. IP-layer handovers should occur at a rate suitable for the MN to update the binding of, at least, its Home Agent and preferably that of every correspondent node (CN) with which it is in communication. An MN that moves faster than necessary for this signaling to complete (which may be of the order of a few seconds) may start losing packets. The signaling cost over the air interface and in the network may increase significantly, especially in the case of rapid movement between several access routers. To avoid the signaling overhead, the following measures are suggested 🫠.
An MN returning to the PAR before updating the necessary bindings when present on the NAR MUST send a Fast Binding Update with the Home Address equal to the MN's PCoA and a lifetime of zero to the PAR. The MN should have a security association with the PAR since it performed a fast handover to the NAR. The PAR, upon receiving this Fast Binding Update, will check its set of outgoing (temporary fast handover) tunnels. If it finds a match, it SHOULD terminate that tunnel, i.e., start delivering packets directly to the node instead. In order for the PAR to process such an FBU, the lifetime of the security association has to be at least that of the tunnel itself 🔐.
Temporary tunnels for the purposes of fast handovers should use short lifetimes (of the order of tens of seconds). The lifetime of such tunnels should be enough to allow an MN to update all its active bindings. The default lifetime of the tunnel should be the same as the lifetime value in the FBU message ⏳.
The effect of erroneous movement is typically limited to the loss of packets since routing can change and the PAR may forward packets toward another router before the MN actually connects to that router. If the MN discovers itself on an unanticipated access router, it SHOULD send a new Fast Binding Update to the PAR. This FBU supersedes the existing binding at the PAR, and the packets will be redirected to the newly confirmed location of the MN 🧭.
6. Message Formats 🦋
All the ICMPv6 messages have a common Type specified in [RFC4443]. The messages are distinguished based on the Subtype field (see below). For all the ICMPv6 messages, the checksum is defined in [RFC4443] 💜.
6.1. New Neighborhood Discovery Messages ✨
6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr) ✨
okay so mobile nodes (MNs) send Router Solicitation for Proxy Advertisement messages to nudge routers into sending back Proxy Router Advertisements 💅. All the Link-Layer Address options use the format from Section 6.4.3, so no surprises there 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: Router Solicitation for Proxy Advertisement (RtSolPr)
MessageIP Fields:
- Source Address: An IP address assigned to the sending interface.
- Destination Address: The address of the access router or the all routers multicast address.
- Hop Limit:
255. See RFC 2461.
ICMP Fields:
- Type:
154 - Code:
0 - Checksum: The ICMPv6 checksum.
- Subtype:
2 - Reserved: MUST be set to zero by the sender and ignored by the receiver.
- Identifier: MUST be set by the sender so that replies can be matched to this Solicitation.
Valid Options:
- Source Link-Layer Address: When known, the link-layer address of the sender SHOULD be included using the Link-Layer Address (
LLA) option. See the LLA option format below. - New Access Point Link-Layer Address: The link-layer address or identification of the access point for which the MN requests routing advertisement information. It MUST be included in all RtSolPr messages. More than one such address or identifier can be present. This field can also be a wildcard address. See the LLA option below.
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options that they do not recognize and continue processing the rest of the message.
Including the source LLA option lets the receiver record the sender's L2 address, so neighbor discovery can be skipped when the receiver needs to send packets back to the sender (of the RtSolPr message) 🧚
When a wildcard is used for the New Access Point LLA, no other New Access Point LLA options must be present.
A Proxy Router Advertisement (PrRtAdv) message should be received by the MN in response to an RtSolPr. If that message doesn't show up in a timely manner (no less than twice the typical round trip time (RTT) over the access link, or 100 milliseconds if RTT is not known), it SHOULD resend the RtSolPr message. Subsequent retransmissions can be up to RTSOLPR_RETRIES, but MUST use an exponential backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled prior to each instance of retransmission. If Proxy Router Advertisement is not received by the time the MN disconnects from the PAR, the MN SHOULD send an FBU immediately after configuring a new CoA 🚀
When RtSolPr messages are sent more than once, they MUST be rate-limited with MAX_RTSOLPR_RATE per second. During each use of an RtSolPr, exponential backoff is used for retransmissions. 💖
6.1.2. Proxy Router Advertisement (PrRtAdv)
access routers send Proxy Router Advertisement messages gratuitously if the handover is network-initiated, or as a response to an RtSolPr message from an MN 🦋 They provide the link-layer address, IP address, and subnet prefixes of neighboring routers. All the Link-Layer Address options have the format defined in 6.4.3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype | Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: Proxy Router Advertisement (PrRtAdv) MessageIP Fields:
- Source Address: MUST be the link-local address assigned to the interface from which this message is sent.
- Destination Address: The Source Address of an invoking Router Solicitation for Proxy Advertisement or the address of the node the access router is instructing to handover.
- Hop Limit:
255. See RFC 2461.
ICMP Fields:
- Type:
154 - Code:
0,1,2,3,4, or5. See below. - Checksum: The ICMPv6 checksum.
- Subtype:
3 - Reserved: MUST be set to zero by the sender and ignored by the receiver.
- Identifier: Copied from the Router Solicitation for Proxy Advertisement or set to zero if unsolicited.
Valid Options in the following order:
- Source Link-Layer Address: When known, the link-layer address of the sender SHOULD be included using the Link-Layer Address option. See the LLA option format below.
- New Access Point Link-Layer Address: The link-layer address or identification of the access point is copied from the RtSolPr message. This option MUST be present.
- New Router's Link-Layer Address: The link-layer address of the access router for which this message is proxied. This option MUST be included when the Code is
0or1. - New Router's IP Address: The IP address of the NAR. This option MUST be included when the Code is
0or1. - New Router Prefix Information Option: Specifies the prefix of the access router the message is proxied for, and is used for address auto-configuration. This option MUST be included when Code is
0or1. However, when this prefix is the same as what is used in the New Router's IP Address option (above), the Prefix Information option need not be present. - New CoA Option: MAY be present when PrRtAdv is sent unsolicited. The PAR MAY compute a new CoA using the NAR's prefix information and the MN's L2 address, or by any other means.
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. 🌸
Currently, Code values 0, 1, 2, 3, 4, and 5 are defined. Let's break them down, bestie 👑
A Proxy Router Advertisement with Code 0 means that the MN should use the [AP-ID, AR-Info] tuple (present in the options above) for movement detection and NCoA formulation. In this case, the Option-Code field in the New Access Point LLA option is 1 to reflect the LLA of the access point for which the rest of the options are related. Multiple tuples may be present.
A Proxy Router Advertisement with Code 1 means that the message has been sent unsolicited. If a New CoA option is present following the New Router Prefix Information option, the MN MUST use the supplied NCoA and send an FBU immediately or else stand to lose service. This message acts as a network-initiated handover trigger; see Section 3.3. In this case, the Option-Code field in the New Access Point LLA option (see below) is 1 to reflect the LLA of the access point for which the rest of the options are related. 🔥
A Proxy Router Advertisement with Code 2 means that no new router information is present. Each New Access Point LLA option contains an Option-Code value (described below) that indicates a specific outcome.
When the Option-Code field in the New Access Point LLA option is5, handover to that access point does not require a change of CoA. This would be the case, for instance, when a number of access points are connected to the same router interface, or when network-based mobility management mechanisms ensure that the specific mobile node always observes the same prefix regardless of whether there is a separate router attached to the target access point. No other options are required in this case. When the Option-Code field in the New Access Point LLA option is6, the PAR is not aware of the Prefix Information requested. The MN SHOULD attempt to send an FBU as soon as it regains connectivity with the NAR. No other options are required in this case. When the Option-Code field in the New Access Point LLA option is7, it means that the NAR does not support fast handover. The MN MUST stop fast handover protocol operations. No other options are required in this case.
A Proxy Router Advertisement with Code 3 means that new router information is only present for a subset of access points requested. The Option-Code field values (those defined above, as well as the value of 1) distinguish different outcomes for individual access points.
A Proxy Router Advertisement with Code 4 means that the subnet information regarding neighboring access points is sent unsolicited, but the message is not a handover trigger, unlike when the message is sent with Code 1. Multiple tuples may be present. 🧁
A Proxy Router Advertisement with Code 5 means that the MN may use the new router information present for detecting movement to a new subnet, but the MN must perform DHCP [RFC3315] upon attaching to the NAR's link. The PAR and NAR will forward packets to the PCoA of the MN. The MN must still formulate an NCoA for transmitting FBU (using the information sent in this message), but that NCoA will not be used for forwarding packets. 💀
When a wildcard AP identifier is supplied in the RtSolPr message, the PrRtAdv message should include any 'n' [Access Point Identifier, Link-Layer Address option, Prefix Information Option] tuples corresponding to the PAR's neighborhood. ✨
6.2. New Mobility Header Messages
Mobile IPv6 uses a new IPv6 header type called Mobility Header [RFC3775]. The Handover Initiate, Handover Acknowledge, Fast Binding Update, Fast Binding Acknowledgment, and the (deprecated) Fast Neighbor Advertisement messages use the Mobility Header. 🦋
6.2.1. Inter - Access Router Messages
6.2.1.1. Handover Initiate (HI) 🦋
okay so the Handover Initiate (HI) is a Mobility Header message 💅 sent by an Access Router (usually a PAR) to another access router (usually a NAR) to kick off the handover for an MN. main character energy, literally 👑
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|U| Reserved | Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: Handover Initiate (HI) Message 🌸
IP Fields: ✨
- Source Address: The IP address of the PAR
- Destination Address: The IP address of the NAR
- Sequence #: MUST be set by the sender so replies can be matched to this message. 🎀
- 'S' flag: Assigned address configuration flag. When set, this message requests a new CoA to be returned by the destination. MAY be set when Code = 0. MUST be 0 when Code = 1. 🧚
- 'U' flag: Buffer flag. When set, the destination SHOULD buffer any packets toward the node indicated in the options of this message. Used when Code = 0, SHOULD be set to 0 when Code = 1. 🍓
- Code: 0 or 1. See below 💖
- Reserved: MUST be set to zero by the sender and ignored by the receiver. 🫶
Valid Options: 🔥
- Link-Layer Address of MN: The link-layer address of the MN that is undergoing handover to the destination (i.e., NAR). This option MUST be included so that the destination can recognize the MN. no cap, this one is non-negotiable 💀
- Previous Care-of Address: The IP address used by the MN while attached to the originating router. This option SHOULD be included so that a host route can be established if necessary. 🦋
- New Care-of Address: The IP address the MN wishes to use when connected to the destination. When the 'S' bit is set, the NAR MAY assign this address. 🌈
The PAR uses a Code value of 0 when it processes an FBU with the PCoA as source IP address. The PAR uses a Code value of 1 when it processes an FBU whose source IP address is not the PCoA. the way that the Code tells you which FBU situation you're in 😭
If a Handover Acknowledge (HAck) message is not received as a response in a short time period (no less than twice the typical round trip time (RTT) between source and destination, or 100 milliseconds if RTT is not known), the Handover Initiate SHOULD be resent. Subsequent retransmissions can be up to HI_RETRIES, but MUST use exponential backoff in which the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled during each instance of retransmission. so if the HAck ghosts you, you wait a bit longer each time before trying again 🙈⏳
6.2.1.2. Handover Acknowledge (HAck) 🧚
The Handover Acknowledge message is a new Mobility Header message that MUST be sent (typically by the NAR to the PAR) as a reply to the Handover Initiate message. it's the reply that you literally cannot skip 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Handover Acknowledge (HAck) Message 🌷
IP Fields: ✨
- Source Address: Copied from the destination address of the Handover Initiate Message to which this message is a response.
- Destination Address: Copied from the source address of the Handover Initiate Message to which this message is a response.
- Sequence #: Copied from the corresponding field in the HI message to which this message is a response, to enable the receiver to match this HAck message with an outstanding HI message. 🎀
- Code:
- 0: Handover Accepted, NCoA valid ✅
- 1: Handover Accepted, NCoA not valid or in use
- 2: Handover Accepted, NCoA assigned (used in Assigned Addressing)
- 3: Handover Accepted, use PCoA
- 4: Message sent unsolicited, usually to trigger an HI message
- 128: Handover Not Accepted, reason unspecified
- 129: Administratively prohibited
- 130: Insufficient resources
- Reserved: MUST be set to zero by the sender and ignored by the receiver. 🫶
Valid Options: 🔥
- New Care-of Address: If the 'S' flag in the Handover Initiate message is set, this option MUST be used to provide the NCoA that the MN should use when connected to this router. This option MAY be included, even when the 'S' bit is not set, e.g., Code 2 above. 🌈
Upon receiving an HI message, the NAR MUST respond with a Handover Acknowledge message. If the 'S' flag is set in the HI message, the NAR SHOULD include the New Care-of Address option and a Code 3. the NAR basically has to answer, and if the S flag is set it should bring the NCoA and say Code 3 💖
The NAR MAY provide support for the PCoA (instead of accepting or assigning an NCoA), establish a host route entry for the PCoA, and set up a tunnel to the PAR to forward the MN's packets sent with the PCoA as a source IP address. This host route entry SHOULD be used to forward packets once the NAR detects that the particular MN is attached to its link. The NAR indicates forwarding support for the PCoA using Code value 3 in the HAck message. Subsequently, the PAR establishes a tunnel to the NAR in order to forward packets arriving for the PCoA. tunnels, host routes, the whole vibe 🦋✨
When responding to an HI message containing a Code value 1, the Code values 1, 2, and 4 in the HAck message are not relevant. 🙈
Finally, the New Access Router can always refuse handover, in which case it MUST indicate the reason in one of the available Code values. nobody's forcing the NAR to say yes, but it has to explain why it said no 🍓💅
6.2.2. Fast Binding Update (FBU) 🎀
The Fast Binding Update message has a Mobility Header Type value of 8. The FBU is identical to the Mobile IPv6 Binding Update (BU) message. However, the processing rules are slightly different. Furthermore, additional flags (as part of the Reserved field below) defined by other related protocols are not relevant in this message, and MUST be set to zero. it's basically a BU with a glow-up, and the extra flags are NOT invited 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: Fast Binding Update (FBU) Message 🌈
IP Fields: ✨
- Source Address: The PCoA or NCoA
- Destination Address: The IP address of the Previous Access Router
'A' flag: MUST be set to one to request that PAR send a Fast Binding Acknowledgment message. 🦋
'H' flag: MUST be set to one. See [RFC3775]. 🫶
'L' flag: See [RFC3775].
'K' flag: See [RFC3775].
Reserved: This field is unused. MUST be set to zero. 🍓
Sequence Number: See [RFC3775].
Lifetime: The requested time in seconds for which the sender wishes to have a binding. ⭐
Mobility Options: MUST contain an alternate CoA option set to the NCoA when an FBU is sent from the PAR's link. MUST contain the Binding Authorization Data for the FMIP (BADF) option. See Section 6.4.5. MAY contain the Mobility Header LLA option (see Section 6.4.4). the options are a whole list of must-haves, so pack your bag 🧳💖
The MN sends an FBU message any time after receiving a PrRtAdv message. If the MN moves prior to receiving a PrRtAdv message, it SHOULD send an FBU to the PAR after configuring the NCoA on the NAR according to Neighbor Discovery and IPv6 Address Configuration protocols. When the MN moves without having received a PrRtAdv message, it cannot transmit an UNA message upon attaching to the NAR's link. ngl the timing matters here, so don't be late to the FBU party 😭⏰
The source IP address is the PCoA when the FBU is sent from the PAR's link, and the source IP address is the NCoA when the FBU sent from the NAR's link. When the source IP address is the PCoA, the MN MUST include the alternate CoA option set to NCoA. The PAR MUST process the FBU even though the address in the alternate CoA option is different from that in the source IP address, and ensure that the address in the alternate CoA option is used in the New CoA option in the HI message to the NAR. so the PAR has to take the alternate CoA and carry it forward into the HI, no matter what the source address says 🧚🌸
The FBU MUST also include the Home Address Option set to PCoA. An FBU message MUST be protected so that the PAR is able to determine that the FBU message is sent by an MN that legitimately owns the PCoA. security bestie check, this part is serious 🔥🔐
6.2.3. Fast Binding Acknowledgment (FBack) 🦋
okay so the FBack message is basically a twin of the Mobile IPv6 Binding Acknowledgment (BAck) message 👯♀️ same format, but the processing rules are lowkey different 🫶 also, the extra flags (the ones hiding in the Reserved field, from other related protocols) aren't relevant here, so they MUST be set to zero 🙈
the Mobility Header Type value for FBack is 9 ✨ the PAR sends it to say "got your FBU!" whenever the FBU had the 'A' bit set 💌 if the PAR sends an HI to the NAR after processing an FBU, the FBack SHOULD NOT go to the MN before the PAR gets an HAck back from the NAR 🧚 but in the reactive mode the PAR MAY send the FBack right away, bestie 💅 and the FBack MAY also be sent to the MN on the old link 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Fast Binding Acknowledgment (FBack) MessageIP Fields:
- Source address: The IP address of the Previous Access Router
- Destination Address: The NCoA, and optionally the PCoA
Status: an 8-bit unsigned integer that tells you what happened to the Fast Binding Update 📬 values under 128 mean the Binding Update was accepted by the receiving node 🎉 the currently defined ones are:
0: Fast Binding Update accepted1: Fast Binding Update accepted but NCoA is invalid. Use NCoA supplied in "alternate" CoA
values of 128 or higher mean the Binding Update got rejected 💀 the currently defined ones are:
128: Reason unspecified129: Administratively prohibited130: Insufficient resources131: Incorrect interface identifier length
'K' flag: See [RFC3775].
Reserved: an unused field. It MUST be set to zero.
Sequence Number: copied from the FBU message so the MN can match this ack with an FBU it's still waiting on 🎀
Lifetime: the granted lifetime in seconds for which the sender of this message will keep a binding for traffic redirection ⏳
Mobility Options: if Status is 1, this MUST contain an "alternate" CoA 🔥 it MUST also contain the Binding Authorization Data for FMIP (BADF) option, which you can read about in Section 6.4.5 🫶
6.3. Unsolicited Neighbor Advertisement (UNA) 🌈
this is the same message as the one in [RFC4861], with one tiny twist: the 'O' bit is always set to zero 🙈 since it's unsolicited, the 'S' bit is zero, and since an MN is the one sending it, the 'R' bit is zero too ✨
if the NAR is proxying the NCoA (because HI and HAck already got exchanged), then UNA processing has some extra steps, which you'll see below 👀 if the NAR is NOT proxying the NCoA (like, the HI and HAck exchange never happened), then UNA processing just follows the normal procedure from [RFC4861] 💅 implementations MAY retransmit UNAs following Section 7.2.6 of [RFC4861], but they should keep in mind that the default RetransTimer value is pretty large for handover purposes 🧚
the Source Address in UNA MUST be the NCoA 💖 the destination address is usually the all-nodes multicast address, but some deployments may not prefer sending to a multicast address 🌸 in those cases the destination address SHOULD be the NAR's IP address 🦋
the Target Address MUST include the NCoA, and the Target link-layer address MUST include the MN's LLA 🫶
the MN sends an UNA to the NAR as soon as it's back online on the new link 📡 arriving or buffered packets can be forwarded immediately ⭐ if the NAR is proxying the NCoA, it creates a neighbor cache entry in STALE state, but it still forwards packets while it figures out bidirectional reachability using the standard Neighbor Discovery procedure 🧠 if there's already an entry in INCOMPLETE state without a link-layer address, the NAR sets it to STALE, again following the procedure in [RFC4861] ✨
the NAR MAY wish to give the MN a different IP address than the one in the UNA 👑 if it does, the NAR MUST delete the proxy entry for the NCoA and send a Router Advertisement with a NAACK option containing the new IP address 💅
the combo of the NCoA (in the source IP address) and the Link-Layer Address (as a Target LLA) SHOULD be used to tell the MN apart from other nodes 🔥
6.4. New Options 💜
all the options, except for Binding Data Authorization for FMIPv6 (BADF), which you'll find in Section 6.4.5, use the Type, Length, and Option-Code format shown in Figure 10 ✨
the Type values come from the Neighbor Discovery options space and the Mobility Header options space 🧚 the Length field is in units of 8 octets for Neighbor Discovery options, and in units of octets for Mobility Header options 📏 and Option-Code gives extra info for each option (see the individual options below) 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Option Format6.4.1. IP Address/Prefix Option 🌷
this option gets sent in the Proxy Router Advertisement message 📨
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 | Option-Code | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: IPv6 Address/Prefix OptionType: 17
Length: the size of this option in 8 octets, including the Type, Option-Code, and Length fields 📐
Option-Code:
1: Old Care-of Address2: New Care-of Address3: NAR's IP address4: NAR's Prefix, sent in PrRtAdv. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver 🫶
Prefix Length: an 8-bit unsigned integer that shows the length of the IPv6 Address Prefix. It ranges from 0 to 128 🍓
Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver 🙈
IPv6 address: the IP address defined by the Option-Code field 💖
6.4.2. Mobility Header IP Address/Prefix Option 🎀
this option is sent in the Handover Initiate and Handover Acknowledge messages 🦋 it has an alignment requirement of 8n+4 📏
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 | Option-Code | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address/Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Mobility Header IPv6 Address/Prefix OptionType: 17
Length: the size of this option in octets, excluding the Type and Length fields 📏
Option-Code:
1: Old Care-of Address2: New Care-of Address3: NAR's IP address4: NAR's Prefix, sent in PrRtAdv. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver 🌸
Prefix Length: an 8-bit unsigned integer that shows the length of the IPv6 Address Prefix. It ranges from 0 to 128 🍓
IPv6 address/prefix: the IP address/prefix defined by the Option-Code field 🧚
6.4.3. Link-Layer Address (LLA) Option 🔗✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | LLA...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Link-Layer Address OptionOkay so this is the LLA option, and it's basically the layer 2 ID badge for a device 🪪💅 Here's the breakdown:
Type:19🎀Length: the size of the option in 8 octets, counting the Type, Option-Code, and Length fields too 📏Option-Code: this one tells you what the address is for 👀0: Wildcard requesting resolution for all nearby access points1: Link-Layer Address of the New Access Point2: Link-Layer Address of the MN3: Link-Layer Address of the NAR (i.e., Proxied Originator)4: Link-Layer Address of the source of RtSolPr or PrRtAdv message5: The access point identified by the LLA belongs to the current interface of the router6: No prefix information available for the access point identified by the LLA7: No fast handover support available for the access point identified by the LLA
LLA: the variable-length link-layer address 🫶
Now the tea ☕ The LLA option has no length field for the LLA itself, so implementations must check the specific link layer the protocol runs over to figure out what the LLA looks like and how long it is. Lowkey important!
Also, depending on how big the individual LLA is, you MUST add padding so that the whole option comes out to a multiple of 8 octets. No skipping this one, bestie 🙅♀️
The New Access Point Link-Layer Address holds the link-layer address of the access point that a handover is about to be attempted with. It shows up in the Router Solicitation for Proxy Advertisement message 🦋
The MN Link-Layer Address option holds the link-layer address of an MN, and it's used in the Handover Initiate message 🧚
The NAR (i.e., Proxied Originator) Link-Layer Address option holds the link-layer address of the access router that the Proxy Router Solicitation message is talking about 🌸
6.4.4. Mobility Header Link-Layer Address (MH-LLA) Option 💜
This one is basically the LLA option's twin, except it lives inside Mobility Header messages like FBU. Other Mobility Header messages might start using it later on 👀 The format is in Figure 14, and there are no alignment requirements for it, so it's chill 😌
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Code | LLA ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Mobility Header Link-Layer Address OptionType:7🍓Length: the size of the option in octets, not counting the Type and Length fields 📐Option-Code:2, which is the Link-Layer Address of the MN 🫧LLA: the variable-length link-layer address 💖
6.4.5. Binding Authorization Data for FMIPv6 (BADF) 🔐
This option MUST be in FBU and FBack messages. No exceptions, bestie 🙅♀️ The security association between the MN and the PAR is set up by companion protocols [RFC5269]. This option tells you how to compute and check a Message Authentication Code (MAC) using that established security association 🔑
Here's the format in Figure 15:
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 | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authenticator |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Binding Authorization Data for FMIPv6 (BADF) OptionType:21🦄Option Length: the length of the Authenticator in bytes 📏SPI: Security Parameter Index.SPI = 0is reserved for the Authenticator computed using SEND-based handover keys 🗝️Authenticator: same as in RFC 3775, except that "correspondent" gets swapped for the PAR's IP address, and Kbm (binding management key) gets swapped for the shared key between the MN and the PAR 🫶
The default MAC calculation uses HMAC_SHA1, with the first 96 bits used for the MAC. Because there's an Option Length field, implementations can use other algorithms, like HMAC_SHA256 ⚡
This option MUST be the last Mobility Option present. Always last, always 💅
6.4.6. Neighbor Advertisement Acknowledgment (NAACK) 🙈
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 | Option-Code | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Neighbor Advertisement Acknowledgment OptionType:20🎀Length: an 8-bit unsigned integer, the length of the option in 8 octets. It's1when a new CoA isn't supplied, and3when a new CoA is present (right after the Reserved field) 📏Option-Code:0🫧Status: an 8-bit unsigned integer showing what happened to the Unsolicited Neighbor Advertisement message. These are the values defined so far:1: NCoA is invalid, perform address configuration2: NCoA is invalid, use the supplied NCoA. The supplied NCoA (in the form of an IP Address Option) MUST be present following the Reserved field.3: NCoA is invalid, use NAR's IP address as NCoA in FBU4: PCoA supplied, do not send FBU128: Link-Layer Address unrecognized
Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver 🤫
So the NAR answers an UNA with the NAACK option when it wants the MN to use a different NCoA than the one it's already using 🌈 If the NAR proposes a different NCoA, the Router Advertisement MUST use the source IP address from the UNA message as its destination address, and it MUST use the L2 address that's in the UNA. The MN MUST use the NCoA if the NAACK option supplies one 💖
Now the spicy part 🌶️ If the NAACK says the Link-Layer Address is unrecognized (for example, the MN is using an LLA that's valid on the PAR's link, but that same LLA isn't valid on the NAR's link because the access technology is different), the MN MUST NOT use the NCoA or the PCoA, and it SHOULD start right away on getting a different NCoA at the NAR 🏃♀️💨
In the future, new option types may be defined 🔮
7. Related Protocol and Device Considerations 🧩
Okay so the big design principle here is that this protocol introduces no changes, or only minimal ones, to related protocols ✨ For example, you don't need any changes to base Mobile IPv6 to implement this. Same deal for the IPv6 stateless address autoconfiguration protocol [RFC4862] and DHCP [RFC3315], which don't get changed either 🙌
The protocol does define an optional extension to Neighbor Discovery [RFC4861], where an access router may send a router advertisement as a response to the UNA message (see Section 6.3). Apart from that extension, the spec doesn't change Neighbor Discovery behavior, including what happens when the MN is attached to the PAR and when it's attaching to the NAR 🦋
Also, the protocol doesn't need any changes to intermediate Layer 2 devices between an MN and its access router, as long as those devices support this spec. That covers wireless access points, switches, snooping devices, and so on 📡💜
8. Evolution from and Compatibility with RFC 4068 🌱
This document grew out of [RFC4068] 🌷 The big new piece is a handover key establishment protocol (see [RFC5269]), which sets up a security association between a mobile node and its access router. That's what lets the routing of packets get updated securely during a handover 🔐 Later on, new specs may define other ways to set up these security associations, depending on the deployment scenario 🔮
The protocol got better from experience implementing [RFC4068] and from experimental use 📈 Feedback improved the spec for parameter fields (things like lifetime, codepoints, and so on), and it also added new parameter fields to the existing messages. As of this writing, there are two publicly available implementations, [fmipv6] and [tarzan], plus several proprietary ones 🧑💻 Some experience suggests the protocol meets the delay and packet loss requirements when it's used properly with particular radio access protocols. For instance, see [RFC5184] and [mip6-book]. Still, handover performance depends on two things: the IP-layer operations this protocol specifies, and the radio access technology itself, which this protocol relies on but doesn't modify 📶
An existing implementation of [RFC4068] has to be updated to support this spec. The main addition is setting up a security association between an MN and its access router (that is, MN and PAR). One way to do that is specified in [RFC5269] 🔑 An implementation that follows this document will probably also work with [RFC4068], with one catch: the Binding Authorization Data for FMIPv6 option (see Section 6.4.5) can only be processed when a security association exists between the mobile node and its access router 🙃 This spec also deprecates the Fast Neighbor Advertisement (FNA) message. That said, it's fine for a NAR to process this message from a mobile node as specified in [RFC4068] 💅
9. Configurable Parameters ⚙️
Mobile nodes rely on the configuration parameters in the table below. Every mobile node MUST have a configuration mechanism to adjust these parameters. That mechanism can be local (like a command line interface) or based on central management of a bunch of mobile nodes 🎛️
+-------------------+---------------+-----------------+
| Parameter Name | Default Value | Definition |
+-------------------+---------------+-----------------+
| RTSOLPR_RETRIES | 3 | Section 6.1.1 |
| MAX_RTSOLPR_RATE | 3 | Section 6.1.1 |
| FBU_RETRIES | 3 | Section 6.2.2 |
| PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.1.2 |
| HI_RETRIES | 3 | Section 6.2.1.1 |
+-------------------+---------------+-----------------+10. Security Considerations 🛡️
Okay bestie, this part is lowkey dramatic 😭 The following security vulnerabilities are identified, and suggested solutions are mentioned ✨
Insecure FBU: in this case, packets meant for one address could be stolen or redirected to some unsuspecting node 🙈 This concern is the same as the one in an MN and Home Agent relationship.
Hence, the PAR MUST ensure that the FBU packet arrived from a node that legitimately owns the PCoA. The access router and its hosts may use any available mechanism to establish a security association that MUST be used to secure FBU. The current version of this protocol relies on a companion protocol [RFC5269] to establish such a security association. Using the shared handover key from [RFC5269], the Authenticator in BADF option (see Section 6.4.5) MUST be computed, and the BADF option included in FBU and FBack messages 🔐
Secure FBU, malicious or inadvertent redirection: okay so in this case, the FBU is secured, but the target of the binding happens to be an unsuspecting node, either due to inadvertent operation or due to malicious intent 😬 This vulnerability can lead to an MN with a genuine security association with its access router redirecting traffic to an incorrect address.
However, the target of malicious traffic redirection is limited to an interface on an access router with which the PAR has a security association ✨ The PAR MUST verify that the NCoA to which the PCoA is being bound actually belongs to the NAR's prefix. In order to do this, HI and HAck message exchanges are to be used. When the NAR accepts the NCoA in HI (with Code = 0), it proxies the NCoA so that any arriving packets are not sent on the link until the MN attaches and announces itself through the UNA. Therefore, any inadvertent or malicious redirection to a host is avoided 🦋 It is still possible to jam a NAR's buffer with redirected traffic. However, since a NAR's handover state corresponding to an NCoA has a finite (and short) lifetime corresponding to a small multiple of anticipated handover latency, the extent of this vulnerability is arguably small 🌸
Sending an FBU from a NAR's link: a malicious node may send an FBU from a NAR's link, providing an unsuspecting node's address as an NCoA 🙅♀️ This is similar to base Mobile IP, where the MN can provide some other node's IP address as its CoA to its Home Agent. Here, the PAR acts like a "temporary Home Agent" having a security association with the mobile node and providing forwarding support for the handover traffic. As in base Mobile IP, this misdelivery is traceable to the MN that has a security association with the router. So, it is possible to isolate such an MN if it continues to misbehave 👀 Similarly, an MN that has a security association with the PAR may provide the LLA of some other node on NAR's link, which can cause misdelivery of packets (meant for the NCoA) to an unsuspecting node. It is possible to trace the MN in this case as well.
Apart from the above, the RtSolPr (Section 6.1.1) and PrRtAdv (Section 6.1.2) messages inherit the weaknesses of the Neighbor Discovery protocol [RFC4861] 😤 Specifically, when its access router is compromised, the MN's RtSolPr message may be answered by an attacker that provides a rogue router as the resolution. Should the MN attach to such a rogue router, its communication can be compromised. Similarly, a network-initiated PrRtAdv message (see Section 3.3) from an attacker could cause an MN to hand over to a rogue router. Where these weaknesses are a concern, a solution such as Secure Neighbor Discovery (SEND) [RFC3971] SHOULD be considered 🧚
The protocol provides support for buffering packets during an MN's handover. This is done by securely exchanging the Handover Initiate (HI) and Handover Acknowledge (HAck) messages in response to the FBU message from an MN. It is possible that an MN may fail, either inadvertently or purposely, to undergo handover to the NAR, which typically provides buffering support. This can cause the NAR to waste its memory containing the buffered packets, and in the worst case, could create resource exhaustion concerns 💀 Hence, implementations must limit the size of the buffer as a local policy configuration that may consider parameters such as the average handover delay, expected size of packets, and so on.
The Handover Initiate (HI) and Handover Acknowledge (HAck) messages exchanged between the PAR and NAR MUST be protected using end-to-end security association(s) offering integrity and data origin authentication 🫶
The PAR and the NAR MUST implement IPsec [RFC4301] for protecting the HI and HAck messages. IPsec Encapsulating Security Payload (ESP) [RFC4303] in transport mode with mandatory integrity protection SHOULD be used for protecting the signaling messages. Confidentiality protection of these messages is not required 💅
The security associations can be created by using either manual IPsec configuration or a dynamic key negotiation protocol such as Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306]. If IKEv2 is used, the PAR and the NAR can use any of the authentication mechanisms, as specified in RFC 4306, for mutual authentication. However, to ensure a baseline interoperability, the implementations MUST support shared secrets for mutual authentication 🔑 The following sections describe the Peer Authorization Database (PAD) and Security Policy Database (SPD) entries specified in [RFC4301] when IKEv2 is used for setting up the required IPsec security associations.
10.1. Peer Authorization Database Entries When Using IKEv2
This section describes PAD entries on the PAR and the NAR. The PAD entries are only example configurations. Note that the PAD is a logical concept, and a particular PAR or NAR implementation can implement the PAD in any implementation-specific manner. The PAD state may also be distributed across various databases in a specific implementation 📚
PAR PAD:
- IF remote_identity = nar_identity_1
THEN authenticate (shared secret/certificate/EAP) and authorize
CHILD_SA for remote address nar_address_1
NAR PAD:
- IF remote_identity = par_identity_1
THEN authenticate (shared secret/certificate/EAP) and authorize
CHILD_SAs for remote address par_address_1The list of authentication mechanisms in the above examples is not exhaustive. There could be other credentials used for authentication stored in the PAD 🌈
10.2. Security Policy Database Entries
This section describes the security policy entries on the PAR and the NAR required to protect the HI and HAck messages. The SPD entries are only example configurations. A particular PAR or NAR implementation could configure different SPD entries as long as they provide the required security ✨
In the examples shown below, the identity of the PAR is assumed to be par_1, the address of the PAR is assumed to be par_address_1, and the address of the NAR is assumed to be nar_address_1 🎀
PAR SPD-S:
- IF local_address = par_address_1 &
remote_address = nar_address_1 &
proto = MH &
local_mh_type = HI &
remote_mh_type = HAck
THEN use SA ESP transport mode Initiate using IDi = par_1 to
address nar_address_1
NAR SPD-S:
- IF local_address = nar_address_1 &
remote_address = par_address_1 &
proto = MH &
local_mh_type = HAck &
remote_mh_type = HI
THEN use SA ESP transport mode11. IANA Considerations 📋
This document defines two new Mobility Header messages that have received Type assignment from the Mobility Header Type registry 🍓
14Handover Initiate Message (Section 6.2.1.1)15Handover Acknowledge Message (Section 6.2.1.2)
This document defines a new Mobility Option that has received Type assignment from the Mobility Options Type registry.
- Mobility Header IPv6 Address/Prefix option (34), described in Section 6.4.2
This document defines a new ICMPv6 message, which has been allocated from the ICMPv6 Type registry.
154FMIPv6 Messages
This document creates a new registry for the 'Subtype' field in the above ICMPv6 message, called the "FMIPv6 Message Types". IANA has assigned the following values 🦋
+---------+-------------------+-----------------+
| Subtype | Description | Reference |
+---------+-------------------+-----------------+
| 2 | RtSolPr | Section 6.1.1 |
| 3 | PrRtAdv | Section 6.1.2 |
| 4 | HI - Deprecated | Section 6.2.1.1 |
| 5 | HAck - Deprecated | Section 6.2.1.2 |
+---------+-------------------+-----------------+The values '0' and '1' are reserved. The upper limit is 255. An RFC is required for new message assignment. The Subtype values 4 and 5 are deprecated but marked as unavailable for future allocations 🚫
The document defines a new Mobility Option that has received Type assignment from the Mobility Options Type registry.
- Binding Authorization Data for FMIPv6 (BADF) option (21), described in Section 6.4.5
The document defines the following Neighbor Discovery [RFC4861] options that have received Type assignment from IANA 💜
+------+--------------------------------------------+---------------+
| Type | Description | Reference |
+------+--------------------------------------------+---------------+
| 17 | IP Address/Prefix Option | Section 6.4.1 |
| 19 | Link-layer Address Option | Section 6.4.3 |
| 20 | Neighbor Advertisement Acknowledgment | Section 6.4.6 |
| | Option | |
+------+--------------------------------------------+---------------+The document defines the following Mobility Header messages that have received Type allocation from the Mobility Header Types registry 🌸
- Fast Binding Update (8), described in Section 6.2.2
- Fast Binding Acknowledgment (9), described in Section 6.2.3
The document defines the following Mobility Option that has received Type assignment from the Mobility Options Type registry.
- Mobility Header Link-Layer Address option (7), described in Section 6.4.4
12. Acknowledgments ✨
okay so the editor wants to thank literally everyone who gave feedback 🫶 but can only name a few here, so the shoutout list is: Vijay Devarapalli, Youn-Hee Han, Emil Ivov, Syam Madanapalli, Suvidh Mathur, Andre Martin, Javier Martin, Koshiro Mitsuya, Gabriel Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Alex Petrescu, Domagoj Premec, Subba Reddy, K. Raghav, Ranjit Wable, and Jonathan Wood 💜 Behcet Sarikaya and Frank Xia get credit for feedback on operation over point-to-point links 🔥 The editor also wants to acknowledge James Kempf for a contribution that made this spec better 🌸 Vijay Devarapalli wrote the text for the security configuration between access routers in Section 10 🔐 Thanks to Jari Arkko for the detailed AD Review, which improved this document ✨ And the editor would also like to thank the MIPSHOP working group chair Gabriel Montenegro, plus the erstwhile MOBILE IP working group chairs Basavaraj Patil and Phil Roberts, for giving so much support to this work 👑
13. References 🦋
13.1. Normative References 💅
Okay these are the must-reads, no cap:
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC5268] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268,
June 2008.
[RFC5269] Kempf, J. and R. Koodli, "Distributing a Symmetric Fast
Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor
Discovery (SEND)", RFC 5269, June 2008.13.2. Informative References 🌈
These are the extra-credit reads, bestie 📚
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers",
RFC 3290, May 2002.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K.
Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3
(L3)-Driven Fast Handover", RFC 5184, May 2008.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury,
K., and B. Patil, "Proxy Mobile IPv6", RFC 5213,
August 2008.
[RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack
Hosts and Routers", RFC 5555, June 2009.
[fmipv6] "fmipv6.org : Home Page", <http://fmipv6.org>.
[mip6-book] Koodli, R. and C. Perkins, "Mobile Inter-networking with
IPv6", Chapter 22, John Wiley & Sons, Inc., 2007.
[pfmipv6] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6", Work
in Progress, May 2009.
[tarzan] "Nautilus6 - Tarzan",
<http://software.nautilus6.org/TARZAN/>.
[x.s0057] 3GPP2, "E-UTRAN - eHRPD Connectivity and Interworking:
Core Network Aspects", 3GPP2 X.S0057-0, April 2009,
<http://www.3gpp2.org/Public_html/Specs/
X.S0057-0_v1.0_090406.pdf>.Appendix A. Contributors 🧚
This document has its origins in the fast handover design team in the erstwhile MOBILE IP working group. The members of this design team, in alphabetical order, were: Gopal Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis, and Alper Yegin 💖
Appendix B. Changes since RFC 5268 🎀
This document specifies the Mobility Header format for HI and HAck messages, and the Mobility Header Option format for IPv6 Address/Prefix option. The use of ICMP for HI and HAck messages is deprecated. The following developments led the WG to adopt this change:
- The Proxy Mobile IPv6 protocol [RFC5213] has been adopted for the deployment of fourth-generation mobile networks. This has established Mobility Header as the default type for critical IP mobility signaling.
- The Mobile IPv6 protocol [RFC3775] (particularly, the Dual-stack MIP6 or DSMIP6 [RFC5555]) protocol, which is also expected to be deployed in the fourth-generation mobile networks, similarly relies on Mobility Header for critical IP mobility signaling.
- The Fast Handover protocol specified in this document is used as the basis for the Fast Handover for Proxy MIP6 [pfmipv6], which is adopted by the "enhanced HRPD" (CDMA) networks [x.s0057]. Hence, the Fast Handover protocol, when used in deployments using either PMIP6 or MIP6, needs to support the Mobility Header for all its critical mobility signaling messages. At the same time, use of ICMP, primarily due to legacy, is unlikely to facilitate critical IP mobility signaling without a non-trivial departure from deploying the new Mobility Header signaling protocols.
Therefore, it follows that specifying the Mobility Header for the HI and HAck messages is necessary for the deployment of the protocol along-side PMIP6 and MIP6 protocols 🦋
Appendix C. Changes since RFC 4068 🌸
The following are the major changes and clarifications:
- Specified security association between the MN and its Access Router in the companion document [RFC5269].
- Specified Binding Authorization Data for Fast Handovers (BADF) option to carry the security parameters used for verifying the authenticity of FBU and FBack messages. The handover key used for computing the Authenticator is specified in companion documents.
- Specified the security configuration for inter - access router signaling (HI, HAck).
- Added a section on prefix management between access routers and illustrated protocol operation over point-to-point links.
- Deprecated FNA, which is a Mobility Header message. In its place, the Unsolicited Neighbor Advertisement (UNA) message from RFC 4861 is used.
- Combined the IPv6 Address Option and IPv6 Prefix Option.
- Added description of the DAD requirement on NAR when determining NCoA uniqueness in Section 4, "Protocol Details".
- Added a new code value for a gratuitous HAck message to trigger a HI message.
- Added Option-Code 5 in PrRtAdv message to indicate NETLMM (Network-based Localized Mobility Management) usage.
- Clarified protocol usage when DHCP is used for NCoA formulation (Sections 6.1.2, 3.1, and 5.2). Added a new Code value (5) in PrRtAdv (Section 6.1.2).
- Clarified that IPv6 Neighbor Discovery operations are a must in Section 7, "Related Protocol and Device Considerations".
- Clarified "PAR = temporary HA" for FBUs sent by a genuine MN to an unsuspecting CoA.
Author's Address 💌
Rajeev Koodli (editor) Starent Networks USA
EMail: rkoodli@starentnetworks.com📦 where this page comes from
- ietf: rfc5568 2009-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms