GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc: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

 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6088.txt · Last modified: 2011/01/28 17:24 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki