draft-ietf-mext-flow-binding-11.txt   rfc6089.txt 
IETF MEXT Working Group G. Tsirtsis Internet Engineering Task Force (IETF) G. Tsirtsis
Internet-Draft Qualcomm Request for Comments: 6089 Qualcomm
Updates: 5648 (if approved) H. Soliman Updates: 5648 H. Soliman
Intended status: Standards Track Elevate Technologies Category: Standards Track Elevate Technologies
Expires: April 8, 2011 N. Montavont ISSN: 2070-1721 N. Montavont
IT/TB IT/TB
G. Giaretta G. Giaretta
Qualcomm Qualcomm
K. Kuladinithi K. Kuladinithi
University of Bremen University of Bremen
October 5, 2010 January 2011
Flow Bindings in Mobile IPv6 and NEMO Basic Support Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support
draft-ietf-mext-flow-binding-11.txt
Abstract Abstract
This document introduces extensions to Mobile IPv6 that allow nodes This document introduces extensions to Mobile IPv6 that allow nodes
to bind one or more flows to a care-of address. These extensions to bind one or more flows to a care-of address. These extensions
allow multihomed nodes to instruct home agents and other Mobile IPv6 allow multihomed nodes to instruct home agents and other Mobile IPv6
entities to direct inbound flows to specific addresses. entities to direct inbound flows to specific addresses.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on April 8, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6089.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 8 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 5
4.1. Definition Update for Binding Identifier Mobility 4.1. Definition Update for Binding Identifier Mobility
Option . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Option . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Flow Identification Mobility Option . . . . . . . . . . . 8 4.2. Flow Identification Mobility Option . . . . . . . . . . . 5
4.2.1. Flow Identification Sub-Options definition . . . . . . 10 4.2.1. Flow Identification Sub-Options Definition . . . . . . 7
4.2.2. Flow Summary Mobility Option . . . . . . . . . . . . . 14 4.2.2. Flow Summary Mobility Option . . . . . . . . . . . . . 11
4.3. Flow Bindings entries list and its relationship to 4.3. Flow Bindings Entries List and Its Relationship to
Binding Cache . . . . . . . . . . . . . . . . . . . . . . 15 Binding Cache . . . . . . . . . . . . . . . . . . . . . . 12
5. Protocol operations . . . . . . . . . . . . . . . . . . . . . 18 5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 14
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Preferred Care-of address . . . . . . . . . . . . . . 18 5.1.1. Preferred Care-of Address . . . . . . . . . . . . . . 15
5.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 18 5.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 15
5.2.1. Sending BU with BID Options . . . . . . . . . . . . . 19 5.2.1. Sending BU with BID Options . . . . . . . . . . . . . 15
5.2.2. Sending BU with Flow Identification Mobility 5.2.2. Sending BU with Flow Identification Mobility
Options . . . . . . . . . . . . . . . . . . . . . . . 19 Options . . . . . . . . . . . . . . . . . . . . . . . 16
5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 21 5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 17
5.2.4. Removing flow bindings . . . . . . . . . . . . . . . . 21 5.2.4. Removing Flow Bindings . . . . . . . . . . . . . . . . 18
5.2.5. Returning Home . . . . . . . . . . . . . . . . . . . . 22 5.2.5. Returning Home . . . . . . . . . . . . . . . . . . . . 18
5.2.6. Receiving Binding Acknowledgements . . . . . . . . . . 22 5.2.6. Receiving Binding Acknowledgements . . . . . . . . . . 19
5.2.7. Return Routability Procedure . . . . . . . . . . . . . 22 5.2.7. Return Routability Procedure . . . . . . . . . . . . . 19
5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 23 5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 19
5.3.1. Handling Binding Identifier Mobility Options . . . . . 23 5.3.1. Handling Binding Identifier Mobility Options . . . . . 20
5.3.2. Handling Flow Identification Mobility Options . . . . 23 5.3.2. Handling Flow Identification Mobility Options . . . . 20
5.3.3. Handling Flow Summary Mobility Option . . . . . . . . 26 5.3.3. Handling Flow Summary Mobility Option . . . . . . . . 23
5.3.4. Flow Binding Removals . . . . . . . . . . . . . . . . 27 5.3.4. Flow Binding Removals . . . . . . . . . . . . . . . . 23
5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 27 5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 24
5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 28 5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 24
6. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 30 6. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 25
7. Security considerations . . . . . . . . . . . . . . . . . . . 31 7. Security considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . . 36 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . . 36 11.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction 1. Introduction
Mobile IPv6 [RFC3775], DSMIPv6 [RFC5555] and NEMO Basic Support Mobile IPv6 [RFC3775], Dual-Stack MIPv6 (DSMIPv6) [RFC5555], and
[RFC3963] allow a mobile node / mobile router to manage its mobility Network Mobility (NEMO) Basic Support [RFC3963] allow a mobile node /
using the binding update message, which binds one care-of address to mobile router to manage its mobility using the binding update
one home address and associated mobile networks. The binding update message, which binds one care-of address to one home address and
message can be sent to the home agent. In Mobile IPv6, the binding associated mobile networks. The binding update message can be sent
update can also be sent to correspondent node or to a mobility anchor to the home agent. In Mobile IPv6, the binding update can also be
point (see [RFC5380]). The semantics of the binding update are sent to a correspondent node or to a mobility anchor point (see
limited to care-of address changes. That is, [RFC3775], [RFC5555], [RFC5380]). The semantics of the binding update are limited to
and [RFC3963] do not allow a mobile node / mobile router to bind more care-of address changes. That is, [RFC3775], [RFC5555], and
than one address to the home address. In [RFC5648] Mobile IPv6 and [RFC3963] do not allow a mobile node / mobile router to bind more
than one address to the home address. In [RFC5648], Mobile IPv6 and
NEMO Basic Support are extended to allow the binding of more than one NEMO Basic Support are extended to allow the binding of more than one
care-of address to a home address. This specification further care-of address to a home address. This specification further
extends Mobile IPv6, DSMIPv6, and NEMO Basic Support to allow it to extends Mobile IPv6, DSMIPv6, and NEMO Basic Support to allow them to
specify policies associated with each binding. A policy can contain specify policies associated with each binding. A policy can contain
a request for special treatment of a particular IPv4 or IPv6 flow, a request for special treatment of a particular IPv4 or IPv6 flow,
which is viewed as a group of packets matching a traffic selector. which is viewed as a group of packets matching a traffic selector.
Hence, this specification allows a mobile node / mobile router to Hence, this specification allows a mobile node / mobile router to
bind a particular flow to a care-of address without affecting other bind a particular flow to a care-of address without affecting other
flows using the same home address. In addition, this specification flows using the same home address. In addition, this specification
allows to bind a particular flow to a particular care-of address allows to bind a particular flow to a particular care-of address
directly with correspondent node and mobility agents (i.e., home directly with correspondent node and mobility agents (i.e., home
agents [RFC3775] and mobility anchor points [RFC5380]). agents [RFC3775] and mobility anchor points [RFC5380]).
In this document, a flow is defined as a set of IP packets matching a 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 traffic selector. A traffic selector can identify the source and
destination IP addresses, transport protocol number, the source and destination IP addresses, transport protocol number, the source and
destination port numbers and other fields in IP and higher layer destination port numbers and other fields in IP and higher-layer
headers. This specification, does not define traffic selectors, headers. This specification does not define traffic selectors, which
which are going to be defined in other specifications. This are going to be defined in other specifications. This specification,
specification, however, does define the traffic selector sub-option however, does define the traffic selector sub-option format to be
format to be used for any specific traffic selector. used for any specific traffic selector.
Using the flow identifier option introduced in this specification a Using the flow identifier option introduced in this specification, a
mobile node / mobile router can bind one or more flows to a care-of mobile node / mobile router can bind one or more flows to a care-of
address while maintaining the reception of other flows on another address while maintaining the reception of other flows on another
care-of address. The mobile node / mobile router assembles the flow care-of address. The mobile node / mobile router assembles the flow
binding requests based on local policies, link characteristics and binding requests based on local policies, link characteristics, and
the types of applications running at the time. Such policies are the types of applications running at the time. Such policies are
outside the scope of this document. outside the scope of this document.
It should be noted that the flow identification mobility option can It should be noted that the flow identification mobility option can
be associated with any binding update, whether it is sent to a be associated with any binding update, whether it is sent to a
mobility agent or a correspondent node. mobility agent or a correspondent node.
Note that per-packet load balancing may have negative impacts on TCP Note that per-packet load balancing may have negative impacts on TCP
congestion avoidance mechanisms as it is desirable to maintain order congestion avoidance mechanisms as it is desirable to maintain order
between packets belonging to the same TCP connection. This behaviour between packets belonging to the same TCP connection. This behavior
is specified in [RFC2702]. Other negative impacts are also foreseen is specified in [RFC2702]. Other negative impacts are also foreseen
for other types of real time connections due to the potential for other types of real-time connections due to the potential
variations in round trip time between packets. Moreover, per-packet variations in round-trip time between packets. Moreover, per-packet
load-balancing will negatively affect traffic with anti-replay load-balancing will negatively affect traffic with anti-replay
protection mechanisms. Hence, per-packet load balancing is not protection mechanisms. Hence, per-packet load balancing is not
envisioned in this specification. envisioned in this specification.
In the rest of the document, the term "mobile node" is used to In the rest of the document, the term "mobile node" is used to
designate either a mobile node as defined in [RFC3775] and [RFC5648], designate either a mobile node as defined in [RFC3775] and [RFC5648],
or a mobile router as defined in [RFC3963] unless stated otherwise. or a mobile router as defined in [RFC3963] unless stated otherwise.
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
Terms used in this document are defined in [RFC3753] and [RFC4885]. Terms used in this document are defined in [RFC3753] and [RFC4885].
The following terms are also used in this document: The following terms are also used in this document:
Flow: A flow is a sequence of packets for which the MN desires Flow: A flow is a sequence of packets for which the mobile node
special handling either by the Home Agent (HA), the Corresponding (MN) desires special handling either by the home agent (HA), the
Node (CN) or the (Mobility Anchor Point) MAP. corresponding node (CN) or the mobility anchor point (MAP).
Traffic Selector: One or more parameters that can be matched Traffic Selector: One or more parameters that can be matched
against fields in the packet's headers for the purpose of against fields in the packet's headers for the purpose of
classifying a packet. Examples of such parameters include the classifying a packet. Examples of such parameters include the
source and destination IP addresses, transport protocol number, source and destination IP addresses, transport protocol number,
the source and destination port numbers and other fields in IP and the source and destination port numbers, and other fields in IP
higher layer headers. and higher-layer headers.
Flow binding: It consists of a traffic selector, and one or more Flow binding: It consists of a traffic selector, and one or more
BIDs. IP packets from one or more flows that match the traffic binding identifiers (BIDs). IP packets from one or more flows
selector associated with the flow binding, are forwarded to the that match the traffic selector associated with the flow binding
BIDs associated with the same flow binding. are forwarded to the BIDs associated with the same flow binding.
Flow Identifier: A flow identifier uniquely identifies a flow Flow Identifier: A flow identifier uniquely identifies a flow
binding associated with a mobile node. It is generated by a binding associated with a mobile node. It is generated by a
mobile node and is cached in the table of flow binding entries mobile node and is cached in the table of flow binding entries
maintained by the MN, HA, CN or MAP. maintained by the MN, HA, CN, or MAP.
4. Mobile IPv6 Extensions 4. Mobile IPv6 Extensions
This section introduces extensions to Mobile IPv6 that are necessary This section introduces extensions to Mobile IPv6 that are necessary
for supporting the flow binding mechanism described in this document. for supporting the flow binding mechanism described in this document.
4.1. Definition Update for Binding Identifier Mobility Option 4.1. Definition Update for Binding Identifier Mobility Option
This specification updates the definition of the Binding Identifier This specification updates the definition of the Binding Identifier
Mobility option defined in [RFC5648], as follows: Mobility option defined in [RFC5648], as follows:
1 2 3 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 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 | | Type = 35 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID (BID) | Status |H| BID-PRI | | Binding ID (BID) | Status |H| BID-PRI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ + + +
: IPv4 or IPv6 care-of address (CoA) : : IPv4 or IPv6 Care-of Address (CoA) :
+ + + +
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 1: The Binding Identifier Mobility option Figure 1: The Binding Identifier Mobility Option
BID-PRI BID-PRI
This is a 7-bit unsigned integer placing each BID to a relative This is a 7-bit unsigned integer placing each BID to a relative
priority with other registered BIDs. Value '0' is reserved and priority (PRI) with other registered BIDs. Value '0' is
MUST NOT be used. A lower number in this field indicates a reserved and MUST NOT be used. A lower number in this field
higher priority, while BIDs with the same BID-PRI value have indicates a higher priority, while BIDs with the same BID-PRI
equal priority meaning that, the BID used is an implementation value have equal priority meaning that, the BID used is an
issue. This is consistent with current practice in packet implementation issue. This is consistent with current practice
classifiers. in packet classifiers.
4.2. Flow Identification Mobility Option 4.2. Flow Identification Mobility Option
The flow identification mobility option is a new mobility option The flow identification mobility option is a new mobility option
[RFC3775] and it is included in the binding update and [RFC3775], and it is included in the binding update and
acknowledgement messages. This option contains information that acknowledgement messages. This option contains information that
allows the receiver of a binding update to install policies on a allows the receiver of a binding update to install policies on a
traffic flow and route it to a given care-of address. Multiple traffic flow and route it to a given care-of address. Multiple
options may exist within the same binding update message. The options may exist within the same binding update message. The
alignment requirement for this option is 2n. alignment requirement for this option is 2n.
0 1 2 3 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 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 | | Option Type | Option Len | FID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID-PRI | Reserved | Status | | FID-PRI | Reserved | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-options (optional) ... | Sub-options (optional) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Flow Identification Mobility Option Figure 2: The Flow Identification Mobility Option
Option Type Option Type
To be assigned by IANA 45
Option Len Option Len
Length of the option in octets as per [RFC3775]. Length of the option in octets as per [RFC3775].
FID FID
The Flow Identifier field is a 16-bit unsigned integer that The Flow Identifier field is a 16-bit unsigned integer that
includes the unique identifier for the flow binding. This includes the unique identifier for the flow binding. This
field is used to refer to an existing flow binding or to create field is used to refer to an existing flow binding or to create
skipping to change at page 10, line 7 skipping to change at page 7, line 5
Status Status
This 8-bit unsigned integer field indicates the success or This 8-bit unsigned integer field indicates the success or
failure of the flow binding operation for the particular flow failure of the flow binding operation for the particular flow
in the option. This field is not relevant to the binding in the option. This field is not relevant to the binding
update message as a whole or to other flow identification update message as a whole or to other flow identification
options. This field is only relevant when included in the options. This field is only relevant when included in the
Binding Acknowledgement message and must be ignored in the Binding Acknowledgement message and must be ignored in the
binding update message. The following values are reserved for binding update message. The following values are reserved for
the status field within the flow identification mobility the Status field within the flow identification mobility
option: option:
0 Flow binding successful 0 Flow binding successful
128 Administratively prohibited 128 Administratively prohibited
129 Flow binding rejected, reason unspecified 129 Flow binding rejected, reason unspecified
130 Flow identification mobility option malformed 130 Flow identification mobility option malformed
131 BID not found 131 BID not found
132 FID not found 132 FID not found
133 Traffic selector format not supported 133 Traffic selector format not supported
Sub-options (optional) Sub-options (optional)
zero or more sub-options, defined in Section 4.2.1 Zero or more sub-options, defined in Section 4.2.1.
4.2.1. Flow Identification Sub-Options definition 4.2.1. Flow Identification Sub-Options Definition
Flow identification sub-options are encoded within the remaining Flow identification sub-options are encoded within the remaining
space of the flow identification mobility option, using a sub-option space of the flow identification mobility option, using a sub-option
type-length-value (TLV) format as follows: type-length-value (TLV) format as follows:
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Opt Type |Sub-Opt Length | Sub-Option Data... | Sub-Opt Type |Sub-Opt Length | Sub-Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flow Identification Sub-Option format Figure 3: Flow Identification Sub-Option Format
Sub-opt Type Sub-Opt Type
8-bit unsigned integer indicating the sub-option Type. When 8-bit unsigned integer indicating the sub-option Type. When
processing a flow identification mobility option containing an processing a flow identification mobility option containing an
option for which the sub-option Type value is not recognized by option for which the sub-option Type value is not recognized by
the receiver, the receiver MUST silently ignore and skip over the receiver, the receiver MUST silently ignore and skip over
the sub-option, correctly handling any remaining sub-options in the sub-option, correctly handling any remaining sub-options in
the same option. the same option.
Sub-opt Len Sub-Opt Len
8-bit unsigned integer, representing the length in octets of 8-bit unsigned integer, representing the length in octets of
the flow identification sub-option. This field indicates the the flow identification sub-option. This field indicates the
length of the sub-option not including the Sub-opt Type and length of the sub-option not including the Sub-Opt Type and
Sub-opt Length fields. Note that Sub-opt Type '0' Sub-Opt Length fields. Note that Sub-Opt Type '0'
(Section 4.2.1.1) is a special case that does not take a Sub- (Section 4.2.1.1) is a special case that does not take a Sub-
opt Length field. Opt Length field.
Sub-Option Data Sub-Option Data
A variable length field that contains data specific to the sub- A variable length field that contains data specific to the sub-
option option.
The following subsections specify the sub-option types which are The following subsections specify the sub-option Types that are
currently defined for use in the flow identification option. currently defined for use in the flow identification option.
Implementations MUST silently ignore any sub-options that they do not Implementations MUST silently ignore any sub-options that they do not
understand. understand.
These sub-options may have alignment requirements. Following the These sub-options may have alignment requirements. Following the
convention in [RFC3775], regarding mobility options, these sub- convention in [RFC3775], regarding mobility options, these sub-
options are aligned in a packet so that multi-octet values within the 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 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 (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) . n octets from the start of the header, for n = 1, 2, 4, or 8).
4.2.1.1. Pad1 4.2.1.1. Pad1
The Pad1 sub-option does not have any alignment requirements. Its The Pad1 sub-option does not have any alignment requirements. Its
format is as follows: format is as follows:
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Sub-Opt Type | | Sub-Opt Type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Sub-opt Type Sub-Opt Type
0 0
NOTE! the format of the Pad1 sub-option is a special case - it has NOTE: The format of the Pad1 sub-option is a special case -- it has
neither sub-option Length nor sub-option Data fields. neither sub-option Length nor sub-option Data fields.
The Pad1 sub-option is used to insert one octet of padding in the 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 flow identification option. If more than one octet of padding is
required, the PadN sub-option, described next, should be used rather required, the PadN sub-option, described next, should be used rather
than multiple Pad1 sub-options. than multiple Pad1 sub-options.
4.2.1.2. PadN 4.2.1.2. PadN
The PadN sub-option does not have any alignment requirements. Its The PadN sub-option does not have any alignment requirements. Its
format is as follows: format is as follows:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Sub-Opt Type | Sub-Opt Len | Option Data | Sub-Opt Type | Sub-Opt Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Sub-opt Type Sub-Opt Type
1 1
Sub-opt Len Sub-Opt Len
set to the length of the sub-option Set to the length of the sub-option.
Sub-opt Data Sub-Opt Data
0 or more bytes set to 0 by the sender and ignored by the 0 or more bytes set to 0 by the sender and ignored by the
receiver. receiver.
The PadN sub-option is used to insert two or more octets of padding 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, in the flow identification mobility option. For N octets of padding,
the sub-option Length field contains the value N, and the sub-option 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 Data field consists of N-2 zero-valued octets. PadN sub-option Data
be ignored by the receiver. MUST be ignored by the receiver.
4.2.1.3. Binding Reference Sub-option 4.2.1.3. Binding Reference Sub-Option
This section introduces the binding reference sub-option, included in This section introduces the binding reference sub-option, included in
the flow identification mobility option. A node MUST NOT include the flow identification mobility option. A node MUST NOT include
more than one binding reference sub-options in a given flow binding more than one binding reference sub-options in a given flow binding
identification option. The binding reference sub-option includes one identification option. The binding reference sub-option includes one
or more BIDs defined in MCoA [RFC5648]. This sub-option associates or more BIDs defined in Multiple Care-of Addresses (MCoA) [RFC5648].
the flow described in a a flow identification mobility option with This sub-option associates the flow described in a flow
one or more registered BIDs. identification mobility option with one or more registered BIDs.
When binding a flow using this sub-option, the binding identifier When binding a flow using this sub-option, the binding identifier
mobility option, defined in [RFC5648], MUST be included in either the mobility option, defined in [RFC5648], MUST be included in either the
same or an earlier Binding Update (BU). The binding reference sub- same or an earlier binding update (BU). The binding reference sub-
option is shown below. The alignment requirement for this sub-option option is shown below. The alignment requirement for this sub-option
is 2n. is 2n.
0 1 2 3 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 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 | |Sub-Opt Type | Sub-Opt Len | BID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BID ........ | BID ........
+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-
Figure 4: The Binding Reference sub-option Figure 4: The Binding Reference Sub-Option
Sub-opt Type Sub-Opt Type
2 2
Sub-opt Len Sub-Opt Len
Variable Variable
BID BID
A 16-bit unsigned integer indicating the BID that the mobile A 16-bit unsigned integer indicating the BID that the mobile
node wants to associate with the flow identification option. node wants to associate with the flow identification option.
One or more BID fields can be included in this sub-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 Since each BID is 2 bytes long, the value of the Sub-opt Len
field indicates the number of BIDs present. Number of BIDs = field indicates the number of BIDs present. Number of BIDs =
Sub-opt Len/2. Sub-Opt Len/2.
4.2.1.4. Traffic Selector sub-option 4.2.1.4. Traffic Selector Sub-Option
The traffic selector sub-option includes the parameters used to match The traffic selector sub-option includes the parameters used to match
packets for a specific flow binding. A node MUST NOT include more packets for a specific flow binding. A node MUST NOT include more
than one traffic selector sub-option in a given flow binding than one traffic selector sub-option in a given flow binding
identification option. identification option.
0 1 2 3 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 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 | |Sub-Opt Type | Sub-Opt Len | TS Format | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Selector ... | Traffic Selector ...
+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Traffic Selector sub-option Figure 5: The Traffic Selector Sub-Option
Sub-opt Type Sub-Opt Type
3 3
Sub-opt Len Sub-Opt Len
variable Variable
TS Format TS Format
An 8-bit unsigned integer indicating the Traffic Selector Format. An 8-bit unsigned integer indicating the Traffic Selector Format.
Value "0" is reserved and MUST NOT be used. Value "0" is reserved and MUST NOT be used.
Reserved Reserved
An 8-bit reserved field. It MUST be set to zero by the sender and An 8-bit reserved field. It MUST be set to zero by the sender and
ignored by the receiver. ignored by the receiver.
Traffic Selector Traffic Selector
A variable length field, the format and content of which is out of A variable-length field, the format and content of which is out of
scope for this specification. The traffic selector defined in scope for this specification. The traffic selector defined in
[I-D.ietf-mext-binary-ts] is mandatory to implement. [RFC6088] is mandatory to implement.
4.2.2. Flow Summary Mobility Option 4.2.2. Flow Summary Mobility Option
The flow summary mobility option is a new mobility option [RFC3775], The flow summary mobility option is a new mobility option [RFC3775],
which includes one or more flow identifiers (FIDs) for the purpose of which includes one or more flow identifiers (FIDs) for the purpose of
refreshing their state. The alignment requirement for this option is refreshing their state. The alignment requirement for this option is
2n. 2n.
0 1 2 3 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 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 | | Option Type | Option Len | FID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID ........ | FID ........
+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-
Figure 6: The Flow Summary Mobility Option Figure 6: The Flow Summary Mobility Option
Option Type Option Type
To be assigned by IANA 44
Option Length Option Length
Length of the option in octets as per [RFC3775] Length of the option in octets as per [RFC3775].
FID FID
A 16-bit unsigned integer indicating a registered FID. One or A 16-bit unsigned integer indicating a registered FID. One or
more FID fields can be included in this option. Number of FIDs more FID fields can be included in this option. Number of FIDs
= Option Len/2 = Option Len/2.
4.3. Flow Bindings entries list and its relationship to Binding Cache 4.3. Flow Bindings Entries List and Its Relationship to Binding Cache
The conceptual mobile IPv6 binding cache was defined in [RFC3775] to The conceptual Mobile IPv6 binding cache was defined in [RFC3775] to
identify the mobile IP state maintained by the mobile node, mobility identify the mobile IP state maintained by the mobile node, mobility
agent, and correspondent node. The binding cache includes, between agent, and correspondent node. The binding cache includes, among
others, the mobile node's home address, the registered care-of others, the mobile node's home address, the registered care-of
address, and the lifetime of the binding. The binding cache has been address, and the lifetime of the binding. The binding cache has been
extended by [RFC5648] to include more than one care-of addresses and extended by [RFC5648] to include more than one care-of addresses and
to associate each of them with a Binding Identifier (BID). to associate each of them with a binding identifier (BID).
This specification does not modify the mobile IPv6 binding cache any This specification does not modify the Mobile IPv6 binding cache any
further. further.
Flow bindings can be thought of as a conceptual list of entries that Flow bindings can be thought of as a conceptual list of entries that
is separate from the binding cache. The flow bindings list contains is separate from the binding cache. The flow bindings list contains
an entry for each of the registered flow bindings. Flow binding 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. entries point to an entry in the binding cache by means of the BID.
Each flow binding entry includes the following parameters: Each flow binding entry includes the following parameters:
o FID (Flow Identifier): For a given mobile node, identified by its o FID (Flow Identifier): For a given mobile node, identified by its
primary home address, the FID MUST uniquely identify an entry, primary home address, the FID MUST uniquely identify an entry,
i.e. a unique flow binding. Each mobile node can only have a 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 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 FID number space is used for all the addresses associated to a
given MN by the HA (e.g., via [RFC3963]). Different mobile nodes given MN by the HA (e.g., via [RFC3963]). Different mobile nodes
use the same FID number space. use the same FID number space.
o A Traffic Selector: Included in a traffic selector sub-option. o A Traffic Selector: Included in a traffic selector sub-option.
o BID(s): The list of BIDs associated with the entry as defined by o BID(s): The list of BIDs associated with the entry as defined by
the binding reference sub-option included in the FID option that the binding reference sub-option included in the FID option that
created it. created it.
skipping to change at page 16, line 18 skipping to change at page 13, line 18
to the FID-PRI field as defined in the FID option that created each to the FID-PRI field as defined in the FID option that created each
entry. entry.
A valid BID is required to make the entry 'Active'. If all of the A valid BID is required to make the entry 'Active'. If all of the
BIDs pointed to by a given entry are deregistered [RFC5648], the flow BIDs pointed to by a given entry are deregistered [RFC5648], the flow
binding entry becomes 'Inactive', in other words it does not affect binding entry becomes 'Inactive', in other words it does not affect
data traffic. Note that an entry becomes 'Inactive' only if all of 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 BIDs are deregistered. If only some of the BIDs are still valid,
the invalid BIDs are simply ignored. the invalid BIDs are simply ignored.
Also note that the state described in this section is maintained by Also, note that the state described in this section is maintained by
the mobile node as well as in mobility agents and correspondent 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 nodes. As such, the mobile node is fully aware of which BIDs are
BIDs at any time and which flow binding entries are active/inactive. valid at any time and which flow binding entries are active/inactive.
Section 5 defines how these flow binding entries are manipulated by Section 5 defines how these flow binding entries are manipulated by
the mobile node in detail. the mobile node in detail.
As an example the following represents an ordered flow binding entry As an example, the following represents an ordered flow binding entry
table for a mobile node that has registered multiple care-of table for a mobile node that has registered multiple care-of
addresses and flow bindings. addresses and flow bindings.
FID-PRI FID Traffic Selector BIDs A/I FID-PRI FID Traffic Selector BIDs A/I
------- --- ---------------- ---- ------- ------- --- ---------------- ---- -------
10 4 TCP 2 Active 10 4 TCP 2 Active
30 2 srcAddr=IPy 4 Inactive 30 2 srcAddr=IPy 4 Inactive
40 5 UDP 1,3 Active 40 5 UDP 1,3 Active
Ordered Flow Binding Entries Ordered Flow Binding Entries
According to the above list of flow binding entries, all TCP traffic According to the above list of flow binding entries, all TCP traffic
will match the first entry, and will be forwarded to BID2, will match the first entry, and will be forwarded to BID2,
corresponding to a given care-of address (IP3), as shown below. corresponding to a given care-of address (IP3), as shown below.
The second entry is marked as Inactive since the BID 4 does not exist The second entry is marked as 'Inactive' since the BID 4 does not
in the ordered list of BID entries below. Inactive entries do not exist in the ordered list of BID entries below. Inactive entries do
affect traffic, i.e., packets are not matched against them. not affect traffic, i.e., packets are not matched against them.
Any UDP traffic that does not match any of the earlier entries will 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 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 forwarded to BIDs 1 and 3, corresponding to care-of addresses IP1 and
IP2 shown below. IP2 shown below.
Finally any remaining packets that do not match any of the entries Finally, any remaining packets that do not match any of the entries
above will be simply forwarded to the care-of address indicated by above will be simply forwarded to the care-of address indicated by
the highest order BID in the table below. In the example, such the highest order BID in the table below. In the example, such
packets will be forwarded to BID1 corresponding to care-of address packets will be forwarded to BID1 corresponding to care-of address
IP1. IP1.
BID-PRI BID CoA BID-PRI BID CoA
--------- --- --- --------- --- ---
20 1 IP1 20 1 IP1
30 3 IP2 30 3 IP2
30 2 IP3 30 2 IP3
Ordered BID Entries Ordered BID Entries
Mobility agent and corresponding node implementations should take Mobility agent and corresponding node implementations should take
care to avoid flow binding rules affecting the fundamental operation care to avoid flow binding rules affecting the fundamental operation
of Mobile IPv6 and its extensions. In particular, flow binding rules of Mobile IPv6 and its extensions. In particular, flow binding rules
MUST NOT apply to Mobile IPv6 signaling generated by mobility agents MUST NOT apply to Mobile IPv6 signaling generated by mobility agents
and corresponding nodes communicating with a given mobile node, since and corresponding nodes communicating with a given mobile node, since
that could adversely affect the operation of the protocol. Other, that could adversely affect the operation of the protocol. Other,
non Mobile IPv6 traffic generated by these entities SHOULD be matched non-MIPv6 traffic generated by these entities SHOULD be matched
against the mobile node's flow binding rules as normal. against the mobile node's flow binding rules as normal.
5. Protocol operations 5. Protocol Operations
5.1. General 5.1. General
This specification introduces a flow bindings list of entries and an This specification introduces a flow bindings list of entries and an
ordered list of flow binding identifiers, allowing mobile nodes to ordered list of flow binding identifiers, allowing mobile nodes to
associate flow binding policies with the registered care-of associate flow binding policies with the registered care-of
addresses. addresses.
The flow identification mobility option defines how the mobile node The flow identification mobility option defines how the mobile node
can control a set of flow binding entries maintained in a mobility can control a set of flow binding entries maintained in a mobility
skipping to change at page 18, line 28 skipping to change at page 15, line 5
This specification allows mobile nodes to direct flows to a This specification allows mobile nodes to direct flows to a
particular care-of address. The granularity of what constitutes a particular care-of address. The granularity of what constitutes a
flow depends on the traffic selector used. flow depends on the traffic selector used.
The remainder of this section discusses how mobile nodes can use the The remainder of this section discusses how mobile nodes can use the
options and sub-options defined in this document when sending binding options and sub-options defined in this document when sending binding
updates to the correspondent node, home agent, or mobility anchor updates to the correspondent node, home agent, or mobility anchor
point. In addition, refresh, deletion, and modification of flow point. In addition, refresh, deletion, and modification of flow
binding entries are all discussed below. binding entries are all discussed below.
5.1.1. Preferred Care-of address 5.1.1. Preferred Care-of Address
Any node that supports this specification MUST maintain an ordered Any node that supports this specification MUST maintain an ordered
list of care-of addresses for each mobile node it maintains a list of list of care-of addresses for each mobile node for which it maintains
flow bindings for. The ordered list of care-of addresses is built a list of flow bindings. The ordered list of care-of addresses is
based on the BID-PRI field of the binding identifier mobility option built based on the BID-PRI field of the binding identifier mobility
(see Section 4.1). option (see Section 4.1).
The ordered list of BIDs is used to determine how to forward a packet 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 to a given mobile node when the packet does not match any of the flow
binding entries defined in Section 4.3. A packet that does not match binding entries defined in Section 4.3. A packet that does not match
any of the flow binding entries SHOULD be forwarded to the care-of 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 address identified by the BID with the highest priority, i.e., lowest
BID-PRI value. BID-PRI value.
5.2. Mobile Node Considerations 5.2. Mobile Node Considerations
This specification allows the mobile node to maintain several This specification allows the mobile node to maintain several
bindings with its mobility agent, and correspondent nodes and to bindings with its mobility agent and correspondent nodes, and it
direct packets to different care-of addresses according to flow allows it to direct packets to different care-of addresses according
bindings. This section details the mobile node operations necessary to flow bindings.
to implement this specification.
The mobility agent and correspondent node list of flow bindings is The mobility agent and correspondent node list of flow bindings is
manipulated by the mobile node, via flow identification and flow manipulated by the mobile node, via flow identification and flow
summary mobility options included in binding update messages. Each summary mobility options included in binding update messages. Each
flow binding update can add, modify, refresh, or delete a given flow binding update can add, modify, refresh, or delete a given
binding. More than one flow identification mobility options MAY be binding. More than one flow identification mobility option MAY be
included in the same binding update but each of them MUST include a included in the same binding update, but each of them MUST include a
different FID. In other words, two flow identification options in different FID. In other words, two flow identification options in
the same message can not be about the same flow binding. the same message cannot be about the same flow binding.
All flow binding state MUST be refreshed in every binding update the All flow binding state MUST be refreshed in every binding update the
mobile node sends. Any previously registered flow binding that is mobile node sends. Any previously registered flow binding that is
not included in a given binding update will be deleted. So, any flow not included in a given binding update will be deleted. So, any flow
bindings that are not added or modified by a flow identification bindings that are not added or modified by a flow identification
mobility option, but have previously registered and need to be mobility option, but have previously registered and need to be
maintained MUST be included in a flow summary mobility option. maintained, MUST be included in a flow summary mobility option.
5.2.1. Sending BU with BID Options 5.2.1. Sending BU with BID Options
This specification (see Section 4.1) updates the definition of the This specification (see Section 4.1) updates the definition of the
binding identifier mobility option, originally defined in [RFC5648]. binding identifier mobility option, originally defined in [RFC5648].
According to this specification the BID option includes a BID-PRI According to this specification, the BID option includes a BID-PRI
field assigning each registered care-of address a priority, and thus field assigning each registered care-of address a priority, and thus
placing them in an ordered list as also described in Section 4.3. places them in an ordered list, as also described in Section 4.3.
To ensure backwards compatibility with [RFC5648], for the purpose of
this specification, the field BID-PRI MUST NOT be set to zero.
To ensure backwards compatibility with [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 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 field of value zero as an indication that this is a BID option of the
format defined in [RFC5648]. format defined in [RFC5648].
Mobile nodes supporting this specification MUST use the BID option Mobile nodes supporting this specification MUST use the BID option
format defined in Section 4.1. Mobile nodes MUST also register all format defined in Section 4.1. Mobile nodes MUST also register all
care-of addresses using the updated BID option format, either in the care-of addresses using the updated BID option format, either in the
same BU as any flow identification mobility options using them, or in same BU as any flow identification mobility options using them or in
earlier BUs. earlier BUs.
5.2.2. Sending BU with Flow Identification Mobility Options 5.2.2. Sending BU with Flow Identification Mobility Options
5.2.2.1. New Flow Bindings 5.2.2.1. New Flow Bindings
When adding a new flow binding, a mobile node sends the flow When adding a new flow binding, a mobile node sends the flow
identification mobility option in the binding update, with the FID 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 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) binding entries maintained by the receiver. The care-of address(es)
associated with each flow identification mobility options in the associated with each flow identification mobility option in the
binding update, must be logically registered by this binding update, binding update must be logically registered by this binding update,
or must have already been registered by the receiver of the binding or must have already been registered by the receiver of the binding
update in an earlier binding update, as defined in Section 5.2.1. update in an earlier binding update, as defined in Section 5.2.1.
The flow identification mobility option MUST include a unique flow The flow identification mobility option MUST include a unique flow
identifier in the FID field. The FID needs only be unique for the identifier in the FID field. The FID need only be unique for the
receiver of the binding update and for the same sender, i.e. the same receiver of the binding update and for the same sender, i.e., the
FID can be used across different receivers of the binding update, for same FID can be used across different receivers of the binding
the same sender. The FID-PRI field is set to the desired unique update, for the same sender. The FID-PRI field is set to the desired
priority of the FID, defining the order of the flow binding to be unique priority of the FID, defining the order of the flow binding to
added in the list of flow binding entries as defined in Section 4.3. be added in the list of flow binding entries, as defined in
The Status field is set to zero in all binding update messages. Section 4.3. The Status field is set to zero in all binding update
messages.
Since this flow identification mobility option is requesting the Since this flow identification mobility option is requesting the
addition of a new flow binding in the list of flow bindings addition of a new flow binding in the list of flow bindings
maintained by the receiver, the mobile node MUST include exactly one maintained by the receiver, the mobile node MUST include exactly one
Traffic Selector sub-option (see Section 4.2.1.4) describing the flow traffic selector sub-option (see Section 4.2.1.4) describing the flow
associated with the new flow binding. The TS Format field of the 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 traffic selector sub-option MUST be set to the non-zero value of the
format used by the mobile node. format used by the mobile node.
The mobile node MUST also include exactly one BID Reference sub- The mobile node MUST also include exactly one BID reference sub-
option (see Section 4.2.1.3) to associate the flow binding with a option (see Section 4.2.1.3) to associate the flow binding with a
given set of BIDs and corresponding CoAs. given set of BIDs and corresponding CoAs.
5.2.2.2. Updating Flow Bindings 5.2.2.2. Updating Flow Bindings
Flow binding modification is essentially a process where parameters Flow binding modification is essentially a process where parameters
associated with an existing flow binding in the list of flow binding associated with an existing flow binding in the list of flow binding
entries is replaced by parameters included in the flow identification entries are replaced by parameters included in the flow
mobility option, and the same FID is maintained. With this procedure identification mobility option, and the same FID is maintained. With
the mobile node can change the priority, the BID(s), and/or the this procedure, the mobile node can change the priority, the BID(s),
traffic selector associated with a flow binding. and/or the traffic selector associated with a flow binding.
To modify an existing flow binding the mobile node MUST send a To modify an existing flow binding, the mobile node MUST send a
binding update with a flow identification option, with the FID field 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 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 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 flow binding entry. The Status field is set to zero since this
option is in a binding update. option is in a binding update.
The mobile node MAY include exactly one traffic selector sub-option The mobile node MAY include exactly one traffic selector sub-option
(see Section 4.2.1.4) describing the updated flow to be associated (see Section 4.2.1.4) describing the updated flow to be associated
with the flow binding. The mobile node MAY, however, omit the with the flow binding. The mobile node MAY, however, omit the
traffic selector sub-option if it wants the traffic selector traffic selector sub-option if it wants the traffic selector
skipping to change at page 21, line 12 skipping to change at page 17, line 41
option if it wants the BIDs currently associated with the flow option if it wants the BIDs currently associated with the flow
binding entry identified by the FID field to be maintained. binding entry identified by the FID field to be maintained.
Note that it is also possible for the mobile node to effectively Note that it is also possible for the mobile node to effectively
modify the effect of a flow binding entry without actually changing modify the effect of a flow binding entry without actually changing
the entry itself. This can be done by changing the CoA associated the entry itself. This can be done by changing the CoA associated
with a given BID, which is a process defined in detail in [RFC5648]. with a given BID, which is a process defined in detail in [RFC5648].
5.2.3. Sending BU with a Flow Summary Option 5.2.3. Sending BU with a Flow Summary Option
When the mobile node sends a binding update it MUST refresh all flow 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 bindings it wants to maintain even if it does not want to change any
of their parameters. of their parameters.
To refresh an existing flow binding the mobile node MUST send a To refresh an existing flow binding, the mobile node MUST send a
binding update with a flow summary option. The flow summary option binding update with a flow summary option. The flow summary option
MUST include one or more FID fields as indicated in Section 4.2.2. MUST include one or more FID fields, as indicated in Section 4.2.2.
Each FID field included MUST be set to one of the FID values already 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 in the list of flow binding entries. Each flow summary mobility
options can identify up to 127 FIDs, so more than one such options option can identify up to 127 FIDs, so more than one such option can
can be included in a binding update message as required. A given FID 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 SHOULD NOT be included more than once in all of the flow summary
mobility options included a given binding update message. mobility options included in a given binding update message.
Any flow bindings (active or inactive) that are not identified in a Any flow bindings (active or inactive) that are not identified in a
binding update will be removed from the list of flow binding entries. binding update will be removed from the list of flow binding entries.
Note that any inactive flow bindings, i.e., flow bindings without Note that any inactive flow bindings, i.e., flow bindings without
associated BIDs that are marked as Inactive in the list of flow associated BIDs that are marked as 'Inactive' in the list of flow
binding entries (see Section 4.3), MUST also be refreshed, or binding entries (see Section 4.3), MUST also be refreshed, or
modified, to be maintained. If they are not included in a BU they modified, to be maintained. If they are not included in a BU
will be removed. message, they will be removed.
5.2.4. Removing flow bindings 5.2.4. Removing Flow Bindings
Removal of flow binding entries is performed implicitly by omission Removal of flow binding entries is performed implicitly by omission
of a given FID from a binding update. of a given FID from a binding update.
To remove a flow binding the MN simply sends a binding update that To remove a flow binding, the MN simply sends a binding update
includes flow identification and flow summary mobility options for message that includes flow identification and flow summary mobility
all the FIDs that need to be refreshed, modified, or added, and options for all the FIDs that need to be refreshed, modified, or
simply omits any FIDs that need to be removed. added, and simply omits any FIDs that need to be removed.
Note that a mobile node can also render a flow binding inactive by Note that a mobile node can also render a flow binding inactive by
removing the BIDs associated with it, without removing the flow removing the BIDs associated with it, without removing the flow
binding itself. The procedure for removing a BID is defined in binding itself. The procedure for removing a BID is defined in
detail in [RFC5648]. detail in [RFC5648].
When all the BIDs associated with a flow binding are removed, the 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 flow binding MUST be marked as 'Inactive' in the list of flow binding
entries as shown in Section 4.3. In other words the state associated entries, as shown in Section 4.3. In other words, the state
with the flow binding MUST be maintained but it does no longer affect associated with the flow binding MUST be maintained, but it no longer
the mobile node's traffic. The MN can return an inactive flow affects the mobile node's traffic. The MN can return an inactive
binding to the active state by using the flow binding modification flow binding to the active state by using the flow binding
process described in Section 5.2.2.2, to associate it again with one modification process, described in Section 5.2.2.2, to associate it
or more valid BIDs. again with one or more valid BIDs.
5.2.5. Returning Home 5.2.5. Returning Home
This specification is compatible to the home registration procedures This specification is compatible with the home registration
defined in [RFC3775] and [RFC5648]. More specifically, if the mobile procedures defined in [RFC3775] and [RFC5648]. More specifically, if
node performs an [RFC3775] style deregistration, all of its bindings, the mobile node performs a deregistration in the [RFC3775] style, all
including flow bindings are deleted. If the mobile node, however, of its bindings, including flow bindings are deleted. If the mobile
performs an [RFC5648] style home registration, then the home link is node, however, performs a home registration in the [RFC5648] style,
associated with a specific BID and so, as far as this specification then the home link is associated with a specific BID and so, as far
is concerned, it is treated as any other link associated with a given as this specification is concerned, it is treated as any other link
BID. associated with a given BID.
5.2.6. Receiving Binding Acknowledgements 5.2.6. Receiving Binding Acknowledgements
According to [RFC3775] all nodes are required to silently ignore According to [RFC3775], all nodes are required to silently ignore
mobility options not understood while processing binding updates. As mobility options not understood while processing binding updates. As
such, a mobile node receiving a Binding Acknowledgement in response such, a mobile node receiving a Binding Acknowledgement message in
to the transmission of a binding update MUST determine if the Binding response to the transmission of a binding update message MUST
Acknowledgement contains a copy of every flow identification mobility determine if the Binding Acknowledgement message contains a copy of
options included in the binding update. A Binding Acknowledgement every flow identification mobility options included in the binding
without flow identification option(s), in response to a Binding update. A Binding Acknowledgement without flow identification
Update with flow identification mobility option, would indicate option(s), in response to a binding update with flow identification
inability (or unwillingness) on behalf of the source node to support mobility option, would indicate the inability (or unwillingness) on
the extensions presented in this document. behalf of the source node to support the extensions presented in this
document.
If a received Binding Acknowledgement contains a copy of each flow If a received Binding Acknowledgement contains a copy of each flow
identification mobility option that was sent within the binding identification mobility option that was sent within the binding
update, the status field of each flow identification option indicates update, the Status field of each flow identification option indicates
the status of the flow binding on the distant node. the status of the flow binding on the distant node.
5.2.7. Return Routability Procedure 5.2.7. Return Routability Procedure
A mobile node may perform route optimization with correspondent nodes A mobile node may perform route optimization with correspondent
as defined in [RFC3775]. Route optimization allows a mobile node to nodes, as defined in [RFC3775]. Route optimization allows a mobile
bind a care-of address to a home address in order to allow the node to bind a care-of address to a home address in order to allow
correspondent node to direct the traffic to the current location of the correspondent node to direct the traffic to the current location
the mobile node. Before sending a Binding Update to correspondent of the mobile node. Before sending a binding update to correspondent
node, the Return Routability Procedure needs to be performed between node, the Return Routability Procedure needs to be performed between
the mobile node and the correspondent node. This procedure is not the mobile node and the correspondent node. This procedure is not
affected by the extensions defined in this document. affected by the extensions defined in this document.
5.3. HA, MAP, and CN Considerations 5.3. HA, MAP, and CN Considerations
This specification allows the mobility agents (Home Agents and This specification allows the mobility agents (home agents and
Mobility Anchor Points), and correspondent nodes to maintain several mobility anchor points), and correspondent nodes to maintain several
flow bindings for a given home address and to direct packets to flow bindings for a given home address and to direct packets to
different care-of addresses according to flow bindings. This section different care-of addresses according to flow bindings. This section
details the home agent operations necessary to implement this details the home agent operations necessary to implement this
specification. These operations are identical for MAPs and CNs specification. These operations are identical for MAPs and CNs,
unless otherwise stated. unless otherwise stated.
Note that route optimization is only defined for mobile nodes (MIPv6 Note that route optimization is only defined for mobile nodes (MIPv6
[RFC3775]), and not mobile routers (NEMOv6 [RFC3963]). Thus, these [RFC3775]) and not mobile routers (NEMOv6 [RFC3963]). Thus, these
sections only apply to correspondent nodes with respect to mobile sections only apply to correspondent nodes with respect to mobile
nodes and not for mobile routers. nodes and not mobile routers.
5.3.1. Handling Binding Identifier Mobility Options 5.3.1. Handling Binding Identifier Mobility Options
This specification (see Section 4.1) updates the definition of the This specification (see Section 4.1) updates the definition of the
binding identifier mobility option, originally defined in [RFC5648]. binding identifier mobility option, originally defined in [RFC5648].
According to this specification the BID option includes a BID-PRI According to this specification, the BID option includes a BID-PRI
field assigning each registered care-of address a priority, and thus field assigning each registered care-of address a priority, and thus
placing them in an ordered list (see Section 4.3). places them in an ordered list (see Section 4.3).
Home agents receiving BUs including BID options and flow Home agents receiving BUs including BID options and flow
identification options MUST logically process BID options first. identification options MUST logically process BID options first.
This is because BID Reference sub-options included in the flow This is because BID reference sub-options included in the flow
identification mobility options might refer to BIDs defined in BID identification mobility options might refer to BIDs defined in BID
options included in the same message. options included in the same message.
The BID option is processed as defined in [RFC5648] but then the BID The BID option is processed as defined in [RFC5648], but then the BID
to care-of address mapping is placed in an ordered list according to to care-of address mapping is placed in an ordered list according to
the BID-PRI field of the BID option. the BID-PRI field of the BID option.
Binding Identifier registrations and deregistrations indirectly Binding identifier registrations and deregistrations indirectly
affect the MN's flow binding entries. The home agent MUST update the affect the MN's flow binding entries. The home agent MUST update the
flow binding entries table accordingly as BIDs are added or removed ( flow binding entries table accordingly as BIDs are added or removed
as per [RFC5648]). For example, as discussed in Section 4.3, if all (as per [RFC5648]). For example, as discussed in Section 4.3, if all
of the BIDs associated with a given flow binding entry are removed of the BIDs associated with a given flow binding entry are removed
(i.e., become invalid) the entry MUST be marked as inactive. While (i.e., become invalid) the entry MUST be marked as 'Inactive'. While
if any of the invalid BIDs associated with an inactive flow binding if any of the invalid BIDs associated with an inactive flow binding
entry are registered (i.e., become valid), the entry MUST be marked entry are registered (i.e., become valid), the entry MUST be marked
as active. as 'Active'.
5.3.2. Handling Flow Identification Mobility Options 5.3.2. Handling Flow Identification Mobility Options
When the home agent receives a binding update which includes at least When the home agent receives a binding update that includes at least
one flow identification mobility option, it first performs the one flow identification mobility option, it first performs the
operation described in section 10.3.1 of RFC3775, followed by the operation described in section 10.3.1 of RFC 3775, followed by the
operations defined in Section 5.3.1 of this document. operations defined in Section 5.3.1 of this document.
Home agents that do not support this specification will ignore the Home agents that do not support this specification will ignore the
flow identification mobility options and all their sub-options, flow identification mobility options and all their sub-options,
having no effect on the operation of the rest of the protocol. having no effect on the operation of the rest of the protocol.
If the binding update is accepted, and the home agent is willing to 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 support flow bindings for this MN, the home agent checks the flow
identification mobility options. identification mobility options.
If more than one flow identification mobility option in the same BU, If more than one flow identification mobility option in the same BU
has the same value in the FID field, all the flow identification has the same value in the FID field, all the flow identification
mobility options MUST be rejected. mobility options MUST be rejected.
If all FID fields have different values the flow identification If all FID fields have different values the flow identification
mobility options can be processed further and in any order, as mobility options can be processed further and in any order, as
defined by the following subsections. defined by the following subsections.
5.3.2.1. Handling new FIDs 5.3.2.1. Handling New FIDs
If the FID field of the flow identification mobility option is not If the FID field of the flow identification mobility option is not
already present in the list of flow binding entries for this mobile already present in the list of flow binding entries for this mobile
node, then this is a request for a new entry. node, then this is a request for a new entry.
If the flow identification mobility option does not include a If the flow identification mobility option does not include a
traffic selector sub-option, the home agent MUST reject this traffic selector sub-option, the home agent MUST reject this
request by copying the flow identification mobility option in the request by copying the flow identification mobility option in the
BA, and setting the Status field to the value defined in Figure 2 Binding Acknowledgement (BA) and setting the Status field to the
for "Flow identification option malformed". value defined in Figure 2 for "Flow identification option
malformed".
If the flow identification option does include a traffic selector If the flow identification option does include a traffic selector
sub-option, but the format indicated in the TS Format field is not sub-option, but the format indicated in the TS Format field is not
supported, the home agent MUST reject this request by copying the supported, the home agent MUST reject this request by copying the
flow identification mobility option in the BA, and setting the flow identification mobility option in the BA, and setting the
Status field to the value defined in Figure 2 for "Traffic Status field to the value defined in Figure 2 for "Traffic
Selector format not supported". Selector format not supported".
Then the home agent MUST check the Binding Reference sub-option. Then, the home agent MUST check the binding reference sub-option.
If the Binding reference sub-option is not included, the home If the binding reference sub-option is not included, the home
agent MUST reject this request by copying the flow identification agent MUST reject this request by copying the flow identification
mobility option in the BA, and setting the Status field to the mobility option in the BA and setting the Status field to the
value defined for "Flow identification mobility option malformed" value defined for "Flow identification mobility option malformed"
in Section 4.2. in Section 4.2.
If the binding reference sub-option is present and includes one or 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 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 node, the home agent MUST reject this request by copying the flow
identification option in the BA, and setting the Status field to identification option in the BA and setting the Status field to
the value defined for "BID not found" in Section 4.2. the value defined for "BID not found" in Section 4.2.
If the binding reference sub-option is present and includes one or 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, 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 the home agent SHOULD add a new entry in the mobile node's list of
flow binding entries, as defined below. flow binding entries, as defined below.
When the home agent decides to add an entry in the mobile node's list 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 of flow binding entries, as discussed above, it MUST do it according
to the following rules: The entry MUST be placed according to the to the following rules: the entry MUST be placed according to the
order indicated by the FID-PRI field of the flow identification order indicated by the FID-PRI field of the flow identification
mobility option and it MUST include: mobility option and it MUST include:
the FID as a key to the entry the FID as a key to the entry,
The traffic selector included in the corresponding sub-option the traffic selector included in the corresponding sub-option,
the BIDs indicated in the binding reference sub-option the BIDs indicated in the binding reference sub-option, and
the entry MUST be marked as Active, as shown in Section 4.3 the entry MUST be marked as 'Active', as shown in Section 4.3.
5.3.2.2. Handling known FIDs 5.3.2.2. Handling Known FIDs
If the FID field of the flow identification mobility option is If the FID field of the flow identification mobility option is
already present in the list of flow binding entries for this mobile already present in the list of flow binding entries for this mobile
node, then this is a request to update the existing entry. node, then this is a request to update the existing entry.
The flow binding modification is essentially a process where The flow binding modification is essentially a process where
parameters associated with an existing flow binding entry are parameters associated with an existing flow binding entry are
replaced by the parameters included in a flow identification mobility replaced by the parameters included in a flow identification mobility
option with the same FID as the existing entry. option with the same FID as the existing entry.
The home agent MUST change the priority of the entry according to the The home agent MUST change the priority of the entry according to the
FID-PRI field of the flow identification mobility option. FID-PRI field of the flow identification mobility option.
Since this flow identification mobility option is designed to update Since this flow identification mobility option is designed to update
an existing entry it may or may not include a traffic selector sub- an existing entry, it may or may not include a traffic selector sub-
option. Specifically: option. Specifically:
if a traffic selector sub-option is not included in the flow if a traffic selector sub-option is not included in the flow
identification mobility option, then the traffic selector already identification mobility option, then the traffic selector already
associated with entry MUST be maintained, associated with entry MUST be maintained;
otherwise the traffic selector in the entry MUST be replaced by otherwise, the traffic selector in the entry MUST be replaced by
the traffic selector in the sub-option. the traffic selector in the sub-option.
Since this flow identification mobility option is designed to update Since this flow identification mobility option is designed to update
an existing entry, it may or may not include a binding reference sub- an existing entry, it may or may not include a binding reference sub-
option. Specifically: option. Specifically:
if a binding reference sub-option is not included in the flow if a binding reference sub-option is not included in the flow
identification mobility option, then the BIDs already associated identification mobility option, then the BIDs already associated
with entry MUST be maintained, with entry MUST be maintained;
otherwise the BIDs in the entry MUST be replaced by the BIDs in otherwise, the BIDs in the entry MUST be replaced by the BIDs in
the sub-option. the sub-option.
5.3.3. Handling Flow Summary Mobility Option 5.3.3. Handling Flow Summary Mobility Option
When the home agent receives a binding update which includes flow When the home agent receives a binding update that includes flow
summary mobility options, it first performs the operation described summary mobility options, it first performs the operation described
so far in Section 5.3. so far in Section 5.3.
If the value of any of the FID fields included in a flow summary 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 mobility option is not present in the list of flow binding entries
for this mobile node, the home agent MUST reject this flow binding for this mobile node, the home agent MUST reject this flow binding
refresh by including a flow identification mobility option in the BA 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 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 value of the FID that is not found and the Status field to the value
defined for "FID not found" in Section 4.2. defined for "FID not found" in Section 4.2.
If the value of the FID field is present in the mobile nodes list of 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 flow binding entries the, home agent SHOULD refresh the flow binding
entry identified by the FID without changing any of the other entry identified by the FID without changing any of the other
parameters associated with it. parameters associated with it.
If a given FID is included more than once in the same or different 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 flow summary mobility options in the same binding update message, the
duplicates can be simply ignored. duplicates can be simply ignored.
Note that, an [RFC3775] de-registration binding update (with a zero Note that, an [RFC3775] deregistration binding update (with a zero
lifetime) would result in deleting all bindings, including all flow lifetime) would result in deleting all bindings, including all flow
bindings regardless of the presence of flow summary mobility options. bindings regardless of the presence of flow summary mobility options.
A binding update (with a zero lifetime) would result in deleting all A binding update (with a zero lifetime) would result in deleting all
bindings, including all flow bindings regardless of the presence of bindings, including all flow bindings regardless of the presence of
flow summary mobility options. A specific binding de-registration, flow summary mobility options. A specific binding deregistration,
however, as defined in [RFC5648] (with lifetime of zero and one or however, as defined in [RFC5648] (with lifetime of zero and one or
more Binding Identifier mobility options identifying specific BIDs) more binding identifier mobility options identifying specific BIDs)
does not remove all the bindings for the MN and thus it SHOULD does not remove all the bindings for the MN, and thus it SHOULD
include flow summary mobility options to maintain the flow bindings include flow summary mobility options to maintain the flow bindings
that need to be preserved. that need to be preserved.
5.3.4. Flow Binding Removals 5.3.4. Flow Binding Removals
Removal of flow bindings is performed implicitly by omission of a Removal of flow bindings is performed implicitly by omission of a
given FID from a binding update. given FID from a binding update.
When a valid binding update is received, any registered FIDs that are When a valid binding update is received, any registered FIDs that are
not explicitly referred to in a flow identification mobility option not explicitly referred to in a flow identification mobility option
or in a flow summary mobility option, in the same binding update, 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 MUST be removed from the list of flow binding entries for the mobile
node. node.
5.3.5. Sending Binding Acknowledgements 5.3.5. Sending Binding Acknowledgements
Upon the reception of a binding update, the home agent is required to Upon the reception of a binding update, the home agent is required to
send back a Binding Acknowledgment. The status code in the Binding send back a Binding Acknowledgement. The status code in the Binding
Acknowledgement must be set as recommended in [RFC3775]. This status Acknowledgement must be set as recommended in [RFC3775]. This status
code does not give information on the success or failure of flow code does not give information on the success or failure of flow
bindings. bindings.
In order to inform the mobile node about the status of the flow In order to inform the mobile node about the status of the flow
binding(s) requested by a mobile node, flow identification options binding(s) requested by a mobile node, flow identification options
SHOULD be included in the Binding Acknowledgement message. SHOULD be included in the Binding Acknowledgement message.
Specifically, the home agent SHOULD copy each flow identification Specifically, the home agent SHOULD copy each flow identification
mobility option received in the binding update and set its status mobility option received in the binding update and set its status
code to an appropriate value. Note that the home agent does not need code to an appropriate value. Note that the home agent does not need
to respond specifically regarding FIDs included in a flow summary to respond specifically regarding FIDs included in a flow summary
mobility option but only to those in flow identification mobility mobility option but only to those in flow identification mobility
options. If an operation requested in a flow identification option options. If an operation requested in a flow identification option
by a mobile node is performed successfully by the home agent, the by a mobile node is performed successfully by the home agent, the
status field on the copied flow identification mobility option in the Status field on the copied flow identification mobility option in the
BA, SHOULD be set to the value defined for "Flow binding successful" BA, SHOULD be set to the value defined for "Flow binding successful"
in Section 4.2, otherwise it SHOULD be set to one of the rejection in Section 4.2; otherwise, it SHOULD be set to one of the rejection
codes also defined in Section 4.2. Section 5.3.2 identifies a number codes also defined in Section 4.2. Section 5.3.2 identifies a number
of cases where specific error codes should be used. of cases where specific error codes should be used.
Home agents that support this specification MAY refuse to maintain Home agents that support this specification MAY refuse to maintain
flow bindings by setting the status field of any flow identification flow bindings by setting the Status field of any flow identification
mobility options to the value defined for "Administratively mobility options to the value defined for "Administratively
prohibited" in Section 4.2, or by just ignoring all the flow binding prohibited" in Section 4.2, or by just ignoring all the flow binding
options. options.
Note that BID options and their Status field are handled as defined Note that BID options and their Status field are handled as defined
in [RFC5648]. The BID-PRI field in a BID option included in the in [RFC5648]. The BID-PRI field in a BID option included in the
binding acknowledgement is copied from the the BID-PRI field of the Binding Acknowledgement is copied from the BID-PRI field of the
corresponding BID option in the binding request. corresponding BID option in the binding request.
5.3.6. Packet Processing 5.3.6. Packet Processing
This section defines packet processing rules according to this This section defines packet processing rules according to this
specification. This specification does not change any of the packet specification. This specification does not change any of the packet
interception rules defined in [RFC3775], and [RFC5555]. These rules interception rules defined in [RFC3775] and [RFC5555]. These rules
apply to HAs, MAPs, and CNs, as part of the routing process for any 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 packet with a destination address set to a valid home address of the
mobile node. For nodes other than CNs this also applies to packets mobile node. For nodes other than CNs, this also applies to packets
with destination address set to an address under any of the with a destination address set to an address under any of the
registered prefixes. These rules apply equally to IPv6 packets as registered prefixes. These rules apply equally to IPv6 packets as
well as to IPv4 packets as per [RFC5555]. well as to IPv4 packets as per [RFC5555].
Before a packet is forwarded to the mobile node it MUST be matched 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 against the ordered list of flow bindings stored in the list of flow
binding entries for this mobile node (see Section 4.3). A match is binding entries for this mobile node (see Section 4.3). A match is
attempted with the traffic selector included in the first line attempted with the traffic selector included in the first line
(highest order) of the table. The first entry that creates a match (highest order) of the table. The first entry that creates a match
defines how the packet is routed. When a packet matches the traffic 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 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 of the care-of addresses associated with the BIDs indicated in the
same line of the table. same line of the table.
If any of the BIDs indicated does not correspond to a valid care-of 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 address, e.g., the BID was deregistered then, that BID has no effect
on the traffic. In other words, packets matching the flow binding on the traffic. In other words, packets matching the flow binding
are forwarded to the remaining BIDs, pointing to registered care-of 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 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 valid, then the entry is considered to be inactive (as defined in
Section 4.3) and is skipped. In other words packets should not be Section 4.3) and is skipped. In other words, packets should not be
matched against that entry. matched against that entry.
If a packet does not match any of the active flow binding entries for 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 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 care-of address, i.e., the one associated with the BID with the
BID-PRI. lowest BID-PRI.
If a packet is fragmented, only the first fragment contains all IP If a packet is fragmented, only the first fragment contains all IP
and transport layer headers, while subsequent fragments only contain and transport layer headers, while subsequent fragments only contain
an IP header without transport layer headers. For this reason it is an IP header without transport layer headers. For this reason, it is
possible that subsequent fragments do not match the same traffic possible that subsequent fragments do not match the same traffic
selector as the initial fragment of such a packet. Unless specific selector as the initial fragment of such a packet. Unless specific
measures are taken the likely outcome is that the initial fragment is measures are taken, the likely outcome is that the initial fragment
routed as the MN intended while subsequent fragments are routed is routed as the MN intended while subsequent fragments are routed
differently, and probably based on the default flow binding. HAs, differently, and probably based on the default flow binding. HAs,
MAPs, and CNs SHOULD take care to forward all fragments of a given 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 packet the same way, and in accordance to the flow binding matching
the first fragment of said packet. This should be possible given the the first fragment of said packet. This should be possible given the
fact that fragment headers include enough information to identify a fact that fragment headers include enough information to identify a
fragment as part of a specific packet, but the details of how this is fragment as part of a specific packet, but the details of how this is
ensured are implementation specific and are not defined in this ensured are implementation specific and are not defined in this
specification. specification.
6. MTU Considerations 6. MTU Considerations
The options and sub-options defined in this specification add to The options and sub-options defined in this specification add to
those defined in [RFC3775] and other related specifications, all of those defined in [RFC3775] and other related specifications, all of
which potentially adds to the size of binding update messages. which potentially add to the size of binding update messages.
Implementations SHOULD take care to minimize fragmentation by forming Implementations SHOULD take care to minimize fragmentation by forming
binding updates that are shorter than what the path MTU allows binding updates that are shorter than what the path MTU allows
whenever possible. whenever possible.
This specification offers a number of mechanisms for reducing the This specification offers a number of mechanisms for reducing the
size of binding updates. The operations defined in this size of binding updates. The operations defined in this
specification that require the most verbose options are those specification that require the most verbose options are those
registering new BIDs Section 4.1 and identifying new flows registering new BIDs, Section 4.1, and identifying new flows,
Section 4.2.1.4. Implementations are encouradged to keep binding Section 4.2.1.4. Implementations are encouraged to keep binding
updates to sizes below than that of the path's MTU by making full use updates to sizes below that of the path's MTU by making full use of
of BID reference Section 4.2.1.3 sub-option and flow summary the BID reference sub-option, Section 4.2.1.3, and flow summary
Section 4.2.2 option, which allows them to refer to already option, Section 4.2.2, which allows them to refer to already
registered care-of addresses and flow bindings, while registering new registered care-of addresses and flow bindings, while registering new
ones in subsequent binding update messages. ones in subsequent binding update messages.
7. Security considerations 7. Security considerations
This draft introduces a new option that adds more granularity to the This document introduces a new option that adds more granularity to
binding update and acknowledgement messages defined in [RFC3775], the binding update and acknowledgement messages defined in [RFC3775],
[RFC5555], and [RFC3963], so it inherits the security considerations [RFC5555], and [RFC3963], so it inherits the security considerations
discussed in these documents. The new option allows the mobile node discussed in these documents. The new option allows the mobile node
to associate some flows to one interface and other flows to another to associate some flows to one interface and other flows to another
interface. Since the flow identification mobility option is part of interface. Since the flow identification mobility option is part of
the mobility header, it uses the same security as the Binding Update, 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. whether it is sent to a mobility agent or to a correspondent node.
This specification does not open up new fundamental lines of attack This specification does not open up new fundamental lines of attack
on communications between the MN and its correspondent nodes. on communications between the MN and its correspondent nodes.
However, it allows attacks of a finer granularity than those on the However, it allows attacks of a finer granularity than those on the
binding update. For instance, the attacker can divert or replicate binding update. For instance, the attacker can divert or replicate
flows of special interest to the attacker to an address of the 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 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 modify a binding update sent by the MN. Hence, it becomes doubly
critical that authentication and integrity services are applied to critical that authentication and integrity services are applied to
binding updates. binding updates.
Finally, when the optional anti-replay feature of Encapsulating Finally, when the optional anti-replay feature of Encapsulating
Security Payload (ESP) [RFC4303] is employed and packets from/to Security Payload (ESP) [RFC4303] is employed and packets to/from
different CoAs are sent on the same security association (SA), some different CoAs are sent on the same security association (SA), some
packets could be discarded at the receiver due to the windowing packets could be discarded at the receiver due to the windowing
mechanism used by this feature. Therefore, a sender SHOULD put mechanism used by this feature. Therefore, a sender SHOULD put
traffic from/to different CoAs, but with the same HoA in the selector traffic to/from different CoAs, but with the same HoA in the selector
values, on different SAs to support Multiple Care-of Addresses values, on different SAs to support Multiple Care-of Addresses
appropriately. To permit this, the IPsec implementation SHOULD appropriately. To permit this, the IPsec implementation SHOULD
establish and maintain multiple SAs between a given sender and establish and maintain multiple SAs between a given sender and
receiver, with the same selectors. Distribution of traffic among receiver, with the same selectors. Distribution of traffic among
these parallel SAs to support Multiple Care-of Addresses is locally these parallel SAs to support Multiple Care-of Addresses is locally
determined by the sender and is not negotiated by the Internet Key determined by the sender and is not negotiated by the Internet Key
Exchange (IKEv2) protocol [RFC4306]. The receiver will process the Exchange version 2 (IKEv2) protocol [RFC5996]. The receiver will
packets from the different SAs without prejudice. process the packets from the different SAs without prejudice.
8. IANA Considerations 8. IANA Considerations
This specification requires the following IANA assignments on This specification requires the following IANA assignments on
existing namespaces as well as the creation of some new namespaces. existing namespaces as well as the creation of some new namespaces.
1) New Mobility Options [RFC3775]: This registry is available from New Mobility Options [RFC3775]: This registry is available from
http://www.iana.org under "Mobile IPv6 parameters". The following http://www.iana.org under "Mobile IPv6 parameters". The following
type numbers need to be assigned for: type numbers have been assigned for:
Flow Identification Mobility Option, define in Section 4.2 44 Flow Identification Mobility Option, defined in Section 4.2
Flow Summary Mobility Option, defined in Section 4.2.2 45 Flow Summary Mobility Option, defined in Section 4.2.2
2) New "Flow Identification Mobility Option Status codes" A new "Flow Identification Mobility Option Status Codes" namespace
namespace needs to be created. The following 'Status' codes are has been created. The following 'Status' codes are defined in
defined in this specification, in Section 4.2: this specification, in Section 4.2:
0 Flow binding successful 0 Flow binding successful
1-127 unassigned and available for success codes to be 1-127 Unassigned. Available for success codes to be allocated
allocated via Standards Action or IESG Approval as per via Standards Action or IESG Approval as per [RFC5226].
[RFC5226]
128 Administratively prohibited 128 Administratively prohibited
129 Flow binding rejected, reason unspecified 129 Flow binding rejected, reason unspecified
130 Flow identification mobility option malformed 130 Flow identification mobility option malformed
131 BID not found 131 BID not found
132 FID not found 132 FID not found
133 Traffic selector format not supported 133 Traffic selector format not supported
134-250 unassigned and available for reject codes to be 134-250 Unassigned. Available for reject codes to be allocated
allocated via Standards Action or IESG Approval as per via Standards Action or IESG Approval as per [RFC5226].
[RFC5226]
251-255 reserved for experimental use. This small number of 251-255 Reserved for experimental use. This small number of
status codes should be sufficient for experiments with status codes should be sufficient for experiments with
currently unforeseen error conditions. currently unforeseen error conditions.
4) New "Flow Identification Sub-Options" namespace for the Flow A new "Flow Identification Sub-Options" namespace for the flow
Identification Mobility Option. The sub-option space is defined identification mobility option has been created. The sub-option
in Figure 3. The following Sub-option Type values are defined in space is defined in Figure 3. The following sub-option Type
this specification: values are defined in this specification:
0 Pad 0 Pad
1 PadN 1 PadN
2 BID Reference 2 BID Reference
3 Traffic Selector 3 Traffic Selector
4-250 unassigned and available for allocation based on 4-250 Unassigned. Available for allocation based on Standards
Standards Action or IESG Approval as per [RFC5226] Action or IESG Approval as per [RFC5226].
251-255 reserved for experimental use. This small number of 251-255 Reserved for experimental use. This small number of
sub-option types should be sufficient for experiments with sub-option Types should be sufficient for experiments with
additional parameters associated with a flow. additional parameters associated with a flow.
5) New "Traffic Selector Format" namespace for the Traffic A new "Traffic Selector Format" namespace for the traffic selector
Selector sub-option. The traffic selector format space is defined sub-option has been created. The traffic selector format space is
by the TS Format field in Figure 5. The following values are defined by the TS Format field in Figure 5. The following values
defined in this specification: are defined in this specification:
0 Reserved 0 Reserved
1-250 unassigned and available for allocation based on 1-250 Unassigned. Available for allocation based on Standards
Standards Action or IESG Approval as per [RFC5226] Action or IESG Approval as per [RFC5226].
251-255 reserved for experimental use. This small number of 251-255 Reserved for experimental use. This small number of
traffic selector format types should be sufficient for traffic selector format types should be sufficient for
experiments with different ways of representing a traffic experiments with different ways of representing a traffic
selector. selector.
Similar to the procedures specified for Mobile IPv6 [RFC3775] number Similar to the procedures specified for Mobile IPv6 [RFC3775] number
spaces, future allocations from the new number spaces requires spaces, future allocations from the new number spaces requires
Standards Action or IESG Approval as per [RFC5226] Standards Action or IESG Approval as per [RFC5226].
9. Contributors 9. Contributors
We would like to explicitly acknowledge the following person who co- We would like to explicitly acknowledge the following person who
authored one of the documents used as source material for this coauthored one of the documents used as source material for this
document. document.
Nikolaus A. Fikouras, niko@comnets.uni-bremen.de Nikolaus A. Fikouras, niko@comnets.uni-bremen.de
10. Acknowledgements 10. Acknowledgements
We would also like to acknowledge the following people in We would also like to acknowledge the following people in
alphabetical order for their contributions to this specification: C. alphabetical order for their contributions to this specification: C.
Castelluccia, D. Craig, K. ElMalki, K. Georgios, , C. Goerg, C. Kaas- Castelluccia, D. Craig, K. ElMalki, K. Georgios, C. Goerg, C. Kaas-
Petersen, J. Laganier, T. Noel, F.-N. Pavlidou, V. Park, P. Stupar. Petersen, J. Laganier, T. Noel, V. Park, F.-N. Pavlidou, P. Stupar.
Also, Gabor Fekete for the analysis that led to the inclusion of the Also, Gabor Fekete for the analysis that led to the inclusion of the
BIDRef sub-option, and Henrik Levkowetz for suggesting support for BID reference sub-option, and Henrik Levkowetz for suggesting support
other ways of describing flows. for other ways of describing flows.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-mext-binary-ts]
Tsirtsis, G., Giaretta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings",
draft-ietf-mext-binary-ts-04 (work in progress),
February 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005. RFC 3963, January 2005.
skipping to change at page 36, line 36 skipping to change at page 29, line 40
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009. Routers", RFC 5555, June 2009.
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration", and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009. RFC 5648, October 2009.
[RFC6088] Tsirtsis, G., Giaretta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings", RFC 6088,
January 2011.
11.2. Informative References 11.2. Informative References
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999. RFC 2702, September 1999.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007. Terminology", RFC 4885, July 2007.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008. Management", RFC 5380, October 2008.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
Authors' Addresses Authors' Addresses
George Tsirtsis George Tsirtsis
Qualcomm Qualcomm
Email: tsirtsis@qualcomm.com EMail: tsirtsis@qualcomm.com
Hesham Soliman Hesham Soliman
Elevate Technologies Elevate Technologies
Email: hesham@elevatemobile.com EMail: hesham@elevatemobile.com
Nicolas Montavont Nicolas Montavont
Institut Telecom / Telecom Bretagne Institut Telecom / Telecom Bretagne
2, rue de la chataigneraie 2, rue de la chataigneraie
Cesson Sevigne 35576 Cesson Sevigne 35576
France France
Phone: (+33) 2 99 12 70 23 Phone: (+33) 2 99 12 70 23
Email: nicolas.montavont@telecom-bretagne.eu EMail: nicolas.montavont@telecom-bretagne.eu
URI: http://www.rennes.enst-bretagne.fr/~nmontavo// URI: http://www.rennes.enst-bretagne.fr/~nmontavo//
Gerardo Giaretta Gerardo Giaretta
Qualcomm Qualcomm
Email: gerardog@qualcomm.com EMail: gerardog@qualcomm.com
Koojana Kuladinithi Koojana Kuladinithi
University of Bremen University of Bremen
ComNets-ikom,University of Bremen. ComNets-ikom
Otto-Hahn-Allee NW 1 Otto-Hahn-Allee NW 1
Bremen, Bremen 28359 Bremen, Bremen 28359
Germany Germany
Phone: +49-421-218-8264 Phone: +49-421-218-8264
Fax: +49-421-218-3601 Fax: +49-421-218-3601
Email: koo@comnets.uni-bremen.de EMail: koo@comnets.uni-bremen.de
URI: http://www.comnets.uni-bremen.de/~koo/ URI: http://www.comnets.uni-bremen.de/~koo/
 End of changes. 195 change blocks. 
369 lines changed or deleted 364 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/