RFC 4988

Mobile IPv4 Fast Handovers

📅 published October 2007, from ietf

RFC 4988: Mobile IPv4 Fast Handovers 💖

Okay bestie, let's get into it. This is RFC 4988, titled "Mobile IPv4 Fast Handovers," and it came out of the Network Working Group in October 2007. R. Koodli and C. Perkins wrote it, both from Nokia Siemens Networks. It's marked as Experimental, so it's not an Internet standard. The header doesn't list anything it obsoletes or updates. 🦋

Status of This Memo 📜

This memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind. The authors want feedback and suggestions for improvement, and the memo can be distributed without limits. 🌸

Abstract ✨

This doc takes the Mobile IPv6 Fast Handovers idea and adapts it for Mobile IPv4, so handovers hurt less in terms of delay and packet loss. It focuses on three things that slow handovers down: movement detection, IP address configuration, and location update latency. To cut down on IP address configuration latency, the new Care-of Address is always made to be the new access router's IP address. It's giving efficiency 🔥

Table of Contents 🎀

1. Introduction ....................................................3
2. Terminology .....................................................4
3. Factors Affecting Handover ......................................5
4. Protocol ........................................................6
   4.1. Overview ...................................................6
   4.2. Operation ..................................................7
5. Message Formats ................................................10
   5.1. Fast Binding Update (FBU) .................................10
   5.2. Fast Binding Acknowledgment (FBAck) .......................12
   5.3. Router Solicitation for Proxy Advertisement (RtSolPr) .....13
   5.4. Proxy Router Advertisement (PrRtAdv) ......................14
   5.5. Handover Initiate (HI) ....................................17
   5.6. Handover Acknowledge (HAck) ...............................19
6. Option Formats .................................................20
   6.1. Link-Layer Address Option Format ..........................20
   6.2. New IPv4 Address Option Format ............................22
   6.3. New Router Prefix Information Option ......................22
7. Security Considerations ........................................23
8. IANA Considerations ............................................24
9. Acknowledgments ................................................25
10. References ....................................................25
   10.1. Normative References .....................................25
   10.2. Informative References ...................................26

1. Introduction ✨

Okay so this doc adapts the fast handover spec [rfc4068] for IPv4 networks. It's especially useful on links like IEEE 802 wireless links. Fast handovers usually aren't needed on wired media, because setting up new connections on today's wired networks already has pretty big delays. Mobile IPv4 [rfc3344] registration messages get reused here, just with new type numbers, so people can implement it faster using existing Mobile IPv4 software. 💅

This doc doesn't require link-layer triggers to work. Performance will typically get a boost, though, when you use the right triggers, if they're available. The doc assumes you already know the basic operation and terminology of Mobile IPv4 [rfc3344] and Fast Handovers for Mobile IPv6 [rfc4068]. 🧚

Now, the agents that keep packets flowing to a mobile node (MN) are the access routers on the networks it connects to. A handover is when the mobile node changes its network connection. This doc looks at the case where that change also means a change in access routers. The mobile node uses access routers as default routers in the normal way, but it also treats them as partners in mobility management. So when the mobile node moves to a new network, it handles handover signaling to find and build a relationship with a new access router. 🦋

In this doc, the previous access router is called PAR and the new one is called NAR, which matches the terminology in [rfc4068]. Unless it says otherwise, a PAR is also a Previous Foreign Agent (PFA), and a NAR is also a New Foreign Agent (NFA). 💜

