Skip to main content

Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery
draft-ietf-alto-xdom-disc-06

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8686.
Authors Sebastian Kiesel , Martin Stiemerling
Last updated 2020-03-09 (Latest revision 2019-08-20)
Replaces draft-kiesel-alto-xdom-disc
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Jan Seedorf
Shepherd write-up Show Last changed 2018-10-29
IESG IESG state Became RFC 8686 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Mirja Kühlewind
Send notices to Jan Seedorf <jan.seedorf@hft-stuttgart.de>
IANA IANA review state Version Changed - Review Needed
IANA action state No IANA Actions
draft-ietf-alto-xdom-disc-06
ALTO                                                           S. Kiesel
Internet-Draft                                   University of Stuttgart
Intended status: Standards Track                          M. Stiemerling
Expires: February 21, 2020                                          H-DA
                                                         August 20, 2019

   Application Layer Traffic Optimization (ALTO) Cross-Domain Server
                               Discovery
                      draft-ietf-alto-xdom-disc-06

Abstract

   The goal of Application-Layer Traffic Optimization (ALTO) is to
   provide guidance to applications that have to select one or several
   hosts from a set of candidates capable of providing a desired
   resource.  ALTO is realized by a client-server protocol.  Before an
   ALTO client can ask for guidance it needs to discover one or more
   ALTO servers that can provide suitable guidance.

   In some deployment scenarios, in particular if the information about
   the network topology is partitioned and distributed over several ALTO
   servers, it may be needed to discover an ALTO server outside of the
   own network domain, in order to get appropriate guidance.  This
   document details applicable scenarios, itemizes requirements, and
   specifies a procedure for ALTO cross-domain server discovery.

   Technically, the procedure specified in this document takes one
   IP address or prefix and a U-NAPTR Service Parameter (typically,
   "ALTO:https") as parameters.  It performs DNS lookups (for NAPTR
   resource records in the in-addr.arpa. or ip6.arpa. tree) and returns
   one or more URI(s) of information resources related to that IP
   address or prefix.

Kiesel & Stiemerling    Expires February 21, 2020               [Page 1]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

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.

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
   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 21, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Kiesel & Stiemerling    Expires February 21, 2020               [Page 2]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  ALTO Cross-Domain Server Discovery Procedure: Overview . . . .  5
   3.  ALTO Cross-Domain Server Discovery Procedure: Specification  .  6
     3.1.  Interface  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Step 1: Prepare Domain Name for Reverse DNS Lookup . . . .  7
     3.3.  Step 2: Prepare Shortened Domain Names . . . . . . . . . .  8
     3.4.  Step 3: Perform DNS U-NAPTR lookups  . . . . . . . . . . .  9
     3.5.  Error Handling . . . . . . . . . . . . . . . . . . . . . . 10
   4.  Using the ALTO Protocol with Cross-Domain Server Discovery . . 11
     4.1.  Network and Cost Map Service . . . . . . . . . . . . . . . 11
     4.2.  Map-Filtering Service  . . . . . . . . . . . . . . . . . . 12
     4.3.  Endpoint Property Service  . . . . . . . . . . . . . . . . 12
     4.4.  Endpoint Cost Service  . . . . . . . . . . . . . . . . . . 12
     4.5.  Summary and Further Extensions . . . . . . . . . . . . . . 14
   5.  Implementation, Deployment, and Operational Considerations . . 15
     5.1.  Considerations for ALTO Clients  . . . . . . . . . . . . . 15
     5.2.  Considerations for Network Operators . . . . . . . . . . . 17
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
     6.1.  Integrity of the ALTO Server's URI . . . . . . . . . . . . 19
     6.2.  Availability of the ALTO Server Discovery Procedure  . . . 20
     6.3.  Confidentiality of the ALTO Server's URI . . . . . . . . . 21
     6.4.  Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 21
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 24
   Appendix A.  Solution Approaches for Partitioned ALTO Knowledge  . 27
     A.1.  Classification of Solution Approaches  . . . . . . . . . . 27
     A.2.  Discussion of Solution Approaches  . . . . . . . . . . . . 28
     A.3.  The Need for Cross-Domain ALTO Server Discovery  . . . . . 28
     A.4.  Our Solution Approach  . . . . . . . . . . . . . . . . . . 29
     A.5.  Relation to the ALTO Requirements  . . . . . . . . . . . . 29
   Appendix B.  Requirements for Cross-Domain Server Discovery  . . . 30
     B.1.  Discovery Client Application Programming Interface . . . . 30
     B.2.  Data Storage and Authority Requirements  . . . . . . . . . 30
     B.3.  Cross-Domain Operations Requirements . . . . . . . . . . . 30
     B.4.  Protocol Requirements  . . . . . . . . . . . . . . . . . . 31
     B.5.  Further Requirements . . . . . . . . . . . . . . . . . . . 31
   Appendix C.  ALTO and Tracker-based Peer-to-Peer Applications  . . 32
     C.1.  A generic Tracker-based Peer-to-Peer Application . . . . . 32
     C.2.  Architectural Options for Placing the ALTO Client  . . . . 33
     C.3.  Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 36
     C.4.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . 38
   Appendix D.  Contributors List and Acknowledgments . . . . . . . . 43
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44

Kiesel & Stiemerling    Expires February 21, 2020               [Page 3]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

1.  Introduction

   The goal of Application-Layer Traffic Optimization (ALTO) is to
   provide guidance to applications that have to select one or several
   hosts from a set of candidates capable of providing a desired
   resource [RFC5693].  ALTO is realized by an HTTP-based client-server
   protocol [RFC7285], which can be used in various scenarios [RFC7971].

   The ALTO base protocol document [RFC7285] specifies the communication
   between an ALTO client and one ALTO server.  In principle, the client
   may send any ALTO query.  For example, it might ask for the routing
   cost between any two IP addresses, or it might request network and
   cost maps for the whole network, which might be the worldwide
   Internet.  It is assumed that the server can answer any query,
   possibly with some kind of default value if no exact data is known.

   No special provisions were made for deployment scenarios with
   multiple ALTO servers, with some servers having more accurate
   information about some parts of the network topology while others
   having better information about other parts of the network
   ("partitioned knowledge").  Various ALTO use cases have been studied
   in the context of such scenarios.  In some cases, one cannot assume
   that a topologically nearby ALTO server (e.g., a server discovered
   with the procedure specified in [RFC7286]) will always provide useful
   information to the client.  One such scenario is detailed in
   Appendix C.  Several solution approaches, such as redirecting a
   client to a server that has more accurate information or forwarding
   the request to it on behalf of the client, have been proposed and
   analyzed (see Appendix A), but none has been specified so far.

   Section 3 of this document specifies the "ALTO Cross-Domain Server
   Discovery Procedure" for client-side usage in these scenarios.  An
   ALTO client that wants to send an ALTO query related to a specific IP
   address or prefix X, may call this procedure with X as a paramenter.
   It will use Domain Name System (DNS) lookups to find of one ore more
   ALTO servers that can provide a competent answer.  The above wording
   "related to" was intentionally kept somewhat unspecific, as the exact
   semantics depends on the ALTO service to be used; see Section 4.

   Those who are in control of the "reverse DNS" for a given IP address
   or prefix (i.e., the corresponding subdomain of in-addr.arpa. or
   ip6.arpa.) - typically an Internet Service Provider (ISP), a
   corporate IT department, or a university's computing center - may add
   resource records to the DNS that point to one or more relevant ALTO
   server(s).  In many cases, it may be an ALTO server run by that ISP
   or IT department, as they naturally have good insight into routing
   costs from and to their networks.  However, they may also refer to an
   ALTO server provided by someone else, e.g., their upstream ISP.

Kiesel & Stiemerling    Expires February 21, 2020               [Page 4]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

2.  ALTO Cross-Domain Server Discovery Procedure: Overview

   This section gives a non-normative overview on the ALTO Cross-Domain
   Server Discovery Procedure.  The detailed specification will follow
   in the next section.

   This procedure was inspired by the "Location Information Server (LIS)
   Discovery Using IP Addresses and Reverse DNS" [RFC7216] and re-uses
   parts of the basic ALTO Server Discovery Procedure [RFC7286].

   The basic idea is to use the Domain Name System (DNS), more
   specifically the "in-addr.arpa." or "ip6.arpa." trees, which are
   mostly used for "reverse mapping" of IP addresses to host names by
   means of PTR resource records.  There, URI-enabled Naming Authority
   Pointer (U-NAPTR) resource records [RFC4848], which allow the mapping
   of domain names to Uniform Resource Identifiers (URIs), are installed
   as needed.  Thereby, it is possible to store a mapping from an IP
   address or prefix to one or more ALTO server URIs in the DNS.

   The ALTO Cross-Domain Server Discovery Procedure is called with one
   IP address or prefix and a U-NAPTR Service Parameter [RFC4848] as
   parameters.

   The service parameter is usually set to "ALTO:https".  However, other
   parameter values may be used in some scenarios, e.g., "ALTO:http" to
   search for a server that supports unencrypted transmission for
   debugging purposes, or other application protocol or service tags if
   applicable.

   The procedure performs DNS lookups and returns one or more URI(s) of
   information resources related to said IP address or prefix, usually
   the URI(s) of one or more ALTO Information Resource Directory (IRD,
   see Section 9 of [RFC7285]).  The U-NAPTR records also provide
   preference values, which should be considered if more than one URI is
   returned.

   The discovery procedure sequentially tries two different lookup
   strategies: First, an ALTO-specific U-NAPTR record is searched in the
   "reverse tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa.
   corresponding to the given IP address or prefix.  If this lookup does
   not yield a usable result, the procedure tries further lookups with
   truncated domain names, which correspond to shorter prefix lengths.
   The goal is to allow deployment scenarios that require fine-grained
   discovery on a per-IP basis, as well as large-scale scenarios where
   discovery is to be enabled for a large number of IP addresses with a
   small number of additional DNS resource records.

