idnits 2.17.1 draft-nandakumar-rtcweb-stun-uri-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 : ---------------------------------------------------------------------------- No issues found here. 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 23, 2013) is 4111 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 informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB S. Nandakumar 3 Internet-Draft G. Salgueiro 4 Intended status: Standards Track P. Jones 5 Expires: March 17, 2013 Cisco Systems 6 M. Petit-Huguenin 7 Impedance Mismatch 8 January 23, 2013 10 URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol 11 draft-nandakumar-rtcweb-stun-uri-03 13 Abstract 15 This document is the specification of the syntax and semantics of the 16 Uniform Resource Identifier (URI) scheme for the Session Traversal 17 Utilities for NAT (STUN) protocol. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. This document may not be modified, 23 and derivative works of it may not be created, except to format it 24 for publication as an RFC or to translate it into languages other 25 than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 17, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Definition of the STUN or STUNS URI . . . . . . . . . . . . . . 3 59 3.1. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. URI Scheme Semantics . . . . . . . . . . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 5.1. STUN URI Registration . . . . . . . . . . . . . . . . . . . 5 64 5.2. STUNS URI Registration . . . . . . . . . . . . . . . . . . 6 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 7 70 Appendix B. Design Notes . . . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 This document specifies the syntax and semantics of the Uniform 76 Resource Identifier (URI) scheme for the Session Traversal Utilities 77 for NAT (STUN) protocol. 79 STUN is a protocol that serves as a tool for other protocols in 80 dealing with Network Address Translator (NAT) traversal. It can be 81 used by an endpoint to determine the IP address and port allocated to 82 it by a NAT, to perform connectivity checks between two endpoints, 83 and used as a keepalive protocol to maintain NAT bindings. RFC 5389 84 [RFC5389] defines the specifics of the STUN protocol. 86 The "stun" and "stuns" URI schemes are used to designate a standalone 87 STUN server or any Internet host performing the operations of a STUN 88 server in the context of STUN usages (Section 14 RFC 5389 [RFC5389]). 89 With the advent of standards such as WEBRTC [WEBRTC], we anticipate a 90 plethora of endpoints and web applications to be able to identify and 91 communicate with such a STUN server to carry out the STUN protocol. 92 This also implies those endpoints and/or applications to be 93 provisioned with appropriate configuration required to identify the 94 STUN server. Having an inconsistent syntax has its drawbacks and can 95 result in non-interoperable solutions. It can result in solutions 96 that are ambiguous and have implementation limitations on the 97 different aspects of the syntax and alike. The 'stun/stuns' URI 98 scheme helps alleviate most of these issues by providing a consistent 99 way to describe, configure and exchange the information identifying a 100 STUN server. This would also prevent the shortcomings inherent with 101 encoding similar information in non-uniform syntaxes such as the ones 102 proposed in the WEBRTC Standards [WEBRTC], for example. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" 107 in this document are to be interpreted as described in [RFC2119]. 109 3. Definition of the STUN or STUNS URI 111 3.1. URI Scheme Syntax 113 The "stun" URI takes the following form (the example below is non- 114 normative): 116 stun:: 117 stuns:: 119 Note that the part and the preceding ":" (colon) character, is 120 OPTIONAL. 122 A STUN/STUNS URI has the following formal ABNF syntax [RFC5234]: 124 stunURI = scheme ":" stun-host [ ":" stun-port ] 125 scheme = "stun" / "stuns" 126 stun-host = IP-literal / IPv4address / reg-name 127 stun-port = *DIGIT 128 IP-literal = "[" ( IPv6address / IPvFuture ) "]" 129 IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" ) 130 IPv6address = 6( h16 ":" ) ls32 131 / "::" 5( h16 ":" ) ls32 132 / [ h16 ] "::" 4( h16 ":" ) ls32 133 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 134 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 135 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 136 / [ *4( h16 ":" ) h16 ] "::" ls32 137 / [ *5( h16 ":" ) h16 ] "::" h16 138 / [ *6( h16 ":" ) h16 ] "::" 139 h16 = 1*4HEXDIG 140 ls32 = ( h16 ":" h16 ) / IPv4address 141 IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet 142 dec-octet = DIGIT ; 0-9 143 / %x31-39 DIGIT ; 10-99 144 / "1" 2DIGIT ; 100-199 145 / "2" %x30-34 DIGIT ; 200-249 146 / "25" %x30-35 ; 250-255 147 reg-name = *( unreserved / pct-encoded / sub-delims ) 149 , , and are specified in 150 [RFC3986]. The core rules and are used as 151 described in Appendix B of RFC 5234 [RFC5234]. 153 3.2. URI Scheme Semantics 155 The STUN protocol supports sending messages over UDP, TCP or TLS- 156 over-TCP. The "stuns" URI scheme MUST be used when STUN is run over 157 TLS-over-TCP (or in the future DTLS-over-UDP) and the "stun" scheme 158 MUST be used otherwise. 160 The required part of the "stun" URI denotes the STUN 161 server host. 163 For the optional DNS Discovery procedure mentioned in the Section 9 164 of RFC5389, "stun" URI scheme implies UDP as the transport protocol 165 for SRV lookup and "stuns" URI scheme indicates TCP as the transport 166 protocol. 168 The part, if present, denotes the port on which the STUN 169 server is awaiting connection requests. If it is absent, the default 170 port is 3478 for both UDP and TCP. The default port for STUN over 171 TLS is 5349 as per Section 9 of RFC 5389 [RFC5389]. 173 4. Security Considerations 175 The "stun" and "stuns" URI schemes do not introduce any specific 176 security issues beyond the security considerations discussed in 177 [RFC3986]. 179 5. IANA Considerations 181 This section contains the registration information for the "stun" and 182 "stuns" URI Schemes (in accordance with [RFC4395]). 184 5.1. STUN URI Registration 186 URI scheme name: stun 188 Status: permanent 190 URI scheme syntax: See Section 3.1. 192 URI scheme semantics: See Section 3.2. 194 Encoding considerations: There are no encoding considerations beyond 195 those in [RFC3986]. 197 Applications/protocols that use this URI scheme name: 199 The "stun" URI scheme is intended to be used by applications that 200 might need access to a STUN server. 202 Interoperability considerations: N/A 204 Security considerations: See Section 4. 206 Contact: Suhas Nandakumar 208 Author/Change controller: The IESG 210 References: RFCXXXX 212 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 213 this specification, and remove this paragraph on publication.]] 215 5.2. STUNS URI Registration 217 URI scheme name: stuns 219 Status: permanent 221 URI scheme syntax: See Section 3.1. 223 URI scheme semantics: See Section 3.2. 225 Encoding considerations: There are no encoding considerations beyond 226 those in [RFC3986]. 228 Applications/protocols that use this URI scheme name: 230 The "stuns" URI scheme is intended to be used by applications that 231 might need access to a STUN server over a secure connection. 233 Interoperability considerations: N/A 235 Security considerations: See Section 4. 237 Contact: Suhas Nandakumar 239 Author/Change controller: The IESG 241 References: RFCXXXX 243 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 244 this specification, and remove this paragraph on publication.]] 246 6. Acknowledgements 248 Many thanks to Cullen Jennings for his detailed review and thoughtful 249 comments on this document. 251 Thanks to Ted Hardie, Bjoern Hoehrmann for their comments, 252 suggestions and questions that helped to improve the this document. 254 This document was written with the xml2rfc tool described in 255 [RFC2629]. 257 7. References 258 7.1. Normative References 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, March 1997. 263 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 264 Resource Identifier (URI): Generic Syntax", STD 66, 265 RFC 3986, January 2005. 267 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 268 Specifications: ABNF", STD 68, RFC 5234, January 2008. 270 7.2. Informative References 272 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 273 June 1999. 275 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 276 Registration Procedures for New URI Schemes", BCP 35, 277 RFC 4395, February 2006. 279 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 280 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 281 October 2008. 283 [WEBRTC] W3C, "WebRTC 1.0: Real-time Communication Between 284 Browsers". 286 . 288 Appendix A. Examples 290 Table 1 shows examples for 'stun/stuns'uri scheme. For all these 291 examples, the component is populated with "example.org". 293 +-----------------------+ 294 | URI | 295 +-----------------------+ 296 | stun:example.org | 297 | stuns:example.org | 298 | stun:example.org:8000 | 299 +-----------------------+ 301 Table 1 303 Appendix B. Design Notes 305 o One recurring comment was to stop using the suffix "s" on URI 306 scheme, and to move the secure option to a parameter (e.g. 307 ";proto=tls"). We decided against this idea because the need of 308 ";proto=" for the STUN URI cannot be sufficiently explained and 309 supporting it would render into an incomplete specification. This 310 would also result in loosing symmetry between the TURN and STUN 311 URIs. A more detailed account of the reasoning behind this is 312 available at 315 Authors' Addresses 317 Suhas Nandakumar 318 Cisco Systems 319 170 West Tasman Drive 320 San Jose, CA 95134 321 US 323 Email: snandaku@cisco.com 325 Gonzalo Salgueiro 326 Cisco Systems 327 7200-12 Kit Creek Road 328 Research Triangle Park, NC 27709 329 US 331 Email: gsalguei@cisco.com 333 Paul E. Jones 334 Cisco Systems 335 7025 Kit Creek Road 336 Research Triangle Park, NC 27709 337 US 339 Email: paulej@packetizer.com 341 Marc Petit-Huguenin 342 Impedance Mismatch 344 Email: petithug@acm.org