Traffic Selectors for Flow Bindings
draft-ietf-mext-binary-ts-02.txt

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 Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 19, 2010.

Copyright Notice

Copyright (c) 2009 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 BSD License.

Table of Contents

1.  Requirements notation
2.  Introduction
3.  Traffic Selector Sub-Options
    3.1.  IPv4 binary traffic selector
    3.2.  IPv6 binary traffic selector
4.  Security Considerations
5.  IANA Considerations
6.  Aknowledgements
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Authors' Addresses

1.  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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Introduction

This document defines binary formats for IPv4 and IPv6 Traffic Selector sub-options as defined in [I‑D.ietf‑mext‑flow‑binding] (Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K. Kuladinithi, “Flow Bindings in Mobile IPv6 and NEMO Basic Support,” November 2009.).

The binary traffic selector format defined here, allows for efficient identification of flow(s) based on well known fields in IPv4 [RFC0791] (Postel, J., “Internet Protocol,” September 1981.), IPv6 [RFC2460] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.), and transport layer headers like TCP [RFC0793] (Postel, J., “Transmission Control Protocol,” September 1981.) and UDP [RFC0768] (Postel, J., “User Datagram Protocol,” August 1980.).

3.  Traffic Selector Sub-Options

[I‑D.ietf‑mext‑flow‑binding] (Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K. Kuladinithi, “Flow Bindings in Mobile IPv6 and NEMO Basic Support,” November 2009.) 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, N is sett

      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 SPI                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          (F)End 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. |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 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 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 SPI - Security Parameter Index

This field identifies the first 32-bit SPI value, from the range of SPI values to be matched, on data packets as seen by the home agent. This field is defined in [RFC4303] (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.).

(F)End SPI - Security Parameter Index

If more than one contiguous SPI values need to be matched then this field can be used to indicate the end value of a range starting from the value of the Start SPI field. This field MUST NOT be included unless the Start 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 as seen by the home agent. This is from the range of port numbers defined by IANA (http://www.iana.org/assignments/port-numbers)

(H)End Source Port

If more than one contiguous source port numbers need 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 as seen by the home agent.

(J)End Destination Port

If more than one contiguous destination port numbers need 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 as seen by the home agent. Note that this field is called Type of Service field in [RFC0791] (Postel, J., “Internet Protocol,” September 1981.). [RFC3260] (Grossman, D., “New Terminology and Clarifications for Diffserv,” April 2002.) then clarified that the field has been redefined as 6 bits DS field and 2 bits reserved, later claimed by Explicit Congestion Notification (ECN) [RFC3168] (Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP,” September 2001.). For the purpose of this specification the DS field is 8 bits long, were the 6 most significant bits indicating the DS field to be matched and the 2 least significant bits MUST be set to 0 by the sender and ignored by the receiver.

(L)End DS - Differential Services

If more than one contiguous DS values need 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 as seen by the home agent.

(N)End Protocol

If more than one contiguous protocol values need 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 SPI                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          (F)End 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 DS  |  (N)End DS    | (O)Start NH   | (P) End NH    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 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 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 SPI - Security Parameter Index

This field identifies the first 32-bit SPI value, from the range of SPI values to be matched, on data packets as seen by the home agent. This field is defined in [RFC4303] (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.).

(F)End SPI - Security Parameter Index

If more than one contiguous SPI values need to be matched then this field can be used to indicate the end value of a range starting from the value of the Start SPI field. This field MUST NOT be included unless the Start 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 as seen by the home agent. According to [RFC2460] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) the flow label is 24-bit 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 this field. The receiver SHOULD ignore the first 8-bits of this field.

(H)End Flow Label

If more than one contiguous flow label values need 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).

(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 as seen by the home agent.

(J)End Source Port

If more than one contiguous source port numbers need 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 as seen by the home agent.

(L)End Destination Port

If more than one contiguous destination port numbers need 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 DS - Differential Services

This field identifies the first differential services value, from the range of differential services values to be matched, on data packets as seen by the home agent. Note that this field is called Type of Service field in [RFC0791] (Postel, J., “Internet Protocol,” September 1981.). [RFC3260] (Grossman, D., “New Terminology and Clarifications for Diffserv,” April 2002.) then clarified that the field has been redefined as 6 bits DS field and 2 bits reserved, later claimed by Explicit Congestion Notification (ECN) [RFC3168] (Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP,” September 2001.). For the purpose of this specification the DS field is 8 bits long, were the 6 most significant bits indicating the DS field to be matched and the 2 least significant bits MUST be set to 0 by the sender and ignored by the receiver.

(N)End DS - Differential Services

If more than one contiguous DS values need 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 (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 as seen by the home agent.

(P)End NH - Next Header

If more than one contiguous next header values need 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 draft defines the format of the traffic selector field of a sub-option defined for flow bindings [I‑D.ietf‑mext‑flow‑binding] (Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K. Kuladinithi, “Flow Bindings in Mobile IPv6 and NEMO Basic Support,” November 2009.). The authors have not identified any security concerns pertaining to this draft beyond what is already identified in [I‑D.ietf‑mext‑flow‑binding] (Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K. Kuladinithi, “Flow Bindings in Mobile IPv6 and NEMO Basic Support,” November 2009.).

5.  IANA Considerations

1) New TS format values from the "Traffic Selector Format" namespace for the Traffic Selector sub-option defined in [I‑D.ietf‑mext‑flow‑binding] (Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K. Kuladinithi, “Flow Bindings in Mobile IPv6 and NEMO Basic Support,” November 2009.). The following values are requested:

1 IPv4 Binary Traffic Selector

2 IPv6 Binary Traffic Selector

6.  Aknowledgements

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

7.2. Informative References

Authors' Addresses