<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
docName="draft-ietf-alto-xdom-disc-06" ipr="trust200902"> ipr="trust200902" obsoletes=""
updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="2"
symRefs="true" sortRefs="true" version="3" number="8686" consensus="true">

  <!-- xml2rfc v2v3 conversion 2.35.0 -->

  <front>
    <title abbrev='ALTO abbrev="ALTO Cross-Domain Server Discovery'>
        Application Layer Discovery">
        Application-Layer Traffic Optimization (ALTO)
        Cross-Domain
        Cross&nbhy;Domain Server Discovery
    </title>
   <seriesInfo name="RFC" value="8686"/>
    <author fullname="Sebastian Kiesel" initials="S." surname="Kiesel">
      <organization abbrev="University of Stuttgart">
            University of Stuttgart Information Center
      </organization>
      <address>
        <postal>
          <street>Allmandring 30</street>
          <city>Stuttgart</city>
          <code>70550</code>
          <country>Germany</country>
        </postal>
        <email>ietf-alto@skiesel.de</email>
        <uri>http://www.izus.uni-stuttgart.de</uri>
      </address>
    </author>
    <author fullname="Martin Stiemerling" initials="M." surname="Stiemerling">
      <organization abbrev="H-DA">
            University of Applied Sciences Darmstadt,
            Computer Science Dept.
      </organization>
      <address>
        <postal>
          <street>Haardtring 100</street>
          <code>64295</code>
          <city>Darmstadt</city>
          <country>Germany</country>
        </postal>
        <phone>+49 6151 16 37938</phone>
        <email>mls.ietf@gmail.com</email>
            <uri>http://ietf.stiemerling.org</uri>
        <uri>https://danet.fbi.h-da.de</uri>
      </address>
    </author>
    <date year="2019" /> year="2020" month="February"/>
    <area>TSV</area>
    <workgroup>ALTO</workgroup>
    <keyword>Application-Layer Traffic Optimization (ALTO)</keyword>
    <keyword>ALTO cross-domain server discovery</keyword>
    <keyword>ALTO third-party server discovery</keyword>
    <abstract>
      <t>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 guidance, it needs to discover one or more
        ALTO servers that can provide suitable guidance.</t>
	<t>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 necessary to discover an ALTO server outside
	of the ALTO client's own network domain, in order to get appropriate
	guidance.  This document details applicable scenarios, itemizes
	requirements, and specifies a procedure for ALTO cross-domain server
	discovery.</t>
      <t>Technically, the procedure specified in this document takes one
        IP&nbsp;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. "in-addr.arpa." or ip6.arpa. tree) "ip6.arpa." trees)
        and returns one or more URI(s) URIs of information resources related
        to that IP address or prefix.</t>
    </abstract>

    <note title="Terminology and Requirements Language">
        <t>This document makes use of the ALTO terminology defined in
        RFC 5693 <xref target="RFC5693"/>.</t>

        <t>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 <xref target="RFC2119"/> <xref target="RFC8174"/>
        when, and only when, they appear in all capitals, as shown here.</t>
    </note>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
            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 <xref target="RFC5693"/>. target="RFC5693" format="default"/>. ALTO is realized by an
            HTTP-based client-server protocol <xref target="RFC7285"/>, target="RFC7285" format="default"/>,
            which can be used in various scenarios
            <xref target="RFC7971"/>. target="RFC7971" format="default"/>.
      </t>
      <t>
            The ALTO base protocol document <xref target="RFC7285"/> target="RFC7285" format="default"/> 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.
      </t>
      <t>
            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
            have better information about other parts of the network
            ("partitioned knowledge"). Various ALTO use cases have been
            studied in the context of such scenarios. In some cases, one
            cannot assume that a topologically nearby ALTO server (e.g., a
            server discovered with the procedure specified in
            <xref target="RFC7286"/>) target="RFC7286" format="default"/>) will always provide useful information
            to the client. One such scenario is detailed in
            <xref target="apx.alto_p2p"/>. target="apx.alto_p2p" format="default"/>.  Several solution
            approaches, such as redirecting a client to a server that has more
            accurate information or forwarding the request to it such a server on behalf
            of the client, have been proposed and analyzed (see
            <xref target="sec.multiplesources"/>), target="sec.multiplesources" format="default"/>), but none no
	    solution has been specified so far.
      </t>
      <t>
            <xref target="sec.3pdisc-spec"/> target="sec.3pdisc-spec" format="default"/> 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, X may call this procedure
            with X as a paramenter. parameter.
            It will use Domain Name System (DNS) lookups to find of one ore or
            more ALTO servers that can provide a competent answer.
            The above wording "related to" was intentionally kept somewhat
            unspecific, as the exact semantics depends on the ALTO service to
            be used; see <xref target="sec.xdom-usage"/>. target="sec.xdom-usage" format="default"/>.
      </t>
      <t>
            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. "in-addr.arpa." or ip6.arpa.)
            - "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). servers.  In many cases, it may be
            an ALTO server run by that ISP or IT department, as they
            naturally have good insight into routing costs from and
            to their networks.  However, they may also refer to an
            ALTO server provided by someone else, e.g., their upstream ISP.
      </t>

    <section>
      <name>Terminology and Requirements Language</name>
      <t>This document makes use of the ALTO terminology defined in
        RFC 5693 <xref target="RFC5693" format="default"/>.</t>
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>

    </section>
    </section>
    <section anchor="sec.3pdisc-overview"
        title="ALTO numbered="true" toc="default">
      <name>ALTO Cross-Domain Server Discovery Procedure: Overview"> Overview</name>
      <t>This section gives a non-normative overview on of the
        ALTO Cross-Domain Server Discovery Procedure. The detailed
        specification will follow in the next section.</t>
      <t>This procedure was inspired by the "Location Information
        Server (LIS) Discovery Using IP Addresses and Reverse DNS"
        <xref target="RFC7216"/> target="RFC7216" format="default"/> and re-uses reuses parts of the basic
        ALTO Server Discovery Procedure <xref target="RFC7286"/>.</t> target="RFC7286" format="default"/>.</t>
      <t>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 <xref target="RFC4848"/>, target="RFC4848" format="default"/>,
        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.
      </t>
      <t>The ALTO Cross-Domain Server Discovery Procedure is called
        with one IP&nbsp;address or prefix and a U-NAPTR Service
        Parameter <xref target="RFC4848"/> target="RFC4848" format="default"/> as parameters. </t>
      <t>The service parameter is usually set to "ALTO:https".
        However, other parameter values may be used in some scenarios, 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.</t>
      <t>The procedure performs DNS lookups and returns one or more
        URI(s)
        URIs of information resources related to said IP address or
        prefix, usually the URI(s) URIs of one or more ALTO Information
        Resource Directory (IRD, Directories (IRDs; see Section 9 of <xref target="RFC7285"/>). target="RFC7285"
	sectionFormat="of" section="9"/>).
        The U-NAPTR records also provide preference values, which should
        be considered if more than one URI is returned.
      </t>
      <t>The discovery procedure sequentially tries two different lookup
        strategies:
        strategies. First, an ALTO-specific U-NAPTR record is searched in the "reverse
        tree",
        tree" -- i.e., in subdomains of in-addr.arpa. "in-addr.arpa." or ip6.arpa. "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.</t>
    </section>
    <section anchor="sec.3pdisc-spec" title="ALTO numbered="true" toc="default">
      <name>ALTO Cross-Domain Server             Discovery Procedure: Specification"> Specification</name>
      <section anchor="sec.3pdisc-spec-interface" title="Interface"> numbered="true" toc="default">
        <name>Interface</name>
        <t>The procedure specified in this document takes two
            parameters, X and SP, where X is an IP&nbsp;address or prefix
            and SP is a U-NAPTR Service Parameter.</t>
        <t>The parameter X may be an IPv4 or an IPv6 address
            or prefix in CIDR Classless Inter-Domain Routing (CIDR) notation (see
	    <xref target="RFC4632"/> target="RFC4632" format="default"/>
            for the IPv4 CIDR notation and <xref target="RFC4291"/> target="RFC4291"
	    format="default"/> 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 definitions of IPv4 and IPv6 IPv6, it follows that
            syntactically valid values for L are
            0&nbsp;&lt;=&nbsp;L&nbsp;&lt;=&nbsp;32 when AT=IPv4 and
            0&nbsp;&lt;=&nbsp;L&nbsp;&lt;=&nbsp;128 when AT=IPv6.
            However, not all syntactically valid values of L are actually
            supported by this procedure - procedure; Step 1 (see below) will
            check for unsupported values and report an error if
            neccessary.</t>
            necessary.</t>
        <t>For example, for X=198.51.100.0/24, we get AT=IPv4,
            A=198.51.100.0
            A=198.51.100.0, and L=24.  Similarly, for X=2001:0DB8::20/128,
            we get AT=IPv6, A=2001:0DB8::20 A=2001:0DB8::20, and L=128.</t>
        <t>In the intended usage scenario, the procedure is normally
            always called with the parameter SP set to "ALTO:https".
            However, for general applicabiliy applicability and in order to support
            future extensions, the procedure MUST <bcp14>MUST</bcp14> support being called
            with any valid U-NAPTR Service Parameter
            (see Section 4.5. of <xref target="RFC4848"/> target="RFC4848" sectionFormat="of" section="4.5"/> for the
            syntax of U-NAPTR Service Parameters and Section 5. <xref target="RFC4848"
	    sectionFormat="bare" section="5"/> of the
            same document for information about the IANA registries).</t>
        <t>The procedure performs DNS lookups and returns one or more
            URI(s)
            URIs of information resources related to that IP address or
            prefix, usually the URI(s) URIs of one or more ALTO Information
            Resource Directory (IRD, Directories (IRDs; see Section 9 of <xref target="RFC7285"/>). target="RFC7285"
	    sectionFormat="of" section="9"/>).
            For each URI, it the procedure also returns order and preference values
            (see Section 4.1 of <xref target="RFC3403"/>), target="RFC3403"  sectionFormat="of" section="4.1"/>),
	    which
            should be considered if more than one URI is returned.</t>
        <t>During execution of this procedure, various
            error conditions may occur and have to be reported to
            the caller; see
            <xref target="sec.3pdisc-spec-errorhandling"/>.</t> target="sec.3pdisc-spec-errorhandling" format="default"/>.</t>
        <t>For the remainder of the document, we use the following
            notation for calling the ALTO Cross-Domain Server Discovery
            Procedure:
            <vspace blankLines="1"/>

            &nbsp;&nbsp;&nbsp;IRD_URIS_X&nbsp;=&nbsp;XDOMDISC(X,"ALTO:https")
        </t>
      </section>
      <section anchor="sec.3pdisc-spec-step1"
            title="Step numbered="true" toc="default">
        <name>Step 1: Prepare Domain Name for Reverse DNS Lookup"> Lookup</name>
        <t>First, the procedure checks the prefix length L for unsupported
            values: If AT=IPv4 (i.e., if A is an IPv4 address) and L &lt; 8,
            the procedure aborts and indicates an "unsupported prefix length"
            error to the caller. Similarly, if AT=IPv6
            and L &lt; 32, the procedure aborts and indicates an
            "unsupported prefix length" error to the caller. Otherwise,
            the procedure continues.</t>
        <t>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
            <xref target="RFC1035"/> target="RFC1035" format="default"  sectionFormat="of"
		  section="3.5"/>, and it is rooted in
            the special domain "IN-ADDR.ARPA.".</t>
        <t>For example, A=198.51.100.3 yields
            R32="3.100.51.198.IN-ADDR.ARPA.". </t>
        <t>If AT=IPv6, a domain name. name, which will be called R128,
            is constructed according to the rules specified in
            Section 2.5 of
            <xref target="RFC3596"/> target="RFC3596" format="default"
	    sectionFormat="of" section="2.5"/>, and the
            special domain "IP6.ARPA." is used.
            <figure>
                <artwork><![CDATA[
        </t>

<t>
For example (note: a line break was added after the second line),
</t>
<sourcecode type="pseudocode">
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."
]]></artwork></figure>
</t>

