[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-petithuguenin-tram-stun-pmtud

Network Working Group                                  M. Petit-Huguenin
Internet-Draft                                                 8x8, Inc.
Intended status: Standards Track                           July 14, 2008
Expires: January 15, 2009


  Path MTU Discovery Using Session Traversal Utilities for NAT (STUN)
                draft-petithuguenin-behave-stun-pmtud-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 January 15, 2009.

Abstract

   This document describes a Session Traversal Utilities for NAT (STUN)
   usage for discovering the path MTU between a client and a server.













Petit-Huguenin          Expires January 15, 2009                [Page 1]


Internet-Draft                  TURN URIs                      July 2008


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Probing Mechanisms  . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Simple Probing Mechanism  . . . . . . . . . . . . . . . . . . . 4
     4.1.  Sending a Probe Request . . . . . . . . . . . . . . . . . . 4
     4.2.  Receiving a Probe Request . . . . . . . . . . . . . . . . . 4
     4.3.  Receiving a Probe Response  . . . . . . . . . . . . . . . . 4
   5.  Complete Probing Mechanism  . . . . . . . . . . . . . . . . . . 4
     5.1.  Sending the Probe Indications and Report Request  . . . . . 4
     5.2.  Receiving a Report Request  . . . . . . . . . . . . . . . . 5
     5.3.  Receiving a Report Response . . . . . . . . . . . . . . . . 5
   6.  Probe Support Discovery Mechanisms  . . . . . . . . . . . . . . 6
     6.1.  Implicit Mechanism  . . . . . . . . . . . . . . . . . . . . 6
     6.2.  Probe Support Discovery with TURN . . . . . . . . . . . . . 6
     6.3.  Probe Support Discovery with ICE  . . . . . . . . . . . . . 6
   7.  New STUN Method . . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  New STUN Attributes . . . . . . . . . . . . . . . . . . . . . . 6
     8.1.  TRANSACTION-IDS . . . . . . . . . . . . . . . . . . . . . . 7
     8.2.  PMTUD-SUPPORTED . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   12. Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Appendix A.  Release notes  . . . . . . . . . . . . . . . . . . . . 8
     A.1.  Modifications between -01 and -00 . . . . . . . . . . . . . 8
     A.2.  TODO List . . . . . . . . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9





















Petit-Huguenin          Expires January 15, 2009                [Page 2]


Internet-Draft                  TURN URIs                      July 2008


1.  Introduction

   The Packetization Layer Path MTU Discovery specification [RFC4821]
   describes a method to discover the path MTU but does not describe a
   practical protocol to do so with UDP.

   This document only describe how the probing mechanisms are
   implemented with STUN.  The algorithm to find the path MTU is
   described in [RFC4821].

   Two probing mechanisms are described, a simple probing mechanism and
   a more complete mechanism that can converge quicker.

   The simple probing mechanism is implemented by sending a Probe
   Request with a PADDING [I-D.ietf-behave-nat-behavior-discovery]
   attribute and the DF bit set over UDP.  A router on the path to the
   server can reject this request with an ICMP message or drop it.  The
   client SHOULD cease retransmissions after 3 missing responses.

   The complete probing mechanism is implemented by sending one or more
   Probe Indication with a PADDING attribute and the DF bit set over UDP
   then a Report Request to the same server.  A router on the path to
   the server can reject this indication with an ICMP message or drop
   it.  The server keeps a time ordered list of transaction identifiers
   of all STUN requests and indications received (including
   retransmitted requests) and sends this list back to the client in the
   Report Response.  The client analyzes this list to find which packets
   were not received.


2.  Terminology

   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.  Probing Mechanisms

   A client MUST NOT send a probe if it does not have knowledge that the
   server supports this specification.  This is done by an external
   mechanism which is specific to each UDP protocol.  Section 6
   describes some of this mechanisms.

   The probe mechanism is used to measure the path MTU in one direction
   only, from the client to the server.





Petit-Huguenin          Expires January 15, 2009                [Page 3]


Internet-Draft                  TURN URIs                      July 2008


4.  Simple Probing Mechanism

4.1.  Sending a Probe Request

   A client forms a Probe Request by following the rules in
   [I-D.ietf-behave-rfc3489bis] section 7.1.  No authentication method
   is used.  The client adds a PADDING
   [I-D.ietf-behave-nat-behavior-discovery] attribute with a size that,
   when added to the IP and UDP headers and the other STUN components,
   is equal to the Selected Probe Size, as defined in [RFC4821] section
   7.3.  If the IP address and port tuple used as destination for the
   Probe Request is also used by another protocol then the client MUST
   add the FINGERPRINT attribute.

   Then the client sends the Probe Request to the server over UDP with
   the DF bit set.  The client SHOULD stop sending after 3 missing
   responses.

4.2.  Receiving a Probe Request

   A server receiving a Probe Request MUST process it as specified in
   [I-D.ietf-behave-rfc3489bis].  The server MUST NOT challenge the
   client.

   The server then creates a Probe Response.  If the IP address and port
   to which the Probe Request will be sent is also used by another
   protocol, then the server MUST add the FINGERPRINT attribute.  The
   server then sends the response to the client.

4.3.  Receiving a Probe Response

   A client receiving a Probe Response processes it as specified in
   [I-D.ietf-behave-rfc3489bis].  If a response is received this is
   interpreted as a Probe Success as defined in [RFC4821] section 7.6.1.
   If an ICMP packet "Fragmentation needed" is received then this is
   interpreted as a Probe Failure as defined in [RFC4821] section 7.6.2.
   If the Probe transactions fails in timeout, then this is interpreted
   as a Probe Inconclusive as defined in [RFC4821] section 7.6.4.


5.  Complete Probing Mechanism

5.1.  Sending the Probe Indications and Report Request

   A client forms one or more Probe Indication by following the rules in
   [I-D.ietf-behave-rfc3489bis] section 7.1.  The client adds to each
   Probe Indication a PADDING attribute with a size that, when added to
   the IP and UDP headers and the other STUN components, is equal to the



Petit-Huguenin          Expires January 15, 2009                [Page 4]


Internet-Draft                  TURN URIs                      July 2008


   Selected Probe Size, as defined in [RFC4821] section 7.3.  Each Probe
   Indication uses a different Selected Probe Size.  If the IP address
   and port tuple used as destination for the Probe Indication is also
   used by another protocol then the client MUST add the FINGERPRINT
   attribute.

   Then the client sends the Probe Indication to the server over UDP
   with the DF bit set.  The client must wait 10 milliseconds before
   sending the next Probe Indication.

   Then the client forms a Report Request by following the rules in
   [I-D.ietf-behave-rfc3489bis] section 7.1.  No authentication method
   is used.  If the IP address and port tuple used as destination for
   the Report Request is also used by another protocol then the client
   MUST add the FINGERPRINT attribute.

   Then the client waits RTO milliseconds after the last Probe
   Indication and sends the Report Request to the server over UDP.

5.2.  Receiving a Report Request

   A server supporting this specification and knowing that the client
   also supports it will keep the transaction identifiers of all
   Requests and Indications received in a list ordered by time.  A
   transaction identifier can appear multiple times in the list because
   of retransmission.  The maximum size of this list is calculated so
   that when the list is added to the Report Response, the total size of
   the packet does not exceed the unknown path MTU as defined in
   [I-D.ietf-behave-rfc3489bis] section 7.1.  Older transactions
   identifiers are removed when new transaction identifiers must be
   added to a list already full.

   A server receiving a Report Request MUST process it as specified in
   [I-D.ietf-behave-rfc3489bis].  The server MUST NOT challenge the
   client.

   The server creates a Report Response and adds a TRANSACTION-IDS
   attribute that contains the list of all transaction identifiers
   received so far.  If the IP address and port to which the Report
   Request will be sent is also used by another protocol, then the
   server MUST add the FINGERPRINT attribute.  The server then sends the
   response to the client.

5.3.  Receiving a Report Response

   A client receiving a Report Response processes it as specified in
   [I-D.ietf-behave-rfc3489bis].  If the response TRANSACTION-IDS
   attribute contains the transaction identifiers of some of the Probe



Petit-Huguenin          Expires January 15, 2009                [Page 5]


Internet-Draft                  TURN URIs                      July 2008


   Indications, then this is interpreted as a Probe Success for this
   probes as defined in [RFC4821] section 7.6.1.  For the Probe
   Indications that cannot be found in the Report Response, this is
   interpreted as a Probe Failure as defined in [RFC4821] section 7.6.2.


6.  Probe Support Discovery Mechanisms

6.1.  Implicit Mechanism

   An endpoint acting as a client for the STUN usage described in this
   specification MUST also act as a server for this STUN usage.  This
   means that a server receiving a probe can assumes that it can acts as
   a client to discover the path MTU to the IP address and port from
   which it received the probe.

6.2.  Probe Support Discovery with TURN

   A TURN client supporting this STUN usage will add a PMTUD-SUPPORTED
   attribute to the Allocate Request sent to the TURN server.  The TURN
   server can immediately start to send probes to the TURN client on
   reception of an Allocation Request with a PMTUD-SUPPORTED attribute.
   The TURN client will then use the Implicit Mechanism described above
   to send probes.

6.3.  Probe Support Discovery with ICE

   An ICE [I-D.ietf-mmusic-ice] client supporting this STUN usage will
   add a PMTUD-SUPPORTED attribute to the Binding Request sent during a
   connectivity check.  The ICE server can immediately start to send
   probes to the ICE client on reception of a Binding Request with a
   PMTUD-SUPPORTED attributed.  The ICE client will then use the
   Implicit Mechanism described above to send probes.


7.  New STUN Method

   This specification defines the following new STUN methods:

      0x201 : Probe
      0x202 : Report


8.  New STUN Attributes

   This specification defines the following new STUN attributes:





Petit-Huguenin          Expires January 15, 2009                [Page 6]


Internet-Draft                  TURN URIs                      July 2008


      0x8001 : TRANSACTION-IDS
      0xC001 : PMTUD-SUPPORTED

8.1.  TRANSACTION-IDS

   The TRANSACTION-IDS attribute is used in Report Response.  It
   contains a list of 96 bit transaction identifiers.

8.2.  PMTUD-SUPPORTED

   The PMTUD-SUPPORTED attribute is used in STUN usages and extensions
   to signal the support of this specification.  This attribute has no
   content.


9.  Security Considerations

   TBD


10.  IANA Considerations

   TBD


11.  Acknowledgements

   Thanks to Dan Wing for his comments, suggestions and questions that
   helped to improve this document.


12.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, March 2007.

   [I-D.ietf-behave-rfc3489bis]
              Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for (NAT) (STUN)",
              draft-ietf-behave-rfc3489bis-16 (work in progress),
              July 2008.

   [I-D.ietf-behave-nat-behavior-discovery]
              MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
              Using STUN", draft-ietf-behave-nat-behavior-discovery-03



Petit-Huguenin          Expires January 15, 2009                [Page 7]


Internet-Draft                  TURN URIs                      July 2008


              (work in progress), February 2008.

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address  Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.


Appendix A.  Release notes

   This section must be removed before publication as an RFC.

A.1.  Modifications between -01 and -00

   o  Removed the use of modified STUN transaction but shorten the
      restranmission for the simple probing mechanism.
   o  Added a complete probing mechanism.
   o  Removed the PADDING-RECEIVED attribute.
   o  Added release notes.

A.2.  TODO List

   o  Add reference to RFC 1191 section 7.1 table and add 9000 MTU
      (jumbogram) entry in the table.


Author's Address

   Marc Petit-Huguenin
   8x8, Inc.
   3151 Jay Street
   Santa Clara, CA  95054
   US

   Phone: +1 408 654 0875
   Email: marc@8x8.com














Petit-Huguenin          Expires January 15, 2009                [Page 8]


Internet-Draft                  TURN URIs                      July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Petit-Huguenin          Expires January 15, 2009                [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/