idnits 2.17.00 (12 Aug 2021) /tmp/idnits49010/draft-thaler-appsawg-multi-transport-uris-01.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 233: '...f port numbers is RECOMMENDED whenever...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 1782 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3261' is mentioned on line 109, but not defined -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 7320 (Obsoleted by RFC 8820) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft Microsoft 4 Intended status: Informational July 3, 2017 5 Expires: January 4, 2018 7 Using URIs With Multiple Transport Stacks 8 draft-thaler-appsawg-multi-transport-uris-01 10 Abstract 12 Many Uniform Resource Identifiers (URIs) today have some mechanism to 13 resolve them to one or more specific endpoints where that resource is 14 available. This document discusses issues that arise when the same 15 resource can be reached over multiple protocol stacks, and discusses 16 various approaches that have been used or discussed, and the 17 tradeoffs between them. Such issues are important to consider when 18 defining new URI schemes and resolution mechanisms. 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 4, 2018. 37 Copyright Notice 39 Copyright (c) 2017 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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Transport endpoint discovery . . . . . . . . . . . . . . . . 4 57 3.1. Specified by the URI scheme specification . . . . . . . . 4 58 3.2. Passed in one URI . . . . . . . . . . . . . . . . . . . . 4 59 3.3. Use separate URI for each transport endpoint . . . . . . 6 60 3.4. Use another mechanism for discovery . . . . . . . . . . . 7 61 4. Transport endpoint selection . . . . . . . . . . . . . . . . 7 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 8. Informative References . . . . . . . . . . . . . . . . . . . 8 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 For Uniform Resource Identifier (URI) schemes that function as 71 locators, [RFC3986] explains that URI "resolution" is the process of 72 determining an access mechanism and the appropriate parameters 73 necessary to deference a URI; this resolution may require several 74 iterations. To use that access mechanism to perform an action on the 75 URI's resource is to "dereference" the URI. 77 The specific details vary by URI scheme and hence are up to each URI 78 scheme definition to specify. Requirements for URI scheme 79 definitions are covered in [RFC3986], [RFC7320], and [RFC7595]. RFC 80 7595 section 3.3 states: 82 For schemes that function as locators, it is important that the 83 mechanism of resource location be clearly defined. 85 Closely related to the concept of resolving a URI to a resource that 86 may have multiple ways to reach it, is the concept of "equivalence". 87 [RFC3986] section 6.1 states: 89 Even though it is possible to determine that two URIs are 90 equivalent, URI comparison is not sufficient to determine whether 91 two URIs identify different resources. For example, an owner of 92 two different domain names could decide to serve the same resource 93 from both, resulting in two different URIs. Therefore, comparison 94 methods are designed to minimize false negatives while strictly 95 avoiding false positives. 97 Thus, it is possible that two distinct URIs refer to the same 98 resource. The goal, as RFC 3986 stated above, is simply to 99 "minimize" such cases, but such minimization often comes at a cost. 100 For example, for many URIs schemes, a DNS name can be used in the 101 authority component rather than using several URIs that differ only 102 in IP address literal, with the cost being a dependency on DNS name 103 resolution and the potential latency and traffic involved. 105 As another example, [RFC5630] section 4.1 states: 107 SIP and SIPS URIs that are identical except for the scheme itself 108 (e.g., sip:alice@example.com and sips:alice@example.com) refer to 109 the same resource. This requirement is implicit in [RFC3261], 110 Section 19.1, which states that "any resource described by a SIP 111 URI can be 'upgraded' to a SIPS URI by just changing the scheme, 112 if it is desired to communicate with that resource securely". 113 This does not mean that the SIPS URI will necessarily be 114 reachable, in particular, if the proxy cannot establish a secure 115 connection to a client or another proxy. This does not suggest 116 either that proxies would arbitrarily "upgrade" SIP URIs to SIPS 117 URIs when forwarding a request (see Section 5.3). Rather, it 118 means that when a resource is addressable with SIP, it will also 119 be addressable with SIPS. 121 Thus, the same resource might be identified by multiple URIs that 122 differ only in URI scheme, or authority component, or path (e.g., 123 using ".." resolution). 125 For URIs used in the World Wide Web, Section 2.3.1 of "Architecture 126 of the World Wide Web" [AWWW] further discusses such aliasing, 127 explaining that links to a resource increase the value of that 128 resource, and multiple URIs for it interfere with such valuation, and 129 also makes it difficult to correlate two sources as pointing to the 130 same resource via differing aliases. Thus to maximize the benefit to 131 the Web, URI aliases should be minimized. 133 2. Problem Statement 135 Besides specifying one or more URI scheme names to be used and the 136 syntax for each (e.g., what the authority component contains), there 137 are two issues a URI scheme definer must deal with when multiple 138 transports are available for accessing a given resource: 140 1. Specifying how the set of transport endpoint identifiers (e.g., 141 TCP and UDP port numbers) for a given URI can be discovered by an 142 entity wishing to resolve it, and 144 2. Specifying how an appropriate transport endpoint can be selected 145 for use, from among the discovered set. 147 At a high level, these issues are equivalent to those arising when 148 multiple IP addresses are available for the same resource. However, 149 in general, there may be multiple layers in a transport stack, each 150 with their own identifiers, so the problems are compounded when 151 multiple choices exist at each of multiple layers below the 152 application-layer protocol itself. 154 3. Transport endpoint discovery 156 A client wishing to access a resource needs to know, for each layer 157 in the transport stack, what protocol(s) to use, and what 158 identifier(s) are needed by each such protocol. There are several 159 possible approaches to transport endpoint identifier discovery, which 160 we cover in the following sections. For simplicity, we will discuss 161 them as if the same approach is used for both types of information, 162 but it is important to remember that a URI scheme could specify 163 discovery of the set of transport protocols via one approach, and 164 discovery of the identifier(s) for each transport protocol via 165 another approach. 167 3.1. Specified by the URI scheme specification 169 In this approach, every resource is assumed to use the exact same set 170 of transport protocols (i.e., stacks of protocols above the network 171 layer) and identifiers. The identifiers can be IANA assigned and 172 specified as part of the URI scheme or protocol specification. For 173 example, TFTP only supports UDP port 69, and so no port number is 174 permitted in a tftp URI. 176 If support for a new transport protocol is later added under a 177 protocol with a given URI scheme, different entities may thus have 178 different hard-coded assumptions about the set of possible transport 179 protocols, which just pushes the rest of the burden to the problem of 180 selection among the known set (see Section 4). 182 A disadvantage of this approach for many use cases is that it does 183 not allow for non-default configurations such as custom ports. 185 3.2. Passed in one URI 187 For single-transport protocols, a common mechanism is to specify a 188 default port for the URI scheme, and to allow putting a non-default 189 port number in the URI authority component. 191 For multi-transport protocols, historically it was sometimes assumed 192 that multiple transport protocols (e.g., UDP and TCP) would use the 193 same port number, so specifying a single number would also be 194 sufficient for multiple transports. When port numbers appear in 195 URIs, they are not the default ports that might be IANA-assigned 196 (since default ports should be omitted from the URI per [RFC3986] 197 section 3.2.3), but instead are either statically chosen by the 198 server application, or are ephemeral ports dynamically allocated on 199 the server hosting the resource. In most TCP/IP stacks, ephemeral 200 ports used by UDP endpoints have no relationship to ephemeral ports 201 used by TCP endpoints in the same application and so it cannot be 202 guaranteed that the port numbers are the same. For example, port 203 51000 might be allocated to one application for UDP, and a different 204 application for TCP. 206 Since 2011, this same issue can also occur with IANA-assigned ports, 207 especially if support for a given transport protocol is added at a 208 later time. [RFC6335] section 7.2 explains: 210 Effective with the publication of this document, IANA will begin 211 assigning port numbers for only those transport protocols 212 explicitly included in an assignment request. This ends the long- 213 standing practice of automatically assigning a port number to an 214 application for both TCP and UDP, even if the request is for only 215 one of these transport protocols. 217 Thus, for most URI schemes, a port number appearing in a URI 218 authority component must be specified as being in a specific 219 transport-layer protocol's numbering space since its value for a 220 given resource might differ by transport protocol. If a URI scheme 221 wishes for the port number in URI authority component to be able to 222 apply to multiple transport protocols, the URI scheme would typically 223 have to assume static configuration on servers; this may be 224 acceptable in some circumstances and unacceptable in others. 226 A common solution in non-URI contexts is to use a service name rather 227 than a literal port number, and allow the service name to be resolved 228 to the relevant transport-layer identifier. Indeed, [RFC6335] 229 section 3 says: 231 Because the port number space is finite (and therefore 232 conservation is an important goal), the alternative of using 233 service names instead of port numbers is RECOMMENDED whenever 234 possible. 236 Unfortunately, it is not possible to follow this recommendation with 237 the port field in URI authority component, since the URI syntax only 238 allows integers in the port field. 240 For new URI schemes, it may be possible in some cases to place a 241 service name in the host field, such as "_myservice._tcp.example.org" 242 as would be used with a DNS SRV record [RFC2782]. That example still 243 specifies only a single transport protocol stack ("_tcp") however, 244 rather than a list of supported stacks. 246 Another limitation of service names is that they are currently 247 limited only to TCP, UDP, SCTP, and DCCP, and so cannot be used with 248 other layers (e.g., websockets) or protocols. Thus, a URI scheme for 249 a protocol that supports both, say, websockets and raw TCP as 250 possible transports for resource access, cannot use a service name as 251 a common identifier for transport-layer endpoint resolution. 253 It is usually also undesirable to put transport-layer endpoint 254 information (the list of supported transport protocols or the 255 identifier(s) used with the transport protocols) in the path or query 256 components for two reasons. First, those components are typically 257 passed over the wire to the server when accessing a resource, which 258 only consumes extra bandwidth with no benefit. Second, if the 259 transport-layer identifiers might change over the lifetime of the 260 resource, then the URI would need to change even if the change did 261 not affect the actual endpoint chosen by the client. Such a change 262 would negatively affect equivalence with the previous URI, e.g., 263 resulting in cache misses. 265 Thus, an advantage of this approach is that it can work without any 266 dependency on other protocols or deployment of servers needed for 267 resolution, and a disadvantage is that putting information about 268 multiple transport-layer endpoints anywhere in the same URI could 269 make for a very long URI that might have issues with certain 270 software, or have bandwidth or storage issues. 272 3.3. Use separate URI for each transport endpoint 274 In this approach, one must simply accept the fact that multiple URIs 275 might refer to the same resource as RFC 3986 already allows. This is 276 similar to using a set of URIs that differ only in IP address 277 literal, for a case when the resource server is not resolvable via a 278 protocol such as DNS or SIP. 280 The obvious disadvantage is that there are multiple URIs for the same 281 resource. Another potential disadvantage for some more complex use 282 cases where there are multiple layers of the transport stack, is that 283 it may be difficult or impossible to express all the identifiers in 284 an entire stack of protocols in one URI. 286 For cases where there are multiple transport protocols but only one 287 such layer, this approach results in needing to identify a single 288 transport protocol per URI. As discussed in Section 3.2, this often 289 cannot be put in the authority component and is undesirable to put in 290 the path or query component. As a result, such cases involve 291 specifying a separate URI scheme per transport. For example, "sip" 292 and "sips" do this. The CoRE WG also proposed this approach for CoAP 293 with "coap", "coaps", "coap+tcp", "coaps+tcp", etc. 295 3.4. Use another mechanism for discovery 297 In this approach, a URI scheme definer would specify a mechanism 298 whereby transport stack identifiers can be resolved for a given URI. 299 If multiple layers exist, then such resolution might involve a 300 resolution step for each layer. 302 DNS records (e.g., SRV records) provide one potential mechanism that 303 can be used to discover a set of supported transports and their 304 associated identifiers. Other types of directories might be usable 305 in other cases. For example, HTTP now provides an "Alt-Svc" 306 [RFC7838] mechanism that can discover alternate transport endpoints 307 for the same HTTP URI. 309 One challenge in many cases is defining a common mechanism that could 310 discover identifiers for different transport protocols. For example, 311 websockets use URIs and TCP uses port numbers (and there is currently 312 no URI scheme for TCP itself), and so the syntax of such identifiers 313 may differ if an application layer protocol could use both TCP and 314 websockets. 316 The advantage of requiring a separate resolution mechanism is that 317 the resource URI itself can be kept short and simple. The downside 318 is extra complexity in both clients and servers, and potentially 319 extra specification work for the URI scheme definer, and the possible 320 additional deployment burden of provisioning and operating extra 321 protocols or servers to facilitate such resolution. 323 In some contexts, it might also be feasible to discover the 324 additional identifiers using the same mechanism used to discover the 325 URI itself, perhaps even in the same message. 327 4. Transport endpoint selection 329 The URI scheme must specify the mechanism for choosing among 330 transport protocol stacks, such as specifying at least one that is 331 mandatory to implement and an algorithm for trying possible transport 332 stacks in some order until one works. 334 This problem is similar to that of choosing among multiple discovered 335 IP addresses for the same transport stack, and two common solutions 336 are used today in that context. One category of algorithm is to sort 337 the choices according to some criteria, and then to try them in order 338 of preference. For example, SRV records provide a priority and 339 weight for each transport endpoint that can be used to sort them, and 340 [RFC6724] provides an algorithm for sorting destination IP addresses. 342 Another category of such algorithms is called "Happy Eyeballs" 343 [RFC6555] where multiple possibilities are attempted in parallel 344 (possibly with some delay added before starting non-preferred 345 choices) and keeping the first one that successfully connects. The 346 advantage is faster connection when a non-preferred choice is needed, 347 and the disadvantages are extra complexity in the client, extra 348 traffic on the network, and extra connections at the server if 349 multiple parallel attempts succeed. 351 As noted earlier, when multiple layers exist in the transport stack, 352 the number of possible permutations might be large in some cases, and 353 so a mechanism must be cognizant of that. 355 5. IANA Considerations 357 This document has no actions for IANA. 359 6. Security Considerations 361 The security considerations in section 3.7 of [RFC7595] and section 7 362 of [RFC3986] apply. [RFC6943] also discusses security considerations 363 with determining equivalence, and section 3.1.4 of that document is 364 relevant to resolution. This document does not raise additional 365 security issues. 367 7. Acknowledgements 369 Thanks to Graham Klyne, Alexey Melnikov, and Gabriel Montenegro for 370 helpful suggestions on this document. 372 8. Informative References 374 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 375 specifying the location of services (DNS SRV)", RFC 2782, 376 DOI 10.17487/RFC2782, February 2000, 377 . 379 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 380 Resource Identifier (URI): Generic Syntax", STD 66, 381 RFC 3986, DOI 10.17487/RFC3986, January 2005, 382 . 384 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 385 Initiation Protocol (SIP)", RFC 5630, 386 DOI 10.17487/RFC5630, October 2009, 387 . 389 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 390 Cheshire, "Internet Assigned Numbers Authority (IANA) 391 Procedures for the Management of the Service Name and 392 Transport Protocol Port Number Registry", BCP 165, 393 RFC 6335, DOI 10.17487/RFC6335, August 2011, 394 . 396 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 397 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 398 2012, . 400 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 401 "Default Address Selection for Internet Protocol Version 6 402 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 403 . 405 [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for 406 Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 407 2013, . 409 [RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190, 410 RFC 7320, DOI 10.17487/RFC7320, July 2014, 411 . 413 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 414 and Registration Procedures for URI Schemes", BCP 35, 415 RFC 7595, DOI 10.17487/RFC7595, June 2015, 416 . 418 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 419 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 420 April 2016, . 422 [AWWW] Jacobs, I. and N. Walsh, "Architecture of the World Wide 423 Web, Volume One", December 2004, 424 . 426 Author's Address 427 Dave Thaler 428 Microsoft 429 One Microsoft Way 430 Redmond, WA 98052 431 USA 433 Email: dthaler@microsoft.com