RFC 6088 PROPOSED STANDARD MOBILITY · IPV6 · PACKET FORMATS
Flow Traffic Selectors: Traffic Selectors for Flow Bindings
Compact binary formats for describing a flow of IPv4 or IPv6 packets, used by Mobile IPv6 flow bindings.
RFC EDITOR
Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, DOI 10.17487/RFC6088, January 2011, <https://www.rfc-editor.org/info/rfc6088>.
BIBTEX
@misc{rfc6088,
series = {Request for Comments},
number = 6088,
howpublished = {RFC 6088},
publisher = {RFC Editor},
doi = {10.17487/RFC6088},
url = {https://www.rfc-editor.org/info/rfc6088},
author = {G. Tsirtsis and G. Giarreta and H. Soliman and N. Montavont},
title = {{Traffic Selectors for Flow Bindings}},
pagetotal = 13,
year = 2011,
month = jan,
} RFC text
Contents
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
3. Traffic Selector Sub-Options . . . . . . . . . . . . . . . . . 2
3.1. IPv4 Binary Traffic Selector . . . . . . . . . . . . . . . 2
3.2. IPv6 Binary Traffic Selector . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
1. 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].
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. 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
3.1. 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.
3.2. 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.
4. 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].
5. 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
6. 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.
7. References
7.1. 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.
7.2. Informative References
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
Authors' Addresses
George Tsirtsis
Qualcomm
EMail: tsirtsis@qualcomm.com
Gerardo Giaretta
Qualcomm
EMail: gerardog@qualcomm.com
Hesham Soliman
Elevate Technologies
EMail: hesham@elevatemobile.com
Nicolas Montavont
Institut Telecom / Telecom Bretagne
2, rue de la chataigneraie
Cesson Sevigne 35576
France
Phone: (+33) 2 99 12 70 23
EMail: nicolas.montavont@telecom-bretagne.eu
URI: http://www.rennes.enst-bretagne.fr/~nmontavo//
ISO Plain Language
On this page
PROBLEMFlow bindings in Mobile IPv6 need a way to say which packets belong to a flow, so that a device can steer different traffic to different addresses.
MECHANISMRFC 6088 defines two binary traffic selector formats, one for IPv4 (TS Format 1) and one for IPv6 (TS Format 2). A set of flags says which fields are present, and most fields have a start and an optional end value to describe a range.
WHY IT MATTERSThe selectors identify flows efficiently from well-known IP and transport header fields. RFC 6088 only defines the formats; the sub-option itself is in RFC 6089.
§1What the Document Defines
This document defines binary formats for IPv4 and IPv6 traffic selector sub-options, as defined in RFC 6089.
The binary traffic selector format allows for efficient identification of flows based on well-known fields in the IPv4 and IPv6 headers and in transport layer headers such as TCP and UDP.
The format is designed so that a receiver can pick out the packets of one conversation by looking at a few header fields, rather than by reading the packets themselves.
§3Sub-Options and the TS Format Values
RFC 6089 defines the format of the traffic selector sub-option. This document defines two values of the TS Format field for binary traffic selectors: value 1 for the IPv4 binary traffic selector and value 2 for the IPv6 binary traffic selector.
Both formats share the same shape. They begin with the sub-option type, the sub-option length, the TS Format and a reserved octet, followed by a row of flag bits, one per optional field, and more reserved bits. Each flag says whether the matching field is present in the message, and every field that can be present has a start value and, in most cases, an end value that turns the start into a range.
Every end field MUST NOT be included unless the matching start field is included, and when the end field is present the receiver matches all the values between the start and the end, inclusive of both. The reserved bits MUST be set to zero by the sender and ignored by the receiver.
Both versions look the same: a header, a row of flags, then the values. A flag says the value is there, and an end value turns a single value into a range that includes both ends.
| Matched value | IPv4 format | IPv6 format |
|---|---|---|
| Source address | 32 bits | 128 bits |
| Destination address | 32 bits | 128 bits |
| IPsec SPI | 32 bits | 32 bits |
| Flow label | Not present | 24 bits, stored in a 32-bit field |
| Source port | 16 bits | 16 bits |
| Destination port | 16 bits | 16 bits |
| DS or traffic class | 8 bits, top 6 compared | 8 bits, top 6 compared |
| Protocol or next header | 8 bits | 8 bits |
§3.1The IPv4 Binary Traffic Selector
When the TS Format field indicates the IPv4 binary traffic selector, the sub-option is laid out as shown in Figure 1 of the document, with the alignment requirement of 4n if any of the flags A, B, C, D, E or F is set, 2n if any of G, H, I or J is set, and n if any of K, L, M or N is set.
Flag A is the start source address, which identifies the first of the 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 one of the addresses of the correspondent node. Flag B is the end source address, used when more than one contiguous source address has to be matched. Flag C is the start destination address, one of the registered home addresses of the mobile node, and flag D is its matching end value.
Flag E is the start IPsec SPI, the Security Parameter Index, which is a 32-bit value, and flag F is the end SPI value. The SPI is defined in RFC 4303.
Flag G is the start source port, a 16-bit port number from the range assigned by IANA, and flag H is the end source port. Flag I is the start destination port and flag J is the end destination port.
Flag K is the start differential services value, and flag L is the end value. This field is called the Type of Service field in RFC 791, which RFC 3260 later clarified as a 6-bit DS field with 2 bits reserved, later claimed by Explicit Congestion Notification. For this specification the field is 8 bits long, where the 6 most significant bits indicate the DS field to be matched and the 2 least significant bits MUST be ignored in any comparison.
Flag M is the start protocol value, an 8-bit value, and flag N is the end protocol value.
The IPv4 selector can match on the source and destination addresses, the IPsec security parameter index, the source and destination ports, the differentiated services value and the protocol number. Each one can be a single value or a range, and the flags say which ones are in use.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
SUB-OPT-TYPE | Sub-opt Type | 1 byte | The sub-option type of the traffic selector. | |
SUB-OPT-LEN | Sub-Opt Len | 1 byte | Length of the sub-option. | |
TS-FORMAT | TS Format | 1 byte | 1 for the IPv4 binary traffic selector. | |
RESERVED-1 | Reserved | 1 byte | Set to zero by the sender, ignored by the receiver. | |
FLAGS | Flags A to N | 2 bytes | One bit per optional field, saying whether that field is present. | |
RESERVED-2 | Reserved | 2 bytes | Set to zero by the sender, ignored by the receiver. | |
SRC-START | Start Source Address | 4 bytes | First source address to match; one of the correspondent node's addresses. | |
SRC-END | End Source Address | 4 bytes | End of the source address range. Present only if the start is. | |
DST-START | Start Destination Address | 4 bytes | First destination address to match; a registered home address of the mobile node. | |
DST-END | End Destination Address | 4 bytes | End of the destination address range. Present only if the start is. | |
SPI-START | Start IPsec SPI | 4 bytes | First IPsec security parameter index to match. | |
SPI-END | End IPsec SPI | 4 bytes | End of the SPI range. Present only if the start is. | |
SPORT-START | Start Source port | 2 bytes | First source port to match. | |
SPORT-END | End Source port | 2 bytes | End of the source port range. Present only if the start is. | |
DPORT-START | Start Destination port | 2 bytes | First destination port to match. | |
DPORT-END | End Destination port | 2 bytes | End of the destination port range. Present only if the start is. | |
DS-START | Start DS | 1 byte | First differential services value to match; the 6 most significant bits are compared. | |
DS-END | End DS | 1 byte | End of the DS range. Present only if the start is. | |
PROTO-START | Start Prot. | 1 byte | First protocol value to match. | |
PROTO-END | End Prot. | 1 byte | End of the protocol range. Present only if the start is. |
§3.2The IPv6 Binary Traffic Selector
When the TS Format field indicates the IPv6 binary traffic selector, the sub-option is laid out as shown in Figure 2, with the alignment requirement of 8n if any of A, B, C or D is set, 4n if any of E, F, G or H is set, 2n if any of I, J, K or L is set, and n if any of M, N, O or P is set.
Flags A to D are the start and end source and destination addresses, this time 128-bit IPv6 addresses, with the same meaning as in the IPv4 selector: the source is one of the addresses of the correspondent node and the destination is one of the registered home addresses of the mobile node.
Flags E and F are the start and end IPsec SPI values, both 32 bits. Flags G and H are the start and end flow label values. The flow label is 24 bits long according to RFC 2460, and for this specification the sender of the option MUST prefix the flow label value with 8 bits of zero before inserting it, while the receiver SHOULD ignore the first 8 bits of the field before comparing it with flow labels in packets.
Flags I to L are the start and end source and destination ports, 16 bits each. Flags M and N are the start and end traffic class values, which are equivalent to the start and end DS fields of the IPv4 selector: 8 bits long, with the 6 most significant bits indicating the DS field to be matched and the 2 least significant bits ignored in any comparison. Flags O and P are the start and end next header values, 8 bits each.
The IPv6 selector matches on the same kinds of values plus the flow label, and uses the next header field where IPv4 uses the protocol field. The 24-bit flow label is stored in a 32-bit field with eight leading zero bits, and the receiver is told to ignore those bits.
§4Security Considerations
This document defines the format of the traffic selector field of a sub-option defined for flow bindings in RFC 6089. The authors have not identified any security concerns pertaining to this document beyond what is already identified in RFC 6089.
Defining the fields adds no new risk of its own; the security questions sit with the flow binding mechanism the fields belong to.
§5IANA Considerations
Two new TS format values have been assigned from the Traffic Selector Format namespace for the traffic selector sub-option defined in RFC 6089: value 1 for the IPv4 binary traffic selector and value 2 for the IPv6 binary traffic selector.
Two numbers are registered to say which of the two layouts is in use.
- 1IPv4 binary traffic selector — Flags A to N, with 32-bit addresses.
- 2IPv6 binary traffic selector — Flags A to P, with 128-bit addresses and a flow label.
§7References
[RFC6089]RFC 6089Tsirtsis, 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.January 2011[RFC0791]RFC 791Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.September 1981[RFC2460]RFC 2460Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.December 1998[RFC4303]RFC 4303Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.December 2005[RFC3260]RFC 3260Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.April 2002[RFC2119]RFC 2119Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.March 1997