Difference between revisions of "RFC6088"
imported>Admin (Created page with " Internet Engineering Task Force (IETF) G. TsirtsisRequest for Comments: 6088 G. GiarettaCategory: Standards Track...") |
|||
| Line 1: | Line 1: | ||
| + | Internet Engineering Task Force (IETF) G. Tsirtsis | ||
| + | Request for Comments: 6088 G. Giaretta | ||
| + | Category: Standards Track Qualcomm | ||
| + | ISSN: 2070-1721 H. Soliman | ||
| + | Elevate Technologies | ||
| + | N. Montavont | ||
| + | IT/TB | ||
| + | January 2011 | ||
| + | Traffic Selectors for Flow Bindings | ||
| − | + | '''Abstract''' | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | Abstract | ||
This document defines binary formats for IPv4 and IPv6 traffic | This document defines binary formats for IPv4 and IPv6 traffic | ||
| Line 14: | Line 16: | ||
IPv6. | IPv6. | ||
| − | Status of This Memo | + | '''Status of This Memo''' |
This is an Internet Standards Track document. | This is an Internet Standards Track document. | ||
| Line 22: | Line 24: | ||
received public review and has been approved for publication by the | received public review and has been approved for publication by the | ||
Internet Engineering Steering Group (IESG). Further information on | Internet Engineering Steering Group (IESG). Further information on | ||
| − | Internet Standards is available in Section 2 of | + | Internet Standards is available in Section 2 of RFC 5741. |
Information about the current status of this document, any errata, | Information about the current status of this document, any errata, | ||
| Line 28: | Line 30: | ||
http://www.rfc-editor.org/info/rfc6088. | http://www.rfc-editor.org/info/rfc6088. | ||
| − | Copyright Notice | + | '''Copyright Notice''' |
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | ||
document authors. All rights reserved. | document authors. All rights reserved. | ||
| − | This document is subject to | + | 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 | ||
| Line 42: | Line 44: | ||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | ||
described in the Simplified BSD License. | described in the Simplified BSD License. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Introduction == | == Introduction == | ||
This document defines binary formats for IPv4 and IPv6 traffic | This document defines binary formats for IPv4 and IPv6 traffic | ||
| − | selector sub-options, as defined in [RFC6089]. | + | selector sub-options, as defined in [[[RFC6089]]]. |
The binary traffic selector format defined here, allows for efficient | The binary traffic selector format defined here, allows for efficient | ||
identification of flow(s) based on well-known fields in IPv4 | identification of flow(s) based on well-known fields in IPv4 | ||
| − | [RFC0791], IPv6 [RFC2460], and transport layer headers like TCP | + | [[[RFC0791]]], IPv6 [[[RFC2460]]], and transport layer headers like TCP |
| − | [RFC0793] and UDP [RFC0768]. | + | [[[RFC0793]]] and UDP [[[RFC0768]]]. |
== Requirements Notation == | == Requirements Notation == | ||
| Line 63: | Line 59: | ||
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]]]. |
== Traffic Selector Sub-Options == | == Traffic Selector Sub-Options == | ||
| − | [RFC6089] defines the format for the traffic selector sub-option. | + | [[[RFC6089]]] defines the format for the traffic selector sub-option. |
The following values of the TS Format field are defined in this | The following values of the TS Format field are defined in this | ||
| Line 83: | Line 79: | ||
"IPv4 binary traffic selector", then the traffic selector is | "IPv4 binary traffic selector", then the traffic selector is | ||
formatted as shown below. | formatted as shown below. | ||
| − | |||
| − | |||
| − | |||
| − | |||
The alignment requirement for this sub-option is: | The alignment requirement for this sub-option is: | ||
| Line 136: | Line 128: | ||
In other words, this is one of the addresses of the correspondent | In other words, this is one of the addresses of the correspondent | ||
node. | node. | ||
| − | |||
| − | |||
| − | |||
| − | |||
(B)End Source Address | (B)End Source Address | ||
| Line 174: | Line 162: | ||
range of SPI values to be matched, on data packets sent from a | range of SPI values to be matched, on data packets sent from a | ||
corresponding node to the mobile node as seen by the home agent. | corresponding node to the mobile node as seen by the home agent. | ||
| − | This field is defined in [RFC4303]. | + | This field is defined in [[[RFC4303]]]. |
(F)End IPsec SPI - Security Parameter Index | (F)End IPsec SPI - Security Parameter Index | ||
| Line 184: | Line 172: | ||
When this field is included, the receiver will match all of the | When this field is included, the receiver will match all of the | ||
SPI values between fields (E) and (F), inclusive of (E) and (F). | SPI values between fields (E) and (F), inclusive of (E) and (F). | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
(G)Start Source Port | (G)Start Source Port | ||
| Line 235: | Line 214: | ||
packets sent from a corresponding node to the mobile node as seen | packets sent from a corresponding node to the mobile node as seen | ||
by the home agent. Note that this field is called a "Type of | by the home agent. Note that this field is called a "Type of | ||
| − | Service field" in [RFC0791]. [RFC3260] then clarified that the | + | Service field" in [[[RFC0791]]]. [[[RFC3260]]] then clarified that the |
field has been redefined as a 6-bit DS field with 2 bits reserved, | field has been redefined as a 6-bit DS field with 2 bits reserved, | ||
| − | later claimed by Explicit Congestion Notification (ECN) [RFC3168]. | + | later claimed by Explicit Congestion Notification (ECN) [[[RFC3168]]]. |
For the purpose of this specification, the (K)Start DS field is 8 | For the purpose of this specification, the (K)Start DS field is 8 | ||
bits long, where the 6 most significant bits indicate the DS field | bits long, where the 6 most significant bits indicate the DS field | ||
to be matched and the 2 least significant bits' values MUST be | to be matched and the 2 least significant bits' values MUST be | ||
ignored in any comparison. | ignored in any comparison. | ||
| − | |||
| − | |||
| − | |||
| − | |||
(L)End DS - Differential Services | (L)End DS - Differential Services | ||
| Line 292: | Line 267: | ||
n if M, N, O, or P is set | n if M, N, O, or P is set | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
0 1 2 3 | 0 1 2 3 | ||
| Line 348: | Line 316: | ||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
| (I)Start Source port | (J)End Source port | | | (I)Start Source port | (J)End Source port | | ||
| − | |||
| − | |||
| − | |||
| − | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||
| Line 401: | Line 365: | ||
included, the receiver will match all of the addresses between | included, the receiver will match all of the addresses between | ||
fields (C) and (D), inclusive of (C) and (D). | fields (C) and (D), inclusive of (C) and (D). | ||
| − | |||
| − | |||
| − | |||
| − | |||
(E)Start IPsec SPI - Security Parameter Index | (E)Start IPsec SPI - Security Parameter Index | ||
| Line 411: | Line 371: | ||
range of SPI values to be matched, on data packets sent from a | range of SPI values to be matched, on data packets sent from a | ||
corresponding node to the mobile node as seen by the home agent. | corresponding node to the mobile node as seen by the home agent. | ||
| − | This field is defined in [RFC4303]. | + | This field is defined in [[[RFC4303]]]. |
(F)End IPsec SPI - Security Parameter Index | (F)End IPsec SPI - Security Parameter Index | ||
| Line 427: | Line 387: | ||
of flow label values to be matched, on data packets sent from a | of flow label values to be matched, on data packets sent from a | ||
corresponding node to the mobile node as seen by the home agent. | corresponding node to the mobile node as seen by the home agent. | ||
| − | According to [RFC2460], the flow label is 24 bits long. For the | + | According to [[[RFC2460]]], the flow label is 24 bits long. For the |
purpose of this specification, the sender of this option MUST | purpose of this specification, the sender of this option MUST | ||
prefix the flow label value with 8 bits of "0" before inserting it | prefix the flow label value with 8 bits of "0" before inserting it | ||
| Line 450: | Line 410: | ||
the range of port numbers to be matched, on data packets sent from | the range of port numbers to be matched, on data packets sent from | ||
a corresponding node to the mobile node as seen by the home agent. | a corresponding node to the mobile node as seen by the home agent. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
(J)End Source Port | (J)End Source Port | ||
| Line 492: | Line 444: | ||
from a corresponding node to the mobile node as seen by the home | from a corresponding node to the mobile node as seen by the home | ||
agent. This field is equivalent to the Start DS field in the IPv4 | agent. This field is equivalent to the Start DS field in the IPv4 | ||
| − | traffic selector in Figure 1. As per [RFC3260], the field is | + | traffic selector in Figure 1. As per [[[RFC3260]]], the field is |
defined as a 6-bit DS field with 2 bits reserved, later claimed by | defined as a 6-bit DS field with 2 bits reserved, later claimed by | ||
| − | Explicit Congestion Notification (ECN) [RFC3168]. For the purpose | + | Explicit Congestion Notification (ECN) [[[RFC3168]]]. For the purpose |
of this specification, the (M)Start TC field is 8 bits long, where | of this specification, the (M)Start TC field is 8 bits long, where | ||
the 6 most significant bits indicate the DS field to be matched | the 6 most significant bits indicate the DS field to be matched | ||
| Line 506: | Line 458: | ||
starting from the value of the Start TC field. This field MUST | starting from the value of the Start TC field. This field MUST | ||
NOT be included unless the Start TC field is included. When this | NOT be included unless the Start TC field is included. When this | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
field is included, it MUST be coded the same way as defined for | field is included, it MUST be coded the same way as defined for | ||
| Line 540: | Line 487: | ||
This document defines the format of the traffic selector field of a | This document defines the format of the traffic selector field of a | ||
| − | sub-option defined for flow bindings [RFC6089]. The authors have not | + | sub-option defined for flow bindings [[[RFC6089]]]. The authors have not |
identified any security concerns pertaining to this document beyond | identified any security concerns pertaining to this document beyond | ||
| − | what is already identified in [RFC6089]. | + | what is already identified in [[[RFC6089]]]. |
== IANA Considerations == | == IANA Considerations == | ||
| Line 548: | Line 495: | ||
The following new TS format values have been assigned from the | The following new TS format values have been assigned from the | ||
"Traffic Selector Format" namespace for the traffic selector sub- | "Traffic Selector Format" namespace for the traffic selector sub- | ||
| − | option defined in [RFC6089]. | + | option defined in [[[RFC6089]]]. |
1 IPv4 Binary Traffic Selector | 1 IPv4 Binary Traffic Selector | ||
| Line 560: | Line 507: | ||
thank Benjamin Lim, Dave Craig, Patrick Stupar, and Basavaraj Patil | thank Benjamin Lim, Dave Craig, Patrick Stupar, and Basavaraj Patil | ||
for their reviews and comments. | for their reviews and comments. | ||
| − | |||
| − | |||
| − | |||
| − | |||
== References == | == References == | ||
| Line 569: | Line 512: | ||
=== Normative References === | === Normative References === | ||
| − | [RFC0768] Postel, J., "User Datagram Protocol", STD 6, | + | [[[RFC0768]]] Postel, J., "User Datagram Protocol", STD 6, RFC 768, |
| − | + | August 1980. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | [[[RFC0791]]] Postel, J., "Internet Protocol", STD 5, RFC 791, | ||
| + | September 1981. | ||
| + | [[[RFC0793]]] Postel, J., "Transmission Control Protocol", STD 7, | ||
| + | RFC 793, September 1981. | ||
| + | [[[RFC2119]]] Bradner, S., "Key words for use in RFCs to Indicate | ||
| + | Requirement Levels", BCP 14, RFC 2119, March 1997. | ||
| + | [[[RFC2460]]] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | ||
| + | (IPv6) Specification", RFC 2460, December 1998. | ||
| + | [[[RFC3168]]] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | ||
| + | of Explicit Congestion Notification (ECN) to IP", | ||
| + | RFC 3168, September 2001. | ||
| + | [[[RFC4303]]] Kent, S., "IP Encapsulating Security Payload (ESP)", | ||
| + | RFC 4303, December 2005. | ||
| + | [[[RFC6089]]] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., | ||
| + | and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and | ||
| + | Network Mobility (NEMO) Basic Support", RFC 6089, | ||
| + | January 2011. | ||
| + | === Informative References === | ||
| + | [[[RFC3260]]] Grossman, D., "New Terminology and Clarifications for | ||
| + | Diffserv", RFC 3260, April 2002. | ||
Authors' Addresses | Authors' Addresses | ||
| Line 603: | Line 550: | ||
EMail: [email protected] | EMail: [email protected] | ||
| − | |||
Gerardo Giaretta | Gerardo Giaretta | ||
| Line 609: | Line 555: | ||
EMail: [email protected] | EMail: [email protected] | ||
| − | |||
Hesham Soliman | Hesham Soliman | ||
| Line 615: | Line 560: | ||
EMail: [email protected] | EMail: [email protected] | ||
| − | |||
Nicolas Montavont | Nicolas Montavont | ||
| Line 626: | Line 570: | ||
EMail: [email protected] | EMail: [email protected] | ||
URI: http://www.rennes.enst-bretagne.fr/~nmontavo// | URI: http://www.rennes.enst-bretagne.fr/~nmontavo// | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
[[Category:Standards Track]] | [[Category:Standards Track]] | ||
Revision as of 05:05, 1 October 2020
Internet Engineering Task Force (IETF) G. Tsirtsis Request for Comments: 6088 G. Giaretta Category: Standards Track Qualcomm ISSN: 2070-1721 H. Soliman
Elevate Technologies
N. Montavont
IT/TB
January 2011
Traffic Selectors for Flow Bindings
Abstract
This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for Mobile IPv6.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6088.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Contents
Introduction
This document defines binary formats for IPv4 and IPv6 traffic selector sub-options, as defined in [[[RFC6089]]].
The binary traffic selector format defined here, allows for efficient identification of flow(s) based on well-known fields in IPv4 [[[RFC0791]]], IPv6 [[[RFC2460]]], and transport layer headers like TCP [[[RFC0793]]] and UDP [[[RFC0768]]].
Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [[[RFC2119]]].
Traffic Selector Sub-Options
[[[RFC6089]]] defines the format for the traffic selector sub-option.
The following values of the TS Format field are defined in this specification for binary traffic selectors.
TS Format:
1 IPv4 binary traffic selector
2 IPv6 binary traffic selector
IPv4 Binary Traffic Selector
If the TS Format field of the traffic selector sub-option indicates "IPv4 binary traffic selector", then the traffic selector is formatted as shown below.
The alignment requirement for this sub-option is:
4n if A, B, C, D, E, or F is set
2n if G, H, I, or J is set
n if K, L, M, or N is set
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-opt Type | Sub-Opt Len | TS Format | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|B|C|D|E|F|G|H|I|J|K|L|M|N| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (A)Start Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (B)End Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (C)Start Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (D)End Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (E)Start IPsec SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (F)End IPsec SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (G)Start Source port | (H)End Source port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (I)Start Destination port | (J)End Destination port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (K)Start DS | (L)End DS |(M)Start Prot. | (N) End Prot. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv4 binary traffic selector
Flags (A-N)
Each flag indicates whether the corresponding field is present in the message.
(A)Start Source Address
This field identifies the first source address, from the range of 32-bit IPv4 addresses to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. In other words, this is one of the addresses of the correspondent node.
(B)End Source Address
If more than one contiguous source address needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start Source Address field. This field MUST NOT be included unless the Start Source Address field is included. When this field is included, the receiver will match all of the addresses between fields (A) and (B), inclusive of (A) and (B).
(C)Start Destination Address
This field identifies the first destination address, from the range of 32-bit IPv4 addresses to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. In other words, this is one of the registered home addresses of the mobile node.
(D)End Destination Address
If more than one contiguous destination address needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start Destination Address field. This field MUST NOT be included unless the Start Destination Address field is included. When this field is included, the receiver will match all of the addresses between fields (C) and (D), inclusive of (C) and (D).
(E)Start IPsec SPI - Security Parameter Index
This field identifies the first 32-bit IPsec SPI value, from the range of SPI values to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. This field is defined in [[[RFC4303]]].
(F)End IPsec SPI - Security Parameter Index
If more than one contiguous SPI value needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start IPsec SPI field. This field MUST NOT be included unless the Start IPsec SPI field is included. When this field is included, the receiver will match all of the SPI values between fields (E) and (F), inclusive of (E) and (F).
(G)Start Source Port
This field identifies the first 16-bit source port number, from the range of port numbers to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. This is from the range of port numbers defined by IANA (http://www.iana.org).
(H)End Source Port
If more than one contiguous source port number needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start Source Port field. This field MUST NOT be included unless the Start Source Port field is included. When this field is included, the receiver will match all of the port numbers between fields (G) and (H), inclusive of (G) and (H).
(I)Start Destination Port
This field identifies the first 16-bit destination port number, from the range of port numbers to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent.
(J)End Destination Port
If more than one contiguous destination port number needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start Destination Port field. This field MUST NOT be included unless the Start Destination Port field is included. When this field is included, the receiver will match all of the port numbers between fields (I) and (J), inclusive of (I) and (J).
(K)Start DS - Differential Services
This field identifies the first differential services value, from the range of differential services values to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. Note that this field is called a "Type of Service field" in [[[RFC0791]]]. [[[RFC3260]]] then clarified that the field has been redefined as a 6-bit DS field with 2 bits reserved, later claimed by Explicit Congestion Notification (ECN) [[[RFC3168]]]. For the purpose of this specification, the (K)Start DS field is 8 bits long, where the 6 most significant bits indicate the DS field to be matched and the 2 least significant bits' values MUST be ignored in any comparison.
(L)End DS - Differential Services
If more than one contiguous DS value needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start DS field. This field MUST NOT be included unless the Start DS field is included. When this field is included, it MUST be coded the same way as defined for (K). When this field is included, the receiver will match all of the values between fields (K) and (L), inclusive of (K) and (L).
(M)Start Protocol
This field identifies the first 8-bit protocol value, from the range of protocol values to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent.
(N)End Protocol
If more than one contiguous protocol value needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start Protocol field. This field MUST NOT be included unless the Start Protocol field is included. When this field is included, the receiver will match all of the values between fields (M) and (N), inclusive of (M) and (N).
Reserved
Reserved for future use. These bits MUST be set to zero by the sender and ignored by the receiver.
IPv6 Binary Traffic Selector
If the TS Format field of the traffic selector sub-option indicates "IPv6 binary traffic selector", then the traffic selector is formatted as follows:
The alignment requirement for this sub-option is:
8n if A, B, C, or D is set
4n if E, F, G, or H is set
2n if I, J, K, or L is set
n if M, N, O, or P is set
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-opt Type | Sub-Opt Len | TS Format | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + (A)Start Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + (B)End Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + (C)Start Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + (D)End Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (E)Start IPsec SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (F)End IPsec SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (G)Start Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (H)End Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (I)Start Source port | (J)End Source port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (K)Start Destination port | (L)End Destination port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (M)Start TC | (N)End TC | (O)Start NH | (P) End NH | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv6 binary traffic selector
Flags (A-P)
Each flag indicates whether the corresponding field is present in the message
(A)Start Source Address
This field identifies the first source address, from the range of 128-bit IPv6 addresses to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. In other words, this is one of the addresses of the correspondent node.
(B)End Source Address
If more than one contiguous source address needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start Source Address field. This field MUST NOT be included unless the Start Source Address field is included. When this field is included, the receiver will match all of the addresses between fields (A) and (B), inclusive of (A) and (B).
(C)Start Destination Address
This field identifies the first destination address, from the range of 128-bit IPv6 addresses to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. In other words, this is one of the registered home addresses of the mobile node.
(D)End Destination Address
If more than one contiguous destination address needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start Destination Address field. This field MUST NOT be included unless the Start Destination Address field is included. When this field is included, the receiver will match all of the addresses between fields (C) and (D), inclusive of (C) and (D).
(E)Start IPsec SPI - Security Parameter Index
This field identifies the first 32-bit IPsec SPI value, from the range of SPI values to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. This field is defined in [[[RFC4303]]].
(F)End IPsec SPI - Security Parameter Index
If more than one contiguous SPI value needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start IPsec SPI field. This field MUST NOT be included unless the Start IPsec SPI field is included. When this field is included, the receiver will match all of the SPI values between fields (E) and (F), inclusive of (E) and (F).
(G)Start Flow Label
This field identifies the first flow label value, from the range of flow label values to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. According to [[[RFC2460]]], the flow label is 24 bits long. For the purpose of this specification, the sender of this option MUST prefix the flow label value with 8 bits of "0" before inserting it in the (G)Start Flow Label field. The receiver SHOULD ignore the first 8 bits of this field before using it in comparisons with flow labels in packets.
(H)End Flow Label
If more than one contiguous flow label value needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start Flow Label field. This field MUST NOT be included unless the Start Flow Label field is included. When this field is included, the receiver will match all of the flow label values between fields (G) and (H), inclusive of (G) and (H). When this field is included, it MUST be coded the same way as defined for (G).
(I)Start Source Port
This field identifies the first 16-bit source port number, from the range of port numbers to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent.
(J)End Source Port
If more than one contiguous source port number needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start Source Port field. This field MUST NOT be included unless the Start Source Port field is included. When this field is included, the receiver will match all of the port numbers between fields (I) and (J), inclusive of (I) and (J).
(K)Start Destination Port
This field identifies the first 16-bit destination port number, from the range of port numbers to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent.
(L)End Destination Port
If more than one contiguous destination port number needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start Destination Port field. This field MUST NOT be included unless the Start Destination Port field is included. When this field is included, the receiver will match all of the port numbers between fields (K) and (L), inclusive of (K) and (L).
(M)Start TC - Traffic Class
This field identifies the first traffic class value, from the range of traffic class values to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent. This field is equivalent to the Start DS field in the IPv4 traffic selector in Figure 1. As per [[[RFC3260]]], the field is defined as a 6-bit DS field with 2 bits reserved, later claimed by Explicit Congestion Notification (ECN) [[[RFC3168]]]. For the purpose of this specification, the (M)Start TC field is 8 bits long, where the 6 most significant bits indicate the DS field to be matched and the 2 least significant bits' values MUST be ignored in any comparison.
(N)End TC - Traffic Class
If more than one contiguous TC value needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start TC field. This field MUST NOT be included unless the Start TC field is included. When this
field is included, it MUST be coded the same way as defined for (M). When this field is included, the receiver will match all of the values between fields (M) and (N), inclusive of (M) and (N).
(O)Start NH - Next Header
This field identifies the first 8-bit next header value, from the range of next header values to be matched, on data packets sent from a corresponding node to the mobile node as seen by the home agent.
(P)End NH - Next Header
If more than one contiguous next header value needs to be matched, then this field can be used to indicate the end value of a range starting from the value of the Start NH field. This field MUST NOT be included unless the Start next header field is included. When this field is included, the receiver will match all of the values between fields (O) and (P), inclusive of (O) and (P).
Reserved
Reserved for future use. These bits MUST be set to zero by the sender and ignored by the receiver.
Security Considerations
This document defines the format of the traffic selector field of a sub-option defined for flow bindings [[[RFC6089]]]. The authors have not identified any security concerns pertaining to this document beyond what is already identified in [[[RFC6089]]].
IANA Considerations
The following new TS format values have been assigned from the "Traffic Selector Format" namespace for the traffic selector sub- option defined in [[[RFC6089]]].
1 IPv4 Binary Traffic Selector
2 IPv6 Binary Traffic Selector
Acknowledgements
The authors would like to thank Patrick Stupar and Julien Laganier for their contributions to this document. We would also like to thank Benjamin Lim, Dave Craig, Patrick Stupar, and Basavaraj Patil for their reviews and comments.
References
Normative References
[[[RFC0768]]] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[[[RFC0791]]] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[[[RFC0793]]] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[[[RFC2119]]] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[[[RFC2460]]] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[[[RFC3168]]] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[[[RFC4303]]] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[[[RFC6089]]] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
Network Mobility (NEMO) Basic Support", RFC 6089,
January 2011.
Informative References
[[[RFC3260]]] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
Authors' Addresses
George Tsirtsis Qualcomm
EMail: [email protected]
Gerardo Giaretta Qualcomm
EMail: [email protected]
Hesham Soliman Elevate Technologies
EMail: [email protected]
Nicolas Montavont Institut Telecom / Telecom Bretagne 2, rue de la chataigneraie Cesson Sevigne 35576 France
Phone: (+33) 2 99 12 70 23 EMail: [email protected] URI: http://www.rennes.enst-bretagne.fr/~nmontavo//