Kiesel & Stiemerling    Expires February 21, 2020               [Page 5]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

3.  ALTO Cross-Domain Server Discovery Procedure: Specification

3.1.  Interface

   The procedure specified in this document takes two parameters, X and
   SP, where X is an IP address or prefix and SP is a U-NAPTR Service
   Parameter.

   The parameter X may be an IPv4 or an IPv6 address or prefix in CIDR
   notation (see [RFC4632] for the IPv4 CIDR notation and [RFC4291] for
   IPv6).  Consequently, the address type AT is either "IPv4" or "IPv6".
   In both cases, X consists of an IP address A and a prefix length L.
   From the definition of IPv4 and IPv6 it follows that syntactically
   valid values for L are 0 <= L <= 32 when AT=IPv4 and 0 <= L <= 128
   when AT=IPv6.  However, not all syntactically valid values of L are
   actually supported by this procedure - Step 1 (see below) will check
   for unsupported values and report an error if neccessary.

   For example, for X=198.51.100.0/24, we get AT=IPv4, A=198.51.100.0
   and L=24.  Similarly, for X=2001:0DB8::20/128, we get AT=IPv6,
   A=2001:0DB8::20 and L=128.

   In the intended usage scenario, the procedure is normally always
   called with the parameter SP set to "ALTO:https".  However, for
   general applicabiliy and in order to support future extensions, the
   procedure MUST support being called with any valid U-NAPTR Service
   Parameter (see Section 4.5. of [RFC4848] for the syntax of U-NAPTR
   Service Parameters and Section 5. of the same document for
   information about the IANA registries).

   The procedure performs DNS lookups and returns one or more URI(s) of
   information resources related to that IP address or prefix, usually
   the URI(s) of one or more ALTO Information Resource Directory (IRD,
   see Section 9 of [RFC7285]).  For each URI, it also returns order and
   preference values (see Section 4.1 of [RFC3403]), which should be
   considered if more than one URI is returned.

   During execution of this procedure, various error conditions may
   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
   calling the ALTO Cross-Domain Server Discovery Procedure:

      IRD_URIS_X = XDOMDISC(X,"ALTO:https")

Kiesel & Stiemerling    Expires February 21, 2020               [Page 6]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

3.2.  Step 1: Prepare Domain Name for Reverse DNS Lookup

   First, the procedure checks the prefix length L for unsupported
   values: If AT=IPv4 (i.e., if A is an IPv4 address) and L < 8, the
   procedure aborts and indicates an "unsupported prefix length" error
   to the caller.  Similarly, if AT=IPv6 and L < 32, the procedure
   aborts and indicates an "unsupported prefix length" error to the
   caller.  Otherwise, the procedure continues.

   If AT=IPv4, the procedure will then produce a DNS domain name, which
   will be referred to as R32.  This domain name is constructed
   according to the rules specified in Section 3.5 of [RFC1035] and it
   is rooted in the special domain "IN-ADDR.ARPA.".

   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
   according to the rules specified in Section 2.5 of [RFC3596] and the
   special domain "IP6.ARPA." is used.

   For example (note: a line break was added after the second line),
   A = 2001:0DB8::20    yields
   R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
           1.0.0.2.IP6.ARPA."

Kiesel & Stiemerling    Expires February 21, 2020               [Page 7]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

3.3.  Step 2: Prepare Shortened Domain Names

   For this step, an auxiliary function "skip" is defined as follows:
   skip(str,n) will skip all characters in the string str, up to and
   including the n-th dot, and return the remaining part of str.  For
   example, skip("foo.bar.baz.qux.quux.",2) will return "baz.qux.quux.".

   If AT=IPv4, the following additional domain names are generated from
   the result of the previous step:

      R24=skip(R32,1),

      R16=skip(R32,2), and

      R8=skip(R32,3).

   Removing one label from a domain name (i.e., one number of the
   "dotted quad notation") corresponds to shortening the prefix length
   by 8 bits.

   For example, R32="3.100.51.198.IN-ADDR.ARPA." yields
   R24="100.51.198.IN-ADDR.ARPA.", R16="51.198.IN-ADDR.ARPA.", and
   R8="198.IN-ADDR.ARPA.".

   If AT=IPv6, the following additional domain names are generated from
   the result of the previous step:

      R64=skip(R128,16),

      R56=skip(R128,18),

      R48=skip(R128,20),

      R40=skip(R128,22), and

      R32=skip(R128,24).

   Removing one label from a domain name (i.e., one hex digit)
   corresponds to shortening the prefix length by 4 bits.

   For example (note: a line break was added after the first line),
   R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
           1.0.0.2.IP6.ARPA."    yields
   R64  = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
   R56  = "0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
   R48  = "0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
   R40  = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and
   R32  = "8.B.D.0.1.0.0.2.IP6.ARPA.".

Kiesel & Stiemerling    Expires February 21, 2020               [Page 8]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

3.4.  Step 3: Perform DNS U-NAPTR lookups

   The address type and the prefix length of X are matched against the
   first and the second column of the following table, respectively:

   +------------+------------+------------+----------------------------+
   | 1: Address | 2: Prefix  | 3: MUST do | 4: SHOULD do further       |
   | Type AT    | Length L   | 1st lookup | lookups in that order      |
   +------------+------------+------------+----------------------------+
   | IPv4       |        32  |  R32       | R24, R16, R8               |
   | IPv4       |  24 .. 31  |  R24       | R16, R8                    |
   | IPv4       |  16 .. 23  |  R16       | R8                         |
   | IPv4       |   8 .. 15  |   R8       | (none)                     |
   | IPv4       |   0 ..  7  | (none, abort: unsupported prefix length)|
   +------------+------------+------------+----------------------------+
   | IPv6       |       128  | R128       | R64, R56, R48, R40, R32    |
   | IPv6       | 64 (..127) |  R64       | R56, R48, R40, R32         |
   | 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)|
   +------------+------------+------------+----------------------------+

   Then, the domain name given in the 3rd column and the U-NAPTR Service
   Parameter SP the procedure was called with (usually "ALTO:https")
   MUST be used for an U-NAPTR [RFC4848] lookup, in order to obtain one
   or more URIs (indicating protocol, host, and possibly path elements)
   for the ALTO server's Information Resource Directory (IRD).  If such
   URI(s) can be found, the ALTO Cross-Domain Server Discovery Procedure
   returns that information to the caller and terminates successfully.

   For example, the following two U-NAPTR resource records can be used
   for mapping "100.51.198.IN-ADDR.ARPA." (i.e., R24 from the example in
   the previous step) to the HTTPS URIs "https://alto1.example.net/ird"
   and "https://alto2.example.net/ird", with the former being preferred.

       100.51.198.IN-ADDR.ARPA.  IN NAPTR 100  10  "u"  "ALTO:https"
            "!.*!https://alto1.example.net/ird!"  ""

       100.51.198.IN-ADDR.ARPA.  IN NAPTR 100  20  "u"  "ALTO:https"
            "!.*!https://alto2.example.net/ird!"  ""

   If no matching U-NAPTR records can be found, the procedure SHOULD try
   further lookups, using the domain names from the fourth column in the
   indicated order, until one lookup succeeds.  If no IRD URI could be
   found after looking up all domain names from the 3rd and 4th column,
   the procedure terminates unsuccessfully, returning an empty URI list.

Kiesel & Stiemerling    Expires February 21, 2020               [Page 9]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

3.5.  Error Handling

   The ALTO Cross-Domain Server Discovery Procedure may fail for several
   reasons.

   If the procedure is called with syntactically invalid parameters or
   unsupported parameter values (in particular the prefix length L, see
   Section 3.2), the procedure aborts, no URI list will be returned and
   the error has to be reported to the caller.

   The procedure performs one or more DNS lookups in a well-defined
   order (corresponding to descending prefix lengths, see Section 3.4),
   until one produces a usable result.  Each of these DNS lookups might
   not produce a usable result, either due to a normal condition (e.g.,
   domain name exists, but no ALTO-specific NAPTR resource records are
   associated with it), a permanent error (e.g., non-existent domain
   name), or due to a temporary error (e.g., timeout).  In all three
   cases, and as long as there are further domain names that can be
   looked up, the procedure SHOULD immediately try to lookup the next
   domain name (from column 4 in the table given in Section 3.4).  Only
   after all domain names have been tried at least once, the procedure
   MAY retry those domain names that had caused temporary lookup errors.

   Generally speaking, ALTO provides advisory information for the
   optimization of applications (e.g., peer-to-peer applications,
   overlay networks, etc.), but applications should not rely on the
   availability of such information for their basic functionality (see
   Section 8.3.4.3 of RFC 7285 [RFC7285]).  Consequently, the speedy
   detection of an ALTO server, even though it may give less accurate
   answers than other servers, or the quick realization that there is no
   suitable ALTO server, is in general more preferable than causing long
   delays by retrying failed queries.  Nevertheless, the ALTO Cross-
   Domain Server Discovery Procedure SHOULD inform its caller, if DNS
   queries have failed due to temporary errors and that retrying the
   discovery at a later point in time might give more accurate results.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 10]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

