GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6089

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

/data/webs/external/dokuwiki/data/pages/rfc/rfc6089.txt · Last modified: 2011/01/28 17:25 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki