RFC 7629

Flow-Binding Support for Mobile IP

📅 published August 2015, from ietf

RFC 7629: Flow-Binding Support for Mobile IP 🦋

okay bestie, this is RFC 7629, Flow-Binding Support for Mobile IP, and it's a whole Experimental vibe 🧪. It's not an Internet Standards Track spec, it was published in August 2015, and its ISSN is 2070-1721. The author team is S. Gundavelli (the editor, "Ed.") and K. Leung, both from Cisco, plus G. Tsirtsis from Qualcomm and A. Petrescu from CEA, LIST 💅. The title block doesn't say it obsoletes or updates anything.

Abstract 💜

okay so this spec adds extensions to the Mobile IP protocol so a mobile node with multiple interfaces can register a care-of address for each interface and set up multiple IP tunnels with its home agent at the same time 🫶. The big payoff is that the mobile node can use all of its available interfaces and build a higher aggregated logical pipe with its home agent for its home address traffic. Lowkey iconic 🔥. The extensions also let the mobile node and the home agent negotiate IP traffic flow policies, so individual flows get bound to the care-of addresses that were registered.

Status of This Memo ✨

this one's giving "not a standard, just for poking at" 🙈. It's not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation.

It defines an Experimental Protocol for the Internet community, and it's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🌸.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7629.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 📜.

Table of Contents 🗂️

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
     2.1.  Conventions . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Example Call Flow . . . . . . . . . . . . . . . . . . . .   6
   4.  Message Extensions  . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Multipath Extension . . . . . . . . . . . . . . . . . . .   7
     4.2.  Flow-Binding Extension  . . . . . . . . . . . . . . . . .   9
     4.3.  New Error Codes for Registration Reply  . . . . . . . . .  12
   5.  Protocol Operation  . . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Mobile Node Considerations  . . . . . . . . . . . . . . .  12
     5.2.  Home Agent Considerations . . . . . . . . . . . . . . . .  14
   6.  Routing Considerations  . . . . . . . . . . . . . . . . . . .  14
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1. Introduction ✨

okay so phones now come with a bunch of wireless interfaces and can connect through any of them 📱. Most mobile devices have Wi-Fi and LTE (Long Term Evolution), for example. In lots of deployments, it's desirable for a mobile node to use all of its available interfaces and get IP mobility support for its IP flows 🌈.

Mobile IP [RFC5944] lets a mobile node keep using its home address while it moves around the Internet 🦋. Depending on the mode, an IP tunnel gets set up either between the home agent and the mobile node, or between the home agent and the foreign agent where the mobile node is attached (see [RFC5944]). In both modes, only one interface on the mobile node is receiving IP traffic from the home agent. Honestly, that's not efficient 💀, so we need Mobile IP to use multiple access interfaces at the same time for routing the mobile node's IP traffic. The goal is to use every available access link well and get higher aggregated bandwidth for the tunneled traffic between the home agent and the mobile node 🚀.

This specification extends Mobile IPv4 so a mobile node with multiple interfaces can register a care-of address for each interface and use all of its access links at once for its IP traffic 💖. It also lets the mobile node and the home agent optionally negotiate IP flow policies for binding individual IP flows to the registered care-of addresses 🫶.

2. Conventions and Terminology 🎀

2.1. Conventions

okay here's the key word situation 🗝️. In this document, the key words are to be interpreted as described in RFC 2119 [RFC2119]:

"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"

2.2. Terminology

okay so all the mobility-related terms are to be read the way [RFC5944] and [RFC3753] define them 📖. This doc also uses a couple of its own terms, below ✨.

Binding Identifier (BID)

It's an identifier assigned to a mobile node's binding 💅. A binding is an association between a mobile node's home address and its registered care-of address. When a mobile node registers multiple bindings with its home agent, each using a different care-of address, every one of those bindings gets its own unique identifier. Each binding identifier has a unique value that differs from the identifiers given to the mobile node's other bindings 🔥.

Flow Identifier (FID)