<t>
    <!-- force a page break as steps 2 and 3 each fit nicely on one page -->
    <vspace blankLines="60"/>
</t>
</sourcecode>

      </section>
      <section anchor="sec.3pdisc-spec-step2"
            title="Step numbered="true" toc="default">
        <name>Step 2: Prepare Shortened Domain Names"> Names</name>
        <t>For this step, an auxiliary function "skip" 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.".
        </t>
        <t>If AT=IPv4, the following additional
            domain names are generated from the result of the previous step:
            <list style="empty">
                <t>R24=skip(R32,1),</t>
                <t>R16=skip(R32,2), and</t>
                <t>R8=skip(R32,3).</t>
            </list>
        </t>
        <ul empty="true" spacing="normal">
          <li>R24=skip(R32,1),</li>
          <li>R16=skip(R32,2), and</li>
          <li>R8=skip(R32,3).</li>
        </ul>
        <t>
            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.</t>

        <t>For example, example,</t>
<sourcecode type="pseudocode">
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.". </t>
R24="100.51.198.IN-ADDR.ARPA."
R16="51.198.IN-ADDR.ARPA."
R8="198.IN-ADDR.ARPA."
</sourcecode>
        <t>If AT=IPv6, the following additional
            domain names are generated from the result of the previous step:
            <list style="empty">
                <t>R64=skip(R128,16),</t>
                <t>R56=skip(R128,18),</t>
                <t>R48=skip(R128,20),</t>
                <t>R40=skip(R128,22), and</t>
                <t>R32=skip(R128,24).</t>
            </list>
        </t>
        <ul empty="true" spacing="normal">
          <li>R64=skip(R128,16),</li>
          <li>R56=skip(R128,18),</li>
          <li>R48=skip(R128,20),</li>
          <li>R40=skip(R128,22), and</li>
          <li>R32=skip(R128,24).</li>
        </ul>
        <t>
            Removing one label from a domain name (i.e., one hex digit)
            corresponds to shortening the prefix length by 4 bits.
            <figure>
                <artwork><![CDATA[
        </t>
<t>
For example (note: a line break was added after the first line),
</t>
<sourcecode type="pseudocode">
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.", "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.", "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.", "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 "0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R32  = "8.B.D.0.1.0.0.2.IP6.ARPA.".
]]></artwork></figure>
</t> "8.B.D.0.1.0.0.2.IP6.ARPA."
</sourcecode>
      </section>
      <section anchor="sec.3pdisc-spec-step3"
            title="Step numbered="true" toc="default">
        <name>Step 3: Perform DNS U-NAPTR lookups"> Lookups</name>
        <t>The address type and the prefix length of X
            are matched against the first and the second column of the
            following table, respectively:</t>
<figure><artwork><![CDATA[
+------------+------------+------------+----------------------------+
| 1:

<table anchor="U-NAPTR">
  <name>Perform DNS U-NAPTR lookups</name>
  <thead>
    <tr>
      <th>1: Address | 2: Type AT</th>
      <th>2: Prefix  | 3: Length L</th>
      <th>3: MUST do | 4: 1st lookup</th>
      <th>4: SHOULD do further       |
| Type AT    | Length L   | 1st lookup | lookups in that order      |
+------------+------------+------------+----------------------------+
| IPv4       |        32  |  R32       | R24, order</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>IPv4</td>
      <td>32</td>
      <td>R32</td>
      <td>R24, R16, R8               |
| IPv4       |  24 R8</td>
    </tr>
    <tr>
      <td>IPv4</td>
      <td>24 .. 31  |  R24       | R16, R8                    |
| IPv4       |  16 31</td>
      <td>R24</td>
      <td>R16, R8</td>
    </tr>
    <tr>
      <td>IPv4</td>
      <td>16 .. 23  |  R16       | R8                         |
| IPv4       |   8 23</td>
      <td>R16</td>
      <td>R8</td>
    </tr>
    <tr>
      <td>IPv4</td>
      <td>8 .. 15  |   R8       | (none)                     |
| IPv4       |   0 15</td>
      <td>R8</td>
      <td>(none)</td>
    </tr>
    <tr>
      <td>IPv4</td>
      <td>0 ..  7  | (none, 7</td>
      <td colspan="2">(none, abort: unsupported prefix length)|
+------------+------------+------------+----------------------------+
| IPv6       |       128  | R128       | R64, length)</td>
    </tr>
    <tr>
      <td>IPv6</td>
      <td>128</td>
      <td>R128</td>
      <td>R64, R56, R48, R40, R32    |
| IPv6       | 64 (..127) |  R64       | R56, R32</td>
    </tr>
    <tr>
      <td>IPv6</td>
      <td>64 (..127)</td>
      <td>R64</td>
      <td>R56, R48, R40, R32         |
| IPv6       |  56 R32</td>
    </tr>
    <tr>
      <td>IPv6</td>
      <td>56 .. 63  |  R56       | R48, 63</td>
      <td>R56</td>
      <td>R48, R40, R32              |
| IPv6       |  48 R32</td>
    </tr>
    <tr>
      <td>IPv6</td>
      <td>48 .. 55  |  R48       | R40, R32                   |
| IPv6       |  40 55</td>
      <td>R48</td>
      <td>R40, R32</td>
    </tr>
    <tr>
      <td>IPv6</td>
      <td>40 .. 47  |  R40       | R32                        |
| IPv6       |  32 47</td>
      <td>R40</td>
      <td>R32</td>
    </tr>
    <tr>
      <td>IPv6</td>
      <td>32 .. 39  |  R32       | (none)                     |
| IPv6       |   0 39</td>
      <td>R32</td>
      <td>(none)</td>
    </tr>
    <tr>
      <td>IPv6</td>
      <td>0 .. 31  | (none, 31</td>
      <td colspan="2">(none, abort: unsupported prefix length)|
+------------+------------+------------+----------------------------+
]]></artwork></figure> length)</td>
    </tr>
  </tbody>
</table>

        <t>Then, the domain name given in the 3rd column and the
            U-NAPTR Service Parameter SP with which the procedure was called with
            (usually "ALTO:https") MUST <bcp14>MUST</bcp14> be used for an a
            U-NAPTR <xref target="RFC4848"/> target="RFC4848" format="default"/> 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) URIs can be found, the
            ALTO Cross-Domain Server Discovery Procedure returns that
            information to the caller and terminates successfully.</t>
        <t>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.
