idnits 2.17.1 draft-petithuguenin-behave-turn-uris-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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. 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 (May 06, 2013) is 4001 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) == Outdated reference: A later version (-06) exists of draft-sheffer-running-code-04 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: November 07, 2013 G. Salgueiro 6 P. Jones 7 Cisco Systems 8 May 06, 2013 10 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers 11 draft-petithuguenin-behave-turn-uris-04 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 that can be used to provision 18 the configuration values needed by the resolution mechanism defined 19 in [RFC5928]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 07, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may not be modified, and derivative works of it may not 54 be created, except to format it for publication as an RFC or to 55 translate it into languages other than English. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Definitions of the TURN and TURNS URI . . . . . . . . . . . . 3 62 3.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 3 63 3.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . 4 64 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 65 4.1. turnuri . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.2. libjingle . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.3. Firefox . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 6.1. TURN URI Registration . . . . . . . . . . . . . . . . . . 6 71 6.2. TURNS URI Registration . . . . . . . . . . . . . . . . . 7 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 8.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 9 77 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 9 78 B.1. Design Notes . . . . . . . . . . . . . . . . . . . . . . 9 79 B.2. Modifications between petithuguenin-behave-turn-uris-04 80 and petithuguenin-behave-turn-uris-03 . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 This document specifies the syntax and semantics of the Uniform 86 Resource Identifier (URI) scheme for the Traversal Using Relays 87 around NAT (TURN) protocol. 89 The TURN protocol is a specification allowing hosts behind NAT to 90 control the operation of a relay server. The relay server allows 91 hosts to exchange packets with its peers. The peers themselves may 92 also be behind NATs. RFC 5766 [RFC5766] defines the specifics of the 93 TURN protocol. 95 The "turn" and "turns" URI schemes are used to designate a TURN 96 server (also known as a relay) on Internet hosts accessible using the 97 TURN protocol. With the advent of standards such as [WEBRTC], we 98 anticipate a plethora of endpoints and web applications to be able to 99 identify and communicate with such a TURN server to carry out the 100 TURN protocol. This also implies those endpoints and/or applications 101 to be provisioned with appropriate configuration required to identify 102 the TURN server. Having an inconsistent syntax has its drawbacks and 103 can result in non-interoperable solutions. It can result in 104 solutions that are ambiguous and have implementation limitations on 105 the different aspects of the syntax and alike. The "turn/turns" URI 106 scheme helps alleviate most of these issues by providing a consistent 107 way to describe, configure and exchange the information identifying a 108 TURN server. This would also prevent the shortcomings inherent with 109 encoding similar information in non-uniform syntaxes such as the ones 110 proposed in [WEBRTC], for example. 112 [RFC5928] defines a resolution mechanism to convert a secure flag, a 113 host name or IP address, an eventually empty port, and an eventually 114 empty transport to a list of IP address, port, and TURN transport 115 tuples. 117 To simplify the provisioning of TURN clients, this document defines a 118 TURN and a TURNS URI scheme that can carry the four components needed 119 for the resolution mechanism. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" 124 in this document are to be interpreted as described in [RFC2119]. 126 3. Definitions of the TURN and TURNS URI 128 3.1. URI Scheme Syntax 130 The "turn" URI takes the following form (the syntax below is non- 131 normative): 133 turn:: 135 turns:: 137 Note that the part and the preceding ":" (colon) character, is 138 OPTIONAL. 140 A TURN/TURNS URI has the following formal ABNF syntax [RFC5234]: 142 turnURI = scheme ":" turn-host [ ":" turn-port ] 143 [ "?transport=" transport ] 144 scheme = "turn" / "turns" 145 transport = "udp" / "tcp" / transport-ext 146 transport-ext = 1*unreserved 147 turn-host = IP-literal / IPv4address / reg-name 148 turn-port = *DIGIT 149 IP-literal = "[" ( IPv6address / IPvFuture ) "]" 150 IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) 151 IPv6address = 6( h16 ":" ) ls32 152 / "::" 5( h16 ":" ) ls32 153 / [ h16 ] "::" 4( h16 ":" ) ls32 154 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 155 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 156 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 157 / [ *4( h16 ":" ) h16 ] "::" ls32 158 / [ *5( h16 ":" ) h16 ] "::" h16 159 / [ *6( h16 ":" ) h16 ] "::" 160 h16 = 1*4HEXDIG 161 ls32 = ( h16 ":" h16 ) / IPv4address 162 IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet 163 dec-octet = DIGIT ; 0-9 164 / %x31-39 DIGIT ; 10-99 165 / "1" 2DIGIT ; 100-199 166 / "2" %x30-34 DIGIT ; 200-249 167 / "25" %x30-35 ; 250-255 168 reg-name = *( unreserved / pct-encoded / sub-delims ) 170 , , and are specified in 171 [RFC3986]. The core rules and are used as 172 described in Appendix B of RFC 5234 [RFC5234]. 174 The , and components are passed without 175 modification to the [RFC5928] algorithm. is set to false if 176 is equal to "turn" and set to true if is equal to 177 "turns" and passed to the [RFC5928] algorithm with the other 178 components. 180 3.2. URI Scheme Semantics 182 The TURN protocol supports sending messages over UDP, TCP or TLS- 183 over-TCP. The "turns" URI scheme MUST be used when TURN is run over 184 TLS-over-TCP (or in the future DTLS-over-UDP) and the "turn" scheme 185 MUST be used otherwise. 187 The required part of the "turn" URI denotes the TURN server 188 host. 190 The part, if present, denotes the port on which the TURN 191 server is awaiting connection requests. If it is absent, the default 192 port is 3478 for both UDP and TCP. The default port for TURN over 193 TLS is 5349. 195 4. Implementation Status 197 Note to RFC Editor: Please remove this section before publication. 199 This section records the status of known implementations of the 200 protocol defined by this specification at the time of posting of this 201 Internet-Draft, and is based on a proposal described in 202 [RUNNING-CODE]. According to [RUNNING-CODE], "this will allow 203 reviewers and working groups to assign due consideration to documents 204 that have the benefit of running code, by considering the running 205 code as evidence of valuable experimentation and feedback that has 206 made the implemented protocols more mature. It is up to the 207 individual working groups to use this information as they see fit". 209 4.1. turnuri 211 Name: turnuri 0.3.4 213 Description: A reference implementation of this document and of RFC 214 5928 [RFC5928]. 216 Level of maturity: Beta. 218 Coverage: Fully implements this specification and RFC 5928. 220 Licensing: AGPL3 222 Contact: Marc Petit-Huguenin . 224 URL: http://debian.implementers.org/stable/source/turnuri.tar.gz 226 4.2. libjingle 228 Name: libjingle 0.7.1 230 Description: Libjingle is a set of components provided by Google to 231 implement Jingle protocols XEP-166 (http://xmpp.org/extensions/ 232 xep-0166.html) and XEP-167 (http://xmpp.org/extensions/ 233 xep-0167.html). 235 Level of maturity: Beta. 237 Coverage: Implements draft-petithuguenin-behave-turn-uris-01 238 without IPv6. 240 Licensing: BSD 3-clauses license. 242 Contact: https://code.google.com/p/chromium/ 244 URL: https://code.google.com/p/chromium/codesearch#chromium/src/ 245 third_party/libjingle/source/talk/app/webrtc/peerconnection.cc 247 4.3. Firefox 249 Name: Firefox Aurora 21 251 Description: Mozilla Firefox is a free and open source web browser. 253 Level of maturity: Beta. 255 Coverage: Implements draft-petithuguenin-behave-turn-uri-03 without 256 RFC 5928. 258 Licensing: Mozilla Public License, v2.0. 260 Contact: http://www.mozilla.org/en-US/firefox/channel/ 262 URL: http://hg.mozilla.org/mozilla-central/rev/6b5016ab9ebb 264 5. Security Considerations 266 Security considerations for the resolution mechanism are discussed in 267 [RFC5928]. 269 The "turn" and "turns" URI schemes do not introduce any specific 270 security issues beyond the security considerations discussed in 271 [RFC3986]. 273 6. IANA Considerations 275 This section contains the registration information for the "turn" and 276 "turns" URI Schemes (in accordance with [RFC4395]). 278 6.1. TURN URI Registration 280 URI scheme name: turn 282 Status: permanent 284 URI scheme syntax: See Section 3.1. 286 URI scheme semantics: See Section 3.2. 288 Encoding considerations: There are no encoding considerations beyond 289 those in [RFC3986]. 291 Applications/protocols that use this URI scheme name: 293 The "turn" URI scheme is intended to be used by applications that 294 might need access to a TURN server. 296 Interoperability considerations: N/A 298 Security considerations: See Section 5. 300 Contact: Marc Petit-Huguenin 302 Author/Change controller: The IESG 304 References: RFCXXXX 306 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 307 this specification, and remove this paragraph on publication.]] 309 6.2. TURNS URI Registration 311 URI scheme name: turns 313 Status: permanent 315 URI scheme syntax: See Section 3.1. 317 URI scheme semantics: See Section 3.2. 319 Encoding considerations: There are no encoding considerations beyond 320 those in [RFC3986]. 322 Applications/protocols that use this URI scheme name: 324 The "turns" URI scheme is intended to be used by applications that 325 might need access to a TURN server over a secure connection. 327 Interoperability considerations: N/A 329 Security considerations: See Section 5. 331 Contact: Marc Petit-Huguenin 333 Author/Change controller: The IESG 335 References: RFCXXXX 337 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 338 this specification, and remove this paragraph on publication.]] 340 7. Acknowledgements 342 Thanks to Margaret Wasserman, Magnus Westerlund, Juergen 343 Schoenwaelder, Sean Turner, Ted Hardie, Dave Thaler, Alfred E. 344 Heggestad, Eilon Yardeni, Dan Wing, Alfred Hoenes, and Jim Kleck for 345 their comments, suggestions and questions that helped to improve the 346 draft-petithuguenin-behave-turn-uri-bis document. 348 Many thanks to Cullen Jennings for his detailed review and thoughtful 349 comments on the draft-nandakumar-rtcweb-turn-uri document. 351 Thanks to Bjoern Hoehrmann for his comments, suggestions and 352 questions that helped to improve the this document. 354 The and ABNF productions have been copied 355 from the and ABNF productions from [RFC3986]. 357 8. References 359 8.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 365 Resource Identifier (URI): Generic Syntax", STD 66, RFC 366 3986, January 2005. 368 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 369 Specifications: ABNF", STD 68, RFC 5234, January 2008. 371 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 372 Relays around NAT (TURN): Relay Extensions to Session 373 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 375 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 376 (TURN) Resolution Mechanism", RFC 5928, August 2010. 378 8.2. Informative References 380 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 381 Registration Procedures for New URI Schemes", BCP 35, RFC 382 4395, February 2006. 384 [WEBRTC] Bergkvist, A., Burnett, D., Jennings, C., and A. 385 Narayanan, "WebRTC 1.0: Real-time Communication Between 386 Browsers", World Wide Web Consortium WD WD- 387 webrtc-20120821, August 2012, 388 . 390 [RUNNING-CODE] 391 Sheffer, Y. and A. Farrel, "Improving Awareness of Running 392 Code: the Implementation Status Section", draft-sheffer- 393 running-code-04 (work in progress), April 2013. 395 Appendix A. Examples 397 Table 1 shows how the , and components are 398 populated from various URIs. For all these examples, the 399 component is populated with "example.org". 401 +---------------------------------+----------+--------+-------------+ 402 | URI | | | | 403 +---------------------------------+----------+--------+-------------+ 404 | turn:example.org | false | | | 405 | turns:example.org | true | | | 406 | turn:example.org:8000 | false | 8000 | | 407 | turn:example.org?transport=udp | false | | UDP | 408 | turn:example.org?transport=tcp | false | | TCP | 409 | turns:example.org?transport=tcp | true | | TLS | 410 +---------------------------------+----------+--------+-------------+ 412 Table 1 414 Appendix B. Release notes 416 This section must be removed before publication as an RFC. 418 B.1. Design Notes 420 o One recurring comment was to stop using the suffix "s" on URI 421 scheme, and to move the secure option to a parameter (e.g. 422 ";proto=tls"). We decided against this idea because the STUN URI 423 does not have a ";proto=" parameter and we would have lost the 424 symmetry between the TURN and STUN URIs. A more detailed account 425 of the reasoning behind this is available at 429 o Following the advice of RFC 4395 section 2.2., and because the 430 TURN URI does not describe a hierarchical structure, the TURN URIs 431 are opaque URIs. 433 o is not used in the URIs because it is deprecated. 434 is not used in the URIs because it is not used to guide 435 the resolution mechanism. 437 o As discussed in Dublin, there is no generic parameters in the URI 438 to prevent compatibility issues. 440 B.2. Modifications between petithuguenin-behave-turn-uris-04 and 441 petithuguenin-behave-turn-uris-03 443 o Added implementation status (from draft-sheffer-running-code) for 444 turnuri, Chromium and Firefox. 446 Authors' Addresses 448 Marc Petit-Huguenin 449 Impedance Mismatch 451 Email: petithug@acm.org 453 Suhas Nandakumar 454 Cisco Systems 455 170 West Tasman Drive 456 San Jose, CA 95134 457 US 459 Email: snandaku@cisco.com 461 Gonzalo Salgueiro 462 Cisco Systems 463 7200-12 Kit Creek Road 464 Research Triangle Park, NC 27709 465 US 467 Email: gsalguei@cisco.com 469 Paul E. Jones 470 Cisco Systems 471 7025 Kit Creek Road 472 Research Triangle Park, NC 27709 473 US 475 Email: paulej@packetizer.com