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]