<figure><artwork><![CDATA[
</t>
<sourcecode type="dns-rr">
    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!"  ""
]]></artwork></figure></t>
</sourcecode>

        <t>If no matching U-NAPTR records can be found,
            the procedure SHOULD <bcp14>SHOULD</bcp14> try further lookups, using the domain
            names from the fourth column in the indicated order, until one
            lookup
            succeeds.  If no IRD URI could can be found after looking up
            all domain names from the 3rd and 4th column, columns, the procedure
            terminates unsuccessfully, returning an empty URI list.
        </t>
      </section>
      <section anchor="sec.3pdisc-spec-errorhandling"
            title="Error Handling"> numbered="true" toc="default">
        <name>Error Handling</name>
        <t>The ALTO Cross-Domain Server Discovery Procedure may fail
            for several reasons.</t>
        <t>If the procedure is called with syntactically invalid
            parameters or unsupported parameter values (in particular particular, the
            prefix length L, L; see <xref target="sec.3pdisc-spec-step1"/>), target="sec.3pdisc-spec-step1" format="default"/>),
            the procedure aborts, no URI list will be returned returned, and
            the error has to be reported to the caller.</t>
        <t>The procedure performs one or more DNS lookups in a
            well-defined order (corresponding to descending prefix lengths,
            see <xref target="sec.3pdisc-spec-step3"/>), target="sec.3pdisc-spec-step3" format="default"/>) until one produces
            a usable result.  Each of these DNS
            lookups might not fail to produce a usable result, either due to either a
            normal condition (e.g., a domain name exists, but no ALTO-specific
            NAPTR resource records are associated with it), a permanent error
            (e.g., non-existent nonexistent 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 <bcp14>SHOULD</bcp14> immediately try to lookup
	    look up the
            next domain name (from column Column 4 in the table given in
            <xref target="sec.3pdisc-spec-step3"/>). target="sec.3pdisc-spec-step3" format="default"/>).
            Only after all domain names have been tried at least once, the
            procedure MAY <bcp14>MAY</bcp14> retry those domain names that had caused temporary
            lookup errors.</t>
        <t>Generally speaking, ALTO provides advisory
            information for the optimization of applications (e.g.,
            peer-to-peer (peer-to-peer
	    applications, overlay networks, etc.), but
            applications should not rely on the availability of such
            information for their basic functionality (see
            <xref target="RFC7285">Section 8.3.4.3 of RFC 7285</xref>). target="RFC7285" sectionFormat="of" section="8.3.4.3" />).

            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 to causing long delays by retrying
            failed queries.

      Nevertheless, if DNS queries have failed due to temporary errors, the
      ALTO Cross-Domain Server Discovery Procedure SHOULD inform its caller, if caller
      that DNS queries have failed due to temporary errors for that reason and that retrying the
      discovery at a later point in time might give more accurate results.

        </t>
      </section>
    </section>
    <section anchor="sec.xdom-usage"
            title="Using numbered="true" toc="default">
      <name>Using the ALTO Protocol with Cross-Domain Server Discovery"> Discovery</name>
      <t>Based on a modular design principle, ALTO provides several ALTO
        services, each consisting of a set of information resouces resources
        that can be accessed using the ALTO protocol.
        The information resources that are available at a specific
        ALTO server are listed in its Information Resource Directory
        (IRD, see Section 9 of <xref target="RFC7285"/>). target="RFC7285" sectionFormat="of" section="9"/>).
        The ALTO protocol specification defines the following ALTO
        services and their corresponding information resouces:
            <list style="symbols">
                <t>Network resources:
      </t>
      <ul spacing="normal">
        <li>Network and Cost Map Service, see Section 11.2 of <xref target="RFC7285"/>
                </t>
                <t>Map-Filtering
	target="RFC7285" sectionFormat="of" section="11.2"/>
        </li>
        <li>Map-Filtering Service, see Section 11.3 of <xref target="RFC7285"/>
                </t>
                <t>Endpoint target="RFC7285"
		    sectionFormat="of" section="11.3"/>
        </li>
        <li>Endpoint Property Service,
                    see Section 11.4 of <xref target="RFC7285"/>
                </t>
                <t>Endpoint target="RFC7285"
		    sectionFormat="of" section="11.4"/>
        </li>
        <li>Endpoint Cost Service,
                    see Section 11.5 of <xref target="RFC7285"/>
                </t>
            </list> target="RFC7285"
		    sectionFormat="of" section="11.5"/>
        </li>
      </ul>
      <t>
        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.
      </t>
      <section anchor="sec.mapservice" title="Network numbered="true" toc="default">
        <name>Network and Cost Map Service"> Service</name>
        <t> An ALTO client may invoke the ALTO Cross-Domain Server
                Discovery Procedure (as specified in
                <xref target="sec.3pdisc-spec"/>) target="sec.3pdisc-spec" format="default"/>) for an IP address
                or prefix "X" X
                and get a list of one or more IRD URI(s), URIs, including
                order and preference values:
                IRD_URIS_X&nbsp;=&nbsp;XDOMDISC(X,"ALTO:https"). The IRD(s)
                referenced by these URI(s) URIs
                will always contain a network and a cost map, as these
                are mandatory information resources (see Section 11.2
                of <xref target="RFC7285"/>).
		target="RFC7285" sectionFormat="of" section="11.2"/>).
		However, the cost matrix
                may be very sparse. If, according to the network map,
                PID_X is the PID Provider-defined Identifier (PID; see <xref
		target="RFC7285" sectionFormat="of" section="5.1"/>) that contains the IP address or prefix X, and
                PID_1, PID_2, PID_3, ... are other PIDS, PIDs, the cost map
                may look like this:
<figure>
                <artwork><![CDATA[
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
]]></artwork>
          </figure>
</t>

<table anchor="PID">
  <name>Cost Map</name>
  <thead>
    <tr>
      <th>From</th>
      <th>To PID_1</th>
      <th>PID_2</th>
      <th>PID_X</th>
      <th>PID_3</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>PID_1</td>
      <td></td>
      <td></td>
      <td>92</td>
      <td></td>
    </tr>
    <tr>
      <td>PID_2</td>
      <td></td>
      <td></td>
      <td>6</td>
      <td></td>
    </tr>
    <tr>
      <td>PID_X</td>
      <td>46</td>
      <td>3</td>
      <td>1</td>
      <td>19</td>
    </tr>
    <tr>
      <td>PID_3</td>
      <td></td>
      <td></td>
      <td>38</td>
      <td></td>
    </tr>
  </tbody>
