doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc6088.txt b/doc/rfc/rfc6088.txt
new file mode 100644
index 0000000..3bb2393
--- /dev/null
+++ b/doc/rfc/rfc6088.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+Tsirtsis, et al.             Standards Track                    [Page 1]
+
+RFC 6088           Traffic Selectors for Flow Bindings      January 2011
+
+
+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.
+
+
+
+Tsirtsis, et al.             Standards Track                    [Page 2]
+
+RFC 6088           Traffic Selectors for Flow Bindings      January 2011
+
+
+   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.
+
+
+
+Tsirtsis, et al.             Standards Track                    [Page 3]
+
+RFC 6088           Traffic Selectors for Flow Bindings      January 2011
+
+
+   (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).
+
+
+
+
+
+
+
+
+Tsirtsis, et al.             Standards Track                    [Page 4]
+
+RFC 6088           Traffic Selectors for Flow Bindings      January 2011
+
+
+   (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.
+
+
+
+Tsirtsis, et al.             Standards Track                    [Page 5]
+
+RFC 6088           Traffic Selectors for Flow Bindings      January 2011
+
+
+   (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
+
+
+
+
+
+
+Tsirtsis, et al.             Standards Track                    [Page 6]
+
+RFC 6088           Traffic Selectors for Flow Bindings      January 2011
+
+
+     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          |
+
+
+
+Tsirtsis, et al.             Standards Track                    [Page 7]
+
+RFC 6088           Traffic Selectors for Flow Bindings      January 2011
+
+
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   (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).
+
+
+
+Tsirtsis, et al.             Standards Track                    [Page 8]
+
+RFC 6088           Traffic Selectors for Flow Bindings      January 2011
+
+
+   (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.
+
+
+
+
+
+
+
+Tsirtsis, et al.             Standards Track                    [Page 9]
+
+RFC 6088           Traffic Selectors for Flow Bindings      January 2011
+
+
+   (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
+
+
+
+
+Tsirtsis, et al.             Standards Track                   [Page 10]
+
+RFC 6088           Traffic Selectors for Flow Bindings      January 2011
+
+
+      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.
+
+
+
+Tsirtsis, et al.             Standards Track                   [Page 11]
+
+RFC 6088           Traffic Selectors for Flow Bindings      January 2011
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsirtsis, et al.             Standards Track                   [Page 12]
+
+RFC 6088           Traffic Selectors for Flow Bindings      January 2011
+
+
+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//
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsirtsis, et al.             Standards Track                   [Page 13]
+