One document matched: draft-ietf-mext-flow-binding-10.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='../../xml2rfc-1.34pre3/rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<!DOCTYPE rfc SYSTEM "../../xml2rfc-1.34pre3/rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2702 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2702.xml'>
<!ENTITY rfc3775 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml'>
<!ENTITY rfc3963 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3963.xml'>
<!ENTITY rfc3753 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3753.xml'>
<!ENTITY rfc4303 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml'>
<!ENTITY rfc4306 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml'>
<!ENTITY rfc4885 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4885.xml'>
<!ENTITY rfc5226 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
<!ENTITY rfc5380 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5380.xml'>
<!ENTITY rfc5555 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5555.xml'>
<!ENTITY rfc5648 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5648.xml'>
<!ENTITY ts PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mext-binary-ts-04.xml'>
]>
<rfc category="std" docName="draft-ietf-mext-flow-binding-10.txt" ipr="trust200902" updates="5648">
<!-- This is how you can add comments -->
<front>
<title abbrev="Flow binding">Flow Bindings in Mobile IPv6 and NEMO Basic Support</title>
<!-- AUTHORS -->
<author fullname="George Tsirtsis" initials="G." surname="Tsirtsis">
<organization>Qualcomm</organization>
<address>
<email>tsirtsis@qualcomm.com</email>
</address>
</author>
<author fullname="Hesham Soliman" initials="H." surname="Soliman">
<organization>Elevate Technologies</organization>
<address>
<email>hesham@elevatemobile.com</email>
</address>
</author>
<author initials="N.M" surname="Montavont" fullname="Nicolas Montavont">
<organization abbrev="IT/TB"> Institut Telecom / Telecom Bretagne</organization>
<address>
<postal>
<street>2, rue de la chataigneraie</street>
<city>Cesson Sevigne</city>
<code>35576</code>
<country>France</country>
</postal>
<phone>(+33) 2 99 12 70 23</phone>
<email>nicolas.montavont@telecom-bretagne.eu</email>
<uri>http://www.rennes.enst-bretagne.fr/~nmontavo//</uri>
</address>
</author>
<author fullname="Gerardo Giaretta" initials="G." surname="Giaretta">
<organization>Qualcomm</organization>
<address>
<email>gerardog@qualcomm.com</email>
</address>
</author>
<author initials="K." surname="Kuladinithi" fullname="Koojana Kuladinithi">
<organization abbrev="University of Bremen"> University of Bremen </organization>
<address>
<postal>
<street>ComNets-ikom,University of Bremen.</street>
<street> Otto-Hahn-Allee NW 1</street>
<city>Bremen</city>
<region>Bremen</region>
<code>28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-8264</phone>
<facsimile>+49-421-218-3601</facsimile>
<email>koo@comnets.uni-bremen.de</email>
<uri>http://www.comnets.uni-bremen.de/~koo/</uri>
</address>
</author>
<date month="September" year="2010"/>
<area>Internet</area>
<workgroup>IETF MEXT Working Group</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Requirements notation">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section title="Introduction" anchor="intro">
<t>Mobile IPv6 <xref target="RFC3775"/>, DSMIPv6 <xref target="RFC5555"/> and NEMO Basic
Support <xref target="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
correspondent node or to a mobility anchor point (see <xref target="RFC5380"/>). The
semantics of the binding update are limited to care-of address changes. That is,
<xref target="RFC3775"/>, <xref target="RFC5555"/>, and <xref target="RFC3963"/>
do not allow a mobile node / mobile router to bind more than one address to the home
address. In <xref target="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
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 <xref target="RFC3775"/>
and mobility anchor points <xref target="RFC5380"/>).</t>
<t>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, however, does not define traffic
di 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
selectors. </t>
<t> 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.</t>
<t>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.</t>
<t>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 <xref target="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. </t>
<t>In the rest of the document, the term "mobile node" is used to designate either a
mobile node as defined in <xref target="RFC3775"/> and <xref target="RFC5648"/>, or
a mobile router as defined in <xref target="RFC3963"/> unless stated otherwise.</t>
</section>
<section title="Terminology" anchor="term">
<t>Terms used in this document are defined in <xref target="RFC3753"/> and <xref
target="RFC4885"/>. The following terms are also used in this document:<list>
<t>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.</t>
<t>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. </t>
<t>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.</t>
<t>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.</t>
</list>
</t>
</section>
<section title="Mobile IPv6 Extensions" anchor="MIPv6ext">
<t>This section introduces extensions to Mobile IPv6 that are necessary for supporting
the flow binding mechanism described in this document.</t>
<section title="Definition Update for Binding Identifier Mobility Option"
anchor="BIDUpdate">
<t>This specification updates the definition of the Binding Identifier Mobility
option defined in <xref target="RFC5648"/>, as follows:</t>
<figure anchor="BIDup" title="The Binding Identifier Mobility option">
<artwork>
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) :
+ +
+---------------------------------------------------------------+
</artwork>
</figure>
<t>
<list>
<t>
<list style="hanging">
<t hangText="BID-PRI">
<vspace blankLines="1"/> 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. </t>
</list>
</t>
</list>
</t>
</section>
<section title="Flow Identification Mobility Option" anchor="FIDoption">
<t>The flow identification mobility option is a new mobility option <xref
target="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.</t>
<figure title="The Flow Identification Mobility Option" anchor="FIDformat">
<artwork>
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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list>
<t>
<list style="hanging">
<t hangText="Option Type">
<vspace blankLines="1"/> To be assigned by IANA</t>
<t hangText="Option Len">
<vspace blankLines="1"/> Length of the option in octets as per
<xref target="RFC3775"/>.</t>
<t hangText="FID">
<vspace blankLines="1"/> 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.</t>
<!-- FID=0 must not be used because in FIDSummary padding can be mistaken as FID=0 -->
<t hangText="FID-PRI">
<vspace blankLines="1"/> 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.</t>
<!-- <t hangText="Action">
<vspace blankLines="1"/> This 8-bit unsigned integer field
specifies the action that needs to be taken by the receiver of
the binding update containing the flow identification option.
The details of these requests are discussed below. The following
values are reserved for the Action field in this option: <list>
<t>0 Reserved and MUST NOT be used</t>
<t>1 'Discard'. This value indicates a request to discard
all packets in the flow described by the option. No BIDs
are associated with this Action. Care should be taken
when using this Action as it will lead to disrupting
applications communication. Implementations may consider
notifying impacted applications in mobile nodes.</t>
<t>2 'Forward'. This value indicates a request to send the
flow to one or more addresses indicated in the binding
reference sub-option (see <xref target="BIDRef"/>). One
or more BIDs MUST be associated with this Action. If
only one BID is associated with this action then it is
essentially a request to forward packets to that CoA,
otherwise matching packets are replicated and forwarded
to all of the indicated CoAs. Care should be taken when
multiple BIDs are used in combination with the 'Forward'
action as some transport layers may not be able to
handle packet duplication and this can affect their
performance.</t>
<t>3-255 Reserved for future use</t>
</list>
</t>-->
<t hangText="Status">
<vspace blankLines="1"/> 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: <list>
<t>0 Flow binding successful</t>
<t>128 Administratively prohibited</t>
<t>129 Flow binding rejected, reason unspecified</t>
<t>130 Flow identification mobility option malformed</t>
<t>131 BID not found</t>
<t>132 FID not found</t>
<t>133 Traffic selector format not supported</t>
</list>
</t>
<t hangText="Sub-options (optional)">
<vspace blankLines="1"/> zero or more sub-options, defined in
<xref target="suboptdef"/>
</t>
</list>
</t>
</list>
</t>
<section title="Flow Identification Sub-Options definition" anchor="suboptdef">
<t> 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:</t>
<figure title="Flow Identification Sub-Option format" anchor="subopt">
<artwork>
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list>
<t>
<list style="hanging">
<t hangText="Sub-opt Type">
<vspace blankLines="1"/> 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. </t>
<t hangText="Sub-opt Len">
<vspace blankLines="1"/> 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' (<xref target="pad1"/>)
is a special case that does not take a Sub-opt Length
field.</t>
<t hangText="Sub-Option Data">
<vspace blankLines="1"/> A variable length field that
contains data specific to the sub-option </t>
</list>
</t>
</list>
</t>
<t> 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.</t>
<t> These sub-options may have alignment requirements. Following the convention
in <xref target="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) .</t>
<section title="Pad1" anchor="pad1">
<t>The Pad1 sub-option does not have any alignment requirements. Its format
is as follows:</t>
<figure>
<artwork>
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Sub-Opt Type |
+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Sub-opt Type">
<vspace blankLines="1"/> 0 </t>
</list>
</t>
<t> NOTE! the format of the Pad1 sub-option is a special case - it has
neither sub-option Length nor sub-option Data fields.</t>
<t> 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.</t>
</section>
<section title="PadN">
<t> The PadN sub-option does not have any alignment requirements. Its format
is as follows:</t>
<figure>
<artwork>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Sub-opt Type">
<vspace blankLines="1"/> 1 </t>
<t hangText="Sub-opt Len">
<vspace blankLines="1"/> set to the length of the sub-option</t>
<t hangText="Sub-opt Data">
<vspace blankLines="1"/> 0 or more bytes set to 0 by the sender
and ignored by the receiver.</t>
</list>
</t>
<t>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.</t>
</section>
<section title="Binding Reference Sub-option" anchor="BIDRef">
<t>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 <xref target="RFC5648"/>. This sub-option associates the
flow described in a a flow identification mobility option with one or
more registered BIDs.</t>
<t>When binding a flow using this sub-option, the binding identifier
mobility option, defined in <xref target="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.</t>
<figure title="The Binding Reference sub-option" anchor="BIDREFFormat">
<artwork>
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 ........
+-+-+-+-+-+-+-+-+-+-
</artwork>
</figure>
<t>
<list>
<t>
<list style="hanging">
<t hangText="Sub-opt Type">
<vspace blankLines="1"/> 2 </t>
<t hangText="Sub-opt Len">
<vspace blankLines="1"/> Variable</t>
<t hangText="BID">
<vspace blankLines="1"/> 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. </t>
</list>
</t>
</list>
</t>
</section>
<section title="Traffic Selector sub-option" anchor="FDsub">
<t>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. </t>
<figure title="The Traffic Selector sub-option" anchor="FDsubFormat">
<artwork>
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 ...
+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="Sub-opt Type">
<vspace blankLines="1"/> 3 </t>
<t hangText="Sub-opt Len">
<vspace blankLines="1"/> variable</t>
<t hangText="TS Format">
<vspace blankLines="1"/> An 8-bit unsigned integer indicating
the Traffic Selector Format. Value "0" is reserved and MUST NOT
be used.</t>
<t hangText="Reserved">
<vspace blankLines="1"/> An 8-bit reserved field. It MUST be set
to zero by the sender and ignored by the receiver.</t>
<t hangText="Traffic Selector">
<vspace blankLines="1"/> A variable length field, the format and
content of which is out of scope for this specification. The
traffic selector defined in <xref
target="I-D.ietf-mext-binary-ts"/> is mandatory to
implement. </t>
</list>
</t>
</section>
</section>
<section title="Flow Summary Mobility Option" anchor="FIDSum">
<t>The flow summary mobility option is a new mobility option <xref
target="RFC3775"/>, which includes one or more flow identifiers (FIDs)
for the purpose of refreshing their state. The alignment requirement for
this option is 2n.</t>
<figure title="The Flow Summary Mobility Option" anchor="FIDSumFormat">
<artwork>
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 ........
+-+-+-+-+-+-+-+-+-+-
</artwork>
</figure>
<t>
<list>
<t>
<list style="hanging">
<t hangText="Option Type">
<vspace blankLines="1"/>To be assigned by IANA</t>
<t hangText="Option Length">
<vspace blankLines="1"/> Length of the option in octets as
per <xref target="RFC3775"/>
</t>
<t hangText="FID">
<vspace blankLines="1"/> 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</t>
</list>
</t>
</list>
</t>
</section>
</section>
<section title="Flow Bindings entries list and its relationship to Binding Cache"
anchor="BCext">
<t> The conceptual mobile IPv6 binding cache was defined in <xref target="RFC3775"/>
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 <xref target="RFC5648"/> to
include more than one care-of addresses and to associate each of them with a
Binding Identifier (BID).</t>
<t>This specification does not modify the mobile IPv6 binding cache any further.</t>
<t>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:</t>
<t>
<list style="symbols">
<t>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 <xref
target="RFC3963"/>). Different mobile nodes use the same FID number
space. </t>
<t>A Traffic Selector: Included in a traffic selector sub-option. </t>
<t>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.</t>
<t>Active/Inactive flag: This flag indicates whether the entry is active or
inactive.</t>
<t>FID-PRI: This field indicates the priority of the flow binding and is
used to break the tie between overlapping flow bindings.</t>
</list>
</t>
<t>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.</t>
<t>A valid BID is required to make the entry 'Active'. If all of the BIDs pointed to
by a given entry are deregistered <xref target="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.</t>
<t>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. <xref target="operation"/> defines how
these flow binding entries are manipulated by the mobile node in detail.</t>
<t>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.</t>
<figure title="Ordered Flow Binding Entries">
<artwork align="center" name="FLOWLIST">
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
</artwork>
</figure>
<t/>
<t>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. </t>
<t> 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.</t>
<t> 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. </t>
<t>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.</t>
<figure title="Ordered BID Entries">
<artwork align="center" name="BIDLIST">
BID-PRI BID CoA
--------- --- ---
20 1 IP1
30 3 IP2
30 2 IP3
</artwork>
</figure>
<t>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.</t>
</section>
</section>
<!-- End of Extensions to Mobile IPv6 -->
<section title="Protocol operations" anchor="operation">
<section title="General">
<t>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.</t>
<t>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. </t>
<t>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. </t>
<t>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.</t>
<section title="Preferred Care-of address" anchor="defaultbinding">
<t>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 <xref
target="BIDUpdate"/>).</t>
<t>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 <xref target="BCext"/>. 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.</t>
</section>
</section>
<section title="Mobile Node Considerations">
<t>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.</t>
<t>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. </t>
<t>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.</t>
<section title="Sending BU with BID Options" anchor="sendBID">
<t>This specification (see <xref target="BIDUpdate"/>) updates the definition of
the binding identifier mobility option, originally defined in <xref
target="RFC5648"/>. 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
<xref target="BCext"/>. </t>
<t>To ensure backwards compatibility with <xref target="RFC5648"/> for the
purpose of this specification the field BID-PRI MUST NOT be set to zero.
Receiver implementation of this specification will take a BID-PRI field of
value zero as an indication that this is a BID option of the format defined
in <xref target="RFC5648"/>.</t>
<t>Mobile nodes supporting this specification MUST use the BID option format
defined in <xref target="BIDUpdate"/>. 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.</t>
</section>
<section title="Sending BU with Flow Identification Mobility Options">
<section title="New Flow Bindings" anchor="addingFDs">
<t>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 <xref target="sendBID"/>.</t>
<t>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 <xref target="BCext"/>. The
Status field is set to zero in all binding update messages.</t>
<t>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 <xref target="FDsub"/>) 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.</t>
<t>The mobile node MUST also include exactly one BID Reference sub-option
(see <xref target="BIDRef"/>) to associate the flow binding with a given
set of BIDs and corresponding CoAs.</t>
</section>
<section title="Updating Flow Bindings" anchor="modifyingFDs">
<t>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.</t>
<t>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.</t>
<t>The mobile node MAY include exactly one traffic selector sub-option (see
<xref target="FDsub"/>) 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.</t>
<t>The mobile node MAY include exactly one binding reference sub-option (see
<xref target="BIDRef"/>) 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. </t>
<t>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 <xref target="RFC5648"
/>.</t>
</section>
</section>
<section title="Sending BU with a Flow Summary Option" anchor="refreshFDs">
<t>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.</t>
<t>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 <xref target="FIDSum"/>. 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.</t>
<t>Any flow bindings (active or inactive) that are not identified in a binding
update will be removed from the list of flow binding entries.</t>
<t>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
<xref target="BCext"/>), MUST also be refreshed, or modified, to be
maintained. If they are not included in a BU they will be removed.</t>
</section>
<section title="Removing flow bindings" anchor="deletingFDs">
<t>Removal of flow binding entries is performed implicitly by omission of a
given FID from a binding update.</t>
<t>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.</t>
<t>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 <xref target="RFC5648"
/>.</t>
<t>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 <xref target="BCext"/>. 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 <xref
target="modifyingFDs"/>, to associate it again with one or more valid
BIDs.</t>
</section>
<section title="Returning Home">
<t>This specification is compatible to the home registration procedures defined
in <xref target="RFC3775"/> and <xref target="RFC5648"/>. More specifically,
if the mobile node performs an <xref target="RFC3775"/> style
deregistration, all of its bindings, including flow bindings are deleted. If
the mobile node, however, performs an <xref target="RFC5648"/> 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.</t>
</section>
<section title="Receiving Binding Acknowledgements">
<t>According to <xref target="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 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.</t>
<t>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.</t>
</section>
<section title="Return Routability Procedure" anchor="mn-rrp">
<t>A mobile node may perform route optimization with correspondent nodes as
defined in <xref target="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.</t>
<!-- However, since a binding update
message is secured with the key generated based on the
home address and care-of address test, a mobile node
MUST NOT bind a flow to a care-of address whose keygen
token (see <xref target="RFC3775"/>) was not
used to generate the key for securing the Binding
Update. This limitation prohibits the sender from
requesting the 'Forward' action for multiple addresses
before having registered each care-of address one by
one.
< NM: don't need this sentence anymore:
Furthermore, it prohibits the sender from including a BID that does
not correspond to the care-of address whose keygen token was used to
secure the BU message.?
</t> -->
</section>
</section>
<section title="HA, MAP, and CN Considerations" anchor="HAops">
<t>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.</t>
<t>Note that route optimization is only defined for mobile nodes (MIPv6 <xref
target="RFC3775"/>), and not mobile routers (NEMOv6 <xref target="RFC3963"
/>). Thus, these sections only apply to correspondent nodes with respect to
mobile nodes and not for mobile routers.</t>
<section anchor="recvBID" title="Handling Binding Identifier Mobility Options">
<t>This specification (see <xref target="BIDUpdate"/>) updates the definition of
the binding identifier mobility option, originally defined in <xref
target="RFC5648"/>. 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 <xref target="BCext"
/>). </t>
<t>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.</t>
<t>The BID option is processed as defined in <xref target="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.</t>
<t>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 <xref
target="RFC5648"/>). For example, as discussed in <xref target="BCext"
/>, 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.</t>
<!--GT> Should we define an error code if BID-PRI field is set to 0? 0 is reserved for MCOA-only implementations that do not support Flow Bindings -->
</section>
<!-- <section
title="Handling Flow Identification Mobility Options in BUs"
anchor="HAops-receiving2">
<t>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. </t>
<t>Home agents that do not support this specification will
ignore the flow identification mobility options and all
their sub-option, having no effect on the operation of
the rest of the protocol.</t>
<t>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. </t>
<t>If more than one flow identification mobility options in
the same BU have the same value in the FID field, all
the flow identification options MUST be rejected.</t>
<t>If all FID fields have different values the flow
identification options can be processed further and in
any order, as defined by the following subsections. The
following processing rules refer to a single flow
identification mobility option and are to be repeated
for each such option.</t>
<t>If a flow identification mobility option does not include
a traffic selector sub-option, 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 "Flow identification option malformed"
in <xref target="FIDoption"/>. </t>
<t>If a flow identification mobility option includes a flow
description sub-option, but the traffic selector format
indicated by the TS Format field is not supported, 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 "Traffic Selector format
not supported" in <xref target="FIDoption"/>.</t>
<t>If the checks above pass then the flow identification
mobility option is further processed as follows.</t>
<t> If the value of the FID field in the option, is present
in the mobile nodes list of flow binding entries, the
home agent SHOULD first remove the flow binding entry
identified by the FID. The home agent SHOULD then
process this flow identification mobility option as
follows.</t>
<t>- if the Action indicates 'Discard', <list>
<t>Any binding reference sub-options that might be
present SHOULD be ignored.</t>
<t>The home agent SHOULD add a new entry in the
mobile node's list of flow binding entries, as
defined below.</t>
</list>
</t>
<t>- if the Action indicates 'Forward",<list>
<t>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
<xref target="FIDoption"/>.</t>
<t>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 <xref
target="FIDoption"/>. </t>
<t>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.</t>
</list>
</t>
<t>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:<list>
<t>the FID as a key to the entry</t>
<t>The traffic selector included in the
correspondent sub-option</t>
<t>the action indicated in the Action field</t>
<t>the BIDs, depending on action field, indicated in
the binding reference sub-option</t>
<t>the entry MUST be marked as Active, as shown in
<xref target="BCext"/>
</t>
</list>
</t>
</section>-->
<section title="Handling Flow Identification Mobility Options"
anchor="HAops-receiving2">
<t>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 <xref target="recvBID"/> of this document. </t>
<t>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.</t>
<t>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. </t>
<t>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.</t>
<t>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.</t>
<section title="Handling new FIDs" anchor="BUaddingFDs">
<t> 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. <list>
<t>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
<xref target="FIDformat"/> for "Flow identification option
malformed". </t>
<t>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 <xref
target="FIDformat"/> for "Traffic Selector format not
supported". </t>
</list>
</t>
<t>Then the home agent MUST check the Binding Reference sub-option. <list>
<t>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 <xref target="FIDoption"/>.</t>
<t>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 <xref
target="FIDoption"/>. </t>
<t>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.</t>
</list>
</t>
<t>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:<list>
<t>the FID as a key to the entry</t>
<t>The traffic selector included in the corresponding sub-option</t>
<t>the BIDs indicated in the binding reference sub-option</t>
<t>the entry MUST be marked as Active, as shown in <xref
target="BCext"/>
</t>
</list>
</t>
</section>
<section title="Handling known FIDs" anchor="HAmodifyingFDs">
<t> 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. </t>
<t>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.</t>
<t>The home agent MUST change the priority of the entry according to the
FID-PRI field of the flow identification mobility option. </t>
<t>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:<list>
<t>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,</t>
<t>otherwise the traffic selector in the entry MUST be replaced by
the traffic selector in the sub-option.</t>
</list>
</t>
<t> 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:<list>
<t>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,</t>
<t>otherwise the BIDs in the entry MUST be replaced by the BIDs in
the sub-option.</t>
</list>
</t>
</section>
</section>
<section title="Handling Flow Summary Mobility Option" anchor="HAFIDSum">
<t>When the home agent receives a binding update which includes flow summary
mobility options, it first performs the operation described so far in <xref
target="HAops"/>. </t>
<t> 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 <xref
target="FIDoption"/>. </t>
<t>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. </t>
<t>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.</t>
<t> Note that, an <xref target="RFC3775"/> 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
<xref target="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.</t>
</section>
<section title="Flow Binding Removals" anchor="HAdeletingFDs">
<t>Removal of flow bindings is performed implicitly by omission of a given FID
from a binding update.</t>
<t> 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. </t>
</section>
<section title="Sending Binding Acknowledgements" anchor="sendBA">
<t>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 <xref target="RFC3775"/>. This
status code does not give information on the success or failure of flow
bindings.</t>
<t>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 <xref target="FIDoption"
/>, otherwise it SHOULD be set to one of the rejection codes also defined in
<xref target="FIDoption"/>. <xref target="HAops-receiving2"/> identifies
a number of cases where specific error codes should be used.</t>
<!-- GT> Should sub-options be copied too? -->
<t>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 <xref
target="FIDoption"/>, or by just ignoring all the flow binding
options.</t>
<t>Note that BID options and their Status field are handled as defined in <xref
target="RFC5648"/>. 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.</t>
</section>
<section title="Packet Processing">
<t>This section defines packet processing rules according to this specification.
This specification does not change any of the packet interception rules
defined in <xref target="RFC3775"/>, and <xref target="RFC5555"/>. 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 <xref
target="RFC5555"/>. </t>
<t>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 <xref target="BCext"/>). 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. </t>
<t>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 <xref target="BCext"/>) and is
skipped. In other words packets should not be matched against that
entry.</t>
<t>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. </t>
<t>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. </t>
</section>
</section>
</section>
<section title="MTU Considerations">
<t> The options and sub-options defined in this specification add to those defined in
<xref target="RFC3775"/> 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.</t>
<t>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 <xref target="BIDUpdate"/> and identifying
new flows <xref target="FDsub"/>. Implementations are encouradged to keep binding
updates to sizes below than that of the path's MTU by making full use of BID
reference <xref target="BIDRef"/> sub-option and flow summary <xref target="FIDSum"
/> option, which allows them to refer to already registered care-of addresses and
flow bindings, while registering new ones in subsequent binding update messages.</t>
</section>
<section title="Security considerations" anchor="security">
<t>This draft introduces a new option that adds more granularity to the binding update
and acknowledgement messages defined in <xref target="RFC3775"/>, <xref
target="RFC5555"/>, and <xref target="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.</t>
<t>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.</t>
<t>Finally, when the optional anti-replay feature of Encapsulating Security Payload
(ESP) <xref target="RFC4303"/> 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 <xref target="RFC4306"/>. The receiver will process the packets from the
different SAs without prejudice.</t>
</section>
<section title="IANA Considerations">
<t>This specification requires the following IANA assignments on existing namespaces as
well as the creation of some new namespaces.</t>
<t>
<list>
<t>1) New Mobility Options <xref target="RFC3775"/>: This registry is available
from http://www.iana.org under "Mobile IPv6 parameters". The following type
numbers need to be assigned for: <list>
<t>Flow Identification Mobility Option, define in <xref
target="FIDoption"/>
</t>
<t>Flow Summary Mobility Option, defined in <xref target="FIDSum"/>
</t>
</list>
</t>
<t>2) New "Flow Identification Mobility Option Status codes" namespace needs to
be created. The following 'Status' codes are defined in this specification,
in <xref target="FIDoption"/>: <list>
<t>0 Flow binding successful</t>
<t>1-127 unassigned and available for success codes to be allocated via
Standards Action or IESG Approval as per <xref target="RFC5226"
/></t>
<t>128 Administratively prohibited</t>
<t>129 Flow binding rejected, reason unspecified</t>
<t>130 Flow identification mobility option malformed</t>
<t>131 BID not found</t>
<t>132 FID not found</t>
<t>133 Traffic selector format not supported</t>
<t>134-250 unassigned and available for reject codes to be allocated via
Standards Action or IESG Approval as per <xref target="RFC5226"/>
</t>
<t>251-255 reserved for experimental use. This small number of status
codes should be sufficient for experiments with currently unforeseen
error conditions.</t>
</list>
</t>
<t>4) New "Flow Identification Sub-Options" namespace for the Flow
Identification Mobility Option. The sub-option space is defined in <xref
target="subopt"/>. The following Sub-option Type values are defined in
this specification: <list>
<t>0 Pad</t>
<t>1 PadN</t>
<t>2 BID Reference</t>
<t>3 Traffic Selector</t>
<t>4-250 unassigned and available for allocation based on Standards
Action or IESG Approval as per <xref target="RFC5226"/>
</t>
<t>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.</t>
</list>
</t>
<t>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 <xref target="FDsubFormat"/>. The following values are defined in
this specification: <list>
<t>0 Reserved</t>
<t>1-250 unassigned and available for allocation based on Standards
Action or IESG Approval as per <xref target="RFC5226"/>
</t>
<t>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.</t>
</list>
</t>
</list>
</t>
<t>Similar to the procedures specified for Mobile IPv6 <xref target="RFC3775"/> number
spaces, future allocations from the new number spaces requires Standards Action or
IESG Approval as per <xref target="RFC5226"/>
</t>
</section>
<section title="Contributors">
<t>We would like to explicitly acknowledge the following person who co-authored one of
the documents used as source material for this document.</t>
<t>
<list>
<t>Nikolaus A. Fikouras, niko@comnets.uni-bremen.de</t>
</list>
</t>
</section>
<section title="Acknowledgements" anchor="ack">
<t>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.</t>
</section>
<!-- <section title="History">
<t>The following major changes were implemented between v01 and v02:</t>
<t>
<list>
<t>Various editorial changes, updated authors and
contributors lists, updated references etc.</t>
<t>Added section updating the BID Option defined in MCoA,
with BID-PRI feld.</t>
<t>Rearanged the fields of the FID option.</t>
<t>Added an FD sub-option to identify the type of flow
description used</t>
<t>Updated BID Reference sub-option with a 2 byte BID as per
MCoA.</t>
</list>
</t>
</section> -->
</middle>
<back>
<references title="Normative References"> &rfc2119; &rfc3775; &rfc3963; &rfc5226; &rfc5555;
&rfc5648; &ts;</references>
<references title="Informative References"> &rfc2702; &rfc3753; &rfc5380;&rfc4303; &rfc4306;
&rfc4885; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:03:53 |