</table>

        <t>
          In this example, all cells outside column "X" Column X and row "X" Row X are
          unspecified. A cost map with this structure contains the same
          information as what could be retrieved using the Endpoint Cost
          Service, cases Cases 1 and 2 in <xref target="sec.ecs"/>. target="sec.ecs" format="default"/>.
          Accessing cells that are neither in column "X" Column X nor row "X" Row X
          may not yield useful results.
        </t>
        <t>Trying to assemble a more densely populated cost map from several
          cost maps with this very sparse structure may be a non-trivial nontrivial
          task, as different ALTO servers may use different PID definitions
          (i.e., network maps) and incompatible scales for the costs,
          in particular for the "routingcost" metric.
        </t>
      </section>
      <section anchor="sec.mfs"title="Map-Filtering Service"> anchor="sec.mfs" numbered="true" toc="default">
        <name>Map-Filtering Service</name>
        <t> An ALTO client may invoke the ALTO Cross-Domain Server
                Discovery Procedure (as specified in
                <xref target="sec.3pdisc-spec"/>) target="sec.3pdisc-spec" format="default"/>) for an IP address
                or prefix "X" X
                and get a list of one or more IRD URI(s), URIs, including
                order and preference values:
                IRD_URIS_X&nbsp;=&nbsp;XDOMDISC(X,"ALTO:https"). These IRD(s) IRDs
                may provide the optional Map-Filtering Service
                (see Section 11.3 of <xref target="RFC7285"/>). target="RFC7285" sectionFormat="of"
		section="11.3"/>).
                This service returns a subset of the full map,
                as specified by the client. As discussed in
                <xref target="sec.mapservice"/>, target="sec.mapservice" format="default"/>, 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.
        </t>
      </section>
      <section anchor="sec.eps" title="Endpoint numbered="true" toc="default">
        <name>Endpoint Property Service"> Service</name>
        <t>
                If an ALTO client wants to query an Endpoint Property Service
                (see <xref target="RFC7285">Section 11.4 of RFC 7285</xref>) target="RFC7285" sectionFormat="of" section="11.4" />)
                about an endpoint with IP address "X" X or a group of endpoints
                within IP prefix "X", X, respectively, it has to
                invoke the ALTO Cross-Domain Server Discovery Procedure
                (as specified in <xref target="sec.3pdisc-spec"/>): target="sec.3pdisc-spec" format="default"/>):
                IRD_URIS_X&nbsp;=&nbsp;XDOMDISC(X,"ALTO:https").
                The result IRD_URIS_X result, IRD_URIS_X, is a list of one or more URIs of
                Information Resource Directories
                (IRD,
                (IRDs, see Section 9 of <xref target="RFC7285"/>). target="RFC7285"
		sectionFormat="of" section="9"/>).
                Considering the order and preference values, the client has
                to check these IRDs for a suitable Endpoint Property Service
                and query it.
        </t>
        <t>
                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.
        </t>
      </section>
      <section anchor="sec.ecs" title="Endpoint numbered="true" toc="default">
        <name>Endpoint Cost Service"> Service</name>
        <t>
                The optional ALTO Endpoint Cost Service (ECS, (ECS;
                see <xref target="RFC7285">Section 11.5 of RFC 7285</xref>) target="RFC7285" sectionFormat="of" section="11.5" />)
                provides information about costs between individual endpoints
                and it also supports ranking.
                The ECS allows that endpoints may to be denoted by IP
                addresses or prefixes.
                The ECS is called with a list of
                one or more source IP addresses or prefixes, which we will call
                (S1, S2, S3, ...), and a list of one or more destination
                IP addresses or prefixes, called (D1, D2, D3, ...).
        </t>
        <t>This specification distinguishes several cases, regarding
            the number of elements in the list of source and destination
            addresses, respectively:
                <list style="numbers">
        </t>
        <ol spacing="normal" type="1">
          <li>
            <t>Exactly one source address S1 and more than one
                    destination addresses D1, (D1, D2, D3, ... ...).  In this case,
                    the ALTO client has to invoke the ALTO Cross-Domain
                    Server Discovery Procedure (as specified in
                    <xref target="sec.3pdisc-spec"/>) target="sec.3pdisc-spec" format="default"/>) with that single
                    source address as a parameter:
                    IRD_URIS_S1&nbsp;=&nbsp;XDOMDISC(S1,"ALTO:https").
                    The result IRD_URIS_S1 result, IRD_URIS_S1, is a list of one or more URIs of
                    Information Resource Directories
                    (IRD,
                    (IRDs, see Section 9 of <xref target="RFC7285"/>). target="RFC7285"
		    sectionFormat="of" section="9"/>).
                    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
                    <xref target="RFC7285">Section 11.5.1 of RFC 7285</xref>) target="RFC7285" sectionFormat="of" section="11.5.1"
			  />), and therefore, it may well be that an IRD does not
                    refer to an ECS.
                    <vspace blankLines="1"/> <!-- new paragraph within
                    the same item of the numbered list -->
            </t>
            <t>
                    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 when
                    cost metrics without lack a well-defined base unit, unit -- e.g.,
                    the "routingcost" metric.
            </t>

                    <t>More
          </li>
          <li>More than one source addresses S1, address (S1, S2, S3, ... ...)
                    and exactly one destination address D1.  In this case,
                    the ALTO client has to invoke the ALTO Cross-Domain
                    Server Discovery Procedure with that single
                    destination address as a parameter:
                    IRD_URIS_D1&nbsp;=&nbsp;XDOMDISC(D1,"ALTO:https").
                    The result IRD_URIS_D1 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.
                    </t>

                    <t>Exactly
                    </li>
          <li>Exactly one source address S1
                    and exactly one destination address D1.
                    The ALTO client may perform the same steps as in
                    case&nbsp;1,
                    Case&nbsp;1, as specified above. As an alternative,
                    it may also perform the same steps as in
                    case&nbsp;2,
                    Case&nbsp;2, as specified above.
                    </t>

                    <t>More
                    </li>
          <li>More than one source addresses S1, address (S1, S2, S3, ... ...)
                    and more than one destination addresses D1, address (D1, D2, D3, ... ...).
                    In this case, the ALTO client should split the
                    list of desired queries based on source addresses and perform separately
                    for each source address the same steps as in case&nbsp;1, Case&nbsp;1,
                    as specified above.  As an alternative, the ALTO
                    client may also group the list based on destination
                    addresses and perform separately for each destination
                    address the same steps as in case&nbsp;2, Case&nbsp;2, as specified
                    above.  However, comparing results between these
                    sub-queries
                    subqueries may be difficult, in particular if
                    the cost metric is a relative preference without
                    a well-defined base unit (e.g., the "routingcost"
                    metric).
                    </t>

                </list>
                    </li>
        </ol>
        <t>

                See <xref target="apx.alto_p2p"/> target="apx.alto_p2p" format="default"/> 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.

        </t>
      </section>
      <section anchor="sec.ext" title="Summary numbered="true" toc="default">
        <name>Summary and Further Extensions"> Extensions</name>
        <t>Considering the four services defined in the ALTO base
            protocol specification <xref target="RFC7285"/>, target="RFC7285" format="default"/>, 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.</t> addresses.</t>
        <t>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).</t>
        <t>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.</t>
      </section>
    </section>
    <section title="Implementation, numbered="true" toc="default">
      <name>Implementation, Deployment, and Operational Considerations"> Considerations</name>
      <section title="Considerations numbered="true" toc="default">
        <name>Considerations for ALTO Clients"> Clients</name>
        <section anchor="sec.rcid" title="Resource Consumer Initiated Discovery">

                <t>Resource consumer initiated numbered="true" toc="default">
          <name>Resource-Consumer-Initiated Discovery</name>
          <t>Resource-consumer-initiated
                ALTO server discovery
                (c.f. ALTO
                (cf.&nbsp;ALTO requirement AR-32 <xref target="RFC6708"/>) target="RFC6708" format="default"/>)
                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), (NATs), additional protocols and mechanisms such
                as STUN Session Traversal Utilities for NAT (STUN) <xref target="RFC5389"/>
		target="RFC5389" format="default"/> are usually needed to
                detect the client's "public" IP address, address before it can
                be used as a parameter to for the discovery procedure.
                Note that a different approach for
                resource consumer initiated
                resource-consumer-initiated ALTO server discovery,
                which is based on DHCP, is
                specified in
                <xref target="RFC7286"/>.</t> target="RFC7286" format="default"/>.</t>
        </section>
        <section title="IPv4/v6 numbered="true" toc="default">
          <name>IPv4/v6 Dual Stack, Multihoming and                 Host Mobility"> Mobility</name>
          <t>The procedure specified in this document can discover
                ALTO server URIs for a given IP address or prefix.
                The intention is, 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.</t>
          <t>However, resource consumers (as defined in Section 2 of
                <xref target="RFC5693"/>) target="RFC5693" format="default" sectionFormat="of"
		      section="2"/>) may reside on hosts with more than
                one IP address, e.g., address -- for example, due to IPv4/v6 dual stack operation
                and/or multihoming.
                IP packets sent with different source addresses may be
                subject to different routing policies and path costs.  In
                some deployment scenarios, it may even be required to ask
                different sets of ALTO servers for guidance.
                Furthermore, source addresses in IP packets may be modified
                en-route
                en route by Network Address Translators (NAT). (NATs).
          </t>
          <t>If a resource consumer queries a resource directory for
                candidate resource providers, the locally selected (and
                possibly en-route
                translated) en-route-translated) source address of the query
		message -&nbsp;as --&nbsp;as
                observed by the resource directory&nbsp;- directory&nbsp;-- 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&nbsp;effect" may not
                occur.</t>
          <t>One solution approach for this problem is, is that
                a dual stack dual-stack or multihomed resource consumer could
                always use the same address for contacting the
                resource directory and all resource providers, thus
                overriding the operating system's automatic selection of
		source IP address selection. addresses.
		For example, when using the
                BSD socket API, one could always bind() the socket to one of
                the local IP addresses before trying to connect() to the
                resource directory or the resource providers, respectively.
                Another solution approach is to perform ALTO-influenced
                resource provider selection (and source address source-address selection)
                locally in the resource consumer,
                in addition to to, or instead of of, performing it in the resource
                directory. See <xref target="sec.rcid"/> target="sec.rcid" format="default"/> for
		a discussion of
                how to discover ALTO servers for local usage in the
                resource consumer.</t>
          <t>Similarly, resource
                consumers on mobile hosts SHOULD <bcp14>SHOULD</bcp14> 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.
          </t>
        </section>
        <section title="Interaction numbered="true" toc="default">
          <name>Interaction with Network Address Translation"> Translation</name>
          <t>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 administrative domains,
                possibly the whole Internet.
                Due to the widespread usage of Network Address Translators
                (NAT)
                (NATs), it may well be that nodes of the overlay network
                (i.e., resource consumers or resource providers) are located
                behind a NAT, maybe even behind several cascaded NATs.</t>
          <t>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 it,
                will be used as a basis for ALTO-optimization. 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).
          </t>
          <t>If a resource directory receives a message from a resource
                consumer and the message's source address is a "private"
                IP address <xref target="RFC1918"/>, target="RFC1918" format="default"/>, this may be a sign
                that both of them are behind the same NAT. An invokation invocation
                of the ALTO Cross-Domain Server Discovery Procedure with
                this private address may be problematic, as this will only
                yield usable results if a DNS "split horizon" and DNSSEC
                trust anchors are configured correctly. In this situation situation,
                it may be more advisable to query an ALTO server that has
                been discovered using <xref target="RFC7286"/> target="RFC7286" format="default"/> or any
                other local configuration.
                The interaction between intra-domain intradomain ALTO for
                large private domains (e.g., behind a "carrier-grade NAT")
                and cross-domain, Internet-wide optimization, is beyond
                the scope of this document.
          </t>
        </section>
      </section>
      <section title="Considerations numbered="true" toc="default">
        <name>Considerations for Network Operators"> Operators</name>
        <section title="Flexibility numbered="true" toc="default">
          <name>Flexibility vs. Load on the DNS"> DNS</name>
          <t>The ALTO Cross-Domain Server Discovery Procedure, as
				specified in <xref target="sec.3pdisc-spec"/>, target="sec.3pdisc-spec"
				format="default"/>, first
                produces a list of domain names (steps (Steps 1 and 2) and
                then looks for relevant NAPTR records associated with
                these names, until a useful result can be found (step (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.
          </t>
          <t>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.</t>
          <t>On the other hand, the ALTO Cross-Domain Server Discovery
                Procedure trying to lookup look up truncated domain names allows for
                efficient configuration of large-scale scenarios, where
                discovery is to be enabled for a large number of IP
                addresses with a small number of additional DNS resource
                records.
                Note that expressly, it expressly has not been a design goal of this
                procedure to give clients a means to understand of understanding the IP
                prefix delegation structure. Furthermore, this specification
                does not assume or reccomend recommend that prefix delegations should
                preferrably
                preferably occur at those prefix lengths that are used
                in Step 2 of this procedure
                (see <xref target="sec.3pdisc-spec-step2"/>). target="sec.3pdisc-spec-step2" format="default"/>).
                A network operator that uses, for example, an IPv4 /18
                prefix and wants to install the NAPTR records efficiently, 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.</t>
        </section>
        <section title="BCP20 numbered="true" toc="default">
          <name>BCP 20 and missing delegations Missing Delegations of the reverse DNS">

                <t>RFC2317 <xref target="RFC2317"/>, Reverse DNS</name>
          <t><xref target="RFC2317" format="default"/>, also known as BCP20, BCP 20,
                describes a way to delegate the "reverse DNS" (i.e.,
                subdomains of in-addr.arpa.) "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 Procedure
                is compatible with this method.</t>
          <t>In some deployment scenarios, scenarios -- e.g., residential Internet
                access,
                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).</t>
          <t>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, Procedure,
                in the subdomain of in-addr.arpa. "in-addr.arpa." that corresponds to
                the whole /24 prefix (c.f., R24 (cf.&nbsp;R24 in
                <xref target="sec.3pdisc-spec-step2"/> target="sec.3pdisc-spec-step2" format="default"/> of this document),
                even if BCP20-style delegations in the style of BCP 20 or no delegations
	  at all are in use.</t>
        </section>
      </section>
    </section>
    <section anchor="seccons" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>A high-level discussion of security issues related to ALTO
            is part of the ALTO problem statement
            <xref target="RFC5693"/>. target="RFC5693" format="default"/>.  A classification of unwanted
            information disclosure risks, as well as specific
            security-related requirements requirements, can be found in the ALTO
            requirements document <xref target="RFC6708"/>. target="RFC6708" format="default"/>.
      </t>
      <t>The remainder of this section focuses on security threats
            and protection mechanisms for the cross-domain Cross-Domain ALTO server discovery
            procedure Server Discovery
            Procedure as such.  Once the ALTO server's URI has been
            discovered
            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
            <xref target="RFC7285"/> target="RFC7285" format="default"/> apply.
      </t>
      <section anchor="sec.sec.integrity"
            title="Integrity numbered="true" toc="default">
        <name>Integrity of the ALTO Server's URI">
            <t><list style="hanging">
                    <t hangText="Scenario Description">
                        <vspace blankLines="0" /> URI</name>
        <dl newline="true" spacing="normal">
          <dt>Scenario Description</dt>
          <dd>
            An attacker could compromise the ALTO server
            discovery procedure or the underlying infrastructure
            in such a way that ALTO clients would discover a "wrong"
            ALTO server URI.
                    </t>
                    <t hangText="Threat Discussion">
                        <vspace blankLines="0" />
          </dd>
          <dt>Threat Discussion</dt>
          <dd>
            The cross-domain Cross-Domain ALTO server discovery procedure Server Discovery Procedure
            relies on a series of DNS lookups, in order to
            produce one or more URI(s). URIs.
            If an attacker was were able to modify or spoof any of
            the DNS records, the resulting
                        URI(s)
            URIs could be replaced by forged URI(s). URIs.
            This is probably the most serious security
            concern related to ALTO server discovery. The
            discovered "wrong" ALTO server might not be able
            to give guidance to a given ALTO client at all,
            or it might give suboptimal or forged
            information. In the latter case, an attacker
            could try to use ALTO to affect the traffic
            distribution in the network or the performance
            of applications (see also Section 15.1. of
            <xref target="RFC7285"/>). target="RFC7285" format="default"
		  sectionFormat="of" section="15.1"/>).
            Furthermore, a hostile ALTO server could
            threaten user privacy (see also Section 5.2.1,
                        case Case (5a) in <xref target="RFC6708"/>).
                    </t>

                    <t hangText="Protection
	    target="RFC6708" sectionFormat="of" section="5.2.1"/>).
          </dd>
          <dt>Protection Strategies and Mechanisms">
                        <vspace blankLines="0" /> Mechanisms</dt>
          <dd>
            The application of DNS security (DNSSEC)
            <xref target="RFC4033"/> target="RFC4033" format="default"/> provides a means to
                        detect of
            detecting and avert averting attacks that rely on modification
            of the DNS records while in transit. All
            implementations of the cross-domain Cross-Domain ALTO server
                        discovery procedure MUST Server
            Discovery Procedure <bcp14>MUST</bcp14> 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
            Cross-Domain ALTO server discovery procedure
                        SHOULD Server Discovery Procedure
            <bcp14>SHOULD</bcp14> use DNSSEC to protect their subdomains
            of in-addr.arpa. "in-addr.arpa." and/or ip6.arpa., "ip6.arpa.", respectively.
            Additional operational precautions for safely operating
            the DNS infrastructure are required in order
            to ensure that name servers do not sign forged
            (or otherwise "wrong") resource records.
            Security considerations specific to U-NAPTR are
            described in more detail in <xref target="RFC4848"/>.
                    </t>
                    <t> target="RFC4848" format="default"/>.
          </dd>
          <dt/>
          <dd>
            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
            <xref target="RFC7285"/>).
                    </t>
                    <t hangText="Note">
                        <vspace blankLines="0" /> target="RFC7285"
		  format="default" sectionFormat="of" section="15.2"/>).
          </dd>
          <dt>Note</dt>
          <dd>
            The cross-domain Cross-Domain ALTO server discovery procedure Server Discovery Procedure
            finishes successfully when it has discovered one
            or more URI(s). URIs. Once an ALTO server's URI has been
            discovered and the communication between the ALTO
            client and the ALTO server starts, the security
            threats and protection mechanisms discussed in the
            ALTO protocol specification <xref target="RFC7285"/> target="RFC7285" format="default"/>
            apply.
                    </t>
                    <t>
          </dd>
          <dt/>
          <dd>
            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
            <xref target="RFC7285"/>. target="RFC7285" format="default"
		  sectionFormat="of" section="15.1"/>.

            The ALTO protocol's primary mechanism for protecting
            authenticity and integrity (as well as confidentiality)
            is the use of
            HTTPS-based transport, transport -- i.e., HTTP over TLS
            <xref target="RFC2818"/>. target="RFC2818" format="default"/>.

            Typically, when the URI's host component is a host
            name, a further DNS lookup is needed to map it to an
            IP address, 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 <xref target="RFC2818"/> target="RFC2818" format="default"/> are able to
            detect DNS spoofing or similar attacks, 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
            Cross-Domain ALTO server discovery procedure, Server Discovery Procedure,
            and therefore, these resource records have to
            be secured using DNSSEC.
                    </t>
                </list>
            </t>
          </dd>
        </dl>
      </section>
      <section title="Availability numbered="true" toc="default">
        <name>Availability of the ALTO Server Discovery Procedure">
            <t><list style="hanging">
                    <t hangText="Scenario Description">
                        <vspace blankLines="0" /> Procedure</name>
        <dl newline="true" spacing="normal">
          <dt>Scenario Description</dt>
          <dd>
            An attacker could compromise the cross-domain Cross-Domain ALTO
                        server discovery procedure
            Server Discovery Procedure or the underlying
            infrastructure in such a way that ALTO clients would not
            be able to discover any ALTO server.
                    </t>
                    <t hangText="Threat Discussion">
                        <vspace blankLines="0" />
          </dd>
          <dt>Threat Discussion</dt>
          <dd>
            If no ALTO server can be discovered (although a
            suitable one exists) 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 the resulting application performance
            and traffic distribution will correspond to a
            deployment scenario without ALTO.
                    </t>
                    <t hangText="Protection
          </dd>
          <dt>Protection Strategies and Mechanisms">
                        <vspace blankLines="0" /> Mechanisms</dt>
          <dd>
            Operators should follow best current practices
            to secure their DNS and ALTO servers (see Section 15.5 of
            <xref target="RFC7285"/>)
                        servers target="RFC7285" format="default"
		  sectionFormat="of" section="15.5"/>)
            against Denial-of-Service (DoS) attacks.
                    </t>
                </list>
            </t>
          </dd>
        </dl>
      </section>
      <section title="Confidentiality numbered="true" toc="default">
        <name>Confidentiality of the ALTO Server's URI">
            <t><list style="hanging">
                    <t hangText="Scenario Description">
                        <vspace blankLines="0"/> URI</name>
        <dl newline="true" spacing="normal">
          <dt>Scenario Description</dt>
          <dd>
            An unauthorized party could invoke the cross-domain Cross-Domain ALTO
                        server discovery procedure,
            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.
                    </t>
                    <t hangText="Threat Discussion">
                        <vspace blankLines="0" />
          </dd>
          <dt>Threat Discussion</dt>
          <dd>
                        In the ALTO use cases that have been described
                        in the ALTO problem statement
                        <xref target="RFC5693"/> target="RFC5693" format="default"/> 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.
                    </t>
                    <t hangText="Protection
                    </dd>
          <dt>Protection Strategies and Mechanisms">
                        <vspace blankLines="0" /> Mechanisms</dt>
          <dd>
                        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.
                    </t>
                </list>
            </t>
                    </dd>
        </dl>
      </section>
      <section title="Privacy for ALTO Clients">
            <t><list style="hanging">
                    <t hangText="Scenario Description">
                        <vspace blankLines="0"/> numbered="true" toc="default">
        <name>Privacy for ALTO Clients</name>
        <dl newline="true" spacing="normal">
          <dt>Scenario Description</dt>
          <dd>
                        An unauthorized party could eavesdrop on the
                        messages between an ALTO client and the
                        DNS servers, 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.
                    </t>
                    <t hangText="Threat Discussion">
                        <vspace blankLines="0" />
                    </dd>
          <dt>Threat Discussion</dt>
          <dd>
                        In the ALTO use cases that have been described
                        in the ALTO problem statement
                        <xref target="RFC5693"/> target="RFC5693" format="default"/> and/or discussed in the
                        ALTO working group, this scenario has not been
                        identified as a relevant threat. However,
                        Pervasive Surveillance
                        pervasive surveillance <xref target="RFC7624"/> target="RFC7624"
			format="default"/>
                        and DNS Privacy Considerations privacy considerations <xref target="RFC7626"/> target="RFC7626"
			format="default"/>
                        have seen significant attention in the Internet
                        community in recent years.
                    </t>
                    <t hangText="Protection
                    </dd>
          <dt>Protection Strategies and Mechanisms">
                        <vspace blankLines="0" /> Mechanisms</dt>
          <dd>
                        DNS over TLS <xref target="RFC7858"/> target="RFC7858" format="default"/> and
                        DNS over HTTPS <xref target="RFC8484"/> target="RFC8484" format="default"/> 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.
                    </t>
                </list>
            </t>
                    </dd>
        </dl>
      </section>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document does not require any has no IANA action.</t> actions.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119" ?>
      <?rfc include="reference.RFC.3403" ?>
      <?rfc include="reference.RFC.4848" ?>
      <?rfc include="reference.RFC.1035" ?>
      <?rfc include="reference.RFC.3596" ?>
      <?rfc include="reference.RFC.8174" ?>
