idnits 2.17.1 draft-petithuguenin-behave-stun-pmtud-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 287. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2008) is 5772 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-16 == Outdated reference: A later version (-08) exists of draft-ietf-behave-nat-behavior-discovery-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-behave-nat-behavior-discovery (ref. 'I-D.ietf-behave-nat-behavior-discovery') Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Petit-Huguenin 3 Internet-Draft 8x8, Inc. 4 Intended status: Standards Track July 7, 2008 5 Expires: January 8, 2009 7 Path MTU Discovery Using Session Traversal Utilities for NAT (STUN) 8 draft-petithuguenin-behave-stun-pmtud-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 8, 2009. 35 Abstract 37 This document describes a Session Traversal Utilities for NAT (STUN) 38 usage for discovering the Path MTU between a client and a server. 40 Table of Contents 42 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 43 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 3. Probe Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 3 45 3.1. Sending a Probe Request . . . . . . . . . . . . . . . . . . 3 46 3.2. Receiving a Probe Request . . . . . . . . . . . . . . . . . 4 47 3.3. Receiving a Probe Response . . . . . . . . . . . . . . . . 4 48 4. Probe Support Discovery Mechanisms . . . . . . . . . . . . . . 4 49 4.1. Implicit Mechanism . . . . . . . . . . . . . . . . . . . . 4 50 4.2. Probe Support Discovery with TURN . . . . . . . . . . . . . 5 51 4.3. Probe Support Discovery with ICE . . . . . . . . . . . . . 5 52 5. New STUN Method . . . . . . . . . . . . . . . . . . . . . . . . 5 53 6. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . . 5 54 6.1. PADDING-RECEIVED . . . . . . . . . . . . . . . . . . . . . 5 55 6.2. PMTUD-SUPPORTED . . . . . . . . . . . . . . . . . . . . . . 6 56 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 58 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 Intellectual Property and Copyright Statements . . . . . . . . . . 8 62 1. Introduction 64 The Packetization Layer Path MTU Discovery specification [RFC4821] 65 describes a method to discover the PMTU but does not describe a 66 practical protocol to discover the Path MTU when using UDP. 68 This document only describe how the probing mechanism is implemented 69 with STUN. The algorithm to find the Path MTU is described in 70 [RFC4821]. 72 The probing mechanism is implemented by sending a Probe Request with 73 a PADDING [I-D.ietf-behave-nat-behavior-discovery] attribute and the 74 DF bit set over UDP. A router on the path to the server can reject 75 this request with an ICMP message or drop it. The STUN 76 retransmission algorithm is modified so the third and next 77 retransmissions do not include the PADDING attribute, so they are not 78 dropped by an intermediate router. The server responds by indicating 79 if the request received contained the PADDING attribute or not. This 80 permits to quickly find if a probe packet if too big for the Path MTU 81 or not. 83 2. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 3. Probe Mechanism 91 A client MUST NOT send a Probe Request if it does not have knowledge 92 that the server supports this specification. This is done by an 93 external mechanism which is specific to each UDP protocol. Section 4 94 describes some of this mechanisms. 96 The probe mechanism is used to measure the Path MTU in one direction 97 only, from the client to the server. 99 3.1. Sending a Probe Request 101 A client forms a Probe Request by following the rules in 102 [I-D.ietf-behave-rfc3489bis] section 7.1. No authentication method 103 is used. The client adds a PADDING 104 [I-D.ietf-behave-nat-behavior-discovery] attribute with a size that, 105 when added to the IP and UDP headers and the other STUN components, 106 is equal to the Selected Probe Size, as defined in [RFC4821] section 107 7.3. If the IP address and port tuple used as destination for the 108 Probe Request is also used by another protocol then the client MUST 109 add the FINGERPRINT attribute. 111 Then the client sends the Probe Request to the server over UDP. The 112 UDP retransmission mechanism described in 113 [I-D.ietf-behave-rfc3489bis] section 7.2.1 is modified so that if the 114 Probe Request has to be retransmitted three times or more then it is 115 stripped of its PADDING attribute before been sent. The UDP packets 116 MUST be sent with the DF bit set. 118 3.2. Receiving a Probe Request 120 A server receiving a Probe Request MUST process it as specified in 121 [I-D.ietf-behave-rfc3489bis]. The server MUST NOT challenge the 122 client. 124 The server then creates a Probe Response. If the Probe Request 125 contains a PADDING attribute, then a PADDING-RECEIVED attribute is 126 added to the response, with a value equals to the size of the PADDING 127 attribute received. If the IP address and port used to send the 128 Probe Request is also used by another protocol, then the server MUST 129 add the FINGERPRINT attribute. The server then sends the response to 130 the client. 132 3.3. Receiving a Probe Response 134 A client receiving a Probe Response processes it as specified in 135 [I-D.ietf-behave-rfc3489bis]. If the response contains a PADDING- 136 RECEIVED attribute, then this is interpreted as a Probe Success as 137 defined in [RFC4821] section 7.6.1. If an ICMP packet "Fragmentation 138 needed" is received or if the response does not contain a PADDING- 139 RECEIVED attribute, then this is interpreted as a Probe Failure as 140 defined in [RFC4821] section 7.6.2. If the Probe transactions fails 141 in timeout, then this is interpreted as a Probe Inconclusive as 142 defined in [RFC4821] section 7.6.4. 144 4. Probe Support Discovery Mechanisms 146 4.1. Implicit Mechanism 148 An endpoint acting as a client for the STUN usage described in this 149 specification MUST also act as a server for this STUN usage. This 150 means that a server receiving a Probe Request can assumes that it can 151 acts as a client to discover the Path MTU to the IP address and port 152 from which it received the Probe Request. 154 4.2. Probe Support Discovery with TURN 156 A TURN client supporting this STUN usage will add a PMTUD-SUPPORTED 157 attribute to the Allocate Request sent to the TURN server. The TURN 158 server can immediately start to send Probe Requests to the TURN 159 client on reception of an Allocation Request with a PMTUD-SUPPORTED 160 attribute. The TURN client will then use the Implicit Mechanism 161 described above to send probes. 163 4.3. Probe Support Discovery with ICE 165 An ICE [I-D.ietf-mmusic-ice] client supporting this STUN usage will 166 add a PMTUD-SUPPORTED attribute to the Binding Request sent during a 167 connectivity check. The ICE server can immediately start to send 168 Probe Requests to the ICE client on reception of a Binding Request 169 with a PMTUD-SUPPORTED attributed. The ICE client will then use the 170 Implicit Mechanism described above to send probes. 172 5. New STUN Method 174 This specification defines one new STUN method: 176 Request/Response Transaction 177 0x801 : Probe 179 6. New STUN Attributes 181 This specification defines the following new STUN attributes: 183 0x4001 : PADDING-RECEIVED 184 0xC002 : PMTUD-SUPPORTED 186 6.1. PADDING-RECEIVED 188 The PADDING-RECEIVED attribute contains the size of the PADDING 189 attribute received. It is a 16-bit unsigned integer, followed by two 190 reserved bytes which MUST be set to 0 on transmission and MUST be 191 ignored on reception. 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Padding size | Reserved | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 6.2. PMTUD-SUPPORTED 201 The PMTUD-SUPPORTED attribute is used in STUN usages and extensions 202 to signal the support of this specification. This attribute has no 203 content. 205 7. Security Considerations 207 TBD 209 8. IANA Considerations 211 TBD 213 9. Normative References 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, March 1997. 218 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 219 Discovery", RFC 4821, March 2007. 221 [I-D.ietf-behave-rfc3489bis] 222 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 223 "Session Traversal Utilities for (NAT) (STUN)", 224 draft-ietf-behave-rfc3489bis-16 (work in progress), 225 July 2008. 227 [I-D.ietf-behave-nat-behavior-discovery] 228 MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 229 Using STUN", draft-ietf-behave-nat-behavior-discovery-03 230 (work in progress), February 2008. 232 [I-D.ietf-mmusic-ice] 233 Rosenberg, J., "Interactive Connectivity Establishment 234 (ICE): A Protocol for Network Address Translator (NAT) 235 Traversal for Offer/Answer Protocols", 236 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 238 Author's Address 240 Marc Petit-Huguenin 241 8x8, Inc. 242 3151 Jay Street 243 Santa Clara, CA 95054 244 US 246 Phone: +1 408 654 0875 247 Email: marc@8x8.com 249 Full Copyright Statement 251 Copyright (C) The IETF Trust (2008). 253 This document is subject to the rights, licenses and restrictions 254 contained in BCP 78, and except as set forth therein, the authors 255 retain all their rights. 257 This document and the information contained herein are provided on an 258 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 259 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 260 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 261 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 262 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 263 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 265 Intellectual Property 267 The IETF takes no position regarding the validity or scope of any 268 Intellectual Property Rights or other rights that might be claimed to 269 pertain to the implementation or use of the technology described in 270 this document or the extent to which any license under such rights 271 might or might not be available; nor does it represent that it has 272 made any independent effort to identify any such rights. Information 273 on the procedures with respect to rights in RFC documents can be 274 found in BCP 78 and BCP 79. 276 Copies of IPR disclosures made to the IETF Secretariat and any 277 assurances of licenses to be made available, or the result of an 278 attempt made to obtain a general license or permission for the use of 279 such proprietary rights by implementers or users of this 280 specification can be obtained from the IETF on-line IPR repository at 281 http://www.ietf.org/ipr. 283 The IETF invites any interested party to bring to its attention any 284 copyrights, patents or patent applications, or other proprietary 285 rights that may cover technology that may be required to implement 286 this standard. Please address the information to the IETF at 287 ietf-ipr@ietf.org.