On a given network, a mobile node might get its IP address through DHCP [rfc2131] (that's the Co-located Care-of Address), or it might use the Foreign Agent CoA. During a handover, the new CoA (NCoA) is always set to the NAR's address. That lets the mobile node keep sending and receiving packets with its previous CoA (PCoA). So delays from IP configuration after it attaches to the new link, like DHCP address acquisition delay, don't mess with existing sessions. Iconic, honestly 👑

Here's the twist: unlike Mobile IPv6, a Mobile IPv4 host can rely on its Foreign Agent to provide a Care-of Address. With the protocol in this doc, the binding at the PAR is always set up between the on-link address the mobile node is using and a new CoA it can use on the NAR's link. When FA-CoA is used, the on-link address is the MN's home address, not the FA-CoA itself, and that home address is what needs to be bound to the NCoA. So when we say "a binding is established between PCoA and NCoA," in FA-CoA mode it's really the mobile node's home address getting bound to the NCoA. Main character energy 🌈

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 [RFC2119]. 🎀

2. Terminology 📖

Okay, the terminology in this doc is based on [rfc4068] and [rfc3344]. Here are some definitions so you don't have to hunt for them. 🍓

Mobile Node (MN): A Mobile IPv4 host.
Access Point (AP): A Layer 2 device connected to an IP subnet that gives wireless connectivity to an MN. An Access Point Identifier (AP-ID) refers to the AP's L2 address. Sometimes the AP-ID is also called a Base Station Subsystem ID (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 default router after its handover.
Previous CoA (PCoA): The IP address of the MN 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: A process of ending existing connectivity and getting new IP connectivity.
(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 [Router's L2 address, Router's IP address, Prefix] is called "AR-Info". 🔥

3. Factors Affecting Handover 🌸

Both link-layer operations and IP-layer procedures affect how a handover performs. Overall performance also always depends on how a specific implementation of the technology is done, and on the system configuration. This doc only specifies IP-layer protocol operations. This section is purely informative, and it's just here to show events that affect handover performance. 💅

The IP-layer handover delay and packet loss are influenced by latencies from movement detection, IP address configuration, and the Mobile IP registration procedure. Movement detection latency comes from having to reliably detect movement to a new subnet. It depends on how often router advertisements happen and on whether the default agent is reachable. IP address configuration latency depends on which IP CoA is being used. If co-located mode with DHCP is used, the latency is likely to be higher, and it could be unacceptable for real-time apps like Voice over IP. Finally, the Mobile IP registration procedure adds a round trip of delay between the Mobile Node and its Home Agent over the Internet. That delay happens after the mobile node finishes movement detection and IP configuration. 😭

Underneath the IP operations are link-layer procedures, and those are technology-specific. For example, in IEEE 802.11, a handover typically means scanning access points across all available channels, picking a suitable access point, and associating with it. It may also involve access control operations like the ones in IEEE 802.1X [ieee-802.1x]. These delays all add to handover performance. See [fh-ccr] and Chapters 20 and 22 in [mi-book]. Optimizations are being proposed for standardization in IEEE, for example [ieee-802.11r] and [ieee-802.21]. Together with the right implementation techniques, these optimizations can give the link layer the level of delay support that real-time applications need. 🦋

4. Protocol 🧚

4.1. Overview 💖

The design of this protocol is the same as Mobile IPv6 [rfc4068]. Readers should check [rfc4068] for details. Here's a quick summary. 🫶

The protocol skips the delay from movement detection and IP configuration, and it takes Mobile IP registration delay off the time-critical path. It gives the mobile node info about its surrounding network neighborhood, so it can figure out whether it's moving to a new subnet even before the handover. That info, plus the signaling between local mobility agents, lets the mobile node send and receive packets right after the handover. To take the Mobile IP registration latency off the table, the protocol also gives routing support so the mobile node can keep using its previous CoA. 🌈

After a mobile node gets its IPv4 Care-of Address, it builds a neighborhood access point and subnet map with the Router Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router Advertisement (PrRtAdv) messages. The mobile node may scan for access points (APs) based on the configuration policy for its wireless network interface. If a scan finds a new AP, the mobile node uses the RtSolPr and PrRtAdv messages to resolve that AP Identifier into subnet info. ✨

Eventually the mobile node decides to do a handover. It sends a Fast Binding Update (FBU) message to the PAR, either from the previous link or from the new one. An FBU message lets a binding be created between the mobile node's previous CoA and the new CoA. 🔥

The access routers coordinate using the Handover Initiate (HI) and Handover Acknowledge (HAck) messages defined in [rfc4068]. Once those have been exchanged between the previous and new access routers (PAR and NAR), data that arrives at the PAR gets tunneled to the NAR for delivery to the newly arrived mobile node. The HI message's job is to securely deliver the routing parameters for setting up this tunnel. The access routers create the tunnel in response to receiving the FBU from the mobile node. 👑

4.2. Operation 💖

okay so, when a handover trigger or indication pops up, the mobile node (MN) sends a Fast Binding Update message to the Previous Access Router (PAR) (see Section 5.1) 🦋. Depending on the Mobile IP mode, the source IP address is either the Home Address (in FA CoA mode) or the co-located CoA (in CCoA mode). The FBU message SHOULD (when possible) be sent while the mobile node is still connected to PAR. When it goes out in this "predictive" mode, the fields in the FBU MUST be set like this:

The Home Address field is either the Home Address or the co-located CoA whenever the mobile node has a co-located CoA.
The Home Agent field is set to PAR's IP address.
The Care-of Address field is the NAR's IP address (as discovered via a PrRtAdv message).

and the fields in the IP header MUST be set like this too:

The Destination IP address is PAR's IP address.
The Source IP address is either the Home Address or the co-located CoA whenever the mobile node has a co-located CoA.

As a result of processing the FBU, PAR creates a binding in its routing table between the address the mobile node gave in the Home Address field and NAR's IP address. Then PAR sends an FBack message (see Section 5.2) back to the mobile node. 🎀

The timeline for the predictive mode (adapted from [rfc4068]) is shown in Figure 1 ✨

         MN                    PAR                  NAR
          |                     |                    |
          |------RtSolPr------->|                    |
          |<-----PrRtAdv--------|                    |
          |                     |                    |
          |------FBU----------->|--------HI--------->|
          |                     |<------HAck---------|
          |          <--FBack---|--FBack--->         |
          |                     |                    |
       disconnect             forward                |
          |                   packets===============>|
          |                     |                    |
          |                     |                    |
      connect                   |                    |
          |                     |                    |
          |--------- FBU --------------------------->|
          |<=================================== deliver packets
          |                     |              (including FBack)
          |                     |<-----FBU-----------|

             Figure 1: Predictive Fast Handover

The mobile node sends the FBU, regardless of its previous transmission, when attachment to a new link is detected. 🦋 This minimally lets NAR detect the mobile node's attachment, but it also covers retransmitting the FBU when an FBack hasn't shown up yet.

When it's sent in this "reactive" mode, the Destination IP address in the IP header MUST be NAR's IP address. The rest of the fields in the FBU are the same as in the "predictive" case. 💅

When NAR receives the FBU, it may already have processed the HI message and created a host route entry for the mobile node, using either the home address or the co-located care-of address that PAR provided. In that case, NAR SHOULD immediately forward arriving and buffered packets as well as the FBAck message. In any case, NAR MUST forward the contents of the FBU message, starting from the Type field, to PAR. The Source and Destination IP addresses in this new packet now hold the IP addresses of NAR and PAR, respectively. 🔥

The reactive mode (adapted from [rfc4068]) is illustrated in Figure 2. The Figure doesn't show the HI and HAck messages from Figure 1, but those could already have been exchanged (if PAR already processed the FBU sent from the previous link). If not, PAR sends a HI message to NAR. NAR forwards the FBack packet to the MN along with the data packets. 🌸

              MN                    PAR                  NAR
               |                     |                    |
               |------RtSolPr------->|                    |
               |<-----PrRtAdv--------|                    |
               |                     |                    |
            disconnect               |                    |
               |                     |                    |
               |                     |                    |
            connect                  |                    |
               |-----------FBU-------|------------------->|
               |                     |<-----FBU-----------|
               |                     |------FBack-------->|
               |                   forward                |
               |                   packets===============>|
               |                     |                    |
               |<=================================== deliver packets
               |                                    (including FBack)
               |                                          |

                    Figure 2: Reactive Fast Handover

The Handover Initiate (HI) and Handover Acknowledge (HAck) messages set up a bidirectional tunnel between the routers so packets for PCoA can get forwarded. 🧚 The tunnel itself gets established as a response to the FBU message. PAR sends the HI message with Code = 0 when it receives an FBU whose source IP address is PCoA. PAR sends HI with Code = 1 when it receives an FBU whose source IP address is not PCoA (i.e., when it's received from NAR). This lets NAR tell apart HI processing that's a response to predictive mode from HI processing that's a response to reactive mode. If NAR receives a HI message with Code = 1 and has already set up a host route entry and a reverse tunnel for PCoA, it SHOULD still respond with a HAck message, using an appropriate Code value defined in Section 5.6. 👑

The protocol gives NAR the option to return an NCoA for the mobile node to use. When NAR can provide an NCoA for the mobile node's exclusive use, the address is supplied in the HAck message. PAR includes this NCoA in the FBack. How NAR manages the address pool it hands NCoAs out of isn't specified in this document. Still, the MN should be prepared to use this address instead of doing DHCP or similar operations to get an IPv4 address. 🫶

Even though the mobile node can get this NCoA from NAR, it doesn't know the address yet when it sends an FBU. So it binds PCoA to NAR's IP address, just like before. 🙈

5. Message Formats ✨

This section lays out the formats for the messages this protocol uses. The Code values below are the same as the ones in [rfc4068], and they don't need any assignment from IANA. 💜

5.1. Fast Binding Update (FBU) 🎀

The FBU format is bitwise identical to the Registration Request format in [rfc3344]. It uses the same destination port number, 434, but the FBU and FBAck messages in this specification have new message type numbers. 🦋

    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      |x|x|D|M|G|r|T|x| reserved  |     Lifetime      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Care-of Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-+

             Figure 3: Fast Binding Update (FBU) Message

Here's the IP field breakdown 🌈

Source address: The interface address the message is sent from. This is either PCoA (co-located or Home Address), or NAR's IP address (when forwarded from NAR to PAR).
Destination Address: The IP address of the Previous Access Router (PAR) or the New Access Router (NAR).
Source Port: variable
Destination port: 434

And here's the message field breakdown ✨

Type: 20
Flags: See [rfc3344]. The 'S' and 'B' flags in [rfc3344] are sent as zero, and ignored on reception.
reserved: Sent as zero, ignored on reception.
Lifetime: The number of seconds remaining before the binding expires. This value MUST NOT exceed 10 seconds. 😭
Home Address: MUST be either the co-located CoA or the Home Address itself (in FA-CoA mode).
Home Agent: The Previous Access Router's global IP address.
Care-of Address: The New Access Router's global IP address. Even when a New CoA is provided to the MN (see Section 5.4), NAR's IP address MUST be used for this field.
Identification: a 64-bit number used for matching an FBU with an FBack. It's used the same way as in [rfc3344].
Extensions: MUST contain the MN-PAR Authentication Extension (see Section 8). 🔐

The MN-PAR Authentication Extension is the Generalized Mobile IP Authentication Extension in [rfc4721], with a new Subtype for MN-PAR Authentication. The Authenticator field in that Generalized Mobile IP Authentication Extension gets calculated using a shared key between the MN and the PAR. Key distribution itself is out of scope for this document, so it's assumed to be handled by other means (for example, using [rfc3957]). 💖

5.2. Fast Binding Acknowledgment (FBAck) 💌

okay bestie, the FBAck is literally a twin of the Registration Reply from [rfc3344]. bitwise identical, no cap 🫶 so if you already know that one, you're basically already 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      | reserved  |     Lifetime      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-+-

Figure 4: Fast Binding Acknowledgment (FBAck) 🎀

IP Fields:

Message Source address: Typically copied from the destination address of the FBU message 🌸
Destination Address: Copied from the Source IP address in FBU message
Source Port: variable
Destination port: Copied from the source port in FBU message

Message Fields:

Type: 21
Code: Indicates the result of processing FBU message. 🔥
- 0: FBU Accepted
- 1: FBU Accepted, NCoA supplied
- 128: FBU Not Accepted, reason unspecified
- 129: Administratively prohibited
- 130: Insufficient resources
reserved: Sent as zero, ignored on reception
Lifetime: The granted number of seconds remaining before binding expires. ⏳
Home Address: either the co-located CoA or the Home Address itself (in FA-Coa mode) 🏡
Home Agent: The Previous Access Router's global IP address
Identification: a 64-bit number used for matching FBU. Copied from the field in FBU for which this FBack is a reply. 🪪
Extensions: The MN-PAR Authentication extension MUST be present (see Section 8). In addition, a New IPv4 Address Option, with Option-Code 2, MUST be present when NAR supplies the NCoA (see Section 6.2). 🔐

5.3. Router Solicitation for Proxy Advertisement (RtSolPr) 🦋

Mobile Nodes send Router Solicitation for Proxy Advertisement to poke routers into sending Proxy Router Advertisements 👀 All the link-layer address options follow the format in Section 6.1, and the message format and processing rules are identical to [rfc4068]. so same vibes, different name 💅

    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: 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.
Time-to-Live: At least 1. See [rfc1256].

ICMP Fields:

Type: 41. See Section 3 in [rfc4065].
Code: 0
Checksum: The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum and the Reserved fields are set to 0. See [rfc1256]. 🧮
Subtype: 6
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:

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 Section 6.1). 📡

5.4. Proxy Router Advertisement (PrRtAdv) 👑

okay this one is the main event ✨ Access routers send out a Proxy Router Advertisement gratuitously if the handover is network-initiated, or as a response to an RtSolPr message from a mobile node. It provides the link-layer address, IP address, and subnet prefixes of neighboring access routers. All the link-layer address options follow the format in Section 6.1.

The message format and processing rules are identical to [rfc4068]. ye, we've seen this energy before 🙈

    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 6: Proxy Router Advertisement (PrRtAdv) Message 💖

IP Fields:

Source Address: An IP address assigned to the sending interface
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. 🚀
Time-to-Live: At least 1. See [rfc1256].

ICMP Fields:

Type: 41. See Section 3 in [rfc4065].
Code: 0, 1, 2, 3, or 4. See below.
Checksum: The 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum and the Reserved fields are set to 0. See [rfc1256].
Subtype: 7
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:

New Access Point Link-layer Address: The link-layer address (LLA) or identification of the access point. When there is no wildcard in RtSolPr, this is copied from the LLA (for which the router is supplying the [AP-ID, AR-Info] tuple) present in RtSolPr. When a wildcard is present in RtSolPr, PAR uses its neighborhood information to populate this field. 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 Code is 0 or 1.
New Router's IP Address: The IP address of NAR. This option MUST be included when Code is 0 or 1.
New Router Prefix Information Option: The number of leading bits that define the network number of the corresponding Router's IP Address option (see above).
New CoA Option: MAY be present, typically when PrRtAdv is sent unsolicited. PAR MAY compute new CoA by communicating with the NAR or by means not specified in this document. In any case, the MN should be prepared to use this address instead of performing DHCP or similar operations to obtain an IPv4 address. Even when it uses the New CoA provided, the MN MUST bind its current on-link address (PCoA) to that of NAR in the FBU message. 🪄

Now the codes, which is where it gets spicy 🌶️

A PrRtAdv with Code 0 means that the MN should use the [AP-ID, AR-Info] tuple present in the options above. In this case, the Option-Code field (see Section 6.1) in the New AP LLA option is 1, reflecting the LLA of the access point for which the rest of the options are related, and the Option-Code for the New Router's LLA option is 3. Multiple tuples may be present. 🍓

A PrRtAdv with Code 1 means that the message is sent unsolicited. If a New IPv4 option (see Figure 10) is present following the New Router Prefix Information option (see Section 6.3), the MN SHOULD use the supplied NCoA and send the FBU immediately or else stand to lose service. 😭 This message acts as a network-initiated handover trigger. The Option-Code field (see Section 6.1) in the New AP LLA option in this case is 1, reflecting the LLA of the access point for which the rest of the options are related.

A Proxy Router Advertisement with Code 2 means that no new router information is present. The LLA option contains an Option-Code value that indicates a specific reason (see Section 6.1). 🙃

A Proxy Router Advertisement with Code 3 means that new router information is only present for a subset of access points requested. The Option-Code values in the LLA option distinguish different outcomes (see Section 6.1). 🧩

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. 🫧

When a wildcard AP identifier is supplied in the RtSolPr message, the PrRtAdv message should include all available [Access Point Identifier, Link-Layer Address option, Prefix Information Option] tuples corresponding to the PAR's neighborhood. 🌟

The New CoA option may also be used when the PrRtAdv is sent as a response to a RtSolPr message. However, the solicited RtSolPr and PrRtAdv exchange for neighborhood discovery is logically decoupled from the actual handover phase involving the FBU and FBack messages (above) as well as HI and HAck messages (see below). This means the access routers have to carefully manage the supplied address due to the relative scarcity of addresses in IPv4. 🥺 that's a lot of responsibility, routers, be careful with those addresses 💜

5.5. Handover Initiate (HI) 🦋

okay so the Handover Initiate (HI) is an ICMP message that an Access Router (usually the PAR) sends to another Access Router (usually the NAR) to kick off a mobile node's handover ✨. The message format and processing rules are literally identical to the ones in [rfc4068] 💅.

      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 7:  Handover Initiate (HI) Message

IP Fields:

Source Address: the IP address of the PAR 🌸
Destination Address: the IP address of the NAR
Time-to-Live: at least 1. See [rfc1256].

ICMP Fields:

Type: 41. See Section 3 in [rfc4065].
Code: 0 or 1. See below.
Checksum: the 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum and the Reserved fields are set to 0. See [rfc1256].
Subtype: 8
S: 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: buffer flag. When set, the destination SHOULD buffer any packets towards 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 MUST be included so that a host route can be established on the NAR. 💜
New Care-of Address: this option MAY be present when the MN wishes to use a new IP address when connected to the destination. When the S bit is set, NAR MAY provide this address in HAck, in which case the MN should be prepared to use this address instead of performing DHCP or similar operations to obtain an IPv4 address. ✨

PAR uses Code = 0 when it processes the FBU received with PCoA as source IP address. PAR uses Code = 1 when the FBU is received with NAR's IP address as the source IP address. 🧚

5.6. Handover Acknowledge (HAck) 🌈

The Handover Acknowledgment message is a new ICMP message that MUST be sent (typically by NAR to PAR) as a reply to the Handover Initiate (HI) (see Section 5.5) message. It's giving reply energy 💖.

The message format and processing rules are identical to those defined in [rfc4068]. Same vibes as the HI, bestie 🎀.

      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 8:  Handover Acknowledge (HAck) Message

IP Fields:

Source Address: copied from the destination address of the Handover Initiate Message to which this message is a response.
Destination Address: copied from the source address of the Handover Initiate Message to which this message is a response.
Time-to-Live: at least 1. See [rfc1256].

ICMP Fields:

Type: 41. See Section 3 in [rfc4065].
Code:
- 0: Handover Accepted 🍓
- 1: Handover Accepted, NCoA not valid
- 2: Handover Accepted, NCoA in use
- 3: Handover Accepted, NCoA assigned (used in Assigned addressing)
- 4: Handover Accepted, NCoA not assigned
- 128: Handover Not Accepted, reason unspecified
- 129: Administratively prohibited
- 130: Insufficient resources
Checksum: the 16-bit one's complement of the one's complement sum of the ICMP message, starting with the ICMP Type. For computing the checksum, the Checksum and the Reserved fields are set to 0. See [rfc1256].
Subtype: 9
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 this message is in response to.

Valid Options:

New Care-of Address: if the S flag in the HI 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 S bit is not set, e.g., Code 2 above. The MN should be prepared to use this address instead of performing DHCP or similar operations to obtain an IPv4 address. 💅

The Code 0 is the expected average case of a handover being accepted and the routing support provided for the use of PCoA. The rest of the Code values pertain to the use of NCoA (which is common in [rfc4068]). Code values 1 and 2 are for cases when the MN proposes an NCoA and the NAR provides a response. Code 3 is when the NAR provides NCoA (which could be the same as that proposed by the MN). Code 4 is when the NAR does not provide NCoA, but instead provides routing support for PCoA. 🦋

6. Option Formats ✨

The options in this section are specified as extensions for the HI and HAck messages, as well as for the PrRtSol and PrRtAdv messages. The Option-Code values below are the same as those in [rfc4068], and do not require any assignment from IANA. 🎀

6.1. Link-Layer Address Option Format 💖

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |  Option-Code  |     LLA ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 9: Link-Layer Address Option Format

Fields:

Type: 20
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
- 4: Link-Layer Address of the source of the 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 LLA
Length: the length of the option (including the Type, Length and Option-Code fields) in units of 8 octets.
Link-Layer Address: the variable-length link-layer address. The content and format of this field (including byte and bit ordering) depends on the specific link-layer in use. 🧚

There is no length field for the LLA itself. Implementations MUST determine the length of the LLA based on the specific link technology where the protocol is run. The total size of the LLA option itself MUST be a multiple of 8 octets. Hence, padding may be necessary depending on the size of the LLA used. In such a case, the padN option [rfc2460] MUST be used. As an example, when the LLA is 6 bytes (meaning 7 bytes of padding is necessary to bring the LLA option length to 2), the padN option will have a length field of 5 and 5 bytes of zero-valued octets (see [rfc2460]). It's a whole math moment 🙈.

6.2. New IPv4 Address Option Format 🌸

This option is used to provide the new router's IPv4 address or the NCoA in PrRtAdv, as well as PCoA and NCoA in HI and HAck 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  |    Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      New IPv4 Address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 10: New IPv4 Address Option Format

Fields:

Type: 21
Length: the length of the option (including the Type, Length and Option-Code fields) in units of 8 octets.
Option-Code:
- 1: Previous CoA
- 2: New CoA
- 3: NAR's IP Address
Reserved: set to zero.
New IPv4 Address: NAR's IPv4 address or the NCoA assigned by NAR. 💜

6.3. New Router Prefix Information Option ✨

This option is used in the PrRtAdv message.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |  Option-Code  | Prefix-Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 11: New Router Prefix Information Option Format

Fields:

Type: 22
Length: the length of the option (including the Type, Length and Option-Code fields) in units of 8 octets.
Option-Code: 0
Prefix-Length: the number of leading bits that define the network number of the corresponding Router's IP Address option. 🦋
Reserved: set to zero.

7. Security Considerations 🔒✨

okay bestie, security is where it gets serious 😭 the original says we're following [rfc4068] here, so the same vulnerabilities pop up and the same fixes come with them 💅

Insecure FBU:

if the FBU message isn't protected, packets meant for an address could get stolen or redirected to some random unsuspecting node 🙈 this is kind of like the Mobile Node and Home Agent situation, so it's giving déjà vu.

so the FBU and FBack messages MUST be protected using a security association shared between a mobile node and its access router 🛡️ the MN-PAR Authentication Extension MUST be present in each of these messages too. this doc doesn't say how that security association gets set up between an MN and the AR/FA, so that's a separate convo 🫶

Secure FBU, malicious or inadvertent redirection:

even if the MN-PAR authentication extension is in an FBU, an MN could accidentally (or on purpose 💀) try to bind its PCoA to some address on the NAR's link, and then cause traffic flooding to an unsuspecting node. not it! 😤

the fix is to always bind the PCoA to the NAR's IP address, even when the NAR gives the MN an NCoA to use 💖 it's still possible to jam the NAR's buffer with redirected traffic, but the handover state for the MN's PCoA has a finite lifetime. it can be configured to be a few multiples of the anticipated handover latency, so the damage stays small ✨ and you can trace the culprit MN through the security association at the access router 🕵️‍♀️

Communication between the access routers:

the access routers talk to each other with HI and HAck messages so they can set up a temporary routing path for the MN that's going through handover 🦋 this exchange needs to be secured so the routing updates happen the way they're supposed to. no chaos allowed 👑

the HI and HAck messages need to be secured with a preexisting security association between the access routers, so you get at least message integrity and authentication. they SHOULD also include encryption, and IPsec ESP SHOULD be used 🔐 literally the most important part of the whole security section, periodt 💅

8. IANA Considerations 🌈

the IANA assignments for the messages, extensions, and options in this document are laid out in the following bits 🧚

this document defines two new messages that use the Mobile IPv4 control message format [rfc3344]. here's the deets:

               +------+-------------+-------------+
               | Type | Description |  Reference  |
               +------+-------------+-------------+
               |  20  |     FBU     | Section 5.1 |
               |  21  |    FBAck    | Section 5.2 |
               +------+-------------+-------------+

this document defines four new experimental ICMP messages that use ICMP Type 41 for IPv4. see Section 3 in [rfc4065] 🎀 the new messages got Subtypes from the registry in [rfc4065]:

              +---------+-------------+-------------+
              | Subtype | Description |  Reference  |
              +---------+-------------+-------------+
              |    6    |   RtSolPr   | Section 5.3 |
              |    7    |   PrRtAdv   | Section 5.4 |
              |    8    |      HI     | Section 5.5 |
              |    9    |     HAck    | Section 5.6 |
              +---------+-------------+-------------+

this document also defines three new options that got Types from the Mobile IP Extensions for ICMP Router Discovery messages [rfc3344] 🍓

             +------+------------------+-------------+
             | Type |    Description   |  Reference  |
             +------+------------------+-------------+
             |  20  |        LLA       | Section 6.1 |
             |  21  | New IPv4 Address | Section 6.2 |
             |  22  |  NAR Prefix Info | Section 6.3 |
             +------+------------------+-------------+

the MN-PAR Authentication Extension from Sections 5.1 and 5.2 is a Generalized Mobile IP Authentication Extension defined in Section 5 of [rfc4721] ✨ it got a Subtype from the registry specified in [rfc4721]. the extension details are:

   +---------+-----------------------+--------------------------+
   | Subtype |      Description      |         Reference        |
   +---------+-----------------------+--------------------------+
   |    4    | MN-PAR Auth Extension |        Section 5.1       |
   +---------+-----------------------+--------------------------+

9. Acknowledgments 🫶

thank you to everyone who wanted a Fast Handovers for Mobile IPv4 protocol along the lines of [rfc4068] 💜 thanks to Vijay Devarapalli, Kent Leung, and Domagoj Premec for their review and input. Kumar Viswanath and Uday Mohan built an early version of this protocol, which is so iconic 👑 huge thanks to Alex Petrescu for the thorough review that made this doc better. thanks to Pete McCann for the proofreading, and to Jari Arkko for the review, which also helped a ton 🌸 and thanks to Francis Dupont and Hannes Tschofenig for the GEN-ART and TSV-DIR reviews 🙌

sending the FBU from the new link (aka reactive mode) is similar to the extension defined in [mip4-ro]. the difference is that this document also tackles movement detection and router discovery latencies ⭐

10. References 📚

10.1. Normative References

[RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[rfc1256]      Deering, S., Ed., "ICMP Router Discovery Messages",
               RFC 1256, September 1991.

[rfc2460]      Deering, S. and R. Hinden, "Internet Protocol, Version
               6 (IPv6) Specification", RFC 2460, December 1998.

[rfc3344]      Perkins, C., Ed., "IP Mobility Support for IPv4", RFC
               3344, August 2002.

[rfc4065]      Kempf, J., "Instructions for Seamoby and Experimental
               Mobility Protocol IANA Allocations", RFC 4065, July
               2005.

[rfc4068]      Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC
               4068, July 2005.

[rfc4721]      Perkins, C., Calhoun, P., and J. Bharatia, "Mobile
               IPv4 Challenge/Response Extensions (Revised)", RFC
               4721, January 2007.

10.2. Informative References

[fh-ccr]       R. Koodli and C. E. Perkins, "Fast Handovers and
               Context Transfers in Mobile Networks", ACM Computer
               Communications Review Special Issue on Wireless
               Extensions to the Internet, October 2001.

[ieee-802.11r] IEEE, "IEEE Standard for Local and Metropolitan Area
               Networks:  Fast Roaming/Fast BSS Transition, IEEE Std
               802.11r", September 2006.

[ieee-802.1x]  IEEE, "IEEE Standards for Local and Metropolitan Area
               Networks: Port-based Network Access Control, IEEE Std
               802.1X-2001", June 2001.

[ieee-802.21]  The IEEE 802.21 group, http://www.ieee802.org/21.

[mi-book]      R. Koodli and C. E. Perkins, "Mobile Internetworking
               with IPv6: Concepts, Principles and Practices", John
               Wiley & Sons, June 2007.

[mip4-ro]      Perkins, C. and D. Johnson, "Route Optimization in
               Mobile IP", Work in Progress, September 2001.

[rfc2131]      Droms, R., "Dynamic Host Configuration Protocol", RFC
               2131, March 1997.

[rfc3957]      Perkins, C. and P. Calhoun, "Authentication,
               Authorization, and Accounting (AAA) Registration Keys
               for Mobile IPv4", RFC 3957, March 2005.

Authors' Addresses 🖊️

Rajeev Koodli
Nokia Siemens Networks
313 Fairchild Driive
Mountain View, CA 94043
USA

EMail: rajeev.koodli@nokia.com


Charles Perkins
Nokia Siemens Networks
313 Fairchild Driive
Mountain View, CA 94043
USA

EMail: charles.perkins@nokia.com

this document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights 💅

this document and the info in it 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 on 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 in this document, or on whether any license under those rights might be available. it also doesn't claim to have made any independent effort to identify such rights. info on the procedures for rights in RFC documents is in BCP 78 and BCP 79 📖

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission to use such proprietary rights by implementers or users of this specification can be found in 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 required to implement this standard. please send that info to the IETF at ietf-ipr@ietf.org 💌

📦 where this page comes from

ietf: rfc4988 2007-10
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms

RFC 4988

RFC 4988: Mobile IPv4 Fast Handovers 💖

Status of This Memo 📜

Abstract ✨

Table of Contents 🎀

1. Introduction ✨

2. Terminology 📖

3. Factors Affecting Handover 🌸

4. Protocol 🧚

4.1. Overview 💖

4.2. Operation 💖

5. Message Formats ✨

5.1. Fast Binding Update (FBU) 🎀

5.2. Fast Binding Acknowledgment (FBAck) 💌

5.3. Router Solicitation for Proxy Advertisement (RtSolPr) 🦋

5.4. Proxy Router Advertisement (PrRtAdv) 👑

5.5. Handover Initiate (HI) 🦋

5.6. Handover Acknowledge (HAck) 🌈

6. Option Formats ✨

6.1. Link-Layer Address Option Format 💖

6.2. New IPv4 Address Option Format 🌸

6.3. New Router Prefix Information Option ✨

7. Security Considerations 🔒✨

8. IANA Considerations 🌈

9. Acknowledgments 🫶

10. References 📚

10.1. Normative References

10.2. Informative References

Authors' Addresses 🖊️

Full Copyright Statement ©️

Intellectual Property 🧾