idnits 2.17.1 draft-ietf-alto-server-discovery-10.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], [RFC5693]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2013) is 3875 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) == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-17 == Outdated reference: A later version (-16) exists of draft-ietf-alto-deployments-07 == Outdated reference: A later version (-05) exists of draft-kist-alto-3pdisc-04 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 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: March 13, 2014 NEC Europe Ltd. 6 N. Schwan 7 Stuttgart, Germany 8 M. Scharf 9 Alcatel-Lucent Bell Labs 10 H. Song 11 Huawei 12 September 9, 2013 14 ALTO Server Discovery 15 draft-ietf-alto-server-discovery-10 17 Abstract 19 The goal of Application-Layer Traffic Optimization (ALTO) is to 20 provide guidance to applications that have to select one or several 21 hosts from a set of candidates capable of providing a desired 22 resource. ALTO is realized by a client-server protocol. Before an 23 ALTO client can ask for guidance it needs to discover one or more 24 ALTO servers. 26 This document specifies a procedure for resource consumer initiated 27 ALTO server discovery, which can be used if the ALTO client is 28 embedded in the resource consumer. 30 Terminology and Requirements Language 32 This document makes use of the ALTO terminology defined in [RFC5693]. 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on March 13, 2014. 55 Copyright Notice 57 Copyright (c) 2013 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. ALTO Server Discovery Procedure Overview . . . . . . . . . . . 5 74 3. ALTO Server Discovery Procedure Specification . . . . . . . . 6 75 3.1. Step 1: Retrieving the Domain Name . . . . . . . . . . . . 6 76 3.1.1. Step 1, Option 1: Local Configuration . . . . . . . . 6 77 3.1.2. Step 1, Option 2: DHCP . . . . . . . . . . . . . . . . 6 78 3.2. Step 2: U-NAPTR Resolution . . . . . . . . . . . . . . . . 7 79 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 80 4.1. Issues with Home Gateways . . . . . . . . . . . . . . . . 9 81 4.2. Issues with Multihoming, Mobility and Changing IP 82 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 6.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 12 86 6.2. Availability of the ALTO Server Discovery Procedure . . . 13 87 6.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 14 88 6.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 14 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 91 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 92 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 17 93 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 96 1. Introduction 98 The goal of Application-Layer Traffic Optimization (ALTO) is to 99 provide guidance to applications that have to select one or several 100 hosts from a set of candidates capable of providing a desired 101 resource [RFC5693]. ALTO is realized by a client-server protocol; 102 see requirement AR-1 in [RFC6708]. Before an ALTO client can ask for 103 guidance it needs to discover one or more ALTO servers that can 104 provide guidance to this specific client. 106 This document specifies a procedure for resource consumer initiated 107 ALTO server discovery, which can be used if the ALTO client is 108 embedded in the resource consumer. In other words, this document 109 meets requirement AR-32 in [RFC6708] while AR-33 is out of scope. A 110 different approach, which tries to meet requirement AR-33, i.e., 111 third-party ALTO server discovery, is addressed in 112 [I-D.kist-alto-3pdisc]. 114 A more detailed discussion of various options on where to place the 115 functional entities comprising the overall ALTO architecture can be 116 found in [I-D.ietf-alto-deployments]. 118 The ALTO protocol specification [I-D.ietf-alto-protocol] is based on 119 HTTP and expects the discovery procedure to yield the HTTP(S) URI of 120 an ALTO server's Information Resource Directory (IRD). Therefore, 121 this procedure is based on a combination of the Dynamic Host 122 Configuration Protocol (DHCP) or local configuration and URI-enabled 123 Name Authority Pointer (U-NAPTR) resource records in the Domain Name 124 System (DNS), in order to deliver such URIs. 126 2. ALTO Server Discovery Procedure Overview 128 The ALTO protocol specification [I-D.ietf-alto-protocol] expects that 129 the ALTO discovery procedure yields the HTTP(S) URI of the ALTO 130 server's Information Resource Directory (IRD), which gives further 131 information about the capabilities and services provided by that ALTO 132 server. 134 On hosts with more than one interface or address family (IPv4/v6), 135 the ALTO server discovery procedure has to be run for every interface 136 and address family. For more details see Section 4.2. 138 The ALTO server discovery procedure is performed in two steps: 140 1. One DNS domain name is retrieved for each combination of 141 interface and address family, either by local configruation 142 (e.g., manual input into a menu or configuration file) or by 143 means of DHCP. 145 2. These DNS domain names are used for U-NAPTR lookups yielding one 146 or more URIs. Further DNS lookups may be necessary to determine 147 the ALTO server's IP address(es). 149 The primary means for retrieving the DNS domain name is DHCP. 150 However, there may be situations where DHCP is not available or does 151 not return a suitable value. Furthermore, there might be situations 152 in which the user wishes to override the value that could be 153 retrieved from DHCP. In these situations, local configuration may be 154 used. Consequently, the algorithm first checks for a locally 155 configured override, before it tries to retrieve a value from DHCP. 157 Typically, but not necessarily, the DNS domain name is the domain 158 name in which the client is located, i.e., a PTR lookup on the 159 client's IP address (according to [RFC1035], Section 3.5 for IPv4 or 160 [RFC3596], Section 2.5 for IPv6) would yield a similar name. 161 However, due to the widespread use of Network Address Translation 162 (NAT), trying to determine the DNS domain name through a PTR lookup 163 on an interface's IP address is not recommended for resource consumer 164 initiated ALTO server discovery (see also [RFC3424]). 166 3. ALTO Server Discovery Procedure Specification 168 As already outlined in Section 2 the ALTO server discovery procedure 169 is performed for every address family on every interface the 170 application considers for communicating with resource providers. 172 First, the algorithm checks for a locally configured domain name, as 173 specified in Section 3.1.1. If no such name was configured, it tries 174 to retrieve one from DHCP, as specified in Section 3.1.2. If still 175 no domain name could be found, the procedure has failed and 176 terminates with an appropriate error code. 178 If one or more domain names were found, they will be used as U-NAPTR/ 179 DDDS (URI-Enabled NAPTR/Dynamic Delegation Discovery Service) 180 [RFC4848] application unique strings for a DNS lookup, as specified 181 in Section 3.2. 183 3.1. Step 1: Retrieving the Domain Name 185 3.1.1. Step 1, Option 1: Local Configuration 187 The preferred way to acquire a domain name related to an interface's 188 point of network attachment is the usage of DHCP (see Section 3.1.2). 189 However, in some network deployment scenarios there is no DHCP server 190 available. Furthermore, a user may want to use an ALTO service 191 instance provided by an entity that is not the operator of the 192 underlying IP network. Therefore, we allow the user to specify a DNS 193 domain name, for example in a configuration file option. An example 194 domain name is: 196 my-alternative-alto-provider.example.org 198 Implementations MAY give the user the opportunity (e.g., by means of 199 configuration file options or menu items) to specify an individual 200 domain name for every address family on every interface. 201 Implementations SHOULD allow the user to specify a default name that 202 is used if no more specific name has been configured. 204 3.1.2. Step 1, Option 2: DHCP 206 Network operators may provide the domain name to be used for service 207 discovery within an access network using DHCP. 209 RFC 5986 [RFC5986] defines DHCP IPv4 and IPv6 access network domain 210 name options to identify a domain name that is suitable for service 211 discovery within the access network. RFC 2132 [RFC2132] defines the 212 DHCP IPv4 domain name option. While this option is less suitable, it 213 still may be useful if the RFC 5986 option is not available. 215 For IPv6, the ALTO server discovery procedure MUST try to retrieve 216 DHCP option 57 (OPTION_V6_ACCESS_DOMAIN). If no such option can be 217 retrieved the procedure fails for this interface. For IPv4, the ALTO 218 server discovery procedure MUST try to retrieve DHCP option 213 219 (OPTION_V4_ACCESS_DOMAIN). If no such option can be retrieved, the 220 procedure SHOULD try to retrieve option 15 (Domain Name). If neither 221 option can be retrieved the procedure fails for this interface. If a 222 result can be retrieved it will be used as an input for the next step 223 (U-NAPTR resolution). One example result could be: 225 example.net 227 3.2. Step 2: U-NAPTR Resolution 229 The first step of the ALTO server discovery procedure (see 230 Section 3.1) retrieved one or - in case of multiple interfaces and/or 231 IPv4/v6 dual stack operation - several domain names, which will be 232 used as U-NAPTR/DDDS (URI-Enabled NAPTR/Dynamic Delegation Discovery 233 Service) [RFC4848] application unique strings. An example is: 235 example.net 237 In the second step, the ALTO Server discovery procedure uses a 238 U-NAPTR [RFC4848] lookup with the "ALTO" Application Service Tag and 239 either the "http" or the "https" Application Protocol Tag to obtain 240 one or more URIs (indicating protocol, host and possibly path 241 elements) for the ALTO server's Information Resource Directory. In 242 this document, only the HTTP and HTTPS URI schemes are defined, as 243 the ALTO protocol specification defines the access over both 244 protocols, but no other [I-D.ietf-alto-protocol]. Note that the 245 result can be any valid HTTP(S) URI. 247 The following two U-NAPTR resource records can be used for mapping 248 "example.net" to the HTTPS URIs "https://alto1.example.net/ird" and 249 "https://alto2.example.net/ird", with the former being preferred. 251 example.net. 253 IN NAPTR 100 10 "u" "ALTO:https" 254 "!.*!https://alto1.example.net/ird!" "" 256 IN NAPTR 100 20 "u" "ALTO:https" 257 "!.*!https://alto2.example.net/ird!" "" 259 If no ALTO-specific U-NAPTR records can be retrieved, the discovery 260 procedure fails for this domain name (and the corresponding interface 261 and IP protocol version). If further domain names retrieved by Step 262 1 are known, the discovery procedure may perform the corresponding 263 U-NAPTR lookups immediately. However, before retrying a lookup that 264 has failed, a client MUST wait a time period that is appropriate for 265 the encountered error (NXDOMAIN, timeout, etc.). 267 4. Deployment Considerations 269 4.1. Issues with Home Gateways 271 Section 3.1.2 describes the usage of a DHCP option that provides a 272 means for the network operator of the network in which the ALTO 273 client is located to provide a DNS domain name. However, this 274 assumes that this particular DHCP option is correctly passed from the 275 DHCP server to the actual host with the ALTO client, and that the 276 particular host understands this DHCP option. This memo assumes the 277 client to be able to understand the proposed DHCP option, otherwise 278 there is no further use of the DHCP option, but the client has to use 279 the other proposed mechanisms. 281 There are well-known issues with the handling of DHCP options in home 282 gateways. One issue is that unknown DHCP options are not passed 283 through some home gateways, effectively eliminating the DHCP option. 285 Another well-known issue is the usage of home gateway specific DNS 286 domain names which "override" the DNS domain name provided by the 287 network operator. For instance, a host behind a home gateway may 288 receive a DNS domain name ".local" instead of "example.net". In 289 general, this domain name is not usable for the server discovery 290 procedure, unless a DNS server in the home gateway resolves the 291 corresponding NAPTR lookup correctly, e.g., by means of a DNS split 292 horizon approach. 294 4.2. Issues with Multihoming, Mobility and Changing IP Addresses 296 If the user decides to enter only one (default) DNS domain name in 297 the local configuration facility (see Section 3.1.1), only one set of 298 ALTO servers will be discovered, irrespectively of multihoming and 299 mobility. Particularly in mobile scenarios this can lead to 300 undesirable results. 302 The DHCP-based discovery method can discover different sets of ALTO 303 servers for each interface and address family (i.e., IPv4/v6). In 304 general, if a client wishes to communicate using one of its 305 interfaces and using a specific IP address family, it SHOULD query 306 the ALTO server(s) that have been discovered for this specific 307 interface and address family. How to select an interface and IP 308 address family, as well as how to compare results returned from 309 different ALTO servers, is out of the scope of this document. 311 A change of the IP address at an interface invalidates the result of 312 the ALTO server discovery procedure. For instance, if the IP address 313 assigned to a mobile host changes due to host mobility, it is 314 required to re-run the ALTO server discovery procedure without 315 relying on earlier gained information. 317 There are several challenges with DNS on hosts with multiple 318 interfaces [RFC6418], which can affect the ALTO server discovery. If 319 the DNS resolution is performed on the wrong interface, it can return 320 an ALTO server that could provide suboptimal or wrong guidance. 321 Finding the best ALTO server for multi-interfaced hosts is outside 322 the scope of this document. 324 When using Virtual Private Network (VPN) connections there is usually 325 no DHCP. The user has to enter the DNS domain name in the local 326 configuration facility. For good optimization results, a DNS domain 327 name corresponding to the VPN concentrator, not corresponding to the 328 user's current location, has to be entered. Similar considerations 329 apply for Mobile IP. 331 5. IANA Considerations 333 IANA is requested to register the following U-NAPTR [RFC4848] 334 application service tag for ALTO: 336 Application Service Tag: ALTO 338 Intended usage: see [RFC5693] or: "The goal of Application-Layer 339 Traffic Optimization (ALTO) is to provide guidance to applications 340 that have to select one or several hosts from a set of candidates 341 capable of providing a desired resource." 343 Defining Publication: The specification contained within this 344 document 346 Contact information: The authors of this document 348 Author/Change controller: The IESG 350 Interoperability considerations: No interoperability issues are 351 known or expected. This tag is to be registered specifically for 352 ALTO, which is a new application without any legacy deployments. 354 Security considerations: see Section 6 of this document. 356 Related publications: This document specifies a procedure for 357 discovering an HTTP or HTTPS URI of an ALTO server. HTTP is 358 specified in [RFC2616] and HTTPS is specified in [RFC2818]. The 359 HTTP(S)-based ALTO protocol is specified in 360 [I-D.ietf-alto-protocol]. 362 Application Protocol Tag: This document specifies how to use the 363 application service tag "ALTO" with the application protocol tags 364 "http" (defining publication: [RFC2616] and "https" (defining 365 publication: [RFC2818]), which have already been registered in the 366 respective IANA registry. Therefore, IANA is not requested by 367 this document to register any new application protocol tag. 369 6. Security Considerations 371 A high-level discussion of security issues related to ALTO is part of 372 the ALTO problem statement [RFC5693]. A classification of unwanted 373 information disclosure risks, as well as specific security-related 374 requirements can be found in the ALTO requirements document 375 [RFC6708]. 377 The remainder of this section focuses on security threats and 378 protection mechanisms for the ALTO server discovery procedure as 379 such. Once the ALTO server's URI has been discovered and the 380 communication between the ALTO client and the ALTO server starts, the 381 security threats and protection mechanisms discussed in the ALTO 382 protocol specification [I-D.ietf-alto-protocol] apply. 384 6.1. Integrity of the ALTO Server's URI 386 Scenario Description 387 An attacker could compromise the ALTO server discovery procedure 388 or infrastructure in a way that ALTO clients would discover a 389 "wrong" ALTO server URI. 391 Threat Discussion 392 This is probably the most serious security concern related to ALTO 393 server discovery. The discovered "wrong" ALTO server might not be 394 able to give guidance to a given ALTO client at all, or it might 395 give suboptimal or forged information. In the latter case, an 396 attacker could try to use ALTO to affect the traffic distribution 397 in the network or the performance of applications (see also 398 Section 14.1. of [I-D.ietf-alto-protocol]). Furthermore, a 399 hostile ALTO server could threaten user privacy (see also Section 400 5.2.1, case (5a) in [RFC6708]). 402 However, it should also be noted that, if an attacker was able to 403 compromise DHCP and/or DNS servers used for ALTO server discovery 404 (see below), (s)he could also launch significantly more serious 405 other attacks (e.g., redirecting various application protocols). 407 Protection Strategies and Mechanisms 408 The ALTO server discovery procedure consists of three building 409 blocks (local configuration, DHCP, and DNS) and each of them is a 410 possible attack vector. 412 The problem of users possibly following "bad advice" that tricks 413 them into manually configuring unsuitable ALTO servers cannot be 414 solved by technical means and is out of the scope of this 415 document. 417 Due to the nature of the protocol, DHCP is rather prone to 418 attacks. As already mentioned, an attacker that is able to inject 419 forged DHCP replies into the network may do significantly more 420 harm than only configuring a wrong ALTO server. Best current 421 practices for safely operating DHCP should be followed. 423 A further threat is the possible alteration of the DNS records 424 used in U-NAPTR resolution. If an attacker was able to modify or 425 spoof any of the DNS records used in the DDDS resolution, this URI 426 could be replaced by a forged URI. The application of DNS 427 security (DNSSEC) [RFC4033] provides a means to limit attacks that 428 rely on modification of the DNS records used in U-NAPTR 429 resolution. Security considerations specific to U-NAPTR are 430 described in more detail in [RFC4848]. 432 A related risk is the impersonation of the ALTO server (i.e., 433 attacks after the correct URI has been discovered). This threat 434 and protection strategies are discussed in Section 14.1 of 435 [I-D.ietf-alto-protocol]. Note that if TLS is used to protect 436 ALTO, the server certificate will contain the host name (CN). 437 Consequently, only the host part of the HTTPS URI will be 438 authenticated, i.e., the result of the ALTO server discovery 439 procedure. The U-NAPTR based mapping within the ALTO server 440 discovery procedure needs to be secured as described above, e.g., 441 by using DNSSEC. 443 In addition to active protection mechanisms, users and network 444 operators can monitor application performance and network traffic 445 patterns for poor performance or abnormalities. If it turns out 446 that relying on the guidance of a specific ALTO server does not 447 result in better-than-random results, the usage of the ALTO server 448 may be discontinued (see also Section 14.2 of 449 [I-D.ietf-alto-protocol]). 451 6.2. Availability of the ALTO Server Discovery Procedure 453 Scenario Description 454 An attacker could compromise the ALTO server discovery procedure 455 or infrastructure in a way that ALTO clients would not be able to 456 discover any ALTO server. 458 Threat Discussion 459 If no ALTO server can be discovered (although a suitable one 460 exists) applications have to make their decisions without ALTO 461 guidance. As ALTO could be temporarily unavailable for many 462 reasons, applications must be prepared to do so. However, The 463 resulting application performance and traffic distribution will 464 correspond to a deployment scenario without ALTO. 466 Protection Strategies and Mechanisms 467 Operators should follow best current practices to secure their 468 DHCP, DNS, and ALTO (see Section 14.5 of [I-D.ietf-alto-protocol]) 469 servers against Denial-of-Service (DoS) attacks. 471 6.3. Confidentiality of the ALTO Server's URI 473 Scenario Description 474 An unauthorized party could invoke the ALTO server discovery 475 procedure, or intercept discovery messages between an authorized 476 ALTO client and the DHCP and DNS servers, in order to acquire 477 knowledge of the ALTO server's URI. 479 Threat Discussion 480 In the ALTO use cases that have been described in the ALTO problem 481 statement [RFC5693] and/or discussed in the ALTO working group, 482 the ALTO server's URI as such has always been considered as public 483 information that does not need protection of confidentiality. 485 Protection Strategies and Mechanisms 486 No protection mechanisms for this scenario have been provided, as 487 it has not been identified as a relevant threat. However, if a 488 new use case is identified that requires this kind of protection, 489 the suitability of this ALTO server discovery procedure as well as 490 possible security extensions have to be re-evaluated thoroughly. 492 6.4. Privacy for ALTO Clients 494 Scenario Description 495 An unauthorized party could intercept discovery messages between 496 an ALTO client and the DHCP and DNS servers, and thereby find out 497 the fact that said ALTO client uses (or at least tries to use) the 498 ALTO service. 500 Threat Discussion 501 In the ALTO use cases that have been described in the ALTO problem 502 statement [RFC5693] and/or discussed in the ALTO working group, 503 this scenario has not been identified as a relevant threat. 505 Protection Strategies and Mechanisms 506 No protection mechanisms for this scenario have been provided, as 507 it has not been identified as a relevant threat. However, if a 508 new use case is identified that requires this kind of protection, 509 the suitability of this ALTO server discovery procedure as well as 510 possible security extensions have to be re-evaluated thoroughly. 512 7. References 514 7.1. Normative References 516 [I-D.ietf-alto-protocol] 517 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 518 draft-ietf-alto-protocol-17 (work in progress), July 2013. 520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 521 Requirement Levels", BCP 14, RFC 2119, March 1997. 523 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 524 Extensions", RFC 2132, March 1997. 526 [RFC4848] Daigle, L., "Domain-Based Application Service Location 527 Using URIs and the Dynamic Delegation Discovery Service 528 (DDDS)", RFC 4848, April 2007. 530 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 531 Location Information Server (LIS)", RFC 5986, 532 September 2010. 534 7.2. Informative References 536 [I-D.ietf-alto-deployments] 537 Stiemerling, M., Kiesel, S., Previdi, S., and M. Scharf, 538 "ALTO Deployment Considerations", 539 draft-ietf-alto-deployments-07 (work in progress), 540 July 2013. 542 [I-D.kist-alto-3pdisc] 543 Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party 544 ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-04 545 (work in progress), July 2013. 547 [RFC1035] Mockapetris, P., "Domain names - implementation and 548 specification", STD 13, RFC 1035, November 1987. 550 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 551 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 552 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 554 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 556 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 557 Self-Address Fixing (UNSAF) Across Network Address 558 Translation", RFC 3424, November 2002. 560 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 561 "DNS Extensions to Support IP Version 6", RFC 3596, 562 October 2003. 564 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 565 Rose, "DNS Security Introduction and Requirements", 566 RFC 4033, March 2005. 568 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 569 Optimization (ALTO) Problem Statement", RFC 5693, 570 October 2009. 572 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 573 Provisioning Domains Problem Statement", RFC 6418, 574 November 2011. 576 [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 577 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 578 Requirements", RFC 6708, September 2012. 580 Appendix A. Contributors 582 The initial version of this document was co-authored by Marco Tomsu. 584 Hannes Tschofenig provided the initial input to the U-NAPTR solution 585 part. Hannes and Martin Thomson provided excellent feedback and 586 input to the server discovery. 588 The authors would also like to thank the following persons for their 589 contribution to this document or its predecessors: Richard Alimi, 590 David Bryan, Roni Even, Gustavo Garcia, Jay Gu, Xingfeng Jiang, 591 Enrico Marocco, Victor Pascual, Y. Richard Yang, Yu-Shun Wang, Yunfei 592 Zhang, Ning Zong. 594 Appendix B. Acknowledgments 596 Olafur Gudmundsson provided an excellent DNS expert review on an 597 earlier version of this document. Thanks to Tina Tsou for an 598 accurate security review. 600 Michael Scharf is supported by the German-Lab project 601 (http://www.german-lab.de) funded by the German Federal Ministry of 602 Education and Research (BMBF). 604 Martin Stiemerling is partially supported by the CHANGE project 605 (http://www.change-project.eu), a research project supported by the 606 European Commission under its 7th Framework Program (contract no. 607 257422). The views and conclusions contained herein are those of the 608 authors and should not be interpreted as necessarily representing the 609 official policies or endorsements, either expressed or implied, of 610 the CHANGE project or the European Commission. 612 Authors' Addresses 614 Sebastian Kiesel 615 University of Stuttgart Information Center 616 Networks and Communication Systems Department 617 Allmandring 30 618 Stuttgart 70550 619 Germany 621 Email: ietf-alto@skiesel.de 622 URI: http://www.rus.uni-stuttgart.de/nks/ 624 Martin Stiemerling 625 NEC Laboratories Europe 626 Kurfuerstenanlage 36 627 Heidelberg 69115 628 Germany 630 Phone: +49 6221 4342 113 631 Email: mls.ietf@gmail.com 632 URI: http://ietf.stiemerling.org 634 Nico Schwan 635 Stuttgart, Germany 637 Email: ietf@nico-schwan.de 639 Michael Scharf 640 Alcatel-Lucent Bell Labs 641 Lorenzstrasse 10 642 Stuttgart 70435 643 Germany 645 Email: michael.scharf@alcatel-lucent.com 646 URI: www.alcatel-lucent.com/bell-labs 648 Haibin Song 649 Huawei 651 Email: melodysong@huawei.com