draft-ietf-mext-flow-binding-01.txt   draft-ietf-mext-flow-binding-02.txt 
IETF MEXT Working Group H. Soliman, Ed. IETF MEXT Working Group H. Soliman
Internet-Draft Elevate Technologies Internet-Draft Elevate Technologies
Intended status: Standards Track N. Montavont Intended status: Standards Track G. Tsirtsis
Expires: August 17, 2009 GET/ENST-B Expires: October 30, 2009 Qualcomm
N. Fikouras N. Montavont
IT/TB
G. Giaretta
Qualcomm
K. Kuladinithi K. Kuladinithi
University of Bremen University of Bremen
February 13, 2009 April 28, 2009
Flow Bindings in Mobile IPv6 and Nemo Basic Support Flow Bindings in Mobile IPv6 and Nemo Basic Support
draft-ietf-mext-flow-binding-01.txt draft-ietf-mext-flow-binding-02.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 17, 2009. This Internet-Draft will expire on October 30, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This document introduces extensions to Mobile IPv6 and Nemo Basic This document introduces extensions to Mobile IPv6 that allow nodes
Support that allow nodes to bind one or more flows to a care-of to bind one or more flows to a care-of address. These extensions
address. These extensions allow multihomed nodes to take full allow multihomed nodes to instruct their peers to direct downlink
advantage of the different properties associated with each of their flows to specific addresses.
interfaces.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Flow Identification option . . . . . . . . . . . . . . . . 7 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 8
3.2. The Binding Reference Sub-option . . . . . . . . . . . . . 10 4.1. Definition Update for Binding Identifier Mobility
3.3. Binding Cache and Binding Update list extensions . . . . . 11 Option . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Protocol operations . . . . . . . . . . . . . . . . . . . . . 12 4.2. Flow Identification Mobility Option . . . . . . . . . . . 8
4.1. Interaction with the Multiple CoA bindings mechanism . . . 12 4.2.1. Binding Reference Sub-option . . . . . . . . . . . . . 11
4.2. Flow binding storage . . . . . . . . . . . . . . . . . . . 13 4.2.2. Flow Description Sub-option . . . . . . . . . . . . . 12
4.3. Preferred Care-of address . . . . . . . . . . . . . . . . 13 4.3. Flow Identification Summary Mobility Option . . . . . . . 13
4.4. Adding flow bindings . . . . . . . . . . . . . . . . . . . 13 4.4. Flow Bindings entries list and its relationship to
4.5. Modifying flow bindings . . . . . . . . . . . . . . . . . 14 Binding Cache . . . . . . . . . . . . . . . . . . . . . . 14
4.6. Removing flow bindings . . . . . . . . . . . . . . . . . . 15 5. Protocol operations . . . . . . . . . . . . . . . . . . . . . 17
4.7. Refreshing Flow Bindings . . . . . . . . . . . . . . . . . 15 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.8. Acknowledging flow identification options . . . . . . . . 15 5.1.1. Preferred Care-of address . . . . . . . . . . . . . . 17
5. Usage scenario . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Mobile Node Considerations . . . . . . . . . . . . . . . . 17
6. Mobile Node operations . . . . . . . . . . . . . . . . . . . . 18 5.2.1. Sending BU with BID Options . . . . . . . . . . . . . 18
6.1. Default Bindings . . . . . . . . . . . . . . . . . . . . . 18 5.2.2. Sending BU with Flow Identification Options . . . . . 18
6.1.1. Managing Flow Bindings with the Home Agent and MAP . . 18 5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 20
6.1.2. Managing Flow Bindings in Correspondent nodes . . . . 19 5.2.4. Removing flow bindings . . . . . . . . . . . . . . . . 21
6.1.3. Using Alternate Care-Of Address . . . . . . . . . . . 20 5.2.5. Receiving Binding Acknowledgements . . . . . . . . . . 21
6.1.4. Receiving Binding Acknowledgements . . . . . . . . . . 20 5.2.6. Return Routability Procedure . . . . . . . . . . . . . 21
6.2. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 22
6.3. Return Routability Procedure . . . . . . . . . . . . . . . 20 5.3.1. Receiving BU with BID Options . . . . . . . . . . . . 22
6.4. Returning Home . . . . . . . . . . . . . . . . . . . . . . 21 5.3.2. Receiving BU with Flow Identification Options . . . . 23
7. Applicability to Route Optimization . . . . . . . . . . . . . 22 5.3.3. Receiving BU with Flow Summary Option . . . . . . . . 25
7.1. Receiving Binding Udpate . . . . . . . . . . . . . . . . . 22 5.3.4. Handling flow binding Removals . . . . . . . . . . . . 26
8. Home Agent operations . . . . . . . . . . . . . . . . . . . . 24 5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 26
8.1. Receiving Binding Update with the Flow Identification 5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 27
option . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Security considerations . . . . . . . . . . . . . . . . . . . 28
8.2. Sending Binding Ackowledgement . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8.3. Deleting an entry in the binding cache . . . . . . . . . . 25 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.3.1. Removing Flow Bindings . . . . . . . . . . . . . . . . 26 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
9. Applicability to Hierarchical Mobile IPv6 . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10. Security considerations . . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 32
12. Informative References . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Requirements notation
Mobile IPv6 (RFC3775) [RFC3775] and Nemo Basic Support (RFC3963) The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
[RFC3963] allow a mobile node / mobile router to manage its mobility "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
using the binding update message, which binds one care-of address to document are to be interpreted as described in [RFC2119].
one home address. The binding update message can be sent to the home
agent. In Mobile IPv6, the Binding Update can also be sent to
correspondent node or to a mobility anchor point (see RFC4140
[RFC4140]). The semantics of the binding update are limited to
address changes. That is, RFC3775 [RFC3775] and RFC3963 [RFC3963] do
not allow a mobile node / mobile router to bind more than one address
to the home address. Furthermore, the binding granularity is limited
to the address. Therefore, a mobile host cannot associate one of the
connections using the home address with a different care-of address.
In draft-ietf-monami6-multiplecoa Mobile IPv6 and Nemo Basic Support
are extended to allow the binding of more than one care-of address to
a home address. This specification extends Mobile IPv6 and Nemo
Basic Support to allow it to specify policies associated with each
binding. A policy can contain a request for a special treatment of a
particular flow. Hence, this specification allows a mobile node /
mobile router to bind a particular flow to a care-of address without
affecting other flows using the same home address. In addition, we
will see that this specification allows to bind a particular flow to
a particular care-of address directly with correspondent node and
mobility anchor point in the case of a single mobile node.
In this document, a flow is defined as one or more connections that 2. Introduction
are identified by a flow identifier. A single connection is
typically identified by the source and destination IP addresses,
transport protocol number and the source and destination port
numbers. Alternatively a flow can be identified in a simpler manner
using the flow label field in the IPv6 header [RFC2460] or the
Security Parameter Index (SPI) when IPsec is used.
Flow bindings are useful in cases where the mobile node / mobile Mobile IPv6 [RFC3775], DSMIPv6 [I-D.ietf-mext-nemo-v4traversal] and
router has more than one address, probably due to being multihomed, Nemo Basic Support [RFC3963] allow a mobile node / mobile router to
and wants to direct certain flows to certain addresses. This may be manage its mobility using the binding update message, which binds one
done because some flows are better suited to certain link layers or care-of address to one home address. The binding update message can
simply to load balance flows between different interfaces. This be sent to the home agent. In Mobile IPv6, the binding update can
specification introduces the flow identifier option, which is also be sent to correspondent node or to a mobility anchor point (see
included in the binding update message and used to distribute [RFC5380]). The semantics of the binding update are limited to
policies to the recipient of the binding update. However, this care-of address changes. That is, [RFC3775],
document does not define the flow itself but only the action to take [I-D.ietf-mext-nemo-v4traversal], and [RFC3963] do not allow a mobile
on this flow. The flow description will be defined in another node / mobile router to bind more than one address to the home
document. This will allow to use the same flow description in address. In [I-D.ietf-monami6-multiplecoa] Mobile IPv6 and Nemo
several protocols. Using the flow identifier option introduced in Basic Support are extended to allow the binding of more than one
this specification a mobile node / mobile router can bind one or more care-of address to a home address. This specification further
flows to a care-of address while maintaining the reception of other extends Mobile IPv6, DSMIPv6, and Nemo Basic Support to allow it to
flows on another care-of address. Requesting the flow binding can be specify policies associated with each binding. A policy can contain
decided based on local policies within the mobile node / mobile a request for a special treatment of a particular IPv4 or IPv6 flow,
router and based on the link characteristics and the types of which is viewed as a group of packets matching a flow descriptor.
applications running at the time. Such policies are outside the Hence, this specification allows a mobile node / mobile router to
scope of this document. bind a particular flow to a care-of address without affecting other
flows using the same home address. In addition, this specification
allows to bind a particular flow to a particular care-of address
directly with correspondent node and mobility anchor point.
In this document, a flow is defined as a set of IP packets matching a
flow descriptor. A flow descriptor can identify the source and
destination IP addresses, transport protocol number, the source and
destination port numbers and other fields in IP and higher layer
headers. This specification, however, does not define flow
descriptors and it is assumed that one or more ways of defining flow
descriptors are going to be defined in other specifications. This
specification, however, does define the sub-option extension format
to be used for any defined flows descriptors.
Using the flow identifier option introduced in this specification a
mobile node / mobile router can bind one or more flows to a care-of
address while maintaining the reception of other flows on another
care-of address. Requesting the flow binding can be decided based on
local policies within the mobile node / mobile router and based on
the link characteristics and the types of applications running at the
time. Such policies are outside the scope of this document.
It should be noted that the flow identification option can be It should be noted that the flow identification option can be
associated with any binding update, whether it is sent to a associated with any binding update, whether it is sent to a home
correspondent node (in the case of Mobile IPv6), home agent or agent, correspondent node (in the case of Mobile IPv6), or mobility
mobility anchor point (in the case of Hierarchical Mobile IPv6). anchor point (in the case of Hierarchical Mobile IPv6).
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 [RFC3775] or a designate either a mobile node as defined in [RFC3775] or a mobile
mobile router as defined in RFC3963 [RFC3963] unless stated router as defined in [RFC3963] unless stated otherwise.
otherwise.
2. Terminology 3. Terminology
Terms used in this document are defined in [RFC3753] and Terms used in this document are defined in [RFC3753] and [RFC4885].
[I-D.ietf-nemo-terminology]. The following terms are also used in The following terms are also used in this document:
this document:
Flow: A flow is identified as a set of data packets that are Flow: A flow is identified as a set of data packets that are
exchanged between two distant hosts exchanged between two nodes and match a given flow description
Flow Description: A set of instructions that describes a flow. Flow Description: A set of instructions that describes a flow.
Flow Identifier: Identifier of a flow binding. Flow Identifier: Identifier of a flow binding.
Flow binding: A mobility binding extended with a flow identifier Flow binding: An entry in the list of flow binding associated with
and flow description. a given mobile node.
3. 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.
3.1. Flow Identification option 4.1. Definition Update for Binding Identifier Mobility Option
The Flow identification option is included in the binding update and This specification updates the definition of the Binding Identifier
acknowledgement messages. This option contains information that Mobility option defined in [I-D.ietf-monami6-multiplecoa], as
allows the receiver of a binding update to install policies on a follows:
traffic flow and route it to a given address. Multiple options may
exist within a binding update message. The Flow identification 1 2 3
option must come with another option (that will be defined in another 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
document) that will describe the flow. This additional option is +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
called Flow Description in the remaining of this document. | Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID (BID) | Status |H| BID-PRI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ +
: IPv4 or IPv6 care-of address (CoA) :
+ +
+---------------------------------------------------------------+
Figure 1: The Binding Identifier Mobility option
BID-PRI
This is a 7-bit field placing each BID to a relative priority
with other registered BIDs. Value "0" is reserved for
implementation of [I-D.ietf-monami6-multiplecoa] that do not
support this specification. A higher number in this field
indicates lower priority, while BIDs with the same BID-PRI
value have equal priority.
4.2. Flow Identification Mobility Option
The Flow identification mobility option is included in the binding
update and acknowledgement messages. This option contains
information that allows the receiver of a binding update to install
policies on a traffic flow and route it to a given care-of address.
Multiple options may exist within the same binding update message.
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 | PRI | FID | | Option Type | Option Len | FID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FID | Action | Status | PRO | Res. | | FID-PRI | Action | Rsvd | PRO | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Description ...
Figure 1: The flow identification option Figure 2: The flow identification mobility option
Option Type Option Type
TBD TBD
Option Len Option Len
Length of option in 8-octet units Length of option, including any sub-options, in 8-octet units
PRI FID
This is a 8-bit priority field to indicate the priority of a The Flow Identifier field is an 8-bit unsigned integer that
includes the identifier for the flow binding. This field is
used to refer to an existing binding or to create a new
binding. The value of this field is set by the mobile node.
FID-PRI
This is an 8-bit priority field to indicate the priority of a
particular option. This field is needed in cases where two particular option. This field is needed in cases where two
different flow descriptions in two different options overlap. different flow descriptions in two different options overlap.
The priority field decides which policy should be in those The priority field decides which policy should be in those
cases. A lower number in this field indicates a higher cases. A lower number in this field indicates a higher
priority. priority.
FID
The Flow Identifier field is an 8-bit unsigned integer that
includes the identifier for the flow binding. This field is
used to refer to an existing binding or to create a new
binding.
Action Action
This field specifies the action that needs to be taken by the This field specifies the action that needs to be taken by the
receiver of the binding update containing the flow receiver of the binding update containing the flow
identification option. identification option. The details of these requests are
discussed below.
Status Rsvd
This field indicates the success or failure of the flow binding This field is unused. It MUST be initialized to zero by the
operation for the particular flow in the option. This field is sender and MUST be ignored by the receiver.
not relevant to the binding update message as a whole or to
other flow identification options. Values from 0 to 127
indicate success. Values of 128 and higher indicate failure.
This field is only relevant when included in the Binding
Acknowledgement message and must be ignored in the binding
update message.
PRO PRO
This is a 4-bit field that describes the required processing This is a 4-bit field that describes the required processing
for the option. This field may indicate a request for adding, for the option. This field may indicate a request for adding,
deleting, modifying or refreshing the option. The details of deleting, modifying or refreshing the option. The details of
these requests are discussed below. these requests are discussed below.
Res. Status
This field is unused. It MUST be initialized to zero by the This field indicates the success or failure of the flow binding
sender and MUST be ignored by the receiver. operation for the particular flow in the option. This field is
not relevant to the binding update message as a whole or to
other flow identification options. Values from 0 to 127
indicate success. Values of 128 and higher indicate failure.
This field is only relevant when included in the Binding
Acknowledgement message and must be ignored in the binding
update message.
The following values are reserved for the PRO field in this option: The following values are reserved for the PRO field in this option:
0 Add a flow binding 0 Add a flow binding
1 Replace a flow binding 1 Modify a flow binding
2 Refresh the current binding
15 Remove a flow binding
The following values are reserved for the Action field in this The following values are reserved for the Action field in this
option: option:
1 Forward. This value indicates a request to forward a flow to 1 Forward. This value indicates a request to forward a flow to
the address included or referred by the option. the address indicated in the Binding Reference sub-option. A
single BID MUST be associated with this Action.
2 Discard. This value indicates a request to discard all packets 2 Discard. This value indicates a request to discard all packets
in the flow described by the option. in the flow described by the option. No BIDs are associated with
this Action.
2 n-cast. his value indicates a request to replicate the flow to 3 n-cast. This value indicates a request to replicate the flow to
several addresses. If this value is used, one or more Binding several addresses indicated in the Binding Reference sub-option.
Reference sub-options MUST exist. The Binding Reference sub- One or more BIDs MUST be associated with this Action.
option is described later in this specification
The following values are reserved for the status field within the The following values are reserved for the status field within the
flow identification option: flow identification option:
0 Flow binding successful. 0 Flow binding successful.
128 Flow binding rejected, reason unspecified. 128 Flow binding rejected, reason unspecified.
129 Flow binding option poorly formed. 129 Flow identification option poorly formed.
130 Administratively prohibited. 130 Administratively prohibited.
131 Flow identification by IPv6 prefix is not supported.
132 Flow identification by port numbers is not supported.
133 Flow identification with Flow label is not supported.
134 Flow identification with SPI is not supported.
135 FID already in use 135 FID already in use
136 FID not found 136 FID not found
137 Classifier language not supported. 137 FD-Type not supported.
138 Discard function not supported. 138 Discard function not supported.
139 N-cast function not supported. 139 N-cast function not supported.
It should be noted that per-packet load balancing has negative It should be noted that per-packet load balancing may have negative
impacts on TCP congestion avoidance mechanisms as it is desirable to impacts on TCP congestion avoidance mechanisms as it is desirable to
maintain order between packets belonging to the same TCP connection. maintain order between packets belonging to the same TCP connection.
This behaviour is specified in RFC2702 [RFC2702]. Other negative This behaviour is specified in RFC2702 [RFC2702]. Other negative
impacts are also foreseen for other types of real time connections impacts are also foreseen for other types of real time connections
due to the potential variations in RTT between packets. Hence per- due to the potential variations in RTT between packets. Hence per-
packet load balancing is not allowed in this extension. However, the packet load balancing is not currently supported in this extension.
MN can still request per-flow load balancing provided that the entire
flow is moved to the new interface.
3.2. The Binding Reference Sub-option A number of sub-options can follow the option defined in this
section. These are defined below.
4.2.1. Binding Reference Sub-option
This section introduces the Binding Reference sub-option, which may This section introduces the Binding Reference sub-option, which may
be included in the Flow identification option. The Binding Reference be included in the Flow identification option. The Binding Reference
sub-option includes one or more BIDs as defined in the MCoA document. sub-option includes one or more BIDs defined in MCoA
When this sub-option is included in the Flow identification option it [I-D.ietf-monami6-multiplecoa]. When this sub-option is included in
associates the flow described with one or more BIDs that where the Flow identification option it associates the flow described with
already registered with the recipient of the BU. A BID sub-option is one or more registered BIDs.
not necessarily included in the same BU, but MUST be already known to
the receiver of the BU. The Binding Reference sub-option is shown The binding identifier option, defined in
[I-D.ietf-monami6-multiplecoa], registering a given BID which is then
indicated in the Binding Reference sub-option, MUST be either defined
in the same or earlier BU from the one including the binding
reference sub-option. The Binding Reference sub-option is shown
below. below.
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 ........
+-+-+-+- +-+-+-+-+-+-+-+-+-+-
Figure 2: The Binding Reference sub-option
Figure 3: The Binding Reference sub-option
Sub-opt Type Sub-opt Type
Indicates the Sub-option type. For the Binding Reference sub- Indicates the Sub-option type. For the Binding Reference sub-
option, this field MUST be set to 1. option, this field MUST be set to 1.
Sub-opt Len Sub-opt Len
Indicates the sub-option length in octets. This field includes Indicates the sub-option length in octets. This field includes
the entire length of the sub-option including the type and the entire length of the sub-option including the Sub-opt Type
length fields. and Sub-opt-Len fields.
BID BID
The BID that the mobile node wants to associate with the flow The BID that the mobile node wants to associate with the flow
identification option. One or more BID fields can be included identification option. One or more BID fields can be included
in this sub-option. in this sub-option. Since each BID is 2 byte long, the value
of the Sub-opt Len field indicates the number of BIDs present.
Number of BIDs = (Sub-opt Len-2)/2.
3.3. Binding Cache and Binding Update list extensions 4.2.2. Flow Description Sub-option
Flow bindings are conceptually stored in Binding Cache of home agent, The Flow description sub-option(s) include the parameters used to
mobility anchor point and correspondent node, and in Binding Update match packets for a specific flow binding.
List of mobile node. These logical structures need to be extended to
include the following parameters (in addition to those described in
RFC3775 [RFC3775]):
* FID (Flow Identifier). For a given home address, the FID MUST 0 1 2 3
uniquely identify an entry, i.e. a unique flow binding. An FID 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
is only unique for a given home address. Different mobile +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
nodes can use the same FID value. |Sub-opt Type | Sub-Opt Len | Flow Description ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Each attribute that constitutes the flow dsecription (and that Figure 4: The Flow Description sub-option
are defined in a separate document).
An entry in these structures is identified by the couple (home Sub-opt Type
address, FID).
4. Protocol operations Indicates the Sub-option type. For the flow description sub-
option, this field SHOULD be set to one of the FD types defined
below.
The flow identification option defines the controls on flow bindings. Sub-opt Len
The fields of the flow identification option are necessary for
indexing flow identification options, indicating the sort of action
that should be undertaken to the recipient's Binding Cache or for
carrying the results of such a petition. The flow description is
transported in another option that will be defined in another
document. This separation is made to use the same flow description
in various protocols.
This specification allows mobile nodes to direct flows to a Indicates the sub-option length in octets. This field includes
particular care-of address. This can be done by aggregating many the entire length of the sub-option including the Sub-opt Type
flows in the flow identification option (e.g. all TCP traffic), or by and Sub-opt-Len fields.
uniquely identifying a flow in the flow identification option.
The remaining of this section discusses how mobile nodes can use the Flow Description
flow identification option when sending binding updates to the
correspondent node, home agent or mobility anchor point. In
addition, deletion and modification of bindings are all discussed
below.
4.1. Interaction with the Multiple CoA bindings mechanism The flow description corresponding to the type indicated by the
Sub-opt Type field. Flow description is out of scope of this
document.
Flow binding presented in this specification MUST be used with the The following values are reserved for the sub-option Type values are
solution in draft-ietf-monami6-multiplecoa. The main reason why is defined for Flow Description:
to avoid the duplication of the default binding to be used when none
of the registered rules can apply to a flow. As the multiple CoA
bindings document already defines a prority field which indicates
which care-of address is preferred, flow binding uses this priority
field in order to maintain a primary Care-of address (see below
section Section 4.3).
Moreover, combining the mechanism in this specification with the 17-32 reserved for Flow Description formats.
multiple CoA bindings allows for further aggregation of bindings.
For example, if a mobile node has several flow identifiers bound to a
single Care-of address identified by a unique BID, the mobile node
can change the Care-of address for all these flows bindings just by
changing the Care-of address associated with the given BID.
Additionally, the combination of the two mechanisms allows for 4.3. Flow Identification Summary Mobility Option
additional features (e.g., n-casting) to take place with minimal
effort. Hence, this specification makes use of the BID option
described in draft-ietf-monami6-multiplecoa.
4.2. Flow binding storage TBD
Home agent, correspondent node and mobility anchor point maintain 0 1 2 3
Binding Cache in order to record associations between home addresses 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
and care-of addresses of mobile nodes that are away from the home +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
link. Mobile nodes maintain binding update list to record binding | Option Type | Option Len | FID |
between home address and care-of address. RFC 3775 [RFC3775] allows +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
mobile nodes to register only one care-of address per home address. | FID ........
Thus a binding cache entry is uniquely identified by the home +-+-+-+-+-+-+-+-+-+-
address.
This specification extends the binding cache and the binding update Figure 5: The Flow Identification Summary Option
list structures, and allows mobile node to (1) register multiple
care-of addresses for a given home address and (2) associate flow
binding policies with the registered care-of addresses.
New parameters are added to these conceptual structures in order to Option Type
list the particular rule associated with a standard binding. On one
hand, an entry is now identified by the pair (home address, FID)
because several Care-of addresses may be bound to a single home
address. On the other hand, the Care-of address is selected
according to the best match between the packets that need to be sent,
and the existing flow bindings. If no matching is found between the
flow bindings and the data packet, a preferred entry is used (see
next subsection). If a flow matches two different flow bindings, the
PRI field indicates which action is preferred by the mobile node.
4.3. Preferred Care-of address Indicates the Sub-option type. For the Binding Reference sub-
option, this field MUST be set to 1.
Any distant node which supports the flow identification option MUST Option Length
maintain a default binding per home address. A default binding
indicates an association between a home address and a Care-of
address. In addition to the default binding, several bindings may
co-exist within a binding cache for the same home address, each of
them indicating different bindings between flows and Care-of
addresses. When a data flow is intercepted by a home agent or
initiated by a correspondent node, if the said data flow does not
match an existing flow identification option, the care-of address
indicated in the default binding is used as destination address for
the mobile node. The default binding is indicated by the Priority
field in the BID option described in draft-ietf-monami6-multiplecoa.
A mobile node is responsible for having a preferred care-of address
with the receiver of the flow identification option.
4.4. Adding flow bindings Indicates the sub-option length in octets. This field includes
the entire length of the sub-option including the Sub-opt Type
and Sub-opt-Len fields.
When adding a new flow binding, a mobile node sends the flow FID
identification option in the binding update. The care-of address
concerned with this binding update must already be registered by the
receiver of the binding update (i.e., must already be associated with
a BID), or a BID sub-option MUST be present in the binding update (as
defined in draft-ietf-multiplecoa"). The flow identification option
MUST include a unique FID. The FID needs only be unique for the
receiver of the binding update, i.e. the same FID can be used across
different receivers of the binding update. The PRO field MUST
indicate an Add operation. Adding the flow binding implies
associating a flow with a particular care-of address for the mobile
node. The care-of address concerned with the flow binding is present
in the source address of the packet or the alternate care-of address
option. Alternatively, the care-of address may be indicated by the
BID (which is pointing to an existing care-of address) when the
Binding Reference sub-option of the Flow Identification option is
present.
The mobile node may need to define the flow partially or entirely A registered FID. One or more FID fields can be included in
based on the source and destination addresses in packets. For this option. Since each FID is 2 bytes long, the value of the
instance, a mobile node may choose to forward all flows from address Option Len field indicates the number of FIDs present. Number
A to address B to a particular care-of address. Alternatively, more of FIDs = (Sub-opt Len-2)/2.
granularity can be added by including port numbers and protocol.
These descriptions will be given in another document.
An Add operation implies that the FID is new and is not already used 4.4. Flow Bindings entries list and its relationship to Binding Cache
by the mobile node for any other flow binding. If the Flow
identification option is sent without any flow description and with
the PRO field indicating an Add operation, this MUST be seen as a
wild card request by the sender. A wild card request implies that
all flows should be directed to the particular care-of address in the
packet.
4.5. Modifying flow bindings The conceptual mobile IPv6 binding cache was defined in [RFC3775] to
identify the mobile IP state maintained by the mobile node, home
agent, and corresponding node. The binding cache includes, between
others, the mobile node's home address, the registered care-of
address, and the lifetime of the binding. The binding cache was then
extended by [I-D.ietf-monami6-multiplecoa] to include more than one
care-of addresses and to associate each of them with a Binding
Identifier (BID).
When modifying a flow binding (either the care-of address or other This specification does not change modify the mobile IPv6 binding
attributes of the flow), the mobile node sends the binding update cache any further.
with a flow identification option. The option includes the FID for
the binding being modified, as well as the PRO field set to 1,
indicating a request to modify the binding. A flow description
option may come with the flow identification option and contain the
new attributes needed to classify the flow. Hence, flow modification
is essentially a process where an existing flow definition is removed
and a new flow (included in the option) is added and given the same
FID as the flow that was removed.
If one of the care-of addresses needs to be updated with a new one Flow bindings can be thought of as a conceptual list of entries that
(e.g., after a change of the IP point of attachment), the mobile node is separate from the binding cache. The flow bindings list contains
may just need to register the new care-of address for the given BID. an entry for each of the registered flow binding. Flow binding
entries can point to an entry in the binding cache by means of the
BID. Each flow binding entry include the following parameters :
4.6. Removing flow bindings * FID (Flow Identifier): For a given mobile node, identified by
its primary home address, the FID MUST uniquely identify an
entry, i.e. a unique flow binding. Each mobile node can only
have a single entry identified by a given FID at any one time.
Different mobile nodes can use the same FID number space.
When removing a flow binding, the mobile node sends a binding update * A Flow Descriptor: Included in a Flow Description sub-option.
message with the flow identification option. The PRO field MUST be
set to a value of 15, which indicates a request for removing a flow
binding. This will provide enough information for the receiver to
locate the flow binding using the FID and remove it.
4.7. Refreshing Flow Bindings * BID(s): The list of BIDs associated with the entry as defined
by the Binding Reference sub-option included in the FID option
that created it.
A flow binding is refreshed by simply including the Flow * Action: The action associated with a given entry as defined by
identification option in the BU message. In this case the PRO field the PRO field of the FID option that created it
is set to indicate a refresh operation.
The refresh operation is included in this specification due to the * Active/Inactive flag: This flag indicates whether the entry is
nature of the BU message. The BU message updates existing bindings active or inactive.
with new information. Hence, all information previously sent in the
last BU message need to be resent in all new messages, otherwise such
information will be lost.
4.8. Acknowledging flow identification options The flow bindings list is associated with a given mobile node, and
the corresponding binding cache. An entry in the flow bindings list,
however, is identified by the FID and the list is ordered according
to the FID-PRI field as defined in the FID option that created each
entry.
The home agent and mobility anchor point are required to ackowledge The BIDs included in a given entry point to a corresponding entry in
the reception of Binding Update by sending Binding Acknowledgment. A the binding cache for the purpose of identifying a care-of address.
correspondent node SHOULD also acknowledge Binding Update. The
Binding Acknowledgement is extended by this specification to indicate
to the mobile node the success of the flow binding. If a Binding
Acknowledgement needs to be sent in response to a Binding Update that
contained flow identification option(s), a copy of each flow
identification MUST be included. Only the Status field needs to be
changed to the appropriate value. The absence of flow identification
option in Binding Acknwoledgement indicates that the sender does not
support the extension descibed in this document and therefore MUST be
interpreted as a negative acknowledgement.
5. Usage scenario Depending on the Action parameter in a given entry a valid BID is
required to make the entry "active". If all of the BIDs pointed to
by a given entry are not valid BIDs in the binding cache, the flow
binding entry becomes "inactive", in other words it does not affect
data traffic. Note that if the action parameter in an entry
indicates "n-cast" then the entry becomes inactive only if none of
the BIDs is valid. If only some of the BIDs are valid, the invalid
BIDs are simply ignored.
In this section, we highlight a use case of the flow identification Also note that the state described in this section is maintained by
option. the mobile node as well as in mobility agents and corresponding
nodes. As such the mobile node is fully aware of which are the valid
BIDs at any time and which flow binding entries are active/inactive.
Section 5 defines how these flow binding entries are manipulated by
the mobile node in detail.
Assume a mobile node equipped with two interfaces namely If1 and If2, As an example the following represents an ordered flow bindings
each connected to a different foreign network. The mobile node entries table for a mobile node that has registered three care-of
configures one global IPv6 address on each interface, namely CoA1 and addresses and three flow bindings.
CoA2 respectively. The mobile node runs Mobile IPv6 with a home
agent located in its home network. We assume that an existing IPsec
security association is set up betweeen the mobile node and its home
agent. We assume that the mobile node wants to exchange secure data
flows over CoA1 and insecure data flows over CoA2. To do so, the
mobile node may request its home agent to redirect packets intended
to the mobile node's home address to a different care-of address,
depending on the type of the communication. For example, port
numbers 22 (ssh) and 443 (https) may be tunneled to CoA1 while other
communications may be tunneled to CoA2. In order to set up these
flow bindings, the following messages are exchanged:
* The mobile node sends a Binding Update through If2, with the FID-PRI FID Flow Description BIDs Action A/I
source address set to CoA2. The Binding Update includes a BID ------- --- ---------------- ---- ------- ------
sub-option as described in draft-ietf-monami6-multiplecoa. 10 4 TCP 2 Forward Active
This sub-option intends to set the highest preference on the 20 3 srcAddr=IPx N/A Discard Active
given Care-of address. 30 2 srcAddr=IPy 4 Forward Inactive
40 5 UDP 1,3 N-Cast Active
* When the home agent receives the Binding Update, it first Ordered Flow Binding Entries
validates the Binding Update as recommanded in section 10.3 of
[RFC3775]. If the Binding Update is accepted, the home agent
processes the BID sub-option as described in section 6.2 of
draft-ietf-monami6-multiplecoa. It then registers the source
address of the Binding Update as the preferred care-of address
for the given home address and sends back a Binding
Acknowledgement.
* Later, the mobile node sends additional Binding Update with According to the above list of flow binding entries, all TCP traffic
both Flow Identification options and BID sub-option. The BID will match the first entry, and according to the Action indicated it
sub-option is used to indicate the priority of the new Care-of will be forwarded to BID2, corresponding to a given care-of address
address. In this example, the priority must be lower than the (IP3), as shown below. Any traffic that is not TCP, but has as
priority of CoA2. The flow identification options are used to source address IPx will match the second entry, and according to the
indicate the Care-of address usage preferences. In order to associated Action it will be discarded. Note that any TCP traffic
redirect source port numbers 22 and 443 to CoA1, two flow with source address IPx will match the first entry and thus it will
identification options need to be transported as well in the be forwarded as per that entry.
Binding Update. These flow identification options are set as
follows: PRI is set to 1, Action is set to 0 (forward), PRO is
set to 0 (add), FID is set to 1 (and 2 for the second option),
and the following flow description option should indicate port
number 22 and 443.
* When the home agent receives this second Binding Update, it The third entry is marked as Inactive since the BID 4 does not exist
first checks the validity of the Binding Update as recommanded in the ordered list of BID entries below. Inactive entries do not
in section 10.3 of [RFC3775] and section 6.2 of affect traffic, i.e., packets are not matched against them.
draft-ietf-monami6-multiplecoa. If the Binding Update is
accepted, the Flow Identification options are treated. If
these options are accepted by the home agent, it will return a
Binding Acknowledgement with Flow Identification options, each
of them having the same first 8 bytes, and the Status field set
to 0 (success).
Thereafter, if a data flow is destinated to the home address of Any UDP traffic that does not match any of the earlier entries will
the mobile node, the home agent will determine if the source match the third rule and according to the Action indicated it will be
port number is equal to 22 or 443. If yes, the home agent will replicated and forwarded to BIDs 1 and 3, corresponding to care-of
tunnel the data flow to CoA1. If not, the data flow will be addresses IP1 and IP2 shown below.
forwarded to CoA2.
6. Mobile Node operations Finally any remaining packets that do not match any of the entries
above will be simply forwarded to the care-of address indicated by
the highest order BID in the table below. In the example, such
packets will be forwarded to BID 1, corresponding to care-of address
IP1.
6.1. Default Bindings BID-PRI BID CoA
--------- --- ---
20 1 IP1
30 3 IP2
30 2 IP3
A default binding is always maintained between a MN and its peers Ordered BID Entries
(home agent, correspondent node if RO is used and mobility anchor
point if applicable). The default entry indicates which care-of
address to use for a data flow that does not match any of the flow
bindings. The preferred care-of address is determined through the
BID option.
6.1.1. Managing Flow Bindings with the Home Agent and MAP 5. Protocol operations
A mobile node may establish a Flow Binding by issuing a Binding 5.1. General
Update containing a Flow Identifier (possibly associated with a Flow
Description) in its mobility options. The Flow Identification option
MUST indicate valid FID, PRO, PRI (rule priority) and Action fields.
The PRO field of the Flow Identification option indicates the This specification introduces a flow bindings list of entries and an
processing that the targeted node has to perform to its Bindings ordered list of binding identifiers, allowing mobile nodes to
Cache List. A mobile node may request for any of the following associate flow binding policies with the registered care-of
requests: addresses.
* 0: Add flow binding. Create a new Flow Binding with the The flow identification option defines how the mobile node can
indicated FID and include the attached Flow. A mobile node control a set of flow binding entries maintained in a home agent,
MUST NOT issue a Flow Identifier with the PRO field set to zero correspondent node, or mobility anchor points, on its behalf. The
for an existing FID. fields of the flow identification option are necessary for ordering
flow identification options, indicating the sort of action that
should be undertaken to the recipient's flow binding list of entries
or for carrying the results of such a petition.
* 1: Replace a flow binding. This request enables the mobile This specification allows mobile nodes to direct flows to a
node to replace attributes of the flow or the care-of address particular care-of address. The granularity of what constitutes a
associated with the FID. A mobile node MUST NOT issue a Flow flow depends on the flow descriptor used. As indicated earlier the
Identifier with the PRO field set to one for a non existent flow description itself is defined in another document.
FID.
* 2: Refresh a flow binding. This request allows the mobile node The remaining of this section discusses how mobile nodes can use the
to inform the receiver of the BU message that the flow binding options and sub-options defined in this document when sending binding
is still valid. This request does not modify the flow option. updates to the correspondent node, home agent or mobility anchor
A flow identification option MUST NOT contain this value in the point. In addition, refresh, deletion, and modification of bindings
PRO field for a non-existent FID. are all discussed below.
* 15: Remove a flow binding. This action enables a mobile node 5.1.1. Preferred Care-of address
to remove the Flow Binding indicated by the FID on the targeted
node. A mobile node MUST not issue a Flow Identifier with the
PRO field set to 15 for a non existent FID.
When adding a flow binding on the home agent or MAP, the mobile node Any node that supports this specification MUST maintain an ordered
MUST ensure the following: list of care-of addresses for each mobile node it maintains a list of
flow bindings for. The ordered list of care-of addresses is built
based on the BID-PRI field of the Binding Identifier option (see
Section 4.1).
* The PRO field MUST be set to indicate an Add operation. The ordered list of BIDs is used to determine how to forward a packet
to a given mobile node when the packet does not match any of the flow
binding entries defined in Section 4.4. A packet that does not match
any of the flow binding entries SHOULD be forwarded to the care-of
address identified by the BID with the highest priority i.e., lowest
BID-PRI value.
* The FID field includes a value that does not already exist in 5.2. Mobile Node Considerations
the mobile node's binding update list.
* The PRI field is set to indicate the priority of the rule in This specification allows the mobile node to maintain several
case of an overlap between rules. An overlap can occur when bindings in its home agent and to direct packets to different care-of
one flow matches multiple flow description options. addresses according to flow bindings. This section details the
mobile node operations necessary to implement this specification.
* If the Action field is set to indicate N-cast, the Binding The home agent list of flow bindings is manipulated by the mobile
Reference sub-option must be present and it must contain one or node, via flow identification and flow summary options included in
more BIDs. If the Binding Update sub-option includes only one binding update messages. Each flow binding update can add, modify,
BID, it must be pointing to a care-of address other than the refresh, or delete a given binding. More than one flow
one included in the binding update. identification options MAY be included in the same binding update but
each of them MUST include a different FID. In other words, two flow
identification options in the same message can not be about the same
flow binding.
6.1.2. Managing Flow Bindings in Correspondent nodes All flow binding state MUST be refreshed in every binding update the
mobile node sends. Any previously registered flow binding that is
not included in a given binding update will be deleted. So, any flow
bindings that are not added or modified by a flow identification
option, but have previously registered and need to be maintained MUST
be included in a flow summary option. Only one flow summary option
can be included in a given binding update.
When route optimisation is used (see RFC3775 [RFC3775]), a mobile 5.2.1. Sending BU with BID Options
node sends the BU message to the correspondent node after the return
routability test procedure. When adding flow bindings in the BU sent
to the correspondent node, the mobile node MUST ensure the following:
* The FID field includes a value that is not already stored in This specification (see Section 4.1) updates the definition of the
the binding update list with the correspondent node's address. Binding Identifier option, originally defined in
[I-D.ietf-monami6-multiplecoa]. According to this specification the
BID option includes a BID-PRI field assigning each registered care-of
address a priority, and thus placing them in an ordered list as also
described in Section 4.4.
* The PRO field is set to indicate an Add operation. Mobile nodes supporting this specification MUST use the BID option
format defined in Section 4.1. Mobiles nodes MUST also register all
care-of addresses using the updated BID option format, either in the
same BU as any flow identification options using them, or in earlier
BUs.
A mobile node can also modify or delete flow bindings in a similar 5.2.2. Sending BU with Flow Identification Options
manner to that described earlier with the home agent and MAP. When
Modifying a flow binding, the mobile node MUST ensure that the FID
used already exists. The rest of the rules for modifying flow
bindings are the same as those listed above for adding a flow
binding.
Refreshing and deleting flow bindings are done in the same manner as 5.2.2.1. Adding flow bindings
that described for the home agent and MAP with one exception: the
mobile node MUST NOT refresh or delete bindings associated with any
care-of address other than the one included in the BU message.
6.1.3. Using Alternate Care-Of Address When adding a new flow binding, a mobile node sends the flow
identification option in the binding update. The care-of address
concerned with each flow identification option in the binding update,
must be logically registered by this binding update, or must have
already been registered by the receiver of the binding update in an
earlier binding update , as defined in Section 5.2.1.
If the Alternate Care-of Address option is used in the Binding The flow identification option MUST include a unique Flow Identifier
Update, it shall indicate the care-of address to be associated with in the FID field. The FID needs only be unique for the receiver of
the Flow Identification options. The Flow Identification options the binding update and for the same sender, i.e. the same FID can be
shall contain the FID to be allocated to the Flow Binding. used across different receivers of the binding update, for the same
sender.
6.1.4. Receiving Binding Acknowledgements The FID-PRI field is set to the desired priority of the FID,
defining the order of the binding to be added in the list of flow
binding entries as defined in Section 4.4.
According to [RFC3775] all nodes are required to silently ignore The Action field is set to one of the defined action codes (see
mobility options not understood while processing Binding Updates. As Section 4.2).
such a mobile node receiving a Binding Acknowledgement in response to
the transmission of a Binding Update MUST determine if the Binding
Acknowledgement contains a copy of the 8 bytes of every Flow
Identification options included in the Binding Update. A Binding
Acknowledgement without Flow Identification option(s) would indicate
inabillity on behalf of the source node to support the extensions
presented in this document.
If a received Binding Acknowledgement contains a copy of the 8 bytes The PRO field MUST indicate an Add operation.
of each flow identification option that was sent within the Binding
Update, the status field of each flow identification option indicates
the status of the flow binding on the distant node.
6.2. Movement The Status filed is set to zero in all binding update messages.
When a MN changes its point of attachment to the Internet, its The mobile node MUST include exactly one Flow Description sub-option
Care-of address(es) may become invalid and need to be updated. All (see Section 4.2.2) describing the flow associated with the new
the flow bindings that are attached to such an old Care-of address binding.
need to be udpated with a new Care-of address. This can be achieved
by adding flow identification options in Binding Update. One flow
identification is needed per flow binding. The flow description may
not be needed if only the Care-of address is changed, and not the
filter itself. The FID must be set to the flow binding that needs to
be udpated and the PRO field MUST be set to 1 (i.e., MODIFY).
Another solution is to take advantage of the multiple care-of The mobile node MAY also include exactly one BID Reference sub-option
addresses bindings to aggregate updates; the mobile node may only (see Section 4.2.1) to associate the flow binding with a given set of
need to update the care-of address associated with the given BID. BIDs and corresponding CoAs. Depending on the Action field of the
This would avoid to send a flow identification option per flow Flow Binding Identifier option, the following rules MUST be followed
with respect to the Binding Reference sub-option:
- if the Action indicates 'Forward', a single Binding Reference
sub-option with a single BID MUST be included. This BID MUST be
associated with a single care-of address.
- if the Action indicates 'Discard', the Binding Reference sub-
option SHOULD NOT be included. If it is included it will be
ignored by the receiver.
- if the Action indicates 'n-cast', a single Binding Reference
sub-option with one or more BIDs MUST be included.
5.2.2.2. Modifying flow bindings
Flow binding modification is essentially a process where an existing
flow binding is removed from the list of flow binding entries and a
new flow binding (included in the option) is added, and given the
same FID as the flow that was removed. With this procedure the
mobile node can change the action, the priority, the BID, or the flow
description associated with a flow binding.
To modify an existing flow binding the mobile node MUST send a
binding update with a flow identification option, with the FID field
set to one of the FID values already in the list of flow binding
entries.
The PRO field MUST be set to 1, indicating a request to modify the
binding. binding.
6.3. Return Routability Procedure The FID-PRI and Action fields MUST be set to the desired values to
be implemented with this modification.
A mobile node may perform route optimization with correpondent nodes. The Status field is set to zero since this option is in a binding
Route optimization allows a mobile node to bind a care-of address to update.
a home address in order to allow the correspondent node to direct the
traffic to the current location of the mobile node. Before sending a The mobile node MAY include exactly one Flow Description sub-option
Binding Update to correspondent node, the Return Routability (see Section 4.2.2) describing the modified flow to be associated
Procedure needs to be performed between the mobile node and the with the binding.
correspondent node.
The mobile node MAY also include exactly one BID Reference sub-option
(see Section 4.2.1) to associate the existing binding with a new set
of CoAs. The rules regarding the Binding Reference sub-option in
this case are identical to those described from flow binding addition
in Section 5.2.2.1 .
Note that it is also possible for the mobile node to effectively
modify the effect of a flow binding entry without actually changing
the entry itself. This can be done by changing the CoA associated
with a given BID, which is a process defined in detail in
[I-D.ietf-monami6-multiplecoa].
5.2.3. Sending BU with a Flow Summary Option
When the mobile node sends a binding update it MUST refresh all flow
bindings it wants to maintain even if it does not want to change any
of their parameters.
To refresh an existing flow binding the mobile node MUST send a
binding update with a flow summary option. The flow summary option
MUST include one or more FID fields as indicated in Section 4.3.
Each FID field included MUST be set to one of the FID values already
in the list of flow binding entries.
Any flow bindings (active or inactive) that are not included in a
binding update will be removed from the list of flow binding entries.
Note that any inactive flow bindings, i.e., flow bindings without
associated BIDs that are marked as Inactive in the list of flow
binding entries (see Section 4.4, MUST also be refreshed, or
modified, to be maintained. If they are not included in a BU they
will be removed.
5.2.4. Removing flow bindings
Removal of flow binging entries is performed implicitly by omission
of a given FID from a binding update.
To remove a flow binding the MN simply sends a binding update that
includes flow identification and flow summary options for all the
FIDs that need to be refreshed, modified, or added, and simply omits
any FIDs that need to be removed.
Note that a mobile node can also remove the BIDs associated with a
given Flow Binding, without removing the flow binding itself. The
procedure for removing a BID is defined in detail in
[I-D.ietf-monami6-multiplecoa].
When all the BIDs associated with a flow binding are removed, the
flow binding MUST be marked as inactive in the list of flow binding
entries as shown in Section 4.4. In other words the state associated
with the flow binding MUST be maintained but it does no longer affect
the mobile node's traffic. The MN can return an inactive flow
binding to the active state by using the flow binding modification
process described in Section 5.2.2.2, to associate it again with one
or more valid BIDs.
5.2.5. Receiving Binding Acknowledgements
According to [RFC3775] all nodes are required to silently ignore
mobility options not understood while processing binding updates. As
such a mobile node receiving a Binding Acknowledgement in response to
the transmission of a binding update MUST determine if the Binding
Acknowledgement contains a copy of every flow identification options
included in the binding update. A Binding Acknowledgement without
flow identification option(s), in response to a Binding Update with
flow identification option, would indicate inability (or
unwillingness) on behalf of the source node to support the extensions
presented in this document.
If a received Binding Acknowledgement contains a copy of of each flow
identification option that was sent within the binding update, the
status field of each flow identification option indicates the status
of the flow binding on the distant node.
5.2.6. Return Routability Procedure
A mobile node may perform route optimization with correspondent nodes
as defined in [RFC3775]. Route optimization allows a mobile node to
bind a care-of address to a home address in order to allow the
correspondent node to direct the traffic to the current location of
the mobile node. Before sending a Binding Update to correspondent
node, the Return Routability Procedure needs to be performed between
the mobile node and the correspondent node.
This procedure is not affected by the extensions defined in this This procedure is not affected by the extensions defined in this
document. However, since a Binding Update message is secured with document. However, since a binding update message is secured with
the key generated based on the home address and care-of address test, the key generated based on the home address and care-of address test,
a mobile node MUST NOT bind a flow to a care-of address whose keygen a mobile node MUST NOT bind a flow to a care-of address whose keygen
token (see RFC3775 [RFC3775]) was not used to generate the key for token (see RFC3775 [RFC3775]) was not used to generate the key for
securing the Binding Update. This limitation prohibits the sender securing the Binding Update. This limitation prohibits the sender
from requesting the n-cast action before having registered each from requesting the n-cast action before having registered each
care-of address one by one. care-of address one by one.
6.4. Returning Home 5.3. HA, MAP, and CN Considerations
Whenever a mobile node acquires a point of attachment to the home This specification allows the home agents, mobility anchor points,
network and wishes to abolish all Flow Bindings associated with the and corresponding nodes to maintain several bindings for a given home
respective home address, it is required to act as described in address and to direct packets to different care-of addresses
Section 11.5.4 of RFC3775 [RFC3775]. This will cause the home agent according to flow bindings. This section details the home agent
to remove all bindings that are linked to the home address, including operations necessary to implement this specification. These
the flow bindings. operations are identical for MAPs and CNs unless otherwise stated.
7. Applicability to Route Optimization Note that route optimization is only defined for mobile nodes (MIPv6
[RFC3775]), and not mobile routers (NEMOv6 [RFC3963]). Thus, these
sections only apply to correspondent nodes with respect to mobile
nodes and not for mobile routers.
The route optimization is only defined for mobile nodes (RFC3775 5.3.1. Receiving BU with BID Options
[RFC3775]), and not mobile router (RFC3963 [RFC3963]). Thus, this
section does not apply to mobile routers. This section describes the
correspondent node operations.
Every correspondent node is required to maintain a Binding Cache This specification (see Section 4.1) updates the definition of the
containing records of associations between mobile node home addresses Binding Identifier option, originally defined in
and care-of addresses (bindings) as they roam away from the home [I-D.ietf-monami6-multiplecoa]. According to this specification the
network. RFC3775 [RFC3775] allows mobile nodes to register only a BID option includes a BID-PRI field assigning each registered care-of
single binding per home address with each correspondent node. address a priority, and thus placing them in an ordered list (see
Section 4.4).
This specification extends the binding cache structure, and enables Home agents receiving BUs including BID options and flow
correspondent nodes to (i) maintain multiple bindings for a given identification options MUST logically process BID options first.
home address and (ii) to associate multiple Flow Identification / This is because BID Reference sub-options included in the flow
description options with every binding, termed as Flow Binding. A identification options might refer to BIDs defined in BID options
flow matching a Flow Description should be directed to the Care-of included in the same message.
address indicated by the Flow Binding.
7.1. Receiving Binding Udpate The BID option is processed as defined in
[I-D.ietf-monami6-multiplecoa] but then the BID to care-of address
mapping is placed in an ordered list according to the BID-PRI field
of the BID option.
When a correspondant node receives a Binding Update, it first 5.3.2. Receiving BU with Flow Identification Options
performs the same operation as defined in RFC3775 [RFC3775]. If the
Binding Update is valid and contains a Flow identification option,
the correspondent node needs to check the content of the PRO field.
If the PRO field contains a value indicating a request to add a new
flow binding, the following checks are done:
* The FID field includes a value that is not already stored in When the home agent receives a binding update which includes at least
the binding update list with the correspondent node's address. one Flow Identification option, it first performs the operation
described in section 10.3.1 of RFC3775.
* The PRO field is set to indicate an Add operation. Home agents that do not support this specification will ignore the
flow identification options and all their suboption, having no effect
on the operation of the rest of the protocol.
+ The FID field needs to contain a value that does not already If the binding update is accepted, and the home agent is willing to
exist. If the FID contains a value that already exists, the support flow bindings for this MN, the home agent checks the flow
correspondent node MUST reject the option by sending that identification options.
option back in its Binding Acknowledgement with a Status
field that contains an error value.
+ If the Action field indicates a request to n-cast the flow, If more than one flow identification option in the same BU, has the
the correspondent node MUST reject the option by sending the same value in the FID field, all the flow identification options MUST
option in its binding acknowledgement with an appropriate be rejected.
error code.
+ If both the FID and Action fields are valid, the If all FID fields have different values the flow identification
correspondent node checks the flow description that must options can be processed further and in any order, as defined by the
follow the flow identification option. If all of the checks following subsections.
above indicated a valid option, the correspondent node
should add the flow binding to its binding cache.
+ The FID MUST include a value that already exists. If the 5.3.2.1. Handling Flow Binding Add Requests
FID cannot be found in the correspondent node's binding
cache, the flow identification option MUST be rejected with
an appropriate error code.
+ If the Action field indicates a request to n-cast the flow, If the PRO field of the flow identification option is set to 'Add',
the correspondent node MUST reject the option by sending the it indicates a flow binding add request.
option in its binding acknowledgement with an appropriate
error code.
+ If the Binding Reference sub-option is present, the If the FID field of the flow identification option is already present
correspondent node MUST ensure that the BID points to the in the list of flow binding entries for this mobile node, the home
care-of address in the packet, or to an already authrozied agent MUST reject this flow binding add request by copying the flow
care-of address. Otherwise the option MUST be rejected with identification option in the BA, and setting the Status field to 135
an appropriate error code. (FID already in use).
+ If all of the above checks returned a valid result, the If the flow identification option does not include a flow description
correspondent node should modify the binding as requested. sub-option, the home agent MUST again reject this request by copying
the flow identification option in the BA, and setting the Status
field to 129 (Flow identification option poorly formed).
If the PRO field in the option indicates a request to modify the If the flow identification option does include a flow description
option, the following checks must be done by the correspondent node: sub-option, but the flow description type is not supported, the home
agent MUST also reject this request by copying the flow
identification option in the BA, and setting the Status field to 137
(FD-Type not supported).
If the PRO field in the option contains a request to refresh a If the FID value is new the home agent MUST check the Action field in
binding, the correspondent node MUST ensure that the FID already combination with the Binding Reference sub-option if present.
exists. If the FID does not exist, the correspondent node MUST
reject the option by sending it back in its binding acknowledgement
with an appropriate error code in the status field. Otherwise, if
the FID exists, the correspondent node must keep it in its binding
cache. No further checks need to be done in the option.
The correspondent node should reply with a Binding Acknowledgement - if the Action indicates 'Forward'
message. This Binding Acknowlegement message must contain a copy of If the Binding reference sub-option is not included or if it is
the 8 bytes of each flow identification option that was included in included but it contains more than a single BID, the home agent
the Binding Udpate. The Status field of each Flow Identification MUST reject this flow binding add request by copying the flow
option MUST be set to an appropriate value. identification option in the BA, and setting the Status field to
129 (Flow identification option poorly formed).
8. Home Agent operations If the Binding Reference sub-option is present and includes a
single BID, but the BID is not present in the binding cache of the
mobile node the home agent MUST reject this flow binding add
request by copying the flow identification option in the BA, and
setting the Status field to TBD (BID not known).
This specification allows the home agent to maintain several bindings If the Binding Reference sub-option is present and includes a
for a given home address and to direct packets to different care-of single BID, and the BID exists in the mobile node's binding cache,
addresses according to flow bindings. This section details the home the home agent SHOULD add a new entry in the mobile node's list of
agent operations necessary to implement this specification. flow binding entries, as defined below.
8.1. Receiving Binding Update with the Flow Identification option - if the Action indicates 'Discard',
When the home agent receives a Binding Update which includes at least Any Binding Reference sub-options that might be present SHOULD be
one Flow Identification option, it first performs the operation ignored.
described in section 10.3.1 of RFC3775. If the Binding Update is
accepted, the home agent then checks the flow identification option.
If the PRO field in the option indicates an Add operation, the
following checks must be done:
* The FID field needs to contain a value that does not already The home agent SHOULD add a new entry in the mobile node's list of
exist. If the FID contains a value that already exists, the flow binding entries, as defined below.
home agent MUST reject the option by sending that option back
in its Binding acknowledgement with a Status field that
contains an appropriate error value.
* If the FID field is valid, the home agent then checks the - if the Action indicates 'n-cast',
Action field. If the Action field contains a request for
n-cast and the Binding Reference sub-option is not included in
the option, the flow binding MUST be rejected in the binding
acknowledgement containing an error code in the Status field.
* If both of the checks above indicate valid FID and Action If the Binding reference sub-option is not included, the home
fields, the home agent checks the flow description following agent MUST reject this flow binding add request by copying the
the flow identification option, and identifies the filter that flow identification option in the BA, and setting the Status field
needs to be set up. to 129 (Flow identification option poorly formed).
* If the flow option includes an action field that requests If the Binding Reference sub-option is present and includes BIDs
n-casting, the home agent MUST check for the presence of the that are not present in the binding cache of the mobile node the
BID sub-option(s). If the sub-options are not present, the home agent MUST reject this flow binding add request by copying
flow identification option MUST be rejected as a poorly the flow identification option in the BA, and setting the Status
formatted option. If one or more BIDs are present in the BID field to TBD (BID not known).
Reference sub-option, the home agent needs to create multiple
logical entries in its binding cache. All flows matching the
one in the option would be n-cast to the care-of addresses
pointed to by the BIDs or the set of registered care-of
addresses. If only one BID were included in the Binding
Reference sub-option and it pointed to a different care-of
address from the one included in the packet, then packets
matching the flow would be bicast to those two addresses.
However, if only one BID is present and points to the same If the Binding Reference sub-option is present and includes one or
address in the BU, the n-cast is essentially pointing to one more BIDs, and the BIDs exist in the mobile node's binding cache,
address and therefore cannot be performed. Such option MAY be the home agent SHOULD add a new entry in the mobile node's list of
rejected as a poorly formatted option. flow binding entries, as defined below.
* If all of the checks above indicated a valid option, the home When the home agent decides to add an entry in the mobile node's list
agent should add the flow binding to its binding cache. of flow binding entries, as discussed above, it MUST do it according
to the following rules: The entry MUST be placed according to the
order indicated by the FID-PRI field of the flow identification
option and it MUST include:
If the PRO field in the option contains a value indicating a request the FID as a key to the entry
to modify an existing binding, the following actions must be taken:
* The FID MUST include a value that already exists. If the FID The flow description included in the corresponding sub-option
cannot be found in the home agent's binding cache, the flow
identification option MUST be rejected as a poorly formed
option.
* If the FID is valid, the home agent MUST perform the same steps the action indicated in the Action field
described above for the Add operation.
If the PRO field indicates a refresh operation, the home agent MUST the BIDs indicated in the binding reference sub-option
ensure that the FID in the option already exists. If the FID field
did not exist, the option MUST be rejected as a poorly formed option.
If the FID existed, the home agent MUST keep the current flow binding
in its binding cache.
8.2. Sending Binding Ackowledgement the entry MUST be marked as Active, as shown in Section 4.4
Upon the reception of a Binding Update, the home agent is required to 5.3.2.2. Handling flow binding Modification Requests
If the PRO field of the flow identification option is set to
'Modify', it indicates a flow binding modification request.
Note that flow binding modification is essentially a process where an
existing flow binding is removed from the list of flow binding
entries and a new flow binding (included in the option) is added, and
given the same FID as the flow that was removed.
If the value of the FID field of the flow identification option is
not present in the binding cache entries for this mobile node, the
home agent MUST reject this flow binding modify request by copying
the flow identification option in the BA, and setting the Status
field to 135 (FID not found).
If the value of the FID field is present in the mobile nodes list of
flow binding entries, the home agent SHOULD first remove the flow
binding entry identified by the FID. The home agent then SHOULD
processes this flow identification option as defined in
Section 5.3.2.1.
5.3.3. Receiving BU with Flow Summary Option
When the home agent receives a binding update which includes a Flow
Summary option, it first performs the operation described in section
10.3.1 of RFC3775. Binding update messages including more than one
flow summary option MUST be rejected.
Home agents that do not support this specification will ignore the
flow summary option, having no effect on the operation of the rest of
the protocol.
If the value of any of the FID fields included in the flow summary
option is not present in the list of flow binding entries for this
mobile node, the home agent MUST reject this flow binding modify
request by including a flow identification option in the BA, and
setting the FID field in the value of the FID that is not found and
the Status field to 135 (FID not found).
If the value of the FID field is present in the mobile nodes list of
slow binding entries the, home agent SHOULD refresh the binding entry
identified by the FID without changing any of the other parameters
associated with it.
5.3.4. Handling flow binding Removals
Removal of flow bindings is performed implicitly by omission of a
given FID from a binding update.
When a valid binding update is received, any registered FIDs that are
not explicitly referred to in a flow identification option or in a
flow summary option, MUST be removed from the list of flow binding
entries for the mobile node.
5.3.5. Sending Binding Acknowledgements
Upon the reception of a binding update, the home agent is required to
send back a Binding Acknowledgment. The status code in the Binding send back a Binding Acknowledgment. The status code in the Binding
Acknowledgement must be set as recommanded in [RFC3775] and is not Acknowledgement must be set as recommended in [RFC3775]. This status
modified by the extension defined in this specification. 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 the flow bindings.
binding.
In order to inform about the status of the flow binding that was In order to inform the mobile node about the status of the flow
requested by a mobile node, a flow identification option MUST be set binding(s) requested by a mobile node, flow identification options
in the Binding Acknowledgement message. The home agent must copy the MUST be included in the Binding Acknowledgement message.
8 octets of each Flow Identification option received in the Binding Specifically, the home agent MUST copy each flow identification
Update and set the status code to an approriate value. Each option option received in the binding update and set its status code to an
must be included in the Binding Acknowledgement message. appropriate value. If an operation requested in a flow
identification option by a mobile node is performed successfully by
the home agent, the status field on the copied flow identification
option in the BA, SHOULD be set to 0 (Flow binding successful),
otherwise it SHOULD be set to one of the rejection codes defined.
Section 5.3.2 identifies a number of cases where specific error codes
should be used.
8.3. Deleting an entry in the binding cache Home agents that support this specification MAY refuse to maintain
flow bindings by setting the status field of any flow identification
options to 130 (Administratively prohibited), or by just ignoring all
the flow binding options.
A home agent might delete an entry in its binding cache for two Note that BID options and their Status field are handled as defined
reasons: either an entry expires, or the MN explicitly requests the in [I-D.ietf-monami6-multiplecoa].
home agent to remove a specific entry. If an entry is going to
expire, the home agent SHOULD send a Binding Refresh Advice.
8.3.1. Removing Flow Bindings 5.3.6. Packet Processing
If the home agent receives a valid Binding Update with a flow This section defines packet processing rules according to this
Identification option where the PRO field is set to 15 (Remove), the specification. This specification does not change any of the packet
home agent MUST remove the corresponding entry. The home agent looks interception rules defined in [RFC3775], and
up the entry corresponding to the FID of the Binding Update. If an [I-D.ietf-mext-nemo-v4traversal]. These rules apply to HAs, MAPs,
entry is found, the entry is removed from the Binding cache and a and CNs, as part of the routing process for any packet with
Binding Acknowledgement is sent back to the mobile node with a destination address set to a valid home address of the mobile node.
success value for the status of the flow Identification option (see For nodes other than CNs this also applies to packets with
section Section 8.2. This operation does not modify any other destination address set to an address under any of the registered
binding that may appear with the same home address. If the FID is prefixes. These rules apply equally to IPv6 packets as well as to
not present in the binding cache entry for the corresponding home IPv4 packets when [I-D.ietf-mext-nemo-v4traversal].
address, the home agent MUST send back to the mobile node a Binding
Acknowledgement with error code 137 (FID not found) in the flow
identification option.
9. Applicability to Hierarchical Mobile IPv6 Before a packet is forwarded to the mobile node it MUST be matched
against the ordered list of flow bindings stored in the list of flow
binding entries for this mobile node (see Section 4.4). A match is
attempted with the flow description included in the first line
(highest order) of the table. If the packet matches the flow
description, the action defined by the action parameter of the table
SHOULD be performed.
This section describes the Mobility Anchor Point (MAP) operations. - if the Action indicates 'Forward' the packet is forwarded to the
The MAP operation is the same as the home agent operation. Flow care-of address indicated by the BID parameter in the same line of
bindings sent to the MAP are associated with the regional care-of the table.
address.
When a MAP receives a Binding Update that includes the flow - if the Action indicates 'Discard', the packet is silently
Identification option, it checks if such option is valid according to discarded
the requirements in Section 8.1. If the option is valid, the MAP
installs the flow binding associated with the flow identified by the
flow description. The lifetime of the binding is the lifetime of the
Binding Update. Once the binding is successfully installed, the MAP
sends the binding acknowledgement and includes the flow
Identification option. The MAP sets the status field to a value
indicating success.
In all cases, a flow identification option SHOULD be included in the - if the Action indicates 'n-cast', a copy of the packet is
Binding Acknowledgement to indicate success or failure of the flow forwarded to each of the care-of addresses associated with the
binding installation. BIDs indicated in the same line of the table.
10. Security considerations If the action indicated in one of the entries in the list of flow
bindings is "Discard" then, no BIDs needs to be indicated in the same
entry since the packet is not forwarded. If, however, the action
indicated in an entry of the list of flow bindings is "forward" or
"n-cast", the entry must indicated a BID. For "n-cast" if any of the
BIDs indicated does not correspond to a valid care-of address, e.g.,
the BID was deregistered then that BID has no effect on the traffic.
In other words, packets matching the flow binding are n-casted to the
other BIDs, pointing to registered care-of addresses. If none of the
BIDs pointed to in a flow binding entry is valid then the entry is
considered to be inactive (as defined in Section 4.4) and is skipped.
In other words packets should not be matched against that entry.
6. Security considerations
This draft introduces a new option that adds more granularity to the This draft introduces a new option that adds more granularity to the
Binding Update message. The new option allows the mobile node to binding update message. The new option allows the mobile node to
associate some flows to an interface and other flows to another associate some flows to one interface and other flows to another
interface. Since the flow Identification option is part of the interface. Since the flow Identification option is part of the
mobility header, it uses the same security as the Binding Update, mobility header, it uses the same security as the Binding Update,
whether it is sent to the home agent, correspondent node, or MAP. whether it is sent to the home agent, correspondent node, or MAP.
11. Acknowledgements 7. IANA Considerations
We would like to thank all authors of initial I-Ds that were merged A Type number (TBD) for Flow Identification Mobility Option and
together to create this document; in alphabetical order: C. another Type number (TBD) for Flow Summary Mobility Option has been
Castelluccia, K. ElMalki, K. Georgios, , C. Goerg, T. Noel, F.-N. registered from the space of numbers for mobility options, defined
Pavlidou. Thanks to George Tsirtsis and Vince Park for their for Mobile IPv6 [RFC3775]. This registry is available from
thorough review and input to the draft. Gabor Fekete for the http://www.iana.org under "Mobile IPv6 parameters".
analysis that led to the inclusion of the BID support. Henrik
Levkowetz for suggesting the equivalent of the CLS field to allow
other ways of describing flows.
12. Informative References A new sub-type space for the type number of the Flow Identification
Mobility Option has been created: "Flow Identification Mobility
Option Sub-Options". The suboption values 1, and 2, are defined in
this specification, and the values 16-32 are reserved for flow
description sub-options to defined in separate documents. The rest
of the sub-options are reserved and available for allocation based on
Expert Review.
[I-D.ietf-nemo-terminology] Finally, a new space for the status field of the Flow Identification
Ernst, T. and H. Lach, "Network Mobility Support Mobility Option has been created: "Flow Identification Mobility
Terminology", draft-ietf-nemo-terminology-06 (work in Option Status codes". Values 0, 128-130 and 135-139 are defined in
progress), November 2006. this specification. The rest of the values below 128 are reserved
for accept codes, and values from 128 and above are reserved for
reject codes.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 Similar to the procedures specified for Mobile IPv6 [RFC3775] number
(IPv6) Specification", RFC 2460, December 1998. spaces, future allocations from the two number spaces require Expert
Review [RFC5226].
[RFC2702] "", 2005. 8. Contributors
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", We would like to explicitly acknowledge the following person who co-
RFC 3753, June 2004. authored one of the documents used as source material for this
document.
Nikolaus A. Fikouras, niko@comnets.uni-bremen.de
9. Acknowledgements
We would also like to acknowledge the following people in
alphabetical order: C. Castelluccia, K. ElMalki, K. Georgios, , C.
Goerg, T. Noel, F.-N. Pavlidou, V. Park. Gabor Fekete for the
analysis that led to the inclusion of the BIDRef sub-option. Henrik
Levkowetz for suggesting support for other ways of describing flows.
10. References
10.1. Normative References
[I-D.ietf-mext-nemo-v4traversal]
Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", draft-ietf-mext-nemo-v4traversal-10 (work in
progress), April 2009.
[I-D.ietf-monami6-multiplecoa]
Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-13 (work in progress),
April 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [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.
[RFC4140] "RF", 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008.
10.2. Informative References
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.
Authors' Addresses Authors' Addresses
Hesham Soliman (editor) Hesham Soliman
Elevate Technologies Elevate Technologies
Email: hesham@elevatemobile.com Email: hesham@elevatemobile.com
George
Qualcomm
Email: tsirtsis@gmail.com
Nicolas Montavont Nicolas Montavont
Ecole Nationale Superieure des telecommunications de 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@enst-bretagne.fr Email: nicolas.montavont@telecom-bretagne.eu
URI: http://www-r2.u-strasbg.fr/~montavont/ URI: http://www.rennes.enst-bretagne.fr/~nmontavo//
Nikolaus A. Fikouras Gerardo
University of Bremen Qualcomm
ComNets-ikom,University of Bremen.
Otto-Hahn-Allee NW 1
Bremen, Bremen 28359
Germany
Phone: +49-421-218-8264 Email: gerardog@qualcomm.com
Fax: +49-421-218-3601
Email: niko@comnets.uni-bremen.de
URI: http://www.comnets.uni-bremen.de
Koojana Kuladinithi Koojana Kuladinithi
University of Bremen University of Bremen
ComNets-ikom,University of Bremen. ComNets-ikom,University of Bremen.
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
 End of changes. 185 change blocks. 
741 lines changed or deleted 868 lines changed or added

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