<displayreference target="I-D.kiesel-alto-alto4alto" to="ALTO4ALTO" />
<displayreference target="I-D.kiesel-alto-ip-based-srv-disc" to="ALTO-ANYCAST" />

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3403.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4848.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3596.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2317.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4632.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5389.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5693.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6708.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7216.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7285.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7286.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7624.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7626.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7971.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>

<!-- draft-kiesel-alto-ip-based-srv-disc-03 is expired -->
        <xi:include
	    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.kiesel-alto-ip-based-srv-disc.xml"/>

<!-- draft-kiesel-alto-alto4alto-00 is expired -->
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.kiesel-alto-alto4alto.xml"/>
      </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.1918" ?>
      <?rfc include="reference.RFC.2317" ?>
      <?rfc include="reference.RFC.2818" ?>
      <?rfc include="reference.RFC.4033" ?>
      <?rfc include="reference.RFC.4291" ?>
      <?rfc include="reference.RFC.4632" ?>
      <?rfc include="reference.RFC.5389" ?>
      <?rfc include="reference.RFC.5693" ?>
      <?rfc include="reference.RFC.6708" ?>
      <?rfc include="reference.RFC.7216" ?>
      <?rfc include="reference.RFC.7285" ?>
      <?rfc include="reference.RFC.7286" ?>
      <?rfc include="reference.RFC.7624" ?>
      <?rfc include="reference.RFC.7626" ?>
      <?rfc include="reference.RFC.7858" ?>
      <?rfc include="reference.RFC.7971" ?>
      <?rfc include="reference.RFC.8484" ?>
      <?rfc include="reference.I-D.kiesel-alto-ip-based-srv-disc" ?>
      <?rfc include="reference.I-D.kiesel-alto-alto4alto" ?>
    </references>
    <section anchor="sec.multiplesources"
    title="Solution numbered="true" toc="default">
      <name>Solution Approaches for Partitioned ALTO Knowledge"> Knowledge</name>
      <t>
            The ALTO base protocol document <xref target="RFC7285"/> target="RFC7285" format="default"/>
            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.
      </t>
      <section title="Classification numbered="true" toc="default">
        <name>Classification of Solution Approaches"> Approaches</name>
        <t>
                Various protocol extensions and other solutions have been
                proposed to deal with multiple information sources and
                partitioned knowledge.  They can be classified as follows:

                <list style='hanging' hangIndent='5'>

                    <t hangText="1">

        </t>

