RFC 5268
Mobile IPv6 Fast Handovers
RFC 5268: Mobile IPv6 Fast Handovers 🦋
Okay bestie, this one is RFC 5268, and it's giving fast. 🚀 It's written by R. Koodli, Ed., from Starent Networks. It's dated June 2008 and it's a Standards Track doc, so it's an actual official protocol 👑. It obsoletes RFC 4068, which means this is the newer, glow-up version of that spec 💅.
Status of This Memo ✨
This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬. If you want to know where this protocol stands in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.
Abstract 🎀
Mobile IPv6 lets a Mobile Node (MN) stay connected to the Internet while it moves from one Access Router to another. That move is called a handover 🚶♀️. During a handover there's a stretch of time where the Mobile Node can't send or receive packets, because of link switching delay and IP protocol operations 😭. This "handover latency" comes from the standard Mobile IPv6 steps: movement detection, new Care-of Address configuration, and Binding Update. It's honestly too much lag for real-time stuff like Voice over IP (VoIP) 📞💀. Non-real-time, throughput-sensitive apps would benefit from less latency too 🍓.
This doc specifies a protocol that improves the handover latency caused by Mobile IPv6 procedures 🧚. It does not address improving the link switching latency 🙈.
Table of Contents 🗂️
1. Introduction ....................................................3
2. Terminology .....................................................3
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 ...............................................11
5. Other Considerations ...........................................15
5.1. Handover Capability Exchange ..............................15
5.2. Determining New Care-of Address ...........................16
5.3. Prefix Management .........................................16
5.4. Packet Loss ...............................................17
5.5. DAD Handling ..............................................18
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. Inter - Access Router Messages ............................25
6.2.1. Handover Initiate (HI) .............................25
6.2.2. Handover Acknowledge (HAck) ........................27
6.3. New Mobility Header Messages ..............................28
6.3.1. Fast Binding Update (FBU) ..........................28
6.3.2. Fast Binding Acknowledgment (FBack) ................30
6.4. Unsolicited Neighbor Advertisement (UNA) ..................31
6.5. New Options ...............................................32
6.5.1. IP Address/Prefix Option ...........................33
6.5.2. Link-Layer Address (LLA) Option ....................34
6.5.3. Mobility Header Link-Layer Address (MH-LLA)
Option .............................................35
6.5.4. Binding Authorization Data for FMIPv6 (BADF) .......35
6.5.5. Neighbor Advertisement Acknowledgment (NAACK) ......36
7. Related Protocol and Device Considerations .....................37
8. Evolution from and Compatibility with RFC 4068 .................38
9. Configurable Parameters ........................................39
10. Security Considerations .......................................39
10.1. Peer Authorization Database Entries when Using IKEv2 .....41
10.2. Security Policy Database Entries .........................42
11. IANA Considerations ...........................................42
12. Acknowledgments ...............................................43
13. References ....................................................44
13.1. Normative References .....................................44
13.2. Informative References ...................................45
Appendix A. Contributors ..........................................46
Appendix B. Changes since RFC 4068 ................................461. Introduction 🌸
Mobile IPv6 [RFC3775] has all the protocol operations a mobile node needs to stay connected to the Internet while it hops from one access router to another 🏃♀️. Those operations include link-layer procedures, movement detection, IP address configuration, and location update 🗺️. Put together, the handover latency is often enough to mess with real-time apps 😩. Throughput-sensitive apps can also benefit from less latency ✨. So this doc describes a protocol that cuts down that handover latency 💅.
This spec tackles two problems. The first is how to let a mobile node send packets as soon as it detects a new subnet link 📡. The second is how to deliver packets to a mobile node as soon as the new access router detects that it's attached 🎯. The protocol defines the IP protocol messages it needs to work, no matter what link technology is in play 🔌. It doesn't depend on specific link-layer features, but it still allows link-specific customizations 🎀. By definition, this spec looks at handovers that interwork with Mobile IP 🤝. Once the MN attaches to its new access router, it runs its Mobile IP operations, including Return Routability [RFC3775] 🔁. There are no special requirements for a mobile node to act differently from its standard Mobile IP operations 🙌.
This spec applies when a mobile node has to do IP layer operations because of a handover 🎯. It does not address improving the link switching latency 🙈. It also doesn't modify or optimize procedures for signaling with the home agent of a mobile node 🏠. Even though it's aimed at Mobile IPv6, it could be used with any mechanism that lets communication continue despite movement 🦋. And finally, this spec does not address bulk movement of nodes using aggregate prefixes 🚫.
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 [RFC2119] 💜. The term "silently ignore" isn't defined in RFC 2119, but this doc uses it anyway, and it should be read in a similar way 🤷♀️.
This doc uses the terms and abbreviations defined in [RFC3775], plus the ones below 📚. The reference handover scenario is shown 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 gives an MN wireless connectivity 📶. An Access Point Identifier (AP-ID) refers to the AP's L2 address. Sometimes the AP-ID is also called a Basic Service Set IDentifier (BSSID) 🆔.
Access Router (AR): The MN's default router 🛣️.
Previous Access Router (PAR): The MN's default router before its handover 👈.
New Access Router (NAR): The MN's expected default router after its handover 👉.
Previous CoA (PCoA): The MN's Care-of Address that's valid on the PAR's subnet 🏡.
New CoA (NCoA): The MN's Care-of Address that's valid on the NAR's subnet 🏘️.
Handover: The process of ending existing connectivity and getting new IP connectivity 🔄.
Router Solicitation for Proxy Advertisement (RtSolPr): A message from the MN to the PAR asking for info about a potential handover 🙋♀️.
Proxy Router Advertisement (PrRtAdv): A message from the PAR to the MN that shares info about neighboring links, which helps speed up movement detection ⚡. It can also act as a trigger for a network-initiated handover 🚨.
(AP-ID, AR-Info) tuple: Holds an access router's L2 and IP addresses, plus the prefix that's valid on the interface where the Access Point (identified by the AP-ID) is attached 🧩. The triplet of [Router's L2 address, Router's IP address, and Prefix] is called "AR-Info". See Section 5.3 💅.
Neighborhood Discovery: The process of resolving neighborhood AP-IDs into AR-Info 🔍.
Assigned Addressing: A specific type of NCoA configuration where the NAR assigns an IPv6 address to the MN 🎁. How the NAR manages its address pool isn't specified in this document 🤐.
Fast Binding Update (FBU): A message from the MN telling its PAR to redirect its traffic (toward the NAR) 🏃♀️💨.
Fast Binding Acknowledgment (FBack): A message from the PAR sent in response to an FBU 💌.
Predictive Fast Handover: A fast handover where the MN can send an FBU while it's still attached to the PAR. The PAR then sets up forwarding for its traffic, even before the MN attaches to the NAR 🔮.
Reactive Fast Handover: A fast handover where the MN can only send the FBU after it has attached 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 💖.
Handover Initiate (HI): A message from the PAR to the NAR about an MN's handover 📨.
Handover Acknowledge (HAck): A message from the NAR to the PAR in response to an HI ✅.
3.1. Addressing the Handover Latency
okay bestie, let's talk about the lag 😭🫶 when you hop onto a new subnet, your "IP connectivity" latency is basically the sum of two things: the movement detection latency and the new CoA configuration latency. once the MN is IP-capable on the new link, it can send a Binding Update to its Home Agent and one or more correspondents. then, once those correspondents process the Binding Update successfully (which usually means the Return Routability procedure, ngl it's a whole process 💅), the MN can finally receive packets at its new CoA. so receiving packets straight at the new CoA depends on the Binding Update latency plus the IP connectivity latency. it's giving compounding delays 🌸
now here's the glow-up 🦋 the protocol lets an MN detect that it has moved before it actually moves, by handing over the new access point and its subnet prefix info while the MN is still connected to its current subnet (that's the PAR in Figure 1). the MN can find nearby access points with link-layer stuff (like a "scan" in Wireless Local Area Network (WLAN)) and then ask for subnet info for one or more of them. it can do this after router discovery, or any time while it's still connected to its current router. resolving an access point identifier gives you an [AP-ID, AR-Info] tuple, and that's what lets the MN spot movement early 👑 once it attaches to the access point with that AP-ID, it already knows the new router's coordinates: prefix, IP address, and L2 address. the "Router Solicitation for Proxy Advertisement (RtSolPr)" and "Proxy Router Advertisement (PrRtAdv)" messages in Section 6.1 are the ones doing this detection help 🧚
the RtSolPr and PrRtAdv messages also let the MN work out a prospective new CoA (NCoA) while it's still on the PAR's link. which means no new prefix discovery after the handover, so that latency is just gone 🎀 and this prospective address can be used right away after attaching to the new link (the NAR's link), as long as the MN got a "Fast Binding Acknowledgment (FBack)" (see Section 6.3.2) before it moved. if it moves without an FBack, no panic 💀 it can still start using NCoA after sending an unsolicited Neighbor Advertisement announcing its attachment, with the 'O' bit set to zero [RFC4861]. the NAR responds to this UNA message only if it wants to give the MN a different IP address to use. so NCoA configuration latency gets reduced either way 🌈
the PrRtAdv info is still useful even when DHCP [RFC3315] is what configures the NCoA on the NAR's link 🙈 in that case the protocol supports forwarding using PCoA, and the MN runs DHCP once it's attached to the NAR's link. the MN still formulates an NCoA for FBU processing, BUT it MUST NOT send data packets using the NCoA in the FBU. no sending from the NCoA in that FBU, periodt 💅
to cut down the Binding Update latency, the protocol sets up a binding between the Previous CoA (PCoA) and the NCoA. the MN sends a "Fast Binding Update" (see Section 6.3.1) message to its Previous Access Router to build this tunnel 🦋 if it can, the MN SHOULD send that FBU from the PAR's link. otherwise, it should send the FBU right after detecting attachment to the NAR. an FBU MUST contain the Binding Authorization Data for FMIPv6 (BADF) option (see Section 6.5.4) so that only a legit MN that owns the PCoA can set up the binding. the later sections explain the mechanics, but the end result is the same: the PAR starts tunneling packets that arrive for PCoA over to NCoA 🫶 that tunnel stays up until the MN finishes its Binding Update with its correspondents. going the other way, the MN SHOULD reverse tunnel packets back to the PAR, again until the Binding Update is complete. and the PAR MUST forward the inner packet in the tunnel to its destination (aka the MN's correspondent). this reverse tunnel is what keeps packets with a PCoA source IP from getting dropped by ingress filtering, which is so important bestie ✨ even though the MN is IP-capable on the new link, it can't use the NCoA directly with correspondents until they've set up a binding cache entry for the NCoA. so forwarding support for the PCoA comes through a reverse tunnel between the MN and the PAR 💜
setting up that tunnel alone doesn't guarantee the MN gets packets the moment it attaches to the new link, unless the NAR can actually detect the MN's presence 😭 the usual neighbor discovery stuff (Neighbor Solicitation and Neighbor Advertisement for address resolution) can take a while, sometimes multiple seconds. like, if arriving packets make the NAR send a Neighbor Solicitation before the MN is even attached, the retransmissions are spaced by a default of one second each 💀 to skip that wait, the MN announces its attachment right away with a UNA message, so the NAR can forward packets to it immediately. between the PCoA tunnel and that fast advertisement, the protocol gives expedited forwarding of packets to the MN 🎀
the protocol also has some other important tricks ✨ the access routers can swap messages to confirm that a proposed NCoA is okay to use. for example, if the MN sends an FBU from the PAR's link, the FBack can arrive once the NAR considers the NCoA acceptable 👑 this is super useful when the access router is the one assigning addresses. the NAR can also lean on its trust relationship with the PAR before it forwards for the MN. so it may create a forwarding entry for the NCoA, subject to "approval" from the PAR it trusts 🌸 buffering handover traffic at the NAR might also be a good call 🙈 the Neighbor Discovery protocol has a small buffer (typically one or two packets) for packets waiting on address resolution, but that might not be enough for traffic that's already going, like VoIP 💅 the routers might want a separate buffer just for handover traffic 🧚 and finally, the access routers could move network-resident contexts like access control, Quality of Service (QoS), and header compression over during the handover (the context transfer process itself isn't specified in this document, so that's a whole other story 🦋)
all of this runs on the "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages (see Section 6.2) 🌈 both of these SHOULD be used. and the access routers MUST have the necessary security association set up by means outside the scope of this document 🔥
3.2. Protocol Operation ✨
okay so the whole thing kicks off when an MN sends an RtSolPr 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 carrying one or more [AP-ID, AR-Info] tuples. 💖 the MN may send an RtSolPr at any convenient time, like as a reaction to some link-specific event (a "trigger") or just after doing router discovery. BUT the expectation is that before sending an RtSolPr, the MN will already have discovered the available APs by link-specific methods 🔍. and the RtSolPr and PrRtAdv messages don't set up any state at the access router (their packet formats live in Section 6.1 🎀).
with the info from the PrRtAdv, the MN cooks up a prospective NCoA and sends an FBU to the PAR. the FBU's whole job is to authorize the PAR to bind the PCoA to the NCoA, so arriving packets can get tunneled to the MN's new spot 🦋. the FBU should be sent from the PAR's link whenever feasible. for example, an internal link-specific trigger could enable FBU transmission from the previous link ⭐.
when that's not feasible, the FBU is sent from the new link 🌈.
the FBU processing format and semantics are specified in Section 6.3.1. and the FBU MUST contain the BADF option (see Section 6.5.4) to secure the message 🔐.
now, depending on whether an FBack shows up 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 FBack on the previous link. this means packet tunneling is already in progress by the time the MN hands over 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 HI and HAck exchange 🤝. when assigned addressing (addresses assigned by the router) 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. such 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. this happens because the MN never sent the FBU, OR it left the link after sending the FBU (which itself may get lost) but before getting 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. if the NAR chooses to supply a different IP address to use than the NCoA, it MAY send a Router Advertisement with a "Neighbor Advertisement Acknowledge (NAACK)" option in which it includes an alternate IP address for the MN to use 🧚. detailed UNA processing rules are in Section 6.4.
the scenario where an MN sends an FBU and gets an FBack on the PAR's link is shown in Figure 2. for convenience, this one is called the "predictive" mode of operation 🔮. the scenario where the MN sends an FBU from the NAR's link is shown in Figure 3, and we call that the "reactive" mode 💜. note that the reactive mode also includes the case where an FBU was sent from the PAR's link but an FBack hasn't 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 Handoverlast but not least, the PrRtAdv message may be sent unsolicited, i.e., without the MN first sending an RtSolPr 📨. 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 agreed on between 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 it MUST send an FBU to the PAR prior to switching to the new link 🔁. after transmitting the 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 build a neighborhood topology map of links and subnets 📡. this usage of PrRtAdv is decoupled from the actual handover, so see Section 6.1.2 🦋.
4. Protocol Details 💖
okay so everything in this section refers back to Figure 1 🦋
After the MN finds one or more nearby access points, it sends RtSolPr to the PAR so it can turn access point identifiers into subnet router information. Doing this right after router discovery is a super convenient time, ngl ✨. But the MN can send RtSolPr at any time, like when one or more new access points show up. It can even send RtSolPr more than once during its attachment to the PAR 💅. The trigger can come from a link-specific event, like a new access point promising better signal strength while the current one's signal quality is fading 📉. People often call these "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 (like UNA) can go out immediately. Implementations SHOULD make use of such triggers whenever available 🫶.
The RtSolPr message holds one or more AP-IDs. A wildcard asks for all the available tuples 🍓.
As a response to RtSolPr, the PAR sends a PrRtAdv message that tells the MN one of the following things 👑:
- 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 that says the new access point is connected to the current interface, but it doesn'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 information 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 (so it gives any 'n' tuples without exceeding the link MTU) 🧚.
When further protocol action is necessary, some implementations MAY choose to begin buffering copies of incoming packets at the PAR. If First in First Out (FIFO) buffering is used, the PAR MUST continue forwarding the packets to the PCoA (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 begins forwarding packets to the NCoA.
How access routers exchange information 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 an access router that supports fast handovers. However, when the parameters the MN needs to send packets immediately upon attaching to the NAR are supplied by the link-layer handover mechanism itself, use of the above messages is optional on such links 💜.
After a PrRtAdv message is processed, the MN sends an FBU at a time determined by link-specific events, and includes the proposed NCoA. The MN SHOULD send the FBU from the PAR's link whenever "anticipation" of handover is feasible. When anticipation isn't feasible, or when the MN hasn't received an FBack, the MN sends an FBU immediately after attaching to NAR's link. In response to the FBU, the PAR establishes a binding between the PCoA ("Home Address") and the NCoA, and sends the FBack to the MN. Before establishing this binding, the PAR SHOULD send an HI message to the NAR and receive HAck in response. To work out the NAR's address for the HI message, the PAR can do the longest prefix match of NCoA (in FBU) with the prefix list of neighboring access routers 🔥. When the source IP address of the FBU is the PCoA (i.e., the FBU is sent 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 (i.e., the FBU is sent from the NAR's link), the HI message MUST have a Code value of 1; see Section 6.2.1.
The HI message contains the PCoA, link-layer address, and the NCoA of the MN. When the NAR processes an HI message with Code 0, it:
- determines whether the NCoA supplied in the HI message is unique before beginning to defend it. It sends a Duplicate Address Detection (DAD) probe [RFC4862] for NCoA to verify uniqueness. However, in deployments where the probability of address collisions is considered extremely low (and hence not an issue), the parameter DupAddrDetectTransmits (see [RFC4862]) is set to zero on the NAR, allowing it to avoid performing DAD on the NCoA. The NAR similarly sets DupAddrDetectTransmits to zero in other deployments where DAD is not a concern. Once the NCoA is determined to be unique, the NAR starts proxying [RFC4861] the address for PROXY_ND_LIFETIME, during which the MN is expected to connect to the NAR. In case there is already an NCoA present in its data structure (for instance, it has already processed an HI message earlier), the NAR MAY verify if the LLA is the same as its own or that of the MN itself. If so, 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 HI.
- MAY create a host route entry for the PCoA (on the interface to which the MN is attaching) in case the NCoA cannot be accepted or assigned. This host route entry SHOULD be implemented such that, until the MN's presence is detected (either through explicit announcement by the MN or by other means), arriving packets do not invoke neighbor discovery. The NAR SHOULD also set up a reverse tunnel to the PAR in this case.
- provides the status of the handover request in the Handover Acknowledge (HAck) message to the PAR.
When the Code value in HI is 1, the NAR MUST skip the above operations. Sending an HI message with Code 1 allows the NAR to validate the neighbor cache entry it creates for the MN during UNA processing. That is, the NAR can make use of the knowledge that its trusted peer (i.e., the PAR) has a trust relationship with the MN 🫶.
If 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 as well, to facilitate faster reception in the event that the MN is still present. The result of FBU and FBack processing is that the PAR begins tunneling the MN's packets to the NCoA ✨. If the MN does not receive an FBack message even after retransmitting the FBU for FBU_RETRIES, it must assume that fast handover support is not 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.4). If the MN has not received an FBack by the time UNA is being sent, it SHOULD send an FBU message following the UNA message.
- joins the all-nodes multicast group and the solicited-node multicast group corresponding to the NCoA.
- starts a DAD probe for NCoA, see [RFC4862].
When a NAR receives an UNA message, it:
- deletes its proxy neighbor cache entry, if it exists, updates the state to STALE [RFC4861], and forwards arriving and buffered packets.
- updates an entry in INCOMPLETE state [RFC4861], if it exists, to STALE and forwards arriving and buffered packets. This would be the case if NAR had previously sent a Neighbor Solicitation that went unanswered, perhaps because the MN had not yet attached to the link.
The buffer for handover traffic should be linked to this UNA processing. The exact mechanism is implementation dependent 🎀.
The NAR may choose to provide a different IP address other than the NCoA. This is possible if it is proxying the NCoA. In such a case, it:
- MAY send a Router Advertisement with the NAACK option in which it includes an alternate IP address for use. This message MUST be sent to the source IP address present in UNA, using the same Layer 2 address present in 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 NAACK could be the PCoA itself, in which case the MN MUST NOT send any more FBUs 🙈. The Status codes for the NAACK option are specified in Section 6.5.5.
Once the MN has confirmed its NCoA (either through DAD or when provided for by the NAR), it SHOULD send a Neighbor Advertisement message with the 'O' bit set, to the all-nodes multicast address. This message allows the MN's neighbors to update their neighbor cache entries 💖.
For data forwarding, the PAR tunnels packets using its global IP address valid on the interface to which the MN was attached. The MN reverse tunnels its packets to the 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 if 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 does not receive a PrRtAdv message even after RTSOLPR_RETRIES, it must assume that the PAR does not support the fast handover protocol and stop sending any more RtSolPr messages 🥲.
Even if an MN's current access router is capable of providing fast handover support, the new access router to which the MN attaches may be incapable of fast handover. This is indicated to the MN during "runtime", through the PrRtAdv message with a Code value of 3 (see Section 6.1.2) 🌈.
5.2. Determining New Care-of Address ✨
okay so typically the MN works out its prospective NCoA using the info from a PrRtAdv message, and then it sends the FBU 💌. The PAR MUST use the NCoA that's in the FBU in its HI message. The NAR MUST verify if the NCoA in HI is already in use 👀. In any case, the NAR MUST respond to HI with a HAck, and it may include another NCoA to use, especially when assigned address configuration is used. If there's a CoA in the HAck, the PAR MUST include it in the FBack message. The MN doesn't have to sit around waiting on the PAR's link for any of this 🙃. It can handover any time after sending the FBU, 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 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 the AP is attached to. This document doesn't specify how this Prefix is managed, its length, or its assignment policies. The protocol operation specified here works regardless of those considerations ✨. 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 a deployment like that 🧚.
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 the 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. Plus, the arrival pattern of packets depends on a lot of things, like application characteristics, network queuing behaviors, and so on 🌀. So packets may arrive at the NAR before the MN is able to establish its link there. Those packets will be lost unless the NAR buffers them. 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're buffered. This protocol gives you an option to request 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 🫶.
Buffering can enable a smooth handover, but the buffer size and the rate at which buffered packets are eventually forwarded are important considerations. There are a few aspects to think about:
- Some applications send less data over a given period than others, and that means different buffering requirements. For instance, Voice over IP typically needs smaller buffers than high-resolution streaming video, since 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 😭.
Sending a big batch of buffered packets back to back can congest the path between the buffering router and the mobile node. On top of that, nodes on that path (like a base station) may drop such packets. If a base station buffers too many of them, they can add jitter for packets arriving behind them, which is undesirable for real-time communication 💀.
- Routers aren't involved in end-to-end communication, so they have no knowledge of transport conditions 🙈.
- The wireless connectivity of the mobile node may vary over time. It may get a smaller or higher bandwidth on the new link, signal strength may be weak right when it enters the area of this access point, and so on 📶.
So it's tricky to design an algorithm that transmits buffered packets at the right spacing in every scenario. The whole point of fast handovers is to avoid packet loss, but draining buffered packets too fast can cause loss of those packets by itself, as well as blocking or loss of the following packets meant for the mobile node 😤.
This specification doesn't stop 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 determined by metering the rate at which packets have entered the buffer. They can potentially use smoothing techniques such as recent activity over a sliding time window and weighted averages [RFC3290] 🔥.
It should be noted, though, that this default algorithm is crude and may not be suitable for every situation. Future revisions of this specification may provide additional algorithms, once enough experience of the various conditions in deployed networks has been gained 🌈.
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. Using DAD to verify that an IPv6 address configured through stateless auto-configuration is unique adds delays to a handover 😩. The probability of an interface identifier duplication on the same subnet is very low, but it can't be ignored. So the protocol specified in this document SHOULD only be used in deployments where the probability of such address collisions is extremely low, or where it isn't 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 it doesn't specify how to create or manage those addresses. In some cases, the NAR may already know whether 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 those cases, the NAR can provide this disposition in the HAck message (see Section 6.2.2) or in the NAACK option (see Section 6.5.5) 🗂️.
5.6. Fast or Erroneous Movement 🏃♀️
Although this specification is for fast handover, the protocol is limited in how fast an MN can move. A special case of fast movement is ping-pong, where an MN moves rapidly between the same two access points 🏓. Another version of the same problem is erroneous movement, i.e., the MN gets information before a handover that it's moving to a new access point, but then it either moves to a different one or aborts the movement altogether 🤪. All of these behaviors are usually the result of link-layer idiosyncrasies, so they're often resolved at the link layer itself.
IP layer mobility has its own limits, though. IP layer handovers should happen at a rate that's suitable for the MN to update the binding of, at least, its Home Agent, and preferably that of every CN it's communicating with. An MN that moves faster than necessary for this signaling to complete, which may take on 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 with rapid movement between several access routers. To avoid that signaling overhead, the following measures are suggested 📉.
An MN returning to the PAR before updating its necessary bindings, when it's 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 🔐. When the PAR receives this Fast Binding Update, it checks 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 🎯. 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 fast handovers should use short lifetimes (on the order of a few tens of seconds at most, or less). The lifetime of such tunnels should be enough to let an MN update all its active bindings. The default lifetime of the tunnel should be the same as the lifetime value in the FBU message 🫧.
Erroneous movement typically only leads to packet loss, 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, so the packets get redirected to the newly confirmed location of the MN 🗺️.
6. Message Formats 📦
All the ICMPv6 messages share a common Type specified in [RFC4443]. The messages are told apart by 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 bestie, so Mobile Nodes send a Router Solicitation for Proxy Advertisement to basically ask the routers "hey, got any Proxy Router Advertisements for me?" ✨ All the Link-Layer Address options follow the format from Section 6.5.2, 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) 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.
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). Lowkey genius 🧠✨
When a wildcard is used for 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. ⏰ Retransmissions can go up to RTSOLPR_RETRIES, but they MUST use an exponential backoff, where the timeout period (i.e., 2xRTT or 100 milliseconds) is doubled before each retransmission. Ngl, it's giving patience 🐢💅 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 with MAX_RTSOLPR_RATE per second. Each use of an RtSolPr also uses exponential backoff for retransmissions. Periodt 💖
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. These messages 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) Message
IP 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 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 the 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. 📋
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, reflecting the LLA of the access point the rest of the options relate to. 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, reflecting the LLA of the access point the rest of the options relate to.
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 is
5, 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 is
6, 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 is
7, 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 the access points requested. The Option-Code field values (defined above, including a 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 the FBU (using the information sent in this message), but that NCoA will not be used for forwarding packets. Big "read the fine print" energy 🔍💜
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. Inter - Access Router Messages 🦋
6.2.1. Handover Initiate (HI) ✨
Okay so the Handover Initiate (HI) is an ICMPv6 message 💌 that an Access Router (usually the PAR) sends to another access router (usually the NAR) to kick off an MN's handover. Think of it as the PAR sliding into the NAR's DMs to say "hey, we need to talk about this MN." 🦋
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 🌸
ICMP Fields:
- Type:
154 - Code:
0or1. See below 🎀 - Checksum: The ICMPv6 checksum. 🧚
- Subtype:
4💜 - '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. 🫶
- 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 is undergoing handover to the destination (i.e., NAR). This option MUST be included so that the destination can recognize the MN. 👑
- 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 PCoA as source IP address. The PAR uses a Code value of 1 when it processes an FBU whose source IP address is not PCoA. 🦋
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. ⏰ Basically, the PAR keeps knocking, but it's giving patience, doubling the wait each time. 🙈
6.2.2. Handover Acknowledge (HAck) 💖
The Handover Acknowledge (HAck) is a brand-new ICMPv6 message, and it MUST be sent (usually by the NAR back to the PAR) as a reply to the Handover Initiate. It's the NAR's "yes, I see you, bestie" moment. 🫶
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:
- 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. 🌷
ICMP Fields:
- Type:
154🎀 - Code:
0: Handover Accepted, NCoA valid ✅1: Handover Accepted, NCoA not valid or in use2: Handover Accepted, NCoA assigned (used in Assigned addressing)3: Handover Accepted, use PCoA4: Message sent unsolicited, usually to trigger an HI message128: Handover Not Accepted, reason unspecified129: Administratively prohibited130: Insufficient resources
- Checksum: The ICMPv6 checksum. 🧚
- Subtype:
5💜 - Reserved: MUST be set to zero by the sender and ignored by the receiver. 🍓
- Identifier: Copied from the corresponding field in the Handover Initiate message to which this message is a response. 🔥
Valid Options:
- New Care-of Address: If the S flag in the Handover Initiate message is set, this option MUST be used to provide 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. 👑
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 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 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. 🌈 It's like building a little secret passage so the MN's packets still get where they're going. 🦋
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, saying "no" with a reason is still iconic. 💀
6.3. New Mobility Header Messages 🧚
Mobile IPv6 uses a new IPv6 header type called Mobility Header [RFC3775]. The Fast Binding Update, Fast Binding Acknowledgment, and the (deprecated) Fast Neighbor Advertisement messages use the Mobility Header. 💜
6.3.1. 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. 🦋
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Fast Binding Update (FBU) MessageIP 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.5.4. MAY contain the Mobility Header LLA option (see Section 6.5.3). 👑
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. 🙈 Lowkey the timing matters a lot here, bestie.
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. 💖
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. 🔐 Main character energy, but the security part is non-negotiable. 👑
6.3.2. Fast Binding Acknowledgment (FBack) 🦋
okay so the FBack message has a Mobility Header Type value of 9 ✨. The PAR sends it to say "got your FBU, bestie" 💅, but only for an FBU where the 'A' bit is set. If the PAR sends an HI to the NAR after processing an FBU, the FBack SHOULD NOT go to the MN until the PAR gets a HAck back from the NAR 🙈. In reactive mode the PAR MAY send the FBack right away tho 🔥. The Fast Binding Acknowledgment MAY also be sent to the MN on the old link 🌸.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 less than 128 mean the Binding Update was accepted by the receiving node. The currently defined ones are:
0 Fast Binding Update accepted
1 Fast Binding Update accepted but NCoA is invalid. Use NCoA
supplied in "alternate" CoAValues of 128 or higher mean the Binding Update was rejected by the receiving node 💀. The currently defined ones are:
128: Reason unspecified
129: Administratively prohibited
130: Insufficient resources
131: 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 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: It MUST contain an "alternate" CoA if Status is 1. It MUST contain the Binding Authorization Data for FMIP (BADF) option. See 6.4.5. 👑
6.4. Unsolicited Neighbor Advertisement (UNA) 🌸
okay so this is the same message as in [RFC4861], with one rule: 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 also zero 💅.
If the NAR is proxying the NCoA (because of a HI and HAck exchange), then UNA processing has extra steps, which you'll see below ✨. If the NAR is NOT proxying the NCoA (like if HI and HAck never happened), UNA processing just follows the normal procedure in [RFC4861]. Implementations MAY retransmit UNA, subject to Section 7.2.6 of [RFC4861], but they should keep in mind that the default RetransTimer value is large for handover purposes 🫶.
The Source Address in UNA MUST be the NCoA. The destination is usually the all-nodes multicast address, but some deployments may not like sending to a multicast address 🙈. In that case, 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 a UNA to the NAR as soon as it regains connectivity 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 forwards packets as it figures out bidirectional reachability using the standard Neighbor Discovery procedure. If there's an entry in INCOMPLETE state without a link-layer address, it gets set to STALE, again following the procedure in [RFC4861].
The NAR MAY wish to provide a different IP address to the MN than the one in the UNA message. If it does, the NAR MUST delete the proxy entry for the NCoA and send a Router Advertisement with the NAACK option containing the new IP address. Not optional vibes, periodt 💀
The combination of the NCoA (in the source IP address) and the Link-Layer Address (in the Target LLA) SHOULD be used to tell the MN apart from other nodes 🦋.
6.5. New Options 🎀
All the options, except Binding Data Authorization for FMIPv6 (BADF) which is covered in Section 6.5.4, use the Type, Length, and Option-Code format shown in Figure 10 ✨.
The Type values come from the Neighbor Discovery options space. The Length field is in units of 8 octets, EXCEPT for the Mobility Header Link-Layer Address option, whose Length field is in units of octets, following Section 6.2 in [RFC3775]. 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.5.1. IP Address/Prefix Option 💖
This option shows up in the Proxy Router Advertisement, the Handover Initiate, and Handover Acknowledge messages 🌈.
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 Address
2: New Care-of Address
3: NAR's IP address
4: 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.Okay so for Option-Code 4, the bits in the prefix after the prefix length are reserved, and they MUST be initialized to zero by the sender and ignored by the receiver 🙈.
Prefix Length: An 8-bit unsigned integer that tells you the length of the IPv6 Address Prefix. The value ranges from 0 to 128 ✨.
Reserved: It 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.5.2. 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 12: Link-Layer Address OptionType: 19
Length: The size of this option in 8 octets, including the Type, Option-Code, and Length fields.
Option-Code:
0: wildcard requesting resolution for all nearby access points
1: Link-Layer Address of the New Access Point
2: Link-Layer Address of the MN
3: Link-Layer Address of the NAR (i.e., Proxied Originator)
4: Link-Layer Address of the source of RtSolPr or PrRtAdv
message
5: The access point identified by the LLA belongs to the
current interface of the router
6: No prefix information available for the access point
identified by the LLA
7: No fast handovers support available for the access point
identified by the LLALLA: The variable length link-layer address 💅.
The LLA option doesn't have a length field for the LLA itself. Implementations must consult the specific link layer the protocol runs over to work out the content and length of the LLA 🫶.
Depending on the size of the individual LLA option, appropriate padding MUST be used so that the entire option size is a multiple of 8 octets 🌸.
The New Access Point Link-Layer Address holds the link-layer address of the access point that a handover is about to be attempted to. This one is used 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 refers to 👑.
6.5.3. Mobility Header Link-Layer Address (MH-LLA) Option 🌈
This option is identical to the LLA option, but it's carried in Mobility Header messages, like the FBU 🎀. Other Mobility Header messages might use it in the future too. The format is shown in Figure 13, and there are no alignment requirements for this 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: Mobility Header Link-Layer Address OptionType: 7
Length: The size of this option in octets, NOT including the Type and Length fields.
Option-Code: 2 Link-Layer Address of the MN.
LLA: The variable length link-layer address.
6.5.4. Binding Authorization Data for FMIPv6 (BADF) 🎀
okay bestie, this option MUST be present in FBU and FBack messages 💅 no skipping it! The security association between the MN and the PAR gets set up by companion protocols [RFC5269]. This option is the part that explains how to compute and verify a Message Authentication Code (MAC) using that established security association 🔐.
Here's the format, shown in Figure 14:
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 14: Binding Authorization Data for FMIPv6 (BADF) Option
- Type:
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, with "correspondent" replaced by the PAR's IP address, and Kbm replaced by the shared key between the MN and the PAR.
The default MAC calculation is done using HMAC_SHA1, with the first 96 bits used for the MAC. Since there is an Option Length field, implementations can use other algorithms such as HMAC_SHA256. ngl that's a very flexible little design ✨
This option MUST be the last Mobility Option present. Put it at the end, every time! 🫶
6.5.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 15: Neighbor Advertisement Acknowledgment Option
- Type:
20 - Length: 8-bit unsigned integer. Length of the option, in 8 octets. The length is
1when a new CoA is not supplied. The length is3when a new CoA is present (immediately following the Reserved field). - Option-Code:
0 - Status: 8-bit unsigned integer indicating the disposition of the Unsolicited Neighbor Advertisement message. The following Status values are currently defined:
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.
The NAR responds to UNA with the NAACK option to tell the MN to use a different NCoA than the one it already used 🙈. If the NAR proposes a different NCoA, the Router Advertisement MUST use the source IP address in the UNA message as the destination address, and use the L2 address present in UNA. The MN MUST use the NCoA if it is supplied with the NAACK option. If the NAACK says the Link-Layer Address is unrecognized, for instance because the MN is using an LLA that's valid on the PAR's link but not on the NAR's link (different access technology, so different vibes 😭), then the MN MUST NOT use the NCoA or the PCoA, and SHOULD start immediately the process of acquiring a different NCoA at the NAR.
In the future, new option types may be defined. Future us is going to be so organised 🌈
7. Related Protocol and Device Considerations 🧚
The protocol here is built on a design principle of introducing no or minimal changes to related protocols, and honestly it's giving very low-drama energy 💜. For example, no changes to the base Mobile IPv6 protocol are needed to implement this protocol. Similarly, no changes to the IPv6 stateless address auto-configuration protocol [RFC4862] and DHCP [RFC3315] are introduced. The protocol specifies an optional extension to Neighbor Discovery [RFC4861], in which an access router may send a router advertisement as a response to the UNA message (see Section 6.4). Other than this extension, the specification does not modify Neighbor Discovery behavior, including the procedures performed when attached to the PAR and when attaching to the NAR.
The protocol does not require changes to any intermediate Layer 2 device between an MN and its access router that supports this specification. That includes wireless access points, switches, snooping devices, and so on 🍓.
8. Evolution from and Compatibility with RFC 4068 🌸
This document evolved from [RFC4068]. Specifically, a new handover key establishment protocol (see [RFC5269]) was defined to enable a security association between a mobile node and its access router. That lets the routing of packets get updated securely during a handover ✨. In the future, new specifications may be defined to establish such security associations, depending on the particular deployment scenario.
The protocol has improved based on experience implementing [RFC4068] and on experimental usage. That input refined the specification of parameter fields (such as lifetime, codepoints, etc.) and added new parameter fields to the existing messages. As of this writing, there are two publicly available implementations, [fmipv6] and [tarzan], plus multiple proprietary implementations 💖. Some experience suggests the protocol meets the delay and packet loss requirements when used appropriately with particular radio access protocols. For instance, see [RFC5184] and [mip6-book]. Still, it's important to remember that handover performance depends on both the IP layer operations this protocol specifies, and the particular radio access technology itself, which this protocol relies upon but does not modify 📡.
An existing implementation of [RFC4068] needs to be updated to support this specification. The main addition is establishing a security association between an MN and its access router (i.e., MN and PAR). One way to do that is specified in [RFC5269]. An implementation that complies with the specification in this document will likely also work with [RFC4068], except for the Binding Authorization Data for FMIPv6 option (see Section 6.5.4), which can only be processed when a security association is in place between a mobile node and its access router. This specification deprecates the Fast Neighbor Advertisement (FNA) message. However, it is acceptable 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 shown in the table below. Each mobile node MUST have a configuration mechanism to adjust the parameters. Such a configuration mechanism may be either local (such as a command line interface) or based on central management of a number 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.3.1 |
| PROXY_ND_LIFETIME | 1.5 seconds | Section 6.2.2 |
| HI_RETRIES | 3 | Section 6.2.1 |
+-------------------+---------------+---------------+10. Security Considerations 🔒✨
Okay bestie, security time 😭 This part is serious, so let's get into it. The doc lists a few vulnerabilities and the fixes for each one.
Insecure FBU: packets meant for one address could get stolen or redirected to some unsuspecting node 💀 This is the same worry as with a Mobile Node (MN) and Home Agent relationship. 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 relies on a companion protocol [RFC5269] to set up that security association. Using the shared handover key from [RFC5269], the Authenticator in the BADF option (see Section 6.5.4) MUST be computed, and the BADF option MUST be included in FBU and FBack messages. 🔐
Secure FBU, malicious or inadvertent redirection: here the FBU is secured, but the target of the binding turns out to be an unsuspecting node, either by accident or on purpose 🙈 This can lead to an MN that has a genuine security association with its access router redirecting traffic to the wrong address.
Good news though! The target of malicious traffic 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, HI and HAck message exchanges are used. When the NAR accepts NCoA in HI (with Code = 0), it proxies NCoA, so arriving packets are not sent on the link until the MN attaches and announces itself through UNA. That means any accidental or malicious redirection to a host gets avoided 🙌 It is still possible to jam a NAR's buffer with redirected traffic. But a NAR's handover state for an NCoA has a finite (and short) lifetime, a small multiple of the anticipated handover latency, so 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 and give an unsuspecting node's address as the NCoA 😬 This is kind of like base Mobile IP, where the MN can hand its Home Agent some other node's IP address as its CoA. Here, the PAR acts like a "temporary Home Agent" that has a security association with the Mobile Node and provides forwarding support for the handover traffic. Just like in base Mobile IP, this misdelivery can be traced back to the MN that has a security association with the router. So it's possible to isolate such an MN if it keeps misbehaving 🚫 Similarly, an MN that has a security association with the PAR may give the LLA of some other node on the NAR's link, which can cause misdelivery of packets (meant for the NCoA) to an unsuspecting node. It's possible to trace the MN in this case too 🕵️♀️
Apart from all that, the RtSolPr (Section 6.1.1) and PrRtAdv (Section 6.1.2) messages inherit the weaknesses of the Neighbor Discovery protocol [RFC4861]. Specifically, if the access router is compromised, the MN's RtSolPr message may get answered by an attacker who offers a rogue router as the resolution. If the MN attaches to that rogue router, its communication can be compromised 💔 Likewise, a network-initiated PrRtAdv message (see Section 3.3) from an attacker could make an MN 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 supports buffering packets during an MN's handover. This happens by securely exchanging the Handover Initiate (HI) and Handover Acknowledgment (HAck) messages in response to the FBU message from an MN. It's possible that an MN fails to hand over to the NAR, which usually provides the buffering support, whether that's an accident or on purpose. That can make the NAR waste memory on the buffered packets and, in the worst case, cause resource exhaustion 😱 So implementations must limit the size of the buffer as a local policy configuration, which may take into account parameters such as the average handover delay, the expected size of packets, and so on.
The Handover Initiate (HI) and Handover Acknowledgement (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] to protect the HI and HAck messages. IPsec Encapsulating Security Payload (ESP) [RFC4303] in transport mode with mandatory integrity protection SHOULD be used to protect the signaling messages. Confidentiality protection for these messages is not required 🌸
The security associations can be created 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 specified in RFC 4306 for mutual authentication. However, to ensure a baseline interoperability, the implementations MUST support shared secrets for mutual authentication 🤝 The next sections describe the Peer Authorization Database (PAD) and Security Policy Database (SPD) entries specified in [RFC4301] for when IKEv2 is used to set 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. 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 spread 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_1NAR 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 examples above isn't 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 that are 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 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 = ICMPv6 & local_icmpv6_type = HI &
remote_icmpv6_type = HAck
THEN use SA ESP transport mode Initiate using IDi = par_1 to
address nar_address_1NAR SPD-S:
- IF local_address = nar_address_1 & remote_address =
par_address_1 & proto = ICMPv6 & local_icmpv6_type = HAck &
remote_icmpv6_type = HI
THEN use SA ESP transport mode11. IANA Considerations 🌈
This document defines a new ICMPv6 message, which has been allocated from the ICMPv6 Type registry.
154 FMIPv6 MessagesThis 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 | Section 6.2.1 |
| 5 | HAck | Section 6.2.2 |
+---------+-------------+---------------+The values '0' and '1' are reserved. The upper limit is 255. An RFC is required for new message assignment. 📋
The document defines a new Mobility Option that has received a Type assignment from the Mobility Options Type registry:
- Binding Authorization Data for FMIPv6 (BADF) option, described in Section 6.5.4
The document has received Type assignments for the following (see [RFC4068]):
The document defines the following Neighbor Discovery [RFC4861] options, which have received Type assignments from IANA:
+---------+-----------------------------------------+---------------+
| Type | Description | Reference |
+---------+-----------------------------------------+---------------+
| 17 | IP Address/Prefix Option | Section 6.5.1 |
| 19 | Link-layer Address Option | Section 6.5.2 |
| 20 | Neighbor Advertisement Acknowledgment | Section 6.5.5 |
| | Option | |
+---------+-----------------------------------------+---------------+The document defines the following Mobility Header messages, which have received Type allocations from the Mobility Header Types registry:
- Fast Binding Update, described in Section 6.3.1
- Fast Binding Acknowledgment, described in Section 6.3.2
The document defines the following Mobility Option that has received a Type assignment from the Mobility Options Type registry:
- Mobility Header Link-Layer Address option, described in Section 6.5.3
12. Acknowledgments 💖
The editor would like to thank everyone who gave feedback on this specification, but can only name a few here: 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 are acknowledged for their feedback on operation over point-to-point links. The editor would like to acknowledge a contribution from James Kempf to improve this specification. Vijay Devarapalli provided text for the security configuration between access routers in Section 10. Thanks to Jari Arkko for the detailed AD Review, which improved this document 🙌 The editor would also like to thank the [mipshop] working group chair Gabriel Montenegro and the erstwhile [mobile ip] working group chairs Basavaraj Patil and Phil Roberts for providing so much support for this work 🧚
13. References 📚
13.1. Normative References ✨
okay so these are the docs this spec just cannot function without, bestie 💅
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 📏 this one's the big one for the capital-letter words!!
[RFC5269] Kempf, J. and R. Koodli, "Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND)", RFC 5269, June 2008. 🔐
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. 🧚
[RFC3315] Droms, R., Ed., 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., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. 🔑
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. 👀
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. ✨
13.2. Informative References 📚
okay these are the "ooh, go read this if you're curious" ones, no pressure 🫶
[fmipv6] "fmipv6.org : Home Page", <http://fmipv6.org>. 🌈
[mip6-book] Koodli, R. and C. Perkins, "Mobile Internetworking with IPv6, Chapter 22, John Wiley & Sons.", July 2007. 📖
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002. 💜
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. 🔐
[RFC4068] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. ⭐ the OG that this one glows up from!
[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. 🍓
[tarzan] "Nautilus6 - Tarzan", <http://software.nautilus6.org/TARZAN/>. 🦖
Appendix A. Contributors 🫶
this whole doc has its roots in the fast handover design team from the old [mobile ip] working group, which was lowkey iconic. the team members, in alphabetical order, were: Gopal Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, Hesham Soliman, George Tsirtsis, and Alper Yegin. the real MVPs 👑
Appendix B. Changes since RFC 4068 🔄
okay the glow-up list! here 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. 💀 bye bye FNA!
- Combined the IPv6 Address Option and IPv6 Prefix Option. 🧩
- Added description of DAD requirement on NAR when determining NCoA uniqueness in Section 4, "Protocol Details". 🔍
- Added a new code value for gratuitous HAck message to trigger a HI message. 🦋
- Added Option-Code 5 in PrRtAdv message to indicate NETLMM 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. 👀
Editor's Address 💌
Rajeev Koodli Starent Networks USA
EMail: rkoodli@starentnetworks.com
Full Copyright Statement ©️
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧠
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💅
📦 where this page comes from
- ietf: rfc5268 2008-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms