One document matched: draft-ietf-mext-flow-binding-09.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-09.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="August" 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 selectors and it is assumed that one or more ways
of defining traffic selectors are going to be defined in other
specifications. This specification, however, does define the
traffic selector sub-option format to be used for any defined
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 request 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 an
action. IP packets from one or more flows that match the
traffic selector associated with the flow binding, are
processed according to the action 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 | Action | Rsvd | 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 an 8-bit
unsigned 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="Rsvd">
<vspace blankLines="1"/> This field is
unused. It MUST be set to zero by the sender
and ignored by the receiver.</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>
<t>134 Discard function not supported</t>
<t>135 Forward function 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, which may be 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"/>. When
this sub-option is included in the flow
identification mobility option it associates the
flow described 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. A node MUST NOT include more than one flow
summary mobility option in a given binding update
message. 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 can 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>Action: The action associated with a given entry as
defined by the Action field of 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 and is used to break the tie between
overlapping flows.</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> For entries that take BIDs (i.e., entries that do not
indicate a 'Discard' action), 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 if the action
parameter in an entry indicates 'Forward' then the 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 Action A/I
------- --- ---------------- ---- ------- ------
10 4 TCP 2 Forward Active
20 3 srcAddr=IPx N/A Discard Active
30 2 srcAddr=IPy 4 Forward Inactive
40 5 UDP 1,3 Forward Active
</artwork>
</figure>
<t/>
<t>According to the above list of flow binding entries, all TCP
traffic will match the first entry, and according to the
Action indicated it will be forwarded to BID2, corresponding
to a given care-of address (IP3), as shown below. Any
traffic that is not TCP, but has as source address IPx will
match the second entry, and according to the associated
Action it will be discarded. Note that any TCP traffic with
source address IPx will match the first entry and thus it
will be forwarded as per that entry. </t>
<t> The third 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 fourth rule and according to the
Action indicated, 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. The
fields of the flow identification mobility option are
necessary for ordering flow identification mobility options,
indicating the sort of action that should be undertaken to
the recipient's flow binding list of entries or for carrying
the results of such a petition. </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. Only one flow
summary mobility option can be included in a given binding
update.</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. <list>
<t>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"/>.</t>
<t>The Action field is set to one of the defined
action codes (see <xref target="FIDoption"
/>).</t>
<t>The Status field is set to zero in all
binding update messages.</t>
</list>
</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 MAY also include up to one BID
Reference sub-option (see <xref target="BIDRef"/>)
to associate the flow binding with a given set of
BIDs and corresponding CoAs. Depending on the Action
field of the flow identification mobility option,
the following rules MUST be followed with respect to
the binding reference sub-option: <list>
<t>- if the Action indicates 'Discard', the
binding reference sub-option SHOULD NOT be
included. If it is included it will be
ignored by the receiver.</t>
<t>- if the Action indicates 'Forward', a single
binding reference sub-option with one or
more BIDs MUST be included. </t>
</list>
</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 action, the priority, the BID, 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. <list>
<t>The FID-PRI and Action fields MUST be set to
the priority value for the flow binding
entry.</t>
<t>The Status field is set to zero since this
option is in a binding update.</t>
</list>
</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. If the mobile node includes a binding
reference sub-option then it should follow the rules
described in <xref target="addingFDs"/>. 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. </t>
<t>Any flow bindings (active or inactive) that are not
included 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. Remember that flow
bindings indicating a 'Discard' action do not take BIDs
and thus cannot be rendered inactive. Instead these
entries can only be removed by omitting their FID from a
subsequent BU.</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 ( <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. </t>
<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>
<t>Then the home agent MUST check the Action field in
combination with the Binding Reference sub-option if
present.</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
corresponding 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 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: <list>
<t>Change the priority of the entry according to
the FID-PRI field of the flow identification
mobility option.</t>
<t>Change the action associated with the entry
according to the Action field of the flow
identification mobility 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 traffic selector sub-option. <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>Like <xref target="BUaddingFDs"/>, if the Action
field in the flow identification mobility option is
set to 'Discard' if a binding reference sub-option
is included in the option, it SHOULD be ignored; and
any BIDs associated with the existing flow binding
entry SHOULD be removed.</t>
<t> Unlike <xref target="BUaddingFDs"/>, however, if the
Action field in the flow identification mobility
option is set to 'Forward', and since this flow
identification mobility option is designed to update
an existing entry, it may or may not include a
binding reference sub-option. <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 a flow summary mobility option, it first
performs the operation described in section 10.3.1 of
RFC3775. Binding update messages including more than one
flow summary mobility option MUST be rejected.</t>
<t> 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 the flow summary mobility option. A
binding update (with a zero lifetime) would result in
deleting all bindings, including all flow bindings
regardless of the presence of the flow summary mobility
option. A specific binding de-registration, however, as
defined in <xref target="RFC5648"/> (with lifetime of
zero and one or mobe Binding Identifier mobility options
identifying specific BIDs)does not remove all the
bindings for the MN and thus it SHOULD include a Flow
Summary Mobility Option to maintain the flow bindings
that need to be preserved.</t>
<t> If the value of any of the FID fields included in the
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>
</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"/>.</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. If the packet
matches the traffic selector, the action defined by the
action parameter of the table SHOULD be performed. <list>
<t>- if the Action indicates 'Discard', the packet
is silently discarded </t>
<t>- if the Action indicates 'Forward", 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>
</list>
</t>
<t>If the action indicated in one of the entries in the list
of flow bindings is 'Discard' then, no BIDs need to be
indicated in the same entry since the packet is not
forwarded. If, however, the action indicated in an entry
of the list of flow bindings is 'Forward", the entry
should indicate one or more valid BIDs. For 'Forward' 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 care-of address associated with the BID with the
highest 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"/> and FID Summary <xref target="FIDSum"/>
sub-options, which allows them to refer to already registered
care-of addresses and flows, 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 Action codes"
namespace needs to be created. The following 'Action'
codes are defined in this specification, in <xref
target="FIDoption"/>: <list>
<t>0 Reserved</t>
<t>1 Discard</t>
<t>2 Forward</t>
<t>3-254 unassigned and available for allocation
based on Standards Action or IESG Approval as
per <xref target="RFC5226"/>
</t>
<t>255 reserved for experimental use. A single value
should be sufficient for experimenting with a
different flow identifiction format.</t>
</list>
</t>
<t>3) 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 STD action</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 Discard function not supported</t>
<t>135 Forward function not supported</t>
<t>136-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;</references>
<references title="Informative References"> &rfc2702; &rfc3753;
&rfc5380;&rfc4303; &rfc4306; &rfc4885;
&ts;</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:17:13 |