4.  Using the ALTO Protocol with Cross-Domain Server Discovery

   Based on a modular design principle, ALTO provides several ALTO
   services, each consisting of a set of information resouces that can
   be accessed using the ALTO protocol.  The information resources that
   are available at a specific ALTO server are listed in its Information
   Resource Directory (IRD, see Section 9 of [RFC7285]).  The ALTO
   protocol specification defines the following ALTO services and their
   corresponding information resouces:

   o  Network and Cost Map Service, see Section 11.2 of [RFC7285]

   o  Map-Filtering Service, see Section 11.3 of [RFC7285]

   o  Endpoint Property Service, see Section 11.4 of [RFC7285]

   o  Endpoint Cost Service, see Section 11.5 of [RFC7285]

   The ALTO Cross-Domain Server Discovery Procedure is most useful in
   conjunction with the Endpoint Property Service and the Endpoint Cost
   Service.  However, for the sake of completeness, possible interaction
   with all four services is discussed below.  Extension documents may
   specify further information resources; however, these are out of
   scope of this document.

4.1.  Network and Cost Map Service

   An ALTO client may invoke the ALTO Cross-Domain Server Discovery
   Procedure (as specified in Section 3) for an IP address or prefix "X"
   and get a list of one or more IRD URI(s), including order and
   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
   map, as these are mandatory information resources (see Section 11.2
   of [RFC7285]).  However, the cost matrix may be very sparse.  If,
   according to the network map, PID_X is the PID 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:

   From \ To PID_1    PID_2    PID_X    PID_3
   ------+-----------------------------------
   PID_1 |                        92
   PID_2 |                         6
   PID_X |      46        3        1       19
   PID_3 |                        38

   In this example, all cells outside column "X" and row "X" are
   unspecified.  A cost map with this structure contains the same
   information as what could be retrieved using the Endpoint Cost

Kiesel & Stiemerling    Expires February 21, 2020              [Page 11]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

   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.

   Trying to assemble a more densely populated cost map from several
   cost maps with this very sparse structure may be a non-trivial task,
   as different ALTO servers may use different PID definitions (i.e.,
   network maps) and incompatible scales for the costs, in particular
   for the "routingcost" metric.

4.2.  Map-Filtering Service

   An ALTO client may invoke the ALTO Cross-Domain Server Discovery
   Procedure (as specified in Section 3) for an IP address or prefix "X"
   and get a list of one or more IRD URI(s), including order and
   preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https").  These
   IRD(s) may provide the optional Map-Filtering Service (see Section
   11.3 of [RFC7285]).  This service returns a subset of the full map,
   as specified by the client.  As discussed in Section 4.1, a cost map
   may be very sparse in the envisioned deployment scenario.  Therefore,
   depending on the filtering criteria provided by the client, this
   service may return results similar to the Endpoint Cost Service, or
   it may not return any useful result.

4.3.  Endpoint Property Service

   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
   "X" or a group of endpoints within IP prefix "X", respectively, it
   has to invoke the ALTO Cross-Domain Server Discovery Procedure (as
   specified in Section 3): IRD_URIS_X = XDOMDISC(X,"ALTO:https").  The
   result IRD_URIS_X is a list of one or more URIs of Information
   Resource Directories (IRD, see Section 9 of [RFC7285]).  Considering
   the order and preference values, the client has to check these IRDs
   for a suitable Endpoint Property Service and query it.

   If the ALTO client wants to do a similar Endpoint Property query for
   a different IP address or prefix "Y", the whole procedure has to be
   repeated, as IRD_URIS_Y = XDOMDISC(Y,"ALTO:https") may yield a
   different list of IRD URIs.  Of course, the results of individual DNS
   queries may be cached as indicated by their respective time-to-live
   (TTL) values.

4.4.  Endpoint Cost Service

   The optional ALTO Endpoint Cost Service (ECS, see Section 11.5 of RFC
   7285 [RFC7285]) provides information about costs between individual
   endpoints and it also supports ranking.  The ECS allows that
   endpoints may be denoted by IP addresses or prefixes.  The ECS is

