rfc8686.original   rfc8686.txt 
ALTO S. Kiesel Internet Engineering Task Force (IETF) S. Kiesel
Internet-Draft University of Stuttgart Request for Comments: 8686 University of Stuttgart
Intended status: Standards Track M. Stiemerling Category: Standards Track M. Stiemerling
Expires: February 21, 2020 H-DA ISSN: 2070-1721 H-DA
August 20, 2019 January 2020
Application Layer Traffic Optimization (ALTO) Cross-Domain Server Application-Layer Traffic Optimization (ALTO) Cross-Domain Server
Discovery Discovery
draft-ietf-alto-xdom-disc-06
Abstract Abstract
The goal of Application-Layer Traffic Optimization (ALTO) is to The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications that have to select one or several provide guidance to applications that have to select one or several
hosts from a set of candidates capable of providing a desired hosts from a set of candidates capable of providing a desired
resource. ALTO is realized by a client-server protocol. Before an 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 client can ask for guidance, it needs to discover one or more
ALTO servers that can provide suitable guidance. ALTO servers that can provide suitable guidance.
In some deployment scenarios, in particular if the information about In some deployment scenarios, in particular if the information about
the network topology is partitioned and distributed over several ALTO the network topology is partitioned and distributed over several ALTO
servers, it may be needed to discover an ALTO server outside of the servers, it may be necessary to discover an ALTO server outside of
own network domain, in order to get appropriate guidance. This the ALTO client's own network domain, in order to get appropriate
document details applicable scenarios, itemizes requirements, and guidance. This document details applicable scenarios, itemizes
specifies a procedure for ALTO cross-domain server discovery. requirements, and specifies a procedure for ALTO cross-domain server
discovery.
Technically, the procedure specified in this document takes one Technically, the procedure specified in this document takes one
IP address or prefix and a U-NAPTR Service Parameter (typically, IP address or prefix and a U-NAPTR Service Parameter (typically,
"ALTO:https") as parameters. It performs DNS lookups (for NAPTR "ALTO:https") as parameters. It performs DNS lookups (for NAPTR
resource records in the in-addr.arpa. or ip6.arpa. tree) and returns resource records in the "in-addr.arpa." or "ip6.arpa." trees) and
one or more URI(s) of information resources related to that IP returns one or more URIs of information resources related to that IP
address or prefix. address or prefix.
Terminology and Requirements Language Status of This Memo
This document makes use of the ALTO terminology defined in RFC 5693
[RFC5693].
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on February 21, 2020. 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.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction
2. ALTO Cross-Domain Server Discovery Procedure: Overview . . . . 5 1.1. Terminology and Requirements Language
3. ALTO Cross-Domain Server Discovery Procedure: Specification . 6 2. ALTO Cross-Domain Server Discovery Procedure: Overview
3.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 6 3. ALTO Cross-Domain Server Discovery Procedure: Specification
3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup . . . . 7 3.1. Interface
3.3. Step 2: Prepare Shortened Domain Names . . . . . . . . . . 8 3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup
3.4. Step 3: Perform DNS U-NAPTR lookups . . . . . . . . . . . 9 3.3. Step 2: Prepare Shortened Domain Names
3.5. Error Handling . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Step 3: Perform DNS U-NAPTR Lookups
4. Using the ALTO Protocol with Cross-Domain Server Discovery . . 11 3.5. Error Handling
4.1. Network and Cost Map Service . . . . . . . . . . . . . . . 11 4. Using the ALTO Protocol with Cross-Domain Server Discovery
4.2. Map-Filtering Service . . . . . . . . . . . . . . . . . . 12 4.1. Network and Cost Map Service
4.3. Endpoint Property Service . . . . . . . . . . . . . . . . 12 4.2. Map-Filtering Service
4.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 12 4.3. Endpoint Property Service
4.5. Summary and Further Extensions . . . . . . . . . . . . . . 14 4.4. Endpoint Cost Service
5. Implementation, Deployment, and Operational Considerations . . 15 4.5. Summary and Further Extensions
5.1. Considerations for ALTO Clients . . . . . . . . . . . . . 15 5. Implementation, Deployment, and Operational Considerations
5.2. Considerations for Network Operators . . . . . . . . . . . 17 5.1. Considerations for ALTO Clients
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5.2. Considerations for Network Operators
6.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 19 6. Security Considerations
6.2. Availability of the ALTO Server Discovery Procedure . . . 20 6.1. Integrity of the ALTO Server's URI
6.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 21 6.2. Availability of the ALTO Server Discovery Procedure
6.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 21 6.3. Confidentiality of the ALTO Server's URI
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6.4. Privacy for ALTO Clients
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations
8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 8. References
8.2. Informative References . . . . . . . . . . . . . . . . . . 24 8.1. Normative References
Appendix A. Solution Approaches for Partitioned ALTO Knowledge . 27 8.2. Informative References
A.1. Classification of Solution Approaches . . . . . . . . . . 27 Appendix A. Solution Approaches for Partitioned ALTO Knowledge
A.2. Discussion of Solution Approaches . . . . . . . . . . . . 28 A.1. Classification of Solution Approaches
A.3. The Need for Cross-Domain ALTO Server Discovery . . . . . 28 A.2. Discussion of Solution Approaches
A.4. Our Solution Approach . . . . . . . . . . . . . . . . . . 29 A.3. The Need for Cross-Domain ALTO Server Discovery
A.5. Relation to the ALTO Requirements . . . . . . . . . . . . 29 A.4. Our Solution Approach
Appendix B. Requirements for Cross-Domain Server Discovery . . . 30 A.5. Relation to the ALTO Requirements
B.1. Discovery Client Application Programming Interface . . . . 30 Appendix B. Requirements for Cross-Domain Server Discovery
B.2. Data Storage and Authority Requirements . . . . . . . . . 30 B.1. Discovery Client Application Programming Interface
B.3. Cross-Domain Operations Requirements . . . . . . . . . . . 30 B.2. Data Storage and Authority Requirements
B.4. Protocol Requirements . . . . . . . . . . . . . . . . . . 31 B.3. Cross-Domain Operations Requirements
B.5. Further Requirements . . . . . . . . . . . . . . . . . . . 31 B.4. Protocol Requirements
Appendix C. ALTO and Tracker-based Peer-to-Peer Applications . . 32 B.5. Further Requirements
C.1. A generic Tracker-based Peer-to-Peer Application . . . . . 32 Appendix C. ALTO and Tracker-Based Peer-to-Peer Applications
C.2. Architectural Options for Placing the ALTO Client . . . . 33 C.1. A Generic Tracker-Based Peer-to-Peer Application
C.3. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 36 C.2. Architectural Options for Placing the ALTO Client
C.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 38 C.3. Evaluation
Appendix D. Contributors List and Acknowledgments . . . . . . . . 43 C.4. Example
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Acknowledgments
Authors' Addresses
1. Introduction 1. Introduction
The goal of Application-Layer Traffic Optimization (ALTO) is to The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications that have to select one or several provide guidance to applications that have to select one or several
hosts from a set of candidates capable of providing a desired hosts from a set of candidates capable of providing a desired
resource [RFC5693]. ALTO is realized by an HTTP-based client-server resource [RFC5693]. ALTO is realized by an HTTP-based client-server
protocol [RFC7285], which can be used in various scenarios [RFC7971]. protocol [RFC7285], which can be used in various scenarios [RFC7971].
The ALTO base protocol document [RFC7285] specifies the communication The ALTO base protocol document [RFC7285] specifies the communication
between an ALTO client and one ALTO server. In principle, the client 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 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 between any two IP addresses, or it might request network and
cost maps for the whole network, which might be the worldwide cost maps for the whole network, which might be the worldwide
Internet. It is assumed that the server can answer any query, Internet. It is assumed that the server can answer any query,
possibly with some kind of default value if no exact data is known. possibly with some kind of default value if no exact data is known.
No special provisions were made for deployment scenarios with No special provisions were made for deployment scenarios with
multiple ALTO servers, with some servers having more accurate multiple ALTO servers, with some servers having more accurate
information about some parts of the network topology while others information about some parts of the network topology while others
having better information about other parts of the network have better information about other parts of the network
("partitioned knowledge"). Various ALTO use cases have been studied ("partitioned knowledge"). Various ALTO use cases have been studied
in the context of such scenarios. In some cases, one cannot assume in the context of such scenarios. In some cases, one cannot assume
that a topologically nearby ALTO server (e.g., a server discovered that a topologically nearby ALTO server (e.g., a server discovered
with the procedure specified in [RFC7286]) will always provide useful with the procedure specified in [RFC7286]) will always provide useful
information to the client. One such scenario is detailed in information to the client. One such scenario is detailed in
Appendix C. Several solution approaches, such as redirecting a Appendix C. Several solution approaches, such as redirecting a
client to a server that has more accurate information or forwarding client to a server that has more accurate information or forwarding
the request to it on behalf of the client, have been proposed and the request to such a server on behalf of the client, have been
analyzed (see Appendix A), but none has been specified so far. proposed and analyzed (see Appendix A), but no solution has been
specified so far.
Section 3 of this document specifies the "ALTO Cross-Domain Server Section 3 of this document specifies the "ALTO Cross-Domain Server
Discovery Procedure" for client-side usage in these scenarios. An Discovery Procedure" for client-side usage in these scenarios. An
ALTO client that wants to send an ALTO query related to a specific IP 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 paramenter. address or prefix X may call this procedure with X as a parameter.
It will use Domain Name System (DNS) lookups to find of one ore more It will use Domain Name System (DNS) lookups to find one or more ALTO
ALTO servers that can provide a competent answer. The above wording servers that can provide a competent answer. The above wording
"related to" was intentionally kept somewhat unspecific, as the exact "related to" was intentionally kept somewhat unspecific, as the exact
semantics depends on the ALTO service to be used; see Section 4. semantics depends on the ALTO service to be used; see Section 4.
Those who are in control of the "reverse DNS" for a given IP address 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 or prefix (i.e., the corresponding subdomain of "in-addr.arpa." or
ip6.arpa.) - typically an Internet Service Provider (ISP), a "ip6.arpa.") -- typically an Internet Service Provider (ISP), a
corporate IT department, or a university's computing center - may add corporate IT department, or a university's computing center -- may
resource records to the DNS that point to one or more relevant ALTO add resource records to the DNS that point to one or more relevant
server(s). In many cases, it may be an ALTO server run by that ISP ALTO servers. In many cases, it may be an ALTO server run by that
or IT department, as they naturally have good insight into routing ISP or IT department, as they naturally have good insight into
costs from and to their networks. However, they may also refer to an routing costs from and to their networks. However, they may also
ALTO server provided by someone else, e.g., their upstream ISP. refer to an ALTO server provided by someone else, e.g., their
upstream ISP.
1.1. Terminology and Requirements Language
This document makes use of the ALTO terminology defined in RFC 5693
[RFC5693].
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.
2. ALTO Cross-Domain Server Discovery Procedure: Overview 2. ALTO Cross-Domain Server Discovery Procedure: Overview
This section gives a non-normative overview on the ALTO Cross-Domain This section gives a non-normative overview of the ALTO Cross-Domain
Server Discovery Procedure. The detailed specification will follow Server Discovery Procedure. The detailed specification will follow
in the next section. in the next section.
This procedure was inspired by the "Location Information Server (LIS) This procedure was inspired by "Location Information Server (LIS)
Discovery Using IP Addresses and Reverse DNS" [RFC7216] and re-uses Discovery Using IP Addresses and Reverse DNS" [RFC7216] and reuses
parts of the basic ALTO Server Discovery Procedure [RFC7286]. parts of the basic ALTO Server Discovery Procedure [RFC7286].
The basic idea is to use the Domain Name System (DNS), more The basic idea is to use the Domain Name System (DNS), more
specifically the "in-addr.arpa." or "ip6.arpa." trees, which are specifically the "in-addr.arpa." or "ip6.arpa." trees, which are
mostly used for "reverse mapping" of IP addresses to host names by mostly used for "reverse mapping" of IP addresses to host names by
means of PTR resource records. There, URI-enabled Naming Authority means of PTR resource records. There, URI-enabled Naming Authority
Pointer (U-NAPTR) resource records [RFC4848], which allow the mapping Pointer (U-NAPTR) resource records [RFC4848], which allow the mapping
of domain names to Uniform Resource Identifiers (URIs), are installed of domain names to Uniform Resource Identifiers (URIs), are installed
as needed. Thereby, it is possible to store a mapping from an IP 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. address or prefix to one or more ALTO server URIs in the DNS.
The ALTO Cross-Domain Server Discovery Procedure is called with one The ALTO Cross-Domain Server Discovery Procedure is called with one
IP address or prefix and a U-NAPTR Service Parameter [RFC4848] as IP address or prefix and a U-NAPTR Service Parameter [RFC4848] as
parameters. parameters.
The service parameter is usually set to "ALTO:https". However, other The service parameter is usually set to "ALTO:https". However, other
parameter values may be used in some scenarios, e.g., "ALTO:http" to parameter values may be used in some scenarios -- e.g., "ALTO:http"
search for a server that supports unencrypted transmission for to search for a server that supports unencrypted transmission for
debugging purposes, or other application protocol or service tags if debugging purposes, or other application protocol or service tags if
applicable. applicable.
The procedure performs DNS lookups and returns one or more URI(s) of The procedure performs DNS lookups and returns one or more URIs of
information resources related to said IP address or prefix, usually information resources related to said IP address or prefix, usually
the URI(s) of one or more ALTO Information Resource Directory (IRD, the URIs of one or more ALTO Information Resource Directories (IRDs;
see Section 9 of [RFC7285]). The U-NAPTR records also provide see Section 9 of [RFC7285]). The U-NAPTR records also provide
preference values, which should be considered if more than one URI is preference values, which should be considered if more than one URI is
returned. returned.
The discovery procedure sequentially tries two different lookup The discovery procedure sequentially tries two different lookup
strategies: First, an ALTO-specific U-NAPTR record is searched in the strategies. First, an ALTO-specific U-NAPTR record is searched in
"reverse tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa. the "reverse tree" -- i.e., in subdomains of "in-addr.arpa." or
corresponding to the given IP address or prefix. If this lookup does "ip6.arpa." corresponding to the given IP address or prefix. If this
not yield a usable result, the procedure tries further lookups with lookup does not yield a usable result, the procedure tries further
truncated domain names, which correspond to shorter prefix lengths. lookups with truncated domain names, which correspond to shorter
The goal is to allow deployment scenarios that require fine-grained prefix lengths. The goal is to allow deployment scenarios that
discovery on a per-IP basis, as well as large-scale scenarios where require fine-grained discovery on a per-IP basis, as well as large-
discovery is to be enabled for a large number of IP addresses with a scale scenarios where discovery is to be enabled for a large number
small number of additional DNS resource records. of IP addresses with a small number of additional DNS resource
records.
3. ALTO Cross-Domain Server Discovery Procedure: Specification 3. ALTO Cross-Domain Server Discovery Procedure: Specification
3.1. Interface 3.1. Interface
The procedure specified in this document takes two parameters, X and 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 SP, where X is an IP address or prefix and SP is a U-NAPTR Service
Parameter. Parameter.
The parameter X may be an IPv4 or an IPv6 address or prefix in CIDR The parameter X may be an IPv4 or an IPv6 address or prefix in
notation (see [RFC4632] for the IPv4 CIDR notation and [RFC4291] for Classless Inter-Domain Routing (CIDR) notation (see [RFC4632] for the
IPv6). Consequently, the address type AT is either "IPv4" or "IPv6". IPv4 CIDR notation and [RFC4291] for IPv6). Consequently, the
In both cases, X consists of an IP address A and a prefix length L. address type AT is either "IPv4" or "IPv6". In both cases, X
From the definition of IPv4 and IPv6 it follows that syntactically consists of an IP address A and a prefix length L. From the
valid values for L are 0 <= L <= 32 when AT=IPv4 and 0 <= L <= 128 definitions of IPv4 and IPv6, it follows that syntactically valid
when AT=IPv6. However, not all syntactically valid values of L are values for L are 0 <= L <= 32 when AT=IPv4 and 0 <= L <= 128 when
actually supported by this procedure - Step 1 (see below) will check AT=IPv6. However, not all syntactically valid values of L are
for unsupported values and report an error if neccessary. actually supported by this procedure; Step 1 (see below) will check
for unsupported values and report an error if necessary.
For example, for X=198.51.100.0/24, we get AT=IPv4, A=198.51.100.0 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, and L=24. Similarly, for X=2001:0DB8::20/128, we get AT=IPv6,
A=2001:0DB8::20 and L=128. A=2001:0DB8::20, and L=128.
In the intended usage scenario, the procedure is normally always In the intended usage scenario, the procedure is normally always
called with the parameter SP set to "ALTO:https". However, for called with the parameter SP set to "ALTO:https". However, for
general applicabiliy and in order to support future extensions, the general applicability and in order to support future extensions, the
procedure MUST support being called with any valid U-NAPTR Service procedure MUST support being called with any valid U-NAPTR Service
Parameter (see Section 4.5. of [RFC4848] for the syntax of U-NAPTR Parameter (see Section 4.5 of [RFC4848] for the syntax of U-NAPTR
Service Parameters and Section 5. of the same document for Service Parameters and Section 5 of the same document for information
information about the IANA registries). about the IANA registries).
The procedure performs DNS lookups and returns one or more URI(s) of The procedure performs DNS lookups and returns one or more URIs of
information resources related to that IP address or prefix, usually information resources related to that IP address or prefix, usually
the URI(s) of one or more ALTO Information Resource Directory (IRD, the URIs of one or more ALTO Information Resource Directories (IRDs;
see Section 9 of [RFC7285]). For each URI, it also returns order and see Section 9 of [RFC7285]). For each URI, the procedure also
preference values (see Section 4.1 of [RFC3403]), which should be returns order and preference values (see Section 4.1 of [RFC3403]),
considered if more than one URI is returned. which should be considered if more than one URI is returned.
During execution of this procedure, various error conditions may During execution of this procedure, various error conditions may
occur and have to be reported to the caller; see Section 3.5. occur and have to be reported to the caller; see Section 3.5.
For the remainder of the document, we use the following notation for For the remainder of the document, we use the following notation for
calling the ALTO Cross-Domain Server Discovery Procedure: calling the ALTO Cross-Domain Server Discovery
Procedure: IRD_URIS_X = XDOMDISC(X,"ALTO:https")
IRD_URIS_X = XDOMDISC(X,"ALTO:https")
3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup 3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup
First, the procedure checks the prefix length L for unsupported 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 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 procedure aborts and indicates an "unsupported prefix length" error
to the caller. Similarly, if AT=IPv6 and L < 32, the procedure to the caller. Similarly, if AT=IPv6 and L < 32, the procedure
aborts and indicates an "unsupported prefix length" error to the aborts and indicates an "unsupported prefix length" error to the
caller. Otherwise, the procedure continues. caller. Otherwise, the procedure continues.
If AT=IPv4, the procedure will then produce a DNS domain name, which If AT=IPv4, the procedure will then produce a DNS domain name, which
will be referred to as R32. This domain name is constructed will be referred to as R32. This domain name is constructed
according to the rules specified in Section 3.5 of [RFC1035] and it according to the rules specified in Section 3.5 of [RFC1035], and it
is rooted in the special domain "IN-ADDR.ARPA.". is rooted in the special domain "IN-ADDR.ARPA.".
For example, A=198.51.100.3 yields R32="3.100.51.198.IN-ADDR.ARPA.". For example, A=198.51.100.3 yields R32="3.100.51.198.IN-ADDR.ARPA.".
If AT=IPv6, a domain name. which will be called R128, is constructed 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 according to the rules specified in Section 2.5 of [RFC3596], and the
special domain "IP6.ARPA." is used. special domain "IP6.ARPA." is used.
For example (note: a line break was added after the second line), For example (note: a line break was added after the second line),
A = 2001:0DB8::20 yields 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. 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." 1.0.0.2.IP6.ARPA."
3.3. Step 2: Prepare Shortened Domain Names 3.3. Step 2: Prepare Shortened Domain Names
For this step, an auxiliary function "skip" is defined as follows: 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 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 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.". example, skip("foo.bar.baz.qux.quux.",2) will return "baz.qux.quux.".
If AT=IPv4, the following additional domain names are generated from If AT=IPv4, the following additional domain names are generated from
the result of the previous step: the result of the previous step:
R24=skip(R32,1), R24=skip(R32,1),
R16=skip(R32,2), and R16=skip(R32,2), and
R8=skip(R32,3). R8=skip(R32,3).
Removing one label from a domain name (i.e., one number of the Removing one label from a domain name (i.e., one number of the
"dotted quad notation") corresponds to shortening the prefix length "dotted quad notation") corresponds to shortening the prefix length
by 8 bits. by 8 bits.
For example, R32="3.100.51.198.IN-ADDR.ARPA." yields For example,
R24="100.51.198.IN-ADDR.ARPA.", R16="51.198.IN-ADDR.ARPA.", and
R8="198.IN-ADDR.ARPA.". 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."
If AT=IPv6, the following additional domain names are generated from If AT=IPv6, the following additional domain names are generated from
the result of the previous step: the result of the previous step:
R64=skip(R128,16), R64=skip(R128,16),
R56=skip(R128,18), R56=skip(R128,18),
R48=skip(R128,20), R48=skip(R128,20),
skipping to change at page 8, line 46 skipping to change at line 338
R48=skip(R128,20), R48=skip(R128,20),
R40=skip(R128,22), and R40=skip(R128,22), and
R32=skip(R128,24). R32=skip(R128,24).
Removing one label from a domain name (i.e., one hex digit) Removing one label from a domain name (i.e., one hex digit)
corresponds to shortening the prefix length by 4 bits. corresponds to shortening the prefix length by 4 bits.
For example (note: a line break was added after the first line), 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. 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 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.", 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.", 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.", 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.", and R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.". R32 = "8.B.D.0.1.0.0.2.IP6.ARPA."
3.4. Step 3: Perform DNS U-NAPTR lookups 3.4. Step 3: Perform DNS U-NAPTR Lookups
The address type and the prefix length of X are matched against the The address type and the prefix length of X are matched against the
first and the second column of the following table, respectively: first and the second column of the following table, respectively:
+------------+------------+------------+----------------------------+ +------------+-----------+------------+-----------------------+
| 1: Address | 2: Prefix | 3: MUST do | 4: SHOULD do further | | 1: Address | 2: Prefix | 3: MUST do | 4: SHOULD do further |
| Type AT | Length L | 1st lookup | lookups in that order | | Type AT | Length L | 1st lookup | lookups in that order |
+------------+------------+------------+----------------------------+ +============+===========+============+=======================+
| IPv4 | 32 | R32 | R24, R16, R8 | | IPv4 | 32 | R32 | R24, R16, R8 |
| IPv4 | 24 .. 31 | R24 | R16, R8 | +------------+-----------+------------+-----------------------+
| IPv4 | 16 .. 23 | R16 | R8 | | IPv4 | 24 .. 31 | R24 | R16, R8 |
| IPv4 | 8 .. 15 | R8 | (none) | +------------+-----------+------------+-----------------------+
| IPv4 | 0 .. 7 | (none, abort: unsupported prefix length)| | IPv4 | 16 .. 23 | R16 | R8 |
+------------+------------+------------+----------------------------+ +------------+-----------+------------+-----------------------+
| IPv6 | 128 | R128 | R64, R56, R48, R40, R32 | | IPv4 | 8 .. 15 | R8 | (none) |
| IPv6 | 64 (..127) | R64 | R56, R48, R40, R32 | +------------+-----------+------------+-----------------------+
| IPv6 | 56 .. 63 | R56 | R48, R40, R32 | | IPv4 | 0 .. 7 | (none, abort: unsupported prefix |
| IPv6 | 48 .. 55 | R48 | R40, R32 | | | | length) |
| IPv6 | 40 .. 47 | R40 | R32 | +------------+-----------+------------+-----------------------+
| IPv6 | 32 .. 39 | R32 | (none) | | IPv6 | 128 | R128 | R64, R56, R48, R40, |
| IPv6 | 0 .. 31 | (none, abort: unsupported prefix length)| | | | | 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
Then, the domain name given in the 3rd column and the U-NAPTR Service Then, the domain name given in the 3rd column and the U-NAPTR Service
Parameter SP the procedure was called with (usually "ALTO:https") Parameter SP with which the procedure was called (usually
MUST be used for an U-NAPTR [RFC4848] lookup, in order to obtain one "ALTO:https") MUST be used for a U-NAPTR [RFC4848] lookup, in order
or more URIs (indicating protocol, host, and possibly path elements) to obtain one or more URIs (indicating protocol, host, and possibly
for the ALTO server's Information Resource Directory (IRD). If such path elements) for the ALTO server's Information Resource Directory
URI(s) can be found, the ALTO Cross-Domain Server Discovery Procedure (IRD). If such URIs can be found, the ALTO Cross-Domain Server
returns that information to the caller and terminates successfully. Discovery Procedure returns that information to the caller and
terminates successfully.
For example, the following two U-NAPTR resource records can be used 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 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" the previous step) to the HTTPS URIs "https://alto1.example.net/ird"
and "https://alto2.example.net/ird", with the former being preferred. and "https://alto2.example.net/ird", with the former being preferred.
100.51.198.IN-ADDR.ARPA. IN NAPTR 100 10 "u" "ALTO:https" 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://alto1.example.net/ird!" "" "!.*!https://alto1.example.net/ird!" ""
100.51.198.IN-ADDR.ARPA. IN NAPTR 100 20 "u" "ALTO:https" 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 20 "u" "ALTO:https"
"!.*!https://alto2.example.net/ird!" "" "!.*!https://alto2.example.net/ird!" ""
If no matching U-NAPTR records can be found, the procedure SHOULD try 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 further lookups, using the domain names from the fourth column in the
indicated order, until one lookup succeeds. If no IRD URI could be indicated order, until one lookup succeeds. If no IRD URI can be
found after looking up all domain names from the 3rd and 4th column, found after looking up all domain names from the 3rd and 4th columns,
the procedure terminates unsuccessfully, returning an empty URI list. the procedure terminates unsuccessfully, returning an empty URI list.
3.5. Error Handling 3.5. Error Handling
The ALTO Cross-Domain Server Discovery Procedure may fail for several The ALTO Cross-Domain Server Discovery Procedure may fail for several
reasons. reasons.
If the procedure is called with syntactically invalid parameters or If the procedure is called with syntactically invalid parameters or
unsupported parameter values (in particular the prefix length L, see unsupported parameter values (in particular, the prefix length L; see
Section 3.2), the procedure aborts, no URI list will be returned and Section 3.2), the procedure aborts, no URI list will be returned, and
the error has to be reported to the caller. the error has to be reported to the caller.
The procedure performs one or more DNS lookups in a well-defined The procedure performs one or more DNS lookups in a well-defined
order (corresponding to descending prefix lengths, see Section 3.4), order (corresponding to descending prefix lengths, see Section 3.4)
until one produces a usable result. Each of these DNS lookups might until one produces a usable result. Each of these DNS lookups might
not produce a usable result, either due to a normal condition (e.g., fail to produce a usable result, due to either a normal condition
domain name exists, but no ALTO-specific NAPTR resource records are (e.g., a domain name exists, but no ALTO-specific NAPTR resource
associated with it), a permanent error (e.g., non-existent domain records are associated with it), a permanent error (e.g., nonexistent
name), or due to a temporary error (e.g., timeout). In all three 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 cases, and as long as there are further domain names that can be
looked up, the procedure SHOULD immediately try to lookup the next 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 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 after all domain names have been tried at least once, the procedure
MAY retry those domain names that had caused temporary lookup errors. MAY retry those domain names that had caused temporary lookup errors.
Generally speaking, ALTO provides advisory information for the Generally speaking, ALTO provides advisory information for the
optimization of applications (e.g., peer-to-peer applications, optimization of applications (peer-to-peer applications, overlay
overlay networks, etc.), but applications should not rely on the networks, etc.), but applications should not rely on the availability
availability of such information for their basic functionality (see of such information for their basic functionality (see
Section 8.3.4.3 of RFC 7285 [RFC7285]). Consequently, the speedy Section 8.3.4.3 of [RFC7285]). Consequently, the speedy detection of
detection of an ALTO server, even though it may give less accurate an ALTO server, even though it may give less accurate answers than
answers than other servers, or the quick realization that there is no other servers, or the quick realization that there is no suitable
suitable ALTO server, is in general more preferable than causing long ALTO server, is in general preferable to causing long delays by
delays by retrying failed queries. Nevertheless, the ALTO Cross- retrying failed queries. Nevertheless, if DNS queries have failed
Domain Server Discovery Procedure SHOULD inform its caller, if DNS due to temporary errors, the ALTO Cross-Domain Server Discovery
queries have failed due to temporary errors and that retrying the Procedure SHOULD inform its caller that DNS queries have failed for
discovery at a later point in time might give more accurate results. that reason and that retrying the discovery at a later point in time
might give more accurate results.
4. Using the ALTO Protocol with Cross-Domain Server Discovery 4. Using the ALTO Protocol with Cross-Domain Server Discovery
Based on a modular design principle, ALTO provides several ALTO Based on a modular design principle, ALTO provides several ALTO
services, each consisting of a set of information resouces that can services, each consisting of a set of information resources that can
be accessed using the ALTO protocol. The information resources that be accessed using the ALTO protocol. The information resources that
are available at a specific ALTO server are listed in its Information are available at a specific ALTO server are listed in its Information
Resource Directory (IRD, see Section 9 of [RFC7285]). The ALTO Resource Directory (IRD, see Section 9 of [RFC7285]). The ALTO
protocol specification defines the following ALTO services and their protocol specification defines the following ALTO services and their
corresponding information resouces: corresponding information resources:
o Network and Cost Map Service, see Section 11.2 of [RFC7285] * Network and Cost Map Service, see Section 11.2 of [RFC7285]
o Map-Filtering Service, see Section 11.3 of [RFC7285] * Map-Filtering Service, see Section 11.3 of [RFC7285]
o Endpoint Property Service, see Section 11.4 of [RFC7285] * Endpoint Property Service, see Section 11.4 of [RFC7285]
o Endpoint Cost Service, see Section 11.5 of [RFC7285] * Endpoint Cost Service, see Section 11.5 of [RFC7285]
The ALTO Cross-Domain Server Discovery Procedure is most useful in The ALTO Cross-Domain Server Discovery Procedure is most useful in
conjunction with the Endpoint Property Service and the Endpoint Cost conjunction with the Endpoint Property Service and the Endpoint Cost
Service. However, for the sake of completeness, possible interaction Service. However, for the sake of completeness, possible interaction
with all four services is discussed below. Extension documents may with all four services is discussed below. Extension documents may
specify further information resources; however, these are out of specify further information resources; however, these are out of
scope of this document. scope of this document.
4.1. Network and Cost Map Service 4.1. Network and Cost Map Service
An ALTO client may invoke the ALTO Cross-Domain Server Discovery An ALTO client may invoke the ALTO Cross-Domain Server Discovery
Procedure (as specified in Section 3) for an IP address or prefix "X" Procedure (as specified in Section 3) for an IP address or prefix X
and get a list of one or more IRD URI(s), including order and 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) preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The IRD(s)
referenced by these URI(s) will always contain a network and a cost referenced by these URIs will always contain a network and a cost
map, as these are mandatory information resources (see Section 11.2 map, as these are mandatory information resources (see Section 11.2
of [RFC7285]). However, the cost matrix may be very sparse. If, of [RFC7285]). However, the cost matrix may be very sparse. If,
according to the network map, PID_X is the PID that contains the IP according to the network map, PID_X is the Provider-defined
address or prefix X, and PID_1, PID_2, PID_3, ... are other PIDS, the 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: cost map may look like this:
From \ To PID_1 PID_2 PID_X PID_3 +-------+----------+-------+-------+-------+
------+----------------------------------- | From | To PID_1 | PID_2 | PID_X | PID_3 |
PID_1 | 92 +=======+==========+=======+=======+=======+
PID_2 | 6 | PID_1 | | | 92 | |
PID_X | 46 3 1 19 +-------+----------+-------+-------+-------+
PID_3 | 38 | PID_2 | | | 6 | |
+-------+----------+-------+-------+-------+
| PID_X | 46 | 3 | 1 | 19 |
+-------+----------+-------+-------+-------+
| PID_3 | | | 38 | |
+-------+----------+-------+-------+-------+
In this example, all cells outside column "X" and row "X" are Table 2: Cost Map
In this example, all cells outside Column X and Row X are
unspecified. A cost map with this structure contains the same unspecified. A cost map with this structure contains the same
information as what could be retrieved using the Endpoint Cost information as what could be retrieved using the Endpoint Cost
Service, cases 1 and 2 in Section 4.4. Accessing cells that are 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. neither in Column X nor Row X may not yield useful results.
Trying to assemble a more densely populated cost map from several Trying to assemble a more densely populated cost map from several
cost maps with this very sparse structure may be a non-trivial task, cost maps with this very sparse structure may be a nontrivial task,
as different ALTO servers may use different PID definitions (i.e., as different ALTO servers may use different PID definitions (i.e.,
network maps) and incompatible scales for the costs, in particular network maps) and incompatible scales for the costs, in particular
for the "routingcost" metric. for the "routingcost" metric.
4.2. Map-Filtering Service 4.2. Map-Filtering Service
An ALTO client may invoke the ALTO Cross-Domain Server Discovery An ALTO client may invoke the ALTO Cross-Domain Server Discovery
Procedure (as specified in Section 3) for an IP address or prefix "X" Procedure (as specified in Section 3) for an IP address or prefix X
and get a list of one or more IRD URI(s), including order and and get a list of one or more IRD URIs, including order and
preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These IRDs
IRD(s) may provide the optional Map-Filtering Service (see Section may provide the optional Map-Filtering Service (see Section 11.3 of
11.3 of [RFC7285]). This service returns a subset of the full map, [RFC7285]). This service returns a subset of the full map, as
as specified by the client. As discussed in Section 4.1, a cost map specified by the client. As discussed in Section 4.1, a cost map may
may be very sparse in the envisioned deployment scenario. Therefore, be very sparse in the envisioned deployment scenario. Therefore,
depending on the filtering criteria provided by the client, this depending on the filtering criteria provided by the client, this
service may return results similar to the Endpoint Cost Service, or service may return results similar to the Endpoint Cost Service, or
it may not return any useful result. it may not return any useful result.
4.3. Endpoint Property Service 4.3. Endpoint Property Service
If an ALTO client wants to query an Endpoint Property Service (see If an ALTO client wants to query an Endpoint Property Service (see
Section 11.4 of RFC 7285 [RFC7285]) about an endpoint with IP address Section 11.4 of [RFC7285]) about an endpoint with IP address X or a
"X" or a group of endpoints within IP prefix "X", respectively, it group of endpoints within IP prefix X, respectively, it has to invoke
has to invoke the ALTO Cross-Domain Server Discovery Procedure (as the ALTO Cross-Domain Server Discovery Procedure (as specified in
specified in Section 3): IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The Section 3): IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The result,
result IRD_URIS_X is a list of one or more URIs of Information IRD_URIS_X, is a list of one or more URIs of Information Resource
Resource Directories (IRD, see Section 9 of [RFC7285]). Considering Directories (IRDs, see Section 9 of [RFC7285]). Considering the
the order and preference values, the client has to check these IRDs order and preference values, the client has to check these IRDs for a
for a suitable Endpoint Property Service and query it. suitable Endpoint Property Service and query it.
If the ALTO client wants to do a similar Endpoint Property query for 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 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 repeated, as IRD_URIS_Y = XDOMDISC(Y,"ALTO:https") may yield a
different list of IRD URIs. Of course, the results of individual DNS different list of IRD URIs. Of course, the results of individual DNS
queries may be cached as indicated by their respective time-to-live queries may be cached as indicated by their respective time-to-live
(TTL) values. (TTL) values.
4.4. Endpoint Cost Service 4.4. Endpoint Cost Service
The optional ALTO Endpoint Cost Service (ECS, see Section 11.5 of RFC The optional ALTO Endpoint Cost Service (ECS; see Section 11.5 of
7285 [RFC7285]) provides information about costs between individual [RFC7285]) provides information about costs between individual
endpoints and it also supports ranking. The ECS allows that endpoints and also supports ranking. The ECS allows endpoints to be
endpoints may be denoted by IP addresses or prefixes. The ECS is denoted by IP addresses or prefixes. The ECS is called with a list
called with a list of one or more source IP addresses or prefixes, of one or more source IP addresses or prefixes, which we will call
which we will call (S1, S2, S3, ...), and a list of one or more (S1, S2, S3, ...), and a list of one or more destination IP addresses
destination IP addresses or prefixes, called (D1, D2, D3, ...). or prefixes, called (D1, D2, D3, ...).
This specification distinguishes several cases, regarding the number This specification distinguishes several cases, regarding the number
of elements in the list of source and destination addresses, of elements in the list of source and destination addresses,
respectively: respectively:
1. Exactly one source address S1 and more than one destination 1. Exactly one source address S1 and more than one destination
addresses D1, D2, D3, ... In this case, the ALTO client has to addresses (D1, D2, D3, ...). In this case, the ALTO client has
invoke the ALTO Cross-Domain Server Discovery Procedure (as to invoke the ALTO Cross-Domain Server Discovery Procedure (as
specified in Section 3) with that single source address as a specified in Section 3) with that single source address as a
parameter: IRD_URIS_S1 = XDOMDISC(S1,"ALTO:https"). The result parameter: IRD_URIS_S1 = XDOMDISC(S1,"ALTO:https"). The result,
IRD_URIS_S1 is a list of one or more URIs of Information Resource IRD_URIS_S1, is a list of one or more URIs of Information
Directories (IRD, see Section 9 of [RFC7285]). Considering the Resource Directories (IRDs, see Section 9 of [RFC7285]).
order and preference values, the client has to check these IRDs Considering the order and preference values, the client has to
for a suitable Endpoint Cost Service and query it. The ECS is an check these IRDs for a suitable Endpoint Cost Service and query
optional service (see Section 11.5.1 of RFC 7285 [RFC7285]) and it. The ECS is an optional service (see Section 11.5.1 of
therefore, it may well be that an IRD does not refer to an ECS. [RFC7285]), and therefore, it may well be that an IRD does not
refer to an ECS.
Calling the Cross-Domain Server Discovery Procedure only once Calling the Cross-Domain Server Discovery Procedure only once
with the single source address as a parameter - as opposed to with the single source address as a parameter -- as opposed to
multiple calls, e.g., one for each destination address - is not multiple calls, e.g., one for each destination address -- is not
only a matter of efficiency. In the given scenario, it is only a matter of efficiency. In the given scenario, it is
advisable to send all ECS queries to the same ALTO server. This advisable to send all ECS queries to the same ALTO server. This
ensures that the results can be compared (e.g., for sorting ensures that the results can be compared (e.g., for sorting
candidate resource providers), even with cost metrics without a candidate resource providers), even when cost metrics lack a
well-defined base unit, e.g., the "routingcost" metric. well-defined base unit -- e.g., the "routingcost" metric.
2. More than one source addresses S1, S2, S3, ... and exactly one 2. More than one source address (S1, S2, S3, ...) and exactly one
destination address D1. In this case, the ALTO client has to destination address D1. In this case, the ALTO client has to
invoke the ALTO Cross-Domain Server Discovery Procedure with that invoke the ALTO Cross-Domain Server Discovery Procedure with that
single destination address as a parameter: single destination address as a parameter:
IRD_URIS_D1 = XDOMDISC(D1,"ALTO:https"). The result IRD_URIS_D1 IRD_URIS_D1 = XDOMDISC(D1,"ALTO:https"). The result,
is a list of one or more URIs of IRDs. Considering the order and IRD_URIS_D1, is a list of one or more URIs of IRDs. Considering
preference values, the client has to check these IRDs for a the order and preference values, the client has to check these
suitable ECS and query it. IRDs for a suitable ECS and query it.
3. Exactly one source address S1 and exactly one destination address 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 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 specified above. As an alternative, it may also perform the same
steps as in case 2, as specified above. steps as in Case 2, as specified above.
4. More than one source addresses S1, S2, S3, ... and more than one 4. More than one source address (S1, S2, S3, ...) and more than one
destination addresses D1, D2, D3, ... In this case, the ALTO destination address (D1, D2, D3, ...). In this case, the ALTO
client should split the list of desired queries based on source client should split the list of desired queries based on source
addresses and perform separately for each source address the same addresses and perform separately for each source address the same
steps as in case 1, as specified above. As an alternative, the steps as in Case 1, as specified above. As an alternative, the
ALTO client may also group the list based on destination ALTO client may also group the list based on destination
addresses and perform separately for each destination address the addresses and perform separately for each destination address the
same steps as in case 2, as specified above. However, comparing same steps as in Case 2, as specified above. However, comparing
results between these sub-queries may be difficult, in particular results between these subqueries may be difficult, in particular
if the cost metric is a relative preference without a well- if the cost metric is a relative preference without a well-
defined base unit (e.g., the "routingcost" metric). defined base unit (e.g., the "routingcost" metric).
See Appendix C for a detailed example showing the interaction of a See Appendix C for a detailed example showing the interaction of a
tracker-based peer-to-peer application, the ALTO Endpoint Cost tracker-based peer-to-peer application, the ALTO Endpoint Cost
Service, and the ALTO Cross-Domain Server Discovery Procedure. Service, and the ALTO Cross-Domain Server Discovery Procedure.
4.5. Summary and Further Extensions 4.5. Summary and Further Extensions
Considering the four services defined in the ALTO base protocol Considering the four services defined in the ALTO base protocol
specification [RFC7285], the ALTO Cross-Domain Server Discovery specification [RFC7285], the ALTO Cross-Domain Server Discovery
Procedure works best with the Endpoint Property Service (EPS) and the Procedure works best with the Endpoint Property Service (EPS) and the
Endpoint Cost Service (ECS). Both the EPS and the ECS take one or Endpoint Cost Service (ECS). Both the EPS and the ECS take one or
more IP addresses as a parameter. The previous sections specify how more IP addresses as a parameter. The previous sections specify how
the parameter for calling the ALTO Cross-Domain Server Discovery the parameter for calling the ALTO Cross-Domain Server Discovery
Procedure has to be derived from these IP adresses. Procedure has to be derived from these IP addresses.
In contrast, the ALTO Cross-Domain Server Discovery Procedure seems In contrast, the ALTO Cross-Domain Server Discovery Procedure seems
less useful if the goal is to retrieve network and cost maps that less useful if the goal is to retrieve network and cost maps that
cover the whole network topology. However, the procedure may be 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 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 map detailing the vicinity of said IP address or a map giving costs
from said IP address to all potential destinations). from said IP address to all potential destinations).
The interaction between further ALTO services (and their The interaction between further ALTO services (and their
corresponding information resources) needs to be investigated and corresponding information resources) needs to be investigated and
defined once such further ALTO services are specified in an extension defined once such further ALTO services are specified in an extension
document. document.
5. Implementation, Deployment, and Operational Considerations 5. Implementation, Deployment, and Operational Considerations
5.1. Considerations for ALTO Clients 5.1. Considerations for ALTO Clients
5.1.1. Resource Consumer Initiated Discovery 5.1.1. Resource-Consumer-Initiated Discovery
Resource consumer initiated ALTO server discovery (c.f. ALTO Resource-consumer-initiated ALTO server discovery (cf. ALTO
requirement AR-32 [RFC6708]) can be seen as a special case of cross- requirement AR-32 [RFC6708]) can be seen as a special case of cross-
domain ALTO server discovery. To that end, an ALTO client embedded domain ALTO server discovery. To that end, an ALTO client embedded
in a resource consumer would have to perform the ALTO Cross-Domain in a resource consumer would have to perform the ALTO Cross-Domain
Server Discovery Procedure with its own IP address as a parameter. Server Discovery Procedure with its own IP address as a parameter.
However, due to the widespread deployment of Network Address However, due to the widespread deployment of Network Address
Translators (NAT), additional protocols and mechanisms such as STUN Translators (NATs), additional protocols and mechanisms such as
[RFC5389] are usually needed to detect the client's "public" IP Session Traversal Utilities for NAT (STUN) [RFC5389] are usually
address, before it can be used as a parameter to the discovery needed to detect the client's "public" IP address before it can be
procedure. Note that a different approach for resource consumer used as a parameter for the discovery procedure. Note that a
initiated ALTO server discovery, which is based on DHCP, is specified different approach for resource-consumer-initiated ALTO server
in [RFC7286]. discovery, which is based on DHCP, is specified in [RFC7286].
5.1.2. IPv4/v6 Dual Stack, Multihoming and Host Mobility 5.1.2. IPv4/v6 Dual Stack, Multihoming and Host Mobility
The procedure specified in this document can discover ALTO server The procedure specified in this document can discover ALTO server
URIs for a given IP address or prefix. The intention is, that a URIs for a given IP address or prefix. The intention is that a third
third party (e.g., a resource directory) that receives query messages party (e.g., a resource directory) that receives query messages from
from a resource consumer can use the source address in these messages a resource consumer can use the source address in these messages to
to discover suitable ALTO servers for this specific resource discover suitable ALTO servers for this specific resource consumer.
consumer.
However, resource consumers (as defined in Section 2 of [RFC5693]) However, resource consumers (as defined in Section 2 of [RFC5693])
may reside on hosts with more than one IP address, e.g., due to may reside on hosts with more than one IP address -- for example, due
IPv4/v6 dual stack operation and/or multihoming. IP packets sent to IPv4/v6 dual stack operation and/or multihoming. IP packets sent
with different source addresses may be subject to different routing with different source addresses may be subject to different routing
policies and path costs. In some deployment scenarios, it may even policies and path costs. In some deployment scenarios, it may even
be required to ask different sets of ALTO servers for guidance. be required to ask different sets of ALTO servers for guidance.
Furthermore, source addresses in IP packets may be modified en-route Furthermore, source addresses in IP packets may be modified en route
by Network Address Translators (NAT). by Network Address Translators (NATs).
If a resource consumer queries a resource directory for candidate If a resource consumer queries a resource directory for candidate
resource providers, the locally selected (and possibly en-route resource providers, the locally selected (and possibly en-route-
translated) source address of the query message - as observed by the translated) source address of the query message -- as observed by the
resource directory - will become the basis for the ALTO server resource directory -- will become the basis for the ALTO server
discovery and the subsequent optimization of the resource directory's discovery and the subsequent optimization of the resource directory's
reply. If, however, the resource consumer then selects different reply. If, however, the resource consumer then selects different
source addresses to contact returned resource providers, the desired source addresses to contact returned resource providers, the desired
better-than-random "ALTO effect" may not occur. better-than-random "ALTO effect" may not occur.
One solution approach for this problem is, that a dual stack or One solution approach for this problem is that a dual-stack or
multihomed resource consumer could always use the same address for multihomed resource consumer could always use the same address for
contacting the resource directory and all resource providers, thus contacting the resource directory and all resource providers, thus
overriding the operating system's automatic source IP address overriding the operating system's automatic selection of source IP
selection. For example, when using the BSD socket API, one could addresses. For example, when using the BSD socket API, one could
always bind() the socket to one of the local IP addresses before always bind() the socket to one of the local IP addresses before
trying to connect() to the resource directory or the resource trying to connect() to the resource directory or the resource
providers, respectively. Another solution approach is to perform providers, respectively. Another solution approach is to perform
ALTO-influenced resource provider selection (and source address ALTO-influenced resource provider selection (and source-address
selection) locally in the resource consumer, in addition to or selection) locally in the resource consumer, in addition to, or
instead of performing it in the resource directory. See instead of, performing it in the resource directory. See
Section 5.1.1 for a discussion how to discover ALTO servers for local Section 5.1.1 for a discussion of how to discover ALTO servers for
usage in the resource consumer. local usage in the resource consumer.
Similarly, resource consumers on mobile hosts SHOULD query the Similarly, resource consumers on mobile hosts SHOULD query the
resource directory again after a change of IP address, in order to resource directory again after a change of IP address, in order to
get a list of candidate resource providers that is optimized for the get a list of candidate resource providers that is optimized for the
new IP address. new IP address.
5.1.3. Interaction with Network Address Translation 5.1.3. Interaction with Network Address Translation
The ALTO Cross-Domain Server Discovery Procedure has been designed to The ALTO Cross-Domain Server Discovery Procedure has been designed to
enable the ALTO-based optimization of applications such as large- enable the ALTO-based optimization of applications such as large-
scale overlay networks, that span - on the IP layer - multiple scale overlay networks, that span -- on the IP layer -- multiple
adminstrative domains, possibly the whole Internet. Due to the administrative domains, possibly the whole Internet. Due to the
widespread usage of Network Address Translators (NAT) it may well be widespread usage of Network Address Translators (NATs), it may well
that nodes of the overlay network (i.e., resource consumers or be that nodes of the overlay network (i.e., resource consumers or
resource providers) are located behind a NAT, maybe even behind resource providers) are located behind a NAT, maybe even behind
several cascaded NATs. several cascaded NATs.
If a resource directory is located in the public Internet (i.e., not If a resource directory is located in the public Internet (i.e., not
behind a NAT) and if it receives a message from a resource consumer behind a NAT) and receives a message from a resource consumer behind
behind one or more NATs, the message's source address will be the one or more NATs, the message's source address will be the public IP
public IP address of the outermost NAT in front of the resource address of the outermost NAT in front of the resource consumer. The
consumer. The same applies if the resource directory is behind a same applies if the resource directory is behind a different NAT than
different NAT than the resource consumer. The resource directory may the resource consumer. The resource directory may call the ALTO
call the ALTO Cross-Domain Server Discovery Procedure with the Cross-Domain Server Discovery Procedure with the message's source
message's source address as a parameter. In effect, not the resource address as a parameter. In effect, not the resource consumer's
consumer's (private) IP address, but the public IP address of the (private) IP address, but the public IP address of the outermost NAT
outermost NAT in front of it will be used as a basis for ALTO- in front of it, will be used as a basis for ALTO optimization. This
optimization. This will work fine as long as the network behind the will work fine as long as the network behind the NAT is not too big
NAT is not too big (e.g., if the NAT is in a residential gateway). (e.g., if the NAT is in a residential gateway).
If a resource directory receives a message from a resource consumer If a resource directory receives a message from a resource consumer
and the message's source address is a "private" IP address [RFC1918], 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 this may be a sign that both of them are behind the same NAT. An
invokation of the ALTO Cross-Domain Server Discovery Procedure with invocation of the ALTO Cross-Domain Server Discovery Procedure with
this private address may be problematic, as this will only yield this private address may be problematic, as this will only yield
usable results if a DNS "split horizon" and DNSSEC trust anchors are usable results if a DNS "split horizon" and DNSSEC trust anchors are
configured correctly. In this situation it may be more advisable to configured correctly. In this situation, it may be more advisable to
query an ALTO server that has been discovered using [RFC7286] or any query an ALTO server that has been discovered using [RFC7286] or any
other local configuration. The interaction between intra-domain ALTO other local configuration. The interaction between intradomain ALTO
for large private domains (e.g., behind a "carrier-grade NAT") and for large private domains (e.g., behind a "carrier-grade NAT") and
cross-domain, Internet-wide optimization, is beyond the scope of this cross-domain, Internet-wide optimization, is beyond the scope of this
document. document.
5.2. Considerations for Network Operators 5.2. Considerations for Network Operators
5.2.1. Flexibility vs. Load on the DNS 5.2.1. Flexibility vs. Load on the DNS
The ALTO Cross-Domain Server Discovery Procedure, as specified in The ALTO Cross-Domain Server Discovery Procedure, as specified in
Section 3, first produces a list of domain names (steps 1 and 2) and Section 3, first produces a list of domain names (Steps 1 and 2) and
then looks for relevant NAPTR records associated with these names, then looks for relevant NAPTR records associated with these names,
until a useful result can be found (step 3). The number of candidate until a useful result can be found (Step 3). The number of candidate
domain names on this list is a compromise between flexibility when domain names on this list is a compromise between flexibility when
installing NAPTR records and avoiding excess load on the DNS. installing NAPTR records and avoiding excess load on the DNS.
A single invocation of the ALTO Cross-Domain Server Discovery A single invocation of the ALTO Cross-Domain Server Discovery
Procedure, with an IPv6 address as a parameter, may cause up to, but 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 no more than, six DNS lookups for NAPTR records. For IPv4, the
maximum is four lookups. Should the load on the DNS infrastructure maximum is four lookups. Should the load on the DNS infrastructure
caused by these lookups become a problem, one solution approach is to caused by these lookups become a problem, one solution approach is to
actually populate the DNS with ALTO-specific NAPTR records. If such populate the DNS with ALTO-specific NAPTR records. If such records
records can be found for individual IP addresses (possibly installed can be found for individual IP addresses (possibly installed using a
using a wildcarding mechanism in the name server) or for long wildcarding mechanism in the name server) or long prefixes, the
prefixes, the procedure will terminate successfully and not perform procedure will terminate successfully and not perform lookups for
lookups for shorter prefix lengths, thus reducing the total number of shorter prefix lengths, thus reducing the total number of DNS
DNS queries. Another approach for reducing the load on the DNS queries. Another approach for reducing the load on the DNS
infrastructure is to increase the TTL for caching negative answers. infrastructure is to increase the TTL for caching negative answers.
On the other hand, the ALTO Cross-Domain Server Discovery Procedure On the other hand, the ALTO Cross-Domain Server Discovery Procedure
trying to lookup truncated domain names allows for efficient trying to look up truncated domain names allows for efficient
configuration of large-scale scenarios, where discovery is to be configuration of large-scale scenarios, where discovery is to be
enabled for a large number of IP addresses with a small number of enabled for a large number of IP addresses with a small number of
additional DNS resource records. Note that expressly, it has not additional DNS resource records. Note that it expressly has not been
been a design goal of this procedure to give clients a means to a design goal of this procedure to give clients a means of
understand the IP prefix delegation structure. Furthermore, this understanding the IP prefix delegation structure. Furthermore, this
specification does not assume or reccomend that prefix delegations specification does not assume or recommend that prefix delegations
should preferrably occur at those prefix lengths that are used in should preferably occur at those prefix lengths that are used in Step
Step 2 of this procedure (see Section 3.3). A network operator that 2 of this procedure (see Section 3.3). A network operator that uses,
uses, for example, an IPv4 /18 prefix and wants to install the NAPTR for example, an IPv4 /18 prefix and wants to install the NAPTR
records efficiently, could either install 64 NAPTR records (one for records efficiently could either install 64 NAPTR records (one for
each of the /24 prefixes contained within the /18 prefix), or they 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 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 enclosing /16 prefix, in order to run a common ALTO server to which
only one NAPTR would point. only one NAPTR would point.
5.2.2. BCP20 and missing delegations of the reverse DNS 5.2.2. BCP 20 and Missing Delegations of the Reverse DNS
RFC2317 [RFC2317], also known as BCP20, describes a way to delegate [RFC2317], also known as BCP 20, describes a way to delegate the
the "reverse DNS" (i.e., subdomains of in-addr.arpa.) for IPv4 "reverse DNS" (i.e., subdomains of "in-addr.arpa.") for IPv4 address
address ranges with fewer than 256 addresses (i.e., less than a whole ranges with fewer than 256 addresses (i.e., less than a whole /24
/24 prefix). The ALTO Cross-Domain Server Discovery procedure is prefix). The ALTO Cross-Domain Server Discovery Procedure is
compatible with this method. compatible with this method.
In some deployment scenarios, e.g., residential Internet access, In some deployment scenarios -- e.g., residential Internet access --
where customers often dynamically receive a single IPv4 address where customers often dynamically receive a single IPv4 address (and/
(and/or a small IPv6 address block) from a pool of addresses, ISPs or a small IPv6 address block) from a pool of addresses, ISPs
typically will not delegate the "reverse DNS" to their customers. typically will not delegate the "reverse DNS" to their customers.
This practice makes it impossible for these customers to populate the This practice makes it impossible for these customers to populate the
DNS with NAPTR resource records that point to an ALTO server of their DNS with NAPTR resource records that point to an ALTO server of their
choice. Yet, the ISP may publish NAPTR resource records in the choice. Yet, the ISP may publish NAPTR resource records in the
"reverse DNS" for individual addresses or larger address pools (i.e., "reverse DNS" for individual addresses or larger address pools (i.e.,
shorter prefix lengths). shorter prefix lengths).
While ALTO is by no means technologically tied to the Border Gateway While ALTO is by no means technologically tied to the Border Gateway
Protocol (BGP), it is anticipated that BGP will be an important Protocol (BGP), it is anticipated that BGP will be an important
source of information for ALTO and that the operator of the outermost source of information for ALTO and that the operator of the outermost
BGP-enabled router will have a strong incentive to publish a digest BGP-enabled router will have a strong incentive to publish a digest
of their routing policies and costs through ALTO. In contrast, an of their routing policies and costs through ALTO. In contrast, an
individual user or an organization that has been assigned only a individual user or an organization that has been assigned only a
small address range (i.e., an IPv4 prefix with a prefix length longer 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 than /24) will typically connect to the Internet using only a single
ISP, and they might not be interested in publishing their own ALTO ISP, and they might not be interested in publishing their own ALTO
information. Consequently, they might wish to leave the operation of information. Consequently, they might wish to leave the operation of
an ALTO server up to their ISP. This ISP may install NAPTR resource an ALTO server up to their ISP. This ISP may install NAPTR resource
records, which are needed for the ALTO Cross-Domain Server Discovery records, which are needed for the ALTO Cross-Domain Server Discovery
procedure, in the subdomain of in-addr.arpa. that corresponds to the Procedure, in the subdomain of "in-addr.arpa." that corresponds to
whole /24 prefix (c.f., R24 in Section 3.3 of this document), even if the whole /24 prefix (cf. R24 in Section 3.3 of this document), even
BCP20-style delegations or no delegations at all are in use. if delegations in the style of BCP 20 or no delegations at all are in
use.
6. Security Considerations 6. Security Considerations
A high-level discussion of security issues related to ALTO is part of A high-level discussion of security issues related to ALTO is part of
the ALTO problem statement [RFC5693]. A classification of unwanted the ALTO problem statement [RFC5693]. A classification of unwanted
information disclosure risks, as well as specific security-related information disclosure risks, as well as specific security-related
requirements can be found in the ALTO requirements document requirements, can be found in the ALTO requirements document
[RFC6708]. [RFC6708].
The remainder of this section focuses on security threats and The remainder of this section focuses on security threats and
protection mechanisms for the cross-domain ALTO server discovery protection mechanisms for the Cross-Domain ALTO Server Discovery
procedure as such. Once the ALTO server's URI has been discovered Procedure as such. Once the ALTO server's URI has been discovered,
and the communication between the ALTO client and the ALTO server and the communication between the ALTO client and the ALTO server
starts, the security threats and protection mechanisms discussed in starts, the security threats and protection mechanisms discussed in
the ALTO protocol specification [RFC7285] apply. the ALTO protocol specification [RFC7285] apply.
6.1. Integrity of the ALTO Server's URI 6.1. Integrity of the ALTO Server's URI
Scenario Description Scenario Description
An attacker could compromise the ALTO server discovery procedure An attacker could compromise the ALTO server discovery procedure
or the underlying infrastructure in a way that ALTO clients would or the underlying infrastructure in such a way that ALTO clients
discover a "wrong" ALTO server URI. would discover a "wrong" ALTO server URI.
Threat Discussion Threat Discussion
The cross-domain ALTO server discovery procedure relies on a The Cross-Domain ALTO Server Discovery Procedure relies on a
series of DNS lookups, in order to produce one or more URI(s). If series of DNS lookups, in order to produce one or more URIs. If
an attacker was able to modify or spoof any of the DNS records, an attacker were able to modify or spoof any of the DNS records,
the resulting URI(s) could be replaced by forged URI(s). This is the resulting URIs could be replaced by forged URIs. This is
probably the most serious security concern related to ALTO server probably the most serious security concern related to ALTO server
discovery. The discovered "wrong" ALTO server might not be able discovery. The discovered "wrong" ALTO server might not be able
to give guidance to a given ALTO client at all, or it might give to give guidance to a given ALTO client at all, or it might give
suboptimal or forged information. In the latter case, an attacker suboptimal or forged information. In the latter case, an attacker
could try to use ALTO to affect the traffic distribution in the could try to use ALTO to affect the traffic distribution in the
network or the performance of applications (see also Section 15.1. network or the performance of applications (see also Section 15.1
of [RFC7285]). Furthermore, a hostile ALTO server could threaten of [RFC7285]). Furthermore, a hostile ALTO server could threaten
user privacy (see also Section 5.2.1, case (5a) in [RFC6708]). user privacy (see also Case (5a) in Section 5.2.1 of [RFC6708]).
Protection Strategies and Mechanisms Protection Strategies and Mechanisms
The application of DNS security (DNSSEC) [RFC4033] provides a The application of DNS security (DNSSEC) [RFC4033] provides a
means to detect and avert attacks that rely on modification of the means of detecting and averting attacks that rely on modification
DNS records while in transit. All implementations of the cross- of the DNS records while in transit. All implementations of the
domain ALTO server discovery procedure MUST support DNSSEC or be Cross-Domain ALTO Server Discovery Procedure MUST support DNSSEC
able to use such functionality provided by the underlying or be able to use such functionality provided by the underlying
operating system. Network operators that publish U-NAPTR resource operating system. Network operators that publish U-NAPTR resource
records to be used for the cross-domain ALTO server discovery records to be used for the Cross-Domain ALTO Server Discovery
procedure SHOULD use DNSSEC to protect their subdomains of in- Procedure SHOULD use DNSSEC to protect their subdomains of "in-
addr.arpa. and/or ip6.arpa., respectively. Additional operational addr.arpa." and/or "ip6.arpa.", respectively. Additional
precautions for safely operating the DNS infrastructure are operational precautions for safely operating the DNS
required in order to ensure that name servers do not sign forged infrastructure are required in order to ensure that name servers
(or otherwise "wrong") resource records. Security considerations do not sign forged (or otherwise "wrong") resource records.
specific to U-NAPTR are described in more detail in [RFC4848]. Security considerations specific to U-NAPTR are described in more
detail in [RFC4848].
In addition to active protection mechanisms, users and network In addition to active protection mechanisms, users and network
operators can monitor application performance and network traffic operators can monitor application performance and network traffic
patterns for poor performance or abnormalities. If it turns out patterns for poor performance or abnormalities. If it turns out
that relying on the guidance of a specific ALTO server does not that relying on the guidance of a specific ALTO server does not
result in better-than-random results, the usage of the ALTO server result in better-than-random results, the usage of the ALTO server
may be discontinued (see also Section 15.2 of [RFC7285]). may be discontinued (see also Section 15.2 of [RFC7285]).
Note Note
The cross-domain ALTO server discovery procedure finishes The Cross-Domain ALTO Server Discovery Procedure finishes
successfully when it has discovered one or more URI(s). Once an successfully when it has discovered one or more URIs. Once an
ALTO server's URI has been discovered and the communication ALTO server's URI has been discovered and the communication
between the ALTO client and the ALTO server starts, the security between the ALTO client and the ALTO server starts, the security
threats and protection mechanisms discussed in the ALTO protocol threats and protection mechanisms discussed in the ALTO protocol
specification [RFC7285] apply. specification [RFC7285] apply.
A threat related to the one considered above is the impersonation A threat related to the one considered above is the impersonation
of an ALTO server after its correct URI has been discovered. This of an ALTO server after its correct URI has been discovered. This
threat and protection strategies are discussed in Section 15.1 of threat and protection strategies are discussed in Section 15.1 of
[RFC7285]. The ALTO protocol's primary mechanism for protecting [RFC7285]. The ALTO protocol's primary mechanism for protecting
authenticity and integrity (as well as confidentiality) is the use authenticity and integrity (as well as confidentiality) is the use
of HTTPS-based transport, i.e., HTTP over TLS [RFC2818]. of HTTPS-based transport -- i.e., HTTP over TLS [RFC2818].
Typically, when the URI's host component is a host name, a further 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 DNS lookup is needed to map it to an IP address before the
communication with the server can begin. This last DNS lookup communication with the server can begin. This last DNS lookup
(for A or AAAA resource records) does not necessarily have to be (for A or AAAA resource records) does not necessarily have to be
protected by DNSSEC, as the server identity checks specified in protected by DNSSEC, as the server identity checks specified in
[RFC2818] are able to detect DNS spoofing or similar attacks, [RFC2818] are able to detect DNS spoofing or similar attacks after
after the connection to the (possibly wrong) host has been the connection to the (possibly wrong) host has been established.
established. However, this validation, which is based on the However, this validation, which is based on the server
server certificate, can only protect the steps that occur after certificate, can only protect the steps that occur after the
the server URI has been discovered. It cannot detect attacks server URI has been discovered. It cannot detect attacks against
against the authenticity of the U-NAPTR lookups needed for the the authenticity of the U-NAPTR lookups needed for the Cross-
cross-domain ALTO server discovery procedure, and therefore, these Domain ALTO Server Discovery Procedure, and therefore, these
resource records have to be secured using DNSSEC. resource records have to be secured using DNSSEC.
6.2. Availability of the ALTO Server Discovery Procedure 6.2. Availability of the ALTO Server Discovery Procedure
Scenario Description Scenario Description
An attacker could compromise the cross-domain ALTO server An attacker could compromise the Cross-Domain ALTO Server
discovery procedure or the underlying infrastructure in a way that Discovery Procedure or the underlying infrastructure in such a way
ALTO clients would not be able to discover any ALTO server. that ALTO clients would not be able to discover any ALTO server.
Threat Discussion Threat Discussion
If no ALTO server can be discovered (although a suitable one If no ALTO server can be discovered (although a suitable one
exists) applications have to make their decisions without ALTO exists), applications have to make their decisions without ALTO
guidance. As ALTO could be temporarily unavailable for many guidance. As ALTO could be temporarily unavailable for many
reasons, applications must be prepared to do so. However, The reasons, applications must be prepared to do so. However, the
resulting application performance and traffic distribution will resulting application performance and traffic distribution will
correspond to a deployment scenario without ALTO. correspond to a deployment scenario without ALTO.
Protection Strategies and Mechanisms Protection Strategies and Mechanisms
Operators should follow best current practices to secure their DNS Operators should follow best current practices to secure their DNS
and ALTO (see Section 15.5 of [RFC7285]) servers against Denial- and ALTO servers (see Section 15.5 of [RFC7285]) against Denial-
of-Service (DoS) attacks. of-Service (DoS) attacks.
6.3. Confidentiality of the ALTO Server's URI 6.3. Confidentiality of the ALTO Server's URI
Scenario Description Scenario Description
An unauthorized party could invoke the cross-domain ALTO server An unauthorized party could invoke the Cross-Domain ALTO Server
discovery procedure, or intercept discovery messages between an Discovery Procedure or intercept discovery messages between an
authorized ALTO client and the DNS servers, in order to acquire authorized ALTO client and the DNS servers, in order to acquire
knowledge of the ALTO server URI for a specific IP address. knowledge of the ALTO server URI for a specific IP address.
Threat Discussion Threat Discussion
In the ALTO use cases that have been described in the ALTO problem In the ALTO use cases that have been described in the ALTO problem
statement [RFC5693] and/or discussed in the ALTO working group, statement [RFC5693] and/or discussed in the ALTO working group,
the ALTO server's URI as such has always been considered as public the ALTO server's URI as such has always been considered as public
information that does not need protection of confidentiality. information that does not need protection of confidentiality.
Protection Strategies and Mechanisms Protection Strategies and Mechanisms
No protection mechanisms for this scenario have been provided, as No protection mechanisms for this scenario have been provided, as
it has not been identified as a relevant threat. However, if a it has not been identified as a relevant threat. However, if a
new use case is identified that requires this kind of protection, new use case is identified that requires this kind of protection,
the suitability of this ALTO server discovery procedure as well as the suitability of this ALTO server discovery procedure as well as
possible security extensions have to be re-evaluated thoroughly. possible security extensions have to be re-evaluated thoroughly.
6.4. Privacy for ALTO Clients 6.4. Privacy for ALTO Clients
Scenario Description Scenario Description
An unauthorized party could eavesdrop on the messages between an An unauthorized party could eavesdrop on the messages between an
ALTO client and the DNS servers, and thereby find out the fact ALTO client and the DNS servers and thereby find out the fact that
that said ALTO client uses (or at least tries to use) the ALTO said ALTO client uses (or at least tries to use) the ALTO service
service in order to optimize traffic from/to a specific IP in order to optimize traffic from/to a specific IP address.
address.
Threat Discussion Threat Discussion
In the ALTO use cases that have been described in the ALTO problem In the ALTO use cases that have been described in the ALTO problem
statement [RFC5693] and/or discussed in the ALTO working group, statement [RFC5693] and/or discussed in the ALTO working group,
this scenario has not been identified as a relevant threat. this scenario has not been identified as a relevant threat.
However, Pervasive Surveillance [RFC7624] and DNS Privacy However, pervasive surveillance [RFC7624] and DNS privacy
Considerations [RFC7626] have seen significant attention in the considerations [RFC7626] have seen significant attention in the
Internet community in recent years. Internet community in recent years.
Protection Strategies and Mechanisms Protection Strategies and Mechanisms
DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] provide means DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] provide means
for protecting confidentiality (and integrity) of DNS traffic for protecting confidentiality (and integrity) of DNS traffic
between a client (stub) and its recursive name servers, including between a client (stub) and its recursive name servers, including
DNS queries and replies caused by the ALTO Cross-Domain Server DNS queries and replies caused by the ALTO Cross-Domain Server
Discovery Procedure. Discovery Procedure.
7. IANA Considerations 7. IANA Considerations
This document does not require any IANA action. This document has no IANA actions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", Part Three: The Domain Name System (DNS) Database",
RFC 3403, DOI 10.17487/RFC3403, October 2002, RFC 3403, DOI 10.17487/RFC3403, October 2002,
<https://www.rfc-editor.org/info/rfc3403>. <https://www.rfc-editor.org/info/rfc3403>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", STD 88, "DNS Extensions to Support IP Version 6", STD 88,
RFC 3596, DOI 10.17487/RFC3596, October 2003, RFC 3596, DOI 10.17487/RFC3596, October 2003,
skipping to change at page 24, line 39 skipping to change at line 1002
Using URIs and the Dynamic Delegation Discovery Service Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007, (DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007,
<https://www.rfc-editor.org/info/rfc4848>. <https://www.rfc-editor.org/info/rfc4848>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.kiesel-alto-alto4alto] [ALTO-ANYCAST]
Kiesel, S., "Using ALTO for ALTO server selection",
draft-kiesel-alto-alto4alto-00 (work in progress),
July 2010.
[I-D.kiesel-alto-ip-based-srv-disc]
Kiesel, S. and R. Penno, "Application-Layer Traffic Kiesel, S. and R. Penno, "Application-Layer Traffic
Optimization (ALTO) Anycast Address", Optimization (ALTO) Anycast Address", Work in Progress,
draft-kiesel-alto-ip-based-srv-disc-03 (work in progress), Internet-Draft, draft-kiesel-alto-ip-based-srv-disc-03, 1
July 2014. July 2014, <https://tools.ietf.org/html/draft-kiesel-alto-
ip-based-srv-disc-03>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [ALTO4ALTO]
and E. Lear, "Address Allocation for Private Internets", Kiesel, S., "Using ALTO for ALTO server selection", Work
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, in Progress, Internet-Draft, draft-kiesel-alto-alto4alto-
<https://www.rfc-editor.org/info/rfc1918>. 00, 5 July 2010, <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>.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/ ADDR.ARPA delegation", BCP 20, RFC 2317,
RFC2317, March 1998, DOI 10.17487/RFC2317, March 1998,
<https://www.rfc-editor.org/info/rfc2317>. <https://www.rfc-editor.org/info/rfc2317>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, Architecture", RFC 4291, DOI 10.17487/RFC4291, February
February 2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
August 2006, <https://www.rfc-editor.org/info/rfc4632>. 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>. <https://www.rfc-editor.org/info/rfc5389>.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, Optimization (ALTO) Problem Statement", RFC 5693,
DOI 10.17487/RFC5693, October 2009, DOI 10.17487/RFC5693, October 2009,
<https://www.rfc-editor.org/info/rfc5693>. <https://www.rfc-editor.org/info/rfc5693>.
skipping to change at page 26, line 25 skipping to change at line 1087
Threat Model and Problem Statement", RFC 7624, Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015, DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>. <https://www.rfc-editor.org/info/rfc7624>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015, DOI 10.17487/RFC7626, August 2015,
<https://www.rfc-editor.org/info/rfc7626>. <https://www.rfc-editor.org/info/rfc7626>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
May 2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and
S. Previdi, "Application-Layer Traffic Optimization (ALTO) S. Previdi, "Application-Layer Traffic Optimization (ALTO)
Deployment Considerations", RFC 7971, DOI 10.17487/ Deployment Considerations", RFC 7971,
RFC7971, October 2016, DOI 10.17487/RFC7971, October 2016,
<https://www.rfc-editor.org/info/rfc7971>. <https://www.rfc-editor.org/info/rfc7971>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
Appendix A. Solution Approaches for Partitioned ALTO Knowledge Appendix A. Solution Approaches for Partitioned ALTO Knowledge
The ALTO base protocol document [RFC7285] specifies the communication The ALTO base protocol document [RFC7285] specifies the communication
between an ALTO client and a single ALTO server. It is implicitly between an ALTO client and a single ALTO server. It is implicitly
skipping to change at page 27, line 23 skipping to change at line 1118
control of different administrative entities (e.g., different ISPs) control of different administrative entities (e.g., different ISPs)
or that the overall ALTO information is partitioned and stored on or that the overall ALTO information is partitioned and stored on
several ALTO servers. several ALTO servers.
A.1. Classification of Solution Approaches A.1. Classification of Solution Approaches
Various protocol extensions and other solutions have been proposed to Various protocol extensions and other solutions have been proposed to
deal with multiple information sources and partitioned knowledge. deal with multiple information sources and partitioned knowledge.
They can be classified as follows: They can be classified as follows:
1 Ensure that all ALTO servers have the same knowledge 1. Ensure that all ALTO servers have the same knowledge.
1.1 Ensure data replication and synchronization within the 1.1 Ensure data replication and synchronization within the
provisioning protocol (cf. RFC 5693, Fig 1 [RFC5693]). provisioning protocol (cf. [RFC5693], Figure 1).
1.2 Use an Inter-ALTO-server data replication protocol. Possibly, 1.2 Use an inter-ALTO-server data replication protocol.
the ALTO protocol itself - maybe with some extensions - could be Possibly, the ALTO protocol itself -- maybe with some
used for that purpose; however, this has not been studied in extensions -- could be used for that purpose; however, this
detail so far. has not been studied in detail so far.
2 Accept that different ALTO servers (possibly operated by 2. Accept that different ALTO servers (possibly operated by
different organizations, e.g., ISPs) do not have the same different organizations, e.g., ISPs) do not have the same
knowledge knowledge.
2.1 Allow ALTO clients to send arbitrary queries to any ALTO server 2.1 Allow ALTO clients to send arbitrary queries to any ALTO
(e.g. the one discovered using [RFC7286]). If this server server (e.g., the one discovered using [RFC7286]). If this
cannot answer the query itself, it will fetch the data on behalf server cannot answer the query itself, it will fetch the
of the client, using the ALTO protocol or a to-be-defined inter- data on behalf of the client, using the ALTO protocol or a
ALTO-server request forwarding protocol. to-be-defined inter-ALTO-server request forwarding protocol.
2.2 Allow ALTO clients to send arbitrary queries to any ALTO server 2.2 Allow ALTO clients to send arbitrary queries to any ALTO
(e.g. the one discovered using [RFC7286]). If this server server (e.g., the one discovered using [RFC7286]). If this
cannot answer the query itself, it will redirect the client to server cannot answer the query itself, it will redirect the
the "right" ALTO server that has the desired information, using client to the "right" ALTO server that has the desired
a small to-be-defined extension of the ALTO protocol. information, using a small to-be-defined extension of the
ALTO protocol.
2.3 ALTO clients need to use some kind of "search engine" that 2.3 ALTO clients need to use some kind of "search engine" that
indexes ALTO servers and redirects and/or gives cached results. indexes ALTO servers and redirects and/or gives cached
results.
2.4 ALTO clients need to use a new discovery mechanism to discover 2.4 ALTO clients need to use a new discovery mechanism to
the ALTO server that has the desired information and contact it discover the ALTO server that has the desired information
directly. and contact it directly.
A.2. Discussion of Solution Approaches A.2. Discussion of Solution Approaches
The provisioning or initialization protocol for ALTO servers (cf. RFC The provisioning or initialization protocol for ALTO servers
5693, Fig 1 [RFC5693]) is currently not standardized. It was a (cf. [RFC5693], Figure 1) is currently not standardized. It was a
conscious decision not to include this in the scope of the IETF ALTO 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 working group. The reason is that there are many different kinds of
information sources. This implementation specific protocol will information sources. This implementation-specific protocol will
adapt them to the ALTO server, which offers a standardized protocol adapt them to the ALTO server, which offers a standardized protocol
to the ALTO clients. However, adding the task of synchronization to the ALTO clients. However, adding the task of synchronization
between ALTO servers to this protocol (i.e., approach 1.1) would between ALTO servers to this protocol (i.e., Approach 1.1) would
overload this protocol with a second functionality that requires overload this protocol with a second functionality that requires
standardization for seamless multi-domain operation. standardization for seamless multidomain operation.
For the 1.? solution approaches, in addition to general technical For Approaches 1.1 and 1.2, in addition to general technical
feasibility and issues like overhead and caching efficiency, another feasibility and issues like overhead and caching efficiency, another
aspect to consider is legal liability. Operator "A" might prefer not aspect to consider is legal liability. Operator "A" might prefer not
to publish information about nodes in or paths between the networks 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 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 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 load on A's ALTO server. Operator A could also face legal liability
issues if that information had a bad impact on the traffic issues if that information had a bad impact on the traffic
engineering between B's and C's networks, or on their business engineering between B's and C's networks or on their business models.
models.
No specific actions to build a "search engine" based solution 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 (Approach 2.3) are currently known, and it is unclear what could be
the incentives to operate such an engine. Therefore, this approach the incentives to operate such an engine. Therefore, this approach
is not considered in the remainder of this document. is not considered in the remainder of this document.
A.3. The Need for Cross-Domain ALTO Server Discovery A.3. The Need for Cross-Domain ALTO Server Discovery
Approaches 1.1, 1.2, 2.1, and 2.2 do not only require the 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 specification of an ALTO protocol extension or a new protocol that
runs between ALTO servers. A large-scale, maybe Internet-wide, runs between ALTO servers. A large-scale, maybe Internet-wide,
multi-domain deployment would also need mechanisms by which an ALTO multidomain deployment would also need mechanisms by which an ALTO
server could discover other ALTO servers, learn which information is server could discover other ALTO servers, learn which information is
available where, and ideally also who is authorized to publish available where, and ideally also who is authorized to publish
information related to a given part of the network. Approach 2.4 information related to a given part of the network. Approach 2.4
needs the same mechanisms, except that they are used on the client- needs the same mechanisms, except that they are used on the client
side instead of the server-side. side instead of the server side.
It is sometimes questioned whether there is a need for a solution It is sometimes questioned whether there is a need for a solution
that allows clients to ask arbitrary queries, even if the ALTO that allows clients to ask arbitrary queries, even if the ALTO
information is partitioned and stored on many ALTO servers. The main information is partitioned and stored on many ALTO servers. The main
argument is, that clients are supposed to optimize the traffic from argument is that clients are supposed to optimize the traffic from
and to themselves, and that the information needed for that is most 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 likely stored on a "nearby" ALTO server -- i.e., the one that can be
discovered using [RFC7286]. However, there are scenarios where the discovered using [RFC7286]. However, there are scenarios where the
ALTO client is not co-located with an endpoint of the to-be-optimized 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 data transmission. Instead, the ALTO client is located at a third
party, which takes part in the application signaling, e.g., a so- party that takes part in the application signaling -- e.g., a so-
called "tracker" in a peer-to-peer application. One such scenario, called "tracker" in a peer-to-peer application. One such scenario,
where it is advantageous to place the ALTO client not at an endpoint where it is advantageous to place the ALTO client not at an endpoint
of the user data transmission, is analyzed in Appendix C. of the user data transmission, is analyzed in Appendix C.
A.4. Our Solution Approach A.4. Our Solution Approach
Several solution approaches for cross-domain ALTO server discovery Several solution approaches for cross-domain ALTO server discovery
have been evaluated, using the criteria documented in Appendix B. have been evaluated, using the criteria documented in Appendix B.
One of them was to use the ALTO protocol itself for the exchange of One of them was to use the ALTO protocol itself for the exchange of
information availability [I-D.kiesel-alto-alto4alto]. However, the information availability [ALTO4ALTO]. However, the drawback of that
drawback of that approach is that a new registration administration approach is that a new registration administration authority would
authority would have to be established. have to be established.
This document specifies a DNS-based procedure for cross-domain ALTO This document specifies a DNS-based procedure for cross-domain ALTO
server discovery, which was inspired by "Location Information Server server discovery, which was inspired by "Location Information Server
(LIS) Discovery Using IP Addresses and Reverse DNS" [RFC7216]. The (LIS) Discovery Using IP Addresses and Reverse DNS" [RFC7216]. The
primary goal is that this procedure can be used on the client-side 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 (i.e., Approach 2.4), but together with new protocols or protocol
extensions it could also be used to implement the other solution extensions, it could also be used to implement the other solution
approaches itemized above. approaches itemized above.
A.5. Relation to the ALTO Requirements A.5. Relation to the ALTO Requirements
During the design phase of the overall ALTO solution, two different During the design phase of the overall ALTO solution, two different
server discovery scenarios have been identified and documented in the server discovery scenarios were identified and documented in the ALTO
ALTO requirements document [RFC6708]. The first scenario, documented requirements document [RFC6708]. The first scenario, documented in
in Req. AR-32, can be supported using the discovery mechanisms Req. AR-32, can be supported using the discovery mechanisms specified
specified in [RFC7286]. An alternative approach, based on IP anycast in [RFC7286]. An alternative approach, based on IP anycast
[I-D.kiesel-alto-ip-based-srv-disc], has also been studied. This [ALTO-ANYCAST], has also been studied. This document, in contrast,
document, in contrast, tries to address Req. AR-33. tries to address Req. AR-33.
Appendix B. Requirements for Cross-Domain Server Discovery Appendix B. Requirements for Cross-Domain Server Discovery
This appendix itemizes requirements that have been collected before This appendix itemizes requirements that were collected before the
the design phase and that are reflected by the design of the ALTO design phase and are reflected in the design of the ALTO Cross-Domain
Cross-Domain Server Discovery Procedure. Server Discovery Procedure.
B.1. Discovery Client Application Programming Interface B.1. Discovery Client Application Programming Interface
The discovery client will be called through some kind of application The discovery client will be called through some kind of application
programming interface (API) and the parameters will be an IP address programming interface (API), and the parameters will be an IP address
and, for purposes of extensibility, a service identifier such as and, for purposes of extensibility, a service identifier such as
"ALTO". It will return one or more URI(s) that offers the requested "ALTO". The client will return one or more URIs that offer the
service ("ALTO") for the given IP address. requested service ("ALTO") for the given IP address.
In other words, the client would be used to retrieve a mapping: In other words, the client would be used to retrieve a mapping:
(IP address, "ALTO") -> IRD-URI(s) (IP address, "ALTO") -> IRD-URI(s)
where IRD-URI(s) is one or more URI(s) of Information Resource where IRD-URI(s) is one or more URIs of Information Resource
Directories (IRD, see Section 9 of [RFC7285]) of ALTO server(s) that Directories (IRDs, see Section 9 of [RFC7285]) of ALTO servers that
can give reasonable guidance to a resource consumer with the can give reasonable guidance to a resource consumer with the
indicated IP address. indicated IP address.
B.2. Data Storage and Authority Requirements B.2. Data Storage and Authority Requirements
The information for mapping IP addresses and service parameters to The information for mapping IP addresses and service parameters to
URIs should be stored in a - preferably distributed - database. It URIs should be stored in a -- preferably distributed -- database. It
must be possible to delegate administration of parts of this must be possible to delegate administration of parts of this
database. Usually, the mapping from a specific IP address to an URI database. Usually, the mapping from a specific IP address to a URI
is defined by the authority that has administrative control over this is defined by the authority that has administrative control over this
IP address, e.g., the ISP in residential access networks or the IT IP address -- e.g., the ISP in residential access networks or the IT
department in enterprise, university, or similar networks. department in enterprise, university, or similar networks.
B.3. Cross-Domain Operations Requirements B.3. Cross-Domain Operations Requirements
The cross-domain server discovery mechanism should be designed in The cross-domain server discovery mechanism should be designed in
such a way that it works across the public Internet and also in other 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 IP-based networks. This, in turn, means that such mechanisms cannot
rely on protocols that are not widely deployed across the Internet or rely on protocols that are not widely deployed across the Internet or
protocols that require special handling within participating protocols that require special handling within participating
networks. An example is multicast, which is not generally available networks. An example is multicast, which is not generally available
across the Internet. across the Internet.
The ALTO Cross-Domain Server Discovery protocol must support gradual The ALTO Cross-Domain Server Discovery Protocol must support gradual
deployment without a network-wide flag day. If the mechanism needs deployment without a network-wide flag day. If the mechanism needs
some kind of well-known "rendezvous point", re-using an existing some kind of well-known "rendezvous point", reusing an existing
infrastructure (such as the DNS root servers or the WHOIS database) infrastructure (such as the DNS root servers or the WHOIS database)
should be preferred over establishing a new one. should be preferred over establishing a new one.
B.4. Protocol Requirements B.4. Protocol Requirements
The protocol must be able to operate across middleboxes, especially The protocol must be able to operate across middleboxes, especially
across NATs and firewalls. NATs and firewalls.
The protocol shall not require any pre-knowledge from the client The protocol shall not require any preknowledge from the client other
other than any information that is known to a regular IP host on the than any information that is known to a regular IP host on the
Internet. Internet.
B.5. Further Requirements B.5. Further Requirements
The ALTO cross domain server discovery cannot assume that the server The ALTO cross-domain server discovery cannot assume that the server-
discovery client and the server discovery responding entity are under discovery client and the server-discovery responding entity are under
the same administrative control. the same administrative control.
Appendix C. ALTO and Tracker-based Peer-to-Peer Applications Appendix C. ALTO and Tracker-Based Peer-to-Peer Applications
This appendix provides a complete example of using ALTO and the ALTO This appendix provides a complete example of using ALTO and the ALTO
Cross-Domain Server Discovery Procedure in one specific application Cross-Domain Server Discovery Procedure in one specific application
scenario, namely a tracker-based peer-to-peer application. First, in scenario -- namely, a tracker-based peer-to-peer application. First,
subsection C.1, we introduce a generic model of such an application in Appendix C.1, we introduce a generic model of such an application
and show why ALTO optimization is desirable. Then, in C.2, we and show why ALTO optimization is desirable. Then, in Appendix C.2,
introduce two architectural options for integrating ALTO into the we introduce two architectural options for integrating ALTO into the
tracker-based peer-to-peer application - one option is based on the tracker-based peer-to-peer application; one option is based on the
"regular" ALTO server discovery procedure [RFC7286], one relies on "regular" ALTO server discovery procedure [RFC7286], and one relies
the ALTO Cross-Domain Server Discovery Procedure. In C.3, a simple on the ALTO Cross-Domain Server Discovery Procedure. In
mathematical model is used to show that the latter approach is Appendix C.3, a simple mathematical model is used to show that the
expected to yield significantly better optimization results. The latter approach is expected to yield significantly better
appendix concludes with subsection C.4, which details an exemplary optimization results. The appendix concludes with Appendix C.4,
complete walk-through of the ALTO Cross-Domain Server Discovery which details an exemplary complete walk-through of the ALTO Cross-
Procedure. Domain Server Discovery Procedure.
C.1. A generic Tracker-based Peer-to-Peer Application C.1. A Generic Tracker-Based Peer-to-Peer Application
The optimization of peer-to-peer (P2P) applications such as The optimization of peer-to-peer (P2P) applications such as
BitTorrent was one of the first use cases that lead to the inception BitTorrent was one of the first use cases that lead to the inception
of the IETF ALTO working group. Further use cases have been of the IETF ALTO working group. Further use cases have been
identified as well, yet we will use this scenario to illustrate the identified as well, yet we will use this scenario to illustrate the
operation and usefulness of the ALTO Cross-Domain Server Discovery operation and usefulness of the ALTO Cross-Domain Server Discovery
Procedure. Procedure.
For the remainder of this chapter we consider a generic, tracker- For the remainder of this chapter, we consider a generic, tracker-
based peer-to-peer file sharing application. The goal is the based peer-to-peer file-sharing application. The goal is the
dissemination of a large file, without using one large server with a dissemination of a large file, without using one large server with a
correspondingly high upload bandwidth. The file is split into correspondingly high upload bandwidth. The file is split into
chunks. So-called "peers" assume the role of both a client and a 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 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 may serve the chunks they already possess to other peers at the same
time, thereby contributing their upload bandwidth. Peers that want time, thereby contributing their upload bandwidth. Peers that want
to share the same file participate in a "swarm". They use the peer- to share the same file participate in a "swarm". They use the peer-
to-peer protocol to inform each other about the availability of to-peer protocol to inform each other about the availability of
chunks and to request and transfer chunks from one peer to another. chunks and request and transfer chunks from one peer to another. A
A swarm may consist of a very large number of peers. Consequently, swarm may consist of a very large number of peers. Consequently,
peers usually maintain logical connections only to a subset of all 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 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 contacts a well-known server, the "tracker", which provides a list of
IP addresses of peers in the swarm. IP addresses of peers in the swarm.
A swarm is an overlay network on top of the IP network. Algorithms A swarm is an overlay network on top of the IP network. Algorithms
that determine the overlay topology and the traffic distribution in that determine the overlay topology and the traffic distribution in
the overlay may consider information about the underlying IP network, the overlay may consider information about the underlying IP network,
such as topological distance, link bandwidth, (monetary) costs for such as topological distance, link bandwidth, (monetary) costs for
sending traffic from one host to another, etc. ALTO is a protocol sending traffic from one host to another, etc. ALTO is a protocol
for retrieving such information. The goal of such "topology aware" for retrieving such information. The goal of such "topology-aware"
decisions is to improve performance or Quality of Experience in the decisions is to improve performance or Quality of Experience in the
application while reducing the utilization of the underlying network application while reducing the utilization of the underlying network
infrastructure. infrastructure.
C.2. Architectural Options for Placing the ALTO Client C.2. Architectural Options for Placing the ALTO Client
The ALTO protocol specification [RFC7285] details how an ALTO client The ALTO protocol specification [RFC7285] details how an ALTO client
can query an ALTO server for guiding information and receive the can query an ALTO server for guiding information and receive the
corresponding replies. However, in the considered scenario of a corresponding replies. However, in the considered scenario of a
tracker-based P2P application, there are two fundamentally different tracker-based P2P application, there are two fundamentally different
possibilities where to place the ALTO client: possible locations for where to place the ALTO client:
1. ALTO client in the resource consumer ("peer") 1. ALTO client in the resource consumer ("peer")
2. ALTO client in the resource directory ("tracker") 2. ALTO client in the resource directory ("tracker")
In the following, both scenarios are compared in order to explain the In the following, both scenarios are compared in order to explain the
need for ALTO queries on behalf of remote resource consumers. need for ALTO queries on behalf of remote resource consumers.
In the first scenario (see Figure 2), the resource consumer queries In the first scenario (see Figure 2), the resource consumer queries
the resource directory for the desired resource (F1). The resource the resource directory for the desired resource (F1). The resource
directory returns a list of potential resource providers without directory returns a list of potential resource providers without
considering ALTO (F2). It is then the duty of the resource consumer considering ALTO (F2). It is then the duty of the resource consumer
to invoke ALTO (F3/F4), in order to solicit guidance regarding this to invoke ALTO (F3/F4), in order to solicit guidance regarding this
list. list.
In the second scenario (see Figure 4), the resource directory has an In the second scenario (see Figure 4), the resource directory has an
embedded ALTO client. After receiving a query for a given resource embedded ALTO client. After receiving a query for a given resource
(F1) the resource directory invokes this ALTO client to evaluate all (F1), the resource directory invokes this ALTO client to evaluate all
resource providers it knows (F2/F3). Then it returns a, possibly resource providers it knows (F2/F3). Then it returns a list,
shortened, list containing the "best" resource providers to the possibly shortened, containing the "best" resource providers to the
resource consumer (F4). resource consumer (F4).
............................. ............................. ............................. .............................
: Tracker : : Peer : : Tracker : : Peer :
: ______ : : : : ______ : : :
: +-______-+ : : k good : : +-______-+ : : k good :
: | | +--------+ : P2P App. : +--------+ peers +------+ : : | | +--------+ : P2P App. : +--------+ peers +------+ :
: | N | | random | : Protocol : | ALTO- |------>| data | : : | N | | random | : Protocol : | ALTO- |------>| data | :
: | known |====>| pre- |*************>| biased | | ex- | : : | known |====>| pre- |*************>| biased | | ex- | :
: | peers, | | selec- | : transmit : | peer |------>| cha- | : : | peers, | | selec- | : transmit : | peer |------>| cha- | :
skipping to change at page 34, line 25 skipping to change at line 1400
:...........................: :.....^.....................: :...........................: :.....^.....................:
| |
| ALTO protocol | ALTO protocol
__|___ __|___
+-______-+ +-______-+
| | | |
| ALTO | | ALTO |
| server | | server |
+-______-+ +-______-+
Figure 1: Tracker-based P2P Application with random peer preselection Figure 1: Tracker-Based P2P Application with Random Peer Preselection
Peer w. ALTO cli. Tracker ALTO Server Peer w. ALTO cli. Tracker ALTO Server
--------+-------- --------+-------- --------+-------- --------+-------- --------+-------- --------+--------
| F1 Tracker query | | | F1 Tracker query | |
|======================>| | |======================>| |
| F2 Tracker reply | | | F2 Tracker reply | |
|<======================| | |<======================| |
| F3 ALTO query | | | F3 ALTO query | |
|---------------------------------------------->| |---------------------------------------------->|
| F4 ALTO reply | | | F4 ALTO reply | |
|<----------------------------------------------| |<----------------------------------------------|
| | | | | |
==== Application protocol (i.e., tracker-based P2P app protocol) ==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO protocol ---- ALTO protocol
Figure 2: Basic message sequence chart for resource consumer- Figure 2: Basic Message Sequence Chart for Resource Consumer-
initiated ALTO query Initiated ALTO Query
............................. ............................. ............................. .............................
: Tracker : : Peer : : Tracker : : Peer :
: ______ : : : : ______ : : :
: +-______-+ : : : : +-______-+ : : :
: | | +--------+ : P2P App. : k good peers & +------+ : : | | +--------+ : P2P App. : k good peers & +------+ :
: | N | | ALTO- | : Protocol : n-k bad peers | data | : : | N | | ALTO- | : Protocol : n-k bad peers | data | :
: | known |====>| biased |******************************>| ex- | : : | known |====>| biased |******************************>| ex- | :
: | peers, | | peer | : transmit : | cha- | : : | peers, | | peer | : transmit : | cha- | :
: | M good | | select | : n peer : | nge | : : | M good | | select | : n peer : | nge | :
skipping to change at page 35, line 25 skipping to change at line 1440
:.....................^.....: :...........................: :.....................^.....: :...........................:
| |
| ALTO protocol | ALTO protocol
__|___ __|___
+-______-+ +-______-+
| | | |
| ALTO | | ALTO |
| server | | server |
+-______-+ +-______-+
Figure 3: Tracker-based P2P Application with ALTO client in tracker Figure 3: Tracker-Based P2P Application with ALTO Client in Tracker
Peer Tracker w. ALTO cli. ALTO Server Peer Tracker w. ALTO cli. ALTO Server
--------+-------- --------+-------- --------+-------- --------+-------- --------+-------- --------+--------
| F1 Tracker query | | | F1 Tracker query | |
|======================>| | |======================>| |
| | F2 ALTO query | | | F2 ALTO query |
| |---------------------->| | |---------------------->|
| | F3 ALTO reply | | | F3 ALTO reply |
| |<----------------------| | |<----------------------|
| F4 Tracker reply | | | F4 Tracker reply | |
|<======================| | |<======================| |
| | | | | |
==== Application protocol (i.e., tracker-based P2P app protocol) ==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO protocol ---- ALTO protocol
Figure 4: Basic message sequence chart for ALTO query on behalf of Figure 4: Basic Message Sequence Chart for ALTO Query on Behalf
remote resource consumer of Remote Resource Consumer
Note: the message sequences depicted in Figure 2 and Figure 4 may | Note: The message sequences depicted in Figures 2 and 4 may
occur both in the target-aware and the target-independent query mode | occur both in the target-aware and the target-independent query
(c.f. [RFC6708]). In the target-independent query mode no message | mode (cf. [RFC6708]). In the target-independent query mode, no
exchange with the ALTO server might be needed after the tracker | message exchange with the ALTO server might be needed after the
query, because the candidate resource providers could be evaluated | tracker query, because the candidate resource providers could
using a locally cached "map", which has been retrieved from the ALTO | be evaluated using a locally cached "map", which has been
server some time ago. | retrieved from the ALTO server some time ago.
C.3. Evaluation C.3. Evaluation
The problem with the first approach is, that while the resource The problem with the first approach is that while the resource
directory might know thousands of peers taking part in a swarm, the directory might know thousands of peers taking part in a swarm, the
list returned to the resource consumer is usually shortened for list returned to the resource consumer is usually shortened for
efficiency reasons. Therefore, the "best" (in the sense of ALTO) efficiency reasons. Therefore, the "best" (in the sense of ALTO)
potential resource providers might not be contained in that list potential resource providers might not be contained in that list
anymore, even before ALTO can consider them. anymore, even before ALTO can consider them.
For illustration, consider a simple model of a swarm, in which all For illustration, consider a simple model of a swarm, in which all
peers fall into one of only two categories: assume that there are peers fall into one of only two categories: assume that there are
"good" ("good" in the sense of ALTO's better-than-random peer only "good" (in the sense of ALTO's better-than-random peer
selection, based on an arbitrary desired rating criterion) and "bad' selection, based on an arbitrary desired rating criterion) and "bad"
peers only. Having more different categories makes the maths more peers. Having more different categories makes the math more complex
complex but does not change anything to the basic outcome of this but does not change anything about the basic outcome of this
analysis. Assume that the swarm has a total number of N peers, out analysis. Assume that the swarm has a total number of N peers, out
of which are M "good" and N-M "bad" peers, which are all known to the of which there are M "good" and N-M "bad" peers, which are all known
tracker. A new peer wants to join the swarm and therefore asks the to the tracker. A new peer wants to join the swarm and therefore
tracker for a list of peers. asks the tracker for a list of peers.
If, according to the first approach, the tracker randomly picks n If, according to the first approach, the tracker randomly picks n
peers from the N known peers, the result can be described with the peers from the N known peers, the result can be described with the
hypergeometric distribution. The probability that the tracker reply hypergeometric distribution. The probability that the tracker reply
contains exactly k "good" peers (and n-k "bad" peers) is: contains exactly k "good" peers (and n-k "bad" peers) is:
/ M \ / N - M \ / M \ / N - M \
\ k / \ n - k / \ k / \ n - k /
P(X=k) = --------------------- P(X=k) = ---------------------
/ N \ / N \
\ n / \ n /
/ n \ n! / n \ n!
with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1 with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1
k! (n-k)! k! (n-k)!
The probability that the reply contains at most k "good" peers is: The probability that the reply contains at most k "good" peers is:
P(X<=k)=P(X=0)+P(X=1)+..+P(X=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 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 tracker, out of which M=100 are "good" peers. If the tracker
randomly selects n=100 peers, the formula yields for the reply: 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 approx. 36% P(X=0)=36%, P(X<=4)=99%. That is, with a probability of approximately
this list does not contain a single "good" peer, and with 99% 36%, this list does not contain a single "good" peer, and with 99%
probability there are only four or less of the "good" peers on the probability, there are only four or fewer of the "good" peers on the
list. Processing this list with the guiding ALTO information will list. Processing this list with the guiding ALTO information will
ensure that the few favorable peers are ranked to the top of the ensure that the few favorable peers are ranked to the top of the
list; however, the benefit is rather limited as the number of list; however, the benefit is rather limited as the number of
favorable peers in the list is just too small. favorable peers in the list is just too small.
Much better traffic optimization could be achieved if the tracker Much better traffic optimization could be achieved if the tracker
would evaluate all known peers using ALTO, and return a list of 100 would evaluate all known peers using ALTO and return a list of 100
peers afterwards. This list would then include a significantly peers afterwards. This list would then include a significantly
higher fraction of "good" peers. (Note, that if the tracker returned higher fraction of "good" peers. (Note that if the tracker returned
"good" peers only, there might be a risk that the swarm might "good" peers only, there might be a risk that the swarm might
disconnect and split into several disjunct partitions. However, disconnect and split into several disjunct partitions. However,
finding the right mix of ALTO-biased and random peer selection is out finding the right mix of ALTO-biased and random peer selection is out
of the scope of this document.) of the scope of this document.)
Therefore, from an overall optimization perspective, the second Therefore, from an overall optimization perspective, the second
scenario with the ALTO client embedded in the resource directory is scenario with the ALTO client embedded in the resource directory is
advantageous, because it is ensured that the addresses of the "best" advantageous, because it is ensured that the addresses of the "best"
resource providers are actually delivered to the resource consumer. resource providers are actually delivered to the resource consumer.
An architectural implication of this insight is that the ALTO server An architectural implication of this insight is that the ALTO server
discovery procedures must support ALTO queries on behalf of remote discovery procedures must support ALTO queries on behalf of remote
resource consumers. That is, as the tracker issues ALTO queries on resource consumers. That is, as the tracker issues ALTO queries on
behalf of the peer which contacted the tracker, the tracker must be behalf of the peer that contacted the tracker, the tracker must be
able to discover an ALTO server that can give guidance suitable for able to discover an ALTO server that can give guidance suitable for
that respective peer. This task can be solved using the ALTO Cross- that peer. This task can be solved using the ALTO Cross-Domain
Domain Server Discovery Procedure. Server Discovery Procedure.
C.4. Example C.4. Example
This section provides a complete example of the ALTO Cross-Domain This section provides a complete example of the ALTO Cross-Domain
Server Discovery Procedure in a tracker-based peer-to-peer scenario. Server Discovery Procedure in a tracker-based peer-to-peer scenario.
The example is based on the network topology shown in Figure 5. Five 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 access networks -- Networks a, b, c, x, and t -- are operated by five
different network operators. They are interconnected by a backbone different network operators. They are interconnected by a backbone
structure. Each network operator runs an ALTO server in their 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 network -- i.e., ALTO_SRV_A, ALTO_SRV_B, ALTO_SRV_C, ALTO_SRV_X, and
ALTO_SRV_T, respectively. ALTO_SRV_T, respectively.
_____ __ _____ __ _____ __ _____ __ _____ __ _____ __
__( )__( )_ __( )__( )_ __( )__( )_ __( )__( )_ __( )__( )_ __( )__( )_
( Network a ) ( Network b ) ( Network c ) ( Network a ) ( Network b ) ( Network c )
( Res. Provider A ) ( Res. Provider B ) ( Res. Provider C ) ( Res. Provider A ) ( Res. Provider B ) ( Res. Provider C )
(__ ALTO_SRV_A __) (__ ALTO_SRV_B __) (__ ALTO_SRV_C __) (__ ALTO_SRV_A __) (__ ALTO_SRV_B __) (__ ALTO_SRV_C __)
(___)--(____) \ (___)--(____) / (___)--(____) (___)--(____) \ (___)--(____) / (___)--(____)
\ / / \ / /
---+---------+-----------------+---- ---+---------+-----------------+----
( Backbone ) ( Backbone )
------------+------------------+---- ------------+------------------+----
_____ __/ _____ \__ _____ __/ _____ \__
__( )__( )_ __( )__( )_ __( )__( )_ __( )__( )_
( Network x ) ( Network t ) ( Network x ) ( Network t )
( Res. Consumer X ) (Resource Directory) ( Res. Consumer X ) (Resource Directory)
(_ ALTO_SRV_X __) (_ ALTO_SRV_T __) (_ ALTO_SRV_X __) (_ ALTO_SRV_T __)
(___)--(____) (___)--(____) (___)--(____) (___)--(____)
Figure 5: Example network topology Figure 5: Example Network Topology
A new peer of a peer-to-peer application wants to join a specific A new peer of a peer-to-peer application wants to join a specific
swarm (overlay network), in order to access a specific resource. swarm (overlay network), in order to access a specific resource.
This new peer will be called "Resource Consumer X" in accordance to This new peer will be called "Resource Consumer X", in accordance
the terminology of [RFC6708] and it is located in Network x. It with the terminology of [RFC6708], and is located in Network x. It
contacts the tracker ("Resource Directory"), which is located in contacts the tracker ("Resource Directory"), which is located in
Network t. The mechanism by which the new peer discovers the tracker 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 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 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 determine that Resource Providers A, B, and C are candidate peers for
Resource Consumer X. Resource Consumer X.
As shown in the previous section, a tracker-side ALTO optimization As shown in the previous section, a tracker-side ALTO optimization
(c.f. Figure 3 and Figure 4) is more efficient than a client-side (cf. Figures 3 and 4) is more efficient than a client-side
optimization. Consequently, the tracker wants to use the ALTO optimization. Consequently, the tracker wants to use the ALTO
Endpoint Cost Service (ECS) to learn the routing costs between X and Endpoint Cost Service (ECS) to learn the routing costs between X and
A, X and B, as well as X and C, in order to sort A, B, and C by their A, X and B, and X and C, in order to sort A, B, and C by their
respective routing costs to X. respective routing costs to X.
In theory, there are many options how the ALTO Cross-Domain Server In theory, there are many options for how the ALTO Cross-Domain
Discovery Procedure could be used. For example, the tracker could do Server Discovery Procedure could be used. For example, the tracker
the following steps: could do the following steps:
IRD_URIS_A = XDOMDISC(A,"ALTO:https") IRD_URIS_A = XDOMDISC(A,"ALTO:https")
COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_A COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_A
IRD_URIS_B = XDOMDISC(B,"ALTO:https") IRD_URIS_B = XDOMDISC(B,"ALTO:https")
COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_B COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_B
IRD_URIS_C = XDOMDISC(C,"ALTO:https") IRD_URIS_C = XDOMDISC(C,"ALTO:https")
COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_C COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_C
Maybe, the ALTO Cross-Domain Server Discovery Procedure queries would In this scenario, the ALTO Cross-Domain Server Discovery Procedure
yield in this scenario: IRD_URIS_A = ALTO_SRV_A, IRD_URIS_B = 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 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 would be sent to a different ALTO server. The problem with this
approach is that we are not neccessarily able to compare COST_X_A, 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 COST_X_B, and COST_X_C with each other. The specification of the
routingcost metric mandates that "A lower value indicates a higher routingcost metric mandates that "A lower value indicates a higher
preference", but "an ISP may internally compute routing cost using preference", but "an ISP may internally compute routing cost using
any method that it chooses" (see section 6.1.1.1. of [RFC7285]). 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 Thus, COST_X_A could be 10 (milliseconds round-trip time), while
COST_X_B could be 200 (kilometers great circle distance between the COST_X_B could be 200 (kilometers great circle distance between the
approximate geographic locations of the hosts) and COST_X_C could be 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 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 IP header). Each of these metrics fulfills the "lower value is more
preferable" requirement on its own, but obviously, they cannot be preferable" requirement on its own, but they obviously cannot be
compared with each other. Even if there was a reasonable formula to compared with each other. Even if there were a reasonable formula to
compare, for example, kilometers with milliseconds, we could not use compare, for example, kilometers with milliseconds, we could not use
it, as the units of measurement (or any other information about the it, as the units of measurement (or any other information about the
computation method for the routingcost) are not sent along with the computation method for the routingcost) are not sent along with the
value in the ECS reply. value in the ECS reply.
To avoid this problem, the tracker tries to send all ECS queries to 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, 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 parameter to Case 2, it uses the IP address of Resource Consumer x as a parameter
the discovery procedure: of the discovery procedure:
IRD_URIS_X = XDOMDISC(X,"ALTO:https") IRD_URIS_X = XDOMDISC(X,"ALTO:https")
COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_X 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_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 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 This strategy ensures that COST_X_A, COST_X_B, and COST_X_C can be
compared with each other. compared with each other.
As discussed above, the tracker calls the ALTO Cross-Domain Server As discussed above, the tracker calls the ALTO Cross-Domain Server
Discovery Procedure with IP address X as a parameter. For the Discovery Procedure with IP address X as a parameter. For the
reminder of this example, we assume that X = 2001:DB8:1:2:227:eff: remainder of this example, we assume that X =
fe6a:de42. Thus, the procedure call is 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"). 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 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, address. Thus, we get AT = IPv6, A = 2001:DB8:1:2:227:eff:fe6a:de42,
L = 128, and SP = "ALTO:https". L = 128, and SP = "ALTO:https".
The procedure constructs (see Step 1 in Section 3.2) The procedure constructs (see Step 1 in Section 3.2)
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. 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 (see Step 2 in Section 3.3) 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.", as well as the following (see Step 2 in Section 3.2):
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.", and R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R32 = "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 In order to illustrate the third step of the ALTO Cross-Domain Server
Discovery Procedure, we use the "dig" (domain information groper) DNS Discovery Procedure, we use the "dig" (domain information groper) DNS
lookup utility that is available for many operating systems (e.g., lookup utility that is available for many operating systems (e.g.,
Linux). A real implementation of the ALTO Cross-Domain Server Linux). A real implementation of the ALTO Cross-Domain Server
Discovery Procedure would not be based on the "dig" utility, but use Discovery Procedure would not be based on the "dig" utility but
appropriate libraries and/or operating system APIs. Please note that instead would use appropriate libraries and/or operating-system APIs.
the following steps have been performed in a controlled lab Please note that the following steps have been performed in a
environment with a appropriately configured name server. A suitable controlled lab environment with an appropriately configured name
DNS configuration will be needed to reproduce these results. Please server. A suitable DNS configuration will be needed to reproduce
also note that the rather verbose output of the "dig" tool has been these results. Please also note that the rather verbose output of
shortened to the relevant lines. the "dig" tool has been shortened to the relevant lines.
Since AT = IPv6 and L = 128, in the table given in Section 3.4, the Since AT = IPv6 and L = 128, in the table given in Section 3.4, the
sixth row (not counting the column headers) applies. sixth row (not counting the column headers) applies.
As mandated by the third column, we start with a lookup of R128, As mandated by the third column, we start with a lookup of R128,
looking for NAPTR resource records: looking for NAPTR resource records:
| user@labpc:~$ dig -tNAPTR 2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.\ | 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. | 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| |
skipping to change at page 41, line 12 skipping to change at line 1693
get a useful result. Therefore, we continue with the fourth column get a useful result. Therefore, we continue with the fourth column
of the table and do a lookup of R64: of the table and do a lookup of R64:
| user@labpc:~$ dig -tNAPTR 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. | user@labpc:~$ dig -tNAPTR 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| |
| ;; Got answer: | ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33193 | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33193
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0 | ;; 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 The domain name R64 could be looked up (status: NOERROR), but there
are no NAPTR resource records associated with it (ANSWER: 0). Maybe, are no NAPTR resource records associated with it (ANSWER: 0). There
there are some other resource records such as PTR, NS, or SOA, but we 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 are not interested in them. Thus, we do not get a useful result, and
we continue with looking up R56: we continue with looking up R56:
| user@labpc:~$ dig -tNAPTR 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. | user@labpc:~$ dig -tNAPTR 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| |
| ;; Got answer: | ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35966 | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35966
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
| |
| ;; ANSWER SECTION: | ;; ANSWER SECTION:
| 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u" | 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!" . | "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" | 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!" . | "LIS:HELD" "!.*!https://lis2.example.org:4802/?c=ex!" .
The domain name R56 could be looked up and there are NAPTR resource The domain name R56 could be looked up, and there are NAPTR resource
records associated with it. However, each of these records has a records associated with it. However, each of these records has a
service parameter that does not match our SP = "ALTO:https" (see service parameter that does not match our SP = "ALTO:https" (see
[RFC7216] for "LIS:HELD"), and therefore, we have to ignore them. [RFC7216] for "LIS:HELD"), and therefore we have to ignore them.
Consequently, we still do not have a useful result and continue with Consequently, we still do not have a useful result and continue with
a lookup of R48: a lookup of R48:
| user@labpc:~$ dig -tNAPTR 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. | user@labpc:~$ dig -tNAPTR 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| |
| ;; Got answer: | ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50459 | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50459
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
| |
| ;; ANSWER SECTION: | ;; ANSWER SECTION:
skipping to change at page 42, line 9 skipping to change at line 1739
This lookup yields two NAPTR resource records. We have to ignore the 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 second one as its service parameter does not match our SP, but the
first NAPTR resource record has a matching service parameter. first NAPTR resource record has a matching service parameter.
Therefore, the procedure terminates successfully and the final Therefore, the procedure terminates successfully and the final
outcome is: IRD_URIS_X = "https://alto1.example.net/ird". outcome is: IRD_URIS_X = "https://alto1.example.net/ird".
The ALTO client that is embedded in the tracker will access the ALTO The ALTO client that is embedded in the tracker will access the ALTO
Information Resource Directory (IRD, see Section 9 of [RFC7285]) at Information Resource Directory (IRD, see Section 9 of [RFC7285]) at
this URI, look for the Endpoint Cost Service (ECS, see Section 11.5 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 of [RFC7285]), and query the ECS for the costs between A and X, B and
X, as well as C and X, before returning an ALTO-optimized list of X, and C and X, before returning an ALTO-optimized list of candidate
candidate resource providers to resource consumer X. resource providers to resource consumer X.
Appendix D. Contributors List and Acknowledgments Acknowledgments
The initial version of this document was co-authored by Marco Tomsu The initial draft version of this document was co-authored by Marco
(Alcatel-Lucent). Tomsu (Alcatel-Lucent).
This document borrows some text from [RFC7286], as historically, it This document borrows some text from [RFC7286], as historically, it
has been part of the draft that eventually became said RFC. Special was part of the draft that eventually became said RFC. Special
thanks to Michael Scharf and Nico Schwan. thanks to Michael Scharf and Nico Schwan.
Authors' Addresses Authors' Addresses
Sebastian Kiesel Sebastian Kiesel
University of Stuttgart Information Center University of Stuttgart Information Center
Allmandring 30 Allmandring 30
Stuttgart 70550 70550 Stuttgart
Germany Germany
Email: ietf-alto@skiesel.de Email: ietf-alto@skiesel.de
URI: http://www.izus.uni-stuttgart.de URI: http://www.izus.uni-stuttgart.de
Martin Stiemerling Martin Stiemerling
University of Applied Sciences Darmstadt, Computer Science Dept. University of Applied Sciences Darmstadt, Computer Science Dept.
Haardtring 100 Haardtring 100
Darmstadt 64295 64295 Darmstadt
Germany Germany
Phone: +49 6151 16 37938 Phone: +49 6151 16 37938
Email: mls.ietf@gmail.com Email: mls.ietf@gmail.com
URI: http://ietf.stiemerling.org URI: https://danet.fbi.h-da.de
 End of changes. 217 change blocks. 
593 lines changed or deleted 632 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/