It's an identifier for a given IP flow, uniquely identified by source address, destination address, protocol type, source port, destination port, Security Parameter Index, and other parameters as identified in [RFC6088] 🧚. In this document, the IP flows associated with a mobile node are the ones using its home address. For a mobile router, the IP flows also include the ones using the mobile network prefix [RFC6626] 🌸.

3. Overview 🦋

okay picture this: Figure 1 shows a mobile node connected to WLAN, LTE, and CDMA access networks 📶. The mobile node is configured with a home address, HoA_1, and has picked up these care-of addresses [RFC5944]: CoA_1 from the WLAN network, CoA_2 from the LTE network, and CoA_3 from the CDMA network 💜.

The mobile node using the extensions in this document registers all three care-of addresses with its home agent. It also sets up an IP tunnel with the home agent using each of its IP addresses, so you get three IP tunnels (Tunnel_1, Tunnel_2, and Tunnel_3) between the mobile node and the home agent 🌈. Each tunnel is an overlay routing path between the mobile node and the home agent, and it can be used to forward the mobile node's IP traffic ✨.

With the extensions in this document, the mobile node and the home agent can negotiate an IP flow policy 🤝. That negotiated policy lets them decide which access network path each of the mobile node's IP flows takes 👑.

   Flow_1 (SIP)
    |
    |Flow_2 (SSH)
    | |
    | |Flow_3 (HTTP)       _----_
    | | |         CoA_1  _(      )_ Tunnel_1
    | | |    .---=======(   Wi-Fi  )========\ Flow_1
    | | |    |           (_      _)          \
    | | |    |             '----'             \
    | | | +=====+          _----_              \  +=====+    _----_
    | | '-|     | CoA_2  _(      )_ Tunnel_2    \ |     |  _(      )_ --
    | '---| MN  |---====(   LTE    )=========-----| HA  |-( Internet )--
    '-----|     |        (_      _)      Flow_3 / |     |  (_      _) --
          +=====+          '----'              /  +=====+    '----'
           | |             _----_             /
    HoA_1--' |    CoA_3  _(      )_ Tunnel_3 /
             .------====(   CDMA   )========/ Flow_2
                         (_      _)
                           '----'

             Figure 1: Mobile Node (MN) with Multiple Tunnels
                          to the Home Agent (HA)

The table below shows how individual flows get bound to the different care-of addresses registered with the home agent 🍓.

   +=========+===================+=====================================+
   | Flow ID |   Access Network  |           Description               |
   |  (FID)  |    Preferences    |                                     |
   +=========+===================+=====================================+
   | Flow_1  | Tunnel_1 / CoA_1  | All SIP flows over Wi-Fi (Preferred)|
   |         | Tunnel_2 / CoA_2  | If Wi-Fi is not available, use LTE  |
   |         |       <DROP>      | If Wi-Fi and LTE access networks are|
   |         |                   | not available, drop the flow        |
   +---------+-------------------+-------------------------------------+
   | Flow_3  | Tunnel_2 / CoA_2  | All HTTP flows over LTE (Preferred) |
   |         |       <DROP>      | If LTE not available, drop the flow |
   +---------+-------------------+-------------------------------------+
   | Flow_2  | Tunnel_3 / CoA_3  | All SSH flows over CDMA (Preferred) |
   |         | Tunnel_2 / CoA_2  | If CDMA not available, use LTE      |
   |         | Tunnel_1 / CoA_1  | If LTE not available, use Wi-Fi     |
   +---------+-------------------+-------------------------------------+

                 Figure 2: Example of an IP Traffic Policy
more of this is coming in part 2, bestie 💖🧚

3.1. Example Call Flow 📞