Kiesel & Stiemerling    Expires February 21, 2020              [Page 12]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

   called with a list of one or more source IP addresses or prefixes,
   which we will call (S1, S2, S3, ...), and a list of one or more
   destination IP addresses or prefixes, called (D1, D2, D3, ...).

   This specification distinguishes several cases, regarding the number
   of elements in the list of source and destination addresses,
   respectively:

   1.  Exactly one source address S1 and more than one destination
       addresses D1, D2, D3, ...  In this case, the ALTO client has to
       invoke the ALTO Cross-Domain Server Discovery Procedure (as
       specified in Section 3) with that single source address as a
       parameter: IRD_URIS_S1 = XDOMDISC(S1,"ALTO:https").  The result
       IRD_URIS_S1 is a list of one or more URIs of Information Resource
       Directories (IRD, see Section 9 of [RFC7285]).  Considering the
       order and preference values, the client has to check these IRDs
       for a suitable Endpoint Cost Service and query it.  The ECS is an
       optional service (see Section 11.5.1 of RFC 7285 [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
       with the single source address as a parameter - as opposed to
       multiple calls, e.g., one for each destination address - is not
       only a matter of efficiency.  In the given scenario, it is
       advisable to send all ECS queries to the same ALTO server.  This
       ensures that the results can be compared (e.g., for sorting
       candidate resource providers), even with cost metrics without a
       well-defined base unit, e.g., the "routingcost" metric.

   2.  More than one source addresses S1, S2, S3, ... and exactly one
       destination address D1.  In this case, the ALTO client has to
       invoke the ALTO Cross-Domain Server Discovery Procedure with that
       single destination address as a parameter:
       IRD_URIS_D1 = XDOMDISC(D1,"ALTO:https").  The result IRD_URIS_D1
       is a list of one or more URIs of IRDs.  Considering the order and
       preference values, the client has to check these IRDs for a
       suitable ECS and query it.

   3.  Exactly one source address S1 and exactly one destination address
       D1.  The ALTO client may perform the same steps as in case 1, as
       specified above.  As an alternative, it may also perform the same
       steps as in case 2, as specified above.

   4.  More than one source addresses S1, S2, S3, ... and more than one
       destination addresses D1, D2, D3, ...  In this case, the ALTO
       client should split the list of desired queries based on source
       addresses and perform separately for each source address the same
       steps as in case 1, as specified above.  As an alternative, the

Kiesel & Stiemerling    Expires February 21, 2020              [Page 13]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

       ALTO client may also group the list based on destination
       addresses and perform separately for each destination address the
       same steps as in case 2, as specified above.  However, comparing
       results between these sub-queries may be difficult, in particular
       if the cost metric is a relative preference without a well-
       defined base unit (e.g., the "routingcost" metric).

   See Appendix C for a detailed example showing the interaction of a
   tracker-based peer-to-peer application, the ALTO Endpoint Cost
   Service, and the ALTO Cross-Domain Server Discovery Procedure.

4.5.  Summary and Further Extensions

   Considering the four services defined in the ALTO base protocol
   specification [RFC7285], the ALTO Cross-Domain Server Discovery
   Procedure works best with the Endpoint Property Service (EPS) and the
   Endpoint Cost Service (ECS).  Both the EPS and the ECS take one or
   more IP addresses as a parameter.  The previous sections specify how
   the parameter for calling the ALTO Cross-Domain Server Discovery
   Procedure has to be derived from these IP adresses.

   In contrast, the ALTO Cross-Domain Server Discovery Procedure seems
   less useful if the goal is to retrieve network and cost maps that
   cover the whole network topology.  However, the procedure may be
   useful if a map centered at a specific IP address is desired (i.e., a
   map detailing the vicinity of said IP address or a map giving costs
   from said IP address to all potential destinations).

   The interaction between further ALTO services (and their
   corresponding information resources) needs to be investigated and
   defined once such further ALTO services are specified in an extension
   document.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 14]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

5.  Implementation, Deployment, and Operational Considerations

5.1.  Considerations for ALTO Clients

5.1.1.  Resource Consumer Initiated Discovery

   Resource consumer initiated ALTO server discovery (c.f.  ALTO
   requirement AR-32 [RFC6708]) can be seen as a special case of cross-
   domain ALTO server discovery.  To that end, an ALTO client embedded
   in a resource consumer would have to perform the ALTO Cross-Domain
   Server Discovery Procedure with its own IP address as a parameter.
   However, due to the widespread deployment of Network Address
   Translators (NAT), additional protocols and mechanisms such as STUN
   [RFC5389] are usually needed to detect the client's "public" IP
   address, before it can be used as a parameter to the discovery
   procedure.  Note that a different approach for resource consumer
   initiated ALTO server discovery, which is based on DHCP, is specified
   in [RFC7286].

5.1.2.  IPv4/v6 Dual Stack, Multihoming and Host Mobility

   The procedure specified in this document can discover ALTO server
   URIs for a given IP address or prefix.  The intention is, that a
   third party (e.g., a resource directory) that receives query messages
   from a resource consumer can use the source address in these messages
   to discover suitable ALTO servers for this specific resource
   consumer.

   However, resource consumers (as defined in Section 2 of [RFC5693])
   may reside on hosts with more than one IP address, e.g., due to
   IPv4/v6 dual stack operation and/or multihoming.  IP packets sent
   with different source addresses may be subject to different routing
   policies and path costs.  In some deployment scenarios, it may even
   be required to ask different sets of ALTO servers for guidance.
   Furthermore, source addresses in IP packets may be modified en-route
   by Network Address Translators (NAT).

   If a resource consumer queries a resource directory for candidate
   resource providers, the locally selected (and possibly en-route
   translated) source address of the query message - as observed by the
   resource directory - will become the basis for the ALTO server
   discovery and the subsequent optimization of the resource directory's
   reply.  If, however, the resource consumer then selects different
   source addresses to contact returned resource providers, the desired
   better-than-random "ALTO effect" may not occur.

   One solution approach for this problem is, that a dual stack or
   multihomed resource consumer could always use the same address for

Kiesel & Stiemerling    Expires February 21, 2020              [Page 15]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

   contacting the resource directory and all resource providers, thus
   overriding the operating system's automatic source IP address
   selection.  For example, when using the BSD socket API, one could
   always bind() the socket to one of the local IP addresses before
   trying to connect() to the resource directory or the resource
   providers, respectively.  Another solution approach is to perform
   ALTO-influenced resource provider selection (and source address
   selection) locally in the resource consumer, in addition to or
   instead of performing it in the resource directory.  See
   Section 5.1.1 for a discussion how to discover ALTO servers for local
   usage in the resource consumer.

   Similarly, resource consumers on mobile hosts SHOULD query the
   resource directory again after a change of IP address, in order to
   get a list of candidate resource providers that is optimized for the
   new IP address.

5.1.3.  Interaction with Network Address Translation

   The ALTO Cross-Domain Server Discovery Procedure has been designed to
   enable the ALTO-based optimization of applications such as large-
   scale overlay networks, that span - on the IP layer - multiple
   adminstrative domains, possibly the whole Internet.  Due to the
   widespread usage of Network Address Translators (NAT) it may well be
   that nodes of the overlay network (i.e., resource consumers or
   resource providers) are located behind a NAT, maybe even behind
   several cascaded NATs.

   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 one or more NATs, the message's source address will be the
   public IP address of the outermost NAT in front of the resource
   consumer.  The same applies if the resource directory is behind a
   different NAT than the resource consumer.  The resource directory may
   call the ALTO Cross-Domain Server Discovery Procedure with the
   message's source address as a parameter.  In effect, not the resource
   consumer's (private) IP address, but the public IP address of the
   outermost NAT in front of it will be used as a basis for ALTO-
   optimization.  This will work fine as long as the network behind the
   NAT is not too big (e.g., if the NAT is in a residential gateway).

   If a resource directory receives a message from a resource consumer
   and the message's source address is a "private" IP address [RFC1918],
   this may be a sign that both of them are behind the same NAT.  An
   invokation of the ALTO Cross-Domain Server Discovery Procedure with
   this private address may be problematic, as this will only yield
   usable results if a DNS "split horizon" and DNSSEC trust anchors are
   configured correctly.  In this situation it may be more advisable to

Kiesel & Stiemerling    Expires February 21, 2020              [Page 16]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

   query an ALTO server that has been discovered using [RFC7286] or any
   other local configuration.  The interaction between intra-domain ALTO
   for large private domains (e.g., behind a "carrier-grade NAT") and
   cross-domain, Internet-wide optimization, is beyond the scope of this
   document.

5.2.  Considerations for Network Operators

5.2.1.  Flexibility vs. Load on the DNS

   The ALTO Cross-Domain Server Discovery Procedure, as specified in
   Section 3, first produces a list of domain names (steps 1 and 2) and
   then looks for relevant NAPTR records associated with these names,
   until a useful result can be found (step 3).  The number of candidate
   domain names on this list is a compromise between flexibility when
   installing NAPTR records and avoiding excess load on the DNS.

   A single invocation of the ALTO Cross-Domain Server Discovery
   Procedure, with an IPv6 address as a parameter, may cause up to, but
   no more than, six DNS lookups for NAPTR records.  For IPv4, the
   maximum is four lookups.  Should the load on the DNS infrastructure
   caused by these lookups become a problem, one solution approach is to
   actually populate the DNS with ALTO-specific NAPTR records.  If such
   records can be found for individual IP addresses (possibly installed
   using a wildcarding mechanism in the name server) or for long
   prefixes, the procedure will terminate successfully and not perform
   lookups for shorter prefix lengths, thus reducing the total number of
   DNS queries.  Another approach for reducing the load on the DNS
   infrastructure is to increase the TTL for caching negative answers.

   On the other hand, the ALTO Cross-Domain Server Discovery Procedure
   trying to lookup truncated domain names allows for efficient
   configuration of large-scale scenarios, where discovery is to be
   enabled for a large number of IP addresses with a small number of
   additional DNS resource records.  Note that expressly, it has not
   been a design goal of this procedure to give clients a means to
   understand the IP prefix delegation structure.  Furthermore, this
   specification does not assume or reccomend that prefix delegations
   should preferrably occur at those prefix lengths that are used in
   Step 2 of this procedure (see Section 3.3).  A network operator that
   uses, for example, an IPv4 /18 prefix and wants to install the NAPTR
   records efficiently, could either install 64 NAPTR records (one for
   each of the /24 prefixes contained within the /18 prefix), or they
   could try to team up with the owners of the other fragments of the
   enclosing /16 prefix, in order to run a common ALTO server to which
   only one NAPTR would point.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 17]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

5.2.2.  BCP20 and missing delegations of the reverse DNS

   RFC2317 [RFC2317], also known as BCP20, describes a way to delegate
   the "reverse DNS" (i.e., subdomains of in-addr.arpa.) for IPv4
   address ranges with fewer than 256 addresses (i.e., less than a whole
   /24 prefix).  The ALTO Cross-Domain Server Discovery procedure is
   compatible with this method.

   In some deployment scenarios, e.g., residential Internet access,
   where customers often dynamically receive a single IPv4 address
   (and/or a small IPv6 address block) from a pool of addresses, ISPs
   typically will not delegate the "reverse DNS" to their customers.
   This practice makes it impossible for these customers to populate the
   DNS with NAPTR resource records that point to an ALTO server of their
   choice.  Yet, the ISP may publish NAPTR resource records in the
   "reverse DNS" for individual addresses or larger address pools (i.e.,
   shorter prefix lengths).

   While ALTO is by no means technologically tied to the Border Gateway
   Protocol (BGP), it is anticipated that BGP will be an important
   source of information for ALTO and that the operator of the outermost
   BGP-enabled router will have a strong incentive to publish a digest
   of their routing policies and costs through ALTO.  In contrast, an
   individual user or an organization that has been assigned only a
   small address range (i.e., an IPv4 prefix with a prefix length longer
   than /24) will typically connect to the Internet using only a single
   ISP, and they might not be interested in publishing their own ALTO
   information.  Consequently, they might wish to leave the operation of
   an ALTO server up to their ISP.  This ISP may install NAPTR resource
   records, which are needed for the ALTO Cross-Domain Server Discovery
   procedure, in the subdomain of in-addr.arpa. that corresponds to the
   whole /24 prefix (c.f., R24 in Section 3.3 of this document), even if
   BCP20-style delegations or no delegations at all are in use.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 18]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

6.  Security Considerations

   A high-level discussion of security issues related to ALTO is part of
   the ALTO problem statement [RFC5693].  A classification of unwanted
   information disclosure risks, as well as specific security-related
   requirements can be found in the ALTO requirements document
   [RFC6708].

   The remainder of this section focuses on security threats and
   protection mechanisms for the cross-domain ALTO server discovery
   procedure as such.  Once the ALTO server's URI has been discovered
   and the communication between the ALTO client and the ALTO server
   starts, the security threats and protection mechanisms discussed in
   the ALTO protocol specification [RFC7285] apply.

6.1.  Integrity of the ALTO Server's URI

   Scenario Description
      An attacker could compromise the ALTO server discovery procedure
      or the underlying infrastructure in a way that ALTO clients would
      discover a "wrong" ALTO server URI.

   Threat Discussion
      The cross-domain ALTO server discovery procedure relies on a
      series of DNS lookups, in order to produce one or more URI(s).  If
      an attacker was able to modify or spoof any of the DNS records,
      the resulting URI(s) could be replaced by forged URI(s).  This is
      probably the most serious security concern related to ALTO server
      discovery.  The discovered "wrong" ALTO server might not be able
      to give guidance to a given ALTO client at all, or it might give
      suboptimal or forged information.  In the latter case, an attacker
      could try to use ALTO to affect the traffic distribution in the
      network or the performance of applications (see also Section 15.1.
      of [RFC7285]).  Furthermore, a hostile ALTO server could threaten
      user privacy (see also Section 5.2.1, case (5a) in [RFC6708]).

   Protection Strategies and Mechanisms
      The application of DNS security (DNSSEC) [RFC4033] provides a
      means to detect and avert attacks that rely on modification of the
      DNS records while in transit.  All implementations of the cross-
      domain ALTO server discovery procedure MUST support DNSSEC or be
      able to use such functionality provided by the underlying
      operating system.  Network operators that publish U-NAPTR resource
      records to be used for the cross-domain ALTO server discovery
      procedure SHOULD use DNSSEC to protect their subdomains of in-
      addr.arpa. and/or ip6.arpa., respectively.  Additional operational
      precautions for safely operating the DNS infrastructure are
      required in order to ensure that name servers do not sign forged

