RFC 4068
Fast Handovers for Mobile IPv6
RFC 4068: Fast Handovers for Mobile IPv6 🦋
okay bestie, this one is all about making phones and laptops keep their internet connection when they hop from one network to another 📱✨ and yes, the RFC number and title are right there at the top, along with the stuff you need to know about it. 💅
Here's the title block, all worked in:
RFC 4068 is titled "Fast Handovers for Mobile IPv6" 🎀. It was written by R. Koodli, Ed., from Nokia Research Center 💜, and it's dated July 2005 🌸. Its category is Experimental, which means it's an Experimental Protocol for the Internet community, not an Internet standard 🧚. It's in the Network Working Group stream, and discussion and suggestions for improvement are requested 🫶.
It doesn't list anything it obsoletes or updates, so it's standing on its own 💖.
Status of This Memo 📝
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
Copyright Notice ©️
Copyright (C) The Internet Society (2005).
Abstract 🌈
Okay so, Mobile IPv6 lets a Mobile Node keep its connection to the internet when it moves from one Access Router to another. That moment is called a handover 🦋. During a handover there's a little gap where the Mobile Node can't send or receive packets, because switching links takes time and the IP stuff has to happen too 😭. This "handover latency" comes from the normal Mobile IPv6 steps: movement detection, configuring a new Care of Address, and the Binding Update. It's honestly unacceptable for real-time stuff like Voice over IP 💀. Cutting this delay would help non-real-time, throughput-sensitive apps too 🔥.
This document describes a protocol that improves the handover latency caused by Mobile IPv6 procedures. It does NOT try to fix link switching latency, so that part is out of scope 🙈.
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Addressing the Handover Latency. . . . . . . . . . . . . 5
3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . 7
3.3. Protocol Operation of Network-initiated Handover . . . . 9
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 10
5. Miscellaneous. . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Handover Capability Exchange . . . . . . . . . . . . . . 15
5.2. Determining New Care of Address. . . . . . . . . . . . . 15
5.3. Packet Loss. . . . . . . . . . . . . . . . . . . . . . . 15
5.4. DAD Handling . . . . . . . . . . . . . . . . . . . . . . 16
5.5. Fast or Erroneous Movement . . . . . . . . . . . . . . . 16
6. Message Formats. . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. New Neighborhood Discovery Messages. . . . . . . . . . . 17
6.1.1. Router Solicitation for Proxy Advertisement
(RtSolPr) . . . . . . . . . . . . . . . . . . . . 17
6.1.2. Proxy Router Advertisement (PrRtAdv). . . . . . . 20
6.2. Inter-Access Router Messages . . . . . . . . . . . . . . 23
6.2.1. Handover Initiate (HI). . . . . . . . . . . . . . 23
6.2.2. Handover Acknowledge (HAck) . . . . . . . . . . . 25
6.3. New Mobility Header Messages . . . . . . . . . . . . . . 27
6.3.1. Fast Binding Update (FBU) . . . . . . . . . . . . 27
6.3.2. Fast Binding Acknowledgment (FBack) . . . . . . . 28
6.3.3. Fast Neighbor Advertisement (FNA) . . . . . . . . 30
6.4. New Options. . . . . . . . . . . . . . . . . . . . . . . 31
6.4.1. IP Address Option . . . . . . . . . . . . . . . . 32
6.4.2. New Router Prefix Information Option. . . . . . . 33
6.4.3. Link-Layer Address (LLA) Option . . . . . . . . . 34
6.4.4. Mobility Header Link-Layer Address (MH-LLA)
Option. . . . . . . . . . . . . . . . . . . . . . 35
6.4.5. Neighbor Advertisement Acknowledgment (NAACK) . . 35
7. Configurable Parameters. . . . . . . . . . . . . . . . . . . . 36
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 38
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 39
11. Normative References . . . . . . . . . . . . . . . . . . . . . 39
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 391. Introduction 🌸
Mobile IPv6 [3] describes the protocol operations for a mobile node to maintain connectivity to the Internet during its handover from one access router to another. These operations involve movement detection, IP address configuration, and location update 🧚. Put together, the handover latency is often enough to mess up real-time apps 😭. Throughput-sensitive apps can also benefit from less latency 🔥. This document describes a protocol to reduce the handover latency ✨.
This specification addresses the following problem: how to let a mobile node send packets as soon as it detects a new subnet link, and how to deliver packets to a mobile node as soon as its attachment is detected by the new access router 💅. The protocol defines the IP protocol messages it needs to work, regardless of link technology 🦋. It doesn't depend on specific link-layer features, but it does allow link-specific customizations 🎀. By definition, this specification considers handovers that interwork with Mobile IP: once attached to its new access router, an MN engages in Mobile IP operations including Return Routability [3] 💜. There are no special requirements for a mobile node to behave differently with respect to its standard Mobile IP operations 🫶.
2. Terminology 💖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1] 🌈. The use of the term "silently ignore" is not defined in RFC 2119, but this document uses it anyway, and it can be construed in a similar way ✨.
The following terminology and abbreviations are used in this document. The reference handover scenario is illustrated in Figure 1 🧚.
Mobile 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 Base Station Subsystem ID (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 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. 🔁
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 also acts 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, Prefix] is called "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 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. 👍
Fast Neighbor Advertisement (FNA) A message from the MN to the NAR to announce attachment, and to confirm the use of NCoA when the MN has not received an FBACK. 📢
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. ✅
v +------------+
+-+ | Previous | <
| | ---------- | Access | ------ > ----\
+-+ | Router | < \
MN | (PAR) | \
| +------------+ +---------------+
| ^ IP | Correspondent |
| | Network | Node |
V | +---------------+
v /
v +------------+ /
+-+ | New | < /
| | ---------- | Access | ------ > ----/
+-+ | Router | <
MN | (NAR) |
+------------+
Figure 1: Reference Scenario for Handover3. Protocol Overview 🦋
3.1. Addressing the Handover Latency ✨
okay bestie, so the ability to immediately send packets from a new subnet link depends on the "IP connectivity" latency 🫶, which in turn depends on the movement detection latency and 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 successfully process the Binding Update (which typically involves the Return Routability procedure), the MN can receive packets at the new CoA 🦋. so being able to receive packets straight from correspondents at its new CoA depends on the Binding Update latency and the IP connectivity latency. no cap, it's a whole chain 😭
the protocol lets an MN quickly detect that it has moved to a new subnet by handing it the new access point and the associated subnet prefix information while the MN is still connected to its current subnet (i.e., PAR in Figure 1) 🌸. for example, an MN may discover available access points using link-layer specific mechanisms (i.e., a "scan" in 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 a [AP-ID, AR-Info] tuple, and an MN can use it to detect movement readily: when attachment to an access point with AP-ID happens, 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 (see Section 6.1) are the ones used to help with movement detection 🎀.
through the RtSolPr and PrRtAdv messages, the MN also formulates a prospective new CoA (NCoA) while it is still present on the PAR's link 💖. so the latency from new prefix discovery after handover is eliminated, periodt 🙌. this prospective address can also be used immediately after attaching to the new subnet link (i.e., NAR's link) when the MN has received a "Fast Binding Acknowledgment (FBack)" message before it moved 🔥. if it moves without receiving an FBack, the MN can still start using NCoA after announcing its attachment through a "Fast Neighbor Advertisement (FNA)" message 🍓. NAR responds to FNA if the tentative address is already in use, which reduces NCoA configuration latency ⭐. under some limited conditions where the probability of address collision is considered insignificant, it may be possible to use NCoA immediately after attaching to the new link 🌈. even so, all implementations MUST support and SHOULD use the mechanism specified in this document to avoid potential address conflicts 🚨. not skipping this one, bestie 💀.
to cut down the Binding Update latency, the protocol specifies a tunnel between the Previous CoA (PCoA) and the NCoA 🫧. an MN sends a "Fast Binding Update" message to its Previous Access Router to set up this tunnel 💜. when feasible, the MN SHOULD send an FBU from PAR's link. otherwise, it should be sent immediately after attachment to NAR has been detected 🕰️. subsequent sections describe the protocol mechanics 📖. as a result, 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 PAR until it completes the Binding Update 🔁. PAR SHOULD forward the inner packet in the tunnel to its destination (i.e., to the MN's correspondent) 🎯. this reverse tunnel makes sure packets with PCoA as their source IP address aren't dropped by ingress filtering 🛡️. readers may notice that even though the MN is IP-capable on the new link, it cannot use NCoA directly with its correspondents until the correspondents first create a binding cache entry (for NCoA) 🙈. forwarding support for PCoA is provided through a reverse tunnel between the MN and the PAR 🌷.
setting up a tunnel alone doesn't guarantee the MN receives 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 a neighbor's address resolution (i.e., Neighbor Solicitation and Neighbor Advertisement) typically causes considerable delay, sometimes lasting multiple seconds 😩. for example, when arriving packets make NAR send Neighbor Solicitation before the MN attaches, later retransmissions of address resolution are spaced by a default period of one second each ⏳. to get around this delay, an MN announces its attachment through the FNA message, which lets the NAR consider the MN reachable 🙌. if there's no existing entry, FNA lets NAR create one 🧁. if NAR already has an entry, FNA updates it while taking potential address conflicts into account ⚖️. with tunnel establishment for PCoA and fast advertisement together, the protocol provides expedited forwarding of packets to the MN 🚀.
the protocol also has some other important functionality 💁. the access routers can exchange messages to confirm that a proposed NCoA is acceptable 🤝. for example, when an MN sends an FBU from 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 PAR before providing forwarding support for the MN 💜. that means it may create a forwarding entry for the NCoA subject to "approval" from PAR, which it trusts 👑. finally, the access routers could transfer network-resident contexts, such as access control, QoS, and header compression, along with the handover 🎁. for these operations, the protocol provides "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages 📬. Both of these messages MUST be supported and 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 🎀
the protocol begins when an MN sends an RtSolPr to its access router to resolve one or more Access Point Identifiers to subnet-specific information 🌸. in response, the access router (e.g., PAR in Figure 1) sends a PrRtAdv message containing one or more [AP-ID, AR-Info] tuples 💌. the MN may send a RtSolPr at any convenient time, for example as a response to some link-specific event (a "trigger") or simply after performing router discovery ⚡. however, the expectation is that before sending RtSolPr, the MN will have discovered the available APs by link-specific methods 🔍. the RtSolPr and PrRtAdv messages do not establish any state at the access router, and their packet formats are defined in Section 6.1 🧾.
with the information in the PrRtAdv message, the MN formulates a prospective NCoA and sends an FBU message when a link-specific handover event occurs 🦋. the whole point of the FBU is to authorize PAR to bind PCoA to NCoA, so arriving packets can be tunneled to the MN's new location 🚇. whenever feasible, the FBU SHOULD be sent from PAR's link 💅. for example, an internal link-specific trigger could make FBU transmission happen from the previous link 🎯. when that isn't feasible, the FBU is sent from the new link 🌈. care must be taken so the NCoA used in the FBU doesn't conflict with an address already in use by some other node on the link 🫣. for this, FBU encapsulation within FNA MUST be implemented and SHOULD be used (see below) when the FBU is sent from NAR's link 🛠️.
the format and semantics of FBU processing are specified in Section 6.3.1 📖.
depending on whether an FBack is received on the previous link (which clearly depends on whether the FBU was sent in the first place), there are two modes of operation 🔀.
- The MN receives an FBack on the previous link. This means packet tunneling is already in progress by the time the MN hands over to NAR 🚀. The MN SHOULD send FNA immediately after attaching to NAR, so arriving and buffered packets can be forwarded to the MN right away ✨.
Before sending an FBack to an MN, PAR can determine whether the NCoA is acceptable to the NAR through the exchange of HI and HAck messages 🤝. When assigned addressing (i.e., addresses are assigned by the router) is used, the proposed NCoA in the FBU is carried in HI, and the NAR MAY assign the proposed NCoA 🏠. Such an assigned NCoA MUST be returned in HAck, and the PAR MUST in turn provide the assigned NCoA in the FBack 📬. If there is an assigned NCoA returned in the FBack, the MN MUST use the assigned address (and not the proposed address in the FBU) upon attaching to NAR 🫶.
- The MN does not receive the FBack on the previous link, because the MN has not sent the FBU, or the MN has left the link after sending the FBU (which itself may be lost) but before receiving an FBack 😬. Without an FBack in the latter case, the MN cannot tell whether PAR has successfully processed the FBU 🤷♀️. so it (re)sends an FBU as soon as it attaches to NAR 🔁. to let NAR forward packets immediately (once the FBU has been processed) and to let NAR verify whether NCoA is acceptable, the MN SHOULD encapsulate the FBU in the FNA 📦. if NAR detects that NCoA is in use when processing the FNA, for instance while creating a neighbor entry, it MUST discard the inner FBU packet and send a Router Advertisement with the "Neighbor Advertisement Acknowledge (NAACK)" option, in which NAR MAY include an alternate IP address for the MN to use 🙅♀️. this discarding avoids the rare and undesirable outcome that comes from an address collision 💥. detailed FNA processing rules are in Section 6.3.3 📚.
the scenario where an MN sends an FBU and receives an FBack on PAR's link is shown in Figure 2 🖼️. for convenience, this is called the "predictive" mode of operation 🔮. the scenario where the MN sends an FBU from NAR's link is shown in Figure 3 🖼️. for convenience, this is called the "reactive" mode of operation ⚡. note that the reactive mode also covers the case where an FBU was sent from PAR's link but an FBack hasn't been received yet 🫠.
finally, the PrRtAdv message may be sent unsolicited (i.e., without the MN first sending a RtSolPr) 📨. this mode is described in Section 3.3 💜.
3.3. Protocol Operation of Network-initiated Handover ✨
okay so bestie, in some wireless technologies the handover control lives in the network 🌐, even though the decision to hand over is something the MN and the network agree on together 🫶. In these networks, the PAR can send an unsolicited PrRtAdv 💌 containing the link layer address, IP address, and subnet prefixes of the NAR 🎀 as soon as the network decides a handover is imminent. The MN MUST process this PrRtAdv to set up a new care of address on the new subnet 🏡, and it MUST send an FBU to the PAR before it switches to the new link 🚪. After sending the PrRtAdv, the PAR MUST keep forwarding packets to the MN on its current link until it gets the FBU 📦. The rest of the operation is the same as what we covered in Section 3.2 🦋, so no need to redo it 💅.
The unsolicited PrRtAdv is also giving the network main character energy 👑, because it lets the network tell the MN about geographically adjacent subnets without the MN having to ask for that info first 🧚. This can cut down on the amount of wireless traffic the MN needs in order to build a neighborhood topology map of links and subnets 🗺️✨. Honestly this usage of PrRtAdv is totally decoupled from the actual handover, so check out Section 6.1.2 for the deets 🙈.
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------FBU----------->|--------HI--------->|
| |<------HAck---------|
| <--FBack---|--FBack---> |
| | |
disconnect forward |
| packets===============>|
| | |
| | |
connect | |
| | |
|--------- FNA --------------------------->|
|<=================================== deliver packets
| |
Figure 2: "Predictive" Fast Handover4. Protocol Details ✨
okay bestie, everything in this section is about Figure 1 🎀 so keep it open in another tab, trust 💅
after the MN finds one or more nearby access points, it sends RtSolPr to turn those access point identifiers into subnet router info 🦋 doing this right after router discovery is super convenient, but the MN can send RtSolPr at any time, like when one or more new access points show up. it can even send it more than once while it's attached to the PAR 🔁 the trigger for RtSolPr can come from a link-specific event, like a new access point promising a better signal while the current one is fading 📉 those events are usually called "L2 triggers." they're outside the scope of this doc, but they still count as events that set this protocol off 🔥 for example, when a "link up" indication shows up on the new link, protocol messages (like FNA) can get sent right away. Implementations SHOULD make use of such triggers whenever possible 💖
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
disconnect | |
| | |
| | |
connect | |
|------FNA[FBU]-------|------------------->|
| |<-----FBU-----------|
| |------FBack-------->|
| forward |
| packets===============>|
| | |
|<=================================== deliver packets
| |
Figure 3: "Reactive" Fast HandoverThe RtSolPr message contains one or more AP-IDs. A wildcard requests all available tuples 🍓
when the PAR answers an RtSolPr, it sends back a PrRtAdv message that shows one of these possible situations 👑
- If the PAR doesn't have an entry for the new access point, it MUST respond saying 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 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 saying 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 (basically, give any
ntuples without going over the link MTU) 📏
when further protocol action is needed, some implementations MAY choose to start buffering copies of incoming packets at the PAR. if that FIFO buffering is used, the PAR MUST keep forwarding the packets to PCoA (so, buffer and forward) 📦 this buffering can be really useful when the MN leaves without sending the FBU from the PAR's link. The PAR SHOULD stop buffering after it processes the FBU message 🛑 the size of the buffer is an implementation-specific consideration.
how Access Routers swap info about their neighbors, so they can build Proxy Router Advertisements with info 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 link layer handover mechanism itself supplies the parameters the MN needs to send packets right after attaching to the NAR, using the above messages is optional on those links 🫶
after a PrRtAdv gets processed, the MN sends an FBU at a time decided by link-specific events, and it 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 it hasn't received an FBack, the MN sends an FBU right after attaching to the NAR's link. This FBU SHOULD be encapsulated in an FNA message 🎁 the encapsulation lets the NAR throw away the (inner) FBU packet if an address conflict shows up while it's processing the (outer) FNA packet (see FNA processing below) 💀
when the PAR gets the FBU, it sets up a binding between PCoA ("Home Address") and 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 an HAck back 🤝 to figure out the NAR's address for the HI message, the PAR can do the longest prefix match of NCoA (from the FBU) against the prefix list of neighboring access routers 🔍 when the source IP address of the FBU is PCoA (meaning the FBU came from the PAR's link), the HI message MUST have a Code value set to 0; see Section 6.2.1. when the source IP address of the FBU is not PCoA (meaning the FBU came from the NAR's link), the HI message MUST have a Code value of 1; see Section 6.2.1.
the HI message carries the PCoA, the Link-Layer Address, and the NCoA of the MN 📨 when the NAR processes an HI message with Code 0, it:
- figures out whether the NCoA in the HI message is a valid address to use. If it is, the NAR starts proxying [6] the address for PROXY_ND_LIFETIME, which is the window where the MN is expected to connect to the NAR ⏳ the NAR MAY use the Link-Layer Address to check whether a matching IP address exists in its forwarding tables.
- allocates NCoA for the MN when assigned addressing is used, creates a proxy neighbor cache entry, and starts defending it 🛡️ the NAR MAY allocate the NCoA proposed in the HI.
- MAY create a host route entry for PCoA in case 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 from the MN or by other means), arriving packets don't trigger neighbor discovery 🙅♀️ the NAR MAY 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 📬
when the Code value in the HI is 1, the NAR MUST skip the operations above, since it already did them during FNA processing 🙃 it SHOULD still be ready to process any other options that might be defined in the future. Sending an HI message with Code 1 lets the NAR validate the neighbor cache entry it made for the MN during FNA processing. Basically, 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 send the FBack to the previous link so it arrives faster in case the MN is still there. The end result of the FBU and FBack processing is that the PAR starts tunneling the MN's packets to NCoA 🚇 if the MN doesn't get an FBack even after resending the FBU for FBU_RETRIES, it must assume fast handover support isn't available and stop the protocol operation 😭
when the MN makes link connectivity with the NAR, it SHOULD send a Fast Neighbor Advertisement (FNA) message (see 6.3.3). If the MN hasn't received an FBack by the time the FNA is being sent, it SHOULD encapsulate the FBU in the FNA and send them together 📤
when the NCoA tied to the FNA message is acceptable, the NAR MUST:
- delete its proxy neighbor cache entry, if one exists.
- create a neighbor cache entry and set its state to REACHABLE, without overwriting an existing entry for a different layer 2 address.
- forward any buffered packets 🚀
- enable the host route entry for PCoA, if one exists.
when the NCoA tied to the FNA message is NOT acceptable (the NAR is in charge here, so it gets a whole list 😤), the NAR MUST:
- discard the inner (FBU) packet.
- send a Router Advertisement with the NAACK option, in which it MAY include an alternate NCoA to use. This message MUST be sent to the source IP address in the FNA, using the same Layer 2 address that was in the FNA 📡
if the MN gets a Router Advertisement with a NAACK option, it MUST use the IP address provided in the NAACK option, if there is one. Otherwise, the MN should configure another NCoA 🔄 after that, the MN SHOULD send an FBU using the new CoA. As a special case, the address supplied in the NAACK could be PCoA itself, and in that case the MN MUST NOT send any more FBUs 🛑
once the MN has confirmed its NCoA, it SHOULD send a Neighbor Advertisement message ✅ this lets the MN's neighbors update their neighbor cache entries with the MN's addresses 💌
just like in Mobile IPv6, the PAR sets the 'R' bit in the Prefix Information option and includes its 128-bit global address in the router advertisements 🌸 this lets mobile nodes learn the PAR's global IPv6 address. The MN reverse tunnels its packets to that same global address of the PAR, so the tunnel end-point addresses must be configured to match. When the PAR gets a reverse tunneled packet, it must verify that a secure binding exists for the MN (identified by the PCoA in the tunneled packet) before forwarding the packet 🔐
5. Miscellaneous ✨
5.1. Handover Capability Exchange
the MN expects a PrRtAdv in response to its RtSolPr message 🧚 if the MN doesn't receive a PrRtAdv message even after RTSOLPR_RETRIES, it must assume the PAR doesn't support the fast handover protocol, and stop sending RtSolPr messages 🥀
even if the MN's current access router can do fast handover, the new access router the MN attaches to might not be able to 🙃 this gets communicated to the MN at "runtime," through the PrRtAdv message with a Code value of 3 (see Section 6.1.2) 💜
5.2. Determining New Care of Address
usually, the MN works out its prospective NCoA from the info in a PrRtAdv message and then sends the FBU 💖 the PAR MUST use the NCoA in the FBU in its HI message. The NAR MUST check whether the NCoA in the HI is already in use. In any case, the NAR MUST respond to the HI with an HAck, and it may include another NCoA to use, especially when assigned address configuration is in play 🎯 if there's a CoA in the HAck, the PAR MUST include it in the FBack message 🫶
if a PrRtAdv message carries an NCoA, the MN MUST use it as its prospective NCoA ✨
5.3. Packet Loss 📦
Okay so handover involves link switching, and that doesn't always line up perfectly with fast handover signaling 🙈 Packets also show up at whatever pace they want, depending on tons of stuff like application characteristics, network queuing behaviors, etc. So packets can land at the NAR before the MN is even connected there 😭 Those packets get lost unless the NAR buffers them. Same drama in reverse: if the MN attaches to the NAR and then sends an FBU message, packets arriving at the PAR will be lost unless they're buffered too.
The protocol gives you an option to ask for buffering at the NAR in the HI message 🎀 And when the PAR asks for this feature for the MN, it SHOULD also offer its own buffering support. Be a good neighbor, bestie 🫶
5.4. DAD Handling 🔍
Duplicate Address Detection (DAD) was defined in [7] to avoid address duplication on links when stateless address auto-configuration is used. The catch is that running DAD to check an IPv6 address from stateless auto-configuration adds delays to a handover, and nobody wants that 💀
The chance of an interface identifier duplicating on the same subnet is very low, but ngl it can't be ignored. So this document proposes some precautions to minimize the effects if a duplicate address does pop up ✨
Sometimes the NAR already knows enough to check whether the MN's address is a duplicate before the MN even moves over. For example, the NAR might keep a list of all the nodes on its subnet (maybe for access control reasons), and by searching that list it can confirm whether the MN's address is a duplicate. The result of that search gets sent back to the PAR in the HAck message 💅 If the NAR doesn't have that knowledge, it can say so by not confirming the NCoA in the HAck message. The NAR can also signal this in the NAACK option in response to the FNA message. In those cases, the MN has to follow the address configuration procedure according to [6] after attaching to the NAR. Plot twist, but still manageable 🦋
5.5. Fast or Erroneous Movement 🏃♀️💨
Even though this spec is for fast handover, the protocol does have limits on how fast an MN can move 😤 Ping-Pong is a special case of fast movement, where an MN bounces rapidly between the same two access points. Another version of the same problem is erroneous movement, which means the MN gets info before a handover saying it's moving to a new access point, but then it either ends up at a different one or it aborts the move altogether. Most of these behaviors come from link layer idiosyncrasies, so they're usually sorted out at the link layer itself 🧚
IP layer mobility has its own limits, though 🥺 IP layer handovers should happen at a rate that gives the MN enough time to update the binding of, at least, its HA and ideally that of every CN it's talking to. If an MN moves faster than this signaling needs to finish (which can take a few seconds), it may start losing packets. The signaling cost over the air and in the network can also climb a lot, especially with rapid movement between several access routers. To avoid all that signaling overhead, here's what's suggested 🌈
An MN that returns to the PAR before updating its necessary bindings, while it's still present on the NAR, MUST send a Fast Binding Update to the PAR with the Home Address equal to the MN's PCoA and a lifetime of zero. The MN should have a security association with the PAR since it performed a fast handover to the NAR. When the PAR gets this Fast Binding Update, it checks its set of outgoing (temporary fast handover) tunnels. If it finds a match, it SHOULD tear down that tunnel, which means it stops forwarding packets for this MN and starts delivering them directly to the node instead ✨ Meanwhile, the MN SHOULD NOT try to use any of the fast handover mechanisms described in this specification, and it SHOULD revert back to standard Mobile IPv6 🙌
Temporary tunnels for fast handovers should have short lifetimes, like a small number of seconds or less. The lifetime should be long enough for the MN to update all its active bindings. The default lifetime of the tunnel should match the lifetime value in the FBU message 💜
Erroneous movement usually just means packet loss, because routing can change, and the PAR might forward packets toward another router before the MN actually connects to it 😬 If the MN discovers itself on an access router nobody expected, a Fast Binding Update to the PAR SHOULD be sent. Since Fast Binding Updates are authenticated, they supersede the existing binding, and packets MUST be redirected to the newly confirmed location of the MN 👑
6. Message Formats 📨
All the ICMPv6 messages share a common Type specified in [4]. The messages are told apart by the Subtype field (more on that below). The Subtype values are specified in Section 9. For all the ICMPv6 messages, the checksum is defined in [2] 🍓
6.1. New Neighborhood Discovery Messages 🏡
6.1.1. Router Solicitation for Proxy Advertisement (RtSolPr) 🎀
Mobile Nodes send Router Solicitation for Proxy Advertisement so they can prompt routers for Proxy Router Advertisements 💖 All the Link-Layer Address options follow 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 4: Router Solicitation for Proxy (RtSolPr) Message
IP 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. - Authentication Header: If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. See RFC 2402 [5].
ICMP Fields:
- Type: The Experimental Mobility Protocol Type. See [4].
- 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 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 with all bits set to zero.
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they don't recognize and keep 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 a 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 a RtSolPr. If that message doesn't arrive 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), the MN SHOULD resend the RtSolPr message. Retransmissions after that can go up to RTSOLPR_RETRIES, but they MUST use an exponential backoff, where the timeout period (i.e., 2xRTT or 100 milliseconds) doubles before each retransmission. If a Proxy Router Advertisement still hasn't arrived by the time the MN disconnects from the PAR, the MN SHOULD send an FBU immediately after configuring a new CoA 😭
When RtSolPr messages get sent more than once, they MUST be rate limited to MAX_RTSOLPR_RATE per second. During each use of a RtSolPr, exponential backoff is used for retransmissions 🌸
6.1.2. Proxy Router Advertisement (PrRtAdv) 🎀
Okay so access routers send Proxy Router Advertisement messages 💌 in two cases: gratuitously, when the handover is network-initiated, or as a reply to a RtSolPr message from an MN. Either way, it hands over the Link-Layer Address, IP address, and subnet prefixes of the neighboring routers. Every Link-Layer Address option uses the format from Section 6.4.3. Iconic. ✨
IP Fields:
- Source Address: MUST be the Link-Local Address assigned to the interface this message is sent from. 🫶
- Destination Address: The Source Address of the Router Solicitation for a Proxy Advertisement that invoked this, or the address of the node the Access Router is telling to hand over. 💅
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) Message- Hop Limit:
255. See RFC 2461 [6]. 🌸 - Authentication Header: If a Security Association for the IP Authentication Header exists between the sender and the destination address, the sender SHOULD include this header. See RFC 2402 [5]. 🔐
ICMP Fields:
- Type: The Experimental Mobility Protocol Type. See RFC 4065 [4]. 🦋
- Code:
0,1,2,3or4. More on these 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 this order:
- Source Link-Layer Address: When it's known, the sender's Link-Layer Address SHOULD be included using the Link-Layer Address option. Check the LLA option format below. ✨
- New Access Point Link-Layer Address: This is the Link-Layer Address or identification of the access point, copied from the RtSolPr message. This option MUST be present. 📍
- New Router's Link-Layer Address: The Link-Layer Address of the Access Router this message is proxied for. This option MUST be included when Code is 0 or 1. 🌈
- New Router's IP Address: The IP address of NAR. This option MUST be included when Code is 0 or 1. 💖
- New Router Prefix Information Option: This one specifies the prefix of the Access Router the message is proxied for, and it's used for address auto-configuration. This option MUST be included when Code is 0 or 1. However, if this prefix is the same as the one in the New Router's IP Address option above, the Prefix Information option doesn't need to be there. 🧁
- New CoA Option: MAY be present when a PrRtAdv is sent unsolicited. PAR MAY compute a new CoA using NAR's prefix information and the MN's L2 address, or by any other means. 🪄
Future versions of this protocol might define new option types. Receivers MUST silently ignore any options they don't recognize and keep processing the message. Lowkey the most chill rule ever. 🫧
Right now, Code values 0, 1, 2, 3 and 4 are defined. 🎯
Code 0 means the MN should use the [AP-ID, AR-Info] tuple (the ones 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, which reflects the LLA of the access point the rest of the options relate to. You can have multiple tuples. 🧩
Code 1 means the message was sent unsolicited. If a New CoA option shows up right after the New Router Prefix Information option, the MN SHOULD use that supplied NCoA and send the FBU immediately, or else it stands to lose service. 😭 This message works as a network-initiated handover trigger, so see Section 3.3. The Option-Code field in the New Access Point LLA option (see below) is 1 here too, reflecting the LLA of the access point the rest of the options relate to. 🚀
Code 2 means there's no new router information. Each New Access Point LLA option carries an Option-Code value (described below) that tells you a specific outcome. 💅
- When the Option-Code field in the New Access Point LLA option is
5, handing over to that access point doesn't need a CoA change. No other options are needed in this case. 🦋 - When the Option-Code field in the New Access Point LLA option is
6, the PAR doesn't know about the Prefix Information that was requested. The MN SHOULD attempt to send an FBU as soon as it gets connectivity back with the NAR. No other options are needed in this case. 🌷 - When the Option-Code field in the New Access Point LLA option is
7, it means the NAR doesn't support fast handover. The MN MUST stop fast handover protocol operations. No other options are needed in this case. 🛑
Code 3 means new router information is only present for a subset of the access points requested. The Option-Code field values (the ones defined above, including 1) tell apart the different outcomes for each individual access point. 🔍
Code 4 means the subnet information about neighboring access points is sent unsolicited, but it's not a handover trigger, unlike Code 1. You can have multiple tuples. 🌙
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 that match the PAR's neighborhood. This is the "give me everything" move. 👑
6.2. Inter-Access Router Messages 🦋
6.2.1. Handover Initiate (HI) 🌈
The Handover Initiate (HI) is an ICMPv6 message an Access Router (usually the PAR) sends to another Access Router (usually the NAR) to kick off the handover process for an MN. Main character energy. 🎬
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 |S|U| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: Handover Initiate (HI) MessageIP Fields:
- Source Address: The IP address of the PAR. 🧚
- Destination Address: The IP address of the NAR. 💖
- Hop Limit:
255. See RFC 2461 [6]. 🌸 - Authentication Header: The authentication header MUST be used when this message is sent. See RFC 2402 [5]. 🔐
ICMP Fields:
- Type: The Experimental Mobility Protocol Type. See RFC 4065 [4]. 🦋
- Code:
0or1. See below. 🍓 - Checksum: The ICMPv6 checksum. 🧁
- Subtype:
4💜 - S flag: Assigned address configuration flag. When it's set, this message asks the destination to return a new CoA. It can be set when Code =
0. MUST be0when Code =1. ✨ - U flag: Buffer flag. When it's set, the destination SHOULD buffer any packets heading toward the node indicated in this message's options. It's used when Code =
0, and SHOULD be set to0when Code =1. 🫧 - Reserved: MUST be set to zero by the sender and ignored by the receiver. 🙈
- Identifier: MUST be set by the sender so replies can be matched to this message. 🎀
Valid Options:
- Link-Layer Address of MN: The Link-Layer Address of the MN that's handing over to the destination (aka the NAR). This option MUST be included so the destination can recognize the MN. 🪪
- Previous Care of Address: The IP address the MN was using while attached to the originating router. This option SHOULD be included so a host route can be set up if it's needed. 🛤️
- New Care of Address: The IP address the MN wants to use once it's connected to the destination. When the
Sbit is set, the NAR MAY assign this address. 🌟
The PAR uses a Code value of 0 when it processes an FBU whose source IP address is PCoA. It uses a Code value of 1 when the FBU's source IP address is not PCoA. Tiny detail, huge difference. 🔍
If a Handover Acknowledge (HAck) message isn't received as a response within a short time period (no less than twice the typical RTT between source and destination, or 100 milliseconds if the RTT isn't known), the Handover Initiate SHOULD be resent. Subsequent retransmissions can go up to HI_RETRIES, but they MUST use exponential backoff, where the timeout period (aka 2xRTT or 100 milliseconds) doubles with each retransmission. Patience is a whole vibe, bestie. 🐢💅
6.2.2. Handover Acknowledge (HAck) 🦋
okay bestie, the Handover Acknowledgment message is a brand new ICMPv6 message ✨ and it MUST be sent (typically by NAR to PAR) as the reply to a Handover Initiate message. it's literally the answer to the HI, so it has to show up 💅
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 7: Handover Acknowledge (HAck) MessageIP Fields (the vibes are immaculate 🌸)
Source Address: copied from the destination address of the Handover Initiate Message this message is responding to.Destination Address: copied from the source address of the Handover Initiate Message this message is responding to.Hop Limit: 255. See RFC 2461 [6].Authentication Header: the authentication header MUST be used when this message is sent. See RFC 2402 [5]. 🔐
ICMP Fields 🧚
Type: the Experimental Mobility Protocol Type. See RFC 4065 [4].Code: the possible values are listed below.
0: Handover Accepted, NCoA valid
1: Handover Accepted, NCoA not valid
2: Handover Accepted, NCoA in use
3: Handover Accepted, NCoA assigned
(used in Assigned addressing)
4: Handover Accepted, NCoA not assigned
(used in Assigned addressing)
128: Handover Not Accepted, reason unspecified
129: Administratively prohibited
130: Insufficient resourcesChecksum: the ICMPv6 checksum.Subtype: 5Reserved: MUST be set to zero by the sender and ignored by the receiver. 🙈Identifier: copied from the corresponding field in the Handover Initiate message this message is responding to.
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 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. 🍓
Okay now the rules, and these are the important bits so pay attention 👑
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 MAY provide support for PCoA (instead of accepting or assigning NCoA), establish a host route entry for PCoA, and set up a tunnel to the PAR to forward MN's packets sent with 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. ✨
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 should indicate the reason in one of the available Code values. no cap, that's a whole power move 😭
6.3. New Mobility Header Messages 🎀
Mobile IPv6 uses a new IPv6 header type called Mobility Header [3]. The Fast Binding Update, Fast Binding Acknowledgment, and Fast Neighbor Advertisement messages use the Mobility Header. It's the header that these three messages all share, bestie 💖
6.3.1. Fast Binding Update (FBU) 🦋
The Fast Binding Update message is identical to the Mobile IPv6 Binding Update (BU) message. However, the processing rules are slightly different. the rules are the only thing that's different, so the vibe is basically the same 💅
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Fast Binding Update (FBU) MessageIP fields 🌸
Source Address: the PCoA or NCoADestination Address: the IP address of the Previous Access RouterA flag: MUST be set to one to request that PAR send a Fast Binding Acknowledgment message. 🙌H flag: MUST be set to one. See RFC 3775 [3].L flag: see RFC 3775 [3].K flag: see RFC 3775 [3].Reserved: this field is unused. MUST be set zero.Sequence Number: see RFC 3775 [3].Lifetime: see RFC 3775 [3].Mobility Options: MUST contain an alternate CoA option set to the NCoA when an FBU is sent from PAR's link. 🧚
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 NCoA on the NAR according to Neighbor Discovery and IPv6 Address Configuration protocols. the timing is everything, periodt ⏰
The source IP address is PCoA when the FBU is sent from PAR's link, and the source IP address is NCoA when sent from NAR's link. When the FBU is sent from NAR's link, it SHOULD be encapsulated within an FNA. 🦋
The FBU MUST also include the Home Address Option, and the Home Address is PCoA. An FBU message MUST be protected so that PAR is able to determine that the FBU message is sent by a genuine MN. security is not optional, bestie 🔥
6.3.2. Fast Binding Acknowledgment (FBack) 🌈
The Fast Binding Acknowledgment message is sent by the PAR to acknowledge receipt of a Fast Binding Update message in which the 'A' bit is set. The Fast Binding Acknowledgment message SHOULD NOT be sent to the MN before the PAR receives a HAck message from the NAR. The Fast Binding Acknowledgment MAY also be sent to the MN on the old link. so the PAR waits for the HAck first, that's the whole move 🫶
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 NCoAStatus: an 8-bit unsigned integer indicating the disposition of the Fast Binding Update. Values of the Status field that are less than 128 indicate that the Binding Update was accepted by the receiving node. The following such Status values are currently defined:
0 Fast Binding Update accepted
1 Fast Binding Update accepted but NCoA is
invalid. Use NCoA supplied in "alternate" CoAValues of the Status field that are greater than or equal to 128 indicate that the Binding Update was rejected by the receiving node. The following such Status values are currently defined:
128 Reason unspecified
129 Administratively prohibited
130 Insufficient resources
131 Incorrect interface identifier lengthK' flag: see RFC 3775 [3].Reserved: an unused field. MUST be set to zero.Sequence Number: copied from the FBU message for use by the MN in matching this acknowledgment with an outstanding FBU. 🎀Lifetime: the granted lifetime in seconds for which the sender of this message will retain a binding for traffic redirection.Mobility Options: MUST contain an "alternate" CoA if Status is 1.
6.3.3. Fast Neighbor Advertisement (FNA) ✨
A MN sends a Fast Neighbor Advertisement to announce itself to the NAR. When the Mobility Header Type is FNA, the Payload Proto field may be set to IPv6 to assist FBU encapsulation. the FNA is basically the "hi, I'm here now" message 🧚
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Fast Neighbor Advertisement (FNA) MessageIP fields 🌸
Source Address: NCoADestination Address: NAR's IP AddressMobility Options: MUST contain the Mobility Header Link-Layer Address of the MN in the MH-LLA option format. See Section 6.4.4. 🔥
The MN sends a Fast Neighbor Advertisement to the NAR, as soon as it regains connectivity on the new link. Arriving or buffered packets can be immediately forwarded. If NAR is proxying NCoA, it creates a neighbor cache entry in REACHABLE state. If there is no entry, it creates one and sets it to REACHABLE. If there is an entry in the INCOMPLETE state without a Link-Layer Address, it sets it to REACHABLE. During the process of creating a neighbor cache entry, NAR can also detect if NCoA is in use, thus avoiding address collisions. Since the FBU is encapsulated within the FNA when sent from NAR's link, NAR drops the FBU if it detects a collision. ✨
The combination of NCoA (present in source IP address) and the Link-Layer Address (present as a Mobility Option) SHOULD be used to distinguish the MN from other nodes. 🫶
6.4. New Options 🎀
Okay so every option in here follows the same shape, shown in Figure 11 🧚 The Type values come from the Neighbor Discovery options space, and the Length field counts in units of 8 octets. The one exception is the Mobility Header Link-Layer Address option, which counts plain octets instead, in line with Section 6.2 in [3]. Option-Code gives extra info for each option, so check the individual ones 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 11: Option Format
6.4.1. IP Address Option 🌸
This option gets sent in the PrRtAdv, HI, and HAck messages, so it's giving "pass the address around" energy 💌
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 12: IPv6 Address Option
Type: 17Length: the size of this option in 8 octets, including theType,Option-Code, andLengthfields.Option-Code: there are three possible values:1: Old Care-of Address2: New Care-of Address3: NAR's IP address
Prefix Length: the Length of the IPv6 Address Prefix.Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver. 🫶IPv6 Address: the IP address for the unit defined by theTypefield.
6.4.2. New Router Prefix Information Option 🦋
This option gets sent in the PrRtAdv message to hand over the prefix info that's valid on the NAR 🌈
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 13: New Router Prefix Information Option
Type: 18Length: the size of this option in 8 octets, including theType,Option-Code, andLengthfields.Option-Code:0Prefix Length: an 8-bit unsigned integer. It's the number of leading bits in the Prefix that are valid. The value ranges from 0 to 128.Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver. 💅Prefix: an IP address or a prefix of an IP address. ThePrefix Lengthfield holds 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. 🧚
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 14: Link-Layer Address Option
Type: 19Length: the size of this option in 8 octets, including theType,Option-Code, andLengthfields.Option-Code: there are eight possible values, so pay attention bestie 👀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 the 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 handovers support available for the access point identified by the LLA
LLA: the variable length Link-Layer Address.
Depending on the size of the individual LLA option, appropriate padding MUST be used so the entire option size is a multiple of 8 octets. Important, don't skip it 🙈
The New Access Point Link-Layer Address holds the Link-Layer Address of the access point that a handover is about to be attempted on. It gets used in the Router Solicitation for the 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 option is basically the LLA option, but it rides in the Mobility Header messages (like the FNA). Other Mobility Header messages might use it down the road too. For example, putting this option in the FBU lets the PAR grab the MN's LLA super easily 🫶 When the LLA is 6 bytes, the format looks like Figure 15. When the LLA size is different, the option MUST be aligned appropriately. See Section 6.2 in [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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Code | Pad0=0 | LLA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 15: Mobility Header Link-Layer Address Option
Type: 7Length: the size of this option in octets, not including theType,Length, andOption-Codefields.Option-Code:2, the Link-Layer Address of the MNLLA: the variable length Link-Layer Address.
6.4.5. 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 Option
Type: 20Length: an 8-bit unsigned integer, the length of the option in 8 octets. It's 1 when NCoA isn't supplied, and 3 when NCoA is supplied (right after theReservedfield).Option-Code:0Status: an 8-bit unsigned integer showing what happened to the Fast Neighbor Advertisement message. These values are currently defined:1: The New CoA is invalid.2: The New CoA is invalid; use the supplied CoA. The New CoA MUST be present following theReservedfield.128: Link Layer Address unrecognized.
Reserved: MUST be set to zero by the sender and MUST be ignored by the receiver.
The NAR answers the FNA with the NAACK option to tell the MN to use a different NCoA if there's an address collision 😭 If the NCoA is invalid, the Router Advertisement MUST use the NCoA as the destination address, but use the L2 address that was in the FNA. The MN SHOULD use the NCoA if it's supplied with the NAACK option. If the NAACK says the Link-Layer Address is unrecognized, the MN MUST NOT use the NCoA or PCoA and SHOULD start the process of acquiring an NCoA at the NAR immediately. Main character energy for the MN, the whole point is to move on fast 🏃♀️
New option types may be defined in the future 🌈
7. Configurable Parameters 👑
Here's the cheat sheet for the configurable parameters, with their default values and where they're defined 📝
Parameter Name Default Value Definition
------------------- ---------------------- -------
RTSOLPR_RETRIES 3 Section 6.1.1
MAX_RTSOLPR_RATE 3 Section 6.1.1
FBU_RETRIES 3 Section 4
PROXY_ND_LIFETIME 1.5 seconds Section 6.2.2
HI_RETRIES 3 Section 6.2.18. Security Considerations 🔐
okay bestie, this is the scary-but-important part 😭 the RFC lists the security holes they found and the fixes they suggest. no cap, you need to read this one carefully.
- Insecure FBU 💀: packets meant for one address could get stolen or redirected to some unsuspecting node. this concern is the same as the one between an MN and its Home Agent 🫶
so 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 set up a security association, and that security association MUST be used to secure FBU. the current version of this protocol doesn't say how that security association gets established, but future work may specify it ✨
if an access router can make sure the source IP address in an arriving packet could only have come from the node whose Link-Layer Address is in the router's neighbor cache, then a bogus node can't use a victim's IP address to redirect traffic maliciously. they recommend doing this at least on neighbor discovery messages, including the RtSolPr message 🌸
- Secure FBU, malicious or inadvertent redirection 🙈: here the FBU is secured, but the binding target happens to be an unsuspecting node, either by accident or on purpose. this can lead to an MN with a genuine security association with its access router redirecting traffic to the wrong address. ngl that's a lot
BUT the target of malicious redirection is limited to an interface on an access router that the PAR has a security association with 🛡️ the PAR MUST verify that the NCoA the PCoA is being bound to actually belongs to the NAR's prefix. to do this, the HI and HAck message exchanges are used. when the NAR accepts NCoA in HI (with Code = 0), it proxies NCoA so that arriving packets aren't sent on the link until the MN attaches and announces itself through FNA. so any inadvertent or malicious redirection to a host gets avoided ✨
it's still possible to jam the NAR's buffer with redirected traffic, though. the NAR's handover state for NCoA has a finite (and short) lifetime, which is a small multiple of the anticipated handover latency, so the extent of this vulnerability is arguably small 🦋
- Sending an FBU from the NAR's link 👀: a malicious node may send an FBU from the NAR's link and give an unsuspecting node's address as the NCoA. since the FBU gets encapsulated in the FNA, the NAR should detect the collision with an address already in use when it processes the FNA, and then drop the FBU. but when the NAR can't detect address collisions, there's a vulnerability where redirection can affect an unsuspecting node 😭
9. IANA Considerations 🎀
this part is all about the number assignments! this document defines four new experimental ICMPv6 messages that use the Experimental Mobility Protocol ICMPv6 format [4]. these four new Subtype values come out of the Experimental Mobility Protocol Subtype Registry [4] and were assigned like this:
Subtype Description Reference
------- ----------- ---------
2 RtSolPr Section 6.1.1
3 PrRtAdv Section 6.1.2
4 HI Section 6.2.1
5 HAck Section 6.2.2this document also defines four new Neighbor Discovery [6] options that got Type assignments from IANA 💖
Option-Type Description Reference
----------- ----------- ---------
17 IP Address Option Section 6.4.1
18 New Router Prefix
Information Option Section 6.4.2
19 Link-Layer Address
Option Section 6.4.3
20 Neighbor Advertisement
Acknowledgment Option Section 6.4.5three new Mobility Header messages got type allocations from the Mobility Header Types registry at http://www.iana.org/assignments/mobility-parameters 🦋
- Fast Binding Update, described in Section 6.3.1
- Fast Binding Acknowledgment, described in Section 6.3.2, and
- Fast Neighbor Advertisement, described in Section 6.3.3.
and finally, one new Mobility Option got type assignments from the Mobility Options Type registry at http://www.iana.org/assignments/mobility-parameters 🧚
- Mobility Header Link-Layer Address option, described in Section 6.4.4.
10. Acknowledgments 🫶
the editor wants to thank everyone who gave feedback on this spec, but can only name a few here: Martin Andre, Vijay Devarapalli, Youn-Hee Han, Emil Ivov, Suvidh Mathur, Koshiro Mitsuya, Gabriel Montenegro, Takeshi Ogawa, Sun Peng, YC Peng, Domagoj Premec, and Jonathan Wood 💜 the editor also wants to acknowledge a contribution from James Kempf that improved this spec. and a big thank-you to 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 👑
11. Normative References 📚
these are the must-read docs this spec leans on:
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[4] Kempf, J., "Instructions for Seamoby and Experimental Mobility
Protocol IANA Allocations", RFC 4065, July 2005.
[5] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[6] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[7] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.12. Contributors 🌈
this doc started out in the fast handover design team effort 🚀 the members of that design team, in alphabetical order, were: Gopal Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis, and Alper Yegin ✨
here's how to reach the design team members:
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone:+1 408 525 1404
EMail: gdommety@cisco.com
Karim El Malki
Ericsson Radio Systems AB
LM Ericssons Vag. 8
126 25 Stockholm
SWEDEN
Phone: +46 8 7195803
Fax: +46 8 7190170
EMail: Karim.El-Malki@era.ericsson.se
Mohamed Khalil
Nortel Networks
EMail: mkhalil@nortelnetworks.com
Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
Fax: +1 650 625-2502
EMail: charliep@iprg.nokia.com
Hesham Soliman
Flarion Technologies
EMail: H.Soliman@flarion.com
George Tsirtsis
Flarion Technologies
EMail: G.Tsirtsis@flarion.com
Alper E. Yegin
Samsung Advanced Institute of Technology
75 West Plumeria Drive
San Jose, CA 95134
USA
Phone: +1 408 544 5656
EMail: alper.yegin@samsung.comAuthor's Address 💅
Rajeev Koodli, Editor
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043 USA
Phone: +1 650 625 2359
Fax: +1 650 625 2502
EMail: Rajeev.Koodli@nokia.comFull Copyright Statement ⭐
Copyright (C) The Internet Society (2005) 🦋
this document is subject to the rights, licenses and restrictions in BCP 78. except as set out there, the authors keep all their rights. the document and the info in it are provided on an "AS IS" basis, and the warranty stuff is legally serious, so here it is word for word:
THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property 🔍
the IETF doesn't take a position on whether any Intellectual Property Rights or other rights claimed around the tech in this doc are valid or in scope, or whether a license for them is available. it also doesn't claim to have independently searched for any such rights. info on how rights work for RFC docs lives in BCP 78 and BCP 79 🌸
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses that will be made available, and the results of any attempt to get a general license or permission for implementers or users to use proprietary rights can be found in the IETF online IPR repository at http://www.ietf.org/ipr 💖
the IETF invites anyone to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that might cover tech required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 📬
Acknowledgement 💜
funding for the RFC Editor function is currently provided by the Internet Society. thank you, Internet Society 🫶✨
📦 where this page comes from
- ietf: rfc4068 2005-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms