diff options
Diffstat (limited to 'doc/rfc/rfc6089.txt')
| -rw-r--r-- | doc/rfc/rfc6089.txt | 1739 |
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc6089.txt b/doc/rfc/rfc6089.txt new file mode 100644 index 0000000..0d334a5 --- /dev/null +++ b/doc/rfc/rfc6089.txt @@ -0,0 +1,1739 @@ + + + + + + +Internet Engineering Task Force (IETF) G. Tsirtsis +Request for Comments: 6089 Qualcomm +Updates: 5648 H. Soliman +Category: Standards Track Elevate Technologies +ISSN: 2070-1721 N. Montavont + IT/TB + G. Giaretta + Qualcomm + K. Kuladinithi + University of Bremen + January 2011 + + + Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support + +Abstract + + This document introduces extensions to Mobile IPv6 that allow nodes + to bind one or more flows to a care-of address. These extensions + allow multihomed nodes to instruct home agents and other Mobile IPv6 + entities to direct 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 + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + + + + +Tsirtsis, et al. Standards Track [Page 1] + +RFC 6089 Flow Binding January 2011 + + + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided 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 . . . . . . . . . . . . . . . . . . 29 + + + + + + + +Tsirtsis, et al. Standards Track [Page 2] + +RFC 6089 Flow Binding January 2011 + + +1. Introduction + + Mobile IPv6 [RFC3775], Dual-Stack MIPv6 (DSMIPv6) [RFC5555], and + Network Mobility (NEMO) Basic Support [RFC3963] allow a mobile node / + mobile router to manage its mobility using the binding update + message, which binds one care-of address to one home address and + associated mobile networks. The binding update message can be sent + to the home agent. In Mobile IPv6, the binding update can also be + sent to a correspondent node or to a mobility anchor point (see + [RFC5380]). The semantics of the binding update are limited to + care-of address changes. That is, [RFC3775], [RFC5555], and + [RFC3963] do not allow a mobile node / mobile router to bind more + than one address to the home address. In [RFC5648], Mobile IPv6 and + NEMO Basic Support are extended to allow the binding of more than one + care-of address to a home address. This specification further + extends Mobile IPv6, DSMIPv6, and NEMO Basic Support to allow them to + specify policies associated with each binding. A policy can contain + a request for special treatment of a particular IPv4 or IPv6 flow, + which is viewed as a group of packets matching a traffic selector. + Hence, this specification allows a mobile node / mobile router to + bind a particular flow to a care-of address without affecting other + flows using the same home address. In addition, this specification + allows to bind a particular flow to a particular care-of address + directly with correspondent node and mobility agents (i.e., home + agents [RFC3775] and mobility anchor points [RFC5380]). + + In this document, a flow is defined as a set of IP packets matching a + traffic selector. A traffic selector can identify the source and + destination IP addresses, transport protocol number, the source and + destination port numbers and other fields in IP and higher-layer + headers. This specification does not define traffic selectors, which + are going to be defined in other specifications. This specification, + however, does define the traffic selector sub-option format to be + used for any specific traffic selector. + + Using the flow identifier option introduced in this specification, a + mobile node / mobile router can bind one or more flows to a care-of + address while maintaining the reception of other flows on another + care-of address. The mobile node / mobile router assembles the flow + binding requests based on local policies, link characteristics, and + the types of applications running at the time. Such policies are + outside the scope of this document. + + It should be noted that the flow identification mobility option can + be associated with any binding update, whether it is sent to a + mobility agent or a correspondent node. + + + + + +Tsirtsis, et al. Standards Track [Page 3] + +RFC 6089 Flow Binding January 2011 + + + Note that per-packet load balancing may have negative impacts on TCP + congestion avoidance mechanisms as it is desirable to maintain order + between packets belonging to the same TCP connection. This behavior + is specified in [RFC2702]. Other negative impacts are also foreseen + for other types of real-time connections due to the potential + variations in round-trip time between packets. Moreover, per-packet + load-balancing will negatively affect traffic with anti-replay + protection mechanisms. Hence, per-packet load balancing is not + envisioned in this specification. + + In the rest of the document, the term "mobile node" is used to + designate either a mobile node as defined in [RFC3775] and [RFC5648], + or a mobile router as defined in [RFC3963] unless stated 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]. + The following terms are also used in this document: + + Flow: A flow is a sequence of packets for which the mobile node + (MN) desires special handling either by 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 the packet's headers for the purpose of + classifying a packet. Examples of such parameters include the + source and destination IP addresses, transport protocol number, + the source and destination port numbers, and other fields in IP + and higher-layer headers. + + Flow binding: It consists of a traffic selector, and one or more + binding identifiers (BIDs). IP packets from one or more flows + that match the traffic selector associated with the flow binding + are forwarded to the BIDs associated with the same flow binding. + + Flow Identifier: A flow identifier uniquely identifies a flow + binding associated with a mobile node. It is generated by a + mobile node and is cached in the table of flow binding entries + maintained by the MN, HA, CN, or MAP. + + + + + + +Tsirtsis, et al. Standards Track [Page 4] + +RFC 6089 Flow Binding January 2011 + + +4. Mobile IPv6 Extensions + + This section introduces extensions to Mobile IPv6 that are necessary + for supporting 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 placing each BID to a relative + priority (PRI) with other registered BIDs. Value '0' is + reserved and MUST NOT be used. A lower number in this field + indicates a higher priority, while BIDs with the same BID-PRI + value have equal priority meaning that, the BID used is an + implementation issue. This is consistent with current practice + in packet classifiers. + +4.2. Flow Identification Mobility Option + + The flow identification mobility option is a new mobility option + [RFC3775], and it is included in the binding update and + acknowledgement messages. This option contains information that + allows the receiver of a binding update to install policies on a + traffic flow and route it to a given care-of address. Multiple + options may exist within the same binding update message. The + alignment requirement for this option is 2n. + + + + + + +Tsirtsis, et al. Standards Track [Page 5] + +RFC 6089 Flow Binding January 2011 + + + 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 Option + + Option 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 + includes the unique identifier for the flow binding. This + field is used to refer to an existing flow binding or to create + a new flow binding. The value of this field is set by the + mobile node. FID = 0 is reserved and MUST NOT be used. + + FID-PRI + + This is a 16-bit unsigned integer priority field to indicate + the priority of a particular option. This field is needed in + cases where two different flow descriptions in two different + options overlap. The priority field decides which policy + should be executed in those cases. A lower number in this + field indicates a higher priority. Value '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. + + Status + + This 8-bit unsigned integer field indicates the success or + failure of the flow binding operation for the particular flow + in the option. This field is not relevant to the binding + update message as a whole or to other flow identification + options. This field is only relevant when included in the + Binding Acknowledgement message and must be ignored in the + + + +Tsirtsis, et al. Standards Track [Page 6] + +RFC 6089 Flow Binding January 2011 + + + binding update message. The following values are reserved for + the Status field within 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 supported + + Sub-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 are encoded within the remaining + space of the flow identification mobility option, using a sub-option + type-length-value (TLV) format as follows: + + 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 Format + + Sub-Opt Type + + 8-bit unsigned integer indicating the sub-option Type. When + processing a flow identification mobility option containing an + option for which the sub-option Type value is not recognized by + the receiver, the receiver MUST silently ignore and skip over + the sub-option, correctly handling any remaining sub-options in + the same option. + + + + + + + +Tsirtsis, et al. Standards Track [Page 7] + +RFC 6089 Flow Binding January 2011 + + + Sub-Opt Len + + 8-bit unsigned integer, representing the length in octets of + the flow identification sub-option. This field indicates the + length of the sub-option not including the Sub-Opt Type and + Sub-Opt Length fields. Note that Sub-Opt Type '0' + (Section 4.2.1.1) is a special case that does not take a Sub- + Opt Length field. + + Sub-Option Data + + A variable length field that contains data specific to the sub- + option. + + The following subsections specify 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 may have alignment requirements. Following the + convention in [RFC3775], regarding mobility options, these sub- + options are aligned in a packet so that multi-octet values within the + sub-option Data field of each sub-option fall on natural boundaries + (i.e., fields of width n octets are placed 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 does not have any 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 sub-option Length nor sub-option Data fields. + + The Pad1 sub-option is used to insert one octet of padding in the + flow identification option. If more than one octet of padding is + required, the PadN sub-option, described next, should be used rather + than multiple Pad1 sub-options. + + + +Tsirtsis, et al. Standards Track [Page 8] + +RFC 6089 Flow Binding January 2011 + + +4.2.1.2. PadN + + The PadN sub-option does not have any 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. + + The PadN sub-option 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 contains the value N, and the sub-option + Data field consists 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 section introduces the binding reference sub-option, included in + the flow identification mobility option. A node MUST NOT include + more than one binding reference sub-options in a given flow binding + identification option. The binding reference sub-option includes one + or more BIDs defined in Multiple Care-of Addresses (MCoA) [RFC5648]. + This sub-option associates the flow described in a flow + identification mobility option with one or more registered BIDs. + + When binding a flow using this sub-option, the binding identifier + mobility option, defined in [RFC5648], MUST be included in either the + same or an earlier binding update (BU). The binding reference sub- + option is shown below. The alignment requirement for this sub-option + is 2n. + + + + + + +Tsirtsis, et al. Standards Track [Page 9] + +RFC 6089 Flow Binding January 2011 + + + 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-Option + + Sub-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. + One or more BID fields can be included in this sub-option. + Since each BID is 2 bytes long, the value of the Sub-opt Len + field indicates the number of BIDs present. Number of BIDs = + Sub-Opt Len/2. + +4.2.1.4. Traffic Selector Sub-Option + + The traffic selector sub-option includes 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-Option + + Sub-Opt Type + + 3 + + + +Tsirtsis, et al. Standards Track [Page 10] + +RFC 6089 Flow Binding January 2011 + + + Sub-Opt Len + + Variable + + TS Format + + An 8-bit unsigned integer indicating the Traffic Selector Format. + 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, the format and content of which is 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 a new mobility option [RFC3775], + which includes one or more flow identifiers (FIDs) for the purpose of + refreshing their state. The alignment requirement for this option 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 Option + + Option Type + + 44 + + Option Length + + Length of the option in octets as per [RFC3775]. + + + + + + + +Tsirtsis, et al. Standards Track [Page 11] + +RFC 6089 Flow Binding January 2011 + + + FID + + A 16-bit unsigned integer indicating a registered FID. One or + more FID fields can be included in this option. Number of FIDs + = Option Len/2. + +4.3. Flow Bindings Entries List and Its Relationship to Binding Cache + + The conceptual Mobile IPv6 binding cache was defined in [RFC3775] to + identify the mobile IP state maintained by the mobile node, mobility + agent, and correspondent node. The binding cache includes, among + others, the mobile node's home address, the registered care-of + address, and the lifetime of the binding. The binding cache has been + extended by [RFC5648] to include more than one care-of addresses and + to associate each of them with a binding identifier (BID). + + This specification does not modify the Mobile IPv6 binding cache any + further. + + Flow bindings can be thought of as a conceptual list of entries that + is separate from the binding cache. The flow bindings list contains + an entry for each of the registered flow bindings. Flow binding + entries point to an entry in the binding cache by means of the BID. + Each flow binding entry includes the following parameters: + + o 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. + + o A Traffic Selector: Included in a traffic selector sub-option. + + o 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. + + o Active/Inactive flag: This flag indicates whether the entry is + active or inactive. + + o FID-PRI: This field indicates the priority of the flow binding and + is used to break the tie between overlapping flow bindings. + + + + + + + +Tsirtsis, et al. Standards Track [Page 12] + +RFC 6089 Flow Binding January 2011 + + + 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, note that 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 Entries + + According 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. + + + + + + +Tsirtsis, et al. Standards Track [Page 13] + +RFC 6089 Flow Binding January 2011 + + + Finally, any remaining packets that do not match any of the entries + above will be simply 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 Entries + + Mobility 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 remainder 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. + + + + + + +Tsirtsis, et al. Standards Track [Page 14] + +RFC 6089 Flow Binding January 2011 + + +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. + + + +Tsirtsis, et al. Standards Track [Page 15] + +RFC 6089 Flow Binding January 2011 + + + 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. + + + + + + + +Tsirtsis, et al. Standards Track [Page 16] + +RFC 6089 Flow Binding January 2011 + + +5.2.2.2. Updating Flow Bindings + + Flow binding modification is essentially a process where parameters + associated with an existing flow binding in the list of flow binding + entries are replaced by parameters included in the flow + identification mobility option, and the same FID is maintained. With + this procedure, the mobile node can change the priority, the BID(s), + and/or the traffic selector associated with a flow binding. + + To modify an existing flow binding, the mobile node MUST send a + binding update with a flow identification option, with the FID field + 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 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 to be associated + with the flow binding. The mobile node MAY, however, omit the + traffic selector sub-option if it wants the traffic selector + currently associated with the flow binding entry identified by the + FID field to be maintained. + + The mobile node MAY include exactly one binding reference sub-option + (see Section 4.2.1.3) to associate the existing flow binding with a + new set of CoAs. The mobile node MAY omit the binding reference sub- + option if it wants the BIDs currently associated with the flow + binding entry identified by the FID field to be maintained. + + Note that it is also possible for the mobile node to effectively + modify the effect of a flow binding entry without actually changing + the entry itself. This can be done by changing the CoA associated + with a given BID, which is a process defined 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 maintain even if it does not want to change 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 + + + + + +Tsirtsis, et al. Standards Track [Page 17] + +RFC 6089 Flow Binding January 2011 + + + be included in a binding update message as required. A given FID + SHOULD NOT be included more than once in all of the flow summary + mobility options included in a given binding update message. + + Any flow bindings (active or inactive) that are not 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 are not included in a BU + message, they will be removed. + +5.2.4. Removing Flow Bindings + + Removal of flow binding entries is performed implicitly by omission + of a given FID from 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. + +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 and so, as far + as this specification is concerned, it is treated as any other link + associated with a given BID. + + + + +Tsirtsis, et al. Standards Track [Page 18] + +RFC 6089 Flow Binding January 2011 + + +5.2.6. Receiving Binding Acknowledgements + + According to [RFC3775], all nodes are required to silently ignore + mobility options not understood while processing binding updates. As + such, a mobile node receiving a Binding Acknowledgement message in + response to the transmission of a binding update message MUST + determine if the Binding Acknowledgement message contains a copy of + every flow identification mobility options 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. + + 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 allows a mobile + node to bind a care-of address to a home address in order to allow + the correspondent node to direct the traffic to the current location + of the mobile node. 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. + + + + + + + +Tsirtsis, et al. Standards Track [Page 19] + +RFC 6089 Flow Binding January 2011 + + +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 assigning each registered care-of address a priority, and thus + places them in an ordered list (see Section 4.3). + + Home agents receiving BUs including 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'. + +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. + + + + + +Tsirtsis, et al. Standards Track [Page 20] + +RFC 6089 Flow Binding January 2011 + + + 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 + + If the FID field of the flow identification mobility option is not + already present in the list of flow binding entries for this mobile + node, then this is a request for a 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 Format field 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 discussed above, 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: + + + +Tsirtsis, et al. Standards Track [Page 21] + +RFC 6089 Flow Binding January 2011 + + + the FID as 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 + + If the FID field of the flow identification mobility option is + already present in the list of flow binding entries for this mobile + node, then this is a request to update the existing entry. + + The flow binding modification is essentially a process where + parameters associated with an existing flow binding entry are + replaced by the parameters included in a flow identification mobility + option with the same FID as the existing entry. + + 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. + + + + + + + + +Tsirtsis, et al. Standards Track [Page 22] + +RFC 6089 Flow Binding January 2011 + + +5.3.3. Handling Flow Summary Mobility Option + + When the home agent receives a binding update that includes flow + summary mobility options, it first performs the operation described + so far in Section 5.3. + + 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 nodes 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. + + Note that, an [RFC3775] deregistration 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 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 lifetime of zero and one or + more binding identifier mobility options identifying specific BIDs) + does not remove all the bindings for the MN, and thus it SHOULD + include flow summary mobility options to maintain the flow bindings + that need to be preserved. + +5.3.4. Flow Binding Removals + + Removal of flow bindings is performed implicitly by omission of a + given FID from 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. + + + + + + +Tsirtsis, et al. Standards Track [Page 23] + +RFC 6089 Flow Binding January 2011 + + +5.3.5. Sending Binding Acknowledgements + + Upon the reception of a binding update, the home agent is required 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 give information on the success or failure of flow + bindings. + + In order to inform the mobile node about the status of the flow + binding(s) requested by a mobile node, 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. Note that the home agent does not need + to respond specifically regarding FIDs included in a flow summary + mobility option but only to those in flow identification mobility + options. If an operation requested in a flow identification option + by a mobile node is performed successfully by the home agent, 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 identifies a number + of cases where specific error codes should be used. + + Home agents that support this specification MAY refuse to maintain + flow bindings 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. + + Note that 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 packet processing rules according to 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 with a destination address set to a valid home address of the + mobile node. For nodes other than CNs, this also applies to packets + with a destination address set to an address under any of the + registered prefixes. These rules apply equally to IPv6 packets as + well as to IPv4 packets as per [RFC5555]. + + + + + +Tsirtsis, et al. Standards Track [Page 24] + +RFC 6089 Flow Binding January 2011 + + + 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, e.g., 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, pointing 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, and 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, and in accordance to the flow binding matching + the first fragment of said packet. This should be possible given the + fact 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 + + The options and sub-options defined in this specification add to + those defined in [RFC3775] and other related specifications, all of + which potentially add to the size of binding update messages. + Implementations SHOULD take care to minimize fragmentation by forming + binding updates that are shorter than what the path MTU allows + whenever possible. + + + +Tsirtsis, et al. Standards Track [Page 25] + +RFC 6089 Flow Binding January 2011 + + + This specification offers a number of mechanisms for reducing the + size of binding updates. The operations defined in this + specification that require the most verbose options are those + registering new BIDs, Section 4.1, and identifying new flows, + Section 4.2.1.4. Implementations are encouraged to keep binding + updates to sizes below that of the path's MTU by making full use of + the BID reference sub-option, Section 4.2.1.3, and flow summary + option, Section 4.2.2, which allows them to refer to already + registered care-of addresses and flow bindings, while registering new + ones in subsequent binding update messages. + +7. Security considerations + + This document introduces a new option that adds more granularity to + the binding update and acknowledgement messages defined in [RFC3775], + [RFC5555], and [RFC3963], so it inherits the security considerations + discussed in these documents. The new option allows the mobile node + to associate some flows to one interface and other flows to another + interface. Since the flow identification mobility option is part of + the mobility header, it uses the same security as the binding update, + whether it is sent to a mobility agent or to a correspondent node. + + This specification does not open up new fundamental lines of attack + on communications between the MN and its correspondent nodes. + However, it allows attacks of a finer granularity than those on the + binding update. For instance, the attacker can divert or replicate + flows of special interest to the attacker to an address of the + attacker's choosing, if the attacker is able to 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. + + Finally, when the optional anti-replay feature of Encapsulating + Security Payload (ESP) [RFC4303] is employed and packets to/from + different CoAs are sent on the same security association (SA), some + packets could be discarded at the receiver due to the windowing + mechanism used by this feature. Therefore, a sender SHOULD put + traffic to/from different CoAs, but with the same HoA in the selector + values, on different SAs to support Multiple Care-of Addresses + appropriately. To permit this, the IPsec implementation SHOULD + establish and maintain multiple SAs between a given sender and + receiver, with the same selectors. Distribution of traffic among + these parallel SAs to support Multiple Care-of Addresses is locally + determined by the sender and 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. + + + + + +Tsirtsis, et al. Standards Track [Page 26] + +RFC 6089 Flow Binding January 2011 + + +8. IANA Considerations + + This specification requires the following IANA assignments on + existing namespaces as well as the creation of some new namespaces. + + New Mobility Options [RFC3775]: This registry is available from + http://www.iana.org under "Mobile IPv6 parameters". The following + type numbers have been assigned for: + + 44 Flow Identification Mobility Option, defined in Section 4.2 + + 45 Flow Summary Mobility Option, defined in Section 4.2.2 + + A new "Flow Identification Mobility Option Status Codes" namespace + has been created. The following 'Status' codes are defined in + this specification, 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. + + + + + + + + + + + +Tsirtsis, et al. Standards Track [Page 27] + +RFC 6089 Flow Binding January 2011 + + + A new "Flow Identification Sub-Options" namespace for the flow + identification mobility option has been created. The sub-option + space is defined in Figure 3. The following sub-option Type + values are defined in this specification: + + 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. + + A new "Traffic Selector Format" namespace for the traffic selector + sub-option has been created. The traffic selector format space is + defined by the TS Format field in Figure 5. The following values + are defined in this specification: + + 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. + + Similar to the procedures specified for Mobile IPv6 [RFC3775] number + spaces, future allocations from the new number spaces requires + Standards Action or IESG Approval as per [RFC5226]. + +9. Contributors + + We would like to explicitly acknowledge the following person who + coauthored one of the documents used as source material for this + document. + + Nikolaus A. Fikouras, niko@comnets.uni-bremen.de + + + + + +Tsirtsis, et al. Standards Track [Page 28] + +RFC 6089 Flow Binding January 2011 + + +10. Acknowledgements + + We would also like to acknowledge the following people in + alphabetical order for their contributions to this specification: 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, Gabor Fekete for the analysis that led to the inclusion of the + BID reference sub-option, and 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. + + + + +Tsirtsis, et al. Standards Track [Page 29] + +RFC 6089 Flow Binding January 2011 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Tsirtsis, et al. Standards Track [Page 30] + +RFC 6089 Flow Binding January 2011 + + +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/ + + + + + + + + + +Tsirtsis, et al. Standards Track [Page 31] + |