Kiesel & Stiemerling    Expires February 21, 2020              [Page 19]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

      (or otherwise "wrong") resource records.  Security considerations
      specific to U-NAPTR are described in more detail in [RFC4848].

      In addition to active protection mechanisms, users and network
      operators can monitor application performance and network traffic
      patterns for poor performance or abnormalities.  If it turns out
      that relying on the guidance of a specific ALTO server does not
      result in better-than-random results, the usage of the ALTO server
      may be discontinued (see also Section 15.2 of [RFC7285]).

   Note
      The cross-domain ALTO server discovery procedure finishes
      successfully when it has discovered one or more URI(s).  Once an
      ALTO server's URI has been discovered and the communication
      between the ALTO client and the ALTO server starts, the security
      threats and protection mechanisms discussed in the ALTO protocol
      specification [RFC7285] apply.

      A threat related to the one considered above is the impersonation
      of an ALTO server after its correct URI has been discovered.  This
      threat and protection strategies are discussed in Section 15.1 of
      [RFC7285].  The ALTO protocol's primary mechanism for protecting
      authenticity and integrity (as well as confidentiality) is the use
      of HTTPS-based transport, i.e., HTTP over TLS [RFC2818].
      Typically, when the URI's host component is a host name, a further
      DNS lookup is needed to map it to an IP address, before the
      communication with the server can begin.  This last DNS lookup
      (for A or AAAA resource records) does not necessarily have to be
      protected by DNSSEC, as the server identity checks specified in
      [RFC2818] are able to detect DNS spoofing or similar attacks,
      after the connection to the (possibly wrong) host has been
      established.  However, this validation, which is based on the
      server certificate, can only protect the steps that occur after
      the server URI has been discovered.  It cannot detect attacks
      against the authenticity of the U-NAPTR lookups needed for the
      cross-domain ALTO server discovery procedure, and therefore, these
      resource records have to be secured using DNSSEC.

6.2.  Availability of the ALTO Server Discovery Procedure

   Scenario Description
      An attacker could compromise the cross-domain ALTO server
      discovery procedure or the underlying infrastructure in a way that
      ALTO clients would not be able to discover any ALTO server.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 20]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

   Threat Discussion
      If no ALTO server can be discovered (although a suitable one
      exists) applications have to make their decisions without ALTO
      guidance.  As ALTO could be temporarily unavailable for many
      reasons, applications must be prepared to do so.  However, The
      resulting application performance and traffic distribution will
      correspond to a deployment scenario without ALTO.

   Protection Strategies and Mechanisms
      Operators should follow best current practices to secure their DNS
      and ALTO (see Section 15.5 of [RFC7285]) servers against Denial-
      of-Service (DoS) attacks.

6.3.  Confidentiality of the ALTO Server's URI

   Scenario Description
      An unauthorized party could invoke the cross-domain ALTO server
      discovery procedure, or intercept discovery messages between an
      authorized ALTO client and the DNS servers, in order to acquire
      knowledge of the ALTO server URI for a specific IP address.

   Threat Discussion
      In the ALTO use cases that have been described in the ALTO problem
      statement [RFC5693] and/or discussed in the ALTO working group,
      the ALTO server's URI as such has always been considered as public
      information that does not need protection of confidentiality.

   Protection Strategies and Mechanisms
      No protection mechanisms for this scenario have been provided, as
      it has not been identified as a relevant threat.  However, if a
      new use case is identified that requires this kind of protection,
      the suitability of this ALTO server discovery procedure as well as
      possible security extensions have to be re-evaluated thoroughly.

6.4.  Privacy for ALTO Clients

   Scenario Description
      An unauthorized party could eavesdrop on the messages between an
      ALTO client and the DNS servers, and thereby find out the fact
      that said ALTO client uses (or at least tries to use) the ALTO
      service in order to optimize traffic from/to a specific IP
      address.

   Threat Discussion
      In the ALTO use cases that have been described in the ALTO problem
      statement [RFC5693] and/or discussed in the ALTO working group,
      this scenario has not been identified as a relevant threat.
      However, Pervasive Surveillance [RFC7624] and DNS Privacy

Kiesel & Stiemerling    Expires February 21, 2020              [Page 21]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

      Considerations [RFC7626] have seen significant attention in the
      Internet community in recent years.

   Protection Strategies and Mechanisms
      DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] provide means
      for protecting confidentiality (and integrity) of DNS traffic
      between a client (stub) and its recursive name servers, including
      DNS queries and replies caused by the ALTO Cross-Domain Server
      Discovery Procedure.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 22]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

7.  IANA Considerations

   This document does not require any IANA action.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 23]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

8.  References

8.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Three: The Domain Name System (DNS) Database",
              RFC 3403, DOI 10.17487/RFC3403, October 2002,
              <https://www.rfc-editor.org/info/rfc3403>.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", STD 88,
              RFC 3596, DOI 10.17487/RFC3596, October 2003,
              <https://www.rfc-editor.org/info/rfc3596>.

   [RFC4848]  Daigle, L., "Domain-Based Application Service Location
              Using URIs and the Dynamic Delegation Discovery Service
              (DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007,
              <https://www.rfc-editor.org/info/rfc4848>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [I-D.kiesel-alto-alto4alto]
              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
              Optimization (ALTO) Anycast Address",
              draft-kiesel-alto-ip-based-srv-disc-03 (work in progress),
              July 2014.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,

Kiesel & Stiemerling    Expires February 21, 2020              [Page 24]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

              <https://www.rfc-editor.org/info/rfc1918>.

   [RFC2317]  Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
              ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/
              RFC2317, March 1998,
              <https://www.rfc-editor.org/info/rfc2317>.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
              RFC2818, May 2000,
              <https://www.rfc-editor.org/info/rfc2818>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291,
              February 2006, <https://www.rfc-editor.org/info/rfc4291>.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632,
              August 2006, <https://www.rfc-editor.org/info/rfc4632>.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              DOI 10.17487/RFC5389, October 2008,
              <https://www.rfc-editor.org/info/rfc5389>.

   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693,
              DOI 10.17487/RFC5693, October 2009,
              <https://www.rfc-editor.org/info/rfc5693>.

   [RFC6708]  Kiesel, S., Ed., Previdi, S., Stiemerling, M., Woundy, R.,
              and Y. Yang, "Application-Layer Traffic Optimization
              (ALTO) Requirements", RFC 6708, DOI 10.17487/RFC6708,
              September 2012, <https://www.rfc-editor.org/info/rfc6708>.

   [RFC7216]  Thomson, M. and R. Bellis, "Location Information Server
              (LIS) Discovery Using IP Addresses and Reverse DNS",
              RFC 7216, DOI 10.17487/RFC7216, April 2014,
              <https://www.rfc-editor.org/info/rfc7216>.

   [RFC7285]  Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
              Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
              "Application-Layer Traffic Optimization (ALTO) Protocol",

Kiesel & Stiemerling    Expires February 21, 2020              [Page 25]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

              RFC 7285, DOI 10.17487/RFC7285, September 2014,
              <https://www.rfc-editor.org/info/rfc7285>.

   [RFC7286]  Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
              H. Song, "Application-Layer Traffic Optimization (ALTO)
              Server Discovery", RFC 7286, DOI 10.17487/RFC7286,
              November 2014, <https://www.rfc-editor.org/info/rfc7286>.

   [RFC7624]  Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
              Trammell, B., Huitema, C., and D. Borkmann,
              "Confidentiality in the Face of Pervasive Surveillance: A
              Threat Model and Problem Statement", RFC 7624,
              DOI 10.17487/RFC7624, August 2015,
              <https://www.rfc-editor.org/info/rfc7624>.

   [RFC7626]  Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
              DOI 10.17487/RFC7626, August 2015,
              <https://www.rfc-editor.org/info/rfc7626>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858,
              May 2016, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC7971]  Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and
              S. Previdi, "Application-Layer Traffic Optimization (ALTO)
              Deployment Considerations", RFC 7971, DOI 10.17487/
              RFC7971, October 2016,
              <https://www.rfc-editor.org/info/rfc7971>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 26]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

Appendix A.  Solution Approaches for Partitioned ALTO Knowledge

   The ALTO base protocol document [RFC7285] specifies the communication
   between an ALTO client and a single ALTO server.  It is implicitly
   assumed that this server can answer any query, possibly with some
   kind of default value if no exact data is known.  No special
   provisions were made for the case that the ALTO information
   originates from multiple sources, which are possibly under the
   control of different administrative entities (e.g., different ISPs)
   or that the overall ALTO information is partitioned and stored on
   several ALTO servers.

