draft-ietf-mext-flow-binding-06.txt   draft-ietf-mext-flow-binding-07.txt 
IETF MEXT Working Group H. Soliman IETF MEXT Working Group G. Tsirtsis
Internet-Draft Elevate Technologies Internet-Draft Qualcomm
Intended status: Standards Track G. Tsirtsis Updates: 5648 (if approved) H. Soliman
Expires: September 2, 2010 Qualcomm Intended status: Standards Track Elevate Technologies
N. Montavont Expires: February 17, 2011 N. Montavont
IT/TB IT/TB
G. Giaretta G. Giaretta
Qualcomm Qualcomm
K. Kuladinithi K. Kuladinithi
University of Bremen University of Bremen
March 1, 2010 August 16, 2010
Flow Bindings in Mobile IPv6 and NEMO Basic Support Flow Bindings in Mobile IPv6 and NEMO Basic Support
draft-ietf-mext-flow-binding-06.txt draft-ietf-mext-flow-binding-07.txt
Abstract Abstract
This document introduces extensions to Mobile IPv6 that allow nodes This document introduces extensions to Mobile IPv6 that allow nodes
to bind one or more flows to a care-of address. These extensions to bind one or more flows to a care-of address. These extensions
allow multihomed nodes to instruct home agents and other Mobile IPv6 allow multihomed nodes to instruct home agents and other Mobile IPv6
entities to direct inbound flows to specific addresses. entities to direct inbound flows to specific addresses.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 This Internet-Draft will expire on February 17, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 2, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 15 skipping to change at page 2, line 9
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 8 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 8
4.1. Definition Update for Binding Identifier Mobility 4.1. Definition Update for Binding Identifier Mobility
Option . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Option . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Flow Identification Mobility Option . . . . . . . . . . . 8 4.2. Flow Identification Mobility Option . . . . . . . . . . . 8
skipping to change at page 3, line 35 skipping to change at page 2, line 41
5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 22 5.2.3. Sending BU with a Flow Summary Option . . . . . . . . 22
5.2.4. Removing flow bindings . . . . . . . . . . . . . . . . 23 5.2.4. Removing flow bindings . . . . . . . . . . . . . . . . 23
5.2.5. Returning Home . . . . . . . . . . . . . . . . . . . . 23 5.2.5. Returning Home . . . . . . . . . . . . . . . . . . . . 23
5.2.6. Receiving Binding Acknowledgements . . . . . . . . . . 23 5.2.6. Receiving Binding Acknowledgements . . . . . . . . . . 23
5.2.7. Return Routability Procedure . . . . . . . . . . . . . 24 5.2.7. Return Routability Procedure . . . . . . . . . . . . . 24
5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 24 5.3. HA, MAP, and CN Considerations . . . . . . . . . . . . . . 24
5.3.1. Handling Binding Identifier Mobility Options . . . . . 24 5.3.1. Handling Binding Identifier Mobility Options . . . . . 24
5.3.2. Handling Flow Identification Mobility Options . . . . 25 5.3.2. Handling Flow Identification Mobility Options . . . . 25
5.3.3. Handling Flow Summary Mobility Option . . . . . . . . 28 5.3.3. Handling Flow Summary Mobility Option . . . . . . . . 28
5.3.4. Flow Binding Removals . . . . . . . . . . . . . . . . 28 5.3.4. Flow Binding Removals . . . . . . . . . . . . . . . . 28
5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 28 5.3.5. Sending Binding Acknowledgements . . . . . . . . . . . 29
5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 29 5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 29
6. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 31 6. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 32
7. Security considerations . . . . . . . . . . . . . . . . . . . 32 7. Security considerations . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . . 38 11.1. Normative References . . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . . 38 11.2. Informative References . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
Mobile IPv6 [RFC3775], DSMIPv6 [RFC5555] and NEMO Basic Support Mobile IPv6 [RFC3775], DSMIPv6 [RFC5555] and NEMO Basic Support
skipping to change at page 7, line 11 skipping to change at page 7, line 11
In the rest of the document, the term "mobile node" is used to In the rest of the document, the term "mobile node" is used to
designate either a mobile node as defined in [RFC3775] and [RFC5648], designate either a mobile node as defined in [RFC3775] and [RFC5648],
or a mobile router as defined in [RFC3963] unless stated otherwise. or a mobile router as defined in [RFC3963] unless stated otherwise.
3. Terminology 3. Terminology
Terms used in this document are defined in [RFC3753] and [RFC4885]. Terms used in this document are defined in [RFC3753] and [RFC4885].
The following terms are also used in this document: The following terms are also used in this document:
Flow: A flow is a sequence of packets for which the MN desires Flow: A flow is a sequence of packets for which the MN desires
special handling either by the HA, the CN or the MAP. special handling either by the Home Agent (HA), the Corresponding
Node (CN) or the (Mobility Anchor Point) MAP.
Traffic Selector: One or more parameters that can be matched Traffic Selector: One or more parameters that can be matched
against fields in the packet's headers for the purpose of against fields in the packet's headers for the purpose of
classifying a packet. Examples of such parameters include the classifying a packet. Examples of such parameters include the
source and destination IP addresses, transport protocol number, source and destination IP addresses, transport protocol number,
the source and destination port numbers and other fields in IP and the source and destination port numbers and other fields in IP and
higher layer headers. higher layer headers.
Flow binding: It consists of a traffic selector, and an action. Flow binding: It consists of a traffic selector, and an action.
IP packets from one or more flows that match the traffic selector IP packets from one or more flows that match the traffic selector
skipping to change at page 8, line 33 skipping to change at page 8, line 33
: IPv4 or IPv6 care-of address (CoA) : : IPv4 or IPv6 care-of address (CoA) :
+ + + +
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 1: The Binding Identifier Mobility option Figure 1: The Binding Identifier Mobility option
BID-PRI BID-PRI
This is a 7-bit unsigned integer placing each BID to a relative This is a 7-bit unsigned integer placing each BID to a relative
priority with other registered BIDs. Value '0' is reserved and priority with other registered BIDs. Value '0' is reserved and
SHOULD NOT be used. A lower number in this field indicates a MUST NOT be used. A lower number in this field indicates a
higher priority, while BIDs with the same BID-PRI value have higher priority, while BIDs with the same BID-PRI value have
equal priority meaning that, the BID used is an implementation equal priority meaning that, the BID used is an implementation
issue. This is consistent with current practice in packet issue. This is consistent with current practice in packet
classifiers. classifiers.
4.2. Flow Identification Mobility Option 4.2. Flow Identification Mobility Option
The flow identification mobility option is a new mobility option The flow identification mobility option is a new mobility option
[RFC3775] and it is included in the binding update and [RFC3775] and it is included in the binding update and
acknowledgement messages. This option contains information that acknowledgement messages. This option contains information that
skipping to change at page 9, line 31 skipping to change at page 9, line 31
Option Len Option Len
Length of the option in octets as per [RFC3775]. Length of the option in octets as per [RFC3775].
FID FID
The Flow Identifier field is a 16-bit unsigned integer that The Flow Identifier field is a 16-bit unsigned integer that
includes the unique identifier for the flow binding. This includes the unique identifier for the flow binding. This
field is used to refer to an existing flow binding or to create field is used to refer to an existing flow binding or to create
a new flow binding. The value of this field is set by the a new flow binding. The value of this field is set by the
mobile node. FID = 0 is reserved and SHOULD NOT be used. mobile node. FID = 0 is reserved and MUST NOT be used.
FID-PRI FID-PRI
This is an 8-bit unsigned priority field to indicate the This is an 8-bit unsigned priority field to indicate the
priority of a particular option. This field is needed in cases priority of a particular option. This field is needed in cases
where two different flow descriptions in two different options where two different flow descriptions in two different options
overlap. The priority field decides which policy should be in overlap. The priority field decides which policy should be in
those cases. A lower number in this field indicates a higher those cases. A lower number in this field indicates a higher
priority. Value '0' is reserved and SHOULD NOT be used. FID- priority. Value '0' is reserved and MUST NOT be used. FID-PRI
PRI MUST be unique to each of the flows pertaining to a given MUST be unique to each of the flows pertaining to a given MN.
MN.
Action Action
This 8-bit unsigned integer field specifies the action that This 8-bit unsigned integer field specifies the action that
needs to be taken by the receiver of the binding update needs to be taken by the receiver of the binding update
containing the flow identification option. The details of containing the flow identification option. The details of
these requests are discussed below. The following values are these requests are discussed below. The following values are
reserved for the Action field in this option: reserved for the Action field in this option:
0 Reserved and SHOULD NOT be used 0 Reserved and MUST NOT be used
1 'Discard'. This value indicates a request to discard all 1 'Discard'. This value indicates a request to discard all
packets in the flow described by the option. No BIDs are packets in the flow described by the option. No BIDs are
associated with this Action. Care should be taken when associated with this Action. Care should be taken when
using this Action as it will lead to disrupting applications using this Action as it will lead to disrupting applications
communication. Implementations may consider notifying communication. Implementations may consider notifying
impacted applications in mobile nodes. impacted applications in mobile nodes.
2 'Forward'. This value indicates a request to send the 2 'Forward'. This value indicates a request to send the
flow to one or more addresses indicated in the binding flow to one or more addresses indicated in the binding
skipping to change at page 10, line 30 skipping to change at page 10, line 30
packets are replicated and forwarded to all of the indicated packets are replicated and forwarded to all of the indicated
CoAs. Care should be taken when multiple BIDs are used in CoAs. Care should be taken when multiple BIDs are used in
combination with the 'Forward' action as some transport combination with the 'Forward' action as some transport
layers may not be able to handle packet duplication and this layers may not be able to handle packet duplication and this
can affect their performance. can affect their performance.
3-255 Reserved for future use 3-255 Reserved for future use
Rsvd Rsvd
This field is unused. It SHOULD be set to zero by the sender This field is unused. It MUST be set to zero by the sender and
and ignored by the receiver. ignored by the receiver.
Status Status
This 8-bit unsigned integer field indicates the success or This 8-bit unsigned integer field indicates the success or
failure of the flow binding operation for the particular flow failure of the flow binding operation for the particular flow
in the option. This field is not relevant to the binding in the option. This field is not relevant to the binding
update message as a whole or to other flow identification update message as a whole or to other flow identification
options. This field is only relevant when included in the options. This field is only relevant when included in the
Binding Acknowledgement message and must be ignored in the Binding Acknowledgement message and must be ignored in the
binding update message. The following values are reserved for binding update message. The following values are reserved for
skipping to change at page 11, line 39 skipping to change at page 11, line 39
| Sub-Opt Type |Sub-Opt Length | Sub-Option Data... | Sub-Opt Type |Sub-Opt Length | Sub-Option Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flow Identification Sub-Option format Figure 3: Flow Identification Sub-Option format
Sub-opt Type Sub-opt Type
8-bit unsigned integer indicating the sub-option Type. When 8-bit unsigned integer indicating the sub-option Type. When
processing a flow identification mobility option containing an processing a flow identification mobility option containing an
option for which the sub-option Type value is not recognized by option for which the sub-option Type value is not recognized by
the receiver, the receiver MUST quietly ignore and skip over the receiver, the receiver MUST silently ignore and skip over
the option, correctly handling any remaining sub-options in the the option, correctly handling any remaining sub-options in the
same option. same option.
Sub-opt Len Sub-opt Len
8-bit unsigned integer, representing the length in octets of 8-bit unsigned integer, representing the length in octets of
the flow identification sub-option. This field indicates the the flow identification sub-option. This field indicates the
length of the sub-option not including the Sub-opt Type and length of the sub-option not including the Sub-opt Type and
Sub-opt Length fields. Note that Sub-opt Type '0' Sub-opt Length fields. Note that Sub-opt Type '0'
(Section 4.2.1.1) is a special case that does not take a Sub- (Section 4.2.1.1) is a special case that does not take a Sub-
skipping to change at page 13, line 42 skipping to change at page 13, line 42
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 mobility option. A node MUST be included in the flow identification mobility option. A node MUST
NOT include more than one binding reference sub-options in a given NOT include more than one binding reference sub-options in a given
flow binding identification option. The binding reference sub-option flow binding identification option. The binding reference sub-option
includes one or more BIDs defined in MCoA [RFC5648]. When this sub- includes one or more BIDs defined in MCoA [RFC5648]. When this sub-
option is included in the flow identification mobility option it option is included in the flow identification mobility option it
associates the flow described with one or more registered BIDs. associates the flow described with one or more registered BIDs.
When binding a flow using this sub-option, the binding identifier When binding a flow using this sub-option, the binding identifier
mobility option, defined in [RFC5648], MUST be included in either the mobility option, defined in [RFC5648], MUST be included in either the
same or an earlier BU. The binding reference sub-option is shown same or an earlier Binding Update (BU). The binding reference sub-
below. The alignment requirement for this sub-option is 2n. option is shown below. The alignment requirement for this sub-option
is 2n.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-opt Type | Sub-Opt Len | BID | |Sub-opt Type | Sub-Opt Len | BID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BID ........ | BID ........
+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-
Figure 4: The Binding Reference sub-option Figure 4: The Binding Reference sub-option
Sub-opt Type Sub-opt Type
2 2
Sub-opt Len Sub-opt Len
Variable Variable
skipping to change at page 15, line 8 skipping to change at page 15, line 16
3 3
Sub-opt Len Sub-opt Len
variable variable
TS Format TS Format
An 8-bit unsigned integer indicating the Traffic Selector Format. An 8-bit unsigned integer indicating the Traffic Selector Format.
Value "0" is reserved and SHOULD NOT be used. Value "0" is reserved and MUST NOT be used.
Reserved Reserved
An 8-bit reserved field. It SHOULD be set to zero by the sender An 8-bit reserved field. It MUST be set to zero by the sender and
and ignored by the receiver. ignored by the receiver.
Traffic Selector Traffic Selector
A variable length field, the format and content of which is out of A variable length field, the format and content of which is out of
scope for this specification. scope for this specification. The traffic selector defined in
[I-D.ietf-mext-binary-ts] is mandatory to implement.
4.2.2. Flow Summary Mobility Option 4.2.2. Flow Summary Mobility Option
The flow summary mobility option is a new mobility option [RFC3775], The flow summary mobility option is a new mobility option [RFC3775],
which includes one or more flow identifiers (FIDs) for the purpose of which includes one or more flow identifiers (FIDs) for the purpose of
refreshing their state. A node MUST NOT include more than one flow refreshing their state. A node MUST NOT include more than one flow
summary mobility option in a given binding update message. The summary mobility option in a given binding update message. The
alignment requirement for this option is 2n. alignment requirement for this option is 2n.
0 1 2 3 0 1 2 3
skipping to change at page 20, line 33 skipping to change at page 20, line 33
5.2.1. Sending BU with BID Options 5.2.1. Sending BU with BID Options
This specification (see Section 4.1) updates the definition of the This specification (see Section 4.1) updates the definition of the
binding identifier mobility option, originally defined in [RFC5648]. binding identifier mobility option, originally defined in [RFC5648].
According to this specification the BID option includes a BID-PRI According to this specification the BID option includes a BID-PRI
field assigning each registered care-of address a priority, and thus field assigning each registered care-of address a priority, and thus
placing them in an ordered list as also described in Section 4.3. placing them in an ordered list as also described in Section 4.3.
To ensure backwards compatibility with [RFC5648] for the purpose of To ensure backwards compatibility with [RFC5648] for the purpose of
this specification the field BID-PRI SHOULD NOT be set to zero. this specification the field BID-PRI MUST NOT be set to zero.
Receiver implementation of this specification will take a BID-PRI Receiver implementation of this specification will take a BID-PRI
field of value zero as an indication that this is a BID option of the field of value zero as an indication that this is a BID option of the
format defined in [RFC5648]. format defined in [RFC5648].
Mobile nodes supporting this specification MUST use the BID option Mobile nodes supporting this specification MUST use the BID option
format defined in Section 4.1. Mobile nodes MUST also register all format defined in Section 4.1. Mobile nodes MUST also register all
care-of addresses using the updated BID option format, either in the care-of addresses using the updated BID option format, either in the
same BU as any flow identification mobility options using them, or in same BU as any flow identification mobility options using them, or in
earlier BUs. earlier BUs.
skipping to change at page 27, line 36 skipping to change at page 27, line 36
The home agent MUST: The home agent MUST:
Change the priority of the entry according to the FID-PRI field of Change the priority of the entry according to the FID-PRI field of
the flow identification mobility option. the flow identification mobility option.
Change the action associated with the entry according to the Change the action associated with the entry according to the
Action field of the flow identification mobility option. Action field of the flow identification mobility option.
Since this flow identification mobility option is designed to update Since this flow identification mobility option is designed to update
an existing entry it may not include a traffic selector sub-option. an existing entry it may or may not include a traffic selector sub-
option.
If a traffic selector sub-option is not included in the flow If a traffic selector sub-option is not included in the flow
identification mobility option, then the traffic selector already identification mobility option, then the traffic selector already
associated with entry MUST be maintained, associated with entry MUST be maintained,
otherwise the traffic selector in the entry MUST be replaced by otherwise the traffic selector in the entry MUST be replaced by
the traffic selector in the sub-option. the traffic selector in the sub-option.
Like Section 5.3.2.1, if the Action field in the flow identification Like Section 5.3.2.1, if the Action field in the flow identification
mobility option is set to 'Discard' if a binding reference sub-option mobility option is set to 'Discard' if a binding reference sub-option
is included in the option, it SHOULD be ignored; and any BIDs is included in the option, it SHOULD be ignored; and any BIDs
associated with the existing flow binding entry SHOULD be removed. associated with the existing flow binding entry SHOULD be removed.
Unlike Section 5.3.2.1, however, if the Action field in the flow Unlike Section 5.3.2.1, however, if the Action field in the flow
identification mobility option is set to 'Forward', and since this identification mobility option is set to 'Forward', and since this
flow identification mobility option is designed to update an existing flow identification mobility option is designed to update an existing
entry, it may not include a binding reference sub-option. entry, it may or may not include a binding reference sub-option.
If a binding reference sub-option is not included in the flow If a binding reference sub-option is not included in the flow
identification mobility option, then the BIDs already associated identification mobility option, then the BIDs already associated
with entry MUST be maintained, with entry MUST be maintained,
otherwise the BIDs in the entry MUST be replaced by the BIDs in otherwise the BIDs in the entry MUST be replaced by the BIDs in
the sub-option. the sub-option.
5.3.3. Handling Flow Summary Mobility Option 5.3.3. Handling Flow Summary Mobility Option
When the home agent receives a binding update which includes a flow When the home agent receives a binding update which includes a flow
summary mobility option, it first performs the operation described in summary mobility option, it first performs the operation described in
section 10.3.1 of RFC3775. Binding update messages including more section 10.3.1 of RFC3775. Binding update messages including more
than one flow summary mobility option MUST be rejected. A de- than one flow summary mobility option MUST be rejected.
registration binding update (with a zero lifetime) would result in
deleting all bindings, including all flow bindings regardless of the An [RFC3775] de-registration binding update (with a zero lifetime)
presence of the flow summary mobility option. would result in deleting all bindings, including all flow bindings
regardless of the presence of the flow summary mobility option. A
binding update (with a zero lifetime) would result in deleting all
bindings, including all flow bindings regardless of the presence of
the flow summary mobility option. A specific binding de-
registration, however, as defined in [RFC5648] (with lifetime of zero
and one or mobe Binding Identifier mobility options identifying
specific BIDs)does not remove all the bindings for the MN and thus it
SHOULD include a Flow Summary Mobility Option to maintain the flow
bindings that need to be preserved.
If the value of any of the FID fields included in the flow summary If the value of any of the FID fields included in the flow summary
mobility option is not present in the list of flow binding entries mobility option is not present in the list of flow binding entries
for this mobile node, the home agent MUST reject this flow binding for this mobile node, the home agent MUST reject this flow binding
refresh by including a flow identification mobility option in the BA refresh by including a flow identification mobility option in the BA
for each FID that is not found, and by setting the FID field to the for each FID that is not found, and by setting the FID field to the
value of the FID that is not found and the Status field to the value value of the FID that is not found and the Status field to the value
defined for "FID not found" in Section 4.2. defined for "FID not found" in Section 4.2.
If the value of the FID field is present in the mobile nodes list of If the value of the FID field is present in the mobile nodes list of
skipping to change at page 29, line 12 skipping to change at page 29, line 22
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 recommended in [RFC3775]. This status Acknowledgement must be set as recommended in [RFC3775]. This status
code does not give information on the success or failure of flow code does not give information on the success or failure of flow
bindings. bindings.
In order to inform the mobile node about the status of the flow In order to inform the mobile node about the status of the flow
binding(s) requested by a mobile node, flow identification options binding(s) requested by a mobile node, flow identification options
SHOULD be included in the Binding Acknowledgement message. SHOULD be included in the Binding Acknowledgement message.
Specifically, the home agent SHOULD copy each flow identification Specifically, the home agent SHOULD copy each flow identification
mobility option received in the binding update and set its status mobility option received in the binding update and set its status
code to an appropriate value. If an operation requested in a flow code to an appropriate value. Note that the home agent does not need
identification option by a mobile node is performed successfully by to respond specifically regarding FIDs included in a flow summary
the home agent, the status field on the copied flow identification mobility option but only to those in flow identification mobility
mobility option in the BA, SHOULD be set to the value defined for options. If an operation requested in a flow identification option
"Flow binding successful" in Section 4.2, otherwise it SHOULD be set by a mobile node is performed successfully by the home agent, the
to one of the rejection codes also defined in Section 4.2. status field on the copied flow identification mobility option in the
Section 5.3.2 identifies a number of cases where specific error codes BA, SHOULD be set to the value defined for "Flow binding successful"
should be used. in Section 4.2, otherwise it SHOULD be set to one of the rejection
codes also defined in Section 4.2. Section 5.3.2 identifies a number
of cases where specific error codes should be used.
Home agents that support this specification MAY refuse to maintain Home agents that support this specification MAY refuse to maintain
flow bindings by setting the status field of any flow identification flow bindings by setting the status field of any flow identification
mobility options to the value defined for "Administratively mobility options to the value defined for "Administratively
prohibited" in Section 4.2, or by just ignoring all the flow binding prohibited" in Section 4.2, or by just ignoring all the flow binding
options. options.
Note that BID options and their Status field are handled as defined Note that BID options and their Status field are handled as defined
in [RFC5648]. in [RFC5648].
skipping to change at page 32, line 8 skipping to change at page 33, line 8
Section 4.2.1.4. Implementations are encouradged to keep binding Section 4.2.1.4. Implementations are encouradged to keep binding
updates to sizes below than that of the path's MTU by making full use updates to sizes below than that of the path's MTU by making full use
of BID Reference Section 4.2.1.3 and FID Summary Section 4.2.2 sub- of BID Reference Section 4.2.1.3 and FID Summary Section 4.2.2 sub-
options, which allows them to refer to already registered care-off options, which allows them to refer to already registered care-off
addresses and flows, while registering new ones in subsequent binding addresses and flows, while registering new ones in subsequent binding
update messages. update messages.
7. Security considerations 7. 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 and acknowledgement messages defined in [RFC3775], ,
associate some flows to one interface and other flows to another and [RFC5555] [RFC3963], and as such inherits the security
interface. Since the flow identification mobility option is part of considerations discussed in these documents. The new option allows
the mobility header, it uses the same security as the Binding Update, the mobile node to associate some flows to one interface and other
whether it is sent to a mobility agent, or to a correspondent node. flows to another interface. Since the flow identification mobility
option is part of the mobility header, it uses the same security as
the Binding Update, whether it is sent to a mobility agent, or to a
correspondent node.
This specification does not open up new fundamental lines of attack
on communications between the MN and its correspondent nodes.
However, it allows attacks of a finer granularity than those on the
binding update. For instance, the attacker can divert or replicate
flows of special interest to the attacker to an address of the
attacker's choosing, if the attacker is able to impersonate the MN or
modify a binding update sent by the MN. Hence it becomes doubly
critical that authentication and integrity services are applied to
binding updates.
8. IANA Considerations 8. IANA Considerations
This specification requires the following IANA assignments on This specification requires the following IANA assignments on
existing namespaces as well as the creation of some new namespaces. existing namespaces as well as the creation of some new namespaces.
1) New Mobility Options [RFC3775]: This registry is available from 1) New Mobility Options [RFC3775]: This registry is available from
http://www.iana.org under "Mobile IPv6 parameters". The following http://www.iana.org under "Mobile IPv6 parameters". The following
type numbers need to be assigned for: type numbers need to be assigned for:
skipping to change at page 38, line 32 skipping to change at page 39, line 32
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009. Routers", RFC 5555, June 2009.
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration", and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009. RFC 5648, October 2009.
11.2. Informative References 11.2. Informative References
[I-D.ietf-mext-binary-ts]
Tsirtsis, G., Giaretta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings",
draft-ietf-mext-binary-ts-04 (work in progress),
February 2010.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999. RFC 2702, September 1999.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007. Terminology", RFC 4885, July 2007.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008. Management", RFC 5380, October 2008.
Authors' Addresses Authors' Addresses
Hesham Soliman
Elevate Technologies
Email: hesham@elevatemobile.com
George Tsirtsis George Tsirtsis
Qualcomm Qualcomm
Email: tsirtsis@qualcomm.com Email: tsirtsis@qualcomm.com
Hesham Soliman
Elevate Technologies
Email: hesham@elevatemobile.com
Nicolas Montavont Nicolas Montavont
Institut Telecom / Telecom Bretagne Institut Telecom / Telecom Bretagne
2, rue de la chataigneraie 2, rue de la chataigneraie
Cesson Sevigne 35576 Cesson Sevigne 35576
France France
Phone: (+33) 2 99 12 70 23 Phone: (+33) 2 99 12 70 23
Email: nicolas.montavont@telecom-bretagne.eu Email: nicolas.montavont@telecom-bretagne.eu
URI: http://www.rennes.enst-bretagne.fr/~nmontavo// URI: http://www.rennes.enst-bretagne.fr/~nmontavo//
 End of changes. 31 change blocks. 
70 lines changed or deleted 100 lines changed or added

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