RFC6088

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

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.

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 |

              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//

Anonymous

Search

RFC6088

Namespaces

More

Page actions

Contents

Introduction

Requirements Notation

Traffic Selector Sub-Options

IPv4 Binary Traffic Selector

IPv6 Binary Traffic Selector

Security Considerations

IANA Considerations

Acknowledgements

References

Normative References

Informative References

Navigation

Navigation

Wiki tools

Wiki tools

Anonymous

Search

RFC6088

Contents

Introduction

Requirements Notation

Traffic Selector Sub-Options

IPv4 Binary Traffic Selector

IPv6 Binary Traffic Selector

Security Considerations

IANA Considerations

Acknowledgements

References

Normative References

Informative References

Navigation

Wiki tools

Page tools

Categories