A.1.  Classification of Solution Approaches

   Various protocol extensions and other solutions have been proposed to
   deal with multiple information sources and partitioned knowledge.
   They can be classified as follows:

   1    Ensure that all ALTO servers have the same knowledge

   1.1  Ensure data replication and synchronization within the
        provisioning protocol (cf. RFC 5693, Fig 1 [RFC5693]).

   1.2  Use an Inter-ALTO-server data replication protocol.  Possibly,
        the ALTO protocol itself - maybe with some extensions - could be
        used for that purpose; however, this has not been studied in
        detail so far.

   2    Accept that different ALTO servers (possibly operated by
        different organizations, e.g., ISPs) do not have the same
        knowledge

   2.1  Allow ALTO clients to send arbitrary queries to any ALTO server
        (e.g. the one discovered using [RFC7286]).  If this server
        cannot answer the query itself, it will fetch the data on behalf
        of the client, using the ALTO protocol or a to-be-defined inter-
        ALTO-server request forwarding protocol.

   2.2  Allow ALTO clients to send arbitrary queries to any ALTO server
        (e.g. the one discovered using [RFC7286]).  If this server
        cannot answer the query itself, it will redirect the client to
        the "right" ALTO server that has the desired information, using
        a small to-be-defined extension of the ALTO protocol.

   2.3  ALTO clients need to use some kind of "search engine" that
        indexes ALTO servers and redirects and/or gives cached results.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 27]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

   2.4  ALTO clients need to use a new discovery mechanism to discover
        the ALTO server that has the desired information and contact it
        directly.

A.2.  Discussion of Solution Approaches

   The provisioning or initialization protocol for ALTO servers (cf. RFC
   5693, Fig 1 [RFC5693]) is currently not standardized.  It was a
   conscious decision not to include this in the scope of the IETF ALTO
   working group.  The reason is that there are many different kinds of
   information sources.  This implementation specific protocol will
   adapt them to the ALTO server, which offers a standardized protocol
   to the ALTO clients.  However, adding the task of synchronization
   between ALTO servers to this protocol (i.e., approach 1.1) would
   overload this protocol with a second functionality that requires
   standardization for seamless multi-domain operation.

   For the 1.? solution approaches, in addition to general technical
   feasibility and issues like overhead and caching efficiency, another
   aspect to consider is legal liability.  Operator "A" might prefer not
   to publish information about nodes in or paths between the networks
   of operators "B" and "C" through A's ALTO server, even if A knew that
   information.  This is not only a question of map size and processing
   load on A's ALTO server.  Operator A could also face legal liability
   issues if that information had a bad impact on the traffic
   engineering between B's and C's networks, or on their business
   models.

   No specific actions to build a "search engine" based solution
   (approach 2.3) are currently known and it is unclear what could be
   the incentives to operate such an engine.  Therefore, this approach
   is not considered in the remainder of this document.

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
   specification of an ALTO protocol extension or a new protocol that
   runs between ALTO servers.  A large-scale, maybe Internet-wide,
   multi-domain deployment would also need mechanisms by which an ALTO
   server could discover other ALTO servers, learn which information is
   available where, and ideally also who is authorized to publish
   information related to a given part of the network.  Approach 2.4
   needs the same mechanisms, except that they are used on the client-
   side instead of the server-side.

   It is sometimes questioned whether there is a need for a solution
   that allows clients to ask arbitrary queries, even if the ALTO
   information is partitioned and stored on many ALTO servers.  The main

Kiesel & Stiemerling    Expires February 21, 2020              [Page 28]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

   argument is, that clients are supposed to optimize the traffic from
   and to themselves, and that the information needed for that is most
   likely stored on a "nearby" ALTO server, i.e., the one that can be
   discovered using [RFC7286].  However, there are scenarios where the
   ALTO client is not co-located with an endpoint of the to-be-optimized
   data transmission.  Instead, the ALTO client is located at a third
   party, which takes part in the application signaling, e.g., a so-
   called "tracker" in a peer-to-peer application.  One such scenario,
   where it is advantageous to place the ALTO client not at an endpoint
   of the user data transmission, is analyzed in Appendix C.

A.4.  Our Solution Approach

   Several solution approaches for cross-domain ALTO server discovery
   have been evaluated, using the criteria documented in Appendix B.
   One of them was to use the ALTO protocol itself for the exchange of
   information availability [I-D.kiesel-alto-alto4alto].  However, the
   drawback of that approach is that a new registration administration
   authority would have to be established.

   This document specifies a DNS-based procedure for cross-domain ALTO
   server discovery, which was inspired by "Location Information Server
   (LIS) Discovery Using IP Addresses and Reverse DNS" [RFC7216].  The
   primary goal is that this procedure can be used on the client-side
   (i.e., approach 2.4), but together with new protocols or protocol
   extensions it could also be used to implement the other solution
   approaches itemized above.

A.5.  Relation to the ALTO Requirements

   During the design phase of the overall ALTO solution, two different
   server discovery scenarios have been identified and documented in the
   ALTO requirements document [RFC6708].  The first scenario, documented
   in Req. AR-32, can be supported using the discovery mechanisms
   specified in [RFC7286].  An alternative approach, based on IP anycast
   [I-D.kiesel-alto-ip-based-srv-disc], has also been studied.  This
   document, in contrast, tries to address Req. AR-33.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 29]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

Appendix B.  Requirements for Cross-Domain Server Discovery

   This appendix itemizes requirements that have been collected before
   the design phase and that are reflected by the design of the ALTO
   Cross-Domain Server Discovery Procedure.

B.1.  Discovery Client Application Programming Interface

   The discovery client will be called through some kind of application
   programming interface (API) and the parameters will be an IP address
   and, for purposes of extensibility, a service identifier such as
   "ALTO".  It will return one or more URI(s) that offers the requested
   service ("ALTO") for the given IP address.

   In other words, the client would be used to retrieve a mapping:

   (IP address, "ALTO") -> IRD-URI(s)

   where IRD-URI(s) is one or more URI(s) of Information Resource
   Directories (IRD, see Section 9 of [RFC7285]) of ALTO server(s) that
   can give reasonable guidance to a resource consumer with the
   indicated IP address.

B.2.  Data Storage and Authority Requirements

   The information for mapping IP addresses and service parameters to
   URIs should be stored in a - preferably distributed - database.  It
   must be possible to delegate administration of parts of this
   database.  Usually, the mapping from a specific IP address to an URI
   is defined by the authority that has administrative control over this
   IP address, e.g., the ISP in residential access networks or the IT
   department in enterprise, university, or similar networks.

B.3.  Cross-Domain Operations Requirements

   The cross-domain server discovery mechanism should be designed in
   such a way that it works across the public Internet and also in other
   IP-based networks.  This in turn means that such mechanisms cannot
   rely on protocols that are not widely deployed across the Internet or
   protocols that require special handling within participating
   networks.  An example is multicast, which is not generally available
   across the Internet.

   The ALTO Cross-Domain Server Discovery protocol must support gradual
   deployment without a network-wide flag day.  If the mechanism needs
   some kind of well-known "rendezvous point", re-using an existing
   infrastructure (such as the DNS root servers or the WHOIS database)
   should be preferred over establishing a new one.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 30]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

B.4.  Protocol Requirements

   The protocol must be able to operate across middleboxes, especially
   across NATs and firewalls.

   The protocol shall not require any pre-knowledge from the client
   other than any information that is known to a regular IP host on the
   Internet.

B.5.  Further Requirements

   The ALTO cross domain server discovery cannot assume that the server
   discovery client and the server discovery responding entity are under
   the same administrative control.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 31]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

Appendix C.  ALTO and Tracker-based Peer-to-Peer Applications

   This appendix provides a complete example of using ALTO and the ALTO
   Cross-Domain Server Discovery Procedure in one specific application
   scenario, namely a tracker-based peer-to-peer application.  First, in
   subsection C.1, we introduce a generic model of such an application
   and show why ALTO optimization is desirable.  Then, in C.2, we
   introduce two architectural options for integrating ALTO into the
   tracker-based peer-to-peer application - one option is based on the
   "regular" ALTO server discovery procedure [RFC7286], one relies on
   the ALTO Cross-Domain Server Discovery Procedure.  In C.3, a simple
   mathematical model is used to show that the latter approach is
   expected to yield significantly better optimization results.  The
   appendix concludes with subsection C.4, which details an exemplary
   complete walk-through of the ALTO Cross-Domain Server Discovery
   Procedure.

C.1.  A generic Tracker-based Peer-to-Peer Application

   The optimization of peer-to-peer (P2P) applications such as
   BitTorrent was one of the first use cases that lead to the inception
   of the IETF ALTO working group.  Further use cases have been
   identified as well, yet we will use this scenario to illustrate the
   operation and usefulness of the ALTO Cross-Domain Server Discovery
   Procedure.

   For the remainder of this chapter we consider a generic, tracker-
   based peer-to-peer file sharing application.  The goal is the
   dissemination of a large file, without using one large server with a
   correspondingly high upload bandwidth.  The file is split into
   chunks.  So-called "peers" assume the role of both a client and a
   server.  That is, they may request chunks from other peers and they
   may serve the chunks they already possess to other peers at the same
   time, thereby contributing their upload bandwidth.  Peers that want
   to share the same file participate in a "swarm".  They use the peer-
   to-peer protocol to inform each other about the availability of
   chunks and to request and transfer chunks from one peer to another.
   A swarm may consist of a very large number of peers.  Consequently,
   peers usually maintain logical connections only to a subset of all
   peers in the swarm.  If a new peer wants to join a swarm, it first
   contacts a well-known server, the "tracker", which provides a list of
   IP addresses of peers in the swarm.

   A swarm is an overlay network on top of the IP network.  Algorithms
   that determine the overlay topology and the traffic distribution in
   the overlay may consider information about the underlying IP network,
   such as topological distance, link bandwidth, (monetary) costs for
   sending traffic from one host to another, etc.  ALTO is a protocol

