Flow Bindings in Mobile IPv6 and NEMO Basic Support
draft-ietf-mext-flow-binding-11.txt

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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on April 8, 2011.

Copyright Notice

Copyright (c) 2010 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 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.  Requirements notation
2.  Introduction
3.  Terminology
4.  Mobile IPv6 Extensions
    4.1.  Definition Update for Binding Identifier Mobility Option
    4.2.  Flow Identification Mobility Option
        4.2.1.  Flow Identification Sub-Options definition
        4.2.2.  Flow Summary Mobility Option
    4.3.  Flow Bindings entries list and its relationship to Binding Cache
5.  Protocol operations
    5.1.  General
        5.1.1.  Preferred Care-of address
    5.2.  Mobile Node Considerations
        5.2.1.  Sending BU with BID Options
        5.2.2.  Sending BU with Flow Identification Mobility Options
        5.2.3.  Sending BU with a Flow Summary Option
        5.2.4.  Removing flow bindings
        5.2.5.  Returning Home
        5.2.6.  Receiving Binding Acknowledgements
        5.2.7.  Return Routability Procedure
    5.3.  HA, MAP, and CN Considerations
        5.3.1.  Handling Binding Identifier Mobility Options
        5.3.2.  Handling Flow Identification Mobility Options
        5.3.3.  Handling Flow Summary Mobility Option
        5.3.4.  Flow Binding Removals
        5.3.5.  Sending Binding Acknowledgements
        5.3.6.  Packet Processing
6.  MTU Considerations
7.  Security considerations
8.  IANA Considerations
9.  Contributors
10.  Acknowledgements
11.  References
    11.1.  Normative References
    11.2.  Informative References
§  Authors' Addresses

1.  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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Introduction

Mobile IPv6 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), DSMIPv6 [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.) and NEMO Basic Support [RFC3963] (Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” January 2005.) 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 correspondent node or to a mobility anchor point (see [RFC5380] (Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, “Hierarchical Mobile IPv6 (HMIPv6) Mobility Management,” October 2008.)). The semantics of the binding update are limited to care-of address changes. That is, [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.), and [RFC3963] (Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” January 2005.) do not allow a mobile node / mobile router to bind more than one address to the home address. In [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.) 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 it 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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) and mobility anchor points [RFC5380] (Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, “Hierarchical Mobile IPv6 (HMIPv6) Mobility Management,” October 2008.)).

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.

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 behaviour is specified in [RFC2702] (Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, “Requirements for Traffic Engineering Over MPLS,” September 1999.). 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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) and [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.), or a mobile router as defined in [RFC3963] (Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” January 2005.) unless stated otherwise.

3.  Terminology

Terms used in this document are defined in [RFC3753] (Manner, J. and M. Kojo, “Mobility Related Terminology,” June 2004.) and [RFC4885] (Ernst, T. and H-Y. Lach, “Network Mobility Support Terminology,” July 2007.). The following terms are also used in this document:

Flow: A flow is a sequence of packets for which the 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 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.

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] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.), 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)            :
       +                                                               +
       +---------------------------------------------------------------+

BID-PRI

This is a 7-bit unsigned integer placing each BID to a relative priority 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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) 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.

     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) ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Option Type

To be assigned by IANA

Option Len

Length of the option in octets as per [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.).

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 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 (Flow Identification Sub-Options definition)

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

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.

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 (Pad1)) 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 which 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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), 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.

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 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 MCoA [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.). This sub-option associates the flow described in a 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] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.), 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.

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

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

Sub-opt Type

3

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 [I‑D.ietf‑mext‑binary‑ts] (Tsirtsis, G., Giaretta, G., Soliman, H., and N. Montavont, “Traffic Selectors for Flow Bindings,” February 2010.) is mandatory to implement.

4.2.2.  Flow Summary Mobility Option

The flow summary mobility option is a new mobility option [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), 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  ........
    +-+-+-+-+-+-+-+-+-+-

Option Type

To be assigned by IANA

Option Length

Length of the option in octets as per [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.)

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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) to identify the mobile IP state maintained by the mobile node, mobility agent, and correspondent node. The binding cache includes, between 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] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.) 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:

• 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] (Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” January 2005.)). Different mobile nodes use the same FID number space.
• A Traffic Selector: Included in a traffic selector sub-option.
• BID(s): The list of BIDs associated with the entry as defined by the binding reference sub-option included in the FID option that created it.
• Active/Inactive flag: This flag indicates whether the entry is active or inactive.
• FID-PRI: This field indicates the priority of the flow binding and is used to break the tie between overlapping flow bindings.