Okay, so picture this: a mobile node is hanging out on both WLAN and LTE at the same time 📶. Figure 3 is the call flow for that exact example scenario, and it's giving full choreography ✨.

      +-------+          +-------+          +-------+          +-------+
      |   MN  |          | WLAN  |          |  LTE  |          |  HA   |
      |       |          |Network|          |Network|          |       |
      +-------+          +-------+          +-------+          +-------+
         |                   |                  |                  |

   * MIP RRQ is sent using the IP address obtained from the WLAN Network

         |<--- (1) --------->|                  |                  |
         |                   |   RRQ (Multipath, Flow-Binding)     |
         |---- (2) ----------------------------------------------->|
         |                   |   RRP            |                  |
         |<--- (3) ------------------------------------------------|
         |              MIP Tunnel through WLAN Network            |
         |=====(4)===========*=====================================|


   * MIP RRQ is sent using the IP address obtained from the LTE Network

         |<--- (5) ---------------------------->|                  |
         |                   |  RRQ (Multipath, Flow-Binding)      |
         |---- (6) ----------------------------------------------->|
         |                   |  RRP             |                  |
         |<--- (7) ------------------------------------------------|
         |              MIP Tunnel through LTE Access Network      |
         |=====(8)==============================*==================|
         |                                                         |
         *                                                         *
   (Policy-based Routing Rule)               (Policy-based Routing Rule)

Figure 3: Multipath Negotiation - Example Call Flow

Here's the play-by-play 🎬:

  • (1): The mobile node connects to the WLAN network and gets its IP address configuration for the WLAN interface 🛜.
  • (2)-(3): The mobile node sends a Registration Request (RRQ) [RFC5944] to the home agent through the WLAN network 💌. The message brings along the Multipath (Section 4.1) and the Flow-Binding (Section 4.2) Extensions 🎀. If the home agent says yes, it sends back a Registration Reply (RRP) [RFC5944] with a value of (0) in the Code field 🥰.
  • (4): The mobile node and the home agent set up a bidirectional IP tunnel over the WLAN network 🚇.
  • (5): The mobile node connects to the LTE network and grabs its IP address configuration from there 📡.
  • (6)-(7): The mobile node sends another Registration Request to the home agent, this time through the LTE network 💅. This one has the Multipath and Flow-Binding Extensions too 🫶. The Flow-Binding Extension says all HTTP flows need to go over the WLAN network, and if WLAN isn't available, they need to go over other access networks instead 🌐. The negotiated policy also says all voice-related traffic flows have to go over the LTE network 📞. If the home agent accepts, it sends back a Registration Reply with a value of (0) in the Code field 💜.
  • (8): The mobile node and the home agent set up a bidirectional IP tunnel over the LTE network 🦋. The negotiated traffic flow policy gets applied ✨. Then both the home agent and the mobile node send all the voice flows through the LTE tunnel, and all the HTTP flows over the WLAN network. Iconic 👑🔥.

4. Message Extensions ✨

This specification defines the following new extensions to Mobile IP 🎀.

4.1. Multipath Extension 🌈

This extension is how you request multipath support 🙌. It tells the home agent to register the current care-of address from this Registration Request as one of the many care-of addresses the mobile node can be reached through 📬. It also carries info about the interface that the care-of address being registered is bound to 🔌.

This extension is a non-skippable extension and MAY be added by the mobile node to the Registration Request message 💖. There MUST NOT be more than one instance of this extension present in the message 🙅‍♀️. This extension MUST NOT be added by the home agent to the Registration Reply 🚫.

This extension should be protected using the Mobile-Home Authentication Extension [RFC5944] 🔐. As specified in Sections 3.2 and 3.6.1.3 of [RFC5944], the mobile node MUST place this Extension before the Mobile-Home Authentication Extension in the registration messages, so that this extension is integrity protected 🛡️. Don't skip this part, bestie 😭.

Here's what the format looks like. It follows the long extension format described in [RFC5944] 🧚.

     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      |    Subtype    |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    If-ATT     |   If-Label    |   Binding ID  |B|O|  Reserved |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Multipath Extension

Now let's break down each field 🍓:

Type

Type: Multipath-Extension-Type (154) 🎀

Subtype

