draft-ietf-mext-flow-binding-08.txt   draft-ietf-mext-flow-binding-09.txt 
IETF MEXT Working Group G. Tsirtsis IETF MEXT Working Group G. Tsirtsis
Internet-Draft Qualcomm Internet-Draft Qualcomm
Updates: 5648 (if approved) H. Soliman Updates: 5648 (if approved) H. Soliman
Intended status: Standards Track Elevate Technologies Intended status: Standards Track Elevate Technologies
Expires: February 17, 2011 N. Montavont Expires: February 18, 2011 N. Montavont
IT/TB IT/TB
G. Giaretta G. Giaretta
Qualcomm Qualcomm
K. Kuladinithi K. Kuladinithi
University of Bremen University of Bremen
August 16, 2010 August 17, 2010
Flow Bindings in Mobile IPv6 and NEMO Basic Support Flow Bindings in Mobile IPv6 and NEMO Basic Support
draft-ietf-mext-flow-binding-08.txt draft-ietf-mext-flow-binding-09.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
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on February 17, 2011. This Internet-Draft will expire on February 18, 2011.
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
skipping to change at page 3, line 5 skipping to change at page 3, line 5
5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 29 5.3.6. Packet Processing . . . . . . . . . . . . . . . . . . 29
6. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 32 6. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 32
7. Security considerations . . . . . . . . . . . . . . . . . . . 33 7. Security considerations . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 37
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . . 39 11.1. Normative References . . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . . 39 11.2. Informative References . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
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 5, line 44 skipping to change at page 5, line 44
headers. This specification, however, does not define traffic headers. This specification, however, does not define traffic
selectors and it is assumed that one or more ways of defining traffic selectors and it is assumed that one or more ways of defining traffic
selectors are going to be defined in other specifications. This selectors are going to be defined in other specifications. This
specification, however, does define the traffic selector sub-option specification, however, does define the traffic selector sub-option
format to be used for any defined traffic selectors. format to be used for any defined traffic selectors.
Using the flow identifier option introduced in this specification a Using the flow identifier option introduced in this specification a
mobile node / mobile router can bind one or more flows to a care-of mobile node / mobile router can bind one or more flows to a care-of
address while maintaining the reception of other flows on another address while maintaining the reception of other flows on another
care-of address. The mobile node / mobile router assembles the flow care-of address. The mobile node / mobile router assembles the flow
binding request based local policies, link characteristics and the binding request based on local policies, link characteristics and the
types of applications running at the time. Such policies are outside types of applications running at the time. Such policies are outside
the scope of this document. the scope of this document.
It should be noted that the flow identification mobility option can It should be noted that the flow identification mobility option can
be associated with any binding update, whether it is sent to a be associated with any binding update, whether it is sent to a
mobility agent or a correspondent node. mobility agent or a correspondent node.
Note that per-packet load balancing may have negative impacts on TCP Note that per-packet load balancing may have negative impacts on TCP
congestion avoidance mechanisms as it is desirable to maintain order congestion avoidance mechanisms as it is desirable to maintain order
between packets belonging to the same TCP connection. This behaviour between packets belonging to the same TCP connection. This behaviour
is specified in [RFC2702]. Other negative impacts are also foreseen is specified in [RFC2702]. Other negative impacts are also foreseen
for other types of real time connections due to the potential for other types of real time connections due to the potential
variations in round trip time between packets. Moreover, per-packet variations in round trip time between packets. Moreover, per-packet
load-balancing will negatively affect traffic with anti-reply load-balancing will negatively affect traffic with anti-replay
protection mechanisms. Hence, per-packet load balancing is not protection mechanisms. Hence, per-packet load balancing is not
envisioned in this specification. envisioned in this specification.
In the rest of the document, the term "mobile node" is used to In the rest of the document, the term "mobile node" is used to
designate either a mobile node as defined in [RFC3775] and [RFC5648], designate either a mobile node as defined in [RFC3775] and [RFC5648],
or a mobile router as defined in [RFC3963] unless stated otherwise. or a mobile router as defined in [RFC3963] unless stated otherwise.
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].
skipping to change at page 9, line 38 skipping to change at page 9, line 38
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 MUST 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
those cases. A lower number in this field indicates a higher executed in those cases. A lower number in this field
priority. Value '0' is reserved and MUST NOT be used. FID-PRI indicates a higher priority. Value '0' is reserved and MUST
MUST be unique to each of the flows pertaining to a given MN. NOT be used. FID-PRI MUST be unique to each of the flows
pertaining to a given MN. In other words, two FIDs MUST NOT be
associated with the same FID-PRI value
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 MUST NOT be used 0 Reserved and MUST NOT be used
skipping to change at page 11, line 40 skipping to change at page 11, line 42
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Flow Identification Sub-Option format Figure 3: Flow Identification Sub-Option format
Sub-opt Type Sub-opt Type
8-bit unsigned integer indicating the sub-option Type. When 8-bit unsigned integer indicating the sub-option Type. When
processing a flow identification mobility option containing an processing a flow identification mobility option containing an
option for which the sub-option Type value is not recognized by option for which the sub-option Type value is not recognized by
the receiver, the receiver MUST silently ignore and skip over the receiver, the receiver MUST silently ignore and skip over
the option, correctly handling any remaining sub-options in the the sub-option, correctly handling any remaining sub-options in
same option. the same option.
Sub-opt Len Sub-opt Len
8-bit unsigned integer, representing the length in octets of 8-bit unsigned integer, representing the length in octets of
the flow identification sub-option. This field indicates the the flow identification sub-option. This field indicates the
length of the sub-option not including the Sub-opt Type and length of the sub-option not including the Sub-opt Type and
Sub-opt Length fields. Note that Sub-opt Type '0' Sub-opt Length fields. Note that Sub-opt Type '0'
(Section 4.2.1.1) is a special case that does not take a Sub- (Section 4.2.1.1) is a special case that does not take a Sub-
opt Length field. opt Length field.
skipping to change at page 16, line 32 skipping to change at page 16, line 32
extended by [RFC5648] to include more than one care-of addresses and extended by [RFC5648] to include more than one care-of addresses and
to associate each of them with a Binding Identifier (BID). to associate each of them with a Binding Identifier (BID).
This specification does not modify the mobile IPv6 binding cache any This specification does not modify the mobile IPv6 binding cache any
further. further.
Flow bindings can be thought of as a conceptual list of entries that Flow bindings can be thought of as a conceptual list of entries that
is separate from the binding cache. The flow bindings list contains is separate from the binding cache. The flow bindings list contains
an entry for each of the registered flow bindings. Flow binding an entry for each of the registered flow bindings. Flow binding
entries can point to an entry in the binding cache by means of the entries can point to an entry in the binding cache by means of the
BID. Each flow binding entry includes the following parameters : BID. Each flow binding entry includes the following parameters:
o FID (Flow Identifier): For a given mobile node, identified by its o FID (Flow Identifier): For a given mobile node, identified by its
primary home address, the FID MUST uniquely identify an entry, primary home address, the FID MUST uniquely identify an entry,
i.e. a unique flow binding. Each mobile node can only have a i.e. a unique flow binding. Each mobile node can only have a
single entry identified by a given FID at any one time. A given single entry identified by a given FID at any one time. A given
FID number space is used for all the addresses associated to a FID number space is used for all the addresses associated to a
given MN by the HA (e.g., via [RFC3963]). Different mobile nodes given MN by the HA (e.g., via [RFC3963]). Different mobile nodes
use the same FID number space. use the same FID number space.
o A Traffic Selector: Included in a traffic selector sub-option. o A Traffic Selector: Included in a traffic selector sub-option.
skipping to change at page 18, line 10 skipping to change at page 18, line 10
source address IPx will match the second entry, and according to the source address IPx will match the second entry, and according to the
associated Action it will be discarded. Note that any TCP traffic associated Action it will be discarded. Note that any TCP traffic
with source address IPx will match the first entry and thus it will with source address IPx will match the first entry and thus it will
be forwarded as per that entry. be forwarded as per that entry.
The third entry is marked as Inactive since the BID 4 does not exist The third entry is marked as Inactive since the BID 4 does not exist
in the ordered list of BID entries below. Inactive entries do not in the ordered list of BID entries below. Inactive entries do not
affect traffic, i.e., packets are not matched against them. affect traffic, i.e., packets are not matched against them.
Any UDP traffic that does not match any of the earlier entries will Any UDP traffic that does not match any of the earlier entries will
match the forth rule and according to the Action indicated, it will match the fourth rule and according to the Action indicated, it will
be replicated and forwarded to BIDs 1 and 3, corresponding to care-of be replicated and forwarded to BIDs 1 and 3, corresponding to care-of
addresses IP1 and IP2 shown below. addresses IP1 and IP2 shown below.
Finally any remaining packets that do not match any of the entries Finally any remaining packets that do not match any of the entries
above will be simply forwarded to the care-of address indicated by above will be simply forwarded to the care-of address indicated by
the highest order BID in the table below. In the example, such the highest order BID in the table below. In the example, such
packets will be forwarded to BID1 corresponding to care-of address packets will be forwarded to BID1 corresponding to care-of address
IP1. IP1.
BID-PRI BID CoA BID-PRI BID CoA
skipping to change at page 32, line 21 skipping to change at page 32, line 21
binding updates that are shorter than what the path MTU allows binding updates that are shorter than what the path MTU allows
whenever possible. whenever possible.
This specification offers a number of mechanisms for reducing the This specification offers a number of mechanisms for reducing the
size of binding updates. The operations defined in this size of binding updates. The operations defined in this
specification that require the most verbose options are those specification that require the most verbose options are those
registering new BIDs Section 4.1 and identifying new flows registering new BIDs Section 4.1 and identifying new flows
Section 4.2.1.4. Implementations are encouradged to keep binding Section 4.2.1.4. Implementations are 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-of
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 and acknowledgement messages defined in [RFC3775], binding update and acknowledgement messages defined in [RFC3775],
[RFC5555], and [RFC3963], so it inherits the security considerations [RFC5555], and [RFC3963], so it inherits the security considerations
discussed in these documents. The new option allows the mobile node discussed in these documents. The new option allows the mobile node
to associate some flows to one interface and other flows to another to associate some flows to one interface and other flows to another
skipping to change at page 34, line 5 skipping to change at page 33, line 26
This specification does not open up new fundamental lines of attack This specification does not open up new fundamental lines of attack
on communications between the MN and its correspondent nodes. on communications between the MN and its correspondent nodes.
However, it allows attacks of a finer granularity than those on the However, it allows attacks of a finer granularity than those on the
binding update. For instance, the attacker can divert or replicate binding update. For instance, the attacker can divert or replicate
flows of special interest to the attacker to an address of the flows of special interest to the attacker to an address of the
attacker's choosing, if the attacker is able to impersonate the MN or attacker's choosing, if the attacker is able to impersonate the MN or
modify a binding update sent by the MN. Hence it becomes doubly modify a binding update sent by the MN. Hence it becomes doubly
critical that authentication and integrity services are applied to critical that authentication and integrity services are applied to
binding updates. binding updates.
Finally, when the optional anti-replay feature of Encapsulating
Security Payload (ESP) [RFC4303] is employed and packets from/to
different CoAs are sent on the same security association (SA), some
packets could be discarded at the receiver due to the windowing
mechanism used by this feature. Therefore, a sender SHOULD put
traffic from/to different CoAs, but with the same HoA in the selector
values, on different SAs to support Multiple Care-of Addresses
appropriately. To permit this, the IPsec implementation SHOULD
establish and maintain multiple SAs between a given sender and
receiver, with the same selectors. Distribution of traffic among
these parallel SAs to support Multiple Care-of Addresses is locally
determined by the sender and is not negotiated by the Internet Key
Exchange (IKEv2) protocol [RFC4306]. The receiver will process the
packets from the different SAs without prejudice.
8. IANA Considerations 8. IANA Considerations
This specification requires the following IANA assignments on This specification requires the following IANA assignments on
existing namespaces as well as the creation of some new namespaces. existing namespaces as well as the creation of some new namespaces.
1) New Mobility Options [RFC3775]: This registry is available from 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:
Flow Identification Mobility Option, define in Section 4.2 Flow Identification Mobility Option, define in Section 4.2
skipping to change at page 35, line 12 skipping to change at page 35, line 12
131 BID not found 131 BID not found
132 FID not found 132 FID not found
133 Traffic selector format not supported 133 Traffic selector format not supported
134 Discard function not supported 134 Discard function not supported
135 Forward function not supported 135 Forward function not supported
126-250 unassigned and available for reject codes to be 136-250 unassigned and available for reject codes to be
allocated via Standards Action or IESG Approval as per allocated via Standards Action or IESG Approval as per
[RFC5226] [RFC5226]
251-255 reserved for experimental use. This small number of 251-255 reserved for experimental use. This small number of
status codes should be sufficient for experiments with status codes should be sufficient for experiments with
currently unforeseen error conditions. currently unforeseen error conditions.
4) New "Flow Identification Sub-Options" namespace for the Flow 4) New "Flow Identification Sub-Options" namespace for the Flow
Identification Mobility Option. The sub-option space is defined Identification Mobility Option. The sub-option space is defined
in Figure 3. The following Sub-option Type values are defined in in Figure 3. The following Sub-option Type values are defined in
skipping to change at page 39, line 45 skipping to change at page 39, line 45
draft-ietf-mext-binary-ts-04 (work in progress), draft-ietf-mext-binary-ts-04 (work in progress),
February 2010. 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.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007. Terminology", RFC 4885, July 2007.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008. Management", RFC 5380, October 2008.
Authors' Addresses Authors' Addresses
George Tsirtsis George Tsirtsis
 End of changes. 15 change blocks. 
17 lines changed or deleted 40 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/