idnits 2.17.1 draft-petithuguenin-behave-turn-uris-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5928]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 13, 2013) is 3938 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) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE M. Petit-Huguenin 3 Internet-Draft Impedance Mismatch 4 Intended status: Standards Track S. Nandakumar 5 Expires: January 14, 2014 G. Salgueiro 6 P. Jones 7 Cisco Systems 8 July 13, 2013 10 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers 11 draft-petithuguenin-behave-turn-uris-05 13 Abstract 15 This document specifies the syntax of Uniform Resource Identifier 16 (URI) schemes for the Traversal Using Relays around NAT (TURN) 17 protocol. It defines two URI schemes to provision the TURN 18 Resolution Mechanism [RFC5928]. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 14, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Definitions of the TURN and TURNS URI . . . . . . . . . . . . 3 57 3.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 3 58 3.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . 4 59 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 60 4.1. turnuri . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.2. libjingle . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.3. Firefox . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 6.1. TURN URI Registration . . . . . . . . . . . . . . . . . . 6 66 6.2. TURNS URI Registration . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 9 72 Appendix B. Design Notes . . . . . . . . . . . . . . . . . . . . 9 73 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 10 74 C.1. Modifications between petithuguenin-behave-turn-uris-05 75 and petithuguenin-behave-turn-uris-04 . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 This document specifies the syntax and semantics of the Uniform 81 Resource Identifier (URI) scheme for the Traversal Using Relays 82 around NAT (TURN) protocol. 84 The TURN protocol is a specification allowing hosts behind NAT to 85 control the operation of a relay server. The relay server allows 86 hosts to exchange packets with its peers. The peers themselves may 87 also be behind NATs. RFC 5766 [RFC5766] defines the specifics of the 88 TURN protocol. 90 The "turn" and "turns" URI schemes are used to designate a TURN 91 server (also known as a relay) on Internet hosts accessible using the 92 TURN protocol. With the advent of standards such as [WEBRTC], we 93 anticipate a plethora of endpoints and web applications to be able to 94 identify and communicate with such a TURN server to carry out the 95 TURN protocol. This also implies those endpoints and/or applications 96 to be provisioned with appropriate configuration required to identify 97 the TURN server. Having an inconsistent syntax has its drawbacks and 98 can result in non-interoperable solutions. It can result in 99 solutions that are ambiguous and have implementation limitations on 100 the different aspects of the syntax and alike. The "turn/turns" URI 101 scheme helps alleviate most of these issues by providing a consistent 102 way to describe, configure and exchange the information identifying a 103 TURN server. This would also prevent the shortcomings inherent with 104 encoding similar information in non-uniform syntaxes such as the ones 105 proposed in [WEBRTC], for example. 107 [RFC5928] defines a resolution mechanism to convert a secure flag, a 108 host name or IP address, an eventually empty port, and an eventually 109 empty transport to a list of IP address, port, and TURN transport 110 tuples. 112 To simplify the provisioning of TURN clients, this document defines a 113 TURN and a TURNS URI scheme that can carry the four components needed 114 for the resolution mechanism. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" 119 in this document are to be interpreted as described in [RFC2119] when 120 they appear in ALL CAPS. When these words are not in ALL CAPS (such 121 as "should" or "Should"), they have their usual english meanings, and 122 are not to be interpreted as RFC 2119 key words. 124 3. Definitions of the TURN and TURNS URI 126 3.1. URI Scheme Syntax 128 A TURN/TURNS URI has the following formal ABNF syntax [RFC5234]: 130 turnURI = scheme ":" turn-host [ ":" turn-port ] 131 [ "?transport=" transport ] 132 scheme = "turn" / "turns" 133 transport = "udp" / "tcp" / transport-ext 134 transport-ext = 1*unreserved 135 turn-host = IP-literal / IPv4address / reg-name 136 turn-port = *DIGIT 137 IP-literal = "[" ( IPv6address / IPvFuture ) "]" 138 IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) 139 IPv6address = 6( h16 ":" ) ls32 140 / "::" 5( h16 ":" ) ls32 141 / [ h16 ] "::" 4( h16 ":" ) ls32 142 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 143 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 144 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 145 / [ *4( h16 ":" ) h16 ] "::" ls32 146 / [ *5( h16 ":" ) h16 ] "::" h16 147 / [ *6( h16 ":" ) h16 ] "::" 148 h16 = 1*4HEXDIG 149 ls32 = ( h16 ":" h16 ) / IPv4address 150 IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet 151 dec-octet = DIGIT ; 0-9 152 / %x31-39 DIGIT ; 10-99 153 / "1" 2DIGIT ; 100-199 154 / "2" %x30-34 DIGIT ; 200-249 155 / "25" %x30-35 ; 250-255 156 reg-name = *( unreserved / pct-encoded / sub-delims ) 158 , , and are specified in 159 [RFC3986]. The core rules and are used as 160 described in Appendix B of RFC 5234 [RFC5234]. 162 The , and components are passed without 163 modification to the [RFC5928] algorithm. is set to false if 164 is equal to "turn" and set to true if is equal to 165 "turns" and passed to the [RFC5928] algorithm with the other 166 components. 168 3.2. URI Scheme Semantics 170 The TURN protocol supports sending messages over UDP, TCP or TLS- 171 over-TCP. The "turns" URI scheme MUST be used when TURN is run over 172 TLS-over-TCP (or in the future DTLS-over-UDP) and the "turn" scheme 173 MUST be used otherwise. 175 The required part of the "turn" URI denotes the TURN server 176 host. 178 The part, if present, denotes the port on which the TURN 179 server is awaiting connection requests. If it is absent, the default 180 port is 3478 for both UDP and TCP. The default port for TURN over 181 TLS is 5349. 183 4. Implementation Status 185 Note to RFC Editor: Please remove this section before publication. 187 This section records the status of known implementations of the 188 protocol defined by this specification at the time of posting of this 189 Internet-Draft, and is based on a proposal described in 190 [RUNNING-CODE]. According to [RUNNING-CODE], "this will allow 191 reviewers and working groups to assign due consideration to documents 192 that have the benefit of running code, by considering the running 193 code as evidence of valuable experimentation and feedback that has 194 made the implemented protocols more mature. It is up to the 195 individual working groups to use this information as they see fit". 197 4.1. turnuri 199 Organization: Impedance Mismatch 201 Name: turnuri 0.3.4 203 Description: A reference implementation of this document and of RFC 204 5928 [RFC5928]. 206 Level of maturity: Beta. 208 Coverage: Fully implements this specification and RFC 5928. 210 Licensing: AGPL3 212 Contact: Marc Petit-Huguenin . http:// 213 debian.implementers.org/stable/source/turnuri.tar.gz 215 4.2. libjingle 217 Organization: Google Inc. 219 Name: libjingle 0.7.1 221 Description: Libjingle is a set of components provided by Google to 222 implement Jingle protocols XEP-166 (http://xmpp.org/extensions/ 223 xep-0166.html) and XEP-167 (http://xmpp.org/extensions/ 224 xep-0167.html). 226 Level of maturity: Beta. 228 Coverage: Implements draft-petithuguenin-behave-turn-uris-01 229 without IPv6. 231 Licensing: BSD 3-clauses license. 233 Contact: https://code.google.com/p/chromium/ https:// 234 code.google.com/p/chromium/codesearch#chromium/src/third_party/ 235 libjingle/source/talk/app/webrtc/peerconnection.cc 237 4.3. Firefox 239 Organization: Mozilla 240 Name: Firefox Aurora 21 242 Description: Mozilla Firefox is a free and open source web browser. 244 Level of maturity: Beta. 246 Coverage: Implements draft-petithuguenin-behave-turn-uri-03 without 247 RFC 5928. 249 Licensing: Mozilla Public License, v2.0. 251 Contact: http://www.mozilla.org/en-US/firefox/channel/ http:// 252 hg.mozilla.org/mozilla-central/rev/6b5016ab9ebb 254 5. Security Considerations 256 Security considerations for the resolution mechanism are discussed in 257 [RFC5928]. 259 The "turn" and "turns" URI schemes do not introduce any specific 260 security issues beyond the security considerations discussed in 261 [RFC3986]. 263 6. IANA Considerations 265 This section contains the registration information for the "turn" and 266 "turns" URI Schemes (in accordance with [RFC4395]). 268 6.1. TURN URI Registration 270 URI scheme name: turn 272 Status: permanent 274 URI scheme syntax: See Section 3.1. 276 URI scheme semantics: See Section 3.2. 278 Encoding considerations: There are no encoding considerations beyond 279 those in [RFC3986]. 281 Applications/protocols that use this URI scheme name: 283 The "turn" URI scheme is intended to be used by applications that 284 might need access to a TURN server. 286 Interoperability considerations: N/A 287 Security considerations: See Section 5. 289 Contact: Marc Petit-Huguenin 291 Author/Change controller: The IESG 293 References: RFCXXXX 295 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 296 this specification, and remove this paragraph on publication.]] 298 6.2. TURNS URI Registration 300 URI scheme name: turns 302 Status: permanent 304 URI scheme syntax: See Section 3.1. 306 URI scheme semantics: See Section 3.2. 308 Encoding considerations: There are no encoding considerations beyond 309 those in [RFC3986]. 311 Applications/protocols that use this URI scheme name: 313 The "turns" URI scheme is intended to be used by applications that 314 might need access to a TURN server over a secure connection. 316 Interoperability considerations: N/A 318 Security considerations: See Section 5. 320 Contact: Marc Petit-Huguenin 322 Author/Change controller: The IESG 324 References: RFCXXXX 326 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 327 this specification, and remove this paragraph on publication.]] 329 7. Acknowledgements 330 Thanks to Margaret Wasserman, Magnus Westerlund, Juergen 331 Schoenwaelder, Sean Turner, Ted Hardie, Dave Thaler, Alfred E. 332 Heggestad, Eilon Yardeni, Dan Wing, Alfred Hoenes, and Jim Kleck for 333 the comments, suggestions and questions that helped improve the 334 draft-petithuguenin-behave-turn-uri-bis document. 336 Many thanks to Cullen Jennings for his detailed review and thoughtful 337 comments on the draft-nandakumar-rtcweb-turn-uri document. 339 Thanks to Bjoern Hoehrmann and Dan Wing for the comments, suggestions 340 and questions that helped improve this document. 342 The and ABNF productions have been copied 343 from the and ABNF productions from [RFC3986]. 345 8. References 347 8.1. Normative References 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 353 Resource Identifier (URI): Generic Syntax", STD 66, RFC 354 3986, January 2005. 356 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 357 Specifications: ABNF", STD 68, RFC 5234, January 2008. 359 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 360 Relays around NAT (TURN): Relay Extensions to Session 361 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 363 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 364 (TURN) Resolution Mechanism", RFC 5928, August 2010. 366 8.2. Informative References 368 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 369 Registration Procedures for New URI Schemes", BCP 35, RFC 370 4395, February 2006. 372 [WEBRTC] Bergkvist, A., Burnett, D., Jennings, C., and A. 373 Narayanan, "WebRTC 1.0: Real-time Communication Between 374 Browsers", World Wide Web Consortium WD WD- 375 webrtc-20120821, August 2012, 376 . 378 [RUNNING-CODE] 379 Sheffer, Y. and A. Farrel, "Improving Awareness of Running 380 Code: the Implementation Status Section", draft-sheffer- 381 running-code-06 (work in progress), June 2013. 383 Appendix A. Examples 385 Table 1 shows how the , and components are 386 populated from various URIs. For all these examples, the 387 component is populated with "example.org". 389 +---------------------------------+----------+--------+-------------+ 390 | URI | | | | 391 +---------------------------------+----------+--------+-------------+ 392 | turn:example.org | false | | | 393 | turns:example.org | true | | | 394 | turn:example.org:8000 | false | 8000 | | 395 | turn:example.org?transport=udp | false | | UDP | 396 | turn:example.org?transport=tcp | false | | TCP | 397 | turns:example.org?transport=tcp | true | | TLS | 398 +---------------------------------+----------+--------+-------------+ 400 Table 1 402 Appendix B. Design Notes 404 o The ABNF duplicates some definitions from [RFC3986] instead of 405 referencing them. This was done because the definitions in RFC 406 3986 are for hierarchical URIs, so using these references in an 407 opaque URI proved confusing. 409 o One recurring comment was to stop using the suffix "s" on URI 410 scheme, and to move the secure option to a parameter (e.g. 411 ";proto=tls"). We decided against this idea because the STUN URI 412 does not have a ";proto=" parameter and we would have lost the 413 symmetry between the TURN and STUN URIs. A more detailed account 414 of the reasoning behind this is available at 418 o Following the advice of RFC 4395 section 2.2., and because the 419 TURN URI does not describe a hierarchical structure, the TURN URIs 420 are opaque URIs. 422 o is not used in the URIs because it is deprecated. 423 is not used in the URIs because it is not used to guide 424 the resolution mechanism. 426 o As discussed at IETF 72 in Dublin, there is no generic parameters 427 in the URI to prevent compatibility issues. 429 Appendix C. Release notes 431 This section must be removed before publication as an RFC. 433 C.1. Modifications between petithuguenin-behave-turn-uris-05 and 434 petithuguenin-behave-turn-uris-04 436 o Simplify the abstract. 438 o Change boilerplate from noModificationTrust200902 to trust200902. 440 o Update RFC 2119 boilerplate to http://trac.tools.ietf.org/group/ 441 iesg/trac/wiki/Draft2119BoilerplateSuggestions 443 o Remove non-normative text in "Definitions of the TURN and TURNS 444 URI" section. 446 o Reorder ABNF production references in the text to match the ABNF 447 definition order. 449 o Add a design note explaining the reason for duplicating the ABNF 450 productions from RFC 3986. 452 o Move the Design Notes section from the Release Notes appendix to 453 its own appendix to keep them in the RFC-to-be. 455 o s/in Dublin/at IETF 72 in Dublin/ 457 o Updated acknowledgment section. 459 o Updated Implementation Status section with new template. 461 Authors' Addresses 463 Marc Petit-Huguenin 464 Impedance Mismatch 466 Email: petithug@acm.org 467 Suhas Nandakumar 468 Cisco Systems 469 170 West Tasman Drive 470 San Jose, CA 95134 471 US 473 Email: snandaku@cisco.com 475 Gonzalo Salgueiro 476 Cisco Systems 477 7200-12 Kit Creek Road 478 Research Triangle Park, NC 27709 479 US 481 Email: gsalguei@cisco.com 483 Paul E. Jones 484 Cisco Systems 485 7025 Kit Creek Road 486 Research Triangle Park, NC 27709 487 US 489 Email: paulej@packetizer.com