Kiesel & Stiemerling    Expires February 21, 2020              [Page 32]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

   for retrieving such information.  The goal of such "topology aware"
   decisions is to improve performance or Quality of Experience in the
   application while reducing the utilization of the underlying network
   infrastructure.

C.2.  Architectural Options for Placing the ALTO Client

   The ALTO protocol specification [RFC7285] details how an ALTO client
   can query an ALTO server for guiding information and receive the
   corresponding replies.  However, in the considered scenario of a
   tracker-based P2P application, there are two fundamentally different
   possibilities where to place the ALTO client:

   1.  ALTO client in the resource consumer ("peer")

   2.  ALTO client in the resource directory ("tracker")

   In the following, both scenarios are compared in order to explain the
   need for ALTO queries on behalf of remote resource consumers.

   In the first scenario (see Figure 2), the resource consumer queries
   the resource directory for the desired resource (F1).  The resource
   directory returns a list of potential resource providers without
   considering ALTO (F2).  It is then the duty of the resource consumer
   to invoke ALTO (F3/F4), in order to solicit guidance regarding this
   list.

   In the second scenario (see Figure 4), the resource directory has an
   embedded ALTO client.  After receiving a query for a given resource
   (F1) the resource directory invokes this ALTO client to evaluate all
   resource providers it knows (F2/F3).  Then it returns a, possibly
   shortened, list containing the "best" resource providers to the
   resource consumer (F4).

Kiesel & Stiemerling    Expires February 21, 2020              [Page 33]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

    .............................          .............................
    : Tracker                   :          : Peer                      :
    :   ______                  :          :                           :
    : +-______-+                :          :            k good         :
    : |        |     +--------+ : P2P App. : +--------+ peers +------+ :
    : |   N    |     | random | : Protocol : | ALTO-  |------>| data | :
    : | known  |====>| pre-   |*************>| biased |       | ex-  | :
    : | peers, |     | selec- | : transmit : | peer   |------>| cha- | :
    : | M good |     | tion   | : n peer   : | select | n-k   | nge  | :
    : +-______-+     +--------+ : IDs      : +--------+ bad p.+------+ :
    :...........................:          :.....^.....................:
                                                 |
                                                 | ALTO protocol
                                               __|___
                                             +-______-+
                                             |        |
                                             | ALTO   |
                                             | server |
                                             +-______-+

   Figure 1: Tracker-based P2P Application with random peer preselection

   Peer w. ALTO cli.            Tracker               ALTO Server
   --------+--------       --------+--------       --------+--------
           | F1 Tracker query      |                       |
           |======================>|                       |
           | F2 Tracker reply      |                       |
           |<======================|                       |
           | F3 ALTO query         |                       |
           |---------------------------------------------->|
           | F4 ALTO reply         |                       |
           |<----------------------------------------------|
           |                       |                       |

   ====  Application protocol (i.e., tracker-based P2P app protocol)
   ----  ALTO protocol

       Figure 2: Basic message sequence chart for resource consumer-
                           initiated ALTO query

Kiesel & Stiemerling    Expires February 21, 2020              [Page 34]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

    .............................          .............................
    : Tracker                   :          : Peer                      :
    :   ______                  :          :                           :
    : +-______-+                :          :                           :
    : |        |     +--------+ : P2P App. :  k good peers &  +------+ :
    : |   N    |     | ALTO-  | : Protocol :  n-k bad peers   | data | :
    : | known  |====>| biased |******************************>| ex-  | :
    : | peers, |     | peer   | : transmit :                  | cha- | :
    : | M good |     | select | : n peer   :                  | nge  | :
    : +-______-+     +--------+ : IDs      :                  +------+ :
    :.....................^.....:          :...........................:
                          |
                          | ALTO protocol
                        __|___
                      +-______-+
                      |        |
                      | ALTO   |
                      | server |
                      +-______-+

    Figure 3: Tracker-based P2P Application with ALTO client in tracker

         Peer             Tracker w. ALTO cli.       ALTO Server
   --------+--------       --------+--------       --------+--------
           | F1 Tracker query      |                       |
           |======================>|                       |
           |                       | F2 ALTO query         |
           |                       |---------------------->|
           |                       | F3 ALTO reply         |
           |                       |<----------------------|
           | F4 Tracker reply      |                       |
           |<======================|                       |
           |                       |                       |

   ====  Application protocol (i.e., tracker-based P2P app protocol)
   ----  ALTO protocol

    Figure 4: Basic message sequence chart for ALTO query on behalf of
                         remote resource consumer

   Note: the message sequences depicted in Figure 2 and Figure 4 may
   occur both in the target-aware and the target-independent query mode
   (c.f.  [RFC6708]).  In the target-independent query mode no message
   exchange with the ALTO server might be needed after the tracker
   query, because the candidate resource providers could be evaluated
   using a locally cached "map", which has been retrieved from the ALTO
   server some time ago.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 35]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

C.3.  Evaluation

   The problem with the first approach is, that while the resource
   directory might know thousands of peers taking part in a swarm, the
   list returned to the resource consumer is usually shortened for
   efficiency reasons.  Therefore, the "best" (in the sense of ALTO)
   potential resource providers might not be contained in that list
   anymore, even before ALTO can consider them.

   For illustration, consider a simple model of a swarm, in which all
   peers fall into one of only two categories: assume that there are
   "good" ("good" in the sense of ALTO's better-than-random peer
   selection, based on an arbitrary desired rating criterion) and "bad'
   peers only.  Having more different categories makes the maths more
   complex but does not change anything to the basic outcome of this
   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
   tracker.  A new peer wants to join the swarm and therefore asks the
   tracker for a list of peers.

   If, according to the first approach, the tracker randomly picks n
   peers from the N known peers, the result can be described with the
   hypergeometric distribution.  The probability that the tracker reply
   contains exactly k "good" peers (and n-k "bad" peers) is:

               / M \   / N - M \
               \ k /   \ n - k /
   P(X=k) =  ---------------------
                     / N \
                     \ n /

           / n \        n!
   with    \ k /  = -----------    and   n! = n * (n-1) * (n-2) * .. * 1
                     k! (n-k)!

   The probability that the reply contains at most k "good" peers is:
   P(X<=k)=P(X=0)+P(X=1)+..+P(X=k).

   For example, consider a swarm with N=10,000 peers known to the
   tracker, out of which M=100 are "good" peers.  If the tracker
   randomly selects n=100 peers, the formula yields for the reply:
   P(X=0)=36%, P(X<=4)=99%.  That is, with a probability of approx. 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

Kiesel & Stiemerling    Expires February 21, 2020              [Page 36]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

   list.  Processing this list with the guiding ALTO information will
   ensure that the few favorable peers are ranked to the top of the
   list; however, the benefit is rather limited as the number of
   favorable peers in the list is just too small.

   Much better traffic optimization could be achieved if the tracker
   would evaluate all known peers using ALTO, and return a list of 100
   peers afterwards.  This list would then include a significantly
   higher fraction of "good" peers.  (Note, that if the tracker returned
   "good" peers only, there might be a risk that the swarm might
   disconnect and split into several disjunct partitions.  However,
   finding the right mix of ALTO-biased and random peer selection is out
   of the scope of this document.)

   Therefore, from an overall optimization perspective, the second
   scenario with the ALTO client embedded in the resource directory is
   advantageous, because it is ensured that the addresses of the "best"
   resource providers are actually delivered to the resource consumer.
   An architectural implication of this insight is that the ALTO server
   discovery procedures must support ALTO queries on behalf of remote
   resource consumers.  That is, as the tracker issues ALTO queries on
   behalf of the peer which contacted the tracker, the tracker must be
   able to discover an ALTO server that can give guidance suitable for
   that respective peer.  This task can be solved using the ALTO Cross-
   Domain Server Discovery Procedure.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 37]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

