RFC 6089
Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support
RFC 6089 🎀 Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support
Okay bestie, this is RFC 6089 💖, a Standards Track doc from January 2011 (ISSN 2070-1721) from the IETF. The authors are G. Tsirtsis (Qualcomm), H. Soliman (Elevate Technologies), N. Montavont (IT/TB), G. Giaretta (Qualcomm), and K. Kuladinithi (University of Bremen). The only header relation it lists is that it updates RFC 5648 ✨, so it's building on that one. 🧚
Abstract 🦋
This document introduces extensions to Mobile IPv6 that let nodes bind one or more flows to a care-of address. These extensions let multihomed nodes tell home agents and other Mobile IPv6 entities to send inbound flows to specific addresses. 💅
Status of This Memo 🌸
This is an Internet Standards Track document. 🔥
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has had public review and has been approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741. ⭐
Info about the current status of this document, any errata, and how to give feedback on it is at http://www.rfc-editor.org/info/rfc6089. 🫶
Copyright Notice 🌈
Copyright (c) 2011 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) as in effect on the date of publication of this document. Please read these carefully, because they describe your rights and restrictions with respect to 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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 5
4.1. Definition Update for Binding Identifier Mobility
Option . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Flow Identification Mobility Option . . . . . . . . . . . 5
4.2.1. Flow Identification Sub-Options Definition . . . . . . 7
4.2.2. Flow Summary Mobility Option . . . . . . . . . . . . . 11
4.3. Flow Bindings Entries List and Its Relationship to
Binding Cache . . . . . . . . . . . . . . . . . . . . . . 12
5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 14
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Preferred Care-of Address . . . . . . . . . . . . . . 15
5.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 15
5.2.1. Sending BU with BID Options . . . . . . . . . . . . . 15
5.2.2. Sending BU with Flow Identification Mobility
Options . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 17
5.2.4. Removing Flow Bindings . . . . . . . . . . . . . . . . 18
5.2.5. Returning Home . . . . . . . . . . . . . . . . . . . . 18
5.2.6. Receiving Binding Acknowledgements . . . . . . . . . . 19
5.2.7. Return Routability Procedure . . . . . . . . . . . . . 19
5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 19
5.3.1. Handling Binding Identifier Mobility Options . . . . . 20
5.3.2. Handling Flow Identification Mobility Options . . . . 20
5.3.3. Handling Flow Summary Mobility Option . . . . . . . . 23
5.3.4. Flow Binding Removals . . . . . . . . . . . . . . . . 23
5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 24
5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 24
6. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 25
7. Security considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . . 291. Introduction ✨
Okay so Mobile IPv6 [RFC3775], Dual-Stack MIPv6 (DSMIPv6) [RFC5555], and Network Mobility (NEMO) Basic Support [RFC3963] let a mobile node / mobile router handle its mobility with the binding update message. That message ties one care-of address to one home address and its associated mobile networks. The binding update can go to the home agent, and in Mobile IPv6 it can also go to a correspondent node or a mobility anchor point (see [RFC5380]). 🦋
The big catch is that binding updates are only about changing the care-of address. [RFC3775], [RFC5555], and [RFC3963] don't let a mobile node / mobile router bind more than one address to the home address. [RFC5648] changed that, so Mobile IPv6 and NEMO Basic Support can bind more than one care-of address to a home address. 💅
This specification goes further. It lets Mobile IPv6, DSMIPv6, and NEMO Basic Support attach policies to each binding 🔥. A policy can ask for special treatment of a particular IPv4 or IPv6 flow, which is basically a group of packets that match a traffic selector. So a mobile node / mobile router can bind one particular flow to a care-of address without messing with the other flows on the same home address. It also lets you bind a flow to a specific care-of address directly with correspondent nodes and mobility agents (that's home agents [RFC3775] and mobility anchor points [RFC5380]). 🫶
In this doc, a flow is a set of IP packets that match a traffic selector. A traffic selector can look at source and destination IP addresses, the transport protocol number, source and destination port numbers, and other fields in IP and higher-layer headers. This spec doesn't define traffic selectors, since other specs are going to do that. What it does define is the traffic selector sub-option format, which is what you use for any specific traffic selector. 🌸
With the flow identifier option from this spec, a mobile node / mobile router can bind one or more flows to a care-of address while still receiving the other flows on another care-of address. The mobile node / mobile router builds its flow binding requests from local policies, link characteristics, and the kinds of apps running at the time. Those policies are outside the scope of this document. 🧚
Heads up 👀: the flow identification mobility option can go with any binding update, whether it's sent to a mobility agent or a correspondent node.
Also, per-packet load balancing may hurt TCP congestion avoidance, because it's important to keep packets from the same TCP connection in order. That behavior is specified in [RFC2702]. Other problems are expected for real-time connections too, because round-trip time can vary a lot between packets. And per-packet load balancing will mess with traffic that uses anti-replay protection. 🙈 So per-packet load balancing is not envisioned in this specification.
Throughout the rest of the document, "mobile node" means either a mobile node as defined in [RFC3775] and [RFC5648], or a mobile router as defined in [RFC3963], unless it says otherwise. 💖
2. Requirements Notation 📝
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]. 💅
3. Terminology 🎀
Terms used in this document are defined in [RFC3753] and [RFC4885]. These extra terms are also used here:
- Flow: a flow is a sequence of packets that the mobile node (MN) wants special handling for, either from the home agent (HA), the corresponding node (CN), or the mobility anchor point (MAP). 🦋
- Traffic Selector: one or more parameters that can be matched against fields in a packet's headers so the packet can be classified. Examples are source and destination IP addresses, transport protocol number, source and destination port numbers, and other fields in IP and higher-layer headers. 🌈
- Flow binding: this consists of a traffic selector and one or more binding identifiers (BIDs). IP packets from one or more flows that match the traffic selector tied to the flow binding are forwarded to the BIDs tied to that same flow binding. 🔥
- Flow Identifier: a flow identifier uniquely identifies a flow binding associated with a mobile node. The mobile node generates it, and it's cached in the table of flow binding entries kept by the MN, HA, CN, or MAP. 🫶
4. Mobile IPv6 Extensions 🧚
This section introduces the Mobile IPv6 extensions needed to support the flow binding mechanism described in this document. ✨
4.1. Definition Update for Binding Identifier Mobility Option 💜
This specification updates the definition of the Binding Identifier Mobility option defined in [RFC5648], as follows:
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 = 35 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID (BID) | Status |H| BID-PRI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ +
: IPv4 or IPv6 Care-of Address (CoA) :
+ +
+---------------------------------------------------------------+Figure 1: The Binding Identifier Mobility Option
BID-PRI 🍓
This is a 7-bit unsigned integer that gives each BID a relative priority (PRI) compared to the other registered BIDs. The value '0' is reserved and MUST NOT be used. A lower number means higher priority. BIDs with the same BID-PRI value have equal priority, which means the implementation decides which BID gets used. This matches how packet classifiers work in current practice. Main character energy, honestly 👑
4.2. Flow Identification Mobility Option ✨
okay bestie, the flow identification mobility option is a brand new mobility option [RFC3775] 💅 It rides along in the binding update and acknowledgement messages. Its whole job is giving the receiver of a binding update what it needs to install policies on a traffic flow and route that flow to a given care-of address 🦋 You can stack multiple options in the same binding update message, so go wild. The alignment requirement is 2n 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Len | FID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID-PRI | Reserved | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-options (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Flow Identification Mobility OptionOption Type 🧚
45
Option Len 🌸
Length of the option in octets as per [RFC3775].
FID 💖
The Flow Identifier field is a 16-bit unsigned integer that holds the unique identifier for the flow binding. It's used to point at an existing flow binding or to create a brand new one 🌈 The mobile node is the one who sets this value. FID = 0 is reserved and MUST NOT be used. 🙈
FID-PRI 👑
This is a 16-bit unsigned integer priority field that tells you how important a particular option is. It's needed for when two different flow descriptions in two different options overlap, because the priority field decides which policy gets executed in that situation ✨ A lower number means a higher priority. '0' is reserved and MUST NOT be used. FID-PRI MUST be unique to each of the flows pertaining to a given MN. In other words, two FIDs MUST NOT be associated with the same FID-PRI value. no duplicates, bestie 💀
Status 🔥
This 8-bit unsigned integer field shows whether the flow binding operation for that particular flow in the option worked or flopped 😭 It's not relevant to the binding update message as a whole or to other flow identification options. It only matters when it shows up in the Binding Acknowledgement message, and it must be ignored in the binding update message. These values are reserved for the Status field inside the flow identification mobility option:
0 Flow binding successful
128 Administratively prohibited
129 Flow binding rejected, reason unspecified
130 Flow identification mobility option malformed
131 BID not found
132 FID not found
133 Traffic selector format not supportedSub-options (optional) 🍓
Zero or more sub-options, defined in Section 4.2.1.
4.2.1. Flow Identification Sub-Options Definition 🦋
Flow identification sub-options live inside the leftover space of the flow identification mobility option. They use a sub-option type-length-value (TLV) format, and it looks like this 💜
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Opt Type |Sub-Opt Length | Sub-Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flow Identification Sub-Option FormatSub-Opt Type 🌷
This is an 8-bit unsigned integer that indicates the sub-option Type. If a receiver runs into a sub-option Type value it doesn't recognize, the receiver MUST silently ignore and skip over that sub-option, and it still has to correctly handle any remaining sub-options in the same option. 🫶
Sub-Opt Len 🎀
This is an 8-bit unsigned integer that gives the length in octets of the flow identification sub-option. It counts only the sub-option itself, not the Sub-Opt Type and Sub-Opt Length fields. Heads up: Sub-Opt Type '0' (Section 4.2.1.1) is a special case and doesn't take a Sub-Opt Length field at all 👀
Sub-Option Data 🌈
A variable length field that holds data specific to the sub-option.
The subsections below spell out the sub-option Types that are currently defined for use in the flow identification option. Implementations MUST silently ignore any sub-options that they do not understand. 🙅♀️
These sub-options might have alignment requirements too. Following the convention in [RFC3775] for mobility options, they get lined up in a packet so that multi-octet values inside the sub-option Data field fall on natural boundaries. In other words, fields that are n octets wide sit at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8 ✨
4.2.1.1. Pad1 🧸
The Pad1 sub-option has no alignment requirements. Its format is as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Sub-Opt Type |
+-+-+-+-+-+-+-+-+Sub-Opt Type
0
NOTE: The format of the Pad1 sub-option is a special case. It has neither a sub-option Length field nor a sub-option Data field 🫠
Pad1 is used to insert one octet of padding into the flow identification option. If you need more than one octet of padding, the PadN sub-option (up next) should be used instead of stacking multiple Pad1 sub-options 💅
4.2.1.2. PadN 🌸
The PadN sub-option has no alignment requirements. Its format is as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Sub-Opt Type | Sub-Opt Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -Sub-Opt Type
1
Sub-Opt Len
Set to the length of the sub-option.
Sub-Opt Data
0 or more bytes set to 0 by the sender and ignored by the receiver.
PadN is used to insert two or more octets of padding in the flow identification mobility option. For N octets of padding, the sub-option Length field holds the value N, and the sub-option Data field is made up of N-2 zero-valued octets. PadN sub-option Data MUST be ignored by the receiver. 🙈
4.2.1.3. Binding Reference Sub-Option 🔗
This is the binding reference sub-option, which gets included in the flow identification mobility option. A node MUST NOT include more than one binding reference sub-option in a given flow binding identification option. This sub-option carries one or more BIDs defined in Multiple Care-of Addresses (MCoA) [RFC5648], and it links the flow described in a flow identification mobility option with one or more registered BIDs 🥰
When you bind a flow using this sub-option, the binding identifier mobility option, defined in [RFC5648], MUST be included in either the same binding update (BU) or an earlier one. The binding reference sub-option looks like this, and its alignment requirement is 2n ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Opt Type | Sub-Opt Len | BID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BID ........
+-+-+-+-+-+-+-+-+-+-
Figure 4: The Binding Reference Sub-OptionSub-Opt Type
2
Sub-Opt Len
Variable
BID
A 16-bit unsigned integer indicating the BID that the mobile node wants to associate with the flow identification option. You can include one or more BID fields in this sub-option. Since each BID is 2 bytes long, the value of the Sub-opt Len field tells you how many BIDs are present. Number of BIDs = Sub-Opt Len/2.
4.2.1.4. Traffic Selector Sub-Option 🎯
The traffic selector sub-option holds the parameters used to match packets for a specific flow binding. A node MUST NOT include more than one traffic selector sub-option in a given flow binding identification 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Opt Type | Sub-Opt Len | TS Format | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Selector ...
+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Traffic Selector Sub-OptionSub-Opt Type
3
Sub-Opt Len
Variable
TS Format
An 8-bit unsigned integer indicating the Traffic Selector Format. The value "0" is reserved and MUST NOT be used.
Reserved
An 8-bit reserved field. It MUST be set to zero by the sender and ignored by the receiver.
Traffic Selector
A variable-length field whose format and content are out of scope for this specification. The traffic selector defined in [RFC6088] is mandatory to implement. 🌟
4.2.2. Flow Summary Mobility Option 📋
The flow summary mobility option is another new mobility option [RFC3775], and its job is to include one or more flow identifiers (FIDs) so it can refresh their state. The alignment requirement is 2n 🫧
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Len | FID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID ........
+-+-+-+-+-+-+-+-+-+-
Figure 6: The Flow Summary Mobility OptionOption Type
44
Option Length
Length of the option in octets as per [RFC3775].
FID
A 16-bit unsigned integer indicating a registered FID. You can include one or more FID fields in this option. Number of FIDs = Option Len/2. 🦋
4.3. Flow Bindings Entries List and Its Relationship to Binding Cache
Okay so the Mobile IPv6 binding cache was first defined in [RFC3775] to keep track of the mobile IP state that the mobile node, mobility agent, and correspondent node all hold 🧚 It stores stuff like the mobile node's home address, the registered care-of address, and how long the binding lasts. Then [RFC5648] level-upped it so it can hold more than one care-of address, with each one getting its own binding identifier (BID) 💅
This spec doesn't modify the binding cache any further, so no new changes there 🙈
Flow bindings are their own thing, kind of like a conceptual list of entries that lives separately from the binding cache ✨ The flow bindings list has an entry for each registered flow binding, and each entry points back to the binding cache by way of the BID. Every flow binding entry has these parameters:
- FID (Flow Identifier): For a given mobile node, identified by its primary home address, the FID MUST uniquely identify an entry, i.e., a unique flow binding. Each mobile node can only have a single entry identified by a given FID at any one time. A given FID number space is used for all the addresses associated to a given MN by the HA (e.g., via [RFC3963]). Different mobile nodes use the same FID number space.
- A Traffic Selector: Included in a traffic selector sub-option.
- BID(s): The list of BIDs associated with the entry as defined by the binding reference sub-option included in the FID option that created it.
- Active/Inactive flag: This flag indicates whether the entry is active or inactive.
- FID-PRI: This field indicates the priority of the flow binding and is used to break the tie between overlapping flow bindings.
The flow bindings list is associated with a given mobile node, and the correspondent binding cache. An entry in the flow bindings list, however, is identified by the FID, and the list is ordered according to the FID-PRI field as defined in the FID option that created each entry.
A valid BID is required to make the entry 'Active'. If all of the BIDs pointed to by a given entry are deregistered [RFC5648], the flow binding entry becomes 'Inactive', in other words it does not affect data traffic. Note that an entry becomes 'Inactive' only if all of the BIDs are deregistered. If only some of the BIDs are still valid, the invalid BIDs are simply ignored 🫶
Also, the state described in this section is maintained by the mobile node as well as in mobility agents and correspondent nodes. As such, the mobile node is fully aware of which BIDs are valid at any time and which flow binding entries are active/inactive. Section 5 defines how these flow binding entries are manipulated by the mobile node in detail 🌸
As an example, the following represents an ordered flow binding entry table for a mobile node that has registered multiple care-of addresses and flow bindings:
FID-PRI FID Traffic Selector BIDs A/I
------- --- ---------------- ---- -------
10 4 TCP 2 Active
30 2 srcAddr=IPy 4 Inactive
40 5 UDP 1,3 Active
Ordered Flow Binding EntriesAccording to the above list of flow binding entries, all TCP traffic will match the first entry, and will be forwarded to BID2, corresponding to a given care-of address (IP3), as shown below. 🦋
The second entry is marked as 'Inactive' since the BID 4 does not exist in the ordered list of BID entries below. Inactive entries do not affect traffic, i.e., packets are not matched against them 💀
Any UDP traffic that does not match any of the earlier entries will match the third rule, at which point it will be replicated and forwarded to BIDs 1 and 3, corresponding to care-of addresses IP1 and IP2 shown below. 👑
Finally, any remaining packets that do not match any of the entries above will simply be forwarded to the care-of address indicated by the highest order BID in the table below. In the example, such packets will be forwarded to BID1, corresponding to care-of address IP1 🍓
BID-PRI BID CoA
--------- --- ---
20 1 IP1
30 3 IP2
30 2 IP3
Ordered BID EntriesMobility agent and corresponding node implementations should take care to avoid flow binding rules affecting the fundamental operation of Mobile IPv6 and its extensions. In particular, flow binding rules MUST NOT apply to Mobile IPv6 signaling generated by mobility agents and corresponding nodes communicating with a given mobile node, since that could adversely affect the operation of the protocol. Other, non-MIPv6 traffic generated by these entities SHOULD be matched against the mobile node's flow binding rules as normal. 🔥
5. Protocol Operations
5.1. General
This specification introduces a flow bindings list of entries and an ordered list of flow binding identifiers, allowing mobile nodes to associate flow binding policies with the registered care-of addresses ✨
The flow identification mobility option defines how the mobile node can control a set of flow binding entries maintained in a mobility agent or correspondent node 🎀
This specification allows mobile nodes to direct flows to a particular care-of address. The granularity of what constitutes a flow depends on the traffic selector used 🌈
The rest of this section discusses how mobile nodes can use the options and sub-options defined in this document when sending binding updates to the correspondent node, home agent, or mobility anchor point. In addition, refresh, deletion, and modification of flow binding entries are all discussed below 🧚
5.1.1. Preferred Care-of Address
Any node that supports this specification MUST maintain an ordered list of care-of addresses for each mobile node for which it maintains a list of flow bindings. The ordered list of care-of addresses is built based on the BID-PRI field of the binding identifier mobility option (see Section 4.1) 💖
The ordered list of BIDs is used to determine how to forward a packet to a given mobile node when the packet does not match any of the flow binding entries defined in Section 4.3. A packet that does not match any of the flow binding entries SHOULD be forwarded to the care-of address identified by the BID with the highest priority, i.e., lowest BID-PRI value 👑
5.2. Mobile Node Considerations
This specification allows the mobile node to maintain several bindings with its mobility agent and correspondent nodes, and it allows it to direct packets to different care-of addresses according to flow bindings 🦋
The mobility agent and correspondent node list of flow bindings is manipulated by the mobile node, via flow identification and flow summary mobility options included in binding update messages. Each flow binding update can add, modify, refresh, or delete a given binding. More than one flow identification mobility option MAY be included in the same binding update, but each of them MUST include a different FID. In other words, two flow identification options in the same message cannot be about the same flow binding 🙈
All flow binding state MUST be refreshed in every binding update the mobile node sends. Any previously registered flow binding that is not included in a given binding update will be deleted. So, any flow bindings that are not added or modified by a flow identification mobility option, but have previously registered and need to be maintained, MUST be included in a flow summary mobility option 💅
5.2.1. Sending BU with BID Options
This specification (see Section 4.1) updates the definition of the binding identifier mobility option, originally defined in [RFC5648]. According to this specification, the BID option includes a BID-PRI field assigning each registered care-of address a priority, and thus places them in an ordered list, as also described in Section 4.3 🌸
To ensure backwards compatibility with [RFC5648], for the purpose of this specification, the field BID-PRI MUST NOT be set to zero.
Receiver implementation of this specification will take a BID-PRI field of value zero as an indication that this is a BID option of the format defined in [RFC5648] 🫶
Mobile nodes supporting this specification MUST use the BID option format defined in Section 4.1. Mobile nodes MUST also register all care-of addresses using the updated BID option format, either in the same BU as any flow identification mobility options using them or in earlier BUs ✨
5.2.2. Sending BU with Flow Identification Mobility Options
5.2.2.1. New Flow Bindings
When adding a new flow binding, a mobile node sends the flow identification mobility option in the binding update, with the FID field set to a value that is not already present in the list of flow binding entries maintained by the receiver. The care-of address(es) associated with each flow identification mobility option in the binding update must be logically registered by this binding update, or must have already been registered by the receiver of the binding update in an earlier binding update, as defined in Section 5.2.1 🎀
The flow identification mobility option MUST include a unique flow identifier in the FID field. The FID need only be unique for the receiver of the binding update and for the same sender, i.e., the same FID can be used across different receivers of the binding update, for the same sender. The FID-PRI field is set to the desired unique priority of the FID, defining the order of the flow binding to be added in the list of flow binding entries, as defined in Section 4.3. The Status field is set to zero in all binding update messages 🧚
Since this flow identification mobility option is requesting the addition of a new flow binding in the list of flow bindings maintained by the receiver, the mobile node MUST include exactly one traffic selector sub-option (see Section 4.2.1.4) describing the flow associated with the new flow binding. The TS Format field of the traffic selector sub-option MUST be set to the non-zero value of the format used by the mobile node 🌈
The mobile node MUST also include exactly one BID reference sub-option (see Section 4.2.1.3) to associate the flow binding with a given set of BIDs and corresponding CoAs 👑
5.2.2.2. Updating Flow Bindings ✨
okay so updating a flow binding is basically a glow-up for a binding that's already in your list 💅 You swap its parameters for whatever shows up in the flow identification mobility option, but the same FID stays put 🦋 so it's still the same binding, just upgraded. The mobile node can change the priority, the BID(s), and/or the traffic selector. iconic 👑
To modify an existing flow binding, the mobile node MUST send a binding update with a flow identification option, and the FID field MUST be set to one of the FID values already in the list of flow binding entries 🎀 The FID-PRI field MUST be set to the priority value for the flow binding entry. The Status field is set to zero, since this option is riding along in a binding update 🌸
The mobile node MAY include exactly one traffic selector sub-option (see Section 4.2.1.4) describing the updated flow for the flow binding. It MAY, however, omit the traffic selector sub-option if it wants to keep the traffic selector currently attached to the flow binding entry identified by the FID field 🙈
The mobile node MAY include exactly one binding reference sub-option (see Section 4.2.1.3) to link the existing flow binding up with a new set of CoAs 💜 It MAY omit the binding reference sub-option if it wants to keep the BIDs currently attached to the flow binding entry identified by the FID field.
Also, the mobile node can effectively change what a flow binding entry does without touching the entry itself 🧚 It does this by changing the CoA tied to a given BID, which is covered in detail in [RFC5648].
5.2.3. Sending BU with a Flow Summary Option 💌
When the mobile node sends a binding update, it MUST refresh all flow bindings it wants to keep, even if it isn't changing any of their parameters 🫶
To refresh an existing flow binding, the mobile node MUST send a binding update with a flow summary option. The flow summary option MUST include one or more FID fields, as indicated in Section 4.2.2. Each FID field included MUST be set to one of the FID values already in the list of flow binding entries. Each flow summary mobility option can identify up to 127 FIDs, so more than one such option can be included in a binding update message as required. A given FID SHOULD NOT be included more than once across all of the flow summary mobility options in a given binding update message 🍓
Any flow bindings (active or inactive) that aren't identified in a binding update will be removed from the list of flow binding entries 💀
Note that any inactive flow bindings, i.e., flow bindings without associated BIDs that are marked as 'Inactive' in the list of flow binding entries (see Section 4.3), MUST also be refreshed, or modified, to be maintained. If they aren't included in a BU message, they will be removed. no exceptions, bestie 😭
5.2.4. Removing Flow Bindings 🗑️
Removal is totally implicit: you just leave the FID out of a binding update 🫠
To remove a flow binding, the MN simply sends a binding update message that includes flow identification and flow summary mobility options for all the FIDs that need to be refreshed, modified, or added, and simply omits any FIDs that need to be removed.
Note that a mobile node can also render a flow binding inactive by removing the BIDs associated with it, without removing the flow binding itself. The procedure for removing a BID is defined in detail in [RFC5648] 🌙
When all the BIDs associated with a flow binding are removed, the flow binding MUST be marked as 'Inactive' in the list of flow binding entries, as shown in Section 4.3. In other words, the state associated with the flow binding MUST be maintained, but it no longer affects the mobile node's traffic. The MN can return an inactive flow binding to the active state by using the flow binding modification process, described in Section 5.2.2.2, to associate it again with one or more valid BIDs. comeback era arc 🦋🔥
5.2.5. Returning Home 🏠
This specification is compatible with the home registration procedures defined in [RFC3775] and [RFC5648]. More specifically, if the mobile node performs a deregistration in the [RFC3775] style, all of its bindings, including flow bindings are deleted 🧹 If the mobile node, however, performs a home registration in the [RFC5648] style, then the home link is associated with a specific BID, so as far as this specification is concerned, it's treated like any other link associated with a given BID 🌈
5.2.6. Receiving Binding Acknowledgements 📬
According to [RFC3775], all nodes are required to silently ignore mobility options they don't understand while processing binding updates. So, a mobile node receiving a Binding Acknowledgement message in response to a binding update message MUST determine if the Binding Acknowledgement message contains a copy of every flow identification mobility option included in the binding update. A Binding Acknowledgement without flow identification option(s), in response to a binding update with flow identification mobility option, would indicate the inability (or unwillingness) on behalf of the source node to support the extensions presented in this document. not it, not the vibe 🙅♀️
If a received Binding Acknowledgement contains a copy of each flow identification mobility option that was sent within the binding update, the Status field of each flow identification option indicates the status of the flow binding on the distant node ✨
5.2.7. Return Routability Procedure 🔐
A mobile node may perform route optimization with correspondent nodes, as defined in [RFC3775]. Route optimization lets a mobile node bind a care-of address to a home address, so the correspondent node can direct traffic to the mobile node's current location 📍 Before sending a binding update to correspondent node, the Return Routability Procedure needs to be performed between the mobile node and the correspondent node. This procedure is not affected by the extensions defined in this document 💅
5.3. HA, MAP, and CN Considerations 🏰
This specification allows the mobility agents (home agents and mobility anchor points), and correspondent nodes to maintain several flow bindings for a given home address and to direct packets to different care-of addresses according to flow bindings. This section details the home agent operations necessary to implement this specification. These operations are identical for MAPs and CNs, unless otherwise stated.
Note that route optimization is only defined for mobile nodes (MIPv6 [RFC3775]) and not mobile routers (NEMOv6 [RFC3963]). Thus, these sections only apply to correspondent nodes with respect to mobile nodes and not mobile routers 🙃
5.3.1. Handling Binding Identifier Mobility Options 🆔
This specification (see Section 4.1) updates the definition of the binding identifier mobility option, originally defined in [RFC5648]. According to this specification, the BID option includes a BID-PRI field that gives each registered care-of address a priority, and so places them in an ordered list (see Section 4.3) 📋
Home agents receiving BUs that include BID options and flow identification options MUST logically process BID options first. This is because BID reference sub-options included in the flow identification mobility options might refer to BIDs defined in BID options included in the same message 🧠
The BID option is processed as defined in [RFC5648], but then the BID to care-of address mapping is placed in an ordered list according to the BID-PRI field of the BID option.
Binding identifier registrations and deregistrations indirectly affect the MN's flow binding entries. The home agent MUST update the flow binding entries table accordingly as BIDs are added or removed (as per [RFC5648]). For example, as discussed in Section 4.3, if all of the BIDs associated with a given flow binding entry are removed (i.e., become invalid), the entry MUST be marked as 'Inactive'. While, if any of the invalid BIDs associated with an inactive flow binding entry are registered (i.e., become valid), the entry MUST be marked as 'Active'. plot twist energy 🎭
5.3.2. Handling Flow Identification Mobility Options 🧩
When the home agent receives a binding update that includes at least one flow identification mobility option, it first performs the operation described in section 10.3.1 of RFC 3775, followed by the operations defined in Section 5.3.1 of this document 📝
Home agents that do not support this specification will ignore the flow identification mobility options and all their sub-options, having no effect on the operation of the rest of the protocol 🙈
If the binding update is accepted, and the home agent is willing to support flow bindings for this MN, the home agent checks the flow identification mobility options 👀
If more than one flow identification mobility option in the same BU has the same value in the FID field, all the flow identification mobility options MUST be rejected 🚫
If all FID fields have different values, the flow identification mobility options can be processed further and in any order, as defined by the following subsections 🌸
5.3.2.1. Handling New FIDs ✨
okay so, if the FID field of the flow identification mobility option is not already in the list of flow binding entries for this mobile node, then this is a request for a brand new entry 💖
- If the flow identification mobility option does not include a traffic selector sub-option, the home agent MUST reject this request by copying the flow identification mobility option in the Binding Acknowledgement (BA) and setting the Status field to the value defined in Figure 2 for "Flow identification option malformed".
- If the flow identification option does include a traffic selector sub-option, but the format indicated in the
TS Formatfield is not supported, the home agent MUST reject this request by copying the flow identification mobility option in the BA, and setting the Status field to the value defined in Figure 2 for "Traffic Selector format not supported".
Then the home agent MUST check the binding reference sub-option 🔍
- If the binding reference sub-option is not included, the home agent MUST reject this request by copying the flow identification mobility option in the BA and setting the Status field to the value defined for "Flow identification mobility option malformed" in Section 4.2.
- If the binding reference sub-option is present and includes one or more BIDs that are not present in the binding cache of the mobile node, the home agent MUST reject this request by copying the flow identification option in the BA and setting the Status field to the value defined for "BID not found" in Section 4.2.
- If the binding reference sub-option is present and includes one or more BIDs, and the BIDs exist in the mobile node's binding cache, the home agent SHOULD add a new entry in the mobile node's list of flow binding entries, as defined below.
When the home agent decides to add an entry in the mobile node's list of flow binding entries (as we just talked about), it MUST do it according to the following rules 🎀 The entry MUST be placed according to the order indicated by the FID-PRI field of the flow identification mobility option, and it MUST include:
- the
FIDas a key to the entry, - the traffic selector included in the corresponding sub-option,
- the BIDs indicated in the binding reference sub-option, and
- the entry MUST be marked as 'Active', as shown in Section 4.3.
5.3.2.2. Handling Known FIDs 🦋
okay this one is the glow-up era 🌸 If the FID field of the flow identification mobility option is already in the list of flow binding entries for this mobile node, then this is a request to update the existing entry.
Modifying a flow binding is basically a process where the parameters of an existing flow binding entry get replaced by the parameters in a flow identification mobility option with the same FID as that entry. It's giving makeover 💅
The home agent MUST change the priority of the entry according to the FID-PRI field of the flow identification mobility option.
Since this flow identification mobility option is designed to update an existing entry, it may or may not include a traffic selector sub-option. Specifically:
- if a traffic selector sub-option is not included in the flow identification mobility option, then the traffic selector already associated with entry MUST be maintained;
- otherwise, the traffic selector in the entry MUST be replaced by the traffic selector in the sub-option.
Since this flow identification mobility option is designed to update an existing entry, it may or may not include a binding reference sub-option. Specifically:
- if a binding reference sub-option is not included in the flow identification mobility option, then the BIDs already associated with entry MUST be maintained;
- otherwise, the BIDs in the entry MUST be replaced by the BIDs in the sub-option.
5.3.3. Handling Flow Summary Mobility Option 🧚
When the home agent gets a binding update that includes flow summary mobility options, it first does everything described so far in Section 5.3. Then the fun part starts 💜
If the value of any of the FID fields included in a flow summary mobility option is not present in the list of flow binding entries for this mobile node, the home agent MUST reject this flow binding refresh by including a flow identification mobility option in the BA for each FID that is not found, and by setting the FID field to the value of the FID that is not found and the Status field to the value defined for "FID not found" in Section 4.2.
If the value of the FID field is present in the mobile node's list of flow binding entries, the home agent SHOULD refresh the flow binding entry identified by the FID without changing any of the other parameters associated with it.
If a given FID is included more than once in the same or different flow summary mobility options in the same binding update message, the duplicates can be simply ignored 🙈
Okay, this next note is important, so read it twice 🔥 An [RFC3775] deregistration binding update (with a zero lifetime) would result in deleting all bindings, including all flow bindings, regardless of whether flow summary mobility options are present. A binding update (with a zero lifetime) would result in deleting all bindings, including all flow bindings, regardless of the presence of flow summary mobility options. A specific binding deregistration, however, as defined in [RFC5648] (with a lifetime of zero and one or more binding identifier mobility options identifying specific BIDs), does not remove all the bindings for the MN. That's why it SHOULD include flow summary mobility options to maintain the flow bindings that need to be preserved 🫶
5.3.4. Flow Binding Removals 🗑️
Removing flow bindings happens implicitly, by leaving a given FID out of a binding update 👀
When a valid binding update is received, any registered FIDs that are not explicitly referred to in a flow identification mobility option or in a flow summary mobility option in the same binding update MUST be removed from the list of flow binding entries for the mobile node.
5.3.5. Sending Binding Acknowledgements 📬
When a binding update comes in, the home agent has to send back a Binding Acknowledgement. The status code in the Binding Acknowledgement must be set as recommended in [RFC3775]. This status code does not tell anyone whether the flow bindings worked out, so don't go looking for that info here 🙅♀️
To let the mobile node know how its flow binding requests did, flow identification options SHOULD be included in the Binding Acknowledgement message. Specifically, the home agent SHOULD copy each flow identification mobility option received in the binding update and set its status code to an appropriate value. The home agent doesn't need to respond about FIDs included in a flow summary mobility option, only the ones in flow identification mobility options 💜 If the home agent successfully performs an operation requested in a flow identification option, the Status field on the copied flow identification mobility option in the BA SHOULD be set to the value defined for "Flow binding successful" in Section 4.2. Otherwise, it SHOULD be set to one of the rejection codes also defined in Section 4.2. Section 5.3.2 lists a number of cases where specific error codes should be used.
Home agents that support this specification MAY refuse to maintain flow bindings, either by setting the Status field of any flow identification mobility options to the value defined for "Administratively prohibited" in Section 4.2, or by just ignoring all the flow binding options 🙃
Also, BID options and their Status field are handled as defined in [RFC5648]. The BID-PRI field in a BID option included in the Binding Acknowledgement is copied from the BID-PRI field of the corresponding BID option in the binding request. ✨
5.3.6. Packet Processing 📦
This section defines the packet processing rules for this specification. This specification does not change any of the packet interception rules defined in [RFC3775] and [RFC5555]. These rules apply to HAs, MAPs, and CNs as part of the routing process for any packet whose destination address is set to a valid home address of the mobile node. For nodes other than CNs, this also applies to packets whose destination address is set to an address under any of the registered prefixes. These rules apply equally to IPv6 packets and to IPv4 packets, as per [RFC5555] 🌈
Before a packet is forwarded to the mobile node, it MUST be matched against the ordered list of flow bindings stored in the list of flow binding entries for this mobile node (see Section 4.3). A match is attempted with the traffic selector included in the first line (highest order) of the table. The first entry that creates a match defines how the packet is routed. When a packet matches the traffic selector of a given entry, a copy of the packet is forwarded to each of the care-of addresses associated with the BIDs indicated in the same line of the table. 🎯
If any of the BIDs indicated does not correspond to a valid care-of address (for example, the BID was deregistered), then that BID has no effect on the traffic. In other words, packets matching the flow binding are forwarded to the remaining BIDs, which point to registered care-of addresses. If none of the BIDs pointed to in a flow binding entry is valid, then the entry is considered to be inactive (as defined in Section 4.3) and is skipped. In other words, packets should not be matched against that entry 🙅♀️
If a packet does not match any of the active flow binding entries for the given MN, the packet SHOULD be forwarded to the highest order care-of address, i.e., the one associated with the BID with the lowest BID-PRI. 🍓
If a packet is fragmented, only the first fragment contains all IP and transport layer headers, while subsequent fragments only contain an IP header without transport layer headers. For this reason, it is possible that subsequent fragments do not match the same traffic selector as the initial fragment of such a packet. Unless specific measures are taken, the likely outcome is that the initial fragment is routed as the MN intended, while subsequent fragments are routed differently, probably based on the default flow binding. HAs, MAPs, and CNs SHOULD take care to forward all fragments of a given packet the same way, in accordance with the flow binding matching the first fragment of said packet. This should be possible, given that fragment headers include enough information to identify a fragment as part of a specific packet, but the details of how this is ensured are implementation specific and are not defined in this specification. 🧩
6. MTU Considerations 🚌
okay so bestie, the options and sub-options in this spec get added on top of what [RFC3775] and other related specs already define, and all of them can make binding update messages bigger 📏. Implementations SHOULD take care to minimize fragmentation by forming binding updates that are shorter than what the path MTU allows whenever possible 🫶.
This spec has a bunch of ways to shrink binding updates ✨. The most verbose operations are registering new BIDs, Section 4.1, and identifying new flows, Section 4.2.1.4. Implementations are encouraged to keep binding updates under the path's MTU by making full use of the BID reference sub-option, Section 4.2.1.3, and the flow summary option, Section 4.2.2. Those let you refer to care-of addresses and flow bindings that are already registered, and then register the new ones in later binding update messages 🧚.
7. Security considerations 🔐
this one is serious, so buckle up 😭. This doc introduces a new option that adds more granularity to the binding update and acknowledgement messages from [RFC3775], [RFC5555], and [RFC3963], which means it inherits all the security considerations discussed in those docs. The new option lets the mobile node associate some flows with one interface and other flows with another interface. Since the flow identification mobility option is part of the mobility header, it uses the same security as the binding update, whether that goes to a mobility agent or to a correspondent node 🛡️.
This spec does not open up new fundamental lines of attack on communications between the MN and its correspondent nodes 🙌. However, it does allow attacks at a finer granularity than attacks on the binding update itself. For example, an attacker can divert or replicate flows of special interest to an address of the attacker's choosing, if the attacker can impersonate the MN or modify a binding update sent by the MN. Hence, it becomes doubly critical that authentication and integrity services are applied to binding updates. no cap, this is a big deal 🚨
Finally, when the optional anti-replay feature of Encapsulating Security Payload (ESP) [RFC4303] is used and packets to and from different CoAs are sent on the same security association (SA), some packets could get discarded at the receiver because of the windowing mechanism that feature uses 🥲. So a sender SHOULD put traffic to and from different CoAs, but with the same HoA in the selector values, on different SAs to support Multiple Care-of Addresses properly 💅. To make that possible, the IPsec implementation SHOULD establish and maintain multiple SAs between a given sender and receiver, with the same selectors. How traffic gets spread across these parallel SAs for Multiple Care-of Addresses is up to the sender, and it is not negotiated by the Internet Key Exchange version 2 (IKEv2) protocol [RFC5996]. The receiver will process the packets from the different SAs without prejudice ⭐.
8. IANA Considerations 📚
this section is basically the spec's registry homework 🎀. The spec needs the following IANA assignments in existing namespaces, plus a few brand-new namespaces too.
New Mobility Options [RFC3775] is where the type numbers below live. You can grab the registry at http://www.iana.org under "Mobile IPv6 parameters" 🌐. Here are the assigned type numbers:
44 Flow Identification Mobility Option, defined in Section 4.2
45 Flow Summary Mobility Option, defined in Section 4.2.2Next up, there's a brand-new "Flow Identification Mobility Option Status Codes" namespace 💖. These 'Status' codes are defined in this spec, in Section 4.2:
0 Flow binding successful
1-127 Unassigned. Available for success codes to be allocated
via Standards Action or IESG Approval as per [RFC5226].
128 Administratively prohibited
129 Flow binding rejected, reason unspecified
130 Flow identification mobility option malformed
131 BID not found
132 FID not found
133 Traffic selector format not supported
134-250 Unassigned. Available for reject codes to be allocated
via Standards Action or IESG Approval as per [RFC5226].
251-255 Reserved for experimental use. This small number of
status codes should be sufficient for experiments with
currently unforeseen error conditions.There's also a new "Flow Identification Sub-Options" namespace for the flow identification mobility option 🧩. The sub-option space is defined in Figure 3. These sub-option Type values are defined in this spec:
0 Pad
1 PadN
2 BID Reference
3 Traffic Selector
4-250 Unassigned. Available for allocation based on Standards
Action or IESG Approval as per [RFC5226].
251-255 Reserved for experimental use. This small number of
sub-option Types should be sufficient for experiments with
additional parameters associated with a flow.And a new "Traffic Selector Format" namespace for the traffic selector sub-option 🦋. The format space is defined by the TS Format field in Figure 5. These values are defined in this spec:
0 Reserved
1-250 Unassigned. Available for allocation based on Standards
Action or IESG Approval as per [RFC5226].
251-255 Reserved for experimental use. This small number of
traffic selector format types should be sufficient for
experiments with different ways of representing a traffic
selector.Just like the Mobile IPv6 [RFC3775] number spaces, future allocations from these new number spaces require Standards Action or IESG Approval as per [RFC5226] 🙏.
9. Contributors 🫂
we want to give a special shoutout to the person who coauthored one of the documents used as source material for this one 👑:
Nikolaus A. Fikouras, niko@comnets.uni-bremen.de10. Acknowledgements 🌸
we also want to thank these people, listed in alphabetical order, for their contributions to this spec 💜: C. Castelluccia, D. Craig, K. ElMalki, K. Georgios, C. Goerg, C. Kaas-Petersen, J. Laganier, T. Noel, V. Park, F.-N. Pavlidou, P. Stupar. Also, a huge thank you to Gabor Fekete for the analysis that led to the BID reference sub-option, and to Henrik Levkowetz for suggesting support for other ways of describing flows 🥹✨.
11. References 📖
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009.
[RFC6088] Tsirtsis, G., Giaretta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings", RFC 6088,
January 2011.11.2. Informative References
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.Authors' Addresses 💌
George Tsirtsis
Qualcomm
EMail: tsirtsis@qualcomm.com
Hesham Soliman
Elevate Technologies
EMail: hesham@elevatemobile.com
Nicolas Montavont
Institut Telecom / Telecom Bretagne
2, rue de la chataigneraie
Cesson Sevigne 35576
France
Phone: (+33) 2 99 12 70 23
EMail: nicolas.montavont@telecom-bretagne.eu
URI: http://www.rennes.enst-bretagne.fr/~nmontavo//
Gerardo Giaretta
Qualcomm
EMail: gerardog@qualcomm.com
Koojana Kuladinithi
University of Bremen
ComNets-ikom
Otto-Hahn-Allee NW 1
Bremen, Bremen 28359
Germany
Phone: +49-421-218-8264
Fax: +49-421-218-3601
EMail: koo@comnets.uni-bremen.de
URI: http://www.comnets.uni-bremen.de/~koo/That's the whole RFC, bestie 🎉🦋 every section, registry, and reference is in there, and we're officially done ✨💅
📦 where this page comes from
- ietf: rfc6089 2011-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms