idnits 2.17.1 draft-ietf-alto-xdom-disc-06.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 ([RFC2119], [RFC8174], [RFC5693]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1464 has weird spacing: '... and n! =...' -- The document date (August 20, 2019) is 1708 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 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO S. Kiesel 3 Internet-Draft University of Stuttgart 4 Intended status: Standards Track M. Stiemerling 5 Expires: February 21, 2020 H-DA 6 August 20, 2019 8 Application Layer Traffic Optimization (ALTO) Cross-Domain Server 9 Discovery 10 draft-ietf-alto-xdom-disc-06 12 Abstract 14 The goal of Application-Layer Traffic Optimization (ALTO) is to 15 provide guidance to applications that have to select one or several 16 hosts from a set of candidates capable of providing a desired 17 resource. ALTO is realized by a client-server protocol. Before an 18 ALTO client can ask for guidance it needs to discover one or more 19 ALTO servers that can provide suitable guidance. 21 In some deployment scenarios, in particular if the information about 22 the network topology is partitioned and distributed over several ALTO 23 servers, it may be needed to discover an ALTO server outside of the 24 own network domain, in order to get appropriate guidance. This 25 document details applicable scenarios, itemizes requirements, and 26 specifies a procedure for ALTO cross-domain server discovery. 28 Technically, the procedure specified in this document takes one 29 IP address or prefix and a U-NAPTR Service Parameter (typically, 30 "ALTO:https") as parameters. It performs DNS lookups (for NAPTR 31 resource records in the in-addr.arpa. or ip6.arpa. tree) and returns 32 one or more URI(s) of information resources related to that IP 33 address or prefix. 35 Terminology and Requirements Language 37 This document makes use of the ALTO terminology defined in RFC 5693 38 [RFC5693]. 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 42 "OPTIONAL" in this document are to be interpreted as described in BCP 43 14 [RFC2119] [RFC8174] when, and only when, they appear in all 44 capitals, as shown here. 46 Status of this Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at http://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on February 21, 2020. 63 Copyright Notice 65 Copyright (c) 2019 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. ALTO Cross-Domain Server Discovery Procedure: Overview . . . . 5 82 3. ALTO Cross-Domain Server Discovery Procedure: Specification . 6 83 3.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 6 84 3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup . . . . 7 85 3.3. Step 2: Prepare Shortened Domain Names . . . . . . . . . . 8 86 3.4. Step 3: Perform DNS U-NAPTR lookups . . . . . . . . . . . 9 87 3.5. Error Handling . . . . . . . . . . . . . . . . . . . . . . 10 88 4. Using the ALTO Protocol with Cross-Domain Server Discovery . . 11 89 4.1. Network and Cost Map Service . . . . . . . . . . . . . . . 11 90 4.2. Map-Filtering Service . . . . . . . . . . . . . . . . . . 12 91 4.3. Endpoint Property Service . . . . . . . . . . . . . . . . 12 92 4.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 12 93 4.5. Summary and Further Extensions . . . . . . . . . . . . . . 14 94 5. Implementation, Deployment, and Operational Considerations . . 15 95 5.1. Considerations for ALTO Clients . . . . . . . . . . . . . 15 96 5.2. Considerations for Network Operators . . . . . . . . . . . 17 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 98 6.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 19 99 6.2. Availability of the ALTO Server Discovery Procedure . . . 20 100 6.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 21 101 6.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 21 102 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 104 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 105 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 106 Appendix A. Solution Approaches for Partitioned ALTO Knowledge . 27 107 A.1. Classification of Solution Approaches . . . . . . . . . . 27 108 A.2. Discussion of Solution Approaches . . . . . . . . . . . . 28 109 A.3. The Need for Cross-Domain ALTO Server Discovery . . . . . 28 110 A.4. Our Solution Approach . . . . . . . . . . . . . . . . . . 29 111 A.5. Relation to the ALTO Requirements . . . . . . . . . . . . 29 112 Appendix B. Requirements for Cross-Domain Server Discovery . . . 30 113 B.1. Discovery Client Application Programming Interface . . . . 30 114 B.2. Data Storage and Authority Requirements . . . . . . . . . 30 115 B.3. Cross-Domain Operations Requirements . . . . . . . . . . . 30 116 B.4. Protocol Requirements . . . . . . . . . . . . . . . . . . 31 117 B.5. Further Requirements . . . . . . . . . . . . . . . . . . . 31 118 Appendix C. ALTO and Tracker-based Peer-to-Peer Applications . . 32 119 C.1. A generic Tracker-based Peer-to-Peer Application . . . . . 32 120 C.2. Architectural Options for Placing the ALTO Client . . . . 33 121 C.3. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 36 122 C.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 38 123 Appendix D. Contributors List and Acknowledgments . . . . . . . . 43 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 126 1. Introduction 128 The goal of Application-Layer Traffic Optimization (ALTO) is to 129 provide guidance to applications that have to select one or several 130 hosts from a set of candidates capable of providing a desired 131 resource [RFC5693]. ALTO is realized by an HTTP-based client-server 132 protocol [RFC7285], which can be used in various scenarios [RFC7971]. 134 The ALTO base protocol document [RFC7285] specifies the communication 135 between an ALTO client and one ALTO server. In principle, the client 136 may send any ALTO query. For example, it might ask for the routing 137 cost between any two IP addresses, or it might request network and 138 cost maps for the whole network, which might be the worldwide 139 Internet. It is assumed that the server can answer any query, 140 possibly with some kind of default value if no exact data is known. 142 No special provisions were made for deployment scenarios with 143 multiple ALTO servers, with some servers having more accurate 144 information about some parts of the network topology while others 145 having better information about other parts of the network 146 ("partitioned knowledge"). Various ALTO use cases have been studied 147 in the context of such scenarios. In some cases, one cannot assume 148 that a topologically nearby ALTO server (e.g., a server discovered 149 with the procedure specified in [RFC7286]) will always provide useful 150 information to the client. One such scenario is detailed in 151 Appendix C. Several solution approaches, such as redirecting a 152 client to a server that has more accurate information or forwarding 153 the request to it on behalf of the client, have been proposed and 154 analyzed (see Appendix A), but none has been specified so far. 156 Section 3 of this document specifies the "ALTO Cross-Domain Server 157 Discovery Procedure" for client-side usage in these scenarios. An 158 ALTO client that wants to send an ALTO query related to a specific IP 159 address or prefix X, may call this procedure with X as a paramenter. 160 It will use Domain Name System (DNS) lookups to find of one ore more 161 ALTO servers that can provide a competent answer. The above wording 162 "related to" was intentionally kept somewhat unspecific, as the exact 163 semantics depends on the ALTO service to be used; see Section 4. 165 Those who are in control of the "reverse DNS" for a given IP address 166 or prefix (i.e., the corresponding subdomain of in-addr.arpa. or 167 ip6.arpa.) - typically an Internet Service Provider (ISP), a 168 corporate IT department, or a university's computing center - may add 169 resource records to the DNS that point to one or more relevant ALTO 170 server(s). In many cases, it may be an ALTO server run by that ISP 171 or IT department, as they naturally have good insight into routing 172 costs from and to their networks. However, they may also refer to an 173 ALTO server provided by someone else, e.g., their upstream ISP. 175 2. ALTO Cross-Domain Server Discovery Procedure: Overview 177 This section gives a non-normative overview on the ALTO Cross-Domain 178 Server Discovery Procedure. The detailed specification will follow 179 in the next section. 181 This procedure was inspired by the "Location Information Server (LIS) 182 Discovery Using IP Addresses and Reverse DNS" [RFC7216] and re-uses 183 parts of the basic ALTO Server Discovery Procedure [RFC7286]. 185 The basic idea is to use the Domain Name System (DNS), more 186 specifically the "in-addr.arpa." or "ip6.arpa." trees, which are 187 mostly used for "reverse mapping" of IP addresses to host names by 188 means of PTR resource records. There, URI-enabled Naming Authority 189 Pointer (U-NAPTR) resource records [RFC4848], which allow the mapping 190 of domain names to Uniform Resource Identifiers (URIs), are installed 191 as needed. Thereby, it is possible to store a mapping from an IP 192 address or prefix to one or more ALTO server URIs in the DNS. 194 The ALTO Cross-Domain Server Discovery Procedure is called with one 195 IP address or prefix and a U-NAPTR Service Parameter [RFC4848] as 196 parameters. 198 The service parameter is usually set to "ALTO:https". However, other 199 parameter values may be used in some scenarios, e.g., "ALTO:http" to 200 search for a server that supports unencrypted transmission for 201 debugging purposes, or other application protocol or service tags if 202 applicable. 204 The procedure performs DNS lookups and returns one or more URI(s) of 205 information resources related to said IP address or prefix, usually 206 the URI(s) of one or more ALTO Information Resource Directory (IRD, 207 see Section 9 of [RFC7285]). The U-NAPTR records also provide 208 preference values, which should be considered if more than one URI is 209 returned. 211 The discovery procedure sequentially tries two different lookup 212 strategies: First, an ALTO-specific U-NAPTR record is searched in the 213 "reverse tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa. 214 corresponding to the given IP address or prefix. If this lookup does 215 not yield a usable result, the procedure tries further lookups with 216 truncated domain names, which correspond to shorter prefix lengths. 217 The goal is to allow deployment scenarios that require fine-grained 218 discovery on a per-IP basis, as well as large-scale scenarios where 219 discovery is to be enabled for a large number of IP addresses with a 220 small number of additional DNS resource records. 222 3. ALTO Cross-Domain Server Discovery Procedure: Specification 224 3.1. Interface 226 The procedure specified in this document takes two parameters, X and 227 SP, where X is an IP address or prefix and SP is a U-NAPTR Service 228 Parameter. 230 The parameter X may be an IPv4 or an IPv6 address or prefix in CIDR 231 notation (see [RFC4632] for the IPv4 CIDR notation and [RFC4291] for 232 IPv6). Consequently, the address type AT is either "IPv4" or "IPv6". 233 In both cases, X consists of an IP address A and a prefix length L. 234 From the definition of IPv4 and IPv6 it follows that syntactically 235 valid values for L are 0 <= L <= 32 when AT=IPv4 and 0 <= L <= 128 236 when AT=IPv6. However, not all syntactically valid values of L are 237 actually supported by this procedure - Step 1 (see below) will check 238 for unsupported values and report an error if neccessary. 240 For example, for X=198.51.100.0/24, we get AT=IPv4, A=198.51.100.0 241 and L=24. Similarly, for X=2001:0DB8::20/128, we get AT=IPv6, 242 A=2001:0DB8::20 and L=128. 244 In the intended usage scenario, the procedure is normally always 245 called with the parameter SP set to "ALTO:https". However, for 246 general applicabiliy and in order to support future extensions, the 247 procedure MUST support being called with any valid U-NAPTR Service 248 Parameter (see Section 4.5. of [RFC4848] for the syntax of U-NAPTR 249 Service Parameters and Section 5. of the same document for 250 information about the IANA registries). 252 The procedure performs DNS lookups and returns one or more URI(s) of 253 information resources related to that IP address or prefix, usually 254 the URI(s) of one or more ALTO Information Resource Directory (IRD, 255 see Section 9 of [RFC7285]). For each URI, it also returns order and 256 preference values (see Section 4.1 of [RFC3403]), which should be 257 considered if more than one URI is returned. 259 During execution of this procedure, various error conditions may 260 occur and have to be reported to the caller; see Section 3.5. 262 For the remainder of the document, we use the following notation for 263 calling the ALTO Cross-Domain Server Discovery Procedure: 265 IRD_URIS_X = XDOMDISC(X,"ALTO:https") 267 3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup 269 First, the procedure checks the prefix length L for unsupported 270 values: If AT=IPv4 (i.e., if A is an IPv4 address) and L < 8, the 271 procedure aborts and indicates an "unsupported prefix length" error 272 to the caller. Similarly, if AT=IPv6 and L < 32, the procedure 273 aborts and indicates an "unsupported prefix length" error to the 274 caller. Otherwise, the procedure continues. 276 If AT=IPv4, the procedure will then produce a DNS domain name, which 277 will be referred to as R32. This domain name is constructed 278 according to the rules specified in Section 3.5 of [RFC1035] and it 279 is rooted in the special domain "IN-ADDR.ARPA.". 281 For example, A=198.51.100.3 yields R32="3.100.51.198.IN-ADDR.ARPA.". 283 If AT=IPv6, a domain name. which will be called R128, is constructed 284 according to the rules specified in Section 2.5 of [RFC3596] and the 285 special domain "IP6.ARPA." is used. 287 For example (note: a line break was added after the second line), 288 A = 2001:0DB8::20 yields 289 R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0. 290 1.0.0.2.IP6.ARPA." 292 3.3. Step 2: Prepare Shortened Domain Names 294 For this step, an auxiliary function "skip" is defined as follows: 295 skip(str,n) will skip all characters in the string str, up to and 296 including the n-th dot, and return the remaining part of str. For 297 example, skip("foo.bar.baz.qux.quux.",2) will return "baz.qux.quux.". 299 If AT=IPv4, the following additional domain names are generated from 300 the result of the previous step: 302 R24=skip(R32,1), 304 R16=skip(R32,2), and 306 R8=skip(R32,3). 308 Removing one label from a domain name (i.e., one number of the 309 "dotted quad notation") corresponds to shortening the prefix length 310 by 8 bits. 312 For example, R32="3.100.51.198.IN-ADDR.ARPA." yields 313 R24="100.51.198.IN-ADDR.ARPA.", R16="51.198.IN-ADDR.ARPA.", and 314 R8="198.IN-ADDR.ARPA.". 316 If AT=IPv6, the following additional domain names are generated from 317 the result of the previous step: 319 R64=skip(R128,16), 321 R56=skip(R128,18), 323 R48=skip(R128,20), 325 R40=skip(R128,22), and 327 R32=skip(R128,24). 329 Removing one label from a domain name (i.e., one hex digit) 330 corresponds to shortening the prefix length by 4 bits. 332 For example (note: a line break was added after the first line), 333 R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0. 334 1.0.0.2.IP6.ARPA." yields 335 R64 = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", 336 R56 = "0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", 337 R48 = "0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", 338 R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and 339 R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.". 341 3.4. Step 3: Perform DNS U-NAPTR lookups 343 The address type and the prefix length of X are matched against the 344 first and the second column of the following table, respectively: 346 +------------+------------+------------+----------------------------+ 347 | 1: Address | 2: Prefix | 3: MUST do | 4: SHOULD do further | 348 | Type AT | Length L | 1st lookup | lookups in that order | 349 +------------+------------+------------+----------------------------+ 350 | IPv4 | 32 | R32 | R24, R16, R8 | 351 | IPv4 | 24 .. 31 | R24 | R16, R8 | 352 | IPv4 | 16 .. 23 | R16 | R8 | 353 | IPv4 | 8 .. 15 | R8 | (none) | 354 | IPv4 | 0 .. 7 | (none, abort: unsupported prefix length)| 355 +------------+------------+------------+----------------------------+ 356 | IPv6 | 128 | R128 | R64, R56, R48, R40, R32 | 357 | IPv6 | 64 (..127) | R64 | R56, R48, R40, R32 | 358 | IPv6 | 56 .. 63 | R56 | R48, R40, R32 | 359 | IPv6 | 48 .. 55 | R48 | R40, R32 | 360 | IPv6 | 40 .. 47 | R40 | R32 | 361 | IPv6 | 32 .. 39 | R32 | (none) | 362 | IPv6 | 0 .. 31 | (none, abort: unsupported prefix length)| 363 +------------+------------+------------+----------------------------+ 365 Then, the domain name given in the 3rd column and the U-NAPTR Service 366 Parameter SP the procedure was called with (usually "ALTO:https") 367 MUST be used for an U-NAPTR [RFC4848] lookup, in order to obtain one 368 or more URIs (indicating protocol, host, and possibly path elements) 369 for the ALTO server's Information Resource Directory (IRD). If such 370 URI(s) can be found, the ALTO Cross-Domain Server Discovery Procedure 371 returns that information to the caller and terminates successfully. 373 For example, the following two U-NAPTR resource records can be used 374 for mapping "100.51.198.IN-ADDR.ARPA." (i.e., R24 from the example in 375 the previous step) to the HTTPS URIs "https://alto1.example.net/ird" 376 and "https://alto2.example.net/ird", with the former being preferred. 378 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 10 "u" "ALTO:https" 379 "!.*!https://alto1.example.net/ird!" "" 381 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 20 "u" "ALTO:https" 382 "!.*!https://alto2.example.net/ird!" "" 384 If no matching U-NAPTR records can be found, the procedure SHOULD try 385 further lookups, using the domain names from the fourth column in the 386 indicated order, until one lookup succeeds. If no IRD URI could be 387 found after looking up all domain names from the 3rd and 4th column, 388 the procedure terminates unsuccessfully, returning an empty URI list. 390 3.5. Error Handling 392 The ALTO Cross-Domain Server Discovery Procedure may fail for several 393 reasons. 395 If the procedure is called with syntactically invalid parameters or 396 unsupported parameter values (in particular the prefix length L, see 397 Section 3.2), the procedure aborts, no URI list will be returned and 398 the error has to be reported to the caller. 400 The procedure performs one or more DNS lookups in a well-defined 401 order (corresponding to descending prefix lengths, see Section 3.4), 402 until one produces a usable result. Each of these DNS lookups might 403 not produce a usable result, either due to a normal condition (e.g., 404 domain name exists, but no ALTO-specific NAPTR resource records are 405 associated with it), a permanent error (e.g., non-existent domain 406 name), or due to a temporary error (e.g., timeout). In all three 407 cases, and as long as there are further domain names that can be 408 looked up, the procedure SHOULD immediately try to lookup the next 409 domain name (from column 4 in the table given in Section 3.4). Only 410 after all domain names have been tried at least once, the procedure 411 MAY retry those domain names that had caused temporary lookup errors. 413 Generally speaking, ALTO provides advisory information for the 414 optimization of applications (e.g., peer-to-peer applications, 415 overlay networks, etc.), but applications should not rely on the 416 availability of such information for their basic functionality (see 417 Section 8.3.4.3 of RFC 7285 [RFC7285]). Consequently, the speedy 418 detection of an ALTO server, even though it may give less accurate 419 answers than other servers, or the quick realization that there is no 420 suitable ALTO server, is in general more preferable than causing long 421 delays by retrying failed queries. Nevertheless, the ALTO Cross- 422 Domain Server Discovery Procedure SHOULD inform its caller, if DNS 423 queries have failed due to temporary errors and that retrying the 424 discovery at a later point in time might give more accurate results. 426 4. Using the ALTO Protocol with Cross-Domain Server Discovery 428 Based on a modular design principle, ALTO provides several ALTO 429 services, each consisting of a set of information resouces that can 430 be accessed using the ALTO protocol. The information resources that 431 are available at a specific ALTO server are listed in its Information 432 Resource Directory (IRD, see Section 9 of [RFC7285]). The ALTO 433 protocol specification defines the following ALTO services and their 434 corresponding information resouces: 436 o Network and Cost Map Service, see Section 11.2 of [RFC7285] 438 o Map-Filtering Service, see Section 11.3 of [RFC7285] 440 o Endpoint Property Service, see Section 11.4 of [RFC7285] 442 o Endpoint Cost Service, see Section 11.5 of [RFC7285] 444 The ALTO Cross-Domain Server Discovery Procedure is most useful in 445 conjunction with the Endpoint Property Service and the Endpoint Cost 446 Service. However, for the sake of completeness, possible interaction 447 with all four services is discussed below. Extension documents may 448 specify further information resources; however, these are out of 449 scope of this document. 451 4.1. Network and Cost Map Service 453 An ALTO client may invoke the ALTO Cross-Domain Server Discovery 454 Procedure (as specified in Section 3) for an IP address or prefix "X" 455 and get a list of one or more IRD URI(s), including order and 456 preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The IRD(s) 457 referenced by these URI(s) will always contain a network and a cost 458 map, as these are mandatory information resources (see Section 11.2 459 of [RFC7285]). However, the cost matrix may be very sparse. If, 460 according to the network map, PID_X is the PID that contains the IP 461 address or prefix X, and PID_1, PID_2, PID_3, ... are other PIDS, the 462 cost map may look like this: 464 From \ To PID_1 PID_2 PID_X PID_3 465 ------+----------------------------------- 466 PID_1 | 92 467 PID_2 | 6 468 PID_X | 46 3 1 19 469 PID_3 | 38 471 In this example, all cells outside column "X" and row "X" are 472 unspecified. A cost map with this structure contains the same 473 information as what could be retrieved using the Endpoint Cost 474 Service, cases 1 and 2 in Section 4.4. Accessing cells that are 475 neither in column "X" nor row "X" may not yield useful results. 477 Trying to assemble a more densely populated cost map from several 478 cost maps with this very sparse structure may be a non-trivial task, 479 as different ALTO servers may use different PID definitions (i.e., 480 network maps) and incompatible scales for the costs, in particular 481 for the "routingcost" metric. 483 4.2. Map-Filtering Service 485 An ALTO client may invoke the ALTO Cross-Domain Server Discovery 486 Procedure (as specified in Section 3) for an IP address or prefix "X" 487 and get a list of one or more IRD URI(s), including order and 488 preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These 489 IRD(s) may provide the optional Map-Filtering Service (see Section 490 11.3 of [RFC7285]). This service returns a subset of the full map, 491 as specified by the client. As discussed in Section 4.1, a cost map 492 may be very sparse in the envisioned deployment scenario. Therefore, 493 depending on the filtering criteria provided by the client, this 494 service may return results similar to the Endpoint Cost Service, or 495 it may not return any useful result. 497 4.3. Endpoint Property Service 499 If an ALTO client wants to query an Endpoint Property Service (see 500 Section 11.4 of RFC 7285 [RFC7285]) about an endpoint with IP address 501 "X" or a group of endpoints within IP prefix "X", respectively, it 502 has to invoke the ALTO Cross-Domain Server Discovery Procedure (as 503 specified in Section 3): IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The 504 result IRD_URIS_X is a list of one or more URIs of Information 505 Resource Directories (IRD, see Section 9 of [RFC7285]). Considering 506 the order and preference values, the client has to check these IRDs 507 for a suitable Endpoint Property Service and query it. 509 If the ALTO client wants to do a similar Endpoint Property query for 510 a different IP address or prefix "Y", the whole procedure has to be 511 repeated, as IRD_URIS_Y = XDOMDISC(Y,"ALTO:https") may yield a 512 different list of IRD URIs. Of course, the results of individual DNS 513 queries may be cached as indicated by their respective time-to-live 514 (TTL) values. 516 4.4. Endpoint Cost Service 518 The optional ALTO Endpoint Cost Service (ECS, see Section 11.5 of RFC 519 7285 [RFC7285]) provides information about costs between individual 520 endpoints and it also supports ranking. The ECS allows that 521 endpoints may be denoted by IP addresses or prefixes. The ECS is 522 called with a list of one or more source IP addresses or prefixes, 523 which we will call (S1, S2, S3, ...), and a list of one or more 524 destination IP addresses or prefixes, called (D1, D2, D3, ...). 526 This specification distinguishes several cases, regarding the number 527 of elements in the list of source and destination addresses, 528 respectively: 530 1. Exactly one source address S1 and more than one destination 531 addresses D1, D2, D3, ... In this case, the ALTO client has to 532 invoke the ALTO Cross-Domain Server Discovery Procedure (as 533 specified in Section 3) with that single source address as a 534 parameter: IRD_URIS_S1 = XDOMDISC(S1,"ALTO:https"). The result 535 IRD_URIS_S1 is a list of one or more URIs of Information Resource 536 Directories (IRD, see Section 9 of [RFC7285]). Considering the 537 order and preference values, the client has to check these IRDs 538 for a suitable Endpoint Cost Service and query it. The ECS is an 539 optional service (see Section 11.5.1 of RFC 7285 [RFC7285]) and 540 therefore, it may well be that an IRD does not refer to an ECS. 542 Calling the Cross-Domain Server Discovery Procedure only once 543 with the single source address as a parameter - as opposed to 544 multiple calls, e.g., one for each destination address - is not 545 only a matter of efficiency. In the given scenario, it is 546 advisable to send all ECS queries to the same ALTO server. This 547 ensures that the results can be compared (e.g., for sorting 548 candidate resource providers), even with cost metrics without a 549 well-defined base unit, e.g., the "routingcost" metric. 551 2. More than one source addresses S1, S2, S3, ... and exactly one 552 destination address D1. In this case, the ALTO client has to 553 invoke the ALTO Cross-Domain Server Discovery Procedure with that 554 single destination address as a parameter: 555 IRD_URIS_D1 = XDOMDISC(D1,"ALTO:https"). The result IRD_URIS_D1 556 is a list of one or more URIs of IRDs. Considering the order and 557 preference values, the client has to check these IRDs for a 558 suitable ECS and query it. 560 3. Exactly one source address S1 and exactly one destination address 561 D1. The ALTO client may perform the same steps as in case 1, as 562 specified above. As an alternative, it may also perform the same 563 steps as in case 2, as specified above. 565 4. More than one source addresses S1, S2, S3, ... and more than one 566 destination addresses D1, D2, D3, ... In this case, the ALTO 567 client should split the list of desired queries based on source 568 addresses and perform separately for each source address the same 569 steps as in case 1, as specified above. As an alternative, the 570 ALTO client may also group the list based on destination 571 addresses and perform separately for each destination address the 572 same steps as in case 2, as specified above. However, comparing 573 results between these sub-queries may be difficult, in particular 574 if the cost metric is a relative preference without a well- 575 defined base unit (e.g., the "routingcost" metric). 577 See Appendix C for a detailed example showing the interaction of a 578 tracker-based peer-to-peer application, the ALTO Endpoint Cost 579 Service, and the ALTO Cross-Domain Server Discovery Procedure. 581 4.5. Summary and Further Extensions 583 Considering the four services defined in the ALTO base protocol 584 specification [RFC7285], the ALTO Cross-Domain Server Discovery 585 Procedure works best with the Endpoint Property Service (EPS) and the 586 Endpoint Cost Service (ECS). Both the EPS and the ECS take one or 587 more IP addresses as a parameter. The previous sections specify how 588 the parameter for calling the ALTO Cross-Domain Server Discovery 589 Procedure has to be derived from these IP adresses. 591 In contrast, the ALTO Cross-Domain Server Discovery Procedure seems 592 less useful if the goal is to retrieve network and cost maps that 593 cover the whole network topology. However, the procedure may be 594 useful if a map centered at a specific IP address is desired (i.e., a 595 map detailing the vicinity of said IP address or a map giving costs 596 from said IP address to all potential destinations). 598 The interaction between further ALTO services (and their 599 corresponding information resources) needs to be investigated and 600 defined once such further ALTO services are specified in an extension 601 document. 603 5. Implementation, Deployment, and Operational Considerations 605 5.1. Considerations for ALTO Clients 607 5.1.1. Resource Consumer Initiated Discovery 609 Resource consumer initiated ALTO server discovery (c.f. ALTO 610 requirement AR-32 [RFC6708]) can be seen as a special case of cross- 611 domain ALTO server discovery. To that end, an ALTO client embedded 612 in a resource consumer would have to perform the ALTO Cross-Domain 613 Server Discovery Procedure with its own IP address as a parameter. 614 However, due to the widespread deployment of Network Address 615 Translators (NAT), additional protocols and mechanisms such as STUN 616 [RFC5389] are usually needed to detect the client's "public" IP 617 address, before it can be used as a parameter to the discovery 618 procedure. Note that a different approach for resource consumer 619 initiated ALTO server discovery, which is based on DHCP, is specified 620 in [RFC7286]. 622 5.1.2. IPv4/v6 Dual Stack, Multihoming and Host Mobility 624 The procedure specified in this document can discover ALTO server 625 URIs for a given IP address or prefix. The intention is, that a 626 third party (e.g., a resource directory) that receives query messages 627 from a resource consumer can use the source address in these messages 628 to discover suitable ALTO servers for this specific resource 629 consumer. 631 However, resource consumers (as defined in Section 2 of [RFC5693]) 632 may reside on hosts with more than one IP address, e.g., due to 633 IPv4/v6 dual stack operation and/or multihoming. IP packets sent 634 with different source addresses may be subject to different routing 635 policies and path costs. In some deployment scenarios, it may even 636 be required to ask different sets of ALTO servers for guidance. 637 Furthermore, source addresses in IP packets may be modified en-route 638 by Network Address Translators (NAT). 640 If a resource consumer queries a resource directory for candidate 641 resource providers, the locally selected (and possibly en-route 642 translated) source address of the query message - as observed by the 643 resource directory - will become the basis for the ALTO server 644 discovery and the subsequent optimization of the resource directory's 645 reply. If, however, the resource consumer then selects different 646 source addresses to contact returned resource providers, the desired 647 better-than-random "ALTO effect" may not occur. 649 One solution approach for this problem is, that a dual stack or 650 multihomed resource consumer could always use the same address for 651 contacting the resource directory and all resource providers, thus 652 overriding the operating system's automatic source IP address 653 selection. For example, when using the BSD socket API, one could 654 always bind() the socket to one of the local IP addresses before 655 trying to connect() to the resource directory or the resource 656 providers, respectively. Another solution approach is to perform 657 ALTO-influenced resource provider selection (and source address 658 selection) locally in the resource consumer, in addition to or 659 instead of performing it in the resource directory. See 660 Section 5.1.1 for a discussion how to discover ALTO servers for local 661 usage in the resource consumer. 663 Similarly, resource consumers on mobile hosts SHOULD query the 664 resource directory again after a change of IP address, in order to 665 get a list of candidate resource providers that is optimized for the 666 new IP address. 668 5.1.3. Interaction with Network Address Translation 670 The ALTO Cross-Domain Server Discovery Procedure has been designed to 671 enable the ALTO-based optimization of applications such as large- 672 scale overlay networks, that span - on the IP layer - multiple 673 adminstrative domains, possibly the whole Internet. Due to the 674 widespread usage of Network Address Translators (NAT) it may well be 675 that nodes of the overlay network (i.e., resource consumers or 676 resource providers) are located behind a NAT, maybe even behind 677 several cascaded NATs. 679 If a resource directory is located in the public Internet (i.e., not 680 behind a NAT) and if it receives a message from a resource consumer 681 behind one or more NATs, the message's source address will be the 682 public IP address of the outermost NAT in front of the resource 683 consumer. The same applies if the resource directory is behind a 684 different NAT than the resource consumer. The resource directory may 685 call the ALTO Cross-Domain Server Discovery Procedure with the 686 message's source address as a parameter. In effect, not the resource 687 consumer's (private) IP address, but the public IP address of the 688 outermost NAT in front of it will be used as a basis for ALTO- 689 optimization. This will work fine as long as the network behind the 690 NAT is not too big (e.g., if the NAT is in a residential gateway). 692 If a resource directory receives a message from a resource consumer 693 and the message's source address is a "private" IP address [RFC1918], 694 this may be a sign that both of them are behind the same NAT. An 695 invokation of the ALTO Cross-Domain Server Discovery Procedure with 696 this private address may be problematic, as this will only yield 697 usable results if a DNS "split horizon" and DNSSEC trust anchors are 698 configured correctly. In this situation it may be more advisable to 699 query an ALTO server that has been discovered using [RFC7286] or any 700 other local configuration. The interaction between intra-domain ALTO 701 for large private domains (e.g., behind a "carrier-grade NAT") and 702 cross-domain, Internet-wide optimization, is beyond the scope of this 703 document. 705 5.2. Considerations for Network Operators 707 5.2.1. Flexibility vs. Load on the DNS 709 The ALTO Cross-Domain Server Discovery Procedure, as specified in 710 Section 3, first produces a list of domain names (steps 1 and 2) and 711 then looks for relevant NAPTR records associated with these names, 712 until a useful result can be found (step 3). The number of candidate 713 domain names on this list is a compromise between flexibility when 714 installing NAPTR records and avoiding excess load on the DNS. 716 A single invocation of the ALTO Cross-Domain Server Discovery 717 Procedure, with an IPv6 address as a parameter, may cause up to, but 718 no more than, six DNS lookups for NAPTR records. For IPv4, the 719 maximum is four lookups. Should the load on the DNS infrastructure 720 caused by these lookups become a problem, one solution approach is to 721 actually populate the DNS with ALTO-specific NAPTR records. If such 722 records can be found for individual IP addresses (possibly installed 723 using a wildcarding mechanism in the name server) or for long 724 prefixes, the procedure will terminate successfully and not perform 725 lookups for shorter prefix lengths, thus reducing the total number of 726 DNS queries. Another approach for reducing the load on the DNS 727 infrastructure is to increase the TTL for caching negative answers. 729 On the other hand, the ALTO Cross-Domain Server Discovery Procedure 730 trying to lookup truncated domain names allows for efficient 731 configuration of large-scale scenarios, where discovery is to be 732 enabled for a large number of IP addresses with a small number of 733 additional DNS resource records. Note that expressly, it has not 734 been a design goal of this procedure to give clients a means to 735 understand the IP prefix delegation structure. Furthermore, this 736 specification does not assume or reccomend that prefix delegations 737 should preferrably occur at those prefix lengths that are used in 738 Step 2 of this procedure (see Section 3.3). A network operator that 739 uses, for example, an IPv4 /18 prefix and wants to install the NAPTR 740 records efficiently, could either install 64 NAPTR records (one for 741 each of the /24 prefixes contained within the /18 prefix), or they 742 could try to team up with the owners of the other fragments of the 743 enclosing /16 prefix, in order to run a common ALTO server to which 744 only one NAPTR would point. 746 5.2.2. BCP20 and missing delegations of the reverse DNS 748 RFC2317 [RFC2317], also known as BCP20, describes a way to delegate 749 the "reverse DNS" (i.e., subdomains of in-addr.arpa.) for IPv4 750 address ranges with fewer than 256 addresses (i.e., less than a whole 751 /24 prefix). The ALTO Cross-Domain Server Discovery procedure is 752 compatible with this method. 754 In some deployment scenarios, e.g., residential Internet access, 755 where customers often dynamically receive a single IPv4 address 756 (and/or a small IPv6 address block) from a pool of addresses, ISPs 757 typically will not delegate the "reverse DNS" to their customers. 758 This practice makes it impossible for these customers to populate the 759 DNS with NAPTR resource records that point to an ALTO server of their 760 choice. Yet, the ISP may publish NAPTR resource records in the 761 "reverse DNS" for individual addresses or larger address pools (i.e., 762 shorter prefix lengths). 764 While ALTO is by no means technologically tied to the Border Gateway 765 Protocol (BGP), it is anticipated that BGP will be an important 766 source of information for ALTO and that the operator of the outermost 767 BGP-enabled router will have a strong incentive to publish a digest 768 of their routing policies and costs through ALTO. In contrast, an 769 individual user or an organization that has been assigned only a 770 small address range (i.e., an IPv4 prefix with a prefix length longer 771 than /24) will typically connect to the Internet using only a single 772 ISP, and they might not be interested in publishing their own ALTO 773 information. Consequently, they might wish to leave the operation of 774 an ALTO server up to their ISP. This ISP may install NAPTR resource 775 records, which are needed for the ALTO Cross-Domain Server Discovery 776 procedure, in the subdomain of in-addr.arpa. that corresponds to the 777 whole /24 prefix (c.f., R24 in Section 3.3 of this document), even if 778 BCP20-style delegations or no delegations at all are in use. 780 6. Security Considerations 782 A high-level discussion of security issues related to ALTO is part of 783 the ALTO problem statement [RFC5693]. A classification of unwanted 784 information disclosure risks, as well as specific security-related 785 requirements can be found in the ALTO requirements document 786 [RFC6708]. 788 The remainder of this section focuses on security threats and 789 protection mechanisms for the cross-domain ALTO server discovery 790 procedure as such. Once the ALTO server's URI has been discovered 791 and the communication between the ALTO client and the ALTO server 792 starts, the security threats and protection mechanisms discussed in 793 the ALTO protocol specification [RFC7285] apply. 795 6.1. Integrity of the ALTO Server's URI 797 Scenario Description 798 An attacker could compromise the ALTO server discovery procedure 799 or the underlying infrastructure in a way that ALTO clients would 800 discover a "wrong" ALTO server URI. 802 Threat Discussion 803 The cross-domain ALTO server discovery procedure relies on a 804 series of DNS lookups, in order to produce one or more URI(s). If 805 an attacker was able to modify or spoof any of the DNS records, 806 the resulting URI(s) could be replaced by forged URI(s). This is 807 probably the most serious security concern related to ALTO server 808 discovery. The discovered "wrong" ALTO server might not be able 809 to give guidance to a given ALTO client at all, or it might give 810 suboptimal or forged information. In the latter case, an attacker 811 could try to use ALTO to affect the traffic distribution in the 812 network or the performance of applications (see also Section 15.1. 813 of [RFC7285]). Furthermore, a hostile ALTO server could threaten 814 user privacy (see also Section 5.2.1, case (5a) in [RFC6708]). 816 Protection Strategies and Mechanisms 817 The application of DNS security (DNSSEC) [RFC4033] provides a 818 means to detect and avert attacks that rely on modification of the 819 DNS records while in transit. All implementations of the cross- 820 domain ALTO server discovery procedure MUST support DNSSEC or be 821 able to use such functionality provided by the underlying 822 operating system. Network operators that publish U-NAPTR resource 823 records to be used for the cross-domain ALTO server discovery 824 procedure SHOULD use DNSSEC to protect their subdomains of in- 825 addr.arpa. and/or ip6.arpa., respectively. Additional operational 826 precautions for safely operating the DNS infrastructure are 827 required in order to ensure that name servers do not sign forged 828 (or otherwise "wrong") resource records. Security considerations 829 specific to U-NAPTR are described in more detail in [RFC4848]. 831 In addition to active protection mechanisms, users and network 832 operators can monitor application performance and network traffic 833 patterns for poor performance or abnormalities. If it turns out 834 that relying on the guidance of a specific ALTO server does not 835 result in better-than-random results, the usage of the ALTO server 836 may be discontinued (see also Section 15.2 of [RFC7285]). 838 Note 839 The cross-domain ALTO server discovery procedure finishes 840 successfully when it has discovered one or more URI(s). Once an 841 ALTO server's URI has been discovered and the communication 842 between the ALTO client and the ALTO server starts, the security 843 threats and protection mechanisms discussed in the ALTO protocol 844 specification [RFC7285] apply. 846 A threat related to the one considered above is the impersonation 847 of an ALTO server after its correct URI has been discovered. This 848 threat and protection strategies are discussed in Section 15.1 of 849 [RFC7285]. The ALTO protocol's primary mechanism for protecting 850 authenticity and integrity (as well as confidentiality) is the use 851 of HTTPS-based transport, i.e., HTTP over TLS [RFC2818]. 852 Typically, when the URI's host component is a host name, a further 853 DNS lookup is needed to map it to an IP address, before the 854 communication with the server can begin. This last DNS lookup 855 (for A or AAAA resource records) does not necessarily have to be 856 protected by DNSSEC, as the server identity checks specified in 857 [RFC2818] are able to detect DNS spoofing or similar attacks, 858 after the connection to the (possibly wrong) host has been 859 established. However, this validation, which is based on the 860 server certificate, can only protect the steps that occur after 861 the server URI has been discovered. It cannot detect attacks 862 against the authenticity of the U-NAPTR lookups needed for the 863 cross-domain ALTO server discovery procedure, and therefore, these 864 resource records have to be secured using DNSSEC. 866 6.2. Availability of the ALTO Server Discovery Procedure 868 Scenario Description 869 An attacker could compromise the cross-domain ALTO server 870 discovery procedure or the underlying infrastructure in a way that 871 ALTO clients would not be able to discover any ALTO server. 873 Threat Discussion 874 If no ALTO server can be discovered (although a suitable one 875 exists) applications have to make their decisions without ALTO 876 guidance. As ALTO could be temporarily unavailable for many 877 reasons, applications must be prepared to do so. However, The 878 resulting application performance and traffic distribution will 879 correspond to a deployment scenario without ALTO. 881 Protection Strategies and Mechanisms 882 Operators should follow best current practices to secure their DNS 883 and ALTO (see Section 15.5 of [RFC7285]) servers against Denial- 884 of-Service (DoS) attacks. 886 6.3. Confidentiality of the ALTO Server's URI 888 Scenario Description 889 An unauthorized party could invoke the cross-domain ALTO server 890 discovery procedure, or intercept discovery messages between an 891 authorized ALTO client and the DNS servers, in order to acquire 892 knowledge of the ALTO server URI for a specific IP address. 894 Threat Discussion 895 In the ALTO use cases that have been described in the ALTO problem 896 statement [RFC5693] and/or discussed in the ALTO working group, 897 the ALTO server's URI as such has always been considered as public 898 information that does not need protection of confidentiality. 900 Protection Strategies and Mechanisms 901 No protection mechanisms for this scenario have been provided, as 902 it has not been identified as a relevant threat. However, if a 903 new use case is identified that requires this kind of protection, 904 the suitability of this ALTO server discovery procedure as well as 905 possible security extensions have to be re-evaluated thoroughly. 907 6.4. Privacy for ALTO Clients 909 Scenario Description 910 An unauthorized party could eavesdrop on the messages between an 911 ALTO client and the DNS servers, and thereby find out the fact 912 that said ALTO client uses (or at least tries to use) the ALTO 913 service in order to optimize traffic from/to a specific IP 914 address. 916 Threat Discussion 917 In the ALTO use cases that have been described in the ALTO problem 918 statement [RFC5693] and/or discussed in the ALTO working group, 919 this scenario has not been identified as a relevant threat. 920 However, Pervasive Surveillance [RFC7624] and DNS Privacy 921 Considerations [RFC7626] have seen significant attention in the 922 Internet community in recent years. 924 Protection Strategies and Mechanisms 925 DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] provide means 926 for protecting confidentiality (and integrity) of DNS traffic 927 between a client (stub) and its recursive name servers, including 928 DNS queries and replies caused by the ALTO Cross-Domain Server 929 Discovery Procedure. 931 7. IANA Considerations 933 This document does not require any IANA action. 935 8. References 937 8.1. Normative References 939 [RFC1035] Mockapetris, P., "Domain names - implementation and 940 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 941 November 1987, . 943 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 944 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 945 RFC2119, March 1997, 946 . 948 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 949 Part Three: The Domain Name System (DNS) Database", 950 RFC 3403, DOI 10.17487/RFC3403, October 2002, 951 . 953 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 954 "DNS Extensions to Support IP Version 6", STD 88, 955 RFC 3596, DOI 10.17487/RFC3596, October 2003, 956 . 958 [RFC4848] Daigle, L., "Domain-Based Application Service Location 959 Using URIs and the Dynamic Delegation Discovery Service 960 (DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007, 961 . 963 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 964 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 965 May 2017, . 967 8.2. Informative References 969 [I-D.kiesel-alto-alto4alto] 970 Kiesel, S., "Using ALTO for ALTO server selection", 971 draft-kiesel-alto-alto4alto-00 (work in progress), 972 July 2010. 974 [I-D.kiesel-alto-ip-based-srv-disc] 975 Kiesel, S. and R. Penno, "Application-Layer Traffic 976 Optimization (ALTO) Anycast Address", 977 draft-kiesel-alto-ip-based-srv-disc-03 (work in progress), 978 July 2014. 980 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 981 and E. Lear, "Address Allocation for Private Internets", 982 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 983 . 985 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 986 ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/ 987 RFC2317, March 1998, 988 . 990 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 991 RFC2818, May 2000, 992 . 994 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 995 Rose, "DNS Security Introduction and Requirements", 996 RFC 4033, DOI 10.17487/RFC4033, March 2005, 997 . 999 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1000 Architecture", RFC 4291, DOI 10.17487/RFC4291, 1001 February 2006, . 1003 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1004 (CIDR): The Internet Address Assignment and Aggregation 1005 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, 1006 August 2006, . 1008 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1009 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1010 DOI 10.17487/RFC5389, October 2008, 1011 . 1013 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1014 Optimization (ALTO) Problem Statement", RFC 5693, 1015 DOI 10.17487/RFC5693, October 2009, 1016 . 1018 [RFC6708] Kiesel, S., Ed., Previdi, S., Stiemerling, M., Woundy, R., 1019 and Y. Yang, "Application-Layer Traffic Optimization 1020 (ALTO) Requirements", RFC 6708, DOI 10.17487/RFC6708, 1021 September 2012, . 1023 [RFC7216] Thomson, M. and R. Bellis, "Location Information Server 1024 (LIS) Discovery Using IP Addresses and Reverse DNS", 1025 RFC 7216, DOI 10.17487/RFC7216, April 2014, 1026 . 1028 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1029 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1030 "Application-Layer Traffic Optimization (ALTO) Protocol", 1031 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1032 . 1034 [RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 1035 H. Song, "Application-Layer Traffic Optimization (ALTO) 1036 Server Discovery", RFC 7286, DOI 10.17487/RFC7286, 1037 November 2014, . 1039 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1040 Trammell, B., Huitema, C., and D. Borkmann, 1041 "Confidentiality in the Face of Pervasive Surveillance: A 1042 Threat Model and Problem Statement", RFC 7624, 1043 DOI 10.17487/RFC7624, August 2015, 1044 . 1046 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 1047 DOI 10.17487/RFC7626, August 2015, 1048 . 1050 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1051 and P. Hoffman, "Specification for DNS over Transport 1052 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, 1053 May 2016, . 1055 [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and 1056 S. Previdi, "Application-Layer Traffic Optimization (ALTO) 1057 Deployment Considerations", RFC 7971, DOI 10.17487/ 1058 RFC7971, October 2016, 1059 . 1061 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1062 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1063 . 1065 Appendix A. Solution Approaches for Partitioned ALTO Knowledge 1067 The ALTO base protocol document [RFC7285] specifies the communication 1068 between an ALTO client and a single ALTO server. It is implicitly 1069 assumed that this server can answer any query, possibly with some 1070 kind of default value if no exact data is known. No special 1071 provisions were made for the case that the ALTO information 1072 originates from multiple sources, which are possibly under the 1073 control of different administrative entities (e.g., different ISPs) 1074 or that the overall ALTO information is partitioned and stored on 1075 several ALTO servers. 1077 A.1. Classification of Solution Approaches 1079 Various protocol extensions and other solutions have been proposed to 1080 deal with multiple information sources and partitioned knowledge. 1081 They can be classified as follows: 1083 1 Ensure that all ALTO servers have the same knowledge 1085 1.1 Ensure data replication and synchronization within the 1086 provisioning protocol (cf. RFC 5693, Fig 1 [RFC5693]). 1088 1.2 Use an Inter-ALTO-server data replication protocol. Possibly, 1089 the ALTO protocol itself - maybe with some extensions - could be 1090 used for that purpose; however, this has not been studied in 1091 detail so far. 1093 2 Accept that different ALTO servers (possibly operated by 1094 different organizations, e.g., ISPs) do not have the same 1095 knowledge 1097 2.1 Allow ALTO clients to send arbitrary queries to any ALTO server 1098 (e.g. the one discovered using [RFC7286]). If this server 1099 cannot answer the query itself, it will fetch the data on behalf 1100 of the client, using the ALTO protocol or a to-be-defined inter- 1101 ALTO-server request forwarding protocol. 1103 2.2 Allow ALTO clients to send arbitrary queries to any ALTO server 1104 (e.g. the one discovered using [RFC7286]). If this server 1105 cannot answer the query itself, it will redirect the client to 1106 the "right" ALTO server that has the desired information, using 1107 a small to-be-defined extension of the ALTO protocol. 1109 2.3 ALTO clients need to use some kind of "search engine" that 1110 indexes ALTO servers and redirects and/or gives cached results. 1112 2.4 ALTO clients need to use a new discovery mechanism to discover 1113 the ALTO server that has the desired information and contact it 1114 directly. 1116 A.2. Discussion of Solution Approaches 1118 The provisioning or initialization protocol for ALTO servers (cf. RFC 1119 5693, Fig 1 [RFC5693]) is currently not standardized. It was a 1120 conscious decision not to include this in the scope of the IETF ALTO 1121 working group. The reason is that there are many different kinds of 1122 information sources. This implementation specific protocol will 1123 adapt them to the ALTO server, which offers a standardized protocol 1124 to the ALTO clients. However, adding the task of synchronization 1125 between ALTO servers to this protocol (i.e., approach 1.1) would 1126 overload this protocol with a second functionality that requires 1127 standardization for seamless multi-domain operation. 1129 For the 1.? solution approaches, in addition to general technical 1130 feasibility and issues like overhead and caching efficiency, another 1131 aspect to consider is legal liability. Operator "A" might prefer not 1132 to publish information about nodes in or paths between the networks 1133 of operators "B" and "C" through A's ALTO server, even if A knew that 1134 information. This is not only a question of map size and processing 1135 load on A's ALTO server. Operator A could also face legal liability 1136 issues if that information had a bad impact on the traffic 1137 engineering between B's and C's networks, or on their business 1138 models. 1140 No specific actions to build a "search engine" based solution 1141 (approach 2.3) are currently known and it is unclear what could be 1142 the incentives to operate such an engine. Therefore, this approach 1143 is not considered in the remainder of this document. 1145 A.3. The Need for Cross-Domain ALTO Server Discovery 1147 Approaches 1.1, 1.2, 2.1, and 2.2 do not only require the 1148 specification of an ALTO protocol extension or a new protocol that 1149 runs between ALTO servers. A large-scale, maybe Internet-wide, 1150 multi-domain deployment would also need mechanisms by which an ALTO 1151 server could discover other ALTO servers, learn which information is 1152 available where, and ideally also who is authorized to publish 1153 information related to a given part of the network. Approach 2.4 1154 needs the same mechanisms, except that they are used on the client- 1155 side instead of the server-side. 1157 It is sometimes questioned whether there is a need for a solution 1158 that allows clients to ask arbitrary queries, even if the ALTO 1159 information is partitioned and stored on many ALTO servers. The main 1160 argument is, that clients are supposed to optimize the traffic from 1161 and to themselves, and that the information needed for that is most 1162 likely stored on a "nearby" ALTO server, i.e., the one that can be 1163 discovered using [RFC7286]. However, there are scenarios where the 1164 ALTO client is not co-located with an endpoint of the to-be-optimized 1165 data transmission. Instead, the ALTO client is located at a third 1166 party, which takes part in the application signaling, e.g., a so- 1167 called "tracker" in a peer-to-peer application. One such scenario, 1168 where it is advantageous to place the ALTO client not at an endpoint 1169 of the user data transmission, is analyzed in Appendix C. 1171 A.4. Our Solution Approach 1173 Several solution approaches for cross-domain ALTO server discovery 1174 have been evaluated, using the criteria documented in Appendix B. 1175 One of them was to use the ALTO protocol itself for the exchange of 1176 information availability [I-D.kiesel-alto-alto4alto]. However, the 1177 drawback of that approach is that a new registration administration 1178 authority would have to be established. 1180 This document specifies a DNS-based procedure for cross-domain ALTO 1181 server discovery, which was inspired by "Location Information Server 1182 (LIS) Discovery Using IP Addresses and Reverse DNS" [RFC7216]. The 1183 primary goal is that this procedure can be used on the client-side 1184 (i.e., approach 2.4), but together with new protocols or protocol 1185 extensions it could also be used to implement the other solution 1186 approaches itemized above. 1188 A.5. Relation to the ALTO Requirements 1190 During the design phase of the overall ALTO solution, two different 1191 server discovery scenarios have been identified and documented in the 1192 ALTO requirements document [RFC6708]. The first scenario, documented 1193 in Req. AR-32, can be supported using the discovery mechanisms 1194 specified in [RFC7286]. An alternative approach, based on IP anycast 1195 [I-D.kiesel-alto-ip-based-srv-disc], has also been studied. This 1196 document, in contrast, tries to address Req. AR-33. 1198 Appendix B. Requirements for Cross-Domain Server Discovery 1200 This appendix itemizes requirements that have been collected before 1201 the design phase and that are reflected by the design of the ALTO 1202 Cross-Domain Server Discovery Procedure. 1204 B.1. Discovery Client Application Programming Interface 1206 The discovery client will be called through some kind of application 1207 programming interface (API) and the parameters will be an IP address 1208 and, for purposes of extensibility, a service identifier such as 1209 "ALTO". It will return one or more URI(s) that offers the requested 1210 service ("ALTO") for the given IP address. 1212 In other words, the client would be used to retrieve a mapping: 1214 (IP address, "ALTO") -> IRD-URI(s) 1216 where IRD-URI(s) is one or more URI(s) of Information Resource 1217 Directories (IRD, see Section 9 of [RFC7285]) of ALTO server(s) that 1218 can give reasonable guidance to a resource consumer with the 1219 indicated IP address. 1221 B.2. Data Storage and Authority Requirements 1223 The information for mapping IP addresses and service parameters to 1224 URIs should be stored in a - preferably distributed - database. It 1225 must be possible to delegate administration of parts of this 1226 database. Usually, the mapping from a specific IP address to an URI 1227 is defined by the authority that has administrative control over this 1228 IP address, e.g., the ISP in residential access networks or the IT 1229 department in enterprise, university, or similar networks. 1231 B.3. Cross-Domain Operations Requirements 1233 The cross-domain server discovery mechanism should be designed in 1234 such a way that it works across the public Internet and also in other 1235 IP-based networks. This in turn means that such mechanisms cannot 1236 rely on protocols that are not widely deployed across the Internet or 1237 protocols that require special handling within participating 1238 networks. An example is multicast, which is not generally available 1239 across the Internet. 1241 The ALTO Cross-Domain Server Discovery protocol must support gradual 1242 deployment without a network-wide flag day. If the mechanism needs 1243 some kind of well-known "rendezvous point", re-using an existing 1244 infrastructure (such as the DNS root servers or the WHOIS database) 1245 should be preferred over establishing a new one. 1247 B.4. Protocol Requirements 1249 The protocol must be able to operate across middleboxes, especially 1250 across NATs and firewalls. 1252 The protocol shall not require any pre-knowledge from the client 1253 other than any information that is known to a regular IP host on the 1254 Internet. 1256 B.5. Further Requirements 1258 The ALTO cross domain server discovery cannot assume that the server 1259 discovery client and the server discovery responding entity are under 1260 the same administrative control. 1262 Appendix C. ALTO and Tracker-based Peer-to-Peer Applications 1264 This appendix provides a complete example of using ALTO and the ALTO 1265 Cross-Domain Server Discovery Procedure in one specific application 1266 scenario, namely a tracker-based peer-to-peer application. First, in 1267 subsection C.1, we introduce a generic model of such an application 1268 and show why ALTO optimization is desirable. Then, in C.2, we 1269 introduce two architectural options for integrating ALTO into the 1270 tracker-based peer-to-peer application - one option is based on the 1271 "regular" ALTO server discovery procedure [RFC7286], one relies on 1272 the ALTO Cross-Domain Server Discovery Procedure. In C.3, a simple 1273 mathematical model is used to show that the latter approach is 1274 expected to yield significantly better optimization results. The 1275 appendix concludes with subsection C.4, which details an exemplary 1276 complete walk-through of the ALTO Cross-Domain Server Discovery 1277 Procedure. 1279 C.1. A generic Tracker-based Peer-to-Peer Application 1281 The optimization of peer-to-peer (P2P) applications such as 1282 BitTorrent was one of the first use cases that lead to the inception 1283 of the IETF ALTO working group. Further use cases have been 1284 identified as well, yet we will use this scenario to illustrate the 1285 operation and usefulness of the ALTO Cross-Domain Server Discovery 1286 Procedure. 1288 For the remainder of this chapter we consider a generic, tracker- 1289 based peer-to-peer file sharing application. The goal is the 1290 dissemination of a large file, without using one large server with a 1291 correspondingly high upload bandwidth. The file is split into 1292 chunks. So-called "peers" assume the role of both a client and a 1293 server. That is, they may request chunks from other peers and they 1294 may serve the chunks they already possess to other peers at the same 1295 time, thereby contributing their upload bandwidth. Peers that want 1296 to share the same file participate in a "swarm". They use the peer- 1297 to-peer protocol to inform each other about the availability of 1298 chunks and to request and transfer chunks from one peer to another. 1299 A swarm may consist of a very large number of peers. Consequently, 1300 peers usually maintain logical connections only to a subset of all 1301 peers in the swarm. If a new peer wants to join a swarm, it first 1302 contacts a well-known server, the "tracker", which provides a list of 1303 IP addresses of peers in the swarm. 1305 A swarm is an overlay network on top of the IP network. Algorithms 1306 that determine the overlay topology and the traffic distribution in 1307 the overlay may consider information about the underlying IP network, 1308 such as topological distance, link bandwidth, (monetary) costs for 1309 sending traffic from one host to another, etc. ALTO is a protocol 1310 for retrieving such information. The goal of such "topology aware" 1311 decisions is to improve performance or Quality of Experience in the 1312 application while reducing the utilization of the underlying network 1313 infrastructure. 1315 C.2. Architectural Options for Placing the ALTO Client 1317 The ALTO protocol specification [RFC7285] details how an ALTO client 1318 can query an ALTO server for guiding information and receive the 1319 corresponding replies. However, in the considered scenario of a 1320 tracker-based P2P application, there are two fundamentally different 1321 possibilities where to place the ALTO client: 1323 1. ALTO client in the resource consumer ("peer") 1325 2. ALTO client in the resource directory ("tracker") 1327 In the following, both scenarios are compared in order to explain the 1328 need for ALTO queries on behalf of remote resource consumers. 1330 In the first scenario (see Figure 2), the resource consumer queries 1331 the resource directory for the desired resource (F1). The resource 1332 directory returns a list of potential resource providers without 1333 considering ALTO (F2). It is then the duty of the resource consumer 1334 to invoke ALTO (F3/F4), in order to solicit guidance regarding this 1335 list. 1337 In the second scenario (see Figure 4), the resource directory has an 1338 embedded ALTO client. After receiving a query for a given resource 1339 (F1) the resource directory invokes this ALTO client to evaluate all 1340 resource providers it knows (F2/F3). Then it returns a, possibly 1341 shortened, list containing the "best" resource providers to the 1342 resource consumer (F4). 1344 ............................. ............................. 1345 : Tracker : : Peer : 1346 : ______ : : : 1347 : +-______-+ : : k good : 1348 : | | +--------+ : P2P App. : +--------+ peers +------+ : 1349 : | N | | random | : Protocol : | ALTO- |------>| data | : 1350 : | known |====>| pre- |*************>| biased | | ex- | : 1351 : | peers, | | selec- | : transmit : | peer |------>| cha- | : 1352 : | M good | | tion | : n peer : | select | n-k | nge | : 1353 : +-______-+ +--------+ : IDs : +--------+ bad p.+------+ : 1354 :...........................: :.....^.....................: 1355 | 1356 | ALTO protocol 1357 __|___ 1358 +-______-+ 1359 | | 1360 | ALTO | 1361 | server | 1362 +-______-+ 1364 Figure 1: Tracker-based P2P Application with random peer preselection 1366 Peer w. ALTO cli. Tracker ALTO Server 1367 --------+-------- --------+-------- --------+-------- 1368 | F1 Tracker query | | 1369 |======================>| | 1370 | F2 Tracker reply | | 1371 |<======================| | 1372 | F3 ALTO query | | 1373 |---------------------------------------------->| 1374 | F4 ALTO reply | | 1375 |<----------------------------------------------| 1376 | | | 1378 ==== Application protocol (i.e., tracker-based P2P app protocol) 1379 ---- ALTO protocol 1381 Figure 2: Basic message sequence chart for resource consumer- 1382 initiated ALTO query 1384 ............................. ............................. 1385 : Tracker : : Peer : 1386 : ______ : : : 1387 : +-______-+ : : : 1388 : | | +--------+ : P2P App. : k good peers & +------+ : 1389 : | N | | ALTO- | : Protocol : n-k bad peers | data | : 1390 : | known |====>| biased |******************************>| ex- | : 1391 : | peers, | | peer | : transmit : | cha- | : 1392 : | M good | | select | : n peer : | nge | : 1393 : +-______-+ +--------+ : IDs : +------+ : 1394 :.....................^.....: :...........................: 1395 | 1396 | ALTO protocol 1397 __|___ 1398 +-______-+ 1399 | | 1400 | ALTO | 1401 | server | 1402 +-______-+ 1404 Figure 3: Tracker-based P2P Application with ALTO client in tracker 1406 Peer Tracker w. ALTO cli. ALTO Server 1407 --------+-------- --------+-------- --------+-------- 1408 | F1 Tracker query | | 1409 |======================>| | 1410 | | F2 ALTO query | 1411 | |---------------------->| 1412 | | F3 ALTO reply | 1413 | |<----------------------| 1414 | F4 Tracker reply | | 1415 |<======================| | 1416 | | | 1418 ==== Application protocol (i.e., tracker-based P2P app protocol) 1419 ---- ALTO protocol 1421 Figure 4: Basic message sequence chart for ALTO query on behalf of 1422 remote resource consumer 1424 Note: the message sequences depicted in Figure 2 and Figure 4 may 1425 occur both in the target-aware and the target-independent query mode 1426 (c.f. [RFC6708]). In the target-independent query mode no message 1427 exchange with the ALTO server might be needed after the tracker 1428 query, because the candidate resource providers could be evaluated 1429 using a locally cached "map", which has been retrieved from the ALTO 1430 server some time ago. 1432 C.3. Evaluation 1434 The problem with the first approach is, that while the resource 1435 directory might know thousands of peers taking part in a swarm, the 1436 list returned to the resource consumer is usually shortened for 1437 efficiency reasons. Therefore, the "best" (in the sense of ALTO) 1438 potential resource providers might not be contained in that list 1439 anymore, even before ALTO can consider them. 1441 For illustration, consider a simple model of a swarm, in which all 1442 peers fall into one of only two categories: assume that there are 1443 "good" ("good" in the sense of ALTO's better-than-random peer 1444 selection, based on an arbitrary desired rating criterion) and "bad' 1445 peers only. Having more different categories makes the maths more 1446 complex but does not change anything to the basic outcome of this 1447 analysis. Assume that the swarm has a total number of N peers, out 1448 of which are M "good" and N-M "bad" peers, which are all known to the 1449 tracker. A new peer wants to join the swarm and therefore asks the 1450 tracker for a list of peers. 1452 If, according to the first approach, the tracker randomly picks n 1453 peers from the N known peers, the result can be described with the 1454 hypergeometric distribution. The probability that the tracker reply 1455 contains exactly k "good" peers (and n-k "bad" peers) is: 1457 / M \ / N - M \ 1458 \ k / \ n - k / 1459 P(X=k) = --------------------- 1460 / N \ 1461 \ n / 1463 / n \ n! 1464 with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1 1465 k! (n-k)! 1467 The probability that the reply contains at most k "good" peers is: 1468 P(X<=k)=P(X=0)+P(X=1)+..+P(X=k). 1470 For example, consider a swarm with N=10,000 peers known to the 1471 tracker, out of which M=100 are "good" peers. If the tracker 1472 randomly selects n=100 peers, the formula yields for the reply: 1473 P(X=0)=36%, P(X<=4)=99%. That is, with a probability of approx. 36% 1474 this list does not contain a single "good" peer, and with 99% 1475 probability there are only four or less of the "good" peers on the 1476 list. Processing this list with the guiding ALTO information will 1477 ensure that the few favorable peers are ranked to the top of the 1478 list; however, the benefit is rather limited as the number of 1479 favorable peers in the list is just too small. 1481 Much better traffic optimization could be achieved if the tracker 1482 would evaluate all known peers using ALTO, and return a list of 100 1483 peers afterwards. This list would then include a significantly 1484 higher fraction of "good" peers. (Note, that if the tracker returned 1485 "good" peers only, there might be a risk that the swarm might 1486 disconnect and split into several disjunct partitions. However, 1487 finding the right mix of ALTO-biased and random peer selection is out 1488 of the scope of this document.) 1490 Therefore, from an overall optimization perspective, the second 1491 scenario with the ALTO client embedded in the resource directory is 1492 advantageous, because it is ensured that the addresses of the "best" 1493 resource providers are actually delivered to the resource consumer. 1494 An architectural implication of this insight is that the ALTO server 1495 discovery procedures must support ALTO queries on behalf of remote 1496 resource consumers. That is, as the tracker issues ALTO queries on 1497 behalf of the peer which contacted the tracker, the tracker must be 1498 able to discover an ALTO server that can give guidance suitable for 1499 that respective peer. This task can be solved using the ALTO Cross- 1500 Domain Server Discovery Procedure. 1502 C.4. Example 1504 This section provides a complete example of the ALTO Cross-Domain 1505 Server Discovery Procedure in a tracker-based peer-to-peer scenario. 1507 The example is based on the network topology shown in Figure 5. Five 1508 access networks - Networks a, b, c, x, and t - are operated by five 1509 different network operators. They are interconnected by a backbone 1510 structure. Each network operator runs an ALTO server in their 1511 network, i.e., ALTO_SRV_A, ALTO_SRV_B, ALTO_SRV_C, ALTO_SRV_X, and 1512 ALTO_SRV_T, respectively. 1514 _____ __ _____ __ _____ __ 1515 __( )__( )_ __( )__( )_ __( )__( )_ 1516 ( Network a ) ( Network b ) ( Network c ) 1517 ( Res. Provider A ) ( Res. Provider B ) ( Res. Provider C ) 1518 (__ ALTO_SRV_A __) (__ ALTO_SRV_B __) (__ ALTO_SRV_C __) 1519 (___)--(____) \ (___)--(____) / (___)--(____) 1520 \ / / 1521 ---+---------+-----------------+---- 1522 ( Backbone ) 1523 ------------+------------------+---- 1524 _____ __/ _____ \__ 1525 __( )__( )_ __( )__( )_ 1526 ( Network x ) ( Network t ) 1527 ( Res. Consumer X ) (Resource Directory) 1528 (_ ALTO_SRV_X __) (_ ALTO_SRV_T __) 1529 (___)--(____) (___)--(____) 1531 Figure 5: Example network topology 1533 A new peer of a peer-to-peer application wants to join a specific 1534 swarm (overlay network), in order to access a specific resource. 1535 This new peer will be called "Resource Consumer X" in accordance to 1536 the terminology of [RFC6708] and it is located in Network x. It 1537 contacts the tracker ("Resource Directory"), which is located in 1538 Network t. The mechanism by which the new peer discovers the tracker 1539 is out of the scope of this document. The tracker maintains a list 1540 of peers that take part in the overlay network, and hence it can 1541 determine that Resource Providers A, B, and C are candidate peers for 1542 Resource Consumer X. 1544 As shown in the previous section, a tracker-side ALTO optimization 1545 (c.f. Figure 3 and Figure 4) is more efficient than a client-side 1546 optimization. Consequently, the tracker wants to use the ALTO 1547 Endpoint Cost Service (ECS) to learn the routing costs between X and 1548 A, X and B, as well as X and C, in order to sort A, B, and C by their 1549 respective routing costs to X. 1551 In theory, there are many options how the ALTO Cross-Domain Server 1552 Discovery Procedure could be used. For example, the tracker could do 1553 the following steps: 1555 IRD_URIS_A = XDOMDISC(A,"ALTO:https") 1556 COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_A 1558 IRD_URIS_B = XDOMDISC(B,"ALTO:https") 1559 COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_B 1561 IRD_URIS_C = XDOMDISC(C,"ALTO:https") 1562 COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_C 1564 Maybe, the ALTO Cross-Domain Server Discovery Procedure queries would 1565 yield in this scenario: IRD_URIS_A = ALTO_SRV_A, IRD_URIS_B = 1566 ALTO_SRV_B, and IRD_URIS_C = ALTO_SRV_C. That is, each ECS query 1567 would be sent to a different ALTO server. The problem with this 1568 approach is that we are not neccessarily able to compare COST_X_A, 1569 COST_X_B, and COST_X_C with each other. The specification of the 1570 routingcost metric mandates that "A lower value indicates a higher 1571 preference", but "an ISP may internally compute routing cost using 1572 any method that it chooses" (see section 6.1.1.1. of [RFC7285]). 1573 Thus, COST_X_A could be 10 (milliseconds round-trip time), while 1574 COST_X_B could be 200 (kilometers great circle distance between the 1575 approximate geographic locations of the hosts) and COST_X_C could be 1576 3 (router hops, corresponding to a decrease of the TTL field in the 1577 IP header). Each of these metrics fulfills the "lower value is more 1578 preferable" requirement on its own, but obviously, they cannot be 1579 compared with each other. Even if there was a reasonable formula to 1580 compare, for example, kilometers with milliseconds, we could not use 1581 it, as the units of measurement (or any other information about the 1582 computation method for the routingcost) are not sent along with the 1583 value in the ECS reply. 1585 To avoid this problem, the tracker tries to send all ECS queries to 1586 the same ALTO server. As specified in Section 4.4 of this document, 1587 case 2, it uses the IP address of Resource Consumer x as parameter to 1588 the discovery procedure: 1590 IRD_URIS_X = XDOMDISC(X,"ALTO:https") 1591 COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_X 1592 COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_X 1593 COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_X 1595 This strategy ensures that COST_X_A, COST_X_B, and COST_X_C can be 1596 compared with each other. 1598 As discussed above, the tracker calls the ALTO Cross-Domain Server 1599 Discovery Procedure with IP address X as a parameter. For the 1600 reminder of this example, we assume that X = 2001:DB8:1:2:227:eff: 1601 fe6a:de42. Thus, the procedure call is 1603 IRD_URIS_X = XDOMDISC(2001:DB8:1:2:227:eff:fe6a:de42,"ALTO:https"). 1605 The first parameter 2001:DB8:1:2:227:eff:fe6a:de42 is a single IPv6 1606 address. Thus, we get AT = IPv6, A = 2001:DB8:1:2:227:eff:fe6a:de42, 1607 L = 128, and SP = "ALTO:https". 1609 The procedure constructs (see Step 1 in Section 3.2) 1610 R128 = "2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.2.0.0.0.1.0.0.0. 1611 8.B.D.0.1.0.0.2.IP6.ARPA.", as well as (see Step 2 in Section 3.3) 1612 R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", 1613 R56 = "0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", 1614 R48 = "1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", 1615 R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and 1616 R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.". 1618 In order to illustrate the third step of the ALTO Cross-Domain Server 1619 Discovery Procedure, we use the "dig" (domain information groper) DNS 1620 lookup utility that is available for many operating systems (e.g., 1621 Linux). A real implementation of the ALTO Cross-Domain Server 1622 Discovery Procedure would not be based on the "dig" utility, but use 1623 appropriate libraries and/or operating system APIs. Please note that 1624 the following steps have been performed in a controlled lab 1625 environment with a appropriately configured name server. A suitable 1626 DNS configuration will be needed to reproduce these results. Please 1627 also note that the rather verbose output of the "dig" tool has been 1628 shortened to the relevant lines. 1630 Since AT = IPv6 and L = 128, in the table given in Section 3.4, the 1631 sixth row (not counting the column headers) applies. 1633 As mandated by the third column, we start with a lookup of R128, 1634 looking for NAPTR resource records: 1636 | user@labpc:~$ dig -tNAPTR 2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.\ 1637 | 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 1638 | 1639 | ;; Got answer: 1640 | ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26553 1641 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0 1643 The domain name R128 does not exist (status: NXDOMAIN), so we cannot 1644 get a useful result. Therefore, we continue with the fourth column 1645 of the table and do a lookup of R64: 1647 | user@labpc:~$ dig -tNAPTR 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 1648 | 1649 | ;; Got answer: 1650 | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33193 1651 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0 1653 The domain name R64 could be looked up (status: NOERROR), but there 1654 are no NAPTR resource records associated with it (ANSWER: 0). Maybe, 1655 there are some other resource records such as PTR, NS, or SOA, but we 1656 are not interested in them. Thus, we do not get a useful result and 1657 we continue with looking up R56: 1659 | user@labpc:~$ dig -tNAPTR 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 1660 | 1661 | ;; Got answer: 1662 | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35966 1663 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2 1664 | 1665 | ;; ANSWER SECTION: 1666 | 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u" 1667 | "LIS:HELD" "!.*!https://lis1.example.org:4802/?c=ex!" . 1668 | 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 20 "u" 1669 | "LIS:HELD" "!.*!https://lis2.example.org:4802/?c=ex!" . 1671 The domain name R56 could be looked up and there are NAPTR resource 1672 records associated with it. However, each of these records has a 1673 service parameter that does not match our SP = "ALTO:https" (see 1674 [RFC7216] for "LIS:HELD"), and therefore, we have to ignore them. 1675 Consequently, we still do not have a useful result and continue with 1676 a lookup of R48: 1678 | user@labpc:~$ dig -tNAPTR 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 1679 | 1680 | ;; Got answer: 1681 | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50459 1682 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2 1683 | 1684 | ;; ANSWER SECTION: 1685 | 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u" 1686 | "ALTO:https" "!.*!https://alto1.example.net/ird!" . 1687 | 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u" 1688 | "LIS:HELD" "!.*!https://lis.example.net:4802/?c=ex!" . 1690 This lookup yields two NAPTR resource records. We have to ignore the 1691 second one as its service parameter does not match our SP, but the 1692 first NAPTR resource record has a matching service parameter. 1693 Therefore, the procedure terminates successfully and the final 1694 outcome is: IRD_URIS_X = "https://alto1.example.net/ird". 1696 The ALTO client that is embedded in the tracker will access the ALTO 1697 Information Resource Directory (IRD, see Section 9 of [RFC7285]) at 1698 this URI, look for the Endpoint Cost Service (ECS, see Section 11.5 1699 of [RFC7285]), and query the ECS for the costs between A and X, B and 1700 X, as well as C and X, before returning an ALTO-optimized list of 1701 candidate resource providers to resource consumer X. 1703 Appendix D. Contributors List and Acknowledgments 1705 The initial version of this document was co-authored by Marco Tomsu 1706 (Alcatel-Lucent). 1708 This document borrows some text from [RFC7286], as historically, it 1709 has been part of the draft that eventually became said RFC. Special 1710 thanks to Michael Scharf and Nico Schwan. 1712 Authors' Addresses 1714 Sebastian Kiesel 1715 University of Stuttgart Information Center 1716 Allmandring 30 1717 Stuttgart 70550 1718 Germany 1720 Email: ietf-alto@skiesel.de 1721 URI: http://www.izus.uni-stuttgart.de 1723 Martin Stiemerling 1724 University of Applied Sciences Darmstadt, Computer Science Dept. 1725 Haardtring 100 1726 Darmstadt 64295 1727 Germany 1729 Phone: +49 6151 16 37938 1730 Email: mls.ietf@gmail.com 1731 URI: http://ietf.stiemerling.org