idnits 2.17.1 draft-kiesel-alto-3pdisc-03.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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 164 has weird spacing: '...Service alto...' == Line 166 has weird spacing: '... Proto tcp...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 9, 2010) is 5039 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'I-D.kiesel-alto-3pdisc' is defined on line 428, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-04 == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-05 == Outdated reference: A later version (-05) exists of draft-kiesel-alto-3pdisc-02 == Outdated reference: A later version (-06) exists of draft-stiemerling-alto-deployments-03 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 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: Informational M. Tomsu 5 Expires: January 10, 2011 N. Schwan 6 M. Scharf 7 Alcatel-Lucent Bell Labs 8 M. Stiemerling 9 NEC Europe Ltd. 10 July 9, 2010 12 Third-party ALTO server discovery 13 draft-kiesel-alto-3pdisc-03 15 Abstract 17 The goal of Application-Layer Traffic Optimization (ALTO) is to 18 provide guidance to applications, which have to select one or several 19 hosts from a set of candidates that are able to provide a desired 20 resource. 22 Entities seeking guidance need to discover and possibly select an 23 ALTO server to ask. This is called ALTO server discovery. This memo 24 describes an ALTO server discovery mechanism based on DNS SRV 25 records. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 10, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. DNS-based ALTO Server Discovery . . . . . . . . . . . . . . . 5 63 2.1. DNS SRV record definition . . . . . . . . . . . . . . . . 5 64 2.2. DNS SRV record lookup procedure . . . . . . . . . . . . . 6 65 2.2.1. Step 1: Finding the IP address . . . . . . . . . . . . 6 66 2.2.2. Step 2: Determining the DNS suffix . . . . . . . . . . 6 67 2.2.3. Step 3: Lookup SRV record . . . . . . . . . . . . . . 7 68 2.2.4. Step 4: Final lookup . . . . . . . . . . . . . . . . . 8 69 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.1. Applicability for third party server discovery . . . . . . 9 71 3.2. Applicability for resource consumer server discovery . . . 9 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 77 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 78 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 The goal of Application-Layer Traffic Optimization (ALTO) is to 84 provide guidance to applications, which have to select one or several 85 hosts from a set of candidates, that are able to provide a desired 86 resource[RFC5693]. The requirements for ALTO are itemized in 87 [I-D.ietf-alto-reqs]. ALTO is realized by a client-server protocol. 88 ALTO clients send queries to ALTO servers, in order to solicit 89 guidance. 91 ALTO clients have to discover suitable ALTO servers. Therefore the 92 ALTO discovery client tells the ALTO client which ALTO servers to 93 send the queries to. The ALTO discovery client and the ALTO client 94 can be embedded in the resource consumer, which will eventually 95 access the desired resource. As an alternative, they can be embedded 96 in a resource directory, which assists resource consumers in finding 97 appropriate resource providers. In some specific peer-to-peer 98 application protocols these resource directories are called 99 "trackers". Finally the ALTO discovery client can be embedded in the 100 resource consumer, whereas the ALTO client is embedded in the 101 resource directory. ALTO queries, which are issued by a resource 102 directory on behalf of a resource consumer, are referred to as third- 103 party ALTO queries. The various possibilities to place ALTO servers 104 and the placement of ALTO clients is discussed in 105 [I-D.stiemerling-alto-deployments]. 107 No matter where ALTO server and client are located, clients have to 108 first find out if there is an ALTO server deployed that is in charge 109 for them and second to get the contact information of that server, 110 i.e., the IP address, port number, and probably transport protocol 111 (which defaults to TCP for [I-D.ietf-alto-protocol]). 113 There exists a number of service location protocols, such as SLP 114 [RFC2608] or DHCP [RFC2131][RFC3315], which could in principle be 115 used for ALTO discovery. However, SLP is not widely deployed or used 116 within the Internet. DHCP is widely deployed but has several 117 limitations: 119 o Though widely deployed DHCP is not in use everywhere. For 120 important scenarios, such as PPPoE based DSL access networks one 121 would have to specify another mechanism. 123 o A DHCP-based discovery mechanism will always yield the addresses 124 of the ALTO servers that are provided by the network operator. 125 The user cannot influence the discovery and, e.g., select an 126 alternative ALTO service from an "independent" ALTO operator. 128 o There are problems with residential gateways or broadband routers 129 with NAT. If the network operator gives information about ALTO 130 serves to the residential gateway via DHCP, the residential 131 gateway would have to forward this information to the hosts with 132 the (P2P) applications within the local network. This is not 133 supported by any of the already deployed residential gateways. 135 o DHCP poorly supports third-party ALTO server discovery, i.e., in 136 scenarios where the ALTO client is co-located with a resource 137 directory ("tracker"), which is located in a different 138 administrative domain than the client which will eventually access 139 the ressource. 141 The goal of this memo is to propose a uniform mechanism for all types 142 of ALTO client deployments that is implementable and deployable at a 143 fast pace, i.e., without creating other deployment dependecies for 144 ALTO. One way of fulfilling the previous mentioned requirements is 145 using the Service Records (SRV) of the Domain Name System (DNS), as 146 described in [RFC2782]. DNS SRVs have been defined and are used for 147 a number of protocols, such as SIP and XMPP. 149 Comments and discussions about this memo should be directed to the 150 ALTO working group: alto@ietf.org. 152 2. DNS-based ALTO Server Discovery 154 2.1. DNS SRV record definition 156 We define a new service record for ALTO servers according to 157 [RFC2782]. The general format of the SRV RR, whose DNS type code is 158 33, is 160 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 162 Where for the ALTO server discovery, we define: 164 Service alto 166 Proto tcp 168 Name "The domain this RR refers to. The SRV RR is unique in that 169 the name one searches for is not this name; the example near the 170 end shows this clearly."[RFC2782] 172 TTL Standard DNS meaning [RFC2782] 174 Class Standard DNS meaning[RFC2782] 176 Priority "The priority of this target host. A client MUST attempt 177 to contact the target host with the lowest-numbered priority it 178 can reach; target hosts with the same priority SHOULD be tried in 179 an order defined by the weight field. The range is 0-65535. This 180 is a 16 bit unsigned integer in network byte order." [RFC2782] 182 Weight "A server selection mechanism. The weight field specifies a 183 relative weight for entries with the same priority. Larger 184 weights SHOULD be given a proportionately higher probability of 185 being selected. The range of this number is 0-65535. This is a 186 16 bit unsigned integer in network byte order. Domain 187 administrators SHOULD use Weight 0 when there isn't any server 188 selection to do, to make the RR easier to read for humans (less 189 noisy). In the presence of records containing weights greater 190 than 0, records with weight 0 should have a very small chance of 191 being selected.[...]" [RFC2782] 193 Port "The port on this target host of this service. The range is 0- 194 65535. This is a 16 bit unsigned integer in network byte order. 195 This is often as specified in Assigned Numbers but need not 196 be."[RFC2782] It will be set to 80, if the standard TCP port for 197 HTTP is used, but this also allows to run the service on any other 198 port. 200 Target "The domain name of the target host. There MUST be one or 201 more address records for this name, the name MUST NOT be an alias 202 (in the sense of RFC 1034 or RFC 2181). Implementors are urged, 203 but not required, to return the address record(s) in the 204 Additional Data section. Unless and until permitted by future 205 standards action, name compression is not to be used for this 206 field. A Target of "." means that the service is decidedly not 207 available at this domain. "[RFC2782] 209 An example for querying for such an ALTO service record running in 210 the domain myisp.net: 212 _alto._tcp.example.com IN SRV 1 0 80 alto-srv01.myisp.net 214 2.2. DNS SRV record lookup procedure 216 This section describes the algorithm that is applied to discover the 217 ALTO server. We differentiate between two use cases: In use case (a) 218 the user has no specific wish which ALTO service instance to use. 219 Here the ALTO service instance is provided by default by the user's 220 access network provider, thus the ALTO discovery client needs to 221 determine the correct domain name automatically. In case (b) the 222 user configures a specific ALTO service instance that he wants to 223 use. Here the ALTO discovery client already has the information 224 about which DNS suffix to use. 226 2.2.1. Step 1: Finding the IP address 228 The first step for the ALTO discovery client is to determine the IP 229 address or IP addresses of the resource consumer. The resource 230 consumer may have private IP addresses and public IP addresses and 231 depending on the deployment it might be necessary to determine for 232 all IP addresses the ALTO server in charge of. To determine its 233 public IP address the resource consumer may need to use STUN[RFC5389] 234 or BEP24[bep24]. For the following example we assume that the IP 235 address of the resource consumer is a.b.c.d 237 2.2.2. Step 2: Determining the DNS suffix 239 To get the DNS suffix in case (a) the ALTO discovery uses a DNS PTR 240 query for the IP address of the resource consumer as determined in 241 step 1. The local DNS server resolves the IP address to the FQDN 242 that also contains the DNS suffix for the respective IP address. A 243 possible answer for a PTR lookup for d.c.b.a.in-addr.apra might be, 244 for example: 246 d-c-b-a.dsl.westcoast.myisp.net 248 In case (b) The user specifies the DNS suffix on its own, for example 249 in a config file option. Here the user wants to use an ALTO service 250 instance which is operated by a third party as for example the 251 tracker operator. A possible DNS suffix entered by the user may be: 253 myaltoprovider.org 255 2.2.3. Step 3: Lookup SRV record 257 In step 3 the ALTO discovery client uses the information that has 258 been determined in the previous steps to composes the domain name 259 that is used for the SRV queries. As the suffix part in not obvious 260 in all cases e.g., it can be for the above example 261 "westcoast.myisp.net" or "myisp.net", the ALTO discovery client might 262 need to perform multiple SRV lookups until it gets a PTR reply. 264 In case (a) the ALTO discovery client composes the domain name as 265 described in Section 2. If there is no response to the lookup the 266 DNS suffix is shortened by one part for the succeeding lookup. The 267 domain names used for the example as described above are: 269 _alto._tcp.d-c-b-a.dsl.westcoast.myisp.net. 271 _alto._tcp.dsl.westcoast.myisp.net. 273 _alto._tcp.westcoast.myisp.net. 275 _alto._tcp.myisp.net. 277 For case (b) the ALTO discovery client extends the DNS suffix by the 278 IP address of the resource consumer in reverse order to compose the 279 domain name. This is needed for the third party ALTO service 280 instance to direct the ALTO client to the ALTO server closest to the 281 client in case there are multiple ALTO servers deployed. The suffix 282 is then shortened as described before until a lookup is successful, 283 as for example 285 _alto._tcp.d.c.b.a.myaltoprovider.org. 287 _alto._tcp.c.b.a.myaltoprovider.org. 289 _alto._tcp.b.a.myaltoprovider.org. 291 _alto._tcp.a.myaltoprovider.org. 293 _alto._tcp.myaltoprovider.org. 295 2.2.4. Step 4: Final lookup 297 After step 3 has been completed the ALTO discovery client processes 298 the PTR records and performs the final DNS lookup on the A record. 299 It then forwards the contact information to the ALTO client, which 300 can now contact the ALTO server to perform ALTO queries. 302 3. Applicability 304 This section discusses the applicability of the proposed solution 305 with respect to the third party and the resource consumer server 306 discovery deployment scenarios. Each section discusses the proposed 307 steps that are needed to create the right domain name for the final 308 DNS lookup. 310 3.1. Applicability for third party server discovery 312 In case of the third party server discovery deployment scenario the 313 ALTO discovery client is a different entity than the resource 314 consumer. Typically the resource consumer is a peer wehereas the 315 ALTO (discovery) client is a resource directory which seeks for ALTO 316 guidance on behalf of the peer. Another use case for the third party 317 discovery is an application that looks for ALTO guidance 318 transparently to the resource consumer, for example a CDN. 320 Here the ALTO discovery client already knows the IP address of the 321 resource consumer which was used to establish the initial connection. 322 In general this IP address is a public address, either of the 323 resource consumer or of the last NAT on the path to the ALTO client. 324 This makes the IP address a good candidate for the next steps. In 325 case the resource consumer needs guidance for a different IP address, 326 for example one from a private network, we propose that the resource 327 consumer does the server discovery by itself and forwards the ALTO 328 server contact information directly to the ALTO client which in turn 329 can then do the third party ALTO query. 331 To determine the DNS suffix the ALTO discovery client uses a DNS PTR 332 query. As here the IP address is public we expect that the DNS query 333 will be successfully resolved to the FQDN of the domain where the 334 resource consumer is registered in. 336 To compose the right domain name from the FQDN the ALTO discovery 337 client follows the mechansims as described in Section 2.2.3. 338 Additionally the ALTO discovery client can cache domain names and 339 contact details of already discovered ALTO servers and compare them 340 with the FQDN by a longest suffix matching. If successful the client 341 can use the contact information and skip the final discovery step. 343 The fourth step of the procedure can be applied as described. 345 3.2. Applicability for resource consumer server discovery 347 In this scenario the ALTO discovery client that performs the 348 discovery is also the resource consumer, for example a peer in a P2P 349 system. After the discovery the peer does the ALTO query on its own, 350 or it might share the ALTO server contact information with a third 351 party, for example a tracker, which then does the ALTO query on 352 behalf of the peer. 354 DNS SRV records can be used for resource consumer discovery, too. 355 Depending on the deployment scenario the resource consumer will have 356 multiple IP addresses which are possible candidates for a reverse 357 lookup to determine the FQDN in step 2. Usually the ALTO server is 358 responsible for a set of public IP addresses, thus in case the 359 resource consumer is behind a NAT or a residential gateway it needs 360 to determine the public IP address assigned to it. As discussed in 361 Section 2.2.1 this can be done by the use of STUN[RFC5389] or 362 BEP24[bep24]. 364 In other deployment scenarios where internal guidance for a large 365 private domain is desired the ALTO server might be inside the same 366 private domain as the resource consumer. In this case the resource 367 consumer can either use a private IP address or it needs to find a 368 STUN server that is also inside the private domain in order to find 369 the right IP address. 371 To determine the DNS suffix for a public IP address the procedure is 372 as described in the respective section. In case of a private IP 373 address it has to be ensured that the DNS server that is used by the 374 discovery client is a local one that is capable of resolving the 375 private IP address. 377 The third and fourth step of the procedure can be applied as 378 described. 380 4. IANA Considerations 382 This document does not mandate any immediate IANA actions. However, 383 such IANA considerations may arise from future ALTO discovery 384 specification documents which try to meet the requirements given 385 here. 387 5. Security Considerations 389 This early version of this memo does not yet have any security 390 considerations, but they will be added in future revision. 392 6. Conclusion 394 This document describes a general DNS SRV queries based ALTO server 395 discovery mechanism and discusses how ALTO discovery clients can find 396 the right domain name which has to be used for the query. In 397 addition this document discusses the applicability of the described 398 mechanism for the third party as well as the resource consumer 399 discovery. 401 7. References 403 7.1. Normative References 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, March 1997. 408 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 409 specifying the location of services (DNS SRV)", RFC 2782, 410 February 2000. 412 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 413 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 414 October 2008. 416 7.2. Informative References 418 [I-D.ietf-alto-protocol] 419 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 420 draft-ietf-alto-protocol-04 (work in progress), May 2010. 422 [I-D.ietf-alto-reqs] 423 Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 424 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 425 Requirements", draft-ietf-alto-reqs-05 (work in progress), 426 June 2010. 428 [I-D.kiesel-alto-3pdisc] 429 Kiesel, S., Tomsu, M., Schwan, N., and M. Scharf, "Third- 430 party ALTO server discovery", draft-kiesel-alto-3pdisc-02 431 (work in progress), March 2010. 433 [I-D.stiemerling-alto-deployments] 434 Stiemerling, M. and S. Kiesel, "ALTO Deployment 435 Considerations", draft-stiemerling-alto-deployments-03 436 (work in progress), June 2010. 438 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 439 RFC 2131, March 1997. 441 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 442 "Service Location Protocol, Version 2", RFC 2608, 443 June 1999. 445 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 446 and M. Carney, "Dynamic Host Configuration Protocol for 447 IPv6 (DHCPv6)", RFC 3315, July 2003. 449 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 450 Optimization (ALTO) Problem Statement", RFC 5693, 451 October 2009. 453 [bep22] Harrison, D., Shalunov, S., and G. Greg Hazel, "BitTorrent 454 Local Tracker Discovery Protocol", 455 BEP http://bittorrent.org/beps/bep_0022.html. 457 [bep24] Harrison, D., "Tracker Returns External IP", 458 BEP http://bittorrent.org/beps/bep_0024.html. 460 Appendix A. Acknowledgments 462 The authors would like to thank Haibin Song, Richard Alimi, and Roni 463 Even for fruitful discussions during the 75th IETF meeting. 465 Marco Tomsu and Nico Schwan are partially supported by the ENVISION 466 project (http://www.envision-project.org), a research project 467 supported by the European Commission under its 7th Framework Program 468 (contract no. 248565). The views and conclusions contained herein 469 are those of the authors and should not be interpreted as necessarily 470 representing the official policies or endorsements, either expressed 471 or implied, of the ENVISION project or the European Commission. 473 Michael Scharf is supported by the German-Lab project 474 (http://www.german-lab.de) funded by the German Federal Ministry of 475 Education and Research (BMBF). 477 Martin Stiemerling is partially supported by the NAPA-WINE project 478 (Network-Aware P2P-TV Application over Wise Networks, 479 http://www.napa-wine.org), a research project supported by the 480 European Commission under its 7th Framework Program (contract no. 481 214412). The views and conclusions contained herein are those of the 482 authors and should not be interpreted as necessarily representing the 483 official policies or endorsements, either expressed or implied, of 484 the NAPA-WINE project or the European Commission. 486 Authors' Addresses 488 Sebastian Kiesel 489 University of Stuttgart Computing Center 490 Allmandring 30 491 Stuttgart 70550 492 Germany 494 Email: ietf-alto@skiesel.de 495 URI: http://www.rus.uni-stuttgart.de/nks/ 497 Marco Tomsu 498 Alcatel-Lucent Bell Labs 499 Lorenzstrasse 10 500 Stuttgart 70435 501 Germany 503 Email: marco.tomsu@alcatel-lucent.com 504 URI: www.alcatel-lucent.com/bell-labs 506 Nico Schwan 507 Alcatel-Lucent Bell Labs 508 Lorenzstrasse 10 509 Stuttgart 70435 510 Germany 512 Email: nico.schwan@alcatel-lucent.com 513 URI: www.alcatel-lucent.com/bell-labs 515 Michael Scharf 516 Alcatel-Lucent Bell Labs 517 Lorenzstrasse 10 518 Stuttgart 70435 519 Germany 521 Email: michael.scharf@alcatel-lucent.com 522 URI: www.alcatel-lucent.com/bell-labs 523 Martin Stiemerling 524 NEC Laboratories Europe/University of Goettingen 525 Kurfuerstenanlage 36 526 Heidelberg 69115 527 Germany 529 Phone: +49 6221 4342 113 530 Email: martin.stiemerling@neclab.eu 531 URI: http://ietf.stiemerling.org