The flow bindings list is associated with a given mobile node, and the correspondent binding cache. An entry in the flow bindings list, however, is identified by the FID and the list is ordered according to the FID-PRI field as defined in the FID option that created each entry.

A valid BID is required to make the entry 'Active'. If all of the BIDs pointed to by a given entry are deregistered [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.), 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 are the valid BIDs at any time and which flow binding entries are active/inactive. Section 5 (Protocol operations) 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

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.

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

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 Mobile IPv6 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.

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 it maintains a list of flow bindings for. 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 (Definition Update for Binding Identifier Mobility Option)).

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 (Flow Bindings entries list and its relationship to Binding Cache). 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 to direct packets to different care-of addresses according to flow bindings. This section details the mobile node operations necessary to implement this specification.

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 options 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 can not 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 (Definition Update for Binding Identifier Mobility Option)) updates the definition of the binding identifier mobility option, originally defined in [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.). According to this specification the BID option includes a BID-PRI field assigning each registered care-of address a priority, and thus placing them in an ordered list as also described in Section 4.3 (Flow Bindings entries list and its relationship to Binding Cache).

To ensure backwards compatibility with [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.) for the purpose of this specification the field BID-PRI MUST NOT be set to zero. Receiver implementation of this specification will take a BID-PRI field of value zero as an indication that this is a BID option of the format defined in [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.).

Mobile nodes supporting this specification MUST use the BID option format defined in Section 4.1 (Definition Update for Binding Identifier Mobility Option). 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 options 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 (Sending BU with BID Options).

The flow identification mobility option MUST include a unique flow identifier in the FID field. The FID needs 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 (Flow Bindings entries list and its relationship to Binding Cache). 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 (Traffic Selector sub-option)) 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 (Binding Reference Sub-option)) to associate the flow binding with a given set of BIDs and corresponding CoAs.

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 is 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 (Traffic Selector sub-option)) 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 (Binding Reference Sub-option)) 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] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.).

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 (Flow Summary Mobility Option). 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 options can identify up to 127 FIDs, so more than one such options can 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 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 (Flow Bindings entries list and its relationship to Binding Cache)), MUST also be refreshed, or modified, to be maintained. If they are not included in a BU 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 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] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.).

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 (Flow Bindings entries list and its relationship to Binding Cache). In other words the state associated with the flow binding MUST be maintained but it does no longer affect 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 (Updating Flow Bindings), to associate it again with one or more valid BIDs.

5.2.5.  Returning Home

This specification is compatible to the home registration procedures defined in [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) and [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.). More specifically, if the mobile node performs an [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) style deregistration, all of its bindings, including flow bindings are deleted. If the mobile node, however, performs an [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.) style home registration, 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.

5.2.6.  Receiving Binding Acknowledgements

According to [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) all nodes are required to silently ignore mobility options not understood while processing binding updates. As such, a mobile node receiving a Binding Acknowledgement in response to the transmission of a binding update MUST determine if the Binding Acknowledgement 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 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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.). 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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.)), and not mobile routers (NEMOv6 [RFC3963] (Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” January 2005.)). Thus, these sections only apply to correspondent nodes with respect to mobile nodes and not for mobile routers.

5.3.1.  Handling Binding Identifier Mobility Options

This specification (see Section 4.1 (Definition Update for Binding Identifier Mobility Option)) updates the definition of the binding identifier mobility option, originally defined in [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.). According to this specification the BID option includes a BID-PRI field assigning each registered care-of address a priority, and thus placing them in an ordered list (see Section 4.3 (Flow Bindings entries list and its relationship to Binding Cache)).

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] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.) 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] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.)). For example, as discussed in Section 4.3 (Flow Bindings entries list and its relationship to Binding Cache), 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 which includes at least one flow identification mobility option, it first performs the operation described in section 10.3.1 of RFC3775, followed by the operations defined in Section 5.3.1 (Handling Binding Identifier Mobility Options) of this document.

Home agents that do not support this specification will ignore the flow identification mobility options and all their sub-options, having no effect on the operation of the rest of the protocol.

If the binding update is accepted, and the home agent is willing to support flow bindings for this MN, the home agent checks the flow identification mobility options.

If more than one flow identification mobility option in the same BU, has the same value in the FID field, all the flow identification mobility options MUST be rejected.

If all FID fields have different values the flow identification mobility options can be processed further and in any order, as defined by the following subsections.

5.3.2.1.  Handling new FIDs

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 BA, and setting the Status field to the value defined in Figure 2 (The Flow Identification Mobility Option) 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 (The Flow Identification Mobility Option) 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 (Flow Identification Mobility Option).

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 (Flow Identification Mobility Option).

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:

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