This field MUST be set to a value of 1 (Multipath Extension) 💅.

Length

This is the length of the extension in octets, not counting the Type, Subtype, and Length fields 📏. This field MUST be set to a value of 4 🔢.

Interface Access-Technology Type (If-ATT)

This 8-bit field identifies the Access Technology type of the interface the mobile node is connected through 📡. The permitted values come from the Access Technology Type registry defined in [RFC5213] 🗂️.

Interface Label (If-Label)

This 8-bit field holds the interface label as an unsigned integer 🏷️. The mobile node uses it to identify each interface it registers a CoA through with the home agent 🫶. When both sides use static traffic flow policies, the label can be used to index forwarding policies 🔍. For example, an operator might have a policy that binds an IP flow "F1" to any interface labeled "Blue" 💙. When a registration through a "Blue" interface gets activated, the home agent and the mobile node set up an IP tunnel and mark it with that label 🚇. Both of them then generate traffic rules that forward IP flow traffic "F1" through the mobile IP tunnel matching the label "Blue" 💫. The permitted values for If-Label are 1 through 255 🌸.

Binding Identifier (BID)

This 8-bit field carries the binding identifier 🪪. It uniquely identifies a specific binding of the mobile node associated with this Registration Request 🔑. Each binding identifier is an unsigned integer 🔢. The permitted values are 1 through 254 ✨. The BID values of 0 and 255 are reserved 🙈.

Bulk Re-registration Flag (B)

If the (B) flag is set to a value of (1), it tells the home agent to update the binding lifetime of all of the mobile node's bindings once it accepts this request ⏰. The (B) flag MUST NOT be set to a value of (1) if the Registration Overwrite Flag (O) is set to a value of (1) 🚫.

Heads up: (B) and (O) can't both be (1). Pick one, bestie 💀.

Registration Overwrite (O)

If the (O) flag is set to a value of (1), it tells the home agent that, once it accepts this request, it should replace all of the mobile node's existing bindings with the new binding created by this request 🧹. The (O) flag MUST NOT be set to a value of (1) if the Bulk Re-registration Flag (B) is set to a value of (1) 🙅‍♀️. This flag MUST be set to a value of (0) in De-Registration requests 🌷.

Reserved (R)

This 6-bit field is unused for now 🫧. The value MUST be initialized to (0) by the sender and MUST be ignored by the receiver 🤍.

4.2. Flow-Binding Extension 🦋

okay bestie, this extension is how the mobile node and the home agent team up to bind specific IP flows to a specific multipath registration 🔗✨ and yes, you can have more than one of these in a single message 💅

This one is a non-skippable extension 🚫⏭️. It MAY be added to the Registration Request by the mobile node, or to the Registration Reply by the home agent 🎀

Heads up: this extension should be protected by the Mobile-Home Authentication Extension [RFC5944] 🔐. As Section 3.2 and 3.6.1.3 of [RFC5944] explain, the mobile node MUST place this extension before the Mobile-Home Authentication Extension in the registration messages so that this extension is integrity protected 🛡️. The ordering is literally the whole point 💅

The format is shown below. It follows the long extension format from [RFC5944] 🧚

     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      |    Subtype    |           Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Action     |  BID Count    |        ...   BID List   ...   ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   TS Format   |             Traffic Selector                  ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 5: Flow-Binding Extension

Type 🏷️

The Type is Multipath-Extension-Type (154).

Subtype 🎯

This field MUST be set to a value of 2 (Flow-Binding Extension).

Length 📏

The length of the extension in octets, excluding Type, Subtype, and Length fields.

Action 🚦

The Action field identifies the traffic rule that needs to be enforced. Here are the possible values, bestie 👑

+---------+-------+-------------------------------------------------+
|  Action | Value | Description                                     |
+---------+-------+-------------------------------------------------+
|  DROP   |   0   | Drop matching packets. A filter rule            |
|         |       | indicating a drop action MUST include a single  |
|         |       | BID byte, the value of which MAY be set to 255  |
|         |       | by the sender and the value of which SHOULD be  |
|         |       | ignored by the receiver.                        |
+---------+-------+-------------------------------------------------+
| FORWARD |   1   | Forward matching packets to the first BID in the|
|         |       | list of BIDs the filter rule is pointing to.    |
|         |       | If the first BID becomes invalid (i.e., the     |
|         |       | corresponding CoA is de-registered), use the    |
|         |       | next BID in the list.                           |
+---------+-------+-------------------------------------------------+

          Figure 6: Action Rules for the Traffic Selector

BID Count 🔢

This is the total number of binding identifiers that follow this field. The permitted values for this field are 1 through 8. Each binding identifier is an unsigned integer in a single octet field. There's no delimiter between two binding identifier values, they're just spaced consecutively 🧃

TS Format 🧭

This is an 8-bit unsigned integer indicating the Traffic Selector (TS) Format. The value (0) is reserved and MUST NOT be used. When the TS Format field is set to (1), the format that follows is the IPv4 Binary Traffic Selector specified in Section 3.1 of [RFC6088]. When it's set to (2), the format that follows is the IPv6 Binary Traffic Selector specified in Section 3.2 of [RFC6088]. The IPv6 traffic selectors are only relevant when the mobile node registers IPv6 prefixes per [RFC5454] 🌸

Traffic Selector 🦋

This is a variable-length opaque field that includes the traffic specification identified by the TS Format field. It identifies the traffic selectors used to match IP traffic and bind it to specific binding identifiers 💜

4.3. New Error Codes for Registration Reply 🚨

This document defines the following error code values for the home agent to use in the Code field of the Registration Reply:

  • MULTIPATH_NOT_ALLOWED (Multipath Support not allowed for this mobile node): 152
  • INVALID_FB_IDENTIFIER (Invalid Flow-Binding Identifier): 153

5. Protocol Operation 🌈

5.1. Mobile Node Considerations 📱

  • The mobile node should register a care-of address for each connected interface it wants registered with the home agent 💖. It can do that by sending a Registration Request to the home agent through each of those interfaces.
  • Each Registration Request includes the care-of address of its respective interface. The Registration Request has to be routed through the specific interface the registration is for. Some of these interfaces may be connected to networks with a configured foreign agent on the link. In those foreign-agent-based registrations, the care-of address is the IP address of the foreign agent 🌐.
  • A Multipath Extension (Section 4.1) reflecting the interface parameters is present in each Registration Request. This tells the home agent the Registration Request is a Multipath registration, and the home agent will have to register this care-of address as one of the many care-of addresses through which the mobile node's home address is reachable 🗺️.
  • If the mobile node is configured to exchange IP flow policy with the home agent, the Flow-Binding Extension (Section 4.2) reflecting that flow policy can be included in the message. Otherwise, the Flow-Binding Extension will not be included 🎯.
  • The mobile node, upon receiving a Registration Reply with the Code value set to MULTIPATH_NOT_ALLOWED, MAY choose to register without the Multipath Extension specified in this document. This implies the home agent has not enabled multipath support for this mobile node, and hence multipath support MUST be disabled on the mobile node 🙅.
  • The mobile node, upon receiving a Registration Reply with the Code value set to INVALID_FB_IDENTIFIER, MUST re-register that specific binding with the home agent 🔁.
  • The mobile node at any time can extend the lifetime of a specific care-of address registration by sending a Registration Request to the home agent with a new lifetime value. The message MUST be sent as the initial multipath registration and must be routed through that specific interface. The message MUST include the Multipath Extension (Section 4.1) with the value in the Binding ID field set to the binding identifier assigned to that binding. Alternatively, the home agent can send a single Registration Request with the Bulk Re-registration Flag (B) set to a value of 1. This serves as a request to the home agent to update the registration lifetime of all the mobile node's registrations ⏰.
  • The mobile node can, at any time, de-register a specific care-of address by sending a Registration Request to the home agent with a lifetime value of 0. The message must include the Multipath Extension (Section 4.1) with the value in the Binding ID field set to the binding identifier assigned to that binding. Alternatively, the home agent can send a single Registration Request with the Bulk Re-registration Flag (B) set to a value of 1 and a lifetime value of 0. This serves as a request to the home agent to consider this request as a request to de-register all the mobile node's care-of addresses 👋.
  • The mobile node can, at any time, update the parameters of a specific registration by sending a Registration Request to the home agent. This includes a change of care-of address associated with a previously registered interface. The message must be sent as the initial multipath registration and must be routed through that specific interface. The message must include the Multipath Extension (Section 4.1) with the value in the Binding ID field set to the binding identifier assigned to that binding, and the Overwrite Flag (O) flag MUST be set to a value of 1 ✏️.
  • The mobile node, upon receiving a Registration Reply with the Code value set to 0 (registration accepted), will establish a Mobile IP tunnel to the home agent using that care-of address. When using a foreign agent care-of address, the tunnel is between the home agent and the foreign agent. The tunnel encapsulation type and any other parameters are based on the registration for that path. If there is also an exchange of flow policy between the mobile node and the home agent, with the use of Flow-Binding Extensions, then the mobile node must set up the forwarding plane that matches the flow policy 🚇.