<ol>
<!-- Item 1 -->
  <li><t>
    Ensure that all ALTO servers have the same
                        knowledge
                    </t>
                    <t hangText="1.1">
    knowledge.</t>
<!-- 1.1 -->
<ol type="1.%d">
      <li>
    Ensure data replication and synchronization
    within the provisioning protocol (cf.
                        <xref target="RFC5693">RFC 5693, Fig 1</xref>).
                    </t>
                    <t hangText="1.2"> (cf.&nbsp;<xref target="RFC5693" format="default"/>, Figure 1).
      </li>
<!-- 1.2 -->
      <li>
    Use an Inter-ALTO-server 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.
                    </t>

                    <t hangText="2">
      </li>
</ol>
  </li>
<!-- Item 2 -->
    <li><t>
    Accept that different ALTO servers (possibly
    operated by different organizations, e.g., ISPs)
    do not have the same knowledge
                    </t>
                    <t hangText="2.1"> knowledge.</t>

<!-- 2.1 -->
<ol type="2.%d">
<li>
      Allow ALTO clients to send arbitrary queries to
      any ALTO server (e.g. (e.g., the one discovered using
      <xref target="RFC7286"/>). target="RFC7286" format="default"/>).  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.
                    </t>
                    <t hangText="2.2">
    </li>
<!-- 2.2 -->
    <li>
      Allow ALTO clients to send arbitrary queries to
      any ALTO server (e.g. (e.g., the one discovered using
      <xref target="RFC7286"/>). target="RFC7286" format="default"/>).  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.
                    </t>
                    <t hangText="2.3">
    </li>
<!-- 2.3 -->
    <li>
      ALTO clients need to use some kind of "search
      engine" that indexes ALTO servers and redirects
      and/or gives cached results.
                    </t>

                    <t hangText="2.4">
    </li>
<!-- 2.4 -->
    <li>
      ALTO clients need to use a new discovery mechanism
      to discover the ALTO server that has the desired
      information and contact it directly.
                    </t>

                </list>
            </t>
    </li>
</ol>
    </li>
</ol>
      </section>
      <section title="Discussion numbered="true" toc="default">
        <name>Discussion of Solution Approaches"> Approaches</name>
        <t>
          The provisioning or initialization protocol for
                ALTO servers
                (cf. <xref target="RFC5693">RFC 5693, Fig 1</xref>)
                (cf.&nbsp;<xref target="RFC5693" format="default"/>, Figure 1)
                is currently not standardized.  It was a conscious
                decision not to include this in the scope of the
                IETF ALTO working group.  The reason is that there
                are many different kinds of information sources.
                This implementation specific 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 Approach 1.1) would overload this protocol with a
                second functionality that requires standardization for
                seamless multi-domain multidomain operation.
        </t>
