One document matched: draft-petithuguenin-behave-stun-pmtud-01.txt
Differences from draft-petithuguenin-behave-stun-pmtud-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 16:13:03 |