5.2. Home Agent Considerations 🏠

The home agent, upon receiving a Registration Request from a mobile node with a Multipath Extension, should check whether the mobile node is authorized for multipath support. If multipath support is not enabled, the home agent MUST reject the request with a Registration Reply and with the Code set to MULTIPATH_NOT_ALLOWED 🚫.

If the received Registration Request includes a Multipath Extension and additionally has the Bulk Re-registration (B) flag set to a value of 1, then the home agent MUST extend the lifetime of all the bindings associated with that mobile node 🫶.

The home agent, upon receipt of a Registration Request with the Flow-Binding Extension, must process the extension and, upon accepting the flow policy, must set up the forwarding plane that matches the flow policy. If the home agent cannot identify any of the binding identifiers, then it MUST reject the request with a Registration Reply and with the Code set to INVALID_FB_IDENTIFIER 🔍.

If the received Registration Request includes a Multipath Extension and additionally has the Registration Overwrite (O) flag set to a value of 1, then the home agent MUST consider this as a request to replace all other mobile node's bindings with just one binding, and that is the binding associated with this request 👑

6. Routing Considerations 🛣️

okay so bestie, when multipath registration is turned on for a mobility node, there are going to be multiple Mobile IP tunnels between the mobile node and its home agent 🚇✨ To the forwarding plane of the mobile node, these tunnels look like equal-cost, point-to-point links. Lowkey iconic.

If the mobile node and the home agent also swap traffic flow policy using the Flow-Binding Extensions (Section 4.2), then the mobility entities can route the mobile node's IP traffic according to that negotiated flow policy 💅 But if multipath is turned on for a mobility session without any flow policy exchange, then both the mobile node and the home agent are required to have a pre-configured static flow policy. What that static flow policy actually means is outside the scope of this document, so don't ask me, I'm just the messenger 🙈

Now, when there's no traffic flow policy at all, most IP hosts can do two different load-balancing schemes: per-flow and per-packet load balancing [RFC2991] 🦋 Both of them let the forwarding plane spread traffic evenly across all the available equal-cost links that can reach a destination. Per-flow is the default vibe: a given flow always takes the same path, so packet re-ordering is off the table, and that's critical for delay-sensitive traffic 🫶 Per-destination load balancing uses all the paths way more effectively, but it can cause packet re-ordering on the receiving end 😭 And that gets especially dramatic when the access links have really different forwarding characteristics. A host can pick whichever of these approaches it wants to enable. Still, this specification recommends per-flow load balancing 🌸

7. IANA Considerations 📋