<t>
   For the 1.? solution approaches, Approaches 1.1 and 1.2, in addition to general technical
   feasibility and issues like overhead and caching efficiency, another
   aspect to consider is legal liability. Operator "A" might prefer not to
                publish information about nodes in in, or paths between 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,
                networks or on their business models.
        </t>
        <t>
                No specific actions to build a solution based on a "search
		engine" based
                solution (approach (Approach 2.3) are currently known 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.
        </t>
      </section>
      <section title="The numbered="true" toc="default">
        <name>The Need for Cross-Domain ALTO Server Discovery"> Discovery</name>

<t>
Approaches 1.1, 1.2, 2.1, and 2.2 do not only require more than just the
specification of an ALTO protocol extension or a new protocol that
runs between ALTO servers. A large-scale,
                maybe Internet-wide, multi-domain multidomain deployment would also need
                mechanisms by which an ALTO server could discover other ALTO
                servers, learn which information is available where, and
                ideally also who is authorized to publish information
                related to a given part of the network.  Approach 2.4 needs
                the same mechanisms, except that they are used on the
                client-side
                client side instead of the server-side. server side.
        </t>
        <t>
                It is sometimes questioned whether there is a need for a
                solution that allows clients to ask arbitrary queries, even
                if the ALTO information is partitioned and stored on many
                ALTO servers.  The main argument is, 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, server -- i.e., the one that can be
                discovered using <xref target="RFC7286"/>. target="RFC7286" format="default"/>.  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 party that
                takes part in the application signaling, 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 <xref
                target="apx.alto_p2p"/>. target="apx.alto_p2p" format="default"/>.
        </t>
      </section>
      <section title="Our numbered="true" toc="default">
        <name>Our Solution Approach"> Approach</name>
        <t>
                Several solution approaches for cross-domain ALTO server
                discovery have been evaluated, using the criteria
                documented in <xref target="sec.xdom-disc-reqs"/>. target="sec.xdom-disc-reqs" format="default"/>.
                One of them was to use the ALTO protocol itself for
                the exchange of information availability
                <xref target="I-D.kiesel-alto-alto4alto"/>. target="I-D.kiesel-alto-alto4alto" format="default"/>.
                However, the drawback of that approach is that a new
                registration administration authority would have to
                be established.
        </t>
        <t>
                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" <xref target="RFC7216"/>. target="RFC7216" format="default"/>.  The
                primary goal is that this procedure can be used on the
                client-side
                client side (i.e., approach Approach 2.4), but together with new
                protocols or protocol extensions extensions, it could also be used to
                implement the other solution approaches itemized above.
        </t>
      </section>
      <section title="Relation numbered="true" toc="default">
        <name>Relation to the ALTO Requirements"> Requirements</name>
        <t>During the design phase of the overall ALTO solution, two
            different server discovery scenarios have been were identified and
            documented in the ALTO requirements document
            <xref target="RFC6708"/>. target="RFC6708" format="default"/>.  The first scenario,
	    documented in
            Req. AR-32, can be supported using the discovery mechanisms
            specified in <xref target="RFC7286"/>. target="RFC7286" format="default"/>.
            An alternative approach, based on IP anycast
            <xref target="I-D.kiesel-alto-ip-based-srv-disc"/>, target="I-D.kiesel-alto-ip-based-srv-disc" format="default"/>,
            has also been studied.
            This document, in contrast, tries to address Req. AR-33.
        </t>
      </section>
    </section>
    <section anchor="sec.xdom-disc-reqs"
        title="Requirements numbered="true" toc="default">
      <name>Requirements for Cross-Domain Server Discovery"> Discovery</name>
      <t>This appendix itemizes requirements that have been were
            collected before the design phase and that are reflected
            by
            in the design of the ALTO Cross-Domain Server Discovery Procedure.
      </t>
      <section title="Discovery numbered="true" toc="default">
        <name>Discovery Client Application Programming Interface"> Interface</name>
        <t>The discovery client will be called through some kind of
            application programming interface (API) (API), and the parameters
            will be an IP address and, for purposes of extensibility,
            a service identifier such as "ALTO". It The client will return one or more
            URI(s)
            URIs that offers offer the requested service ("ALTO") for the given
            IP address.
        </t>
        <t>In other words, the client would be used to retrieve a
            mapping:</t>
        <t>(IP address, "ALTO") -> -&gt; IRD-URI(s)</t>
        <t>where IRD-URI(s) is one or more URI(s) URIs of
            Information Resource Directories
            (IRD,
            (IRDs, see Section 9 of <xref target="RFC7285"/>) target="RFC7285" format="default"
	    sectionFormat="of" section="9"/>)
            of ALTO server(s) servers that can give reasonable guidance
            to a resource consumer with the indicated IP address.</t>
      </section>
      <section title="Data numbered="true" toc="default">
        <name>Data Storage and Authority Requirements"> Requirements</name>
        <t>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 a URI is defined
            by the authority that has administrative control over
            this IP address, address -- e.g., the ISP in residential access networks
            or the IT department in enterprise, university, or similar
            networks.
        </t>
      </section>
      <section title="Cross-Domain numbered="true" toc="default">
        <name>Cross-Domain Operations Requirements"> Requirements</name>
        <t>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
            This, in turn 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.
        </t>
        <t>The ALTO Cross-Domain Server Discovery protocol Protocol must
            support gradual deployment without a network-wide flag day.
            If the mechanism needs some kind of well-known "rendezvous
            point", re-using reusing an existing infrastructure (such as the DNS
            root servers or the WHOIS database) should be preferred over
            establishing a new one.</t>
      </section>
      <section title="Protocol Requirements"> numbered="true" toc="default">
        <name>Protocol Requirements</name>
        <t>The protocol must be able to operate across middleboxes,
            especially across NATs and firewalls.
        </t>
        <t>The protocol shall not require any pre-knowledge preknowledge from
            the client other than any information that is known to
            a regular IP host on the Internet.
        </t>
      </section>
      <section title="Further Requirements"> numbered="true" toc="default">
        <name>Further Requirements</name>
        <t>The ALTO cross domain cross-domain server discovery cannot assume that
            the server discovery server-discovery client and the server discovery server-discovery
            responding entity are under the same administrative
            control.
        </t>
      </section>
    </section>
    <section anchor="apx.alto_p2p" title="ALTO numbered="true" toc="default">
      <name>ALTO and Tracker-based Tracker-Based Peer-to-Peer Applications"> Applications</name>
      <t>This appendix provides a complete example of using ALTO and
        the ALTO Cross-Domain Server Discovery Procedure in one
        specific application scenario, namely scenario -- namely, a tracker-based peer-to-peer
        application. First, in
        subsection
        <xref target="apx.alto_p2p_app" format="counter"/>, target="apx.alto_p2p_app"/>,
        we introduce a generic model of such an
        application and show why ALTO optimization is desirable. Then,
        in <xref target="apx.alto_p2p_arch" format="counter"/>, target="apx.alto_p2p_arch"/>,
        we introduce two architectural options for integrating ALTO
        into the tracker-based peer-to-peer application - application; one option
        is based on the "regular" ALTO server discovery
        procedure <xref target="RFC7286"/>, target="RFC7286" format="default"/>, and one relies on the
        ALTO Cross-Domain Server Discovery Procedure.
        In <xref target="apx.alto_p2p_eval" format="counter"/>, target="apx.alto_p2p_eval"/>,
        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 <xref target="apx.alto_p2p_example" format="counter"/>, />,
        which details an exemplary complete walk-through of the
        ALTO Cross-Domain Server Discovery Procedure.</t>
      <section anchor="apx.alto_p2p_app"
            title="A generic Tracker-based numbered="true" toc="default">
        <name>A Generic Tracker-Based Peer-to-Peer Application"> Application</name>
        <t>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.</t>
        <t>For the remainder of this chapter chapter, we consider a generic,
            tracker-based peer-to-peer file sharing 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 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 only
            a subset of all peers in the swarm.
            If a new peer wants to join a swarm, it first contacts a
            well-known server, the "tracker", which provides a list of IP
            addresses of peers in the swarm.</t>
        <t>A swarm is an overlay network on top of the IP network.
            Algorithms that determine the overlay topology and the traffic
            distribution in the overlay may consider information about
            the underlying IP network, such as topological distance,
            link bandwidth, (monetary) costs for sending traffic from
            one host to another, etc.
            ALTO is a protocol for retrieving such information.
            The goal of such "topology aware" "topology-aware" decisions is to improve
            performance or Quality of Experience in the application while
            reducing the utilization of the underlying network
            infrastructure.
        </t>
      </section>
      <section anchor="apx.alto_p2p_arch"
            title="Architectural numbered="true" toc="default">
        <name>Architectural Options for Placing the ALTO Client"> Client</name>
        <t>The ALTO protocol specification <xref
            target="RFC7285"/> target="RFC7285" format="default"/> 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 possible locations for where to place the
            ALTO client:
            <list style='numbers'>
                <t>ALTO
        </t>
        <ol spacing="normal" type="1">
          <li>ALTO client in the resource consumer ("peer")</t>
                <t>ALTO ("peer")</li>
          <li>ALTO client in the resource directory ("tracker")</t>
            </list></t> ("tracker")</li>
        </ol>
        <t>In the following, both scenarios are compared in order to
            explain the need for ALTO queries on behalf of remote resource
            consumers.</t>
        <t>In the first scenario (see <xref target="fig.rcq"/>), target="fig.rcq" format="default"/>), 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.</t>
        <t>In the second scenario (see <xref target="fig.3pq"/>), target="fig.3pq" format="default"/>),
            the resource directory has an embedded ALTO client. After
            receiving a query for a given resource (F1) (F1), the resource directory
            invokes this ALTO client to evaluate all resource providers it
            knows (F2/F3).  Then it returns a, a list, possibly shortened, list
            containing the "best" resource providers to the resource
            consumer (F4).</t>

      <t><figure anchor="fig.tracker_random_preselect"
          title="Tracker-based
        <figure anchor="fig.tracker_random_preselect">
          <name>Tracker-Based P2P Application with random peer preselection">
        <artwork><![CDATA[ Random Peer Preselection</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 .............................          .............................
 : 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 |
                                          +-______-+
]]></artwork>
      </figure></t>

      <t><figure anchor="fig.rcq"
          title="Basic message sequence chart
        </figure>
        <figure anchor="fig.rcq">
          <name>Basic Message Sequence Chart for resource consumer-initiated Resource Consumer-Initiated ALTO query">
            <artwork><![CDATA[ Query</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
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
]]></artwork>
      </figure></t>

      <t><figure anchor="fig.tracker_alto_client"
          title="Tracker-based
        </figure>
        <figure anchor="fig.tracker_alto_client">
          <name>Tracker-Based P2P Application with ALTO client Client in tracker">
        <artwork><![CDATA[ Tracker</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 .............................          .............................
 : 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 |
                   +-______-+
]]></artwork>
      </figure></t>

      <t><figure anchor="fig.3pq"
          title="Basic message sequence chart
        </figure>
        <figure anchor="fig.3pq">
          <name>Basic Message Sequence Chart for ALTO query Query on behalf Behalf of remote resource consumer">
            <artwork><![CDATA[ Remote Resource Consumer</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
      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
]]></artwork>
      </figure></t>

            <t>Note: the
        </figure>

        <aside><t>Note: The message sequences depicted in Figures <xref
            target="fig.rcq"/> target="fig.rcq"
	format="counter"/> and <xref target="fig.3pq"/> target="fig.3pq" format="counter"/> may
	occur
            both in the target-aware and the target-independent query
            mode (c.f. <xref target="RFC6708"/>). (cf.&nbsp;<xref target="RFC6708" format="default"/>). In the
            target-independent query mode 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.</t> ago.</t></aside>
      </section>
      <section anchor="apx.alto_p2p_eval" title="Evaluation"> numbered="true" toc="default">
        <name>Evaluation</name>
        <t>The problem with the first approach is, 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.</t>
        <t>For illustration, consider a simple model of a swarm, in
            which all peers fall into one of only two categories: assume
            that there are only "good" ("good" in (in the sense of ALTO's
            better-than-random peer selection, based on an arbitrary
            desired rating criterion) and "bad' peers only. "bad" peers. Having more
            different categories makes the maths math more complex but does
            not change anything to about the basic outcome of this analysis.
            Assume that the swarm has a total number of N peers, out of
            which there are M "good" and N-M "bad" peers, which are all known
            to the tracker. A new peer wants to join the swarm and
            therefore asks the tracker for a list of peers.</t>
        <t>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:</t>

      <t><figure><artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[
            / 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)!

]]></artwork></figure></t>
]]></artwork>
        <t>The probability that the reply contains at most k "good"
            peers is: P(X&lt;=k)=P(X=0)+P(X=1)+..+P(X=k).</t> P(X&lt;=k) = P(X=0) + P(X=1) + .. + P&wj;(X=k).</t>
        <t>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&wj;(X=0)=36%, P(X&lt;=4)=99%. That is, with a
            probability of approx. 36% approximately 36%, this list does not contain a
            single "good" peer, and with 99% probability probability, there are only
            four or less fewer of the "good" peers on the list.  Processing
            this list with the guiding ALTO information will ensure that
            the few favorable peers are ranked to the top of the list;
            however, the benefit is rather limited as the number of
            favorable peers in the list is just too small.</t>
        <t>Much better traffic optimization could be achieved if the
            tracker would evaluate all known peers using ALTO, ALTO and
            return a list of 100 peers afterwards.  This list would then
            include a significantly higher fraction of "good"
            peers. (Note, (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.) </t>
        <t>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 that 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.
        </t>

            <!-- force a page break -->
            <t><vspace blankLines="99"/></t>
        <t/>
      </section>
      <section anchor="apx.alto_p2p_example" title="Example"> numbered="true" toc="default">
        <name>Example</name>
        <t>This section provides a complete example of the
            ALTO Cross-Domain Server Discovery Procedure in a tracker-based
            peer-to-peer scenario.</t>
        <t>The example is based on the network topology shown in
            <xref target="fig.example_network_topology"/>. target="fig.example_network_topology" format="default"/>.
            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, network -- i.e., ALTO_SRV_A,
            ALTO_SRV_B, ALTO_SRV_C, ALTO_SRV_X, and ALTO_SRV_T,
            respectively.

        </t>
        <figure anchor="fig.example_network_topology"
          title="Example network topology">
        <artwork><![CDATA[ anchor="fig.example_network_topology">
          <name>Example Network Topology</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
     _____    __             _____    __             _____    __
  __(     )__(  )_        __(     )__(  )_        __(     )__(  )_
 (    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 __)
              (___)--(____)           (___)--(____)
]]></artwork>
      </figure></t>
        </figure>
        <t>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" X",
            in accordance to with the terminology of <xref target="RFC6708"/> target="RFC6708"
	    format="default"/>, 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.</t>
        <t>As shown in the previous section, a tracker-side ALTO
            optimization (c.f.&nbsp;<xref target="fig.tracker_alto_client"/> (cf.&nbsp;Figures <xref target="fig.tracker_alto_client"
	    format="counter"/>
            and <xref target="fig.3pq"/>) target="fig.3pq" format="counter"/>)
            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 and X and C, in order to sort
            A, B, and C by their respective routing costs to X.</t>
        <t>In theory, there are many options for how the
            ALTO Cross-Domain Server Discovery Procedure could be used.
            For example,
            the tracker could do the following steps:

<figure><artwork><![CDATA[

</t>
<sourcecode type="pseudocode">
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
]]></artwork></figure>

            Maybe,
</sourcecode>

        <t>

            In this scenario, the ALTO Cross-Domain Server Discovery Procedure
            queries would yield in this scenario: might yield:  IRD_URIS_A = ALTO_SRV_A,
            IRD_URIS_B = ALTO_SRV_B, and IRD_URIS_C = ALTO_SRV_C.
            That is, each ECS query would be sent to a different
            ALTO server. The problem with this approach is that we are
            not neccessarily necessarily able to
            compare COST_X_A, COST_X_B, and COST_X_C with each
            other. The specification of the routingcost metric
            mandates that "A lower value indicates a higher preference",
            but "an ISP may internally compute routing cost using any method
            that it chooses"
            (see section 6.1.1.1. of <xref target="RFC7285"/>). target="RFC7285" format="default"
	    sectionFormat="of" section="6.1.1.1"/>).
            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 obviously cannot be compared with each other. Even if there was were
            a reasonable formula to compare, for example, kilometers
            with milliseconds, we could not use it, as the units of measurement
            (or any other information about the computation method
            for the routingcost) are
            not sent along with the value in the ECS reply.</t>
        <t>To avoid this problem, the tracker tries to send all
            ECS queries to the same ALTO server. As specified
            in <xref target="sec.ecs"/> target="sec.ecs" format="default"/> of this document, case Case 2, it uses
            the IP address of Resource Consumer x as a parameter to of
            the discovery procedure:

<figure><artwork><![CDATA[

</t>

<sourcecode type="pseudocode">
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
]]></artwork></figure>
</sourcecode>
        <t>

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

            <!-- force a page break -->
            <t><vspace blankLines="99"/></t>
        <t/>
        <t>As discussed above, the tracker calls the ALTO Cross-Domain
            Server Discovery Procedure with IP address X as a
            parameter.  For the reminder remainder of this example, we assume
            that X = 2001:DB8:1:2:227:eff:fe6a:de42.  Thus, the
            procedure call is <vspace blankLines="1"/>
            IRD_URIS_X = XDOMDISC(2001:DB8:1:2:227:eff:fe6a:de42,"ALTO:https").
        </t>
        <t>The first parameter 2001:DB8:1:2:227:eff:fe6a:de42 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".
        </t>
        <t>The procedure constructs
            (see Step 1 in <xref target="sec.3pdisc-spec-step1"/>)<vspace/> target="sec.3pdisc-spec-step1"
	    format="default"/>)
	</t>

<sourcecode type="pseudocode">
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
        8.B.D.0.1.0.0.2.IP6.ARPA."
</sourcecode>
<t>as well as the following
            (see Step 2 in <xref target="sec.3pdisc-spec-step2"/>)<vspace/> target="sec.3pdisc-spec-step1"
	    format="default"/>):
	</t>
<sourcecode type="pseudocode">
R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",<vspace/> "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.",<vspace/> "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.",<vspace/> "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<vspace/> "0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.".
            </t> "8.B.D.0.1.0.0.2.IP6.ARPA."
</sourcecode>

        <t>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, utility but instead would use
            appropriate libraries and/or operating system operating-system APIs.
            Please note that the following steps have been performed in a
            controlled lab environment with a an appropriately configured
            name server. A suitable DNS configuration will be needed
            to reproduce these results. Please also note that the rather
            verbose output of the "dig" tool has been shortened to the
            relevant lines.</t>
        <t>Since AT = IPv6 and L = 128, in the table given
            in <xref target="sec.3pdisc-spec-step3"/>, target="sec.3pdisc-spec-step3" format="default"/>, the sixth row
            (not counting the column headers) applies.</t>
        <t>As mandated by the third column, we start with a lookup
            of R128, looking for NAPTR resource records:

<figure><artwork><![CDATA[

</t>
<artwork>
| 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<<- ->>HEADER&lt;&lt;- opcode: QUERY, status: NXDOMAIN, id: 26553
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0
]]></artwork></figure>
</artwork>

        <t>

            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:

<figure><artwork><![CDATA[

</t>
<artwork>
| 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<<- ->>HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 33193
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0
]]></artwork></figure>
</artwork>
        <t>

            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 There may be some other resource records such as
            PTR, NS, or SOA, but we are not interested in them.
            Thus, we do not get a useful result result, and we continue with
            looking up R56:

<figure><artwork><![CDATA[

</t>
<artwork>
| user@labpc:~$ dig -tNAPTR 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
|
| ;; Got answer:
| ;; ->>HEADER<<- ->>HEADER&lt;&lt;- 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!" .
]]></artwork></figure>
</artwork>
        <t>

            The domain name R56 could be looked up 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 <xref target="RFC7216"/> target="RFC7216" format="default"/> for "LIS:HELD"),
            and therefore, therefore we have to ignore them.
            Consequently, we still do not have a useful result and
            continue with a lookup of R48:

<figure><artwork><![CDATA[

</t>
<artwork>
| user@labpc:~$ dig -tNAPTR 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
|
| ;; Got answer:
| ;; ->>HEADER<<- ->>HEADER&lt;&lt;- 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!" .
]]></artwork></figure>
</artwork>
        <t>

            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".
        </t>
        <t>The ALTO client that is embedded in the tracker will
            access the ALTO Information Resource Directory
            (IRD, see Section 9 of <xref target="RFC7285"/>) target="RFC7285" format="default"
	    sectionFormat="of" section="9"/>)
            at this URI, look for the Endpoint Cost Service
            (ECS, see Section 11.5 of <xref target="RFC7285"/>), target="RFC7285" format="default"
	    sectionFormat="of" section="11.5"/>),
            and query the ECS for the costs between A and X,
            B and X, as well as and C and X, before returning
            an ALTO-optimized list of candidate resource providers
            to resource consumer X.</t>
      </section>
    </section>

    <section title="Contributors

<!-- [rfced] FYI, we have changed the title from "Contributors List and Acknowledgments">
Acknowledgements" to simply "Acknowledgements", as those are typically
separate sections. Please let us know if you'd like to move text into a
"Contributors" section.
-->

    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The initial draft version of this document was co-authored by
        Marco Tomsu
        <contact fullname="Marco Tomsu"/> (Alcatel-Lucent).</t>
      <t>This document borrows some text from <xref target="RFC7286"/>, target="RFC7286" format="default"/>,
        as historically, it has been was part of the draft that
        eventually became said RFC.
        Special thanks to Michael Scharf and Nico Schwan.</t> <contact fullname="Michael Scharf"/> and <contact fullname="Nico Schwan"/>.</t>
    </section>
  </back>
</rfc>