C.4.  Example

   This section provides a complete example of the ALTO Cross-Domain
   Server Discovery Procedure in a tracker-based peer-to-peer scenario.

   The example is based on the network topology shown in Figure 5.  Five
   access networks - Networks a, b, c, x, and t - are operated by five
   different network operators.  They are interconnected by a backbone
   structure.  Each network operator runs an ALTO server in their
   network, i.e., ALTO_SRV_A, ALTO_SRV_B, ALTO_SRV_C, ALTO_SRV_X, and
   ALTO_SRV_T, respectively.

        _____    __             _____    __             _____    __
     __(     )__(  )_        __(     )__(  )_        __(     )__(  )_
    (    Network a   )      (    Network b   )      (    Network c   )
   ( Res. Provider A  )    ( Res. Provider B  )    ( Res. Provider C  )
    (__ ALTO_SRV_A __)      (__ ALTO_SRV_B __)      (__ ALTO_SRV_C __)
      (___)--(____) \         (___)--(____)         / (___)--(____)
                     \           /                 /
                   ---+---------+-----------------+----
                  (              Backbone              )
                   ------------+------------------+----
                   _____    __/            _____   \__
                __(     )__(  )_        __(     )__(  )_
               (    Network x   )      (    Network t   )
              ( Res. Consumer X  )    (Resource Directory)
               (_  ALTO_SRV_X __)      (_  ALTO_SRV_T __)
                 (___)--(____)           (___)--(____)

                    Figure 5: Example network topology

   A new peer of a peer-to-peer application wants to join a specific
   swarm (overlay network), in order to access a specific resource.
   This new peer will be called "Resource Consumer X" in accordance to
   the terminology of [RFC6708] and it is located in Network x.  It
   contacts the tracker ("Resource Directory"), which is located in
   Network t.  The mechanism by which the new peer discovers the tracker
   is out of the scope of this document.  The tracker maintains a list
   of peers that take part in the overlay network, and hence it can
   determine that Resource Providers A, B, and C are candidate peers for
   Resource Consumer X.

   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
   optimization.  Consequently, the tracker wants to use the ALTO
   Endpoint Cost Service (ECS) to learn the routing costs between X and
   A, X and B, as well as X and C, in order to sort A, B, and C by their
   respective routing costs to X.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 38]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

   In theory, there are many options how the ALTO Cross-Domain Server
   Discovery Procedure could be used.  For example, the tracker could do
   the following steps:

   IRD_URIS_A = XDOMDISC(A,"ALTO:https")
   COST_X_A   = query the ECS(X,A,routingcost) found in IRD_URIS_A

   IRD_URIS_B = XDOMDISC(B,"ALTO:https")
   COST_X_B   = query the ECS(X,B,routingcost) found in IRD_URIS_B

   IRD_URIS_C = XDOMDISC(C,"ALTO:https")
   COST_X_C   = query the ECS(X,C,routingcost) found in IRD_URIS_C

   Maybe, the ALTO Cross-Domain Server Discovery Procedure queries would
   yield in this scenario: IRD_URIS_A = ALTO_SRV_A, IRD_URIS_B =
   ALTO_SRV_B, and IRD_URIS_C = ALTO_SRV_C. That is, each ECS query
   would be sent to a different ALTO server.  The problem with this
   approach is that we are not neccessarily able to compare COST_X_A,
   COST_X_B, and COST_X_C with each other.  The specification of the
   routingcost metric mandates that "A lower value indicates a higher
   preference", but "an ISP may internally compute routing cost using
   any method that it chooses" (see section 6.1.1.1. of [RFC7285]).
   Thus, COST_X_A could be 10 (milliseconds round-trip time), while
   COST_X_B could be 200 (kilometers great circle distance between the
   approximate geographic locations of the hosts) and COST_X_C could be
   3 (router hops, corresponding to a decrease of the TTL field in the
   IP header).  Each of these metrics fulfills the "lower value is more
   preferable" requirement on its own, but obviously, they cannot be
   compared with each other.  Even if there was a reasonable formula to
   compare, for example, kilometers with milliseconds, we could not use
   it, as the units of measurement (or any other information about the
   computation method for the routingcost) are not sent along with the
   value in the ECS reply.

   To avoid this problem, the tracker tries to send all ECS queries to
   the same ALTO server.  As specified in Section 4.4 of this document,
   case 2, it uses the IP address of Resource Consumer x as parameter to
   the discovery procedure:

   IRD_URIS_X = XDOMDISC(X,"ALTO:https")
   COST_X_A   = query the ECS(X,A,routingcost) found in IRD_URIS_X
   COST_X_B   = query the ECS(X,B,routingcost) found in IRD_URIS_X
   COST_X_C   = query the ECS(X,C,routingcost) found in IRD_URIS_X

   This strategy ensures that COST_X_A, COST_X_B, and COST_X_C can be
   compared with each other.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 39]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

   As discussed above, the tracker calls the ALTO Cross-Domain Server
   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:
   fe6a:de42.  Thus, the procedure call is

   IRD_URIS_X = XDOMDISC(2001:DB8:1:2:227:eff:fe6a:de42,"ALTO:https").

   The first parameter 2001:DB8:1:2:227:eff:fe6a:de42 is a single IPv6
   address.  Thus, we get AT = IPv6, A = 2001:DB8:1:2:227:eff:fe6a:de42,
   L = 128, and SP = "ALTO:https".

   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.
   8.B.D.0.1.0.0.2.IP6.ARPA.", as well as (see Step 2 in Section 3.3)
   R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
   R56 = "0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
   R48 = "1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
   R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and
   R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.".

   In order to illustrate the third step of the ALTO Cross-Domain Server
   Discovery Procedure, we use the "dig" (domain information groper) DNS
   lookup utility that is available for many operating systems (e.g.,
   Linux).  A real implementation of the ALTO Cross-Domain Server
   Discovery Procedure would not be based on the "dig" utility, but use
   appropriate libraries and/or operating system APIs.  Please note that
   the following steps have been performed in a controlled lab
   environment with a appropriately configured name server.  A suitable
   DNS configuration will be needed to reproduce these results.  Please
   also note that the rather verbose output of the "dig" tool has been
   shortened to the relevant lines.

   Since AT = IPv6 and L = 128, in the table given in Section 3.4, the
   sixth row (not counting the column headers) applies.

   As mandated by the third column, we start with a lookup of R128,
   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.\
   | 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
   |
   | ;; Got answer:
   | ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26553
   | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0

   The domain name R128 does not exist (status: NXDOMAIN), so we cannot
   get a useful result.  Therefore, we continue with the fourth column
   of the table and do a lookup of R64:

Kiesel & Stiemerling    Expires February 21, 2020              [Page 40]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

   | user@labpc:~$ dig -tNAPTR 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
   |
   | ;; Got answer:
   | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33193
   | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0

   The domain name R64 could be looked up (status: NOERROR), but there
   are no NAPTR resource records associated with it (ANSWER: 0).  Maybe,
   there are some other resource records such as PTR, NS, or SOA, but we
   are not interested in them.  Thus, we do not get a useful result and
   we continue with looking up R56:

   | user@labpc:~$ dig -tNAPTR 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
   |
   | ;; Got answer:
   | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35966
   | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
   |
   | ;; ANSWER SECTION:
   | 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
   |  "LIS:HELD" "!.*!https://lis1.example.org:4802/?c=ex!" .
   | 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 20 "u"
   |  "LIS:HELD" "!.*!https://lis2.example.org:4802/?c=ex!" .

   The domain name R56 could be looked up and there are NAPTR resource
   records associated with it.  However, each of these records has a
   service parameter that does not match our SP = "ALTO:https" (see
   [RFC7216] for "LIS:HELD"), and therefore, we have to ignore them.
   Consequently, we still do not have a useful result and continue with
   a lookup of R48:

   | user@labpc:~$ dig -tNAPTR 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
   |
   | ;; Got answer:
   | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50459
   | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
   |
   | ;; ANSWER SECTION:
   | 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
   |  "ALTO:https" "!.*!https://alto1.example.net/ird!" .
   | 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
   |  "LIS:HELD" "!.*!https://lis.example.net:4802/?c=ex!" .

   This lookup yields two NAPTR resource records.  We have to ignore the
   second one as its service parameter does not match our SP, but the
   first NAPTR resource record has a matching service parameter.
   Therefore, the procedure terminates successfully and the final
   outcome is: IRD_URIS_X = "https://alto1.example.net/ird".

Kiesel & Stiemerling    Expires February 21, 2020              [Page 41]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

   The ALTO client that is embedded in the tracker will access the ALTO
   Information Resource Directory (IRD, see Section 9 of [RFC7285]) at
   this URI, look for the Endpoint Cost Service (ECS, see Section 11.5
   of [RFC7285]), and query the ECS for the costs between A and X, B and
   X, as well as C and X, before returning an ALTO-optimized list of
   candidate resource providers to resource consumer X.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 42]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

Appendix D.  Contributors List and Acknowledgments

   The initial version of this document was co-authored by Marco Tomsu
   (Alcatel-Lucent).

   This document borrows some text from [RFC7286], as historically, it
   has been part of the draft that eventually became said RFC.  Special
   thanks to Michael Scharf and Nico Schwan.

Kiesel & Stiemerling    Expires February 21, 2020              [Page 43]
Internet-Draft     ALTO Cross-Domain Server Discovery        August 2019

Authors' Addresses

   Sebastian Kiesel
   University of Stuttgart Information Center
   Allmandring 30
   Stuttgart  70550
   Germany

   Email: ietf-alto@skiesel.de
   URI:   http://www.izus.uni-stuttgart.de

   Martin Stiemerling
   University of Applied Sciences Darmstadt, Computer Science Dept.
   Haardtring 100
   Darmstadt  64295
   Germany

   Phone: +49 6151 16 37938
   Email: mls.ietf@gmail.com
   URI:   http://ietf.stiemerling.org

Kiesel & Stiemerling    Expires February 21, 2020              [Page 44]