Here's what IANA has already handled for this document ✨

  • Action 1: This specification defines two new Mobile IP extensions, the Multipath Extension and the Flow-Binding Extension. The format of the Multipath Extension is in Section 4.1, and the format of the Flow-Binding Extension is in Section 4.2. Both of these are non-skippable extensions to the Mobile IPv4 header, following the long extension format of [RFC5944] 🔥 They both share the same Type value, Multipath-Extension (154), but they're told apart by different Subtype values. The Type value 154 was allocated from the "Extensions to Mobile IP Registration Messages" registry at http://www.iana.org/assignments/mobileip-numbers 🎀 For this extension, the field "Permitted for Notification Messages" MUST be set to "N".
  • Action 2: This specification defines a new message subtype space, the Multipath Extension subtype. That field is described in Section 4.1. IANA manages the values for this subtype field under the "Multipath Extension subtypes (Value 154)" registry 🧚 This specification reserves the following Type values, and approvals of new Multipath Extension subtype values go through IANA Expert Review [RFC5226] 💜
+=========================================================+
|  0    | Reserved                                        |
+=========================================================+
|  1    | Multipath Extension                             |
+=========================================================+
|  2    | Flow-Binding Extension                          |
+=========================================================+
|       |                                                 |
~ 3-254 | Unassigned                                      ~
|       |                                                 |
+=========================================================+
|  255  | Reserved                                        |
+=========================================================+
  • Action 3: This document defines new status code values, MULTIPATH_NOT_ALLOWED (152) and INVALID_FB_IDENTIFIER (153), for the home agent to use in the Code field of the Registration Reply, as described in Section 4.3 🙌 These values were assigned from the "Registration denied by the home agent" registry at http://www.iana.org/assignments/mobileip-numbers 🌈

8. Security Considerations 🔐

Okay, this one is serious but still a slay, so let's go 💀

This specification lets a mobile node set up multiple Mobile IP tunnels with its home agent, by registering a care-of address for each of its active roaming interfaces 🛸 Basically, the mobile node's IP traffic can get routed through any of the tunnel paths, based on either a static or a dynamically negotiated flow policy. This new capability has no impact on the protocol security 🔒 The spec also defines two new Mobile IP extensions, the Multipath Extension and the Flow-Binding Extension. These are supposed to be included in Mobile IP control messages, which are authenticated and integrity protected as described in [RFC5944] 🛡️ So, periodt: this specification does not weaken the security of the Mobile IP protocol and does not introduce any new security vulnerabilities 👑

9. References 📚

9.1. Normative References

9.2. Informative References

Acknowledgements 🫶

We would like to thank Qin Wu, Shahriar Rahman, Mohana Jeyatharan, Yungui Wang, Hui Deng Behcet Sarikaya, Jouni Korhonen, Michaela Vanderveen, Antti Makela, Charles Perkins, Pierrick Seite, Vijay Gurbani, Barry Leiba, Henrik Levkowetz, Pete McCann, and Brian Haberman for their review and comments on this document 💕

Contributors 🌟

This document reflects discussions and contributions from the following people:

  • Ahmad Muhanna, Email: asmuhanna@yahoo.com 💅
  • Srinivasa Kanduru, Email: skanduru@gmail.com 🍓
  • Vince Park, Email: vpark@qualcomm.com ✨
  • Hesham Soliman, Email: hesham@elevatemobile.com 🎀

Authors' Addresses 💌

Sri Gundavelli (editor)
Cisco
170 West Tasman Drive
San Jose, CA  95134
United States

Email: sgundave@cisco.com


Kent Leung
Cisco
170 West Tasman Drive
San Jose, CA  95134
United States

Email: kleung@cisco.com


George Tsirtsis
Qualcomm

Email: tsirtsis@qualcomm.com


Alexandre Petrescu
CEA, LIST
CEA Saclay
Gif-sur-Yvette , Ile-de-France  91191
France

Phone: +33169089223
Email: alexandre.petrescu@cea.fr

That's the whole thing, bestie! 🌈🦋💖 Thank you for being the absolute best protocol-reading buddy 👑✨

📦 where this page comes from