[要約] RFC 8686は、ALTOクライアントが異なるドメインのALTOサーバを発見するためのプロトコルを提供します。目的は、ALTOクライアントが最適なネットワーク経路を選択するために必要な情報を提供することです。
Internet Engineering Task Force (IETF) S. Kiesel
Request for Comments: 8686 University of Stuttgart
Category: Standards Track M. Stiemerling
ISSN: 2070-1721 H-DA
February 2020
Application-Layer Traffic Optimization (ALTO) Cross-Domain 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 that can provide suitable guidance.
アプリケーションレイヤートラフィック最適化（ALTO）の目標は、目的のリソースを提供できる候補のセットから1つまたは複数のホストを選択する必要があるアプリケーションにガイダンスを提供することです。 ALTOは、クライアントサーバープロトコルによって実現されます。 ALTOクライアントはガイダンスを要求する前に、適切なガイダンスを提供できる1つ以上のALTOサーバーを検出する必要があります。
In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be necessary to discover an ALTO server outside of the ALTO client's own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery.
一部の展開シナリオでは、特にネットワークトポロジに関する情報が複数のALTOサーバーに分割されて分散されている場合、適切なガイダンスを取得するために、ALTOクライアントの独自のネットワークドメインの外部にあるALTOサーバーを検出する必要がある場合があります。このドキュメントでは、該当するシナリオの詳細を示し、要件を項目別に示し、ALTOクロスドメインサーバー検出の手順を示します。
Technically, the procedure specified in this document takes one IP address or prefix and a U-NAPTR Service Parameter (typically, "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the "in-addr.arpa." or "ip6.arpa." trees) and returns one or more URIs of information resources related to that IP address or prefix.
技術的には、このドキュメントで指定されている手順では、パラメータとして1つのIPアドレスまたはプレフィックスとU-NAPTRサービスパラメータ（通常は「ALTO：https」）を使用します。 DNSルックアップを実行し（「in-addr.arpa。」または「ip6.arpa。」ツリーのNAPTRリソースレコードに対して）、そのIPアドレスまたはプレフィックスに関連する情報リソースの1つ以上のURIを返します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8686.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8686で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Terminology and Requirements Language
2. ALTO Cross-Domain Server Discovery Procedure: Overview
3. ALTO Cross-Domain Server Discovery Procedure: Specification
3.1. Interface
3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup
3.3. Step 2: Prepare Shortened Domain Names
3.4. Step 3: Perform DNS U-NAPTR Lookups
3.5. Error Handling
4. Using the ALTO Protocol with Cross-Domain Server Discovery
4.1. Network and Cost Map Service
4.2. Map-Filtering Service
4.3. Endpoint Property Service
4.4. Endpoint Cost Service
4.5. Summary and Further Extensions
5. Implementation, Deployment, and Operational Considerations
5.1. Considerations for ALTO Clients
5.2. Considerations for Network Operators
6. Security Considerations
6.1. Integrity of the ALTO Server's URI
6.2. Availability of the ALTO Server Discovery Procedure
6.3. Confidentiality of the ALTO Server's URI
6.4. Privacy for ALTO Clients
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Solution Approaches for Partitioned ALTO Knowledge
A.1. Classification of Solution Approaches
A.2. Discussion of Solution Approaches
A.3. The Need for Cross-Domain ALTO Server Discovery
A.4. Our Solution Approach
A.5. Relation to the ALTO Requirements
Appendix B. Requirements for Cross-Domain Server Discovery
B.1. Discovery Client Application Programming Interface
B.2. Data Storage and Authority Requirements
B.3. Cross-Domain Operations Requirements
B.4. Protocol Requirements
B.5. Further Requirements
Appendix C. ALTO and Tracker-Based Peer-to-Peer Applications
C.1. A Generic Tracker-Based Peer-to-Peer Application
C.2. Architectural Options for Placing the ALTO Client
C.3. Evaluation
C.4. Example
Acknowledgments
Authors' Addresses
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 an HTTP-based client-server protocol [RFC7285], which can be used in various scenarios [RFC7971].
アプリケーション層トラフィック最適化（ALTO）の目的は、希望するリソースを提供できる候補のセットから1つまたは複数のホストを選択する必要があるアプリケーションにガイダンスを提供することです[RFC5693]。 ALTOは、さまざまなシナリオ[RFC7971]で使用できるHTTPベースのクライアントサーバープロトコル[RFC7285]によって実現されます。
The ALTO base protocol document [RFC7285] specifies the communication between an ALTO client and one ALTO server. In principle, the client may send any ALTO query. For example, it might ask for the routing cost between any two IP addresses, or it might request network and cost maps for the whole network, which might be the worldwide Internet. It is assumed that the server can answer any query, possibly with some kind of default value if no exact data is known.
ALTO基本プロトコルドキュメント[RFC7285]は、ALTOクライアントと1つのALTOサーバー間の通信を指定しています。原則として、クライアントは任意のALTOクエリを送信できます。たとえば、任意の2つのIPアドレス間のルーティングコストを要求したり、世界規模のインターネットであるネットワーク全体のネットワークおよびコストマップを要求したりする場合があります。正確なデータがわからない場合は、サーバーが任意のクエリに応答できると想定されます。
No special provisions were made for deployment scenarios with multiple ALTO servers, with some servers having more accurate information about some parts of the network topology while others have better information about other parts of the network ("partitioned knowledge"). Various ALTO use cases have been studied in the context of such scenarios. In some cases, one cannot assume that a topologically nearby ALTO server (e.g., a server discovered with the procedure specified in [RFC7286]) will always provide useful information to the client. One such scenario is detailed in Appendix C. Several solution approaches, such as redirecting a client to a server that has more accurate information or forwarding the request to such a server on behalf of the client, have been proposed and analyzed (see Appendix A), but no solution has been specified so far.
複数のALTOサーバーを使用する展開シナリオでは特別な準備は行われませんでした。サーバーによっては、ネットワークトポロジの一部についてより正確な情報を持っているものと、ネットワークの他の部分についてのより適切な情報を持っているものがあります（「パーティション化された知識」）。このようなシナリオのコンテキストで、さまざまなALTOユースケースが調査されています。場合によっては、トポロジ的に近くにあるALTOサーバー（[RFC7286]で指定された手順で発見されたサーバーなど）が常にクライアントに有用な情報を提供するとは限りません。そのようなシナリオの1つを付録Cで詳しく説明します。より正確な情報を持つサーバーにクライアントをリダイレクトする、クライアントに代わってそのようなサーバーに要求を転送するなど、いくつかのソリューションアプローチが提案および分析されています（付録Aを参照） 、しかしこれまでのところ解決策は指定されていません。
Section 3 of this document specifies the "ALTO Cross-Domain Server Discovery Procedure" for client-side usage in these scenarios. An ALTO client that wants to send an ALTO query related to a specific IP address or prefix X may call this procedure with X as a parameter. It will use Domain Name System (DNS) lookups to find one or more ALTO servers that can provide a competent answer. The above wording "related to" was intentionally kept somewhat unspecific, as the exact semantics depends on the ALTO service to be used; see Section 4.
このドキュメントのセクション3では、これらのシナリオでクライアント側で使用するための「ALTOクロスドメインサーバー検出手順」を指定しています。特定のIPアドレスまたは接頭辞Xに関連するALTOクエリを送信したいALTOクライアントは、Xをパラメータとしてこのプロシージャを呼び出すことができます。ドメインネームシステム（DNS）ルックアップを使用して、適切な回答を提供できる1つ以上のALTOサーバーを検索します。正確なセマンティクスは使用するALTOサービスに依存するため、上記の「関連する」という表現は、意図的にやや不特定にしたものです。セクション4を参照してください。
Those who are in control of the "reverse DNS" for a given IP address or prefix (i.e., the corresponding subdomain of "in-addr.arpa." or "ip6.arpa.") -- typically an Internet Service Provider (ISP), a corporate IT department, or a university's computing center -- may add resource records to the DNS that point to one or more relevant ALTO servers. In many cases, it may be an ALTO server run by that ISP or IT department, as they naturally have good insight into routing costs from and to their networks. However, they may also refer to an ALTO server provided by someone else, e.g., their upstream ISP.
特定のIPアドレスまたはプレフィックスの「リバースDNS」を制御している人（つまり、「in-addr.arpa。」または「ip6.arpa。」の対応するサブドメイン）-通常はインターネットサービスプロバイダー（ISP） ）、企業のIT部門、または大学のコンピューティングセンター-1つ以上の関連するALTOサーバーを指すリソースレコードをDNSに追加できます。多くの場合、ISPやIT部門が実行するALTOサーバーである可能性があります。これは、ネットワークとの間のルーティングコストをよく理解しているためです。ただし、上流のISPなど、他の誰かが提供するALTOサーバーを指す場合もあります。
This document makes use of the ALTO terminology defined in RFC 5693 [RFC5693].
このドキュメントでは、RFC 5693 [RFC5693]で定義されているALTO用語を使用しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This section gives a non-normative overview of the ALTO Cross-Domain Server Discovery Procedure. The detailed specification will follow in the next section.
このセクションでは、ALTOクロスドメインサーバー検出手順の非規範的な概要を示します。詳細な仕様は次のセクションで説明します。
This procedure was inspired by "Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS" [RFC7216] and reuses parts of the basic ALTO Server Discovery Procedure [RFC7286].
この手順は、「IPアドレスとリバースDNSを使用したロケーション情報サーバー（LIS）の発見」[RFC7216]に着想を得ており、基本的なALTOサーバーの発見手順[RFC7286]の一部を再利用しています。
The basic idea is to use the Domain Name System (DNS), more specifically the "in-addr.arpa." or "ip6.arpa." trees, which are mostly used for "reverse mapping" of IP addresses to host names by means of PTR resource records. There, URI-enabled Naming Authority Pointer (U-NAPTR) resource records [RFC4848], which allow the mapping of domain names to Uniform Resource Identifiers (URIs), are installed as needed. Thereby, it is possible to store a mapping from an IP address or prefix to one or more ALTO server URIs in the DNS.
基本的な考え方は、ドメインネームシステム（DNS）、より具体的には「in-addr.arpa」を使用することです。または「ip6.arpa」。ツリーは、主にPTRリソースレコードを使用してIPアドレスをホスト名に「リバースマッピング」するために使用されます。そこでは、ドメイン名からUniform Resource Identifier（URI）へのマッピングを可能にするURI対応ネーミングオーソリティポインター（U-NAPTR）リソースレコード[RFC4848]が必要に応じてインストールされます。これにより、IPアドレスまたはプレフィックスから1つ以上のALTOサーバーのURIへのマッピングをDNSに保存できます。
The ALTO Cross-Domain Server Discovery Procedure is called with one IP address or prefix and a U-NAPTR Service Parameter [RFC4848] as parameters.
ALTO Cross-Domain Server Discovery Procedureは、1つのIPアドレスまたはプレフィックスと、U-NAPTRサービスパラメータ[RFC4848]をパラメータとして呼び出されます。
The service parameter is usually set to "ALTO:https". However, other parameter values may be used in some scenarios -- e.g., "ALTO:http" to search for a server that supports unencrypted transmission for debugging purposes, or other application protocol or service tags if applicable.
サービスパラメータは通常「ALTO：https」に設定されます。ただし、一部のシナリオでは、他のパラメーター値が使用される場合があります。たとえば、 "ALTO：http"は、デバッグ目的で暗号化されていない送信をサポートするサーバー、または該当する場合は他のアプリケーションプロトコルやサービスタグを検索します。
The procedure performs DNS lookups and returns one or more URIs of information resources related to said IP address or prefix, usually the URIs of one or more ALTO Information Resource Directories (IRDs; see Section 9 of [RFC7285]). The U-NAPTR records also provide preference values, which should be considered if more than one URI is returned.
この手順では、DNSルックアップを実行し、前述のIPアドレスまたはプレフィックスに関連する情報リソースの1つ以上のURI、通常は1つ以上のALTO情報リソースディレクトリ（IRD、[RFC7285]のセクション9を参照）のURIを返します。 U-NAPTRレコードは設定値も提供します。これは、複数のURIが返された場合に考慮する必要があります。
The discovery procedure sequentially tries two different lookup strategies. First, an ALTO-specific U-NAPTR record is searched in the "reverse tree" -- i.e., in subdomains of "in-addr.arpa." or "ip6.arpa." corresponding to the given IP address or prefix. If this lookup does not yield a usable result, the procedure tries further lookups with truncated domain names, which correspond to shorter prefix lengths. The goal is to allow deployment scenarios that require fine-grained discovery on a per-IP basis, as well as large-scale scenarios where discovery is to be enabled for a large number of IP addresses with a small number of additional DNS resource records.
検出手順では、2つの異なるルックアップ戦略を順番に試行します。最初に、ALTO固有のU-NAPTRレコードが「リバースツリー」、つまり「in-addr.arpa」のサブドメインで検索されます。または「ip6.arpa」。指定されたIPアドレスまたはプレフィックスに対応します。この検索で使用可能な結果が得られない場合、プロシージャは、プレフィックス長が短いことに対応するドメイン名の切り捨てを使用して、さらに検索を試みます。目標は、IPごとにきめの細かい検出を必要とする展開シナリオと、少数の追加のDNSリソースレコードで多数のIPアドレスに対して検出を有効にする大規模なシナリオを許可することです。
The procedure specified in this document takes two parameters, X and SP, where X is an IP address or prefix and SP is a U-NAPTR Service Parameter.
このドキュメントで指定されている手順は、XとSPの2つのパラメータを取ります。XはIPアドレスまたはプレフィックスで、SPはU-NAPTRサービスパラメータです。
The parameter X may be an IPv4 or an IPv6 address or prefix in Classless Inter-Domain Routing (CIDR) notation (see [RFC4632] for the IPv4 CIDR notation and [RFC4291] for IPv6). Consequently, the address type AT is either "IPv4" or "IPv6". In both cases, X consists of an IP address A and a prefix length L. From the definitions of IPv4 and IPv6, it follows that syntactically valid values for L are 0 <= L <= 32 when AT=IPv4 and 0 <= L <= 128 when AT=IPv6. However, not all syntactically valid values of L are actually supported by this procedure; Step 1 (see below) will check for unsupported values and report an error if necessary.
パラメータXは、クラスレスドメイン間ルーティング（CIDR）表記のIPv4またはIPv6アドレスまたはプレフィックスの場合があります（IPv4 CIDR表記については[RFC4632]を、IPv6については[RFC4291]を参照）。したがって、アドレスタイプATは「IPv4」または「IPv6」のいずれかです。どちらの場合も、XはIPアドレスAとプレフィックス長Lで構成されます。IPv4とIPv6の定義から、AT = IPv4および0 <= Lの場合、Lの構文的に有効な値は0 <= L <= 32になります。 AT = IPv6の場合は128以下。ただし、Lの構文的に有効な値のすべてが実際にこの手順でサポートされるわけではありません。ステップ1（以下を参照）は、サポートされていない値をチェックし、必要に応じてエラーを報告します。
For example, for X=198.51.100.0/24, we get AT=IPv4, A=198.51.100.0, and L=24. Similarly, for X=2001:0DB8::20/128, we get AT=IPv6, A=2001:0DB8::20, and L=128.
たとえば、X = 198.51.100.0 / 24の場合、AT = IPv4、A = 198.51.100.0、およびL = 24になります。同様に、X = 2001：0DB8 :: 20/128の場合、AT = IPv6、A = 2001：0DB8 :: 20、およびL = 128になります。
In the intended usage scenario, the procedure is normally always called with the parameter SP set to "ALTO:https". However, for general applicability and in order to support future extensions, the procedure MUST support being called with any valid U-NAPTR Service Parameter (see Section 4.5 of [RFC4848] for the syntax of U-NAPTR Service Parameters and Section 5 of the same document for information about the IANA registries).
意図した使用シナリオでは、通常、プロシージャは常にパラメータSPを "ALTO：https"に設定して呼び出されます。ただし、一般的な適用性のため、および将来の拡張をサポートするために、プロシージャは有効なU-NAPTRサービスパラメータで呼び出されることをサポートする必要があります（U-NAPTRサービスパラメータの構文および同じセクション5の[RFC4848]のセクション4.5を参照）。 IANAレジストリに関する情報のドキュメント）。
The procedure performs DNS lookups and returns one or more URIs of information resources related to that IP address or prefix, usually the URIs of one or more ALTO Information Resource Directories (IRDs; see Section 9 of [RFC7285]). For each URI, the procedure also returns order and preference values (see Section 4.1 of [RFC3403]), which should be considered if more than one URI is returned.
この手順ではDNSルックアップを実行し、そのIPアドレスまたはプレフィックスに関連する情報リソースの1つ以上のURI、通常は1つ以上のALTO情報リソースディレクトリ（IRD、[RFC7285]のセクション9を参照）のURIを返します。各URIについて、プロシージャは順序と設定値も返します（[RFC3403]のセクション4.1を参照）。複数のURIが返される場合は、これらを考慮する必要があります。
During execution of this procedure, various error conditions may occur and have to be reported to the caller; see Section 3.5.
このプロシージャの実行中に、さまざまなエラー条件が発生する可能性があり、呼び出し元に報告する必要があります。セクション3.5を参照してください。
For the remainder of the document, we use the following notation for calling the ALTO Cross-Domain Server Discovery Procedure: IRD_URIS_X = XDOMDISC(X,"ALTO:https")
このドキュメントの残りの部分では、ALTO Cross-Domain Server Discovery Procedureを呼び出すために次の表記を使用します：IRD_URIS_X = XDOMDISC（X、 "ALTO：https"）
First, the procedure checks the prefix length L for unsupported values: If AT=IPv4 (i.e., if A is an IPv4 address) and L < 8, the procedure aborts and indicates an "unsupported prefix length" error to the caller. Similarly, if AT=IPv6 and L < 32, the procedure aborts and indicates an "unsupported prefix length" error to the caller. Otherwise, the procedure continues.
最初に、プロシージャはプレフィックス長Lをチェックして、サポートされていない値がないか確認します。AT= IPv4（つまり、AがIPv4アドレスの場合）およびL <8の場合、プロシージャは中止され、「サポートされていないプレフィックス長」エラーを呼び出し元に示します。同様に、AT = IPv6およびL <32の場合、プロシージャは中止され、「サポートされていないプレフィックス長」エラーを呼び出し元に示します。それ以外の場合、手順は続行されます。
If AT=IPv4, the procedure will then produce a DNS domain name, which will be referred to as R32. This domain name is constructed according to the rules specified in Section 3.5 of [RFC1035], and it is rooted in the special domain "IN-ADDR.ARPA.".
AT = IPv4の場合、プロシージャはR32と呼ばれるDNSドメイン名を生成します。このドメイン名は、[RFC1035]のセクション3.5で指定されたルールに従って作成され、特別なドメイン「IN-ADDR.ARPA。」をルートとします。
For example, A=198.51.100.3 yields R32="3.100.51.198.IN-ADDR.ARPA.".
たとえば、A = 198.51.100.3はR32 = "3.100.51.198.IN-ADDR.ARPA。"になります。
If AT=IPv6, a domain name, which will be called R128, is constructed according to the rules specified in Section 2.5 of [RFC3596], and the special domain "IP6.ARPA." is used.
AT = IPv6の場合、R128と呼ばれるドメイン名は、[RFC3596]のセクション2.5で指定されたルールと特別なドメイン「IP6.ARPA」に従って構築されます。使用されている。
For example (note: a line break was added after the second line),
例（注：2行目の後に改行が追加されました）、
A = 2001:0DB8::20 yields
R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
1.0.0.2.IP6.ARPA."
For this step, an auxiliary function, "skip", is defined as follows: skip(str,n) will skip all characters in the string str, up to and including the n-th dot, and return the remaining part of str. For example, skip("foo.bar.baz.qux.quux.",2) will return "baz.qux.quux.".
このステップでは、補助関数 "skip"が次のように定義されています。skip（str、n）は、文字列strのn番目のドットまでのすべての文字をスキップし、strの残りの部分を返します。たとえば、skip（ "foo.bar.baz.qux.quux。"、2）は "baz.qux.quux。"を返します。
If AT=IPv4, the following additional domain names are generated from the result of the previous step:
AT = IPv4の場合、前の手順の結果から次の追加のドメイン名が生成されます。
R24=skip(R32,1),
R24 = skip（R32,1）、
R16=skip(R32,2), and
R16 = skip（R32,2）、および
R8=skip(R32,3).
R8 = skip（R32,3）。
Removing one label from a domain name (i.e., one number of the "dotted quad notation") corresponds to shortening the prefix length by 8 bits.
ドメイン名から1つのラベル（つまり、「ドット付きクワッド表記」の1つの番号）を削除することは、プレフィックス長を8ビットだけ短くすることに対応します。
For example,
例えば、
R32="3.100.51.198.IN-ADDR.ARPA." yields R24="100.51.198.IN-ADDR.ARPA." R16="51.198.IN-ADDR.ARPA." R8="198.IN-ADDR.ARPA."
R32 = "3.100.51.198.IN-ADDR.ARPA。" R24 = "100.51.198.IN-ADDR.ARPA。"を生成します。 R16 = "51.198.IN-ADDR.ARPA。" R8 = "198.IN-ADDR.ARPA。"
If AT=IPv6, the following additional domain names are generated from the result of the previous step:
AT = IPv6の場合、前の手順の結果から次の追加のドメイン名が生成されます。
R64=skip(R128,16),
R64 = skip（R128,16）、
R56=skip(R128,18),
R56 = skip（R128,18）、
R48=skip(R128,20),
R48 = skip（R128,20）、
R40=skip(R128,22), and
R40 = skip（R128,22）、および
R32=skip(R128,24).
R32 = skip（R128,24）。
Removing one label from a domain name (i.e., one hex digit) corresponds to shortening the prefix length by 4 bits.
ドメイン名から1つのラベルを削除する（つまり、1つの16進数字）ことは、プレフィックス長を4ビットだけ短くすることに対応します。
For example (note: a line break was added after the first line),
例（注：改行は最初の行の後に追加されました）、
R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0. 1.0.0.2.IP6.ARPA." yields R64 = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA." R56 = "0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA." R48 = "0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA." R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA." R32 = "8.B.D.0.1.0.0.2.IP6.ARPA."
R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0。1.0.0.2.IP6.ARPA。" R64 = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA。"が生成されます。 R56 = "0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA。" R48 = "0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA。" R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA。" R32 = "8.B.D.0.1.0.0.2.IP6.ARPA。"
The address type and the prefix length of X are matched against the first and the second column of the following table, respectively:
Xのアドレスタイプとプレフィックス長は、それぞれ次の表の1列目と2列目と照合されます。
+------------+-----------+------------+-----------------------+
| 1: Address | 2: Prefix | 3: MUST do | 4: SHOULD do further |
| Type AT | Length L | 1st lookup | lookups in that order |
+============+===========+============+=======================+
| IPv4 | 32 | R32 | R24, R16, R8 |
+------------+-----------+------------+-----------------------+
| IPv4 | 24 .. 31 | R24 | R16, R8 |
+------------+-----------+------------+-----------------------+
| IPv4 | 16 .. 23 | R16 | R8 |
+------------+-----------+------------+-----------------------+
| IPv4 | 8 .. 15 | R8 | (none) |
+------------+-----------+------------+-----------------------+
| IPv4 | 0 .. 7 | (none, abort: unsupported prefix |
| | | length) |
+------------+-----------+------------+-----------------------+
| IPv6 | 128 | R128 | R64, R56, R48, R40, |
| | | | R32 |
+------------+-----------+------------+-----------------------+
| IPv6 | 64 | R64 | R56, R48, R40, R32 |
| | (..127) | | |
+------------+-----------+------------+-----------------------+
| IPv6 | 56 .. 63 | R56 | R48, R40, R32 |
+------------+-----------+------------+-----------------------+
| IPv6 | 48 .. 55 | R48 | R40, R32 |
+------------+-----------+------------+-----------------------+
| IPv6 | 40 .. 47 | R40 | R32 |
+------------+-----------+------------+-----------------------+
| IPv6 | 32 .. 39 | R32 | (none) |
+------------+-----------+------------+-----------------------+
| IPv6 | 0 .. 31 | (none, abort: unsupported prefix |
| | | length) |
+------------+-----------+------------------------------------+
Table 1: Perform DNS U-NAPTR lookups
表1：DNS U-NAPTRルックアップを実行する
Then, the domain name given in the 3rd column and the U-NAPTR Service Parameter SP with which the procedure was called (usually "ALTO:https") MUST be used for a U-NAPTR [RFC4848] lookup, in order to obtain one or more URIs (indicating protocol, host, and possibly path elements) for the ALTO server's Information Resource Directory (IRD). If such URIs can be found, the ALTO Cross-Domain Server Discovery Procedure returns that information to the caller and terminates successfully.
次に、3番目の列に示されているドメイン名と、プロシージャの呼び出しに使用されたU-NAPTRサービスパラメータSP（通常は「ALTO：https」）を使用して、U-NAPTR [RFC4848]ルックアップに使用する必要があります。 ALTOサーバーの情報リソースディレクトリ（IRD）のURI（プロトコル、ホスト、場合によってはパス要素を示す）以上。そのようなURIが見つかると、ALTOクロスドメインサーバー検出プロシージャはその情報を呼び出し元に返し、正常に終了します。
For example, the following two U-NAPTR resource records can be used for mapping "100.51.198.IN-ADDR.ARPA." (i.e., R24 from the example in the previous step) to the HTTPS URIs "https://alto1.example.net/ird" and "https://alto2.example.net/ird", with the former being preferred.
たとえば、次の2つのU-NAPTRリソースレコードは、「100.51.198.IN-ADDR.ARPA」のマッピングに使用できます。 （つまり、前のステップの例のR24）からHTTPS URI "https://alto1.example.net/ird"および "https://alto2.example.net/ird"に、前者が優先されます。
100.51.198.IN-ADDR.ARPA. IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://alto1.example.net/ird!" ""
100.51.198.IN-ADDR.ARPA. IN NAPTR 100 20 "u" "ALTO:https"
"!.*!https://alto2.example.net/ird!" ""
If no matching U-NAPTR records can be found, the procedure SHOULD try further lookups, using the domain names from the fourth column in the indicated order, until one lookup succeeds. If no IRD URI can be found after looking up all domain names from the 3rd and 4th columns, the procedure terminates unsuccessfully, returning an empty URI list.
一致するU-NAPTRレコードが見つからない場合、手順は、1つの検索が成功するまで、指定された順序で4番目の列のドメイン名を使用して、さらに検索を試行する必要があります（SHOULD）。 3番目と4番目の列からすべてのドメイン名を検索してもIRD URIが見つからない場合、プロシージャは正常に終了せず、空のURIリストが返されます。
The ALTO Cross-Domain Server Discovery Procedure may fail for several reasons.
ALTO Cross-Domain Server Discovery Procedureは、いくつかの理由で失敗する可能性があります。
If the procedure is called with syntactically invalid parameters or unsupported parameter values (in particular, the prefix length L; see Section 3.2), the procedure aborts, no URI list will be returned, and the error has to be reported to the caller.
構文的に無効なパラメーターまたはサポートされていないパラメーター値（特に、プレフィックス長L、セクション3.2を参照）を使用してプロシージャを呼び出すと、プロシージャは異常終了し、URIリストは返されないため、呼び出し元にエラーを報告する必要があります。
The procedure performs one or more DNS lookups in a well-defined order (corresponding to descending prefix lengths, see Section 3.4) until one produces a usable result. Each of these DNS lookups might fail to produce a usable result, due to either a normal condition (e.g., a domain name exists, but no ALTO-specific NAPTR resource records are associated with it), a permanent error (e.g., nonexistent domain name), or a temporary error (e.g., timeout). In all three cases, and as long as there are further domain names that can be looked up, the procedure SHOULD immediately try to look up the next domain name (from Column 4 in the table given in Section 3.4). Only after all domain names have been tried at least once, the procedure MAY retry those domain names that had caused temporary lookup errors.
この手順では、使用可能な結果が生成されるまで、1つ以上のDNSルックアップを明確な順序（降順のプレフィックス長に対応、セクション3.4を参照）で実行します。これらの各DNSルックアップは、通常の状態（たとえば、ドメイン名が存在するが、ALTO固有のNAPTRリソースレコードが関連付けられていない）、永続的なエラー（たとえば、存在しないドメイン名）が原因で、使用可能な結果を生成できない場合があります。 ）、または一時的なエラー（タイムアウトなど）。 3つのケースすべてで、さらに検索できるドメイン名がある限り、プロシージャはすぐに次のドメイン名（セクション3.4の表の列4から）を検索する必要があります（SHOULD）。すべてのドメイン名が少なくとも1回試行された後でのみ、プロシージャは一時的な検索エラーの原因となったドメイン名を再試行できます。
Generally speaking, ALTO provides advisory information for the optimization of applications (peer-to-peer applications, overlay networks, etc.), but applications should not rely on the availability of such information for their basic functionality (see Section 8.3.4.3 of [RFC7285]). Consequently, the speedy detection of an ALTO server, even though it may give less accurate answers than other servers, or the quick realization that there is no suitable ALTO server, is in general preferable to causing long delays by retrying failed queries. Nevertheless, if DNS queries have failed due to temporary errors, the ALTO Cross-Domain Server Discovery Procedure SHOULD inform its caller that DNS queries have failed for that reason and that retrying the discovery at a later point in time might give more accurate results.
一般的に言って、ALTOはアプリケーション（ピアツーピアアプリケーション、オーバーレイネットワークなど）の最適化に関する助言情報を提供しますが、アプリケーションは基本的な機能についてそのような情報の可用性に依存すべきではありません（[ RFC7285]）。したがって、ALTOサーバーの迅速な検出は、他のサーバーよりも正確な回答が得られない場合や、適切なALTOサーバーがないことをすばやく認識した場合でも、失敗したクエリを再試行して長い遅延を引き起こすよりも一般的には望ましい方法です。それにもかかわらず、一時的なエラーが原因でDNSクエリが失敗した場合、ALTOクロスドメインサーバー検出プロシージャは、その理由によりDNSクエリが失敗し、後で検出を再試行するとより正確な結果が得られる可能性があることを呼び出し元に通知する必要があります（SHOULD）。
Based on a modular design principle, ALTO provides several ALTO services, each consisting of a set of information resources that can be accessed using the ALTO protocol. The information resources that are available at a specific ALTO server are listed in its Information Resource Directory (IRD, see Section 9 of [RFC7285]). The ALTO protocol specification defines the following ALTO services and their corresponding information resources:
モジュール設計原理に基づいて、ALTOはいくつかのALTOサービスを提供します。各サービスは、ALTOプロトコルを使用してアクセスできる情報リソースのセットで構成されています。特定のALTOサーバーで利用可能な情報リソースは、その情報リソースディレクトリ（IRD、[RFC7285]のセクション9を参照）にリストされています。 ALTOプロトコル仕様では、次のALTOサービスとそれに対応する情報リソースが定義されています。
* Network and Cost Map Service, see Section 11.2 of [RFC7285]
* ネットワークとコストマップサービス、[RFC7285]のセクション11.2を参照
* Map-Filtering Service, see Section 11.3 of [RFC7285]
* Map-Filtering Service、[RFC7285]のセクション11.3を参照
* Endpoint Property Service, see Section 11.4 of [RFC7285]
* Endpoint Property Service、[RFC7285]のセクション11.4を参照
* Endpoint Cost Service, see Section 11.5 of [RFC7285]
* Endpoint Cost Service、[RFC7285]のセクション11.5を参照
The ALTO Cross-Domain Server Discovery Procedure is most useful in conjunction with the Endpoint Property Service and the Endpoint Cost Service. However, for the sake of completeness, possible interaction with all four services is discussed below. Extension documents may specify further information resources; however, these are out of scope of this document.
ALTO Cross-Domain Server Discovery Procedureは、Endpoint Property ServiceおよびEndpoint Cost Serviceと組み合わせて使用すると最も役立ちます。ただし、完全を期すために、4つのサービスすべてとの可能な相互作用について以下で説明します。拡張ドキュメントでは、さらに情報リソースを指定できます。ただし、これらはこのドキュメントの範囲外です。
An ALTO client may invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) for an IP address or prefix X and get a list of one or more IRD URIs, including order and preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The IRD(s) referenced by these URIs will always contain a network and a cost map, as these are mandatory information resources (see Section 11.2 of [RFC7285]). However, the cost matrix may be very sparse. If, according to the network map, PID_X is the Provider-defined Identifier (PID; see Section 5.1 of [RFC7285]) that contains the IP address or prefix X, and PID_1, PID_2, PID_3, ... are other PIDs, the cost map may look like this:
ALTOクライアントは、IPアドレスまたはプレフィックスXに対して（セクション3で指定されている）ALTOクロスドメインサーバー検出手順を呼び出し、順序と設定値を含む1つ以上のIRD URIのリストを取得できます。IRD_URIS_X = XDOMDISC（X、 「ALTO：https」）。これらのURIが参照するIRDには、必須の情報リソースであるため、常にネットワークとコストマップが含まれます（[RFC7285]のセクション11.2を参照）。ただし、コストマトリックスは非常にまばらな場合があります。ネットワークマップによると、PID_Xがプロバイダー定義の識別子（PID。[RFC7285]のセクション5.1を参照）であり、IPアドレスまたはプレフィックスXを含み、PID_1、PID_2、PID_3、...が他のPIDである場合、コストマップは次のようになります。
+-------+----------+-------+-------+-------+
| From | To PID_1 | PID_2 | PID_X | PID_3 |
+=======+==========+=======+=======+=======+
| PID_1 | | | 92 | |
+-------+----------+-------+-------+-------+
| PID_2 | | | 6 | |
+-------+----------+-------+-------+-------+
| PID_X | 46 | 3 | 1 | 19 |
+-------+----------+-------+-------+-------+
| PID_3 | | | 38 | |
+-------+----------+-------+-------+-------+
Table 2: Cost Map
表2：コストマップ
In this example, all cells outside Column X and Row X are unspecified. A cost map with this structure contains the same information as what could be retrieved using the Endpoint Cost Service, Cases 1 and 2 in Section 4.4. Accessing cells that are neither in Column X nor Row X may not yield useful results.
この例では、列Xと行Xの外側のすべてのセルが指定されていません。この構造のコストマップには、エンドポイントコストサービス、セクション4.4のケース1および2を使用して取得できる情報と同じ情報が含まれています。列Xにも行Xにもないセルにアクセスすると、有用な結果が得られない場合があります。
Trying to assemble a more densely populated cost map from several cost maps with this very sparse structure may be a nontrivial task, as different ALTO servers may use different PID definitions (i.e., network maps) and incompatible scales for the costs, in particular for the "routingcost" metric.
さまざまなALTOサーバーがさまざまなPID定義（ネットワークマップなど）と互換性のないコストのスケールを使用する可能性があるため、特に、 「ルーティングコスト」メトリック。
An ALTO client may invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) for an IP address or prefix X and get a list of one or more IRD URIs, including order and preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These IRDs may provide the optional Map-Filtering Service (see Section 11.3 of [RFC7285]). This service returns a subset of the full map, as specified by the client. As discussed in Section 4.1, a cost map may be very sparse in the envisioned deployment scenario. Therefore, depending on the filtering criteria provided by the client, this service may return results similar to the Endpoint Cost Service, or it may not return any useful result.
ALTOクライアントは、IPアドレスまたはプレフィックスXに対して（セクション3で指定されている）ALTOクロスドメインサーバー検出手順を呼び出し、順序と設定値を含む1つ以上のIRD URIのリストを取得できます。IRD_URIS_X = XDOMDISC（X、 「ALTO：https」）。これらのIRDは、オプションのマップフィルタリングサービスを提供する場合があります（[RFC7285]のセクション11.3を参照）。このサービスは、クライアントによって指定されたフルマップのサブセットを返します。セクション4.1で説明したように、想定される展開シナリオでは、コストマップが非常に疎になる場合があります。したがって、クライアントが提供するフィルタリング基準によっては、このサービスがEndpoint Cost Serviceと同様の結果を返すか、有用な結果を返さない場合があります。
If an ALTO client wants to query an Endpoint Property Service (see Section 11.4 of [RFC7285]) about an endpoint with IP address X or a group of endpoints within IP prefix X, respectively, it has to invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3): IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The result, IRD_URIS_X, is a list of one or more URIs of Information Resource Directories (IRDs, see Section 9 of [RFC7285]). Considering the order and preference values, the client has to check these IRDs for a suitable Endpoint Property Service and query it.
ALTOクライアントがIPアドレスXのエンドポイントまたはIPプレフィックスX内のエンドポイントのグループについてエンドポイントプロパティサービス（[RFC7285]のセクション11.4を参照）にクエリを実行する場合、ALTOクロスドメインサーバー検出を呼び出す必要があります。手順（セクション3で指定）：IRD_URIS_X = XDOMDISC（X、 "ALTO：https"）。結果のIRD_URIS_Xは、情報リソースディレクトリ（IRD、[RFC7285]のセクション9を参照）の1つ以上のURIのリストです。順序と設定値を考慮して、クライアントはこれらのIRDをチェックして適切なエンドポイントプロパティサービスを探し、クエリする必要があります。
If the ALTO client wants to do a similar Endpoint Property query for a different IP address or prefix "Y", the whole procedure has to be repeated, as IRD_URIS_Y = XDOMDISC(Y,"ALTO:https") may yield a different list of IRD URIs. Of course, the results of individual DNS queries may be cached as indicated by their respective time-to-live (TTL) values.
ALTOクライアントが別のIPアドレスまたは接頭辞「Y」に対して同様のエンドポイントプロパティクエリを実行する場合、IRD_URIS_Y = XDOMDISC（Y、 "ALTO：https"）が別のリストを生成する可能性があるため、手順全体を繰り返す必要があります。 IRD URI。もちろん、個々のDNSクエリの結果は、それぞれの存続時間（TTL）値で示されるようにキャッシュされます。
The optional ALTO Endpoint Cost Service (ECS; see Section 11.5 of [RFC7285]) provides information about costs between individual endpoints and also supports ranking. The ECS allows endpoints to be denoted by IP addresses or prefixes. The ECS is called with a list of one or more source IP addresses or prefixes, which we will call (S1, S2, S3, ...), and a list of one or more destination IP addresses or prefixes, called (D1, D2, D3, ...).
オプションのALTOエンドポイントコストサービス（ECS。[RFC7285]のセクション11.5を参照）は、個々のエンドポイント間のコストに関する情報を提供し、ランキングもサポートします。 ECSでは、エンドポイントをIPアドレスまたはプレフィックスで表すことができます。 ECSは、1つ以上の送信元IPアドレスまたはプレフィックスのリスト（S1、S2、S3、...）と呼ばれ、1つ以上の宛先IPアドレスまたはプレフィックスのリスト（D1、 D2、D3、...）。
This specification distinguishes several cases, regarding the number of elements in the list of source and destination addresses, respectively:
この仕様では、送信元アドレスと宛先アドレスのリスト内の要素の数に関して、それぞれいくつかのケースを区別しています。
1. Exactly one source address S1 and more than one destination addresses (D1, D2, D3, ...). In this case, the ALTO client has to invoke the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) with that single source address as a parameter: IRD_URIS_S1 = XDOMDISC(S1,"ALTO:https"). The result, IRD_URIS_S1, is a list of one or more URIs of Information Resource Directories (IRDs, see Section 9 of [RFC7285]). Considering the order and preference values, the client has to check these IRDs for a suitable Endpoint Cost Service and query it. The ECS is an optional service (see Section 11.5.1 of [RFC7285]), and therefore, it may well be that an IRD does not refer to an ECS.
1. 正確に1つの送信元アドレスS1と複数の宛先アドレス（D1、D2、D3、...）。この場合、ALTOクライアントは、その単一の送信元アドレスをパラメーターとして使用して（セクション3で指定されている）ALTOクロスドメインサーバー検出手順を呼び出す必要があります：IRD_URIS_S1 = XDOMDISC（S1、 "ALTO：https"）。結果のIRD_URIS_S1は、情報リソースディレクトリ（IRD、[RFC7285]のセクション9を参照）の1つ以上のURIのリストです。順序と設定値を考慮して、クライアントはこれらのIRDをチェックして適切なエンドポイントコストサービスを探し、それを照会する必要があります。 ECSはオプションのサービスであるため（[RFC7285]のセクション11.5.1を参照）、IRDがECSを参照していない可能性があります。
Calling the Cross-Domain Server Discovery Procedure only once with the single source address as a parameter -- as opposed to multiple calls, e.g., one for each destination address -- is not only a matter of efficiency. In the given scenario, it is advisable to send all ECS queries to the same ALTO server. This ensures that the results can be compared (e.g., for sorting candidate resource providers), even when cost metrics lack a well-defined base unit -- e.g., the "routingcost" metric.
複数の呼び出し（たとえば、宛先アドレスごとに1つ）とは対照的に、単一の送信元アドレスをパラメーターとして1回だけクロスドメインサーバー検出手順を呼び出すことは、効率の問題だけではありません。特定のシナリオでは、すべてのECSクエリを同じALTOサーバーに送信することをお勧めします。これにより、コストメトリックに明確な基本単位（「ルーティングコスト」メトリックなど）がない場合でも、結果を確実に比較できます（候補リソースプロバイダーの並べ替えなど）。
2. More than one source address (S1, S2, S3, ...) and exactly one destination address D1. In this case, the ALTO client has to invoke the ALTO Cross-Domain Server Discovery Procedure with that single destination address as a parameter: IRD_URIS_D1 = XDOMDISC(D1,"ALTO:https"). The result, IRD_URIS_D1, is a list of one or more URIs of IRDs. Considering the order and preference values, the client has to check these IRDs for a suitable ECS and query it.
2. 複数の送信元アドレス（S1、S2、S3、...）と正確に1つの宛先アドレスD1。この場合、ALTOクライアントは、その単一の宛先アドレスをパラメーターとして使用して、ALTO Cross-Domain Server Discovery Procedureを呼び出す必要があります：IRD_URIS_D1 = XDOMDISC（D1、 "ALTO：https"）。結果のIRD_URIS_D1は、IRDの1つ以上のURIのリストです。順序と設定値を考慮して、クライアントはこれらのIRDをチェックして適切なECSを探し、クエリする必要があります。
3. Exactly one source address S1 and exactly one destination address D1. The ALTO client may perform the same steps as in Case 1, as specified above. As an alternative, it may also perform the same steps as in Case 2, as specified above.
3. 正確に1つの送信元アドレスS1と1つの送信先アドレスD1。 ALTOクライアントは、上記のように、ケース1と同じ手順を実行できます。別の方法として、上記のように、ケース2と同じ手順を実行することもできます。
4. More than one source address (S1, S2, S3, ...) and more than one destination address (D1, D2, D3, ...). In this case, the ALTO client should split the list of desired queries based on source addresses and perform separately for each source address the same steps as in Case 1, as specified above. As an alternative, the ALTO client may also group the list based on destination addresses and perform separately for each destination address the same steps as in Case 2, as specified above. However, comparing results between these subqueries may be difficult, in particular if the cost metric is a relative preference without a well-defined base unit (e.g., the "routingcost" metric).
4. 複数の送信元アドレス（S1、S2、S3、...）および複数の宛先アドレス（D1、D2、D3、...）。この場合、ALTOクライアントは送信元アドレスに基づいて目的のクエリのリストを分割し、送信元アドレスごとに、上記のケース1と同じ手順で個別に実行する必要があります。別の方法として、ALTOクライアントは、宛先アドレスに基づいてリストをグループ化し、上記のようにケース2と同じ手順で宛先アドレスごとに個別に実行することもできます。ただし、これらのサブクエリ間の結果の比較は、特に、コストメトリックが明確に定義された基本単位（たとえば、「ルーティングコスト」メトリック）なしで相対的に優先される場合、難しい場合があります。
See Appendix C for a detailed example showing the interaction of a tracker-based peer-to-peer application, the ALTO Endpoint Cost Service, and the ALTO Cross-Domain Server Discovery Procedure.
トラッカーベースのピアツーピアアプリケーション、ALTOエンドポイントコストサービス、およびALTOクロスドメインサーバー検出手順の相互作用を示す詳細な例については、付録Cを参照してください。
Considering the four services defined in the ALTO base protocol specification [RFC7285], the ALTO Cross-Domain Server Discovery Procedure works best with the Endpoint Property Service (EPS) and the Endpoint Cost Service (ECS). Both the EPS and the ECS take one or more IP addresses as a parameter. The previous sections specify how the parameter for calling the ALTO Cross-Domain Server Discovery Procedure has to be derived from these IP addresses.
ALTO基本プロトコル仕様[RFC7285]で定義されている4つのサービスを考慮すると、ALTOクロスドメインサーバー検出手順は、エンドポイントプロパティサービス（EPS）およびエンドポイントコストサービス（ECS）で最適に機能します。 EPSとECSはどちらも、パラメータとして1つ以上のIPアドレスを取ります。前のセクションでは、ALTO Cross-Domain Server Discovery Procedureを呼び出すためのパラメーターをこれらのIPアドレスから取得する方法を指定しました。
In contrast, the ALTO Cross-Domain Server Discovery Procedure seems less useful if the goal is to retrieve network and cost maps that cover the whole network topology. However, the procedure may be useful if a map centered at a specific IP address is desired (i.e., a map detailing the vicinity of said IP address or a map giving costs from said IP address to all potential destinations).
対照的に、目標がネットワークトポロジ全体をカバーするネットワークおよびコストマップを取得することである場合、ALTOクロスドメインサーバー検出手順はあまり役に立たないようです。しかしながら、特定のＩＰアドレスを中心とするマップ（すなわち、前記ＩＰアドレスの近傍を詳述するマップ、または前記ＩＰアドレスからすべての潜在的な宛先へのコストを与えるマップ）が望まれる場合、手順は有用かもしれない。
The interaction between further ALTO services (and their corresponding information resources) needs to be investigated and defined once such further ALTO services are specified in an extension document.
追加のALTOサービス（および対応する情報リソース）間の相互作用は、そのような追加のALTOサービスが拡張ドキュメントで指定されたら、調査および定義する必要があります。
Resource-consumer-initiated ALTO server discovery (cf. ALTO requirement AR-32 [RFC6708]) can be seen as a special case of cross-domain ALTO server discovery. To that end, an ALTO client embedded in a resource consumer would have to perform the ALTO Cross-Domain Server Discovery Procedure with its own IP address as a parameter. However, due to the widespread deployment of Network Address Translators (NATs), additional protocols and mechanisms such as Session Traversal Utilities for NAT (STUN) [RFC5389] are usually needed to detect the client's "public" IP address before it can be used as a parameter for the discovery procedure. Note that a different approach for resource-consumer-initiated ALTO server discovery, which is based on DHCP, is specified in [RFC7286].
リソースコンシューマーが開始するALTOサーバーの検出（ALTO要件AR-32 [RFC6708]を参照）は、クロスドメインALTOサーバーの検出の特殊なケースと見なすことができます。そのため、リソースコンシューマに組み込まれたALTOクライアントは、独自のIPアドレスをパラメータとして使用して、ALTOクロスドメインサーバー検出手順を実行する必要があります。ただし、ネットワークアドレストランスレータ（NAT）が広く導入されているため、通常、NAT用セッショントラバーサルユーティリティ（STUN）[RFC5389]などの追加のプロトコルとメカニズムが、クライアントの「パブリック」IPアドレスを検出して、検出手順のパラメータ。 DHCPに基づく、リソース消費者が開始するALTOサーバーの発見のための異なるアプローチが[RFC7286]で指定されていることに注意してください。
The procedure specified in this document can discover ALTO server URIs for a given IP address or prefix. The intention is that a third party (e.g., a resource directory) that receives query messages from a resource consumer can use the source address in these messages to discover suitable ALTO servers for this specific resource consumer.
このドキュメントで指定されている手順は、特定のIPアドレスまたはプレフィックスのALTOサーバーURIを検出できます。目的は、リソースコンシューマからクエリメッセージを受信するサードパーティ（リソースディレクトリなど）がこれらのメッセージの送信元アドレスを使用して、この特定のリソースコンシューマに適したALTOサーバーを発見できるようにすることです。
However, resource consumers (as defined in Section 2 of [RFC5693]) may reside on hosts with more than one IP address -- for example, due to IPv4/v6 dual stack operation and/or multihoming. IP packets sent with different source addresses may be subject to different routing policies and path costs. In some deployment scenarios, it may even be required to ask different sets of ALTO servers for guidance. Furthermore, source addresses in IP packets may be modified en route by Network Address Translators (NATs).
ただし、リソースコンシューマー（[RFC5693]のセクション2で定義）は、たとえばIPv4 / v6デュアルスタック操作やマルチホーミングなどにより、複数のIPアドレスを持つホストに常駐する場合があります。異なる送信元アドレスで送信されたIPパケットは、異なるルーティングポリシーとパスコストの影響を受ける場合があります。一部の展開シナリオでは、ガイダンスについてALTOサーバーのさまざまなセットに要求することさえ必要になる場合があります。さらに、IPパケットのソースアドレスは、ネットワークアドレス変換（NAT）によって途中で変更される可能性があります。
If a resource consumer queries a resource directory for candidate resource providers, the locally selected (and possibly en-route-translated) source address of the query message -- as observed by the resource directory -- will become the basis for the ALTO server discovery and the subsequent optimization of the resource directory's reply. If, however, the resource consumer then selects different source addresses to contact returned resource providers, the desired better-than-random "ALTO effect" may not occur.
リソースコンシューマーがリソースディレクトリに候補リソースプロバイダーをクエリする場合、ローカルで選択された（場合によってはルート変換された）クエリメッセージの送信元アドレス（リソースディレクトリで観察される）が、ALTOサーバーの検出の基礎になります。そして、リソースディレクトリの応答のその後の最適化。ただし、リソースコンシューマーが返されたリソースプロバイダーに連絡するために別のソースアドレスを選択した場合、ランダムよりも優れた「ALTO効果」が得られないことがあります。
One solution approach for this problem is that a dual-stack or multihomed resource consumer could always use the same address for contacting the resource directory and all resource providers, thus overriding the operating system's automatic selection of source IP addresses. For example, when using the BSD socket API, one could always bind() the socket to one of the local IP addresses before trying to connect() to the resource directory or the resource providers, respectively. Another solution approach is to perform ALTO-influenced resource provider selection (and source-address selection) locally in the resource consumer, in addition to, or instead of, performing it in the resource directory. See Section 5.1.1 for a discussion of how to discover ALTO servers for local usage in the resource consumer.
この問題の解決策の1つは、デュアルスタックまたはマルチホームのリソースコンシューマーが、リソースディレクトリとすべてのリソースプロバイダーに接続するために常に同じアドレスを使用して、オペレーティングシステムによるソースIPアドレスの自動選択を上書きできることです。たとえば、BSDソケットAPIを使用する場合、リソースディレクトリまたはリソースプロバイダーにそれぞれconnect()する前に、ソケットを常にローカルIPアドレスの1つにbind()できます。別のソリューションアプローチは、ALTOの影響を受けるリソースプロバイダーの選択（およびソースアドレスの選択）を、リソースディレクトリで実行することに加えて、またはその代わりに、リソースコンシューマーでローカルに実行することです。リソースコンシューマーでローカルに使用するALTOサーバーを検出する方法については、セクション5.1.1を参照してください。
Similarly, resource consumers on mobile hosts SHOULD query the resource directory again after a change of IP address, in order to get a list of candidate resource providers that is optimized for the new IP address.
同様に、モバイルホスト上のリソースコンシューマーは、新しいIPアドレスに最適化された候補リソースプロバイダーのリストを取得するために、IPアドレスの変更後にリソースディレクトリに再度クエリを実行する必要があります（SHOULD）。
The ALTO Cross-Domain Server Discovery Procedure has been designed to enable the ALTO-based optimization of applications such as large-scale overlay networks, that span -- on the IP layer -- multiple administrative domains, possibly the whole Internet. Due to the widespread usage of Network Address Translators (NATs), it may well be that nodes of the overlay network (i.e., resource consumers or resource providers) are located behind a NAT, maybe even behind several cascaded NATs.
ALTO Cross-Domain Server Discovery Procedureは、IPレイヤーで複数の管理ドメイン、場合によってはインターネット全体にわたる、大規模なオーバーレイネットワークなどのアプリケーションのALTOベースの最適化を可能にするように設計されています。ネットワークアドレストランスレータ（NAT）が広く使用されているため、オーバーレイネットワークのノード（つまり、リソースコンシューマまたはリソースプロバイダ）がNATの背後に配置されている可能性があります。
If a resource directory is located in the public Internet (i.e., not behind a NAT) and receives a message from a resource consumer behind one or more NATs, the message's source address will be the public IP address of the outermost NAT in front of the resource consumer. The same applies if the resource directory is behind a different NAT than the resource consumer. The resource directory may call the ALTO Cross-Domain Server Discovery Procedure with the message's source address as a parameter. In effect, not the resource consumer's (private) IP address, but the public IP address of the outermost NAT in front of it, will be used as a basis for ALTO optimization. This will work fine as long as the network behind the NAT is not too big (e.g., if the NAT is in a residential gateway).
リソースディレクトリがパブリックインターネット（NATの背後ではない）にあり、1つ以上のNATの背後にあるリソースコンシューマーからメッセージを受信する場合、メッセージの送信元アドレスは、リソース消費者。リソースディレクトリがリソースコンシューマとは異なるNATの背後にある場合も同様です。リソースディレクトリは、メッセージとしてメッセージの送信元アドレスをパラメーターとして使用して、ALTO Cross-Domain Server Discovery Procedureを呼び出すことができます。実際には、リソースコンシューマの（プライベート）IPアドレスではなく、その前にある最も外側のNATのパブリックIPアドレスが、ALTO最適化の基礎として使用されます。これは、NATの背後にあるネットワークが大きすぎない限り（NATが住宅用ゲートウェイにある場合など）、問題なく機能します。
If a resource directory receives a message from a resource consumer and the message's source address is a "private" IP address [RFC1918], this may be a sign that both of them are behind the same NAT. An invocation of the ALTO Cross-Domain Server Discovery Procedure with this private address may be problematic, as this will only yield usable results if a DNS "split horizon" and DNSSEC trust anchors are configured correctly. In this situation, it may be more advisable to query an ALTO server that has been discovered using [RFC7286] or any other local configuration. The interaction between intradomain ALTO for large private domains (e.g., behind a "carrier-grade NAT") and cross-domain, Internet-wide optimization, is beyond the scope of this document.
リソースディレクトリがリソースコンシューマからメッセージを受信し、そのメッセージの送信元アドレスが「プライベート」IPアドレス[RFC1918]である場合、これは、両方が同じNATの背後にあることを示している可能性があります。このプライベートアドレスを使用したALTO Cross-Domain Server Discovery Procedureの呼び出しは、DNSの「スプリットホライズン」とDNSSECトラストアンカーが正しく構成されている場合にのみ使用可能な結果を生成するため、問題となる場合があります。この状況では、[RFC7286]またはその他のローカル構成を使用して検出されたALTOサーバーにクエリを実行することをお勧めします。大規模なプライベートドメインのイントラドメインALTO（「キャリアグレードのNAT」の背後など）とクロスドメインのインターネット全体の最適化の相互作用は、このドキュメントの範囲を超えています。
The ALTO Cross-Domain Server Discovery Procedure, as specified in Section 3, first produces a list of domain names (Steps 1 and 2) and then looks for relevant NAPTR records associated with these names, until a useful result can be found (Step 3). The number of candidate domain names on this list is a compromise between flexibility when installing NAPTR records and avoiding excess load on the DNS.
セクション3で指定されたALTOクロスドメインサーバー検出手順では、最初にドメイン名のリストを作成し（ステップ1および2）、次に、有用な結果が見つかるまで（ステップ3） ）。このリストの候補ドメイン名の数は、NAPTRレコードをインストールするときの柔軟性とDNSへの過剰な負荷を回避することの間の妥協点です。
A single invocation of the ALTO Cross-Domain Server Discovery Procedure, with an IPv6 address as a parameter, may cause up to, but no more than, six DNS lookups for NAPTR records. For IPv4, the maximum is four lookups. Should the load on the DNS infrastructure caused by these lookups become a problem, one solution approach is to populate the DNS with ALTO-specific NAPTR records. If such records can be found for individual IP addresses (possibly installed using a wildcarding mechanism in the name server) or long prefixes, the procedure will terminate successfully and not perform lookups for shorter prefix lengths, thus reducing the total number of DNS queries. Another approach for reducing the load on the DNS infrastructure is to increase the TTL for caching negative answers.
IPv6アドレスをパラメーターとして使用して、ALTOクロスドメインサーバー検出手順を1回呼び出すと、NAPTRレコードのDNSルックアップが最大6回まで発生する可能性があります。 IPv4の場合、最大は4つのルックアップです。これらのルックアップによって引き起こされるDNSインフラストラクチャの負荷が問題になる場合、解決策の1つは、DNSにALTO固有のNAPTRレコードを入力することです。個々のIPアドレス（ネームサーバーのワイルドカードメカニズムを使用してインストールされている可能性があります）または長いプレフィックスについてそのようなレコードが見つかると、プロシージャは正常に終了し、短いプレフィックス長の検索を実行しないため、DNSクエリの総数が減少します。 DNSインフラストラクチャの負荷を軽減するもう1つの方法は、否定的な回答をキャッシュするためのTTLを増やすことです。
On the other hand, the ALTO Cross-Domain Server Discovery Procedure trying to look up truncated domain names allows for efficient configuration of large-scale scenarios, where discovery is to be enabled for a large number of IP addresses with a small number of additional DNS resource records. Note that it expressly has not been a design goal of this procedure to give clients a means of understanding the IP prefix delegation structure. Furthermore, this specification does not assume or recommend that prefix delegations should preferably occur at those prefix lengths that are used in Step 2 of this procedure (see Section 3.3). A network operator that uses, for example, an IPv4 /18 prefix and wants to install the NAPTR records efficiently could either install 64 NAPTR records (one for each of the /24 prefixes contained within the /18 prefix), or they could try to team up with the owners of the other fragments of the enclosing /16 prefix, in order to run a common ALTO server to which only one NAPTR would point.
一方、ALTO Cross-Domain Server Discovery Procedureが切り捨てられたドメイン名を検索しようとすると、大規模シナリオの効率的な構成が可能になります。この場合、少数の追加DNSで多数のIPアドレスの検出が有効になります。リソースレコード。クライアントにIPプレフィックス委任構造を理解する手段を提供することは、この手順の設計目標ではないことに注意してください。さらに、この仕様では、この手順のステップ2で使用されるプレフィックス長でプレフィックス委任が発生することを想定または推奨していません（セクション3.3を参照）。たとえば、IPv4 / 18プレフィックスを使用し、NAPTRレコードを効率的にインストールするネットワークオペレーターは、64個のNAPTRレコード（/ 18プレフィックスに含まれる/ 24プレフィックスごとに1つ）をインストールするか、または1つのNAPTRだけが指す共通のALTOサーバーを実行するために、囲んでいる/ 16プレフィックスの他のフラグメントの所有者とチームを組みます。
[RFC2317], also known as BCP 20, describes a way to delegate the "reverse DNS" (i.e., subdomains of "in-addr.arpa.") for IPv4 address ranges with fewer than 256 addresses (i.e., less than a whole /24 prefix). The ALTO Cross-Domain Server Discovery Procedure is compatible with this method.
[RFC2317]はBCP 20とも呼ばれ、256未満のアドレス（つまり、全体より少ない）のIPv4アドレス範囲に対して「リバースDNS」（つまり、「in-addr.arpa。」のサブドメイン）を委任する方法を説明します/ 24プレフィックス）。 ALTO Cross-Domain Server Discovery Procedureは、この方法と互換性があります。
In some deployment scenarios -- e.g., residential Internet access -- where customers often dynamically receive a single IPv4 address (and/ or a small IPv6 address block) from a pool of addresses, ISPs typically will not delegate the "reverse DNS" to their customers. This practice makes it impossible for these customers to populate the DNS with NAPTR resource records that point to an ALTO server of their choice. Yet, the ISP may publish NAPTR resource records in the "reverse DNS" for individual addresses or larger address pools (i.e., shorter prefix lengths).
一部の導入シナリオ（住宅インターネットアクセスなど）では、顧客がアドレスのプールから単一のIPv4アドレス（または小さなIPv6アドレスブロック）を動的に受け取ることが多いため、ISPは通常、「リバースDNS」を顧客に委任しません。顧客。このプラクティスにより、これらの顧客は、選択したALTOサーバーを指すNAPTRリソースレコードをDNSに入力することができなくなります。ただし、ISPは、個々のアドレスまたはより大きなアドレスプール（つまり、より短いプレフィックス長）の「リバースDNS」でNAPTRリソースレコードを公開する場合があります。
While ALTO is by no means technologically tied to the Border Gateway Protocol (BGP), it is anticipated that BGP will be an important source of information for ALTO and that the operator of the outermost BGP-enabled router will have a strong incentive to publish a digest of their routing policies and costs through ALTO. In contrast, an individual user or an organization that has been assigned only a small address range (i.e., an IPv4 prefix with a prefix length longer than /24) will typically connect to the Internet using only a single ISP, and they might not be interested in publishing their own ALTO information. Consequently, they might wish to leave the operation of an ALTO server up to their ISP. This ISP may install NAPTR resource records, which are needed for the ALTO Cross-Domain Server Discovery Procedure, in the subdomain of "in-addr.arpa." that corresponds to the whole /24 prefix (cf. R24 in Section 3.3 of this document), even if delegations in the style of BCP 20 or no delegations at all are in use.
ALTOは決してボーダーゲートウェイプロトコル（BGP）に技術的に結び付けられているわけではありませんが、BGPはALTOの重要な情報源となり、最も外側のBGP対応ルーターのオペレーターは、 ALTOによるルーティングポリシーとコストのダイジェスト。対照的に、小さなアドレス範囲（つまり、プレフィックス長が/ 24より長いIPv4プレフィックス）のみが割り当てられている個々のユーザーまたは組織は、通常、単一のISPのみを使用してインターネットに接続します。自分のALTO情報を公開することに興味がある。したがって、ALTOサーバーの運用はISPに任せたいと考えるかもしれません。このISPは、ALTO Cross-Domain Server Discovery Procedureに必要なNAPTRリソースレコードを「in-addr.arpa」のサブドメインにインストールする場合があります。これは、BCP 20の形式の委任が使用されていたり、まったく使用されていない場合でも、/ 24プレフィックス全体に対応します（このドキュメントのセクション3.3のR24を参照）。
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 Cross-Domain 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 the underlying infrastructure in such a way that ALTO clients would discover a "wrong" ALTO server URI.
シナリオの説明攻撃者は、ALTOクライアントが「間違った」ALTOサーバーURIを発見するような方法で、ALTOサーバーの発見手順または基盤となるインフラストラクチャを危険にさらす可能性があります。
Threat Discussion The Cross-Domain ALTO Server Discovery Procedure relies on a series of DNS lookups, in order to produce one or more URIs. If an attacker were able to modify or spoof any of the DNS records, the resulting URIs could be replaced by forged URIs. 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 Case (5a) in Section 5.2.1 of [RFC6708]).
脅威に関する議論クロスドメインALTOサーバーの検出手順は、1つ以上のURIを生成するために、一連のDNSルックアップに依存しています。攻撃者がDNSレコードのいずれかを変更またはスプーフィングできた場合、結果のURIは偽造されたURIに置き換えられる可能性があります。これはおそらく、ALTOサーバーの検出に関連する最も深刻なセキュリティ上の問題です。検出された「間違った」ALTOサーバーは、特定のALTOクライアントにまったくガイダンスを提供できないか、最適ではない情報または偽造された情報を提供する可能性があります。後者の場合、攻撃者はALTOを使用して、ネットワーク内のトラフィック分散やアプリケーションのパフォーマンスに影響を与える可能性があります（[RFC7285]のセクション15.1も参照）。さらに、悪意のあるALTOサーバーがユーザーのプライバシーを脅かす可能性があります（[RFC6708]のセクション5.2.1のケース（5a）も参照）。
Protection Strategies and Mechanisms The application of DNS security (DNSSEC) [RFC4033] provides a means of detecting and averting attacks that rely on modification of the DNS records while in transit. All implementations of the Cross-Domain ALTO Server Discovery Procedure MUST support DNSSEC or be able to use such functionality provided by the underlying operating system. Network operators that publish U-NAPTR resource records to be used for the Cross-Domain ALTO Server Discovery Procedure SHOULD use DNSSEC to protect their subdomains of "in-addr.arpa." and/or "ip6.arpa.", respectively. Additional operational precautions for safely operating the DNS infrastructure are required in order to ensure that name servers do not sign forged (or otherwise "wrong") resource records. Security considerations specific to U-NAPTR are described in more detail in [RFC4848].
保護戦略とメカニズムDNSセキュリティ（DNSSEC）[RFC4033]のアプリケーションは、送信中のDNSレコードの変更に依存する攻撃を検出して回避する手段を提供します。クロスドメインALTOサーバーディスカバリプロシージャのすべての実装は、DNSSECをサポートするか、基盤となるオペレーティングシステムによって提供されるそのような機能を使用できる必要があります。クロスドメインALTOサーバー検出手順に使用されるU-NAPTRリソースレコードを公開するネットワークオペレーターは、DNSSECを使用して、「in-addr.arpa」のサブドメインを保護する必要があります（SHOULD）。および/または「ip6.arpa。」。ネームサーバーが偽造された（または「誤った」）リソースレコードに署名しないようにするには、DNSインフラストラクチャを安全に運用するための追加の運用上の予防措置が必要です。 U-NAPTRに固有のセキュリティの考慮事項は、[RFC4848]でより詳細に説明されています。
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 results, the usage of the ALTO server may be discontinued (see also Section 15.2 of [RFC7285]).
アクティブな保護メカニズムに加えて、ユーザーとネットワークオペレーターは、パフォーマンスの低下や異常がないか、アプリケーションのパフォーマンスとネットワークトラフィックのパターンを監視できます。特定のALTOサーバーのガイダンスに依存しても結果がランダムではないことが判明した場合、ALTOサーバーの使用が中止される可能性があります（[RFC7285]のセクション15.2も参照）。
Note The Cross-Domain ALTO Server Discovery Procedure finishes successfully when it has discovered one or more URIs. Once an 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サーバー検出手順は、1つ以上のURIを検出すると正常に終了します。 ALTOサーバーのURIが検出され、ALTOクライアントとALTOサーバー間の通信が開始されると、ALTOプロトコル仕様[RFC7285]で説明されているセキュリティの脅威と保護メカニズムが適用されます。
A threat related to the one considered above is the impersonation of an ALTO server after its correct URI has been discovered. This threat and protection strategies are discussed in Section 15.1 of [RFC7285]. The ALTO protocol's primary mechanism for protecting authenticity and integrity (as well as confidentiality) is the use of HTTPS-based transport -- i.e., HTTP over TLS [RFC2818]. Typically, when the URI's host component is a host name, a further DNS lookup is needed to map it to an IP address before the communication with the server can begin. This last DNS lookup (for A or AAAA resource records) does not necessarily have to be protected by DNSSEC, as the server identity checks specified in [RFC2818] are able to detect DNS spoofing or similar attacks after the connection to the (possibly wrong) host has been established. However, this validation, which is based on the server certificate, can only protect the steps that occur after the server URI has been discovered. It cannot detect attacks against the authenticity of the U-NAPTR lookups needed for the Cross-Domain ALTO Server Discovery Procedure, and therefore, these resource records have to be secured using DNSSEC.
上記で検討した脅威に関連する脅威は、正しいURIが発見された後のALTOサーバーの偽装です。この脅威と保護戦略については、[RFC7285]のセクション15.1で説明されています。真正性と完全性（および機密性）を保護するためのALTOプロトコルの主要なメカニズムは、HTTPSベースのトランスポート（つまり、HTTP over TLS [RFC2818]）の使用です。通常、URIのホストコンポーネントがホスト名である場合、サーバーとの通信を開始する前に、それをIPアドレスにマップするために、さらにDNSルックアップが必要です。 [RFC2818]で指定されたサーバーIDチェックは、（おそらく間違っている）への接続後にDNSスプーフィングまたは同様の攻撃を検出できるため、この最後のDNSルックアップ（AまたはAAAAリソースレコード用）は必ずしもDNSSECで保護する必要はありません。ホストが確立されました。ただし、サーバー証明書に基づくこの検証では、サーバーURIが検出された後に発生する手順のみを保護できます。クロスドメインALTOサーバー検出手順に必要なU-NAPTRルックアップの信頼性に対する攻撃を検出できないため、これらのリソースレコードはDNSSECを使用して保護する必要があります。
Scenario Description An attacker could compromise the Cross-Domain ALTO Server Discovery Procedure or the underlying infrastructure in such 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 DNS and ALTO servers (see Section 15.5 of [RFC7285]) against Denial-of-Service (DoS) attacks.
保護戦略とメカニズムオペレーターは、サービス拒否（DoS）攻撃からDNSおよびALTOサーバー（[RFC7285]のセクション15.5を参照）を保護するために、現在のベストプラクティスに従う必要があります。
Scenario Description An unauthorized party could invoke the Cross-Domain ALTO Server Discovery Procedure or intercept discovery messages between an authorized ALTO client and the DNS servers, in order to acquire knowledge of the ALTO server URI for a specific IP address.
シナリオの説明無許可のパーティは、特定のIPアドレスのALTOサーバーURIの情報を取得するために、クロスドメインALTOサーバーのディスカバリプロシージャを呼び出すか、許可されたALTOクライアントとDNSサーバーの間のディスカバリメッセージを傍受する可能性があります。
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 eavesdrop on the messages between an ALTO client and the DNS servers and thereby find out the fact that said ALTO client uses (or at least tries to use) the ALTO service in order to optimize traffic from/to a specific IP address.
シナリオの説明不正な当事者がALTOクライアントとDNSサーバーの間のメッセージを盗聴し、ALTOクライアントが特定の送受信トラフィックを最適化するためにALTOサービスを使用する（または少なくとも使用しようとする）ことを発見する可能性があります。 IPアドレス。
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. However, pervasive surveillance [RFC7624] and DNS privacy considerations [RFC7626] have seen significant attention in the Internet community in recent years.
脅威の議論ALTO問題ステートメント[RFC5693]で説明されているか、ALTOワーキンググループで議論されているALTOの使用例では、このシナリオは関連する脅威として識別されていません。ただし、広汎な監視[RFC7624]とDNSプライバシーの考慮事項[RFC7626]は、近年インターネットコミュニティで大きな注目を集めています。
Protection Strategies and Mechanisms DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] provide means for protecting confidentiality (and integrity) of DNS traffic between a client (stub) and its recursive name servers, including DNS queries and replies caused by the ALTO Cross-Domain Server Discovery Procedure.
保護戦略とメカニズムDNS over TLS [RFC7858]およびDNS over HTTPS [RFC8484]は、クライアント（スタブ）とその再帰的なネームサーバー間のDNSトラフィックの機密性（および整合性）を保護する手段を提供します。クロスドメインサーバーの検出手順。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https://www.rfc-editor.org/info/rfc1035>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, DOI 10.17487/RFC3403, October 2002, <https://www.rfc-editor.org/info/rfc3403>.
[RFC3403] Mealling、M。、「Dynamic Delegation Discovery System（DDDS）Part Three：The Domain Name System（DNS）Database」、RFC 3403、DOI 10.17487 / RFC3403、2002年10月、<https：//www.rfc-editor .org / info / rfc3403>。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, <https://www.rfc-editor.org/info/rfc3596>.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「IPバージョン6をサポートするDNS拡張機能」、STD 88、RFC 3596、DOI 10.17487 / RFC3596、2003年10月、<https： //www.rfc-editor.org/info/rfc3596>。
[RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007, <https://www.rfc-editor.org/info/rfc4848>.
[RFC4848] Daigle、L。、「URIと動的委任発見サービス（DDDS）を使用したドメインベースのアプリケーションサービスの場所」、RFC 4848、DOI 10.17487 / RFC4848、2007年4月、<https：//www.rfc-editor。 org / info / rfc4848>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[ALTO-ANYCAST] Kiesel, S. and R. Penno, "Application-Layer Traffic Optimization (ALTO) Anycast Address", Work in Progress, Internet-Draft, draft-kiesel-alto-ip-based-srv-disc-03, 1 July 2014, <https://tools.ietf.org/html/draft-kiesel-alto-ip-based-srv-disc-03>.
[ALTO-ANYCAST]キーゼル、S.、R。ペンノ、「アプリケーションレイヤートラフィック最適化（ALTO）エニーキャストアドレス」、作業中、インターネットドラフト、draft-kiesel-alto-ip-based-srv-disc-03 、2014年7月1日、<https://tools.ietf.org/html/draft-kiesel-alto-ip-based-srv-disc-03>。
[ALTO4ALTO] Kiesel, S., "Using ALTO for ALTO server selection", Work in Progress, Internet-Draft, draft-kiesel-alto-alto4alto-00, 5 July 2010, <https://tools.ietf.org/html/draft-kiesel-alto-alto4alto-00>.
[ALTO4ALTO]キーゼル、S。、「ALTOによるALTOサーバーの選択」、作業中、インターネットドラフト、draft-kiesel-alto-alto4alto-00、2010年7月5日、<https://tools.ietf.org/ html / draft-kiesel-alto-alto4alto-00>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、GJ、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、 <https://www.rfc-editor.org/info/rfc1918>。
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998, <https://www.rfc-editor.org/info/rfc2317>.
[RFC2317] Eidnes、H.、de Groot、G。、およびP. Vixie、「Classless IN-ADDR.ARPA delegation」、BCP 20、RFC 2317、DOI 10.17487 / RFC2317、1998年3月、<https：// www。 rfc-editor.org/info/rfc2317>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https://www.rfc-editor.org/info/rfc2818>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https： //www.rfc-editor.org/info/rfc4033>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https://www.rfc-editor.org/info/rfc4291>。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC4632] Fuller、V。およびT. Li、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、BCP 122、RFC 4632、DOI 10.17487 / RFC4632、2006年8月、<https：// www.rfc-editor.org/info/rfc4632>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<https：// www.rfc-editor.org/info/rfc5389>。
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, DOI 10.17487/RFC5693, October 2009, <https://www.rfc-editor.org/info/rfc5693>.
[RFC5693] Seedorf、J。およびE. Burger、「Application-Layer Traffic Optimization（ALTO）Problem Statement」、RFC 5693、DOI 10.17487 / RFC5693、2009年10月、<https://www.rfc-editor.org/info / rfc5693>。
[RFC6708] Kiesel, S., Ed., Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", RFC 6708, DOI 10.17487/RFC6708, September 2012, <https://www.rfc-editor.org/info/rfc6708>.
[RFC6708]キーゼル、S。、編、Previdi、S.、Stiemerling、M.、Woundy、R。、およびY. Yang、「アプリケーション層トラフィック最適化（ALTO）要件」、RFC 6708、DOI 10.17487 / RFC6708 、2012年9月、<https://www.rfc-editor.org/info/rfc6708>。
[RFC7216] Thomson, M. and R. Bellis, "Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS", RFC 7216, DOI 10.17487/RFC7216, April 2014, <https://www.rfc-editor.org/info/rfc7216>.
[RFC7216] Thomson、M。およびR. Bellis、「IPアドレスと逆引きDNSを使用したロケーション情報サーバー（LIS）の発見」、RFC 7216、DOI 10.17487 / RFC7216、2014年4月、<https：//www.rfc-editor。 org / info / rfc7216>。
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, <https://www.rfc-editor.org/info/rfc7285>.
[RFC7285]アリミ、R。、エド、ペンノ、R。、エド、ヤン、Y。、エド、キーゼル、S。、プレビディ、S。、ルーム、W。、シャルノフ、S.、R。 Woundy、「Application-Layer Traffic Optimization（ALTO）Protocol」、RFC 7285、DOI 10.17487 / RFC7285、2014年9月、<https://www.rfc-editor.org/info/rfc7285>。
[RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and H. Song, "Application-Layer Traffic Optimization (ALTO) Server Discovery", RFC 7286, DOI 10.17487/RFC7286, November 2014, <https://www.rfc-editor.org/info/rfc7286>.
[RFC7286]キーゼル、S。、スティーマーリング、M。、シュワン、N。、シャーフ、M。、およびH.ソング、「アプリケーション層トラフィック最適化（ALTO）サーバーの発見」、RFC 7286、DOI 10.17487 / RFC7286、11月2014、<https://www.rfc-editor.org/info/rfc7286>。
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, <https://www.rfc-editor.org/info/rfc7624>.
[RFC7624] Barnes、R.、Schneier、B.、Jennings、C.、Hardie、T.、Trammell、B.、Huitema、C。、およびD. Borkmann、「広範囲にわたる監視に直面した場合の機密性：脅威モデルand Problem Statement」、RFC 7624、DOI 10.17487 / RFC7624、2015年8月、<https://www.rfc-editor.org/info/rfc7624>。
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, <https://www.rfc-editor.org/info/rfc7626>.
[RFC7626] Bortzmeyer、S。、「DNSプライバシーに関する考慮事項」、RFC 7626、DOI 10.17487 / RFC7626、2015年8月、<https://www.rfc-editor.org/info/rfc7626>。
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858] Hu、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D。、およびP. Hoffman、「DNS over Transport Layer Security（TLS）の仕様」、RFC 7858、DOI 10.17487 / RFC7858、2016年5月、<https://www.rfc-editor.org/info/rfc7858>。
[RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and S. Previdi, "Application-Layer Traffic Optimization (ALTO) Deployment Considerations", RFC 7971, DOI 10.17487/RFC7971, October 2016, <https://www.rfc-editor.org/info/rfc7971>.
[RFC7971] Stiemerling、M.、Kiesel、S.、Scharf、M.、Seidel、H。、およびS. Previdi、「Application-Layer Traffic Optimization（ALTO）Deployment Considerations」、RFC 7971、DOI 10.17487 / RFC7971、10月2016、<https://www.rfc-editor.org/info/rfc7971>。
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.
[RFC8484] Hoffman、P。およびP. McManus、「HTTPS（DoH）を介したDNSクエリ」、RFC 8484、DOI 10.17487 / RFC8484、2018年10月、<https://www.rfc-editor.org/info/rfc8484> 。
The ALTO base protocol document [RFC7285] specifies the communication between an ALTO client and a single ALTO server. It is implicitly assumed that this server can answer any query, possibly with some kind of default value if no exact data is known. No special provisions were made for the case that the ALTO information originates from multiple sources, which are possibly under the control of different administrative entities (e.g., different ISPs) or that the overall ALTO information is partitioned and stored on several ALTO servers.
ALTO基本プロトコルドキュメント[RFC7285]は、ALTOクライアントと単一のALTOサーバー間の通信を指定しています。正確なデータがわからない場合は、このサーバーが任意のクエリに回答できると暗黙的に想定されています。 ALTO情報が複数のソースから発信されている可能性がある場合（特に異なるISPなどの管理エンティティ）の制御下にある場合、または全体的なALTO情報が複数のALTOサーバーに分割および格納されている場合は、特別な規定はありません。
Various protocol extensions and other solutions have been proposed to deal with multiple information sources and partitioned knowledge. They can be classified as follows:
複数の情報源と分割された知識を処理するために、さまざまなプロトコル拡張やその他のソリューションが提案されています。それらは次のように分類できます。
1. Ensure that all ALTO servers have the same knowledge.
1. すべてのALTOサーバーが同じ知識を持っていることを確認してください。
1.1 Ensure data replication and synchronization within the provisioning protocol (cf. [RFC5693], Figure 1).
1.1 プロビジョニングプロトコル内でのデータの複製と同期を確認します（[RFC5693]、図1を参照）。
1.2 Use an inter-ALTO-server data replication protocol. Possibly, the ALTO protocol itself -- maybe with some extensions -- could be used for that purpose; however, this has not been studied in detail so far.
1.2 ALTOサーバー間のデータ複製プロトコルを使用します。おそらく、ALTOプロトコル自体（おそらくいくつかの拡張機能を備えたもの）をその目的に使用できます。ただし、これはこれまでのところ詳細に検討されていません。
2. Accept that different ALTO servers (possibly operated by different organizations, e.g., ISPs) do not have the same knowledge.
2. 異なるALTOサーバー（ISPなどの異なる組織が運営している可能性がある）が同じ知識を持っていないことを受け入れます。
2.1 Allow ALTO clients to send arbitrary queries to any ALTO server (e.g., the one discovered using [RFC7286]). If this server cannot answer the query itself, it will fetch the data on behalf of the client, using the ALTO protocol or a to-be-defined inter-ALTO-server request forwarding protocol.
2.1 ALTOクライアントが任意のALTOサーバー（[RFC7286]を使用して検出されたものなど）に任意のクエリを送信できるようにします。このサーバーがクエリ自体に応答できない場合、サーバーはクライアントに代わって、ALTOプロトコルまたは将来定義されるALTOサーバー間要求転送プロトコルを使用してデータをフェッチします。
2.2 Allow ALTO clients to send arbitrary queries to any ALTO server (e.g., the one discovered using [RFC7286]). If this server cannot answer the query itself, it will redirect the client to the "right" ALTO server that has the desired information, using a small to-be-defined extension of the ALTO protocol.
2.2 ALTOクライアントが任意のALTOサーバー（[RFC7286]を使用して検出されたものなど）に任意のクエリを送信できるようにします。このサーバーがクエリ自体に応答できない場合は、ALTOプロトコルの定義済みの小さな拡張機能を使用して、目的の情報を持つ「正しい」ALTOサーバーにクライアントをリダイレクトします。
2.3 ALTO clients need to use some kind of "search engine" that indexes ALTO servers and redirects and/or gives cached results.
2.3 ALTOクライアントは、ALTOサーバーにインデックスを付け、リダイレクトしたり、キャッシュされた結果を返す、ある種の「検索エンジン」を使用する必要があります。
2.4 ALTO clients need to use a new discovery mechanism to discover the ALTO server that has the desired information and contact it directly.
2.4 ALTOクライアントは、新しい検出メカニズムを使用して、必要な情報を持つALTOサーバーを検出し、それに直接連絡する必要があります。
The provisioning or initialization protocol for ALTO servers (cf. [RFC5693], Figure 1) is currently not standardized. It was a conscious decision not to include this in the scope of the IETF ALTO working group. The reason is that there are many different kinds of information sources. This implementation-specific protocol will adapt them to the ALTO server, which offers a standardized protocol to the ALTO clients. However, adding the task of synchronization between ALTO servers to this protocol (i.e., Approach 1.1) would overload this protocol with a second functionality that requires standardization for seamless multidomain operation.
ALTOサーバーのプロビジョニングまたは初期化プロトコル（[RFC5693]、図1を参照）は現在標準化されていません。これをIETF ALTOワーキンググループの範囲に含めないことは意識的な決定でした。その理由は、さまざまな種類の情報源があるためです。この実装固有のプロトコルは、標準化されたプロトコルをALTOクライアントに提供するALTOサーバーにそれらを適合させます。ただし、ALTOサーバー間の同期タスクをこのプロトコル（つまり、アプローチ1.1）に追加すると、シームレスなマルチドメイン操作の標準化を必要とする2番目の機能でこのプロトコルが過負荷になります。
For Approaches 1.1 and 1.2, in addition to general technical feasibility and issues like overhead and caching efficiency, another aspect to consider is legal liability. Operator "A" might prefer not to publish information about nodes in, or paths between, the networks of operators "B" and "C" through A's ALTO server, even if A knew that information. This is not only a question of map size and processing load on A's ALTO server. Operator A could also face legal liability issues if that information had a bad impact on the traffic engineering between B's and C's networks or on their business models.
アプローチ1.1および1.2の場合、一般的な技術的な実現可能性と、オーバーヘッドやキャッシング効率などの問題に加えて、考慮すべきもう1つの側面は法的責任です。オペレーター「A」は、Aがその情報を知っていたとしても、AのALTOサーバーを介してオペレーター「B」と「C」のネットワーク内のノードまたはその間のパスに関する情報を公開しないことを好むかもしれません。これは、AのALTOサーバーのマップサイズと処理負荷の問題だけではありません。オペレーターAは、その情報がBとCのネットワーク間のトラフィックエンジニアリングまたはビジネスモデルに悪影響を及ぼす場合、法的責任の問題に直面する可能性もあります。
No specific actions to build a solution based on a "search engine" (Approach 2.3) are currently known, and it is unclear what could be the incentives to operate such an engine. Therefore, this approach is not considered in the remainder of this document.
「検索エンジン」（アプローチ2.3）に基づいてソリューションを構築する具体的なアクションは現在知られておらず、そのようなエンジンを操作するインセンティブが何であるかは不明です。したがって、このアプローチはこのドキュメントの残りの部分では考慮されません。
Approaches 1.1, 1.2, 2.1, and 2.2 require more than just the specification of an ALTO protocol extension or a new protocol that runs between ALTO servers. A large-scale, maybe Internet-wide, multidomain deployment would also need mechanisms by which an ALTO server could discover other ALTO servers, learn which information is available where, and ideally also who is authorized to publish information related to a given part of the network. Approach 2.4 needs the same mechanisms, except that they are used on the client side instead of the server side.
アプローチ1.1、1.2、2.1、および2.2には、ALTOプロトコル拡張またはALTOサーバー間で実行される新しいプロトコルの仕様以上のものが必要です。大規模な、おそらくインターネット全体にわたるマルチドメインの展開には、ALTOサーバーが他のALTOサーバーを検出し、どこで利用可能な情報を取得できるか、理想的には、特定の部分に関連する情報を公開する権限があるユーザーも必要です。通信網。アプローチ2.4では、サーバー側ではなくクライアント側で使用されることを除いて、同じメカニズムが必要です。
It is sometimes questioned whether there is a need for a solution that allows clients to ask arbitrary queries, even if the ALTO information is partitioned and stored on many ALTO servers. The main argument is that clients are supposed to optimize the traffic from and to themselves, and that the information needed for that is most likely stored on a "nearby" ALTO server -- i.e., the one that can be discovered using [RFC7286]. However, there are scenarios where the ALTO client is not co-located with an endpoint of the to-be-optimized data transmission. Instead, the ALTO client is located at a third party that takes part in the application signaling -- e.g., a so-called "tracker" in a peer-to-peer application. One such scenario, where it is advantageous to place the ALTO client not at an endpoint of the user data transmission, is analyzed in Appendix C.
ALTO情報が分割されて多くのALTOサーバーに格納されている場合でも、クライアントが任意のクエリを要求できるソリューションが必要かどうかが時々問われます。主な議論は、クライアントは自分自身への、そして自分自身へのトラフィックを最適化することになっているということであり、そのために必要な情報は、「RFC7286」を使用して発見できる「近くの」ALTOサーバーに保存される可能性が最も高いということです。ただし、ALTOクライアントが最適化されるデータ転送のエンドポイントと同じ場所に配置されないシナリオがあります。代わりに、ALTOクライアントは、アプリケーションのシグナリングに参加するサードパーティ（たとえば、ピアツーピアアプリケーションのいわゆる「トラッカー」）にあります。 ALTOクライアントをユーザーデータ送信のエンドポイントに配置しない方が有利なシナリオの1つは、付録Cで分析されています。
Several solution approaches for cross-domain ALTO server discovery have been evaluated, using the criteria documented in Appendix B. One of them was to use the ALTO protocol itself for the exchange of information availability [ALTO4ALTO]. However, the drawback of that approach is that a new registration administration authority would have to be established.
付録Bに記載されている基準を使用して、クロスドメインALTOサーバーの検出のためのいくつかのソリューションアプローチが評価されました。その1つは、ALTOプロトコル自体を使用して情報の可用性を交換することでした[ALTO4ALTO]。ただし、このアプローチの欠点は、新しい登録管理権限を確立する必要があることです。
This document specifies a DNS-based procedure for cross-domain ALTO server discovery, which was inspired by "Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS" [RFC7216]. The primary goal is that this procedure can be used on the client side (i.e., Approach 2.4), but together with new protocols or protocol extensions, it could also be used to implement the other solution approaches itemized above.
このドキュメントでは、「IPアドレスと逆引きDNSを使用したロケーション情報サーバー（LIS）の発見」[RFC7216]に着想を得た、クロスドメインALTOサーバーの発見のためのDNSベースの手順を説明します。主な目的は、この手順をクライアント側で使用できること（つまり、アプローチ2.4）ですが、新しいプロトコルまたはプロトコル拡張とともに、上記の項目で説明した他のソリューションアプローチを実装するためにも使用できます。
During the design phase of the overall ALTO solution, two different server discovery scenarios were identified and documented in the ALTO requirements document [RFC6708]. The first scenario, documented in Req. AR-32, can be supported using the discovery mechanisms specified in [RFC7286]. An alternative approach, based on IP anycast [ALTO-ANYCAST], has also been studied. This document, in contrast, tries to address Req. AR-33.
ALTOソリューション全体の設計段階で、2つの異なるサーバー検出シナリオが識別され、ALTO要件ドキュメント[RFC6708]に文書化されました。 Reqに記載されている最初のシナリオ。 AR-32は、[RFC7286]で指定されている検出メカニズムを使用してサポートできます。 IPエニーキャスト[ALTO-ANYCAST]に基づく代替アプローチも検討されています。これとは対照的に、このドキュメントでは、Reqを取り上げます。 AR-33。
This appendix itemizes requirements that were collected before the design phase and are reflected in the design of the ALTO Cross-Domain Server Discovery Procedure.
この付録では、設計フェーズの前に収集され、ALTO Cross-Domain Server Discovery Procedureの設計に反映された要件を項目別に示します。
The discovery client will be called through some kind of application programming interface (API), and the parameters will be an IP address and, for purposes of extensibility, a service identifier such as "ALTO". The client will return one or more URIs that offer the requested service ("ALTO") for the given IP address.
検出クライアントは、ある種のアプリケーションプログラミングインターフェイス（API）を介して呼び出され、パラメーターはIPアドレスであり、拡張性のために、 "ALTO"などのサービス識別子になります。クライアントは、指定されたIPアドレスに対して要求されたサービス（「ALTO」）を提供する1つ以上のURIを返します。
In other words, the client would be used to retrieve a mapping:
つまり、クライアントはマッピングを取得するために使用されます。
(IP address, "ALTO") -> IRD-URI(s)
where IRD-URI(s) is one or more URIs of Information Resource Directories (IRDs, see Section 9 of [RFC7285]) of ALTO servers that can give reasonable guidance to a resource consumer with the indicated IP address.
ここで、IRD-URIは、示されたIPアドレスを持つリソースコンシューマーに適切なガイダンスを提供できる、ALTOサーバーの情報リソースディレクトリ（IRD、[RFC7285]のセクション9を参照）の1つ以上のURIです。
The information for mapping IP addresses and service parameters to URIs should be stored in a -- preferably distributed -- database. It must be possible to delegate administration of parts of this database. Usually, the mapping from a specific IP address to a URI is defined by the authority that has administrative control over this IP address -- e.g., the ISP in residential access networks or the IT department in enterprise, university, or similar networks.
IPアドレスとサービスパラメータをURIにマッピングするための情報は、データベースに保存する必要があります。このデータベースの一部の管理を委任できる必要があります。通常、特定のIPアドレスからURIへのマッピングは、このIPアドレスを管理する権限を持つ機関によって定義されます。たとえば、住宅用アクセスネットワークのISPや、企業、大学、または同様のネットワークのIT部門です。
The cross-domain server discovery mechanism should be designed in such a way that it works across the public Internet and also in other IP-based networks. This, in turn, means that such mechanisms cannot rely on protocols that are not widely deployed across the Internet or protocols that require special handling within participating networks. An example is multicast, which is not generally available across the Internet.
クロスドメインサーバーの検出メカニズムは、パブリックインターネットや他のIPベースのネットワーク全体で機能するように設計する必要があります。つまり、このようなメカニズムは、インターネット全体に広く展開されていないプロトコルや、参加しているネットワーク内で特別な処理を必要とするプロトコルに依存できないということです。例はマルチキャストです。これは、インターネット経由では一般的に利用できません。
The ALTO Cross-Domain Server Discovery Protocol must support gradual deployment without a network-wide flag day. If the mechanism needs some kind of well-known "rendezvous point", reusing an existing infrastructure (such as the DNS root servers or the WHOIS database) should be preferred over establishing a new one.
ALTO Cross-Domain Server Discovery Protocolは、ネットワーク全体の旗のない段階的な展開をサポートする必要があります。メカニズムに何らかの既知の「ランデブーポイント」が必要な場合は、既存のインフラストラクチャ（DNSルートサーバーやWHOISデータベースなど）を再利用することを、新しいインフラストラクチャを確立するよりも優先する必要があります。
The protocol must be able to operate across middleboxes, especially NATs and firewalls.
プロトコルは、ミドルボックス、特にNATおよびファイアウォール全体で動作できる必要があります。
The protocol shall not require any preknowledge from the client other than any information that is known to a regular IP host on the Internet.
このプロトコルは、インターネット上の通常のIPホストに知られている情報以外に、クライアントからの事前知識を必要としません。
The ALTO cross-domain server discovery cannot assume that the server-discovery client and the server-discovery responding entity are under the same administrative control.
ALTOクロスドメインサーバーの検出では、サーバー検出クライアントとサーバー検出応答エンティティが同じ管理制御下にあると想定できません。
This appendix provides a complete example of using ALTO and the ALTO Cross-Domain Server Discovery Procedure in one specific application scenario -- namely, a tracker-based peer-to-peer application. First, in Appendix C.1, we introduce a generic model of such an application and show why ALTO optimization is desirable. Then, in Appendix C.2, we introduce two architectural options for integrating ALTO into the tracker-based peer-to-peer application; one option is based on the "regular" ALTO server discovery procedure [RFC7286], and one relies on the ALTO Cross-Domain Server Discovery Procedure. In Appendix C.3, a simple mathematical model is used to show that the latter approach is expected to yield significantly better optimization results. The appendix concludes with Appendix C.4, which details an exemplary complete walk-through of the ALTO Cross-Domain Server Discovery Procedure.
この付録では、特定の1つのアプリケーションシナリオ、つまりトラッカーベースのピアツーピアアプリケーションでALTOとALTOクロスドメインサーバー検出手順を使用する完全な例を示します。まず、付録C.1で、このようなアプリケーションの一般的なモデルを紹介し、ALTO最適化が望ましい理由を示します。次に、付録C.2で、ALTOをトラッカーベースのピアツーピアアプリケーションに統合するための2つのアーキテクチャオプションを紹介します。 1つのオプションは「通常の」ALTOサーバー検出手順[RFC7286]に基づいており、1つはALTOクロスドメインサーバー検出手順に依存しています。付録C.3では、単純な数学モデルを使用して、後者のアプローチが大幅に優れた最適化結果をもたらすことが期待されることを示しています。付録は、付録C.4で終わります。この付録では、ALTOクロスドメインサーバーの検出手順の完全なウォークスルーの詳細を説明しています。
The optimization of peer-to-peer (P2P) applications such as BitTorrent was one of the first use cases that lead to the inception of the IETF ALTO working group. Further use cases have been identified as well, yet we will use this scenario to illustrate the operation and usefulness of the ALTO Cross-Domain Server Discovery Procedure.
BitTorrentなどのピアツーピア（P2P）アプリケーションの最適化は、IETF ALTOワーキンググループの開始につながった最初のユースケースの1つでした。さらなるユースケースも確認されていますが、このシナリオを使用して、ALTOクロスドメインサーバー検出手順の操作と有用性を説明します。
For the remainder of this chapter, we consider a generic, tracker-based peer-to-peer file-sharing application. The goal is the dissemination of a large file, without using one large server with a correspondingly high upload bandwidth. The file is split into chunks. So-called "peers" assume the role of both a client and a server. That is, they may request chunks from other peers, and they may serve the chunks they already possess to other peers at the same time, thereby contributing their upload bandwidth. Peers that want to share the same file participate in a "swarm". They use the peer-to-peer protocol to inform each other about the availability of chunks and request and transfer chunks from one peer to another. A swarm may consist of a very large number of peers. Consequently, peers usually maintain logical connections to only a subset of all peers in the swarm. If a new peer wants to join a swarm, it first contacts a well-known server, the "tracker", which provides a list of IP addresses of peers in the swarm.
この章の残りの部分では、汎用のトラッカーベースのピアツーピアファイル共有アプリケーションについて検討します。目標は、対応する高いアップロード帯域幅を持つ1台の大きなサーバーを使用せずに、大きなファイルを配布することです。ファイルはチャンクに分割されます。いわゆる「ピア」は、クライアントとサーバーの両方の役割を担います。つまり、他のピアにチャンクを要求したり、すでに所有しているチャンクを他のピアに同時に提供したりして、アップロードの帯域幅に貢献することができます。同じファイルを共有したいピアは「スウォーム」に参加します。それらは、ピアツーピアプロトコルを使用して、チャンクの可用性について互いに通知し、チャンクを1つのピアから別のピアに要求および転送します。群れは、非常に多数のピアで構成される場合があります。その結果、ピアは通常、スウォーム内のすべてのピアのサブセットのみへの論理接続を維持します。新しいピアがスウォームに参加したい場合、最初によく知られたサーバーである「トラッカー」に連絡します。これは、スウォーム内のピアのIPアドレスのリストを提供します。
A swarm is an overlay network on top of the IP network. Algorithms that determine the overlay topology and the traffic distribution in the overlay may consider information about the underlying IP network, such as topological distance, link bandwidth, (monetary) costs for sending traffic from one host to another, etc. ALTO is a protocol for retrieving such information. The goal of such "topology-aware" decisions is to improve performance or Quality of Experience in the application while reducing the utilization of the underlying network infrastructure.
スウォームは、IPネットワーク上のオーバーレイネットワークです。オーバーレイトポロジとオーバーレイ内のトラフィック分散を決定するアルゴリズムは、トポロジー距離、リンク帯域幅、1つのホストから別のホストにトラフィックを送信するための（金銭的）コストなど、基礎となるIPネットワークに関する情報を考慮します。ALTOは、そのような情報を取得する。このような「トポロジを認識する」決定の目標は、基盤となるネットワークインフラストラクチャの使用率を削減しながら、アプリケーションのパフォーマンスまたはエクスペリエンスの品質を向上させることです。
The ALTO protocol specification [RFC7285] details how an ALTO client can query an ALTO server for guiding information and receive the corresponding replies. However, in the considered scenario of a tracker-based P2P application, there are two fundamentally different possible locations for where to place the ALTO client:
ALTOプロトコル仕様[RFC7285]は、ALTOクライアントがガイド情報を求めてALTOサーバーにクエリを行い、対応する応答を受信する方法を詳しく説明しています。ただし、トラッカーベースのP2Pアプリケーションの検討シナリオでは、ALTOクライアントを配置する場所として、根本的に異なる2つの場所が考えられます。
1. ALTO client in the resource consumer ("peer")
1. リソースコンシューマ（ "ピア"）のALTOクライアント
2. ALTO client in the resource directory ("tracker")
2. リソースディレクトリ内のALTOクライアント（「トラッカー」）
In the following, both scenarios are compared in order to explain the need for ALTO queries on behalf of remote resource consumers.
以下では、リモートリソースコンシューマに代わってALTOクエリの必要性を説明するために、両方のシナリオを比較します。
In the first scenario (see Figure 2), the resource consumer queries the resource directory for the desired resource (F1). The resource directory returns a list of potential resource providers without considering ALTO (F2). It is then the duty of the resource consumer to invoke ALTO (F3/F4), in order to solicit guidance regarding this list.
最初のシナリオ（図2を参照）では、リソースコンシューマーがリソースディレクトリに目的のリソース（F1）を照会します。リソースディレクトリは、ALTO（F2）を考慮せずに、潜在的なリソースプロバイダーのリストを返します。このリストに関するガイダンスを求めるために、ALTO（F3 / F4）を呼び出すのはリソースコンシューマーの義務です。
In the second scenario (see Figure 4), the resource directory has an embedded ALTO client. After receiving a query for a given resource (F1), the resource directory invokes this ALTO client to evaluate all resource providers it knows (F2/F3). Then it returns a list, possibly shortened, containing the "best" resource providers to the resource consumer (F4).
2番目のシナリオ（図4を参照）では、リソースディレクトリにALTOクライアントが組み込まれています。特定のリソース（F1）のクエリを受け取った後、リソースディレクトリはこのALTOクライアントを呼び出して、知っているすべてのリソースプロバイダーを評価します（F2 / F3）。次に、リソースコンシューマー（F4）に「最適な」リソースプロバイダーを含む、短縮されたリストを返します。
............................. .............................
: Tracker : : Peer :
: ______ : : :
: +-______-+ : : k good :
: | | +--------+ : P2P App. : +--------+ peers +------+ :
: | N | | random | : Protocol : | ALTO- |------>| data | :
: | known |====>| pre- |*************>| biased | | ex- | :
: | peers, | | selec- | : transmit : | peer |------>| cha- | :
: | M good | | tion | : n peer : | select | n-k | nge | :
: +-______-+ +--------+ : IDs : +--------+ bad p.+------+ :
:...........................: :.....^.....................:
|
| ALTO protocol
__|___
+-______-+
| |
| ALTO |
| server |
+-______-+
Figure 1: Tracker-Based P2P Application with Random Peer Preselection
図1：ランダムピア事前選択を使用したトラッカーベースのP2Pアプリケーション
Peer w. ALTO cli. Tracker ALTO Server
--------+-------- --------+-------- --------+--------
| F1 Tracker query | |
|======================>| |
| F2 Tracker reply | |
|<======================| |
| F3 ALTO query | |
|---------------------------------------------->|
| F4 ALTO reply | |
|<----------------------------------------------|
| | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO protocol
Figure 2: Basic Message Sequence Chart for Resource Consumer-Initiated ALTO Query
図2：リソースコンシューマが開始したALTOクエリの基本的なメッセージシーケンスチャート
............................. .............................
: Tracker : : Peer :
: ______ : : :
: +-______-+ : : :
: | | +--------+ : P2P App. : k good peers & +------+ :
: | N | | ALTO- | : Protocol : n-k bad peers | data | :
: | known |====>| biased |******************************>| ex- | :
: | peers, | | peer | : transmit : | cha- | :
: | M good | | select | : n peer : | nge | :
: +-______-+ +--------+ : IDs : +------+ :
:.....................^.....: :...........................:
|
| ALTO protocol
__|___
+-______-+
| |
| ALTO |
| server |
+-______-+
Figure 3: Tracker-Based P2P Application with ALTO Client in Tracker
図3：トラッカーにALTOクライアントを備えたトラッカーベースのP2Pアプリケーション
Peer Tracker w. ALTO cli. ALTO Server
--------+-------- --------+-------- --------+--------
| F1 Tracker query | |
|======================>| |
| | F2 ALTO query |
| |---------------------->|
| | F3 ALTO reply |
| |<----------------------|
| F4 Tracker reply | |
|<======================| |
| | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO protocol
Figure 4: Basic Message Sequence Chart for ALTO Query on Behalf of Remote Resource Consumer
図4：リモートリソースコンシューマに代わるALTOクエリの基本的なメッセージシーケンスチャート
| Note: The message sequences depicted in Figures 2 and 4 may
| occur both in the target-aware and the target-independent query
| mode (cf. [RFC6708]). In the target-independent query mode, no
| message exchange with the ALTO server might be needed after the
| tracker query, because the candidate resource providers could
| be evaluated using a locally cached "map", which has been
| retrieved from the ALTO server some time ago.
The problem with the first approach is that while the resource directory might know thousands of peers taking part in a swarm, the list returned to the resource consumer is usually shortened for efficiency reasons. Therefore, the "best" (in the sense of ALTO) potential resource providers might not be contained in that list anymore, even before ALTO can consider them.
最初のアプローチの問題は、リソースディレクトリがスウォームに参加する数千のピアを知っている可能性がある一方で、リソースコンシューマに返されるリストは通常、効率上の理由で短縮されることです。したがって、ALTOが考慮に入れる前であっても、（ALTOの意味で）「最良」の潜在的なリソースプロバイダーは、そのリストに含まれなくなる可能性があります。
For illustration, consider a simple model of a swarm, in which all peers fall into one of only two categories: assume that there are only "good" (in the sense of ALTO's better-than-random peer selection, based on an arbitrary desired rating criterion) and "bad" peers. Having more different categories makes the math more complex but does not change anything about the basic outcome of this analysis. Assume that the swarm has a total number of N peers, out of which there are M "good" and N-M "bad" peers, which are all known to the tracker. A new peer wants to join the swarm and therefore asks the tracker for a list of peers.
説明のために、すべてのピアが2つだけのカテゴリの1つに分類される、スウォームの単純なモデルを考えてみましょう。評価基準）と「悪い」ピア。さまざまなカテゴリがあると、計算はより複雑になりますが、この分析の基本的な結果については何も変わりません。スウォームには合計N個のピアがあり、そのうちのM個の「良好」ピアとN-M個の「不良」ピアがあり、これらはすべてトラッカーに認識されています。新しいピアがスウォームに参加することを望んでいるため、トラッカーにピアのリストを要求します。
If, according to the first approach, the tracker randomly picks n peers from the N known peers, the result can be described with the hypergeometric distribution. The probability that the tracker reply contains exactly k "good" peers (and n-k "bad" peers) is:
最初のアプローチに従って、トラッカーがN個の既知のピアからランダムにn個のピアを選択した場合、結果は超幾何分布で記述できます。トラッカーの応答に正確にk個の「良好な」ピア（およびn-k個の「不良な」ピア）が含まれる確率は次のとおりです。
/ M \ / N - M \
\ k / \ n - k /
P(X=k) = ---------------------
/ N \
\ n /
/ n \ n!
with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1
k! (n-k)!
The probability that the reply contains at most k "good" peers is: P(X<=k) = P(X=0) + P(X=1) + .. + P(X=k).
応答に最大でk個の「良好な」ピアが含まれる確率は、P（X <= k）= P（X = 0）+ P（X = 1）+ .. + P（X = k）です。
For example, consider a swarm with N=10,000 peers known to the tracker, out of which M=100 are "good" peers. If the tracker randomly selects n=100 peers, the formula yields for the reply: P(X=0)=36%, P(X<=4)=99%. That is, with a probability of approximately 36%, this list does not contain a single "good" peer, and with 99% probability, there are only four or fewer of the "good" peers on the list. Processing this list with the guiding ALTO information will ensure that the few favorable peers are ranked to the top of the list; however, the benefit is rather limited as the number of favorable peers in the list is just too small.
たとえば、トラッカーに既知のN = 10,000のピアを持つ群を考えます。そのうち、M = 100は「良好な」ピアです。トラッカーがn = 100のピアをランダムに選択する場合、式は応答に対して生成されます：P（X = 0）= 36％、P（X <= 4）= 99％。つまり、約36％の確率で、このリストには単一の「良好な」ピアが含まれていません。99％の確率では、リストに含まれる「良好な」ピアは4つ以下です。このリストをガイドALTO情報で処理すると、少数の有利なピアがリストの最上位にランク付けされます。ただし、リスト内の有利なピアの数が少なすぎるため、利点はかなり限られています。
Much better traffic optimization could be achieved if the tracker would evaluate all known peers using ALTO and return a list of 100 peers afterwards. This list would then include a significantly higher fraction of "good" peers. (Note that if the tracker returned "good" peers only, there might be a risk that the swarm might disconnect and split into several disjunct partitions. However, finding the right mix of ALTO-biased and random peer selection is out of the scope of this document.)
トラッカーがALTOを使用してすべての既知のピアを評価し、その後100ピアのリストを返す場合、はるかに優れたトラフィック最適化を実現できます。このリストには、「良い」ピアのかなり高い割合が含まれます。 （トラッカーが「良好な」ピアのみを返した場合、スウォームが切断され、いくつかの分離したパーティションに分割されるリスクがあることに注意してください。ただし、ALTOバイアスとランダムピア選択の適切な組み合わせを見つけることは、このドキュメント。）
Therefore, from an overall optimization perspective, the second scenario with the ALTO client embedded in the resource directory is advantageous, because it is ensured that the addresses of the "best" resource providers are actually delivered to the resource consumer. An architectural implication of this insight is that the ALTO server discovery procedures must support ALTO queries on behalf of remote resource consumers. That is, as the tracker issues ALTO queries on behalf of the peer that contacted the tracker, the tracker must be able to discover an ALTO server that can give guidance suitable for that peer. This task can be solved using the ALTO Cross-Domain Server Discovery Procedure.
したがって、全体的な最適化の観点から見ると、ALTOクライアントがリソースディレクトリに埋め込まれている2番目のシナリオは、「最適な」リソースプロバイダーのアドレスが実際にリソースコンシューマーに確実に配信されるため、有利です。この洞察のアーキテクチャ上の意味は、ALTOサーバーの検出手順が、リモートリソースコンシューマに代わってALTOクエリをサポートする必要があることです。つまり、トラッカーは、トラッカーに連絡したピアに代わってALTOクエリを発行するため、そのピアに適したガイダンスを提供できるALTOサーバーを検出できる必要があります。このタスクは、ALTO Cross-Domain Server Discovery Procedureを使用して解決できます。
This section provides a complete example of the ALTO Cross-Domain Server Discovery Procedure in a tracker-based peer-to-peer scenario.
このセクションでは、トラッカーベースのピアツーピアシナリオでのALTOクロスドメインサーバー検出手順の完全な例を示します。
The example is based on the network topology shown in Figure 5. Five access networks -- Networks a, b, c, x, and t -- are operated by five different network operators. They are interconnected by a backbone structure. Each network operator runs an ALTO server in their network -- i.e., ALTO_SRV_A, ALTO_SRV_B, ALTO_SRV_C, ALTO_SRV_X, and ALTO_SRV_T, respectively.
この例は、図5に示すネットワークトポロジに基づいています。5つのアクセスネットワーク（ネットワークa、b、c、x、およびt）は、5つの異なるネットワークオペレーターによって運用されています。それらはバックボーン構造によって相互接続されています。各ネットワークオペレーターは、ネットワーク内でALTOサーバーを実行します。つまり、それぞれALTO_SRV_A、ALTO_SRV_B、ALTO_SRV_C、ALTO_SRV_X、およびALTO_SRV_Tです。
_____ __ _____ __ _____ __
__( )__( )_ __( )__( )_ __( )__( )_
( Network a ) ( Network b ) ( Network c )
( Res. Provider A ) ( Res. Provider B ) ( Res. Provider C )
(__ ALTO_SRV_A __) (__ ALTO_SRV_B __) (__ ALTO_SRV_C __)
(___)--(____) \ (___)--(____) / (___)--(____)
\ / /
---+---------+-----------------+----
( Backbone )
------------+------------------+----
_____ __/ _____ \__
__( )__( )_ __( )__( )_
( Network x ) ( Network t )
( Res. Consumer X ) (Resource Directory)
(_ ALTO_SRV_X __) (_ ALTO_SRV_T __)
(___)--(____) (___)--(____)
Figure 5: Example Network Topology
図5：ネットワークトポロジの例
A new peer of a peer-to-peer application wants to join a specific swarm (overlay network), in order to access a specific resource. This new peer will be called "Resource Consumer X", in accordance with the terminology of [RFC6708], and is located in Network x. It contacts the tracker ("Resource Directory"), which is located in Network t. The mechanism by which the new peer discovers the tracker is out of the scope of this document. The tracker maintains a list of peers that take part in the overlay network, and hence it can determine that Resource Providers A, B, and C are candidate peers for Resource Consumer X.
ピアツーピアアプリケーションの新しいピアは、特定のリソースにアクセスするために、特定のスウォーム（オーバーレイネットワーク）に参加したいと考えています。この新しいピアは、[RFC6708]の用語に従って「リソースコンシューマX」と呼ばれ、ネットワークxに配置されます。ネットワークtにあるトラッカー（「リソースディレクトリ」）に接続します。新しいピアがトラッカーを発見するメカニズムは、このドキュメントの範囲外です。トラッカーは、オーバーレイネットワークに参加するピアのリストを保持しているため、リソースプロバイダーA、B、CがリソースコンシューマーXの候補ピアであると判断できます。
As shown in the previous section, a tracker-side ALTO optimization (cf. Figures 3 and 4) is more efficient than a client-side optimization. Consequently, the tracker wants to use the ALTO Endpoint Cost Service (ECS) to learn the routing costs between X and A, X and B, and X and C, in order to sort A, B, and C by their respective routing costs to X.
前のセクションで示したように、トラッカー側のALTO最適化（図3および4を参照）は、クライアント側の最適化よりも効率的です。したがって、トラッカーは、ALTOエンドポイントコストサービス（ECS）を使用して、XとA、XとB、およびXとCの間のルーティングコストを学習し、A、B、Cをそれぞれのルーティングコストでソートして、バツ。
In theory, there are many options for how the ALTO Cross-Domain Server Discovery Procedure could be used. For example, the tracker could do the following steps:
理論的には、ALTO Cross-Domain Server Discovery Procedureの使用方法には多くのオプションがあります。たとえば、トラッカーは次の手順を実行できます。
IRD_URIS_A = XDOMDISC(A,"ALTO:https")
COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_A
IRD_URIS_B = XDOMDISC(B,"ALTO:https")
COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_B
IRD_URIS_C = XDOMDISC(C,"ALTO:https")
COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_C
In this scenario, the ALTO Cross-Domain Server Discovery Procedure queries might yield: IRD_URIS_A = ALTO_SRV_A, IRD_URIS_B = ALTO_SRV_B, and IRD_URIS_C = ALTO_SRV_C. That is, each ECS query would be sent to a different ALTO server. The problem with this approach is that we are not necessarily able to compare COST_X_A, COST_X_B, and COST_X_C with each other. The specification of the routingcost metric mandates that "A lower value indicates a higher preference", but "an ISP may internally compute routing cost using any method that it chooses" (see Section 6.1.1.1 of [RFC7285]). Thus, COST_X_A could be 10 (milliseconds round-trip time), while COST_X_B could be 200 (kilometers great circle distance between the approximate geographic locations of the hosts) and COST_X_C could be 3 (router hops, corresponding to a decrease of the TTL field in the IP header). Each of these metrics fulfills the "lower value is more preferable" requirement on its own, but they obviously cannot be compared with each other. Even if there were a reasonable formula to compare, for example, kilometers with milliseconds, we could not use it, as the units of measurement (or any other information about the computation method for the routingcost) are not sent along with the value in the ECS reply.
このシナリオでは、ALTO Cross-Domain Server Discovery Procedureクエリにより、IRD_URIS_A = ALTO_SRV_A、IRD_URIS_B = ALTO_SRV_B、およびIRD_URIS_C = ALTO_SRV_Cが生成される場合があります。つまり、各ECSクエリは異なるALTOサーバーに送信されます。このアプローチの問題は、COST_X_A、COST_X_B、COST_X_Cを互いに比較できるとは限らないことです。ルーティングコストメトリックの仕様では、「値が小さいほど優先度が高いことを示す」が規定されていますが、「ISPは、選択した任意の方法を使用してルーティングコストを内部的に計算する可能性があります」（[RFC7285]のセクション6.1.1.1を参照）。したがって、COST_X_Aは10（ミリ秒の往復時間）で、COST_X_Bは200（ホストのおおよその地理的位置間のキロメートルの大圏距離）、COST_X_Cは3（ルーターホップ、TTLフィールドの減少に対応） IPヘッダー）。これらの各指標は、それ自体で「値が小さいほど望ましい」という要件を満たしますが、それらを明らかに比較することはできません。たとえば、キロメートルとミリ秒を比較するための合理的な式があったとしても、測定単位（またはルーティングコストの計算方法に関するその他の情報）は、 ECS応答。
To avoid this problem, the tracker tries to send all ECS queries to the same ALTO server. As specified in Section 4.4 of this document, Case 2, it uses the IP address of Resource Consumer x as a parameter of the discovery procedure:
この問題を回避するために、トラッカーはすべてのECSクエリを同じALTOサーバーに送信しようとします。このドキュメントのケース4.4のケース2で指定されているように、リソースコンシューマxのIPアドレスを検出手順のパラメータとして使用します。
IRD_URIS_X = XDOMDISC(X,"ALTO:https")
COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_X
COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_X
COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_X
This strategy ensures that COST_X_A, COST_X_B, and COST_X_C can be compared with each other.
この戦略により、COST_X_A、COST_X_B、およびCOST_X_Cを確実に比較できます。
As discussed above, the tracker calls the ALTO Cross-Domain Server Discovery Procedure with IP address X as a parameter. For the remainder of this example, we assume that X = 2001:DB8:1:2:227:eff:fe6a:de42. Thus, the procedure call is IRD_URIS_X = XDOMDISC(2001:DB8:1:2:227:eff:fe6a:de42,"ALTO:https").
上で説明したように、トラッカーはIPアドレスXをパラメーターとして使用して、ALTOクロスドメインサーバー検出手順を呼び出します。この例の残りの部分では、X = 2001：DB8：1：2：227：eff：fe6a：de42と想定しています。したがって、プロシージャコールはIRD_URIS_X = XDOMDISC（2001：DB8：1：2：227：eff：fe6a：de42、 "ALTO：https"）です。
The first parameter, 2001:DB8:1:2:227:eff:fe6a:de42, is a single IPv6 address. Thus, we get AT = IPv6, A = 2001:DB8:1:2:227:eff:fe6a:de42, L = 128, and SP = "ALTO:https".
最初のパラメーター2001：DB8：1：2：227：eff：fe6a：de42は、単一のIPv6アドレスです。したがって、AT = IPv6、A = 2001：DB8：1：2：227：eff：fe6a：de42、L = 128、およびSP = "ALTO：https"になります。
The procedure constructs (see Step 1 in Section 3.2)
プロシージャは構成します（セクション3.2のステップ1を参照）
R128 = "2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.2.0.0.0.1.0.0.0. 8.B.D.0.1.0.0.2.IP6.ARPA."
R128 = "2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.2.0.0.0.1.0.0.0。8.B.D.0.1.0.0.2.IP6.ARPA。"
as well as the following (see Step 2 in Section 3.2):
また、次のことも行います（セクション3.2のステップ2を参照）。
R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA." R56 = "0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA." R48 = "1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA." R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA." R32 = "8.B.D.0.1.0.0.2.IP6.ARPA."
R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA。" R56 = "0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA。" R48 = "1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA。" R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA。" R32 = "8.B.D.0.1.0.0.2.IP6.ARPA。"
In order to illustrate the third step of the ALTO Cross-Domain Server Discovery Procedure, we use the "dig" (domain information groper) DNS lookup utility that is available for many operating systems (e.g., Linux). A real implementation of the ALTO Cross-Domain Server Discovery Procedure would not be based on the "dig" utility but instead would use appropriate libraries and/or operating-system APIs. Please note that the following steps have been performed in a controlled lab environment with an appropriately configured name server. A suitable DNS configuration will be needed to reproduce these results. Please also note that the rather verbose output of the "dig" tool has been shortened to the relevant lines.
ALTO Cross-Domain Server Discovery Procedureの3番目のステップを説明するために、多くのオペレーティングシステム（Linuxなど）で使用可能な「dig」（ドメイン情報groper）DNSルックアップユーティリティを使用します。 ALTOクロスドメインサーバーディスカバリプロシージャの実際の実装は、「dig」ユーティリティに基づくのではなく、適切なライブラリやオペレーティングシステムAPIを使用します。以下の手順は、適切に構成されたネームサーバーを使用して、制御されたラボ環境で実行されていることに注意してください。これらの結果を再現するには、適切なDNS構成が必要です。 「dig」ツールのかなり冗長な出力が関連する行に短縮されていることにも注意してください。
Since AT = IPv6 and L = 128, in the table given in Section 3.4, the sixth row (not counting the column headers) applies.
AT = IPv6およびL = 128なので、セクション3.4の表では、6番目の行（列ヘッダーは数えません）が適用されます。
As mandated by the third column, we start with a lookup of R128, looking for NAPTR resource records:
3番目の列で義務付けられているように、NAPTRリソースレコードを探すR128のルックアップから始めます。
| user@labpc:~$ dig -tNAPTR 2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.\
| 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
|
| ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26553
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0
The domain name R128 does not exist (status: NXDOMAIN), so we cannot get a useful result. Therefore, we continue with the fourth column of the table and do a lookup of R64:
ドメイン名R128が存在しないため（ステータス：NXDOMAIN）、有用な結果を得ることができません。したがって、テーブルの4列目を続行して、R64のルックアップを行います。
| user@labpc:~$ dig -tNAPTR 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
|
| ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33193
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0
The domain name R64 could be looked up (status: NOERROR), but there are no NAPTR resource records associated with it (ANSWER: 0). There may be some other resource records such as PTR, NS, or SOA, but we are not interested in them. Thus, we do not get a useful result, and we continue with looking up R56:
ドメイン名R64を検索できましたが（ステータス：NOERROR）、それに関連付けられたNAPTRリソースレコードはありません（ANSWER：0）。 PTR、NS、SOAなどの他のリソースレコードが存在する可能性がありますが、それらには関心がありません。したがって、有用な結果は得られず、R56の検索を続行します。
| user@labpc:~$ dig -tNAPTR 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
|
| ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35966
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
|
| ;; ANSWER SECTION:
| 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
| "LIS:HELD" "!.*!https://lis1.example.org:4802/?c=ex!" .
| 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 20 "u"
| "LIS:HELD" "!.*!https://lis2.example.org:4802/?c=ex!" .
The domain name R56 could be looked up, and there are NAPTR resource records associated with it. However, each of these records has a service parameter that does not match our SP = "ALTO:https" (see [RFC7216] for "LIS:HELD"), and therefore we have to ignore them. Consequently, we still do not have a useful result and continue with a lookup of R48:
ドメイン名R56を検索でき、それに関連付けられたNAPTRリソースレコードがあります。ただし、これらの各レコードには、SP = "ALTO：https"（[LIS：HELD]については[RFC7216]を参照）と一致しないサービスパラメータがあるため、無視する必要があります。その結果、まだ有用な結果が得られず、R48のルックアップを続行します。
| user@labpc:~$ dig -tNAPTR 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
|
| ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50459
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
|
| ;; ANSWER SECTION:
| 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
| "ALTO:https" "!.*!https://alto1.example.net/ird!" .
| 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
| "LIS:HELD" "!.*!https://lis.example.net:4802/?c=ex!" .
This lookup yields two NAPTR resource records. We have to ignore the second one as its service parameter does not match our SP, but the first NAPTR resource record has a matching service parameter. Therefore, the procedure terminates successfully and the final outcome is: IRD_URIS_X = "https://alto1.example.net/ird".
このルックアップにより、2つのNAPTRリソースレコードが生成されます。 2番目のサービスはサービスパラメータがSPと一致しないため無視する必要がありますが、最初のNAPTRリソースレコードには一致するサービスパラメータがあります。したがって、プロシージャは正常に終了し、最終結果はIRD_URIS_X = "https://alto1.example.net/ird"になります。
The ALTO client that is embedded in the tracker will access the ALTO Information Resource Directory (IRD, see Section 9 of [RFC7285]) at this URI, look for the Endpoint Cost Service (ECS, see Section 11.5 of [RFC7285]), and query the ECS for the costs between A and X, B and X, and C and X, before returning an ALTO-optimized list of candidate resource providers to resource consumer X.
トラッカーに組み込まれているALTOクライアントは、このURIでALTO情報リソースディレクトリ（IRD、[RFC7285]のセクション9を参照）にアクセスし、Endpoint Cost Service（ECS、[RFC7285]のセクション11.5を参照）を探します。 AとX、BとX、CとXの間のコストをECSに問い合わせてから、リソースプロバイダー候補のALTO最適化リストをリソースコンシューマーXに返します。
Acknowledgments
謝辞
The initial draft version of this document was co-authored by Marco Tomsu (Alcatel-Lucent).
このドキュメントの最初のドラフトバージョンは、Marco Tomsu（Alcatel-Lucent）によって共同執筆されました。
This document borrows some text from [RFC7286], as historically, it was part of the draft that eventually became said RFC. Special thanks to Michael Scharf and Nico Schwan.
この文書は、[RFC7286]から一部のテキストを借用したものであり、歴史的には、最終的にはRFCとなった草案の一部でした。 Michael ScharfとNico Schwanに特に感謝します。
Authors' Addresses
著者のアドレス
Sebastian Kiesel University of Stuttgart Information Center Allmandring 30 70550 Stuttgart Germany
Sebastian Kiesel University of Stuttgart Information Center Allmandring 30 70550シュトゥットガルトドイツ
Email: ietf-alto@skiesel.de
URI: http://www.izus.uni-stuttgart.de
Martin Stiemerling University of Applied Sciences Darmstadt, Computer Science Dept. Haardtring 100 64295 Darmstadt Germany
マーティンスティーマーリング応用科学大学ダルムシュタット、コンピューターサイエンス学部ハードトリング100 64295ダルムシュタットドイツ
Phone: +49 6151 16 37938
Email: mls.ietf@gmail.com
URI: https://danet.fbi.h-da.de