doc: Add RFC documents

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]
+