Internet Engineering Task Force (IETF) S. Kiesel
Request for Comments: 7286 University of Stuttgart
Category: Standards Track M. Stiemerling
ISSN: 2070-1721 NEC Europe Ltd.
N. Schwan
Thales Deutschland
M. Scharf
Alcatel-Lucent Bell Labs
H. Song
Huawei
November 2014
Internet Engineering Task Force (IETF) S. Kiesel
Request for Comments: 7286 University of Stuttgart
Category: Standards Track M. Stiemerling
ISSN: 2070-1721 NEC Europe Ltd.
N. Schwan
Thales Deutschland
M. Scharf
Alcatel-Lucent Bell Labs
H. Song
Huawei
November 2014
Application-Layer Traffic Optimization (ALTO) Server Discovery
应用层流量优化（ALTO）服务器发现
Abstract
摘要
The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers.
应用层流量优化（ALTO）的目标是为那些必须从一组能够提供所需资源的候选主机中选择一个或多个主机的应用程序提供指导。ALTO由客户机-服务器协议实现。ALTO客户端在请求指导之前，需要发现一个或多个ALTO服务器。
This document specifies a procedure for resource-consumer-initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer.
本文档指定了资源使用者启动的ALTO服务器发现过程，如果ALTO客户端嵌入到资源使用者中，则可以使用该过程。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7286.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7286.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Requirements Language . . . . . . . . . . 3
2. ALTO Server Discovery Procedure Overview . . . . . . . . . . 3
3. ALTO Server Discovery Procedure Specification . . . . . . . . 4
3.1. Step 1: Retrieving the Domain Name . . . . . . . . . . . 5
3.1.1. Step 1, Option 1: Local Configuration . . . . . . . . 5
3.1.2. Step 1, Option 2: DHCP . . . . . . . . . . . . . . . 5
3.2. Step 2: U-NAPTR Resolution . . . . . . . . . . . . . . . 6
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
4.1. Issues with Home Gateways . . . . . . . . . . . . . . . . 7
4.2. Issues with Multihoming, Mobility, and Changing IP
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Integrity of the ALTO Server's URI . . . . . . . . . . . 9
6.2. Availability of the ALTO Server Discovery Procedure . . . 11
6.3. Confidentiality of the ALTO Server's URI . . . . . . . . 11
6.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 14
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Requirements Language . . . . . . . . . . 3
2. ALTO Server Discovery Procedure Overview . . . . . . . . . . 3
3. ALTO Server Discovery Procedure Specification . . . . . . . . 4
3.1. Step 1: Retrieving the Domain Name . . . . . . . . . . . 5
3.1.1. Step 1, Option 1: Local Configuration . . . . . . . . 5
3.1.2. Step 1, Option 2: DHCP . . . . . . . . . . . . . . . 5
3.2. Step 2: U-NAPTR Resolution . . . . . . . . . . . . . . . 6
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
4.1. Issues with Home Gateways . . . . . . . . . . . . . . . . 7
4.2. Issues with Multihoming, Mobility, and Changing IP
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Integrity of the ALTO Server's URI . . . . . . . . . . . 9
6.2. Availability of the ALTO Server Discovery Procedure . . . 11
6.3. Confidentiality of the ALTO Server's URI . . . . . . . . 11
6.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 14
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource [RFC5693]. ALTO is realized by a client-server protocol; see requirement AR-1 in [RFC6708]. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers that can provide guidance to this specific client.
应用层流量优化（ALTO）的目标是为必须从一组能够提供所需资源的候选主机中选择一个或多个主机的应用程序提供指导[RFC5693]。ALTO由客户机-服务器协议实现；参见[RFC6708]中的要求AR-1。在ALTO客户端请求指导之前，它需要发现一个或多个可以向该特定客户端提供指导的ALTO服务器。
This document specifies a procedure for resource-consumer-initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer. In other words, this document meets requirement AR-32 in [RFC6708] while AR-33 is out of scope. A different approach, which tries to meet requirement AR-33, i.e., third-party ALTO server discovery, is addressed in [3PDISC].
本文档指定了资源使用者启动的ALTO服务器发现过程，如果ALTO客户端嵌入到资源使用者中，则可以使用该过程。换句话说，本文件满足[RFC6708]中的AR-32要求，而AR-33不在范围内。[3PDISC]介绍了另一种尝试满足AR-33要求的方法，即第三方ALTO服务器发现。
A more detailed discussion of various options on where to place the functional entities comprising the overall ALTO architecture can be found in [ALTO-DEPLOY].
关于构成整个ALTO体系结构的功能实体的放置位置的各种选项的更详细讨论，请参见[ALTO-DEPLOY]。
The ALTO protocol specification [RFC7285] is based on HTTP and expects the discovery procedure to yield the HTTP(S) URI of an ALTO server's Information Resource Directory (IRD). Therefore, this procedure is based on a combination of the Dynamic Host Configuration Protocol (DHCP) or local configuration and URI-enabled Naming Authority Pointer (U-NAPTR) resource records in the Domain Name System (DNS), in order to deliver such URIs.
ALTO协议规范[RFC7285]基于HTTP，并期望发现过程生成ALTO服务器信息资源目录（IRD）的HTTP（S）URI。因此，此过程基于域名系统（DNS）中的动态主机配置协议（DHCP）或本地配置和启用URI的命名机构指针（U-NAPTR）资源记录的组合，以交付此类URI。
This document makes use of the ALTO terminology defined in [RFC5693].
本文件使用了[RFC5693]中定义的ALTO术语。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The ALTO protocol specification [RFC7285] expects that the ALTO discovery procedure yields the HTTP(S) URI [RFC7230] of the ALTO server's Information Resource Directory (IRD), which gives further information about the capabilities and services provided by that ALTO server.
ALTO协议规范[RFC7285]要求ALTO发现过程生成ALTO服务器信息资源目录（IRD）的HTTP（S）URI[RFC7230]，该URI提供有关该ALTO服务器提供的功能和服务的更多信息。
On hosts with more than one interface or address family (IPv4/v6), the ALTO server discovery procedure has to be run for every interface and address family. For more details see Section 4.2.
在具有多个接口或地址系列（IPv4/v6）的主机上，必须为每个接口和地址系列运行ALTO服务器发现过程。有关更多详细信息，请参见第4.2节。
The ALTO server discovery procedure is performed in two steps:
ALTO服务器发现过程分两步执行：
1. One DNS domain name is retrieved for each combination of interface and address family, either by local configuration (e.g., manual input into a menu or configuration file) or by means of DHCP.
1. 通过本地配置（例如，手动输入菜单或配置文件）或通过DHCP，为接口和地址系列的每个组合检索一个DNS域名。
2. These DNS domain names are used for U-NAPTR lookups yielding one or more URIs. Further DNS lookups may be necessary to determine the ALTO server's IP address(es).
2. 这些DNS域名用于产生一个或多个URI的U-NAPTR查找。可能需要进一步的DNS查找来确定ALTO服务器的IP地址。
The primary means for retrieving the DNS domain name is DHCP. However, there may be situations where DHCP is not available or does not return a suitable value. Furthermore, there might be situations in which the user wishes to override the value that could be retrieved from DHCP. In these situations, local configuration may be used. Consequently, the algorithm first checks for a locally configured override, before it tries to retrieve a value from DHCP.
检索DNS域名的主要方法是DHCP。但是，可能存在DHCP不可用或未返回适当值的情况。此外，可能存在用户希望覆盖可从DHCP检索的值的情况。在这些情况下，可以使用本地配置。因此，算法首先检查本地配置的覆盖，然后再尝试从DHCP检索值。
Typically, but not necessarily, the DNS domain name is the domain name in which the client is located, i.e., a PTR lookup on the client's IP address (according to [RFC1035], Section 3.5 for IPv4 or [RFC3596], Section 2.5 for IPv6) would yield a similar name. However, due to the widespread use of Network Address Translation (NAT), trying to determine the DNS domain name through a PTR lookup on an interface's IP address is not recommended for resource consumer initiated ALTO server discovery (see also [RFC3424]).
通常，但不一定，DNS域名是客户端所在的域名，即，对客户端IP地址的PTR查找（根据[RFC1035]，第3.5节（IPv4）或[RFC3596]，第2.5节（IPv6））将产生类似的名称。但是，由于网络地址转换（NAT）的广泛使用，对于资源使用者发起的ALTO服务器发现，不建议尝试通过PTR查找接口的IP地址来确定DNS域名（另请参见[RFC3424]）。
As already outlined in Section 2, the ALTO server discovery procedure is performed for every address family on every interface the application considers for communicating with resource providers.
如第2节所述，ALTO服务器发现过程针对应用程序考虑与资源提供者通信的每个接口上的每个地址族执行。
First, the algorithm checks for a locally configured domain name, as specified in Section 3.1.1. If no such name was configured, it tries to retrieve one from DHCP, as specified in Section 3.1.2. If still no domain name could be found, the procedure has failed and terminates with an appropriate error code.
首先，算法检查本地配置的域名，如第3.1.1节所述。如果没有配置这样的名称，它将尝试从DHCP检索一个名称，如第3.1.2节所述。如果仍然找不到域名，则过程失败，并以相应的错误代码终止。
If one or more domain names were found, they will be used as U-NAPTR/ DDDS (URI-Enabled NAPTR/Dynamic Delegation Discovery Service) [RFC4848] application-unique strings for a DNS lookup, as specified in Section 3.2.
如果找到一个或多个域名，它们将用作DNS查找的U-NAPTR/DDDS（启用URI的NAPTR/动态委派发现服务）[RFC4848]应用程序唯一字符串，如第3.2节所述。
The preferred way to acquire a domain name related to an interface's point of network attachment is the use of DHCP (see Section 3.1.2). However, in some network deployment scenarios, there is no DHCP server available. Furthermore, a user may want to use an ALTO service instance provided by an entity that is not the operator of the underlying IP network. Therefore, we allow the user to specify a DNS domain name, for example, in a configuration file option. An example domain name is:
获取与接口的网络连接点相关的域名的首选方法是使用DHCP（见第3.1.2节）。但是，在某些网络部署方案中，没有可用的DHCP服务器。此外，用户可能希望使用由不是底层IP网络运营商的实体提供的ALTO服务实例。因此，我们允许用户在配置文件选项中指定DNS域名。域名示例如下：
my-alternative-alto-provider.example.org
my-alternative-alto-provider.example.org
Implementations MAY give the user the opportunity (e.g., by means of configuration file options or menu items) to specify an individual domain name for every address family on every interface. Implementations SHOULD allow the user to specify a default name that is used if no more specific name has been configured.
实现可能给用户机会（例如，通过配置文件选项或菜单项）为每个接口上的每个地址系列指定单个域名。实现应该允许用户指定默认名称，如果没有配置更具体的名称，则使用该名称。
Network operators may provide the domain name to be used for service discovery within an access network using DHCP.
网络运营商可以使用DHCP在接入网络内提供用于服务发现的域名。
RFC 5986 [RFC5986] defines DHCP IPv4 and IPv6 access network domain name options to identify a domain name that is suitable for service discovery within the access network. RFC 2132 [RFC2132] defines the DHCP IPv4 domain name option. While this option is less suitable, it still may be useful if the RFC 5986 option is not available.
RFC 5986[RFC5986]定义了DHCP IPv4和IPv6接入网络域名选项，以标识适合接入网络内服务发现的域名。RFC 2132[RFC2132]定义DHCP IPv4域名选项。虽然此选项不太合适，但如果RFC 5986选项不可用，它仍然可能有用。
For IPv6, the ALTO server discovery procedure MUST try to retrieve DHCP option 57 (OPTION_V6_ACCESS_DOMAIN). If no such option can be retrieved the procedure fails for this interface. For IPv4, the ALTO server discovery procedure MUST try to retrieve DHCP option 213 (OPTION_V4_ACCESS_DOMAIN). If no such option can be retrieved, the procedure SHOULD try to retrieve option 15 (Domain Name). If neither option can be retrieved, the procedure fails for this interface. If a result can be retrieved, it will be used as an input for the next step (U-NAPTR resolution). One example result could be:
对于IPv6，ALTO服务器发现过程必须尝试检索DHCP选项57（选项6访问域）。如果无法检索此类选项，则此接口的过程将失败。对于IPv4，ALTO服务器发现过程必须尝试检索DHCP选项213（选项4访问域）。如果无法检索此类选项，则过程应尝试检索选项15（域名）。如果两个选项都无法检索，则此接口的过程将失败。如果可以检索结果，则将其用作下一步（U-NAPTR分辨率）的输入。一个示例结果可能是：
example.net
示例.net
The first step of the ALTO server discovery procedure (see Section 3.1) retrieved one or -- in case of multiple interfaces and/ or IPv4/v6 dual-stack operation -- several domain names, which will be used as U-NAPTR/DDDS (URI-Enabled NAPTR/Dynamic Delegation Discovery Service) [RFC4848] application unique strings. An example is:
ALTO服务器发现过程的第一步（参见第3.1节）检索了一个或多个域名（如果是多个接口和/或IPv4/v6双堆栈操作），这些域名将用作U-NAPTR/DDDS（启用URI的NAPTR/动态委派发现服务）[RFC4848]应用程序唯一字符串。例如：
example.net
示例.net
In the second step, the ALTO server discovery procedure uses a U-NAPTR [RFC4848] lookup with the "ALTO" Application Service Tag and either the "http" or the "https" Application Protocol Tag to obtain one or more URIs (indicating protocol, host, and possibly path elements) for the ALTO server's Information Resource Directory. In this document, only the HTTP and HTTPS URI schemes are defined, as the ALTO protocol specification defines the access over both protocols, but no other [RFC7285]. Note that the result can be any valid HTTP(S) URI.
在第二步中，ALTO服务器发现过程使用带有“ALTO”应用程序服务标签和“http”或“https”应用程序协议标签的U-NAPTR[RFC4848]查找，以获得ALTO服务器信息资源目录的一个或多个URI（指示协议、主机和可能的路径元素）。在本文档中，仅定义了HTTP和HTTPS URI方案，因为ALTO协议规范定义了对这两个协议的访问，而没有定义其他[RFC7285]。请注意，结果可以是任何有效的HTTP（S）URI。
The following two U-NAPTR resource records can be used for mapping "example.net" to the HTTPS URIs "https://alto1.example.net/ird" and "https://alto2.example.net/ird", with the former being preferred.
以下两个U-NAPTR资源记录可用于将“example.net”映射到HTTPS URIhttps://alto1.example.net/ird“和”https://alto2.example.net/ird“，首选前者。
example.net.
例如.net。
IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://alto1.example.net/ird!" ""
IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://alto1.example.net/ird!" ""
IN NAPTR 100 20 "u" "ALTO:https"
"!.*!https://alto2.example.net/ird!" ""
IN NAPTR 100 20 "u" "ALTO:https"
"!.*!https://alto2.example.net/ird!" ""
If no ALTO-specific U-NAPTR records can be retrieved, the discovery procedure fails for this domain name (and the corresponding interface and IP protocol version). If further domain names retrieved by Step 1 are known, the discovery procedure may perform the corresponding U-NAPTR lookups immediately. However, before retrying a lookup that has failed, a client MUST wait a time period that is appropriate for the encountered error (NXDOMAIN, timeout, etc.).
如果无法检索特定于ALTO的U-NAPTR记录，则发现过程将失败，该域名（以及相应的接口和IP协议版本）。如果已知步骤1检索到的其他域名，则发现过程可立即执行相应的U-NAPTR查找。但是，在重试失败的查找之前，客户端必须等待一段适合遇到错误的时间（NXDOMAIN、超时等）。
Section 3.1.2 describes the usage of a DHCP option that provides a means for the network operator of the network in which the ALTO client is located to provide a DNS domain name. However, this assumes that this particular DHCP option is correctly passed from the DHCP server to the actual host with the ALTO client, and that the particular host understands this DHCP option. This memo assumes the client to be able to understand the proposed DHCP option; otherwise, there is no further use of the DHCP option, but the client has to use the other proposed mechanisms.
第3.1.2节描述了DHCP选项的使用，该选项为ALTO客户端所在网络的网络运营商提供了提供DNS域名的方法。但是，这假定此特定DHCP选项已通过ALTO客户端从DHCP服务器正确传递到实际主机，并且特定主机理解此DHCP选项。本备忘录假设客户能够理解提议的DHCP选项；否则，将不再使用DHCP选项，但客户端必须使用其他建议的机制。
There are well-known issues with the handling of DHCP options in home gateways. One issue is that unknown DHCP options are not passed through some home gateways, effectively eliminating the DHCP option.
家庭网关中DHCP选项的处理存在众所周知的问题。一个问题是未知的DHCP选项没有通过某些家庭网关，从而有效地消除了DHCP选项。
Another well-known issue is the use of home-gateway-specific DNS domain names that "override" the DNS domain name provided by the network operator. For instance, a host behind a home gateway may receive a DNS domain name ".local" instead of "example.net". In general, this domain name is not usable for the server discovery procedure, unless a DNS server in the home gateway resolves the corresponding NAPTR lookup correctly, e.g., by means of a DNS split horizon approach.
另一个众所周知的问题是使用家庭网关特定的DNS域名，“覆盖”网络运营商提供的DNS域名。例如，家庭网关后面的主机可能会接收DNS域名“.local”，而不是“example.net”。通常，此域名不可用于服务器发现过程，除非家庭网关中的DNS服务器正确解析相应的NAPTR查找，例如通过DNS拆分地平线方法。
If the user decides to enter only one (default) DNS domain name in the local configuration facility (see Section 3.1.1), only one set of ALTO servers will be discovered, irrespective of multihoming and mobility. Particularly in mobile scenarios, this can lead to undesirable results.
如果用户决定在本地配置设施中只输入一个（默认）DNS域名（参见第3.1.1节），则无论多宿和移动性如何，只会发现一组ALTO服务器。特别是在移动场景中，这可能会导致不良结果。
The DHCP-based discovery method can discover different sets of ALTO servers for each interface and address family (i.e., IPv4/v6). In general, if a client wishes to communicate using one of its interfaces and using a specific IP address family, it SHOULD query the ALTO server or servers that have been discovered for this specific interface and address family. How to select an interface and IP address family as well as how to compare results returned from different ALTO servers are out of the scope of this document.
基于DHCP的发现方法可以为每个接口和地址系列（即IPv4/v6）发现不同的ALTO服务器集。通常，如果客户机希望使用其某个接口和特定IP地址系列进行通信，则应查询已发现此特定接口和地址系列的ALTO服务器。如何选择接口和IP地址族以及如何比较从不同ALTO服务器返回的结果不在本文档的范围内。
A change of the IP address at an interface invalidates the result of the ALTO server discovery procedure. For instance, if the IP address assigned to a mobile host changes due to host mobility, it is required to re-run the ALTO server discovery procedure without relying on earlier gained information.
接口上IP地址的更改将使ALTO服务器发现过程的结果无效。例如，如果分配给移动主机的IP地址由于主机移动性而改变，则需要重新运行ALTO服务器发现过程，而不依赖于先前获得的信息。
There are several challenges with DNS on hosts with multiple interfaces [RFC6418], which can affect the ALTO server discovery. If the DNS resolution is performed on the wrong interface, it can return an ALTO server that could provide suboptimal or wrong guidance. Finding the best ALTO server for multi-interfaced hosts is outside the scope of this document.
在具有多个接口[RFC6418]的主机上使用DNS有几个挑战，这可能会影响ALTO服务器发现。如果DNS解析在错误的接口上执行，它可能返回一个ALTO服务器，该服务器可能会提供不理想或错误的指导。为多接口主机寻找最佳ALTO服务器超出了本文档的范围。
When using Virtual Private Network (VPN) connections, there is usually no DHCP. The user has to enter the DNS domain name in the local configuration facility. For good optimization results, a DNS domain name corresponding to the VPN concentrator, not corresponding to the user's current location, has to be entered. Similar considerations apply for Mobile IP.
当使用虚拟专用网络（VPN）连接时，通常没有DHCP。用户必须在本地配置设施中输入DNS域名。为了获得良好的优化结果，必须输入与VPN集中器相对应的DNS域名，而不是与用户的当前位置相对应的域名。类似的考虑也适用于移动IP。
IANA has registered the following U-NAPTR [RFC4848] application service tag for ALTO:
IANA已为ALTO注册了以下U-NAPTR[RFC4848]应用程序服务标签：
Application Service Tag: ALTO
应用程序服务标签：ALTO
Intended usage: see [RFC5693] or: "The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource."
预期用途：请参阅[RFC5693]或：“应用层流量优化（ALTO）的目标是为必须从一组能够提供所需资源的候选主机中选择一个或多个主机的应用程序提供指导。”
Defining Publication: The specification contained within this document
定义出版物：本文件中包含的规范
Contact information: The authors of this document
联系方式：本文件的作者
Author/Change controller: The IESG
作者/变更控制员：IESG
Interoperability considerations: No interoperability issues are known or expected. This tag is to be registered specifically for ALTO, which is a new application without any legacy deployments.
互操作性注意事项：不存在已知或预期的互操作性问题。此标记是专门为ALTO注册的，ALTO是一个没有任何遗留部署的新应用程序。
Security considerations: see Section 6 of this document.
安全注意事项：见本文件第6节。
Related publications: This document specifies a procedure for discovering an HTTP or HTTPS URI of an ALTO server. HTTP and HTTPS are specified in [RFC7230]. The HTTP(S)-based ALTO protocol is specified in [RFC7285].
相关出版物：本文档指定了查找ALTO服务器的HTTP或HTTPS URI的过程。[RFC7230]中指定了HTTP和HTTPS。[RFC7285]中规定了基于HTTP（S）的ALTO协议。
Application Protocol Tag: This document specifies how to use the application service tag "ALTO" with the application protocol tags "http" and "https", which have already been registered in the relevant IANA registry. Therefore, IANA is not requested by this document to register any new application protocol tag.
应用程序协议标签：本文档指定如何将应用程序服务标签“ALTO”与应用程序协议标签“http”和“https”一起使用，这些标签已经在相关IANA注册表中注册。因此，本文件不要求IANA注册任何新的应用程序协议标签。
A high-level discussion of security issues related to ALTO is part of the ALTO problem statement [RFC5693]. A classification of unwanted information disclosure risks, as well as specific security-related requirements can be found in the ALTO requirements document [RFC6708].
有关ALTO安全问题的高层讨论是ALTO问题声明[RFC5693]的一部分。不需要的信息披露风险分类以及特定的安全相关要求可在ALTO要求文件[RFC6708]中找到。
The remainder of this section focuses on security threats and protection mechanisms for the ALTO server discovery procedure as such. Once the ALTO server's URI has been discovered and the communication between the ALTO client and the ALTO server starts, the security threats and protection mechanisms discussed in the ALTO protocol specification [RFC7285] apply.
本节的其余部分将重点介绍ALTO服务器发现过程的安全威胁和保护机制。一旦发现ALTO服务器的URI并且ALTO客户端和ALTO服务器之间的通信开始，ALTO协议规范[RFC7285]中讨论的安全威胁和保护机制将适用。
Scenario Description An attacker could compromise the ALTO server discovery procedure or infrastructure in a way that ALTO clients would discover a "wrong" ALTO server URI.
场景描述攻击者可以通过ALTO客户端发现“错误”的ALTO服务器URI的方式破坏ALTO服务器发现过程或基础结构。
Threat Discussion This is probably the most serious security concern related to ALTO server discovery. The discovered "wrong" ALTO server might not be able to give guidance to a given ALTO client at all, or it might give suboptimal or forged information. In the latter case, an attacker could try to use ALTO to affect the traffic distribution in the network or the performance of applications (see also Section 15.1. of [RFC7285]). Furthermore, a hostile ALTO server could threaten user privacy (see also Section 5.2.1, case (5a) in [RFC6708]).
威胁讨论这可能是与ALTO服务器发现相关的最严重的安全问题。发现的“错误”ALTO服务器可能根本无法为给定的ALTO客户端提供指导，或者可能提供不理想或伪造的信息。在后一种情况下，攻击者可能试图使用ALTO影响网络中的流量分布或应用程序的性能（另请参见[RFC7285]第15.1节）。此外，恶意ALTO服务器可能威胁用户隐私（另见[RFC6708]第5.2.1节案例（5a））。
However, it should also be noted that, if an attacker was able to compromise DHCP and/or DNS servers used for ALTO server discovery (see below), (s)he could also launch significantly more serious other attacks (e.g., redirecting various application protocols).
但是，还应注意，如果攻击者能够破坏用于ALTO服务器发现（见下文）的DHCP和/或DNS服务器，他还可能发起更严重的其他攻击（例如，重定向各种应用程序协议）。
Protection Strategies and Mechanisms The ALTO server discovery procedure consists of three building blocks (local configuration, DHCP, and DNS) and each of them is a possible attack vector.
ALTO服务器发现过程的保护策略和机制包括三个构建块（本地配置、DHCP和DNS），并且每个都是可能的攻击向量。
The problem of users possibly following "bad advice" that tricks them into manually configuring unsuitable ALTO servers cannot be solved by technical means and is out of the scope of this document.
用户可能遵循“错误建议”的问题无法通过技术手段解决，这会诱使他们手动配置不合适的ALTO服务器，不在本文档的范围内。
Due to the nature of the protocol, DHCP is rather prone to attacks. As already mentioned, an attacker that is able to inject forged DHCP replies into the network may do significantly more harm than only configuring a wrong ALTO server. Best current practices for safely operating DHCP should be followed.
由于协议的性质，DHCP很容易受到攻击。如前所述，能够将伪造的DHCP应答注入网络的攻击者可能比仅配置错误的ALTO服务器造成更大的危害。应遵循当前安全操作DHCP的最佳实践。
A further threat is the possible alteration of the DNS records used in U-NAPTR resolution. If an attacker was able to modify or spoof any of the DNS records used in the DDDS resolution, this URI could be replaced by a forged URI. The application of DNS security (DNSSEC) [RFC4033] provides a means to limit attacks that rely on modification of the DNS records used in U-NAPTR resolution. Security considerations specific to U-NAPTR are described in more detail in [RFC4848].
另一个威胁是U-NAPTR解析中使用的DNS记录可能发生更改。如果攻击者能够修改或欺骗DDDS解析中使用的任何DNS记录，则此URI可能会被伪造的URI替换。DNS安全性（DNSSEC）[RFC4033]的应用提供了一种方法来限制依赖于修改U-NAPTR解析中使用的DNS记录的攻击。[RFC4848]中详细描述了U-NAPTR特有的安全注意事项。
A related risk is the impersonation of the ALTO server (i.e., attacks after the correct URI has been discovered). This threat and protection strategies are discussed in Section 15.1 of [RFC7285]. Note that if Transport Layer Security (TLS) is used to protect ALTO, the server certificate will contain the host name (CN). Consequently, only the host part of the HTTPS URI will be authenticated, i.e., the result of the ALTO server discovery procedure. The U-NAPTR based mapping within the ALTO server discovery procedure needs to be secured as described above, e.g., by using DNSSEC.
一个相关的风险是模拟ALTO服务器（即，在发现正确的URI后进行攻击）。[RFC7285]第15.1节讨论了这种威胁和保护策略。请注意，如果使用传输层安全性（TLS）保护ALTO，则服务器证书将包含主机名（CN）。因此，只有HTTPS URI的主机部分将被验证，即ALTO服务器发现过程的结果。ALTO服务器发现过程中基于U-NAPTR的映射需要如上所述进行保护，例如使用DNSSEC。
In addition to active protection mechanisms, users and network operators can monitor application performance and network traffic patterns for poor performance or abnormalities. If it turns out that relying on the guidance of a specific ALTO server does not result in better-than-random outcomes, the use of the ALTO server may be discontinued (see also Section 15.2 of [RFC7285]).
除了主动保护机制外，用户和网络运营商还可以监控应用程序性能和网络流量模式，以发现性能差或异常。如果事实证明，依靠特定ALTO服务器的指导不会产生比随机结果更好的结果，则可以停止使用ALTO服务器（另请参见[RFC7285]第15.2节）。
Scenario Description An attacker could compromise the ALTO server discovery procedure or infrastructure in a way that ALTO clients would not be able to discover any ALTO server.
场景描述攻击者可能以ALTO客户端无法发现任何ALTO服务器的方式破坏ALTO服务器发现过程或基础结构。
Threat Discussion If no ALTO server can be discovered (although a suitable one exists), applications have to make their decisions without ALTO guidance. As ALTO could be temporarily unavailable for many reasons, applications must be prepared to do so. However, the resulting application performance and traffic distribution will correspond to a deployment scenario without ALTO.
威胁讨论如果无法发现ALTO服务器（尽管存在合适的服务器），应用程序必须在没有ALTO指导的情况下做出决策。由于许多原因，ALTO可能暂时不可用，因此必须准备好申请。但是，由此产生的应用程序性能和流量分布将对应于没有ALTO的部署场景。
Protection Strategies and Mechanisms Operators should follow best current practices to secure their DHCP, DNS, and ALTO (see Section 15.5 of [RFC7285]) servers against Denial-of-Service (DoS) attacks.
保护策略和机制运营商应遵循当前最佳实践，以保护其DHCP、DNS和ALTO（见[RFC7285]第15.5节）服务器免受拒绝服务（DoS）攻击。
Scenario Description An unauthorized party could invoke the ALTO server discovery procedure, or intercept discovery messages between an authorized ALTO client and the DHCP and DNS servers, in order to acquire knowledge of the ALTO server's URI.
场景描述未经授权的一方可以调用ALTO服务器发现过程，或截获授权ALTO客户端与DHCP和DNS服务器之间的发现消息，以获取ALTO服务器URI的知识。
Threat Discussion
威胁讨论
In the ALTO use cases that have been described in the ALTO problem statement [RFC5693] and/or discussed in the ALTO working group, the ALTO server's URI as such has always been considered as public information that does not need protection of confidentiality.
在ALTO问题声明[RFC5693]中描述和/或ALTO工作组中讨论的ALTO用例中，ALTO服务器的URI本身始终被视为不需要保密保护的公共信息。
Protection Strategies and Mechanisms No protection mechanisms for this scenario have been provided, as it has not been identified as a relevant threat. However, if a new use case is identified that requires this kind of protection, the suitability of this ALTO server discovery procedure as well as possible security extensions have to be re-evaluated thoroughly.
保护战略和机制没有为这种情况提供保护机制，因为它尚未被确定为相关威胁。但是，如果确定了需要此类保护的新用例，则必须彻底重新评估此ALTO服务器发现过程以及可能的安全扩展的适用性。
Scenario Description An unauthorized party could intercept discovery messages between an ALTO client and the DHCP and DNS servers, and thereby find out the fact that said ALTO client uses (or at least tries to use) the ALTO service.
场景描述未经授权的一方可以截获ALTO客户端与DHCP和DNS服务器之间的发现消息，从而查明所述ALTO客户端使用（或至少尝试使用）ALTO服务的事实。
Threat Discussion In the ALTO use cases that have been described in the ALTO problem statement [RFC5693] and/or discussed in the ALTO working group, this scenario has not been identified as a relevant threat.
ALTO用例中的威胁讨论已在ALTO问题声明[RFC5693]中描述和/或ALTO工作组中讨论，但该场景未被确定为相关威胁。
Protection Strategies and Mechanisms No protection mechanisms for this scenario have been provided, as it has not been identified as a relevant threat. However, if a new use case is identified that requires this kind of protection, the suitability of this ALTO server discovery procedure as well as possible security extensions have to be re-evaluated thoroughly.
保护战略和机制没有为这种情况提供保护机制，因为它尚未被确定为相关威胁。但是，如果确定了需要此类保护的新用例，则必须彻底重新评估此ALTO服务器发现过程以及可能的安全扩展的适用性。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997, <http://www.rfc-editor.org/info/rfc2132>.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月<http://www.rfc-editor.org/info/rfc2132>.
[RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007, <http://www.rfc-editor.org/info/rfc4848>.
[RFC4848]Daigle，L.，“使用URI和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 48482007年4月<http://www.rfc-editor.org/info/rfc4848>.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010, <http://www.rfc-editor.org/info/rfc5986>.
[RFC5986]Thomson，M.和J.Winterbottom，“发现本地位置信息服务器（LIS）”，RFC 59862010年9月<http://www.rfc-editor.org/info/rfc5986>.
[RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, September 2014, <http://www.rfc-editor.org/info/rfc7285>.
[RFC7285]Alimi，R.，Penno，R.，Yang，Y.，Kiesel，S.，Previdi，S.，Roome，W.，Shalunov，S.，和R.Woundy，“应用层流量优化（ALTO）协议”，RFC 72852014年9月<http://www.rfc-editor.org/info/rfc7285>.
[3PDISC] Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party ALTO Server Discovery (3pdisc)", Work in Progress, draft-kist-alto-3pdisc-05, January 2014.
[3PDISC]Kiesel，S.，Krause，K.和M.Stiemerling，“第三方ALTO服务器发现（3PDISC）”，正在进行的工作，草稿-kist-ALTO-3PDISC-05，2014年1月。
[ALTO-DEPLOY] Stiemerling, M., Kiesel, S., Previdi, S., and M. Scharf, "ALTO Deployment Considerations", Work in Progress, draft-ietf-alto-deployments-10, July 2014.
[ALTO-DEPLOY]Stiemerling，M.，Kiesel，S.，Previdi，S.，和M.Scharf，“ALTO部署注意事项”，正在进行的工作，草案-ietf-ALTO-deployments-10，2014年7月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002, <http://www.rfc-editor.org/info/rfc3424>.
[RFC3424]Daigle，L.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月<http://www.rfc-editor.org/info/rfc3424>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003, <http://www.rfc-editor.org/info/rfc3596>.
[RFC3596]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月<http://www.rfc-editor.org/info/rfc3596>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月<http://www.rfc-editor.org/info/rfc4033>.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009, <http://www.rfc-editor.org/info/rfc5693>.
[RFC5693]Seedorf，J.和E.Burger，“应用层流量优化（ALTO）问题陈述”，RFC 56932009年10月<http://www.rfc-editor.org/info/rfc5693>.
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011, <http://www.rfc-editor.org/info/rfc6418>.
[RFC6418]Blanchet，M.和P.Seite，“多接口和供应域问题声明”，RFC 6418，2011年11月<http://www.rfc-editor.org/info/rfc6418>.
[RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", RFC 6708, September 2012, <http://www.rfc-editor.org/info/rfc6708>.
[RFC6708]Kiesel，S.，Previdi，S.，Stiemerling，M.，Woundy，R.，和Y.Yang，“应用层流量优化（ALTO）要求”，RFC 67082012年9月<http://www.rfc-editor.org/info/rfc6708>.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.和J.Reschke，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
Acknowledgments
致谢
Olafur Gudmundsson provided an excellent DNS expert review on an earlier version of this document. Thanks to Tina Tsou for an accurate security review.
Olafur Gudmundsson对本文档的早期版本进行了出色的DNS专家评审。感谢Tina Tsou提供了准确的安全审查。
Michael Scharf is supported by the German-Lab project <http://www.german-lab.de> funded by the German Federal Ministry of Education and Research (BMBF).
Michael Scharf得到了德国实验室项目的支持<http://www.german-lab.de>由德国联邦教育和研究部（BMBF）资助。
Martin Stiemerling is partially supported by the CHANGE project <http://www.change-project.eu>, a research project supported by the European Commission under its 7th Framework Program (contract no. 257422). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the CHANGE project or the European Commission.
Martin Stiemerling得到了变更项目的部分支持<http://www.change-project.eu>，这是一个由欧盟委员会根据其第七个框架计划（合同号257422）支持的研究项目。本文中包含的观点和结论是作者的观点和结论，不应被解释为代表变更项目或欧盟委员会的官方政策或认可，无论明示或暗示。
Contributors
贡献者
The initial version of this document was coauthored by Marco Tomsu.
本文件的初始版本由Marco Tomsu合著。
Hannes Tschofenig provided the initial input to the U-NAPTR solution part. Hannes and Martin Thomson provided excellent feedback and input to the server discovery.
Hannes Tschofenig为U-NAPTR解决方案部分提供了初始输入。Hannes和Martin Thomson为服务器发现提供了极好的反馈和输入。
The authors would also like to thank the following persons for their contribution to this document or its predecessors: Richard Alimi, David Bryan, Roni Even, Gustavo Garcia, Jay Gu, Xingfeng Jiang, Enrico Marocco, Victor Pascual, Y. Richard Yang, Yu-Shun Wang, Yunfei Zhang, Ning Zong.
作者还要感谢以下人士对本文件或其前身的贡献：Richard Alimi、David Bryan、Roni Even、Gustavo Garcia、Jay Gu、Jiang Xingfeng、Enrico Marocco、Victor Pascual、Y.Richard Yang、于顺王、张云飞、宁宗。
Authors' Addresses
作者地址
Sebastian Kiesel University of Stuttgart Information Center Networks and Communication Systems Department Allmandring 30 Stuttgart 70550 Germany
塞巴斯蒂安KIESEL斯图加特大学信息中心网络与通信系统系ALMANDRIN 30斯图加特70550德国
EMail: ietf-alto@skiesel.de
URI: http://www.rus.uni-stuttgart.de/nks/
EMail: ietf-alto@skiesel.de
URI: http://www.rus.uni-stuttgart.de/nks/
Martin Stiemerling NEC Laboratories Europe Kurfuerstenanlage 36 Heidelberg 69115 Germany
Martin Stiemerling NEC Laboratories Europe Kurfuerstenalage 36德国海德堡69115
Phone: +49 6221 4342 113
EMail: mls.ietf@gmail.com
URI: http://ietf.stiemerling.org
Phone: +49 6221 4342 113
EMail: mls.ietf@gmail.com
URI: http://ietf.stiemerling.org
Nico Schwan Thales Deutschland Thalesplatz 1 Ditzingen 71254 Germany
Nico Schwan Thales Deutschland Thalesplatz 1 Ditzingen 71254德国
EMail: ietf@nico-schwan.de
EMail: ietf@nico-schwan.de
Michael Scharf Alcatel-Lucent Bell Labs Lorenzstrasse 10 Stuttgart 70435 Germany
Michael Scharf Alcatel-Lucent Bell实验室Lorenzstrasse 10斯图加特70435德国
EMail: michael.scharf@alcatel-lucent.com
EMail: michael.scharf@alcatel-lucent.com
Haibin Song Huawei
宋海斌
EMail: haibin.song@huawei.com
EMail: haibin.song@huawei.com