idnits 2.17.1 draft-petithuguenin-behave-turn-uris-03.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 (January 16, 2013) is 4117 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 (~~), 2 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: July 20, 2013 G. Salgueiro 6 P. Jones 7 Cisco Systems 8 January 16, 2013 10 Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers 11 draft-petithuguenin-behave-turn-uris-03 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. This document may not be modified, 25 and derivative works of it may not be created, except to format it 26 for publication as an RFC or to translate it into languages other 27 than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 20, 2013. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Definitions of the TURN and TURNS URI . . . . . . . . . . . . . 4 61 3.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 5 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 5.1. TURN URI Registration . . . . . . . . . . . . . . . . . . . 5 66 5.2. TURNS URI Registration . . . . . . . . . . . . . . . . . . 6 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 71 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 8 72 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . . 8 73 B.1. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 8 74 B.2. Modifications between 75 petithuguenin-behave-turn-uris-03 and 76 petithuguenin-behave-turn-uris-02 . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 This document specifies the syntax and semantics of the Uniform 82 Resource Identifier (URI) scheme for the Traversal Using Relays 83 around NAT (TURN) protocol. 85 The TURN protocol is a specification allowing hosts behind NAT to 86 control the operation of a relay server. The relay server allows 87 hosts to exchange packets with its peers. The peers themselves may 88 also be behind NATs. RFC 5766 [RFC5766] defines the specifics of the 89 TURN protocol. 91 The "turn" and "turns" URI schemes are used to designate a TURN 92 server (also known as a relay) on Internet hosts accessible using the 93 TURN protocol. With the advent of standards such as [WEBRTC], we 94 anticipate a plethora of endpoints and web applications to be able to 95 identify and communicate with such a TURN server to carry out the 96 TURN protocol. This also implies those endpoints and/or applications 97 to be provisioned with appropriate configuration required to identify 98 the TURN server. Having an inconsistent syntax has its drawbacks and 99 can result in non-interoperable solutions. It can result in 100 solutions that are ambiguous and have implementation limitations on 101 the different aspects of the syntax and alike. The "turn/turns" URI 102 scheme helps alleviate most of these issues by providing a consistent 103 way to describe, configure and exchange the information identifying a 104 TURN server. This would also prevent the shortcomings inherent with 105 encoding similar information in non-uniform syntaxes such as the ones 106 proposed in [WEBRTC], for example. 108 [RFC5928] defines a resolution mechanism to convert a secure flag, a 109 host name or IP address, an eventually empty port, and an eventually 110 empty transport to a list of IP address, port, and TURN transport 111 tuples. 113 To simplify the provisioning of TURN clients, this document defines a 114 TURN and a TURNS URI scheme that can carry the four components needed 115 for the resolution mechanism. 117 A reference implementation [REF-IMPL] is available. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" 122 in this document are to be interpreted as described in [RFC2119]. 124 3. Definitions of the TURN and TURNS URI 126 3.1. URI Scheme Syntax 128 The "turn" URI takes the following form (the syntax below is non- 129 normative): 131 turn:: 132 turns:: 134 Note that the part and the preceding ":" (colon) character, is 135 OPTIONAL. 137 A TURN/TURNS URI has the following formal ABNF syntax [RFC5234]: 139 turnURI = scheme ":" turn-host [ ":" turn-port ] 140 [ "?transport=" transport ] 141 scheme = "turn" / "turns" 142 transport = "udp" / "tcp" / transport-ext 143 transport-ext = 1*unreserved 144 turn-host = IP-literal / IPv4address / reg-name 145 turn-port = *DIGIT 146 IP-literal = "[" ( IPv6address / IPvFuture ) "]" 147 IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) 148 IPv6address = 6( h16 ":" ) ls32 149 / "::" 5( h16 ":" ) ls32 150 / [ h16 ] "::" 4( h16 ":" ) ls32 151 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 152 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 153 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 154 / [ *4( h16 ":" ) h16 ] "::" ls32 155 / [ *5( h16 ":" ) h16 ] "::" h16 156 / [ *6( h16 ":" ) h16 ] "::" 157 h16 = 1*4HEXDIG 158 ls32 = ( h16 ":" h16 ) / IPv4address 159 IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet 160 dec-octet = DIGIT ; 0-9 161 / %x31-39 DIGIT ; 10-99 162 / "1" 2DIGIT ; 100-199 163 / "2" %x30-34 DIGIT ; 200-249 164 / "25" %x30-35 ; 250-255 165 reg-name = *( unreserved / pct-encoded / sub-delims ) 167 , , and are specified in 168 [RFC3986]. The core rules and are used as 169 described in Appendix B of RFC 5234 [RFC5234]. 171 The , and components are passed without 172 modification to the [RFC5928] algorithm. is set to false if 173 is equal to "turn" and set to true if is equal to 174 "turns" and passed to the [RFC5928] algorithm with the other 175 components. 177 3.2. URI Scheme Semantics 179 The TURN protocol supports sending messages over UDP, TCP or TLS- 180 over-TCP. The "turns" URI scheme MUST be used when TURN is run over 181 TLS-over-TCP (or in the future DTLS-over-UDP) and the "turn" scheme 182 MUST be used otherwise. 184 The required part of the "turn" URI denotes the TURN server 185 host. 187 The part, if present, denotes the port on which the TURN 188 server is awaiting connection requests. If it is absent, the default 189 port is 3478 for both UDP and TCP. The default port for TURN over 190 TLS is 5349. 192 4. Security Considerations 194 Security considerations for the resolution mechanism are discussed in 195 [RFC5928]. 197 The "turn" and "turns" URI schemes do not introduce any specific 198 security issues beyond the security considerations discussed in 199 [RFC3986]. 201 5. IANA Considerations 203 This section contains the registration information for the "turn" and 204 "turns" URI Schemes (in accordance with [RFC4395]). 206 5.1. TURN URI Registration 208 URI scheme name: turn 210 Status: permanent 212 URI scheme syntax: See Section 3.1. 214 URI scheme semantics: See Section 3.2. 216 Encoding considerations: There are no encoding considerations beyond 217 those in [RFC3986]. 219 Applications/protocols that use this URI scheme name: 221 The "turn" URI scheme is intended to be used by applications that 222 might need access to a TURN server. 224 Interoperability considerations: N/A 226 Security considerations: See Section 4. 228 Contact: Marc Petit-Huguenin 230 Author/Change controller: The IESG 232 References: RFCXXXX 234 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 235 this specification, and remove this paragraph on publication.]] 237 5.2. TURNS URI Registration 239 URI scheme name: turns 241 Status: permanent 243 URI scheme syntax: See Section 3.1. 245 URI scheme semantics: See Section 3.2. 247 Encoding considerations: There are no encoding considerations beyond 248 those in [RFC3986]. 250 Applications/protocols that use this URI scheme name: 252 The "turns" URI scheme is intended to be used by applications that 253 might need access to a TURN server over a secure connection. 255 Interoperability considerations: N/A 257 Security considerations: See Section 4. 259 Contact: Marc Petit-Huguenin 261 Author/Change controller: The IESG 263 References: RFCXXXX 265 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 266 this specification, and remove this paragraph on publication.]] 268 6. Acknowledgements 270 Thanks to Margaret Wasserman, Magnus Westerlund, Juergen 271 Schoenwaelder, Sean Turner, Ted Hardie, Dave Thaler, Alfred E. 272 Heggestad, Eilon Yardeni, Dan Wing, Alfred Hoenes, and Jim Kleck for 273 their comments, suggestions and questions that helped to improve the 274 draft-petithuguenin-behave-turn-uri-bis document. 276 Many thanks to Cullen Jennings for his detailed review and thoughtful 277 comments on the draft-nandakumar-rtcweb-turn-uri document. 279 Thanks to Bjoern Hoehrmann for his comments, suggestions and 280 questions that helped to improve the this document. 282 The and ABNF productions have been copied 283 from the and ABNF productions from [RFC3986]. 285 7. References 287 7.1. Normative References 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 293 Resource Identifier (URI): Generic Syntax", STD 66, 294 RFC 3986, January 2005. 296 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 297 Specifications: ABNF", STD 68, RFC 5234, January 2008. 299 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 300 Relays around NAT (TURN): Relay Extensions to Session 301 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 303 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 304 (TURN) Resolution Mechanism", RFC 5928, August 2010. 306 7.2. Informative References 308 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 309 Registration Procedures for New URI Schemes", BCP 35, 310 RFC 4395, February 2006. 312 [WEBRTC] Bergkvist, A., Burnett, D., Jennings, C., and A. 313 Narayanan, "WebRTC 1.0: Real-time Communication Between 314 Browsers", World Wide Web Consortium WD WD-webrtc- 315 20120821, August 2012, 316 . 318 [REF-IMPL] 319 Petit-Huguenin, MPH., "Reference Implementation of TURN 320 resolver and TURN URI parser". 322 . 325 Appendix A. Examples 327 Table 1 shows how the , and components are 328 populated from various URIs. For all these examples, the 329 component is populated with "example.org". 331 +---------------------------------+----------+--------+-------------+ 332 | URI | | | | 333 +---------------------------------+----------+--------+-------------+ 334 | turn:example.org | false | | | 335 | turns:example.org | true | | | 336 | turn:example.org:8000 | false | 8000 | | 337 | turn:example.org?transport=udp | false | | UDP | 338 | turn:example.org?transport=tcp | false | | TCP | 339 | turns:example.org?transport=tcp | true | | TLS | 340 +---------------------------------+----------+--------+-------------+ 342 Table 1 344 Appendix B. Release notes 346 This section must be removed before publication as an RFC. 348 B.1. Design Notes 350 o One recurring comment was to stop using the suffix "s" on URI 351 scheme, and to move the secure option to a parameter (e.g. 352 ";proto=tls"). We decided against this idea because the STUN URI 353 does not have a ";proto=" parameter and we would have lost the 354 symmetry between the TURN and STUN URIs. A more detailed account 355 of the reasoning behind this is available at 358 o Following the advice of RFC 4395 section 2.2., and because the 359 TURN URI does not describe a hierarchical structure, the TURN URIs 360 are opaque URIs. 362 o is not used in the URIs because it is deprecated. 363 is not used in the URIs because it is not used to guide 364 the resolution mechanism. 365 o As discussed in Dublin, there is no generic parameters in the URI 366 to prevent compatibity issues. 368 B.2. Modifications between petithuguenin-behave-turn-uris-03 and 369 petithuguenin-behave-turn-uris-02 371 o Changed affiliation. 372 o Cleaned RFC 2119 section. 373 o Changed title section 3. 374 o Fixed reference URI scheme semantics in registrations. 375 o s/SHALL/MUST/. 376 o s/SHALL be/is/. 377 o "turn/turns" URI scheme -> "turn" and "turns" URI schemes. 379 Authors' Addresses 381 Marc Petit-Huguenin 382 Impedance Mismatch 384 Email: petithug@acm.org 386 Suhas Nandakumar 387 Cisco Systems 388 170 West Tasman Drive 389 San Jose, CA 95134 390 US 392 Email: snandaku@cisco.com 394 Gonzalo Salgueiro 395 Cisco Systems 396 7200-12 Kit Creek Road 397 Research Triangle Park, NC 27709 398 US 400 Email: gsalguei@cisco.com 401 Paul E. Jones 402 Cisco Systems 403 7025 Kit Creek Road 404 Research Triangle Park, NC 27709 405 US 407 Email: paulej@packetizer.com