idnits 2.17.1 draft-petithuguenin-behave-stun-pmtud-01.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 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 373. 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 14, 2008) is 5764 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 14, 2008 5 Expires: January 15, 2009 7 Path MTU Discovery Using Session Traversal Utilities for NAT (STUN) 8 draft-petithuguenin-behave-stun-pmtud-01 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 15, 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. Probing Mechanisms . . . . . . . . . . . . . . . . . . . . . . 3 45 4. Simple Probing Mechanism . . . . . . . . . . . . . . . . . . . 4 46 4.1. Sending a Probe Request . . . . . . . . . . . . . . . . . . 4 47 4.2. Receiving a Probe Request . . . . . . . . . . . . . . . . . 4 48 4.3. Receiving a Probe Response . . . . . . . . . . . . . . . . 4 49 5. Complete Probing Mechanism . . . . . . . . . . . . . . . . . . 4 50 5.1. Sending the Probe Indications and Report Request . . . . . 4 51 5.2. Receiving a Report Request . . . . . . . . . . . . . . . . 5 52 5.3. Receiving a Report Response . . . . . . . . . . . . . . . . 5 53 6. Probe Support Discovery Mechanisms . . . . . . . . . . . . . . 6 54 6.1. Implicit Mechanism . . . . . . . . . . . . . . . . . . . . 6 55 6.2. Probe Support Discovery with TURN . . . . . . . . . . . . . 6 56 6.3. Probe Support Discovery with ICE . . . . . . . . . . . . . 6 57 7. New STUN Method . . . . . . . . . . . . . . . . . . . . . . . . 6 58 8. New STUN Attributes . . . . . . . . . . . . . . . . . . . . . . 6 59 8.1. TRANSACTION-IDS . . . . . . . . . . . . . . . . . . . . . . 7 60 8.2. PMTUD-SUPPORTED . . . . . . . . . . . . . . . . . . . . . . 7 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 12. Normative References . . . . . . . . . . . . . . . . . . . . . 7 65 Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 8 66 A.1. Modifications between -01 and -00 . . . . . . . . . . . . . 8 67 A.2. TODO List . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 Intellectual Property and Copyright Statements . . . . . . . . . . 9 71 1. Introduction 73 The Packetization Layer Path MTU Discovery specification [RFC4821] 74 describes a method to discover the path MTU but does not describe a 75 practical protocol to do so with UDP. 77 This document only describe how the probing mechanisms are 78 implemented with STUN. The algorithm to find the path MTU is 79 described in [RFC4821]. 81 Two probing mechanisms are described, a simple probing mechanism and 82 a more complete mechanism that can converge quicker. 84 The simple probing mechanism is implemented by sending a Probe 85 Request with a PADDING [I-D.ietf-behave-nat-behavior-discovery] 86 attribute and the DF bit set over UDP. A router on the path to the 87 server can reject this request with an ICMP message or drop it. The 88 client SHOULD cease retransmissions after 3 missing responses. 90 The complete probing mechanism is implemented by sending one or more 91 Probe Indication with a PADDING attribute and the DF bit set over UDP 92 then a Report Request to the same server. A router on the path to 93 the server can reject this indication with an ICMP message or drop 94 it. The server keeps a time ordered list of transaction identifiers 95 of all STUN requests and indications received (including 96 retransmitted requests) and sends this list back to the client in the 97 Report Response. The client analyzes this list to find which packets 98 were not received. 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Probing Mechanisms 108 A client MUST NOT send a probe if it does not have knowledge that the 109 server supports this specification. This is done by an external 110 mechanism which is specific to each UDP protocol. Section 6 111 describes some of this mechanisms. 113 The probe mechanism is used to measure the path MTU in one direction 114 only, from the client to the server. 116 4. Simple Probing Mechanism 118 4.1. Sending a Probe Request 120 A client forms a Probe Request by following the rules in 121 [I-D.ietf-behave-rfc3489bis] section 7.1. No authentication method 122 is used. The client adds a PADDING 123 [I-D.ietf-behave-nat-behavior-discovery] attribute with a size that, 124 when added to the IP and UDP headers and the other STUN components, 125 is equal to the Selected Probe Size, as defined in [RFC4821] section 126 7.3. If the IP address and port tuple used as destination for the 127 Probe Request is also used by another protocol then the client MUST 128 add the FINGERPRINT attribute. 130 Then the client sends the Probe Request to the server over UDP with 131 the DF bit set. The client SHOULD stop sending after 3 missing 132 responses. 134 4.2. Receiving a Probe Request 136 A server receiving a Probe Request MUST process it as specified in 137 [I-D.ietf-behave-rfc3489bis]. The server MUST NOT challenge the 138 client. 140 The server then creates a Probe Response. If the IP address and port 141 to which the Probe Request will be sent is also used by another 142 protocol, then the server MUST add the FINGERPRINT attribute. The 143 server then sends the response to the client. 145 4.3. Receiving a Probe Response 147 A client receiving a Probe Response processes it as specified in 148 [I-D.ietf-behave-rfc3489bis]. If a response is received this is 149 interpreted as a Probe Success as defined in [RFC4821] section 7.6.1. 150 If an ICMP packet "Fragmentation needed" is received then this is 151 interpreted as a Probe Failure as defined in [RFC4821] section 7.6.2. 152 If the Probe transactions fails in timeout, then this is interpreted 153 as a Probe Inconclusive as defined in [RFC4821] section 7.6.4. 155 5. Complete Probing Mechanism 157 5.1. Sending the Probe Indications and Report Request 159 A client forms one or more Probe Indication by following the rules in 160 [I-D.ietf-behave-rfc3489bis] section 7.1. The client adds to each 161 Probe Indication a PADDING attribute with a size that, when added to 162 the IP and UDP headers and the other STUN components, is equal to the 163 Selected Probe Size, as defined in [RFC4821] section 7.3. Each Probe 164 Indication uses a different Selected Probe Size. If the IP address 165 and port tuple used as destination for the Probe Indication is also 166 used by another protocol then the client MUST add the FINGERPRINT 167 attribute. 169 Then the client sends the Probe Indication to the server over UDP 170 with the DF bit set. The client must wait 10 milliseconds before 171 sending the next Probe Indication. 173 Then the client forms a Report Request by following the rules in 174 [I-D.ietf-behave-rfc3489bis] section 7.1. No authentication method 175 is used. If the IP address and port tuple used as destination for 176 the Report Request is also used by another protocol then the client 177 MUST add the FINGERPRINT attribute. 179 Then the client waits RTO milliseconds after the last Probe 180 Indication and sends the Report Request to the server over UDP. 182 5.2. Receiving a Report Request 184 A server supporting this specification and knowing that the client 185 also supports it will keep the transaction identifiers of all 186 Requests and Indications received in a list ordered by time. A 187 transaction identifier can appear multiple times in the list because 188 of retransmission. The maximum size of this list is calculated so 189 that when the list is added to the Report Response, the total size of 190 the packet does not exceed the unknown path MTU as defined in 191 [I-D.ietf-behave-rfc3489bis] section 7.1. Older transactions 192 identifiers are removed when new transaction identifiers must be 193 added to a list already full. 195 A server receiving a Report Request MUST process it as specified in 196 [I-D.ietf-behave-rfc3489bis]. The server MUST NOT challenge the 197 client. 199 The server creates a Report Response and adds a TRANSACTION-IDS 200 attribute that contains the list of all transaction identifiers 201 received so far. If the IP address and port to which the Report 202 Request will be sent is also used by another protocol, then the 203 server MUST add the FINGERPRINT attribute. The server then sends the 204 response to the client. 206 5.3. Receiving a Report Response 208 A client receiving a Report Response processes it as specified in 209 [I-D.ietf-behave-rfc3489bis]. If the response TRANSACTION-IDS 210 attribute contains the transaction identifiers of some of the Probe 211 Indications, then this is interpreted as a Probe Success for this 212 probes as defined in [RFC4821] section 7.6.1. For the Probe 213 Indications that cannot be found in the Report Response, this is 214 interpreted as a Probe Failure as defined in [RFC4821] section 7.6.2. 216 6. Probe Support Discovery Mechanisms 218 6.1. Implicit Mechanism 220 An endpoint acting as a client for the STUN usage described in this 221 specification MUST also act as a server for this STUN usage. This 222 means that a server receiving a probe can assumes that it can acts as 223 a client to discover the path MTU to the IP address and port from 224 which it received the probe. 226 6.2. Probe Support Discovery with TURN 228 A TURN client supporting this STUN usage will add a PMTUD-SUPPORTED 229 attribute to the Allocate Request sent to the TURN server. The TURN 230 server can immediately start to send probes to the TURN client on 231 reception of an Allocation Request with a PMTUD-SUPPORTED attribute. 232 The TURN client will then use the Implicit Mechanism described above 233 to send probes. 235 6.3. Probe Support Discovery with ICE 237 An ICE [I-D.ietf-mmusic-ice] client supporting this STUN usage will 238 add a PMTUD-SUPPORTED attribute to the Binding Request sent during a 239 connectivity check. The ICE server can immediately start to send 240 probes to the ICE client on reception of a Binding Request with a 241 PMTUD-SUPPORTED attributed. The ICE client will then use the 242 Implicit Mechanism described above to send probes. 244 7. New STUN Method 246 This specification defines the following new STUN methods: 248 0x201 : Probe 249 0x202 : Report 251 8. New STUN Attributes 253 This specification defines the following new STUN attributes: 255 0x8001 : TRANSACTION-IDS 256 0xC001 : PMTUD-SUPPORTED 258 8.1. TRANSACTION-IDS 260 The TRANSACTION-IDS attribute is used in Report Response. It 261 contains a list of 96 bit transaction identifiers. 263 8.2. PMTUD-SUPPORTED 265 The PMTUD-SUPPORTED attribute is used in STUN usages and extensions 266 to signal the support of this specification. This attribute has no 267 content. 269 9. Security Considerations 271 TBD 273 10. IANA Considerations 275 TBD 277 11. Acknowledgements 279 Thanks to Dan Wing for his comments, suggestions and questions that 280 helped to improve this document. 282 12. Normative References 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 288 Discovery", RFC 4821, March 2007. 290 [I-D.ietf-behave-rfc3489bis] 291 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 292 "Session Traversal Utilities for (NAT) (STUN)", 293 draft-ietf-behave-rfc3489bis-16 (work in progress), 294 July 2008. 296 [I-D.ietf-behave-nat-behavior-discovery] 297 MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 298 Using STUN", draft-ietf-behave-nat-behavior-discovery-03 299 (work in progress), February 2008. 301 [I-D.ietf-mmusic-ice] 302 Rosenberg, J., "Interactive Connectivity Establishment 303 (ICE): A Protocol for Network Address Translator (NAT) 304 Traversal for Offer/Answer Protocols", 305 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 307 Appendix A. Release notes 309 This section must be removed before publication as an RFC. 311 A.1. Modifications between -01 and -00 313 o Removed the use of modified STUN transaction but shorten the 314 restranmission for the simple probing mechanism. 315 o Added a complete probing mechanism. 316 o Removed the PADDING-RECEIVED attribute. 317 o Added release notes. 319 A.2. TODO List 321 o Add reference to RFC 1191 section 7.1 table and add 9000 MTU 322 (jumbogram) entry in the table. 324 Author's Address 326 Marc Petit-Huguenin 327 8x8, Inc. 328 3151 Jay Street 329 Santa Clara, CA 95054 330 US 332 Phone: +1 408 654 0875 333 Email: marc@8x8.com 335 Full Copyright Statement 337 Copyright (C) The IETF Trust (2008). 339 This document is subject to the rights, licenses and restrictions 340 contained in BCP 78, and except as set forth therein, the authors 341 retain all their rights. 343 This document and the information contained herein are provided on an 344 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 345 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 346 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 347 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 348 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 349 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 351 Intellectual Property 353 The IETF takes no position regarding the validity or scope of any 354 Intellectual Property Rights or other rights that might be claimed to 355 pertain to the implementation or use of the technology described in 356 this document or the extent to which any license under such rights 357 might or might not be available; nor does it represent that it has 358 made any independent effort to identify any such rights. Information 359 on the procedures with respect to rights in RFC documents can be 360 found in BCP 78 and BCP 79. 362 Copies of IPR disclosures made to the IETF Secretariat and any 363 assurances of licenses to be made available, or the result of an 364 attempt made to obtain a general license or permission for the use of 365 such proprietary rights by implementers or users of this 366 specification can be obtained from the IETF on-line IPR repository at 367 http://www.ietf.org/ipr. 369 The IETF invites any interested party to bring to its attention any 370 copyrights, patents or patent applications, or other proprietary 371 rights that may cover technology that may be required to implement 372 this standard. Please address the information to the IETF at 373 ietf-ipr@ietf.org.