the entry MUST be marked as Active, as shown in Section 4.3 (Flow Bindings entries list and its relationship to Binding Cache)

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.

5.3.3.  Handling Flow Summary Mobility Option

When the home agent receives a binding update which includes flow summary mobility options, it first performs the operation described so far in Section 5.3 (HA, MAP, and CN Considerations).

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 (Flow Identification Mobility Option).

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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) de-registration 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 de-registration, however, as defined in [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.) (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.

5.3.5.  Sending Binding Acknowledgements

Upon the reception of a binding update, the home agent is required to send back a Binding Acknowledgment. The status code in the Binding Acknowledgement must be set as recommended in [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.). 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 (Flow Identification Mobility Option), otherwise it SHOULD be set to one of the rejection codes also defined in Section 4.2 (Flow Identification Mobility Option). Section 5.3.2 (Handling Flow Identification Mobility Options) 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 (Flow Identification Mobility Option), or by just ignoring all the flow binding options.

Note that BID options and their Status field are handled as defined in [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.). The BID-PRI field in a BID option included in the binding acknowledgement is copied from the 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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), and [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.). These rules apply to HAs, MAPs, and CNs, as part of the routing process for any packet with destination address set to a valid home address of the mobile node. For nodes other than CNs this also applies to packets with 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] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.).

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 (Flow Bindings entries list and its relationship to Binding Cache)). 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 (Flow Bindings entries list and its relationship to Binding Cache)) 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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) and other related specifications, all of which potentially adds 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.

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 (Definition Update for Binding Identifier Mobility Option) and identifying new flows Section 4.2.1.4 (Traffic Selector sub-option). Implementations are encouradged to keep binding updates to sizes below than that of the path's MTU by making full use of BID reference Section 4.2.1.3 (Binding Reference Sub-option) sub-option and flow summary Section 4.2.2 (Flow Summary Mobility Option) option, 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 draft introduces a new option that adds more granularity to the binding update and acknowledgement messages defined in [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.), [RFC5555] (Soliman, H., “Mobile IPv6 Support for Dual Stack Hosts and Routers,” June 2009.), and [RFC3963] (Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol,” January 2005.), 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] (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.) is employed and packets from/to 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 from/to 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 (IKEv2) protocol [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.). The receiver will process the packets from the different SAs without prejudice.

8.  IANA Considerations

This specification requires the following IANA assignments on existing namespaces as well as the creation of some new namespaces.

1) New Mobility Options [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.): This registry is available from http://www.iana.org under "Mobile IPv6 parameters". The following type numbers need to be assigned for:

Flow Identification Mobility Option, define in Section 4.2 (Flow Identification Mobility Option)

Flow Summary Mobility Option, defined in Section 4.2.2 (Flow Summary Mobility Option)

2) New "Flow Identification Mobility Option Status codes" namespace needs to be created. The following 'Status' codes are defined in this specification, in Section 4.2 (Flow Identification Mobility Option):

0 Flow binding successful

1-127 unassigned and available for success codes to be allocated via Standards Action or IESG Approval as per [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.)

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 and available for reject codes to be allocated via Standards Action or IESG Approval as per [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.)

251-255 reserved for experimental use. This small number of status codes should be sufficient for experiments with currently unforeseen error conditions.

4) New "Flow Identification Sub-Options" namespace for the Flow Identification Mobility Option. The sub-option space is defined in Figure 3 (Flow Identification Sub-Option format). The following Sub-option Type values are defined in this specification:

0 Pad

1 PadN

2 BID Reference

3 Traffic Selector

4-250 unassigned and available for allocation based on Standards Action or IESG Approval as per [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.)

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.

5) New "Traffic Selector Format" namespace for the Traffic Selector sub-option. The traffic selector format space is defined by the TS Format field in Figure 5 (The Traffic Selector sub-option). The following values are defined in this specification:

0 Reserved

1-250 unassigned and available for allocation based on Standards Action or IESG Approval as per [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.)

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] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) number spaces, future allocations from the new number spaces requires Standards Action or IESG Approval as per [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.)

9.  Contributors

We would like to explicitly acknowledge the following person who co-authored one of the documents used as source material for this document.

Nikolaus A. Fikouras, niko@comnets.uni-bremen.de

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, F.-N. Pavlidou, V. Park, P. Stupar. Also, Gabor Fekete for the analysis that led to the inclusion of the BIDRef sub-option, and Henrik Levkowetz for suggesting support for other ways of describing flows.

11.  References

11.1. Normative References

11.2. Informative References

Authors' Addresses