rfc8686xml2.original.xml   rfc8686.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <?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 category="std" docName="draft-ietf-alto-xdom-disc-06" ipr="trust200902">
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
<title abbrev='ALTO Cross-Domain Server Discovery'> docName="draft-ietf-alto-xdom-disc-06" ipr="trust200902" obsoletes=""
Application Layer Traffic Optimization (ALTO) updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="2"
Cross-Domain Server Discovery symRefs="true" sortRefs="true" version="3" number="8686" consensus="true">
</title>
<!-- xml2rfc v2v3 conversion 2.35.0 -->
<front>
<title abbrev="ALTO Cross-Domain Server Discovery">
Application-Layer Traffic Optimization (ALTO)
Cross&nbhy;Domain Server Discovery
</title>
<seriesInfo name="RFC" value="8686"/>
<author fullname="Sebastian Kiesel" initials="S." surname="Kiesel"> <author fullname="Sebastian Kiesel" initials="S." surname="Kiesel">
<organization abbrev="University of Stuttgart"> <organization abbrev="University of Stuttgart">
University of Stuttgart Information Center University of Stuttgart Information Center
</organization> </organization>
<address> <address>
<postal> <postal>
<street>Allmandring 30</street> <street>Allmandring 30</street>
<city>Stuttgart</city> <city>Stuttgart</city>
<code>70550</code> <code>70550</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>ietf-alto@skiesel.de</email> <email>ietf-alto@skiesel.de</email>
<uri>http://www.izus.uni-stuttgart.de</uri> <uri>http://www.izus.uni-stuttgart.de</uri>
</address> </address>
</author> </author>
<author fullname="Martin Stiemerling" initials="M." surname="Stiemerling"> <author fullname="Martin Stiemerling" initials="M." surname="Stiemerling">
<organization abbrev="H-DA"> <organization abbrev="H-DA">
University of Applied Sciences Darmstadt, University of Applied Sciences Darmstadt,
Computer Science Dept. Computer Science Dept.
</organization> </organization>
<address> <address>
<postal> <postal>
<street>Haardtring 100</street> <street>Haardtring 100</street>
<code>64295</code> <code>64295</code>
<city>Darmstadt</city> <city>Darmstadt</city>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<phone>+49 6151 16 37938</phone> <phone>+49 6151 16 37938</phone>
<email>mls.ietf@gmail.com</email> <email>mls.ietf@gmail.com</email>
<uri>http://ietf.stiemerling.org</uri> <uri>https://danet.fbi.h-da.de</uri>
</address> </address>
</author> </author>
<date year="2020" month="February"/>
<date year="2019" />
<area>TSV</area> <area>TSV</area>
<workgroup>ALTO</workgroup> <workgroup>ALTO</workgroup>
<keyword>Application-Layer Traffic Optimization (ALTO)</keyword> <keyword>Application-Layer Traffic Optimization (ALTO)</keyword>
<keyword>ALTO cross-domain server discovery</keyword> <keyword>ALTO cross-domain server discovery</keyword>
<keyword>ALTO third-party server discovery</keyword> <keyword>ALTO third-party server discovery</keyword>
<abstract> <abstract>
<t>The goal of Application-Layer Traffic Optimization (ALTO) is to
<t>The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications that have to select one or several provide guidance to applications that have to select one or several
hosts from a set of candidates capable of providing a desired hosts from a set of candidates capable of providing a desired
resource. ALTO is realized by a client-server protocol. Before an resource. ALTO is realized by a client-server protocol. Before an
ALTO client can ask for guidance it needs to discover one or more ALTO client can ask for guidance, it needs to discover one or more
ALTO servers that can provide suitable guidance.</t> ALTO servers that can provide suitable guidance.</t>
<t>In some deployment scenarios, in particular if the information
<t>In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several
about the network topology is partitioned and distributed over ALTO servers, it may be necessary to discover an ALTO server outside
several ALTO servers, it may be needed to discover an of the ALTO client's own network domain, in order to get appropriate
ALTO server outside of the own network domain, in order to get guidance. This document details applicable scenarios, itemizes
appropriate guidance. requirements, and specifies a procedure for ALTO cross-domain server
This document details applicable scenarios, itemizes requirements, and discovery.</t>
specifies a procedure for ALTO cross-domain server discovery.</t> <t>Technically, the procedure specified in this document takes one
<t>Technically, the procedure specified in this document takes one
IP&nbsp;address or prefix and a U-NAPTR Service Parameter IP&nbsp;address or prefix and a U-NAPTR Service Parameter
(typically, "ALTO:https") (typically, "ALTO:https") as parameters. It performs DNS lookups (for
as parameters. It performs DNS lookups (for NAPTR resource records in the "in-addr.arpa." or "ip6.arpa." trees)
NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and returns one or more URIs of information resources related
and returns one or more URI(s) of information resources related
to that IP address or prefix.</t> to that IP address or prefix.</t>
</abstract> </abstract>
</front>
<note title="Terminology and Requirements Language"> <middle>
<t>This document makes use of the ALTO terminology defined in <section numbered="true" toc="default">
RFC 5693 <xref target="RFC5693"/>.</t> <name>Introduction</name>
<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">
<t>
The goal of Application-Layer Traffic Optimization (ALTO) is to The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications that have to select one or several provide guidance to applications that have to select one or several
hosts from a set of candidates capable of providing a desired hosts from a set of candidates capable of providing a desired
resource <xref target="RFC5693"/>. ALTO is realized by an resource <xref target="RFC5693" format="default"/>. ALTO is realized
HTTP-based client-server protocol <xref target="RFC7285"/>, by an
HTTP-based client-server protocol <xref target="RFC7285" format="def
ault"/>,
which can be used in various scenarios which can be used in various scenarios
<xref target="RFC7971"/>. <xref target="RFC7971" format="default"/>.
</t> </t>
<t>
<t> The ALTO base protocol document <xref target="RFC7285" format="defau
The ALTO base protocol document <xref target="RFC7285"/> specifies lt"/> specifies
the communication between an ALTO client and one ALTO server. the communication between an ALTO client and one ALTO server.
In principle, the client may send any ALTO query. In principle, the client may send any ALTO query.
For example, it might ask for the routing cost between any two IP For example, it might ask for the routing cost between any two IP
addresses, or it might request network and addresses, or it might request network and
cost maps for the whole network, which might be the worldwide cost maps for the whole network, which might be the worldwide
Internet. It is assumed that the server can answer any query, Internet. It is assumed that the server can answer any query,
possibly with some kind of default value if no exact data is possibly with some kind of default value if no exact data is
known. known.
</t> </t>
<t>
<t>
No special provisions were made for deployment scenarios with No special provisions were made for deployment scenarios with
multiple ALTO servers, with some servers having more accurate multiple ALTO servers, with some servers having more accurate
information about some parts of the network topology while others information about some parts of the network topology while others
having better information about other parts of the network have better information about other parts of the network
("partitioned knowledge"). Various ALTO use cases have been ("partitioned knowledge"). Various ALTO use cases have been
studied in the context of such scenarios. In some cases, one studied in the context of such scenarios. In some cases, one
cannot assume that a topologically nearby ALTO server (e.g., a cannot assume that a topologically nearby ALTO server (e.g., a
server discovered with the procedure specified in server discovered with the procedure specified in
<xref target="RFC7286"/>) will always provide useful information <xref target="RFC7286" format="default"/>) will always provide usefu l information
to the client. One such scenario is detailed in to the client. One such scenario is detailed in
<xref target="apx.alto_p2p"/>. Several solution <xref target="apx.alto_p2p" format="default"/>. Several solution
approaches, such as redirecting a client to a server that has more approaches, such as redirecting a client to a server that has more
accurate information or forwarding the request to it on behalf accurate information or forwarding the request to such a server on b ehalf
of the client, have been proposed and analyzed (see of the client, have been proposed and analyzed (see
<xref target="sec.multiplesources"/>), but none has been specified <xref target="sec.multiplesources" format="default"/>), but no
so far. solution has been specified so far.
</t> </t>
<t>
<t> <xref target="sec.3pdisc-spec" format="default"/> of this document s
<xref target="sec.3pdisc-spec"/> of this document specifies pecifies
the "ALTO Cross-Domain Server Discovery Procedure" the "ALTO Cross-Domain Server Discovery Procedure"
for client-side usage in these scenarios. for client-side usage in these scenarios.
An ALTO client that wants to send an ALTO query related to a An ALTO client that wants to send an ALTO query related to a
specific IP address or prefix X, may call this procedure specific IP address or prefix X may call this procedure
with X as a paramenter. with X as a parameter.
It will use Domain Name System (DNS) lookups to find of one ore It will use Domain Name System (DNS) lookups to find one or
more ALTO servers that can provide a competent answer. more ALTO servers that can provide a competent answer.
The above wording "related to" was intentionally kept somewhat The above wording "related to" was intentionally kept somewhat
unspecific, as the exact semantics depends on the ALTO service to unspecific, as the exact semantics depends on the ALTO service to
be used; see <xref target="sec.xdom-usage"/>. be used; see <xref target="sec.xdom-usage" format="default"/>.
</t> </t>
<t>
<t>
Those who are in control of the "reverse DNS" Those who are in control of the "reverse DNS"
for a given IP address or prefix for a given IP address or prefix
(i.e., the corresponding subdomain of in-addr.arpa. or ip6.arpa.) (i.e., the corresponding subdomain of "in-addr.arpa." or "ip6.arpa."
- typically an Internet Service Provider (ISP), a )
corporate IT department, or a university's computing center - -- 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 may add resource records to the DNS that point to one or more
relevant ALTO server(s). In many cases, it may be relevant ALTO servers. In many cases, it may be
an ALTO server run by that ISP or IT department, as they an ALTO server run by that ISP or IT department, as they
naturally have good insight into routing costs from and naturally have good insight into routing costs from and
to their networks. However, they may also refer to an to their networks. However, they may also refer to an
ALTO server provided by someone else, e.g., their upstream ISP. 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> </t>
</section> </section>
</section>
<section anchor="sec.3pdisc-overview" <section anchor="sec.3pdisc-overview" numbered="true" toc="default">
title="ALTO Cross-Domain Server Discovery Procedure: Overview"> <name>ALTO Cross-Domain Server Discovery Procedure: Overview</name>
<t>This section gives a non-normative overview of the
<t>This section gives a non-normative overview on the
ALTO Cross-Domain Server Discovery Procedure. The detailed ALTO Cross-Domain Server Discovery Procedure. The detailed
specification will follow in the next section.</t> specification will follow in the next section.</t>
<t>This procedure was inspired by "Location Information
<t>This procedure was inspired by the "Location Information
Server (LIS) Discovery Using IP Addresses and Reverse DNS" Server (LIS) Discovery Using IP Addresses and Reverse DNS"
<xref target="RFC7216"/> and re-uses parts of the basic <xref target="RFC7216" format="default"/> and reuses parts of the basic
ALTO Server Discovery Procedure <xref target="RFC7286"/>.</t> ALTO Server Discovery Procedure <xref target="RFC7286" format="default"/
>.</t>
<t>The basic idea is to use the Domain Name System (DNS), <t>The basic idea is to use the Domain Name System (DNS),
more specifically the "in-addr.arpa." or "ip6.arpa." trees, more specifically the "in-addr.arpa." or "ip6.arpa." trees,
which are mostly used for "reverse mapping" of IP addresses which are mostly used for "reverse mapping" of IP addresses
to host names by means of PTR resource records. to host names by means of PTR resource records.
There, URI-enabled Naming Authority Pointer (U-NAPTR) There, URI-enabled Naming Authority Pointer (U-NAPTR)
resource records <xref target="RFC4848"/>, resource records <xref target="RFC4848" format="default"/>,
which allow the mapping of domain names to which allow the mapping of domain names to
Uniform Resource Identifiers (URIs), are installed Uniform Resource Identifiers (URIs), are installed
as needed. Thereby, it is possible to store a mapping from 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. an IP address or prefix to one or more ALTO server URIs in the DNS.
</t> </t>
<t>The ALTO Cross-Domain Server Discovery Procedure is called
<t>The ALTO Cross-Domain Server Discovery Procedure is called
with one IP&nbsp;address or prefix and a U-NAPTR Service with one IP&nbsp;address or prefix and a U-NAPTR Service
Parameter <xref target="RFC4848"/> as parameters. </t> Parameter <xref target="RFC4848" format="default"/> as parameters. </t>
<t>The service parameter is usually set to "ALTO:https".
<t>The service parameter is usually set to "ALTO:https". However, other parameter values may be used in some scenarios -- e.g.,
However, other parameter values may be used in some scenarios, e.g.,
"ALTO:http" to search for a server that supports unencrypted "ALTO:http" to search for a server that supports unencrypted
transmission for debugging purposes, or other application protocol transmission for debugging purposes, or other application protocol
or service tags if applicable.</t> or service tags if applicable.</t>
<t>The procedure performs DNS lookups and returns one or more
<t>The procedure performs DNS lookups and returns one or more URIs of information resources related to said IP address or
URI(s) of information resources related to said IP address or prefix, usually the URIs of one or more ALTO Information
prefix, usually the URI(s) of one or more ALTO Information Resource Directories (IRDs; see <xref target="RFC7285"
Resource Directory (IRD, see Section 9 of <xref target="RFC7285"/>). sectionFormat="of" section="9"/>).
The U-NAPTR records also provide preference values, which should The U-NAPTR records also provide preference values, which should
be considered if more than one URI is returned. be considered if more than one URI is returned.
</t> </t>
<t>The discovery procedure sequentially tries two different lookup
<t>The discovery procedure sequentially tries two different lookup strategies. First, an ALTO-specific U-NAPTR record is searched in the "r
strategies: everse
First, an ALTO-specific U-NAPTR record is searched in the "reverse tree" -- i.e., in subdomains of "in-addr.arpa." or "ip6.arpa." correspon
tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa. corresponding ding
to the given IP address or prefix. to the given IP address or prefix.
If this lookup does not yield a usable result, the procedure If this lookup does not yield a usable result, the procedure
tries further lookups with truncated domain names, which correspond tries further lookups with truncated domain names, which correspond
to shorter prefix lengths. The goal is to allow deployment to shorter prefix lengths. The goal is to allow deployment
scenarios that require fine-grained discovery on a per-IP basis, as 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 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 large number of IP addresses with a small number of additional DNS
resource records.</t> resource records.</t>
</section> </section>
<section anchor="sec.3pdisc-spec" numbered="true" toc="default">
<section anchor="sec.3pdisc-spec" title="ALTO Cross-Domain Server <name>ALTO Cross-Domain Server Discovery Procedure: Specificat
Discovery Procedure: Specification"> ion</name>
<section anchor="sec.3pdisc-spec-interface" numbered="true" toc="default">
<section anchor="sec.3pdisc-spec-interface" title="Interface"> <name>Interface</name>
<t>The procedure specified in this document takes two
<t>The procedure specified in this document takes two
parameters, X and SP, where X is an IP&nbsp;address or prefix parameters, X and SP, where X is an IP&nbsp;address or prefix
and SP is a U-NAPTR Service Parameter.</t> and SP is a U-NAPTR Service Parameter.</t>
<t>The parameter X may be an IPv4 or an IPv6 address
<t>The parameter X may be an IPv4 or an IPv6 address or prefix in Classless Inter-Domain Routing (CIDR) notation (see
or prefix in CIDR notation (see <xref target="RFC4632"/> <xref target="RFC4632" format="default"/>
for the IPv4 CIDR notation and <xref target="RFC4291"/> for IPv6). for the IPv4 CIDR notation and <xref target="RFC4291"
format="default"/> for IPv6).
Consequently, the address type AT is either "IPv4" or "IPv6". Consequently, the address type AT is either "IPv4" or "IPv6".
In both cases, X consists of an IP address A and a In both cases, X consists of an IP address A and a
prefix length L. prefix length L.
From the definition of IPv4 and IPv6 it follows that From the definitions of IPv4 and IPv6, it follows that
syntactically valid values for L are 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;32 when AT=IPv4 and
0&nbsp;&lt;=&nbsp;L&nbsp;&lt;=&nbsp;128 when AT=IPv6. 0&nbsp;&lt;=&nbsp;L&nbsp;&lt;=&nbsp;128 when AT=IPv6.
However, not all syntactically valid values of L are actually However, not all syntactically valid values of L are actually
supported by this procedure - Step 1 (see below) will supported by this procedure; Step 1 (see below) will
check for unsupported values and report an error if 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,
<t>For example, for X=198.51.100.0/24, we get AT=IPv4, A=198.51.100.0, and L=24. Similarly, for X=2001:0DB8::20/128,
A=198.51.100.0 and L=24. Similarly, for X=2001:0DB8::20/128, we get AT=IPv6, A=2001:0DB8::20, and L=128.</t>
we get AT=IPv6, A=2001:0DB8::20 and L=128.</t> <t>In the intended usage scenario, the procedure is normally
<t>In the intended usage scenario, the procedure is normally
always called with the parameter SP set to "ALTO:https". always called with the parameter SP set to "ALTO:https".
However, for general applicabiliy and in order to support However, for general applicability and in order to support
future extensions, the procedure MUST support being called future extensions, the procedure <bcp14>MUST</bcp14> support being c
alled
with any valid U-NAPTR Service Parameter with any valid U-NAPTR Service Parameter
(see Section 4.5. of <xref target="RFC4848"/> for the (see <xref target="RFC4848" sectionFormat="of" section="4.5"/> for t
syntax of U-NAPTR Service Parameters and Section 5. of the he
syntax of U-NAPTR Service Parameters and Section <xref target="RFC48
48"
sectionFormat="bare" section="5"/> of the
same document for information about the IANA registries).</t> same document for information about the IANA registries).</t>
<t>The procedure performs DNS lookups and returns one or more
<t>The procedure performs DNS lookups and returns one or more URIs of information resources related to that IP address or
URI(s) of information resources related to that IP address or prefix, usually the URIs of one or more ALTO Information
prefix, usually the URI(s) of one or more ALTO Information Resource Directories (IRDs; see <xref target="RFC7285"
Resource Directory (IRD, see Section 9 of <xref target="RFC7285"/>). sectionFormat="of" section="9"/>).
For each URI, it also returns order and preference values For each URI, the procedure also returns order and preference values
(see Section 4.1 of <xref target="RFC3403"/>), which (see <xref target="RFC3403" sectionFormat="of" section="4.1"/>),
which
should be considered if more than one URI is returned.</t> should be considered if more than one URI is returned.</t>
<t>During execution of this procedure, various
<t>During execution of this procedure, various
error conditions may occur and have to be reported to error conditions may occur and have to be reported to
the caller; see the caller; see
<xref target="sec.3pdisc-spec-errorhandling"/>.</t> <xref target="sec.3pdisc-spec-errorhandling" format="default"/>.</t>
<t>For the remainder of the document, we use the following
<t>For the remainder of the document, we use the following
notation for calling the ALTO Cross-Domain Server Discovery notation for calling the ALTO Cross-Domain Server Discovery
Procedure: Procedure:
<vspace blankLines="1"/>
&nbsp;&nbsp;&nbsp;IRD_URIS_X&nbsp;=&nbsp;XDOMDISC(X,"ALTO:https")
</t>
</section>
<section anchor="sec.3pdisc-spec-step1" &nbsp;&nbsp;&nbsp;IRD_URIS_X&nbsp;=&nbsp;XDOMDISC(X,"ALTO:https")
title="Step 1: Prepare Domain Name for Reverse DNS Lookup"> </t>
</section>
<t>First, the procedure checks the prefix length L for unsupported <section anchor="sec.3pdisc-spec-step1" numbered="true" toc="default">
<name>Step 1: Prepare Domain Name for Reverse DNS 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, 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" the procedure aborts and indicates an "unsupported prefix length"
error to the caller. Similarly, if AT=IPv6 error to the caller. Similarly, if AT=IPv6
and L &lt; 32, the procedure aborts and indicates an and L &lt; 32, the procedure aborts and indicates an
"unsupported prefix length" error to the caller. Otherwise, "unsupported prefix length" error to the caller. Otherwise,
the procedure continues.</t> the procedure continues.</t>
<t>If AT=IPv4, the procedure will then produce a
<t>If AT=IPv4, the procedure will then produce a
DNS domain name, DNS domain name,
which will be referred to as R32. This domain name is which will be referred to as R32. This domain name is
constructed according to the rules specified in constructed according to the rules specified in
Section 3.5 of <xref target="RFC1035"/> and it is rooted in <xref target="RFC1035" format="default" sectionFormat="of"
section="3.5"/>, and it is rooted in
the special domain "IN-ADDR.ARPA.".</t> the special domain "IN-ADDR.ARPA.".</t>
<t>For example, A=198.51.100.3 yields
<t>For example, A=198.51.100.3 yields
R32="3.100.51.198.IN-ADDR.ARPA.". </t> R32="3.100.51.198.IN-ADDR.ARPA.". </t>
<t>If AT=IPv6, a domain name, which will be called R128,
<t>If AT=IPv6, a domain name. which will be called R128,
is constructed according to the rules specified in is constructed according to the rules specified in
Section 2.5 of <xref target="RFC3596"/> and the <xref target="RFC3596" format="default"
sectionFormat="of" section="2.5"/>, and the
special domain "IP6.ARPA." is used. special domain "IP6.ARPA." is used.
<figure> </t>
<artwork><![CDATA[
<t>
For example (note: a line break was added after the second line), For example (note: a line break was added after the second line),
</t>
<sourcecode type="pseudocode">
A = 2001:0DB8::20 yields A = 2001:0DB8::20 yields
R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0. R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
1.0.0.2.IP6.ARPA." 1.0.0.2.IP6.ARPA."
]]></artwork></figure> </sourcecode>
</t>
<t>
<!-- force a page break as steps 2 and 3 each fit nicely on one page -->
<vspace blankLines="60"/>
</t>
</section>
<section anchor="sec.3pdisc-spec-step2"
title="Step 2: Prepare Shortened Domain Names">
<t>For this step, an auxiliary function "skip" is defined as </section>
<section anchor="sec.3pdisc-spec-step2" numbered="true" toc="default">
<name>Step 2: Prepare Shortened Domain Names</name>
<t>For this step, an auxiliary function, "skip", is defined as
follows: follows:
skip(str,n) will skip all characters in the string str, up to skip(str,n) will skip all characters in the string str, up to
and including the n-th dot, and return the remaining and including the n-th dot, and return the remaining
part of str. For example, skip("foo.bar.baz.qux.quux.",2) will part of str. For example, skip("foo.bar.baz.qux.quux.",2) will
return "baz.qux.quux.". return "baz.qux.quux.".
</t> </t>
<t>If AT=IPv4, the following additional
<t>If AT=IPv4, the following additional
domain names are generated from the result of the previous step: domain names are generated from the result of the previous step:
<list style="empty"> </t>
<t>R24=skip(R32,1),</t> <ul empty="true" spacing="normal">
<t>R16=skip(R32,2), and</t> <li>R24=skip(R32,1),</li>
<t>R8=skip(R32,3).</t> <li>R16=skip(R32,2), and</li>
</list> <li>R8=skip(R32,3).</li>
</ul>
<t>
Removing one label from a domain name (i.e., one number of the Removing one label from a domain name (i.e., one number of the
"dotted quad notation") corresponds to shortening the prefix length "dotted quad notation") corresponds to shortening the prefix length
by 8 bits.</t> by 8 bits.</t>
<t>For example, R32="3.100.51.198.IN-ADDR.ARPA." yields <t>For example,</t>
R24="100.51.198.IN-ADDR.ARPA.", <sourcecode type="pseudocode">
R16="51.198.IN-ADDR.ARPA.", and R32="3.100.51.198.IN-ADDR.ARPA." yields
R8="198.IN-ADDR.ARPA.". </t> R24="100.51.198.IN-ADDR.ARPA."
R16="51.198.IN-ADDR.ARPA."
<t>If AT=IPv6, the following additional R8="198.IN-ADDR.ARPA."
</sourcecode>
<t>If AT=IPv6, the following additional
domain names are generated from the result of the previous step: domain names are generated from the result of the previous step:
<list style="empty"> </t>
<t>R64=skip(R128,16),</t> <ul empty="true" spacing="normal">
<t>R56=skip(R128,18),</t> <li>R64=skip(R128,16),</li>
<t>R48=skip(R128,20),</t> <li>R56=skip(R128,18),</li>
<t>R40=skip(R128,22), and</t> <li>R48=skip(R128,20),</li>
<t>R32=skip(R128,24).</t> <li>R40=skip(R128,22), and</li>
</list> <li>R32=skip(R128,24).</li>
</ul>
<t>
Removing one label from a domain name (i.e., one hex digit) Removing one label from a domain name (i.e., one hex digit)
corresponds to shortening the prefix length by 4 bits. corresponds to shortening the prefix length by 4 bits.
<figure> </t>
<artwork><![CDATA[ <t>
For example (note: a line break was added after the first line), 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. R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
1.0.0.2.IP6.ARPA." yields 1.0.0.2.IP6.ARPA." yields
R64 = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R64 = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R56 = "0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R56 = "0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R48 = "0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R48 = "0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.". R32 = "8.B.D.0.1.0.0.2.IP6.ARPA."
]]></artwork></figure> </sourcecode>
</t> </section>
</section> <section anchor="sec.3pdisc-spec-step3" numbered="true" toc="default">
<name>Step 3: Perform DNS U-NAPTR Lookups</name>
<section anchor="sec.3pdisc-spec-step3" <t>The address type and the prefix length of X
title="Step 3: Perform DNS U-NAPTR lookups">
<t>The address type and the prefix length of X
are matched against the first and the second column of the are matched against the first and the second column of the
following table, respectively:</t> following table, respectively:</t>
<figure><artwork><![CDATA[
+------------+------------+------------+----------------------------+
| 1: Address | 2: Prefix | 3: MUST do | 4: SHOULD do further |
| Type AT | Length L | 1st lookup | lookups in that order |
+------------+------------+------------+----------------------------+
| IPv4 | 32 | R32 | R24, R16, R8 |
| IPv4 | 24 .. 31 | R24 | R16, R8 |
| IPv4 | 16 .. 23 | R16 | R8 |
| IPv4 | 8 .. 15 | R8 | (none) |
| IPv4 | 0 .. 7 | (none, abort: unsupported prefix length)|
+------------+------------+------------+----------------------------+
| IPv6 | 128 | R128 | R64, R56, R48, R40, R32 |
| IPv6 | 64 (..127) | R64 | R56, R48, R40, R32 |
| IPv6 | 56 .. 63 | R56 | R48, R40, R32 |
| IPv6 | 48 .. 55 | R48 | R40, R32 |
| IPv6 | 40 .. 47 | R40 | R32 |
| IPv6 | 32 .. 39 | R32 | (none) |
| IPv6 | 0 .. 31 | (none, abort: unsupported prefix length)|
+------------+------------+------------+----------------------------+
]]></artwork></figure>
<t>Then, the domain name given in the 3rd column and the <table anchor="U-NAPTR">
U-NAPTR Service Parameter SP the procedure was called with <name>Perform DNS U-NAPTR lookups</name>
(usually "ALTO:https") MUST be used for an <thead>
U-NAPTR <xref target="RFC4848"/> lookup, in order <tr>
<th>1: Address Type AT</th>
<th>2: Prefix Length L</th>
<th>3: MUST do 1st lookup</th>
<th>4: SHOULD do further lookups in that order</th>
</tr>
</thead>
<tbody>
<tr>
<td>IPv4</td>
<td>32</td>
<td>R32</td>
<td>R24, R16, R8</td>
</tr>
<tr>
<td>IPv4</td>
<td>24 .. 31</td>
<td>R24</td>
<td>R16, R8</td>
</tr>
<tr>
<td>IPv4</td>
<td>16 .. 23</td>
<td>R16</td>
<td>R8</td>
</tr>
<tr>
<td>IPv4</td>
<td>8 .. 15</td>
<td>R8</td>
<td>(none)</td>
</tr>
<tr>
<td>IPv4</td>
<td>0 .. 7</td>
<td colspan="2">(none, abort: unsupported prefix length)</td>
</tr>
<tr>
<td>IPv6</td>
<td>128</td>
<td>R128</td>
<td>R64, R56, R48, R40, R32</td>
</tr>
<tr>
<td>IPv6</td>
<td>64 (..127)</td>
<td>R64</td>
<td>R56, R48, R40, R32</td>
</tr>
<tr>
<td>IPv6</td>
<td>56 .. 63</td>
<td>R56</td>
<td>R48, R40, R32</td>
</tr>
<tr>
<td>IPv6</td>
<td>48 .. 55</td>
<td>R48</td>
<td>R40, R32</td>
</tr>
<tr>
<td>IPv6</td>
<td>40 .. 47</td>
<td>R40</td>
<td>R32</td>
</tr>
<tr>
<td>IPv6</td>
<td>32 .. 39</td>
<td>R32</td>
<td>(none)</td>
</tr>
<tr>
<td>IPv6</td>
<td>0 .. 31</td>
<td colspan="2">(none, abort: unsupported prefix 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
(usually "ALTO:https") <bcp14>MUST</bcp14> be used for a
U-NAPTR <xref target="RFC4848" format="default"/> lookup, in order
to obtain one or more URIs (indicating protocol, host, and to obtain one or more URIs (indicating protocol, host, and
possibly path elements) for the ALTO server's Information Resource possibly path elements) for the ALTO server's Information Resource
Directory (IRD). If such URI(s) can be found, the Directory (IRD). If such URIs can be found, the
ALTO Cross-Domain Server Discovery Procedure returns that ALTO Cross-Domain Server Discovery Procedure returns that
information to the caller and terminates successfully.</t> information to the caller and terminates successfully.</t>
<t>For example, the following two U-NAPTR resource records can be
<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 used for mapping "100.51.198.IN-ADDR.ARPA." (i.e., R24 from the
example in the previous step) to the HTTPS URIs example in the previous step) to the HTTPS URIs
"https://alto1.example.net/ird" and "https://alto1.example.net/ird" and
"https://alto2.example.net/ird", with the former being preferred. "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" 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://alto1.example.net/ird!" "" "!.*!https://alto1.example.net/ird!" ""
100.51.198.IN-ADDR.ARPA. IN NAPTR 100 20 "u" "ALTO:https" 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 20 "u" "ALTO:https"
"!.*!https://alto2.example.net/ird!" "" "!.*!https://alto2.example.net/ird!" ""
]]></artwork></figure></t> </sourcecode>
<t>If no matching U-NAPTR records can be found, <t>If no matching U-NAPTR records can be found,
the procedure SHOULD try further lookups, using the domain the procedure <bcp14>SHOULD</bcp14> try further lookups, using the d
omain
names from the fourth column in the indicated order, until one names from the fourth column in the indicated order, until one
lookup lookup
succeeds. If no IRD URI could be found after looking up succeeds. If no IRD URI can be found after looking up
all domain names from the 3rd and 4th column, the procedure all domain names from the 3rd and 4th columns, the procedure
terminates unsuccessfully, returning an empty URI list. terminates unsuccessfully, returning an empty URI list.
</t> </t>
</section>
</section> <section anchor="sec.3pdisc-spec-errorhandling" numbered="true" toc="defau
<section anchor="sec.3pdisc-spec-errorhandling" lt">
title="Error Handling"> <name>Error Handling</name>
<t>The ALTO Cross-Domain Server Discovery Procedure may fail
<t>The ALTO Cross-Domain Server Discovery Procedure may fail
for several reasons.</t> for several reasons.</t>
<t>If the procedure is called with syntactically invalid
<t>If the procedure is called with syntactically invalid parameters or unsupported parameter values (in particular, the
parameters or unsupported parameter values (in particular the prefix length L; see <xref target="sec.3pdisc-spec-step1" format="de
prefix length L, see <xref target="sec.3pdisc-spec-step1"/>), fault"/>),
the procedure aborts, no URI list will be returned and the procedure aborts, no URI list will be returned, and
the error has to be reported to the caller.</t> the error has to be reported to the caller.</t>
<t>The procedure performs one or more DNS lookups in a
<t>The procedure performs one or more DNS lookups in a
well-defined order (corresponding to descending prefix lengths, well-defined order (corresponding to descending prefix lengths,
see <xref target="sec.3pdisc-spec-step3"/>), until one produces see <xref target="sec.3pdisc-spec-step3" format="default"/>) until o ne produces
a usable result. Each of these DNS a usable result. Each of these DNS
lookups might not produce a usable result, either due to a lookups might fail to produce a usable result, due to either a
normal condition (e.g., domain name exists, but no ALTO-specific normal condition (e.g., a domain name exists, but no ALTO-specific
NAPTR resource records are associated with it), a permanent error NAPTR resource records are associated with it), a permanent error
(e.g., non-existent domain name), or due to a temporary error (e.g., nonexistent domain name), or a temporary error
(e.g., timeout). In all three (e.g., timeout). In all three
cases, and as long as there are further domain names that can be cases, and as long as there are further domain names that can be
looked up, the procedure SHOULD immediately try to lookup the looked up, the procedure <bcp14>SHOULD</bcp14> immediately try to
next domain name (from column 4 in the table given in look up the
<xref target="sec.3pdisc-spec-step3"/>). next domain name (from Column 4 in the table given in
<xref target="sec.3pdisc-spec-step3" format="default"/>).
Only after all domain names have been tried at least once, the Only after all domain names have been tried at least once, the
procedure MAY retry those domain names that had caused temporary procedure <bcp14>MAY</bcp14> retry those domain names that had cause d temporary
lookup errors.</t> lookup errors.</t>
<t>Generally speaking, ALTO provides advisory
<t>Generally speaking, ALTO provides advisory information for the optimization of applications (peer-to-peer
information for the optimization of applications (e.g., applications, overlay networks, etc.), but
peer-to-peer applications, overlay networks, etc.), but
applications should not rely on the availability of such applications should not rely on the availability of such
information for their basic functionality (see information for their basic functionality (see
<xref target="RFC7285">Section 8.3.4.3 of RFC 7285</xref>). <xref target="RFC7285" sectionFormat="of" section="8.3.4.3" />).
Consequently, the speedy detection of an ALTO server, even Consequently, the speedy detection of an ALTO server, even
though it may give less accurate answers than other servers, or though it may give less accurate answers than other servers, or
the quick realization that there is no suitable ALTO server, is the quick realization that there is no suitable ALTO server, is
in general more preferable than causing long delays by retrying in general preferable to causing long delays by retrying
failed queries. Nevertheless, the ALTO Cross-Domain Server failed queries.
Discovery Procedure SHOULD inform its caller, if DNS queries
have failed due to temporary errors and that retrying the
discovery at a later point in time might give more accurate
results.
</t>
</section>
</section>
<section anchor="sec.xdom-usage" Nevertheless, if DNS queries have failed due to temporary errors, the
title="Using the ALTO Protocol with Cross-Domain Server Discovery"> ALTO Cross-Domain Server Discovery Procedure SHOULD inform its caller
that DNS queries have failed for that reason and that retrying the
discovery at a later point in time might give more accurate results.
<t>Based on a modular design principle, ALTO provides several ALTO </t>
services, each consisting of a set of information resouces </section>
</section>
<section anchor="sec.xdom-usage" numbered="true" toc="default">
<name>Using the ALTO Protocol with Cross-Domain Server Discovery</name>
<t>Based on a modular design principle, ALTO provides several ALTO
services, each consisting of a set of information resources
that can be accessed using the ALTO protocol. that can be accessed using the ALTO protocol.
The information resources that are available at a specific The information resources that are available at a specific
ALTO server are listed in its Information Resource Directory ALTO server are listed in its Information Resource Directory
(IRD, see Section 9 of <xref target="RFC7285"/>). (IRD, see <xref target="RFC7285" sectionFormat="of" section="9"/>).
The ALTO protocol specification defines the following ALTO The ALTO protocol specification defines the following ALTO
services and their corresponding information resouces: services and their corresponding information resources:
<list style="symbols"> </t>
<t>Network and Cost Map Service, <ul spacing="normal">
see Section 11.2 of <xref target="RFC7285"/> <li>Network and Cost Map Service, see <xref
</t> target="RFC7285" sectionFormat="of" section="11.2"/>
<t>Map-Filtering Service, </li>
see Section 11.3 of <xref target="RFC7285"/> <li>Map-Filtering Service, see <xref target="RFC7285"
</t> sectionFormat="of" section="11.3"/>
<t>Endpoint Property Service, </li>
see Section 11.4 of <xref target="RFC7285"/> <li>Endpoint Property Service,
</t> see <xref target="RFC7285"
<t>Endpoint Cost Service, sectionFormat="of" section="11.4"/>
see Section 11.5 of <xref target="RFC7285"/> </li>
</t> <li>Endpoint Cost Service,
</list> see <xref target="RFC7285"
sectionFormat="of" section="11.5"/>
</li>
</ul>
<t>
The ALTO Cross-Domain Server Discovery Procedure is The ALTO Cross-Domain Server Discovery Procedure is
most useful in conjunction with the Endpoint Property Service and most useful in conjunction with the Endpoint Property Service and
the Endpoint Cost Service. However, for the sake of completeness, the Endpoint Cost Service. However, for the sake of completeness,
possible interaction with all four services is discussed below. possible interaction with all four services is discussed below.
Extension documents may specify further information resources; Extension documents may specify further information resources;
however, these are out of scope of this document. however, these are out of scope of this document.
</t> </t>
<section anchor="sec.mapservice" numbered="true" toc="default">
<section anchor="sec.mapservice" title="Network and Cost Map Service"> <name>Network and Cost Map Service</name>
<t> An ALTO client may invoke the ALTO Cross-Domain Server
<t> An ALTO client may invoke the ALTO Cross-Domain Server
Discovery Procedure (as specified in Discovery Procedure (as specified in
<xref target="sec.3pdisc-spec"/>) for an IP address <xref target="sec.3pdisc-spec" format="default"/>) for an IP add
or prefix "X" ress
and get a list of one or more IRD URI(s), including or prefix X
and get a list of one or more IRD URIs, including
order and preference values: order and preference values:
IRD_URIS_X&nbsp;=&nbsp;XDOMDISC(X,"ALTO:https"). The IRD(s) IRD_URIS_X&nbsp;=&nbsp;XDOMDISC(X,"ALTO:https"). The IRD(s)
referenced by these URI(s) referenced by these URIs
will always contain a network and a cost map, as these will always contain a network and a cost map, as these
are mandatory information resources (see Section 11.2 are mandatory information resources (see <xref
of <xref target="RFC7285"/>). However, the cost matrix target="RFC7285" sectionFormat="of" section="11.2"/>).
However, the cost matrix
may be very sparse. If, according to the network map, may be very sparse. If, according to the network map,
PID_X is the PID that contains the IP address or prefix X, and PID_X is the Provider-defined Identifier (PID; see <xref
PID_1, PID_2, PID_3, ... are other PIDS, the cost map target="RFC7285" sectionFormat="of" section="5.1"/>) that contain
s the IP address or prefix X, and
PID_1, PID_2, PID_3, ... are other PIDs, the cost map
may look like this: may look like this:
<figure> </t>
<artwork><![CDATA[
From \ To PID_1 PID_2 PID_X PID_3 <table anchor="PID">
PID_1 | 92 <name>Cost Map</name>
PID_2 | 6 <thead>
PID_X | 46 3 1 19 <tr>
PID_3 | 38 <th>From</th>
]]></artwork> <th>To PID_1</th>
</figure> <th>PID_2</th>
In this example, all cells outside column "X" and row "X" are <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 and Row X are
unspecified. A cost map with this structure contains the same unspecified. A cost map with this structure contains the same
information as what could be retrieved using the Endpoint Cost information as what could be retrieved using the Endpoint Cost
Service, cases 1 and 2 in <xref target="sec.ecs"/>. Service, Cases 1 and 2 in <xref target="sec.ecs" format="default"/>.
Accessing cells that are neither in column "X" nor row "X" Accessing cells that are neither in Column X nor Row X
may not yield useful results. may not yield useful results.
</t> </t>
<t>Trying to assemble a more densely populated cost map from several
<t>Trying to assemble a more densely populated cost map from several cost maps with this very sparse structure may be a nontrivial
cost maps with this very sparse structure may be a non-trivial
task, as different ALTO servers may use different PID definitions task, as different ALTO servers may use different PID definitions
(i.e., network maps) and incompatible scales for the costs, (i.e., network maps) and incompatible scales for the costs,
in particular for the "routingcost" metric. in particular for the "routingcost" metric.
</t> </t>
</section>
</section> <section anchor="sec.mfs" numbered="true" toc="default">
<name>Map-Filtering Service</name>
<section anchor="sec.mfs"title="Map-Filtering Service"> <t> An ALTO client may invoke the ALTO Cross-Domain Server
<t> An ALTO client may invoke the ALTO Cross-Domain Server
Discovery Procedure (as specified in Discovery Procedure (as specified in
<xref target="sec.3pdisc-spec"/>) for an IP address <xref target="sec.3pdisc-spec" format="default"/>) for an IP add
or prefix "X" ress
and get a list of one or more IRD URI(s), including or prefix X
and get a list of one or more IRD URIs, including
order and preference values: order and preference values:
IRD_URIS_X&nbsp;=&nbsp;XDOMDISC(X,"ALTO:https"). These IRD(s) IRD_URIS_X&nbsp;=&nbsp;XDOMDISC(X,"ALTO:https"). These IRDs
may provide the optional Map-Filtering Service may provide the optional Map-Filtering Service
(see Section 11.3 of <xref target="RFC7285"/>). (see <xref target="RFC7285" sectionFormat="of"
section="11.3"/>).
This service returns a subset of the full map, This service returns a subset of the full map,
as specified by the client. As discussed in as specified by the client. As discussed in
<xref target="sec.mapservice"/>, a cost map may <xref target="sec.mapservice" format="default"/>, a cost map may
be very sparse in the envisioned deployment scenario. be very sparse in the envisioned deployment scenario.
Therefore, depending on the filtering criteria provided Therefore, depending on the filtering criteria provided
by the client, this service may return results similar by the client, this service may return results similar
to the Endpoint Cost Service, or it may not return any to the Endpoint Cost Service, or it may not return any
useful result. useful result.
</t> </t>
</section> </section>
<section anchor="sec.eps" numbered="true" toc="default">
<section anchor="sec.eps" title="Endpoint Property Service"> <name>Endpoint Property Service</name>
<t> <t>
If an ALTO client wants to query an Endpoint Property Service If an ALTO client wants to query an Endpoint Property Service
(see <xref target="RFC7285">Section 11.4 of RFC 7285</xref>) (see <xref target="RFC7285" sectionFormat="of" section="11.4" />
about an endpoint with IP address "X" or a group of endpoints )
within IP prefix "X", respectively, it has to about an endpoint with IP address X or a group of endpoints
within IP prefix X, respectively, it has to
invoke the ALTO Cross-Domain Server Discovery Procedure invoke the ALTO Cross-Domain Server Discovery Procedure
(as specified in <xref target="sec.3pdisc-spec"/>): (as specified in <xref target="sec.3pdisc-spec" format="default" />):
IRD_URIS_X&nbsp;=&nbsp;XDOMDISC(X,"ALTO:https"). IRD_URIS_X&nbsp;=&nbsp;XDOMDISC(X,"ALTO:https").
The result IRD_URIS_X is a list of one or more URIs of The result, IRD_URIS_X, is a list of one or more URIs of
Information Resource Directories Information Resource Directories
(IRD, see Section 9 of <xref target="RFC7285"/>). (IRDs, see <xref target="RFC7285"
sectionFormat="of" section="9"/>).
Considering the order and preference values, the client has Considering the order and preference values, the client has
to check these IRDs for a suitable Endpoint Property Service to check these IRDs for a suitable Endpoint Property Service
and query it. and query it.
</t> </t>
<t> <t>
If the ALTO client wants to do a similar Endpoint Property If the ALTO client wants to do a similar Endpoint Property
query for a different IP address or prefix "Y", the whole query for a different IP address or prefix "Y", the whole
procedure has to be repeated, as IRD_URIS_Y = procedure has to be repeated, as IRD_URIS_Y =
XDOMDISC(Y,"ALTO:https") may yield a different list of IRD XDOMDISC(Y,"ALTO:https") may yield a different list of IRD
URIs. Of course, the results of individual DNS queries may URIs. Of course, the results of individual DNS queries may
be cached as indicated by their respective time-to-live be cached as indicated by their respective time-to-live
(TTL) values. (TTL) values.
</t> </t>
</section> </section>
<section anchor="sec.ecs" numbered="true" toc="default">
<section anchor="sec.ecs" title="Endpoint Cost Service"> <name>Endpoint Cost Service</name>
<t> <t>
The optional ALTO Endpoint Cost Service (ECS, The optional ALTO Endpoint Cost Service (ECS;
see <xref target="RFC7285">Section 11.5 of RFC 7285</xref>) see <xref target="RFC7285" sectionFormat="of" section="11.5" />)
provides information about costs between individual endpoints provides information about costs between individual endpoints
and it also supports ranking. and also supports ranking.
The ECS allows that endpoints may be denoted by IP The ECS allows endpoints to be denoted by IP
addresses or prefixes. addresses or prefixes.
The ECS is called with a list of The ECS is called with a list of
one or more source IP addresses or prefixes, which we will call one or more source IP addresses or prefixes, which we will call
(S1, S2, S3, ...), and a list of one or more destination (S1, S2, S3, ...), and a list of one or more destination
IP addresses or prefixes, called (D1, D2, D3, ...). IP addresses or prefixes, called (D1, D2, D3, ...).
</t> </t>
<t>This specification distinguishes several cases, regarding
<t>This specification distinguishes several cases, regarding
the number of elements in the list of source and destination the number of elements in the list of source and destination
addresses, respectively: addresses, respectively:
<list style="numbers"> </t>
<ol spacing="normal" type="1">
<t>Exactly one source address S1 and more than one <li>
destination addresses D1, D2, D3, ... In this case, <t>Exactly one source address S1 and more than one
destination addresses (D1, D2, D3, ...). In this case,
the ALTO client has to invoke the ALTO Cross-Domain the ALTO client has to invoke the ALTO Cross-Domain
Server Discovery Procedure (as specified in Server Discovery Procedure (as specified in
<xref target="sec.3pdisc-spec"/>) with that single <xref target="sec.3pdisc-spec" format="default"/>) with that single
source address as a parameter: source address as a parameter:
IRD_URIS_S1&nbsp;=&nbsp;XDOMDISC(S1,"ALTO:https"). IRD_URIS_S1&nbsp;=&nbsp;XDOMDISC(S1,"ALTO:https").
The result IRD_URIS_S1 is a list of one or more URIs of The result, IRD_URIS_S1, is a list of one or more URIs of
Information Resource Directories Information Resource Directories
(IRD, see Section 9 of <xref target="RFC7285"/>). (IRDs, see <xref target="RFC7285"
sectionFormat="of" section="9"/>).
Considering the order and preference values, the client has Considering the order and preference values, the client has
to check these IRDs for a suitable Endpoint Cost Service to check these IRDs for a suitable Endpoint Cost Service
and query it. The ECS is an optional service (see and query it. The ECS is an optional service (see
<xref target="RFC7285">Section 11.5.1 of RFC 7285</xref>) <xref target="RFC7285" sectionFormat="of" section="11.5.1"
and therefore, it may well be that an IRD does not />), and therefore, it may well be that an IRD does not
refer to an ECS. refer to an ECS.
<vspace blankLines="1"/> <!-- new paragraph within </t>
the same item of the numbered list --> <t>
Calling the Cross-Domain Server Discovery Procedure Calling the Cross-Domain Server Discovery Procedure
only once with the single source address as a parameter only once with the single source address as a parameter
- as opposed to multiple calls, e.g., one for each -- as opposed to multiple calls, e.g., one for each
destination address - is not only a matter of efficiency. destination address -- is not only a matter of efficiency.
In the given scenario, it is advisable to send all In the given scenario, it is advisable to send all
ECS queries to the same ALTO server. This ensures that ECS queries to the same ALTO server. This ensures that
the results can be compared (e.g., for sorting the results can be compared (e.g., for sorting
candidate resource providers), even with candidate resource providers), even when
cost metrics without a well-defined base unit, e.g., cost metrics lack a well-defined base unit -- e.g.,
the "routingcost" metric. the "routingcost" metric.
</t> </t>
</li>
<t>More than one source addresses S1, S2, S3, ... <li>More than one source address (S1, S2, S3, ...)
and exactly one destination address D1. In this case, and exactly one destination address D1. In this case,
the ALTO client has to invoke the ALTO Cross-Domain the ALTO client has to invoke the ALTO Cross-Domain
Server Discovery Procedure with that single Server Discovery Procedure with that single
destination address as a parameter: destination address as a parameter:
IRD_URIS_D1&nbsp;=&nbsp;XDOMDISC(D1,"ALTO:https"). IRD_URIS_D1&nbsp;=&nbsp;XDOMDISC(D1,"ALTO:https").
The result IRD_URIS_D1 is a list of one or more URIs of The result, IRD_URIS_D1, is a list of one or more URIs of
IRDs. IRDs.
Considering the order and preference values, the client has Considering the order and preference values, the client has
to check these IRDs for a suitable ECS and query it. to check these IRDs for a suitable ECS and query it.
</t> </li>
<li>Exactly one source address S1
<t>Exactly one source address S1
and exactly one destination address D1. and exactly one destination address D1.
The ALTO client may perform the same steps as in The ALTO client may perform the same steps as in
case&nbsp;1, as specified above. As an alternative, Case&nbsp;1, as specified above. As an alternative,
it may also perform the same steps as in it may also perform the same steps as in
case&nbsp;2, as specified above. Case&nbsp;2, as specified above.
</t> </li>
<li>More than one source address (S1, S2, S3, ...)
<t>More than one source addresses S1, S2, S3, ... and more than one destination address (D1, D2, D3, ...).
and more than one destination addresses D1, D2, D3, ...
In this case, the ALTO client should split the In this case, the ALTO client should split the
list of desired queries based on source addresses and perfor m separately list of desired queries based on source addresses and perfor m separately
for each source address the same steps as in case&nbsp;1, for each source address the same steps as in Case&nbsp;1,
as specified above. As an alternative, the ALTO as specified above. As an alternative, the ALTO
client may also group the list based on destination client may also group the list based on destination
addresses and perform separately for each destination addresses and perform separately for each destination
address the same steps as in case&nbsp;2, as specified address the same steps as in Case&nbsp;2, as specified
above. However, comparing results between these above. However, comparing results between these
sub-queries may be difficult, in particular if subqueries may be difficult, in particular if
the cost metric is a relative preference without the cost metric is a relative preference without
a well-defined base unit (e.g., the "routingcost" a well-defined base unit (e.g., the "routingcost"
metric). metric).
</t> </li>
</ol>
</list> <t>
See <xref target="apx.alto_p2p"/> for a See <xref target="apx.alto_p2p" format="default"/> for a
detailed example showing the interaction of a detailed example showing the interaction of a
tracker-based peer-to-peer application, the ALTO tracker-based peer-to-peer application, the ALTO
Endpoint Cost Service, and the ALTO Cross-Domain Endpoint Cost Service, and the ALTO Cross-Domain
Server Discovery Procedure. Server Discovery Procedure.
</t> </t>
</section>
</section> <section anchor="sec.ext" numbered="true" toc="default">
<name>Summary and Further Extensions</name>
<section anchor="sec.ext" title="Summary and Further Extensions"> <t>Considering the four services defined in the ALTO base
protocol specification <xref target="RFC7285" format="default"/>, th
<t>Considering the four services defined in the ALTO base e
protocol specification <xref target="RFC7285"/>, the
ALTO Cross-Domain Server Discovery Procedure works ALTO Cross-Domain Server Discovery Procedure works
best with the Endpoint Property Service (EPS) and the best with the Endpoint Property Service (EPS) and the
Endpoint Cost Service (ECS). Both the EPS and the ECS Endpoint Cost Service (ECS). Both the EPS and the ECS
take one or more IP addresses as a parameter. The previous take one or more IP addresses as a parameter. The previous
sections specify how the parameter for calling the sections specify how the parameter for calling the
ALTO Cross-Domain Server Discovery Procedure has to be ALTO Cross-Domain Server Discovery Procedure has to be
derived from these IP adresses.</t> derived from these IP addresses.</t>
<t>In contrast, the ALTO Cross-Domain Server Discovery Procedure
<t>In contrast, the ALTO Cross-Domain Server Discovery Procedure
seems less useful if the goal is to retrieve network and cost seems less useful if the goal is to retrieve network and cost
maps that cover the whole network topology. However, the maps that cover the whole network topology. However, the
procedure may be useful if a map centered at a specific procedure may be useful if a map centered at a specific
IP address is desired (i.e., a map detailing the vicinity IP address is desired (i.e., a map detailing the vicinity
of said IP address or a map giving costs from said IP address of said IP address or a map giving costs from said IP address
to all potential destinations).</t> to all potential destinations).</t>
<t>The interaction between further ALTO services (and their
<t>The interaction between further ALTO services (and their
corresponding information resources) needs to be investigated corresponding information resources) needs to be investigated
and defined once such further ALTO services are specified and defined once such further ALTO services are specified
in an extension document.</t> in an extension document.</t>
</section>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="Implementation, Deployment, and Operational Considerations"> <name>Implementation, Deployment, and Operational Considerations</name>
<section numbered="true" toc="default">
<section title="Considerations for ALTO Clients"> <name>Considerations for ALTO Clients</name>
<section anchor="sec.rcid" numbered="true" toc="default">
<section anchor="sec.rcid" title="Resource Consumer Initiated Discov <name>Resource-Consumer-Initiated Discovery</name>
ery"> <t>Resource-consumer-initiated
<t>Resource consumer initiated
ALTO server discovery ALTO server discovery
(c.f. ALTO requirement AR-32 <xref target="RFC6708"/>) (cf.&nbsp;ALTO requirement AR-32 <xref target="RFC6708" format=" default"/>)
can be seen as a special case of can be seen as a special case of
cross-domain ALTO server discovery. To that end, an ALTO cross-domain ALTO server discovery. To that end, an ALTO
client embedded in a resource consumer would have to client embedded in a resource consumer would have to
perform the ALTO Cross-Domain Server Discovery Procedure perform the ALTO Cross-Domain Server Discovery Procedure
with its own IP address as a parameter. with its own IP address as a parameter.
However, due to the widespread deployment of Network Address However, due to the widespread deployment of Network Address
Translators (NAT), additional protocols and mechanisms such Translators (NATs), additional protocols and mechanisms such
as STUN <xref target="RFC5389"/> are usually needed to as Session Traversal Utilities for NAT (STUN) <xref
detect the client's "public" IP address, before it can target="RFC5389" format="default"/> are usually needed to
be used as a parameter to the discovery procedure. detect the client's "public" IP address before it can
be used as a parameter for the discovery procedure.
Note that a different approach for Note that a different approach for
resource consumer initiated ALTO server discovery, resource-consumer-initiated ALTO server discovery,
which is based on DHCP, is which is based on DHCP, is
specified in specified in
<xref target="RFC7286"/>.</t> <xref target="RFC7286" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IPv4/v6 Dual Stack, Multihoming and <name>IPv4/v6 Dual Stack, Multihoming and Host Mobilit
Host Mobility"> y</name>
<t>The procedure specified in this document can discover
<t>The procedure specified in this document can discover
ALTO server URIs for a given IP address or prefix. ALTO server URIs for a given IP address or prefix.
The intention is, that a third party (e.g., a The intention is that a third party (e.g., a
resource directory) that receives query messages from resource directory) that receives query messages from
a resource consumer can use the source address in a resource consumer can use the source address in
these messages to discover suitable ALTO servers for this these messages to discover suitable ALTO servers for this
specific resource consumer.</t> specific resource consumer.</t>
<t>However, resource consumers (as defined in
<t>However, resource consumers (as defined in Section 2 of <xref target="RFC5693" format="default" sectionFormat="of"
<xref target="RFC5693"/>) may reside on hosts with more than section="2"/>) may reside on hosts with more than
one IP address, e.g., due to IPv4/v6 dual stack operation one IP address -- for example, due to IPv4/v6 dual stack operati
on
and/or multihoming. and/or multihoming.
IP packets sent with different source addresses may be IP packets sent with different source addresses may be
subject to different routing policies and path costs. In subject to different routing policies and path costs. In
some deployment scenarios, it may even be required to ask some deployment scenarios, it may even be required to ask
different sets of ALTO servers for guidance. different sets of ALTO servers for guidance.
Furthermore, source addresses in IP packets may be modified Furthermore, source addresses in IP packets may be modified
en-route by Network Address Translators (NAT). en route by Network Address Translators (NATs).
</t> </t>
<t>If a resource consumer queries a resource directory for
<t>If a resource consumer queries a resource directory for
candidate resource providers, the locally selected (and candidate resource providers, the locally selected (and
possibly en-route possibly en-route-translated) source address of the query
translated) source address of the query message -&nbsp;as message --&nbsp;as
observed by the resource directory&nbsp;- will become the observed by the resource directory&nbsp;-- will become the
basis for the ALTO server discovery and the subsequent basis for the ALTO server discovery and the subsequent
optimization of the resource directory's reply. If, optimization of the resource directory's reply. If,
however, the resource consumer then selects different source however, the resource consumer then selects different source
addresses to contact returned resource providers, the addresses to contact returned resource providers, the
desired better-than-random "ALTO&nbsp;effect" may not desired better-than-random "ALTO&nbsp;effect" may not
occur.</t> occur.</t>
<t>One solution approach for this problem is that
<t>One solution approach for this problem is, that a dual-stack or multihomed resource consumer could
a dual stack or multihomed resource consumer could
always use the same address for contacting the always use the same address for contacting the
resource directory and all resource providers, thus resource directory and all resource providers, thus
overriding the operating system's automatic source overriding the operating system's automatic selection of
IP address selection. For example, when using the source IP addresses.
For example, when using the
BSD socket API, one could always bind() the socket to one of BSD socket API, one could always bind() the socket to one of
the local IP addresses before trying to connect() to the the local IP addresses before trying to connect() to the
resource directory or the resource providers, respectively. resource directory or the resource providers, respectively.
Another solution approach is to perform ALTO-influenced Another solution approach is to perform ALTO-influenced
resource provider selection (and source address selection) resource provider selection (and source-address selection)
locally in the resource consumer, locally in the resource consumer,
in addition to or instead of performing it in the resource in addition to, or instead of, performing it in the resource
directory. See <xref target="sec.rcid"/> for a discussion directory. See <xref target="sec.rcid" format="default"/> for
a discussion of
how to discover ALTO servers for local usage in the how to discover ALTO servers for local usage in the
resource consumer.</t> resource consumer.</t>
<t>Similarly, resource
<t>Similarly, resource consumers on mobile hosts <bcp14>SHOULD</bcp14> query the resour
consumers on mobile hosts SHOULD query the resource ce
directory again after a change of IP address, in order to directory again after a change of IP address, in order to
get a list of candidate resource providers that is optimized get a list of candidate resource providers that is optimized
for the new IP address. for the new IP address.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Interaction with Network Address Translation"> <name>Interaction with Network Address Translation</name>
<t>The ALTO Cross-Domain Server Discovery Procedure has
<t>The ALTO Cross-Domain Server Discovery Procedure has
been designed to enable the ALTO-based optimization been designed to enable the ALTO-based optimization
of applications such as large-scale overlay networks, that of applications such as large-scale overlay networks, that
span - on the IP layer - multiple adminstrative domains, span -- on the IP layer -- multiple administrative domains,
possibly the whole Internet. possibly the whole Internet.
Due to the widespread usage of Network Address Translators Due to the widespread usage of Network Address Translators
(NAT) it may well be that nodes of the overlay network (NATs), it may well be that nodes of the overlay network
(i.e., resource consumers or resource providers) are located (i.e., resource consumers or resource providers) are located
behind a NAT, maybe even behind several cascaded NATs.</t> behind a NAT, maybe even behind several cascaded NATs.</t>
<t>If a resource directory is located in the public Internet
<t>If a resource directory is located in the public Internet (i.e., not behind a NAT) and
(i.e., not behind a NAT) and if it
receives a message from a resource consumer behind one or receives a message from a resource consumer behind one or
more NATs, the message's source address will be the more NATs, the message's source address will be the
public IP address of the outermost NAT in front of the public IP address of the outermost NAT in front of the
resource consumer. The same applies if the resource resource consumer. The same applies if the resource
directory is behind a different NAT than the resource directory is behind a different NAT than the resource
consumer. The resource directory may call the consumer. The resource directory may call the
ALTO Cross-Domain Server Discovery Procedure with the ALTO Cross-Domain Server Discovery Procedure with the
message's source address as a parameter. In effect, message's source address as a parameter. In effect,
not the resource consumer's (private) IP address, but not the resource consumer's (private) IP address, but
the public IP address of the outermost NAT in front of it the public IP address of the outermost NAT in front of it,
will be used as a basis for ALTO-optimization. This will will be used as a basis for ALTO optimization. This will
work fine as long as the network behind the NAT is not too work fine as long as the network behind the NAT is not too
big (e.g., if the NAT is in a residential gateway). big (e.g., if the NAT is in a residential gateway).
</t> </t>
<t>If a resource directory receives a message from a resource
<t>If a resource directory receives a message from a resource
consumer and the message's source address is a "private" consumer and the message's source address is a "private"
IP address <xref target="RFC1918"/>, this may be a sign IP address <xref target="RFC1918" format="default"/>, this may b
that both of them are behind the same NAT. An invokation e a sign
that both of them are behind the same NAT. An invocation
of the ALTO Cross-Domain Server Discovery Procedure with of the ALTO Cross-Domain Server Discovery Procedure with
this private address may be problematic, as this will only this private address may be problematic, as this will only
yield usable results if a DNS "split horizon" and DNSSEC yield usable results if a DNS "split horizon" and DNSSEC
trust anchors are configured correctly. In this situation trust anchors are configured correctly. In this situation,
it may be more advisable to query an ALTO server that has it may be more advisable to query an ALTO server that has
been discovered using <xref target="RFC7286"/> or any been discovered using <xref target="RFC7286" format="default"/> or any
other local configuration. other local configuration.
The interaction between intra-domain ALTO for The interaction between intradomain ALTO for
large private domains (e.g., behind a "carrier-grade NAT") large private domains (e.g., behind a "carrier-grade NAT")
and cross-domain, Internet-wide optimization, is beyond and cross-domain, Internet-wide optimization, is beyond
the scope of this document. the scope of this document.
</t> </t>
</section>
</section> </section>
</section>
<section title="Considerations for Network Operators"> <section numbered="true" toc="default">
<name>Considerations for Network Operators</name>
<section title="Flexibility vs. Load on the DNS"> <section numbered="true" toc="default">
<name>Flexibility vs. Load on the DNS</name>
<t>The ALTO Cross-Domain Server Discovery Procedu <t>The ALTO Cross-Domain Server Discovery Procedure, as
re, as specified in <xref target="sec.3pdisc-spec"
specified in <xref target="sec.3pdisc-spec"/>, fi format="default"/>, first
rst produces a list of domain names (Steps 1 and 2) and
produces a list of domain names (steps 1 and 2) and
then looks for relevant NAPTR records associated with then looks for relevant NAPTR records associated with
these names, until a useful result can be found (step 3). these names, until a useful result can be found (Step 3).
The number of candidate domain names on this The number of candidate domain names on this
list is a compromise between flexibility when installing list is a compromise between flexibility when installing
NAPTR records and avoiding excess load on the DNS. NAPTR records and avoiding excess load on the DNS.
</t> </t>
<t>A single invocation of the ALTO Cross-Domain Server
<t>A single invocation of the ALTO Cross-Domain Server
Discovery Procedure, with an IPv6 address as a parameter, may Discovery Procedure, with an IPv6 address as a parameter, may
cause up to, but no more than, six DNS lookups for NAPTR cause up to, but no more than, six DNS lookups for NAPTR
records. For IPv4, the maximum is four lookups. records. For IPv4, the maximum is four lookups.
Should the load on the DNS infrastructure caused by these Should the load on the DNS infrastructure caused by these
lookups become a problem, one solution approach is to lookups become a problem, one solution approach is to
actually populate the DNS with ALTO-specific NAPTR records. populate the DNS with ALTO-specific NAPTR records.
If such records can be found for individual IP addresses If such records can be found for individual IP addresses
(possibly installed using a wildcarding mechanism in (possibly installed using a wildcarding mechanism in
the name server) or for long prefixes, the the name server) or long prefixes, the
procedure will terminate successfully and not perform procedure will terminate successfully and not perform
lookups for shorter prefix lengths, thus reducing the lookups for shorter prefix lengths, thus reducing the
total number of DNS queries. total number of DNS queries.
Another approach for reducing the load on the DNS Another approach for reducing the load on the DNS
infrastructure is to increase the TTL for caching negative infrastructure is to increase the TTL for caching negative
answers.</t> answers.</t>
<t>On the other hand, the ALTO Cross-Domain Server Discovery
<t>On the other hand, the ALTO Cross-Domain Server Discovery Procedure trying to look up truncated domain names allows for
Procedure trying to lookup truncated domain names allows for
efficient configuration of large-scale scenarios, where efficient configuration of large-scale scenarios, where
discovery is to be enabled for a large number of IP discovery is to be enabled for a large number of IP
addresses with a small number of additional DNS resource addresses with a small number of additional DNS resource
records. records.
Note that expressly, it has not been a design goal of this Note that it expressly has not been a design goal of this
procedure to give clients a means to understand the IP procedure to give clients a means of understanding the IP
prefix delegation structure. Furthermore, this specification prefix delegation structure. Furthermore, this specification
does not assume or reccomend that prefix delegations should does not assume or recommend that prefix delegations should
preferrably occur at those prefix lengths that are used preferably occur at those prefix lengths that are used
in Step 2 of this procedure in Step 2 of this procedure
(see <xref target="sec.3pdisc-spec-step2"/>). (see <xref target="sec.3pdisc-spec-step2" format="default"/>).
A network operator that uses, for example, an IPv4 /18 A network operator that uses, for example, an IPv4 /18
prefix and wants to install the NAPTR records efficiently, prefix and wants to install the NAPTR records efficiently
could either install 64 NAPTR records (one for each of the could either install 64 NAPTR records (one for each of the
/24 prefixes contained within the /18 prefix), or they could /24 prefixes contained within the /18 prefix), or they could
try to team up with the owners of the other fragments of the try to team up with the owners of the other fragments of the
enclosing /16 prefix, in order to run a common ALTO server enclosing /16 prefix, in order to run a common ALTO server
to which only one NAPTR would point.</t> to which only one NAPTR would point.</t>
</section>
</section> <section numbered="true" toc="default">
<name>BCP 20 and Missing Delegations of the Reverse DNS</name>
<section title="BCP20 and missing delegations of the reverse DNS"> <t><xref target="RFC2317" format="default"/>, also known as BCP 20,
<t>RFC2317 <xref target="RFC2317"/>, also known as BCP20,
describes a way to delegate the "reverse DNS" (i.e., describes a way to delegate the "reverse DNS" (i.e.,
subdomains of in-addr.arpa.) for IPv4 address ranges subdomains of "in-addr.arpa.") for IPv4 address ranges
with fewer than 256 addresses (i.e., less than a whole with fewer than 256 addresses (i.e., less than a whole
/24 prefix). The ALTO Cross-Domain Server Discovery procedure /24 prefix). The ALTO Cross-Domain Server Discovery Procedure
is compatible with this method.</t> is compatible with this method.</t>
<t>In some deployment scenarios -- e.g., residential Internet
<t>In some deployment scenarios, e.g., residential Internet access -- where customers often dynamically receive a single
access, where customers often dynamically receive a single
IPv4 address (and/or a small IPv6 address block) from a pool IPv4 address (and/or a small IPv6 address block) from a pool
of addresses, ISPs typically will not delegate the "reverse of addresses, ISPs typically will not delegate the "reverse
DNS" to their customers. This practice makes it impossible DNS" to their customers. This practice makes it impossible
for these customers to populate the DNS with NAPTR resource for these customers to populate the DNS with NAPTR resource
records that point to an ALTO server of their choice. Yet, records that point to an ALTO server of their choice. Yet,
the ISP may publish NAPTR resource records in the the ISP may publish NAPTR resource records in the
"reverse DNS" for individual addresses or larger "reverse DNS" for individual addresses or larger
address pools (i.e., shorter prefix lengths).</t> address pools (i.e., shorter prefix lengths).</t>
<t>While ALTO is by no means technologically tied
<t>While ALTO is by no means technologically tied
to the Border Gateway Protocol (BGP), to the Border Gateway Protocol (BGP),
it is anticipated that BGP will be an important it is anticipated that BGP will be an important
source of information for ALTO and that the operator of the source of information for ALTO and that the operator of the
outermost BGP-enabled router will have a strong incentive to outermost BGP-enabled router will have a strong incentive to
publish a digest of their routing policies and costs through publish a digest of their routing policies and costs through
ALTO. In contrast, an individual user or an organization ALTO. In contrast, an individual user or an organization
that has been assigned only a small address range that has been assigned only a small address range
(i.e., an IPv4 prefix with a prefix length longer than /24) (i.e., an IPv4 prefix with a prefix length longer than /24)
will typically connect to the Internet using only a single ISP, will typically connect to the Internet using only a single ISP,
and they might not be interested in publishing their and they might not be interested in publishing their
own ALTO information. Consequently, they might wish to leave own ALTO information. Consequently, they might wish to leave
the operation of an ALTO server up to their ISP. the operation of an ALTO server up to their ISP.
This ISP may install NAPTR resource records, which are This ISP may install NAPTR resource records, which are
needed for the ALTO Cross-Domain Server Discovery procedure, needed for the ALTO Cross-Domain Server Discovery Procedure,
in the subdomain of in-addr.arpa. that corresponds to in the subdomain of "in-addr.arpa." that corresponds to
the whole /24 prefix (c.f., R24 in the whole /24 prefix (cf.&nbsp;R24 in
<xref target="sec.3pdisc-spec-step2"/> of this document), <xref target="sec.3pdisc-spec-step2" format="default"/> of this
even if BCP20-style document),
delegations or no delegations at all are in use.</t> even if delegations in the style of BCP 20 or no delegations
at all are in use.</t>
</section>
</section> </section>
</section>
</section> </section>
<section anchor="seccons" numbered="true" toc="default">
<section anchor="seccons" title="Security Considerations"> <name>Security Considerations</name>
<t>A high-level discussion of security issues related to ALTO
<t>A high-level discussion of security issues related to ALTO
is part of the ALTO problem statement is part of the ALTO problem statement
<xref target="RFC5693"/>. A classification of unwanted <xref target="RFC5693" format="default"/>. A classification of unwa nted
information disclosure risks, as well as specific information disclosure risks, as well as specific
security-related requirements can be found in the ALTO security-related requirements, can be found in the ALTO
requirements document <xref target="RFC6708"/>. requirements document <xref target="RFC6708" format="default"/>.
</t> </t>
<t>The remainder of this section focuses on security threats
<t>The remainder of this section focuses on security threats and protection mechanisms for the Cross-Domain ALTO Server Discovery
and protection mechanisms for the cross-domain ALTO server discovery Procedure as such. Once the ALTO server's URI has been
procedure as such. Once the ALTO server's URI has been discovered, and the communication between the ALTO client and
discovered and the communication between the ALTO client and
the ALTO server starts, the security threats and protection the ALTO server starts, the security threats and protection
mechanisms discussed in the ALTO protocol specification mechanisms discussed in the ALTO protocol specification
<xref target="RFC7285"/> apply. <xref target="RFC7285" format="default"/> apply.
</t> </t>
<section anchor="sec.sec.integrity" numbered="true" toc="default">
<section anchor="sec.sec.integrity" <name>Integrity of the ALTO Server's URI</name>
title="Integrity of the ALTO Server's URI"> <dl newline="true" spacing="normal">
<t><list style="hanging"> <dt>Scenario Description</dt>
<t hangText="Scenario Description"> <dd>
<vspace blankLines="0" /> An attacker could compromise the ALTO server
An attacker could compromise the ALTO server discovery procedure or the underlying infrastructure
discovery procedure or the underlying infrastructure in such a way that ALTO clients would discover a "wrong"
in a way that ALTO clients would discover a "wrong" ALTO server URI.
ALTO server URI. </dd>
</t> <dt>Threat Discussion</dt>
<t hangText="Threat Discussion"> <dd>
<vspace blankLines="0" /> The Cross-Domain ALTO Server Discovery Procedure
The cross-domain ALTO server discovery procedure relies on a series of DNS lookups, in order to
relies on a series of DNS lookups, in order to produce one or more URIs.
produce one or more URI(s). If an attacker were able to modify or spoof any of
If an attacker was able to modify or spoof any of the DNS records, the resulting
the DNS records, the resulting URIs could be replaced by forged URIs.
URI(s) could be replaced by forged URI(s). This is probably the most serious security
This is probably the most serious security concern related to ALTO server discovery. The
concern related to ALTO server discovery. The discovered "wrong" ALTO server might not be able
discovered "wrong" ALTO server might not be able to give guidance to a given ALTO client at all,
to give guidance to a given ALTO client at all, or it might give suboptimal or forged
or it might give suboptimal or forged information. In the latter case, an attacker
information. In the latter case, an attacker could try to use ALTO to affect the traffic
could try to use ALTO to affect the traffic distribution in the network or the performance
distribution in the network or the performance of applications (see also
of applications (see also Section 15.1. of <xref target="RFC7285" format="default"
<xref target="RFC7285"/>). sectionFormat="of" section="15.1"/>).
Furthermore, a hostile ALTO server could Furthermore, a hostile ALTO server could
threaten user privacy (see also Section 5.2.1, threaten user privacy (see also Case (5a) in <xref
case (5a) in <xref target="RFC6708"/>). target="RFC6708" sectionFormat="of" section="5.2.1"/>).
</t> </dd>
<dt>Protection Strategies and Mechanisms</dt>
<t hangText="Protection Strategies and Mechanisms"> <dd>
<vspace blankLines="0" /> The application of DNS security (DNSSEC)
<xref target="RFC4033" format="default"/> provides a means of
The application of DNS security (DNSSEC) detecting and averting attacks that rely on modification
<xref target="RFC4033"/> provides a means to of the DNS records while in transit. All
detect and avert attacks that rely on modification implementations of the Cross-Domain ALTO Server
of the DNS records while in transit. All Discovery Procedure <bcp14>MUST</bcp14> support DNSSEC or be able to
implementations of the cross-domain ALTO server use such functionality provided by the underlying
discovery procedure MUST support DNSSEC or be able to operating system. Network operators that publish
use such functionality provided by the underlying U-NAPTR resource records to be used for the
operating system. Network operators that publish Cross-Domain ALTO Server Discovery Procedure
U-NAPTR resource records to be used for the <bcp14>SHOULD</bcp14> use DNSSEC to protect their subdomains
cross-domain ALTO server discovery procedure of "in-addr.arpa." and/or "ip6.arpa.", respectively.
SHOULD use DNSSEC to protect their subdomains Additional operational precautions for safely operating
of in-addr.arpa. and/or ip6.arpa., respectively. the DNS infrastructure are required in order
Additional operational precautions for safely operating to ensure that name servers do not sign forged
the DNS infrastructure are required in order (or otherwise "wrong") resource records.
to ensure that name servers do not sign forged Security considerations specific to U-NAPTR are
(or otherwise "wrong") resource records. described in more detail in <xref target="RFC4848" format="default"/
Security considerations specific to U-NAPTR are >.
described in more detail in <xref target="RFC4848"/>. </dd>
</t> <dt/>
<t> <dd>
In addition to active protection mechanisms, In addition to active protection mechanisms,
users and network operators can monitor users and network operators can monitor
application performance and network traffic application performance and network traffic
patterns for poor performance or patterns for poor performance or
abnormalities. If it turns out that relying on abnormalities. If it turns out that relying on
the guidance of a specific ALTO server does not the guidance of a specific ALTO server does not
result in better-than-random results, the usage result in better-than-random results, the usage
of the ALTO server may be discontinued (see also of the ALTO server may be discontinued (see also
Section 15.2 of <xref target="RFC7285"/>). <xref target="RFC7285"
</t> format="default" sectionFormat="of" section="15.2"/>).
<t hangText="Note"> </dd>
<vspace blankLines="0" /> <dt>Note</dt>
The cross-domain ALTO server discovery procedure <dd>
finishes successfully when it has discovered one The Cross-Domain ALTO Server Discovery Procedure
or more URI(s). Once an ALTO server's URI has been finishes successfully when it has discovered one
discovered and the communication between the ALTO or more URIs. Once an ALTO server's URI has been
client and the ALTO server starts, the security discovered and the communication between the ALTO
threats and protection mechanisms discussed in the client and the ALTO server starts, the security
ALTO protocol specification <xref target="RFC7285"/> threats and protection mechanisms discussed in the
apply. ALTO protocol specification <xref target="RFC7285" format="default"/
</t> >
<t> apply.
A threat related to the one considered above is the </dd>
impersonation of an ALTO server after its correct <dt/>
URI has been discovered. This threat and protection <dd>
strategies are discussed in Section 15.1 of A threat related to the one considered above is the
<xref target="RFC7285"/>. impersonation of an ALTO server after its correct
URI has been discovered. This threat and protection
The ALTO protocol's primary mechanism for protecting strategies are discussed in
authenticity and integrity (as well as confidentiality) <xref target="RFC7285" format="default"
is the use of sectionFormat="of" section="15.1"/>.
HTTPS-based transport, i.e., HTTP over TLS
<xref target="RFC2818"/>.
Typically, when the URI's host component is a host
name, a further DNS lookup is needed to map it to an
IP address, before the communication with the server
can begin. This last DNS lookup (for A or AAAA
resource records) does not necessarily have to be
protected by DNSSEC, as the server identity checks
specified in <xref target="RFC2818"/> are able to
detect DNS spoofing or similar attacks, after the
connection to the (possibly wrong) host has been
established.
However, this validation, which is based on the
server certificate, can only protect the steps that
occur after the server URI has been discovered.
It cannot detect attacks against the authenticity
of the U-NAPTR lookups needed for the
cross-domain ALTO server discovery procedure,
and therefore, these resource records have to
be secured using DNSSEC.
</t>
</list>
</t>
</section>
<section title="Availability of the ALTO Server Discovery Procedure"> The ALTO protocol's primary mechanism for protecting
<t><list style="hanging"> authenticity and integrity (as well as confidentiality)
<t hangText="Scenario Description"> is the use of
<vspace blankLines="0" /> HTTPS-based transport -- i.e., HTTP over TLS
An attacker could compromise the cross-domain ALTO <xref target="RFC2818" format="default"/>.
server discovery procedure or the underlying
infrastructure in a way that ALTO clients would not
be able to discover any ALTO server.
</t>
<t hangText="Threat Discussion">
<vspace blankLines="0" />
If no ALTO server can be discovered (although a
suitable one exists) applications have to make
their decisions without ALTO guidance. As ALTO
could be temporarily unavailable for many
reasons, applications must be prepared to do so.
However, The resulting application performance
and traffic distribution will correspond to a
deployment scenario without ALTO.
</t>
<t hangText="Protection Strategies and Mechanisms">
<vspace blankLines="0" />
Operators should follow best current practices
to secure their DNS and ALTO (see Section 15.5 of
<xref target="RFC7285"/>)
servers against Denial-of-Service (DoS) attacks.
</t>
</list>
</t>
</section>
<section title="Confidentiality of the ALTO Server's URI"> Typically, when the URI's host component is a host
<t><list style="hanging"> name, a further DNS lookup is needed to map it to an
<t hangText="Scenario Description"> IP address before the communication with the server
<vspace blankLines="0"/> can begin. This last DNS lookup (for A or AAAA
An unauthorized party could invoke the cross-domain ALTO resource records) does not necessarily have to be
server discovery procedure, or intercept protected by DNSSEC, as the server identity checks
discovery messages between an authorized ALTO specified in <xref target="RFC2818" format="default"/> are able to
client and the DNS servers, in order to detect DNS spoofing or similar attacks after the
acquire knowledge of the ALTO server URI for connection to the (possibly wrong) host has been
a specific IP address. established.
</t> However, this validation, which is based on the
<t hangText="Threat Discussion"> server certificate, can only protect the steps that
<vspace blankLines="0" /> occur after the server URI has been discovered.
It cannot detect attacks against the authenticity
of the U-NAPTR lookups needed for the
Cross-Domain ALTO Server Discovery Procedure,
and therefore, these resource records have to
be secured using DNSSEC.
</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>Availability of the ALTO Server Discovery Procedure</name>
<dl newline="true" spacing="normal">
<dt>Scenario Description</dt>
<dd>
An attacker could compromise the Cross-Domain ALTO
Server Discovery Procedure or the underlying
infrastructure in such a way that ALTO clients would not
be able to discover any ALTO server.
</dd>
<dt>Threat Discussion</dt>
<dd>
If no ALTO server can be discovered (although a
suitable one exists), applications have to make
their decisions without ALTO guidance. As ALTO
could be temporarily unavailable for many
reasons, applications must be prepared to do so.
However, the resulting application performance
and traffic distribution will correspond to a
deployment scenario without ALTO.
</dd>
<dt>Protection Strategies and Mechanisms</dt>
<dd>
Operators should follow best current practices
to secure their DNS and ALTO servers (see
<xref target="RFC7285" format="default"
sectionFormat="of" section="15.5"/>)
against Denial-of-Service (DoS) attacks.
</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>Confidentiality of the ALTO Server's URI</name>
<dl newline="true" spacing="normal">
<dt>Scenario Description</dt>
<dd>
An unauthorized party could invoke the Cross-Domain ALTO
Server Discovery Procedure or intercept
discovery messages between an authorized ALTO
client and the DNS servers, in order to
acquire knowledge of the ALTO server URI for
a specific IP address.
</dd>
<dt>Threat Discussion</dt>
<dd>
In the ALTO use cases that have been described In the ALTO use cases that have been described
in the ALTO problem statement in the ALTO problem statement
<xref target="RFC5693"/> and/or discussed in the <xref target="RFC5693" format="default"/> and/or discuss ed in the
ALTO working group, the ALTO server's URI as ALTO working group, the ALTO server's URI as
such has always been considered as public such has always been considered as public
information that does not need protection of information that does not need protection of
confidentiality. confidentiality.
</t> </dd>
<t hangText="Protection Strategies and Mechanisms"> <dt>Protection Strategies and Mechanisms</dt>
<vspace blankLines="0" /> <dd>
No protection mechanisms for this scenario have No protection mechanisms for this scenario have
been provided, as it has not been identified as been provided, as it has not been identified as
a relevant threat. However, if a new use case is a relevant threat. However, if a new use case is
identified that requires this kind of identified that requires this kind of
protection, the suitability of this ALTO server protection, the suitability of this ALTO server
discovery procedure as well as possible security discovery procedure as well as possible security
extensions have to be re-evaluated thoroughly. extensions have to be re-evaluated thoroughly.
</t> </dd>
</list> </dl>
</t> </section>
</section> <section numbered="true" toc="default">
<name>Privacy for ALTO Clients</name>
<section title="Privacy for ALTO Clients"> <dl newline="true" spacing="normal">
<t><list style="hanging"> <dt>Scenario Description</dt>
<t hangText="Scenario Description"> <dd>
<vspace blankLines="0"/>
An unauthorized party could eavesdrop on the An unauthorized party could eavesdrop on the
messages between an ALTO client and the messages between an ALTO client and the
DNS servers, and thereby find out the fact that DNS servers and thereby find out the fact that
said ALTO client uses (or at least tries to use) said ALTO client uses (or at least tries to use)
the ALTO service in order to optimize traffic the ALTO service in order to optimize traffic
from/to a specific IP address. from/to a specific IP address.
</t> </dd>
<t hangText="Threat Discussion"> <dt>Threat Discussion</dt>
<vspace blankLines="0" /> <dd>
In the ALTO use cases that have been described In the ALTO use cases that have been described
in the ALTO problem statement in the ALTO problem statement
<xref target="RFC5693"/> and/or discussed in the <xref target="RFC5693" format="default"/> and/or discuss ed in the
ALTO working group, this scenario has not been ALTO working group, this scenario has not been
identified as a relevant threat. However, identified as a relevant threat. However,
Pervasive Surveillance <xref target="RFC7624"/> pervasive surveillance <xref target="RFC7624"
and DNS Privacy Considerations <xref target="RFC7626"/> format="default"/>
and DNS privacy considerations <xref target="RFC7626"
format="default"/>
have seen significant attention in the Internet have seen significant attention in the Internet
community in recent years. community in recent years.
</t> </dd>
<t hangText="Protection Strategies and Mechanisms"> <dt>Protection Strategies and Mechanisms</dt>
<vspace blankLines="0" /> <dd>
DNS over TLS <xref target="RFC7858"/> and DNS over TLS <xref target="RFC7858" format="default"/> a
DNS over HTTPS <xref target="RFC8484"/> provide nd
DNS over HTTPS <xref target="RFC8484" format="default"/>
provide
means for protecting confidentiality (and integrity) means for protecting confidentiality (and integrity)
of DNS traffic between a client (stub) and its of DNS traffic between a client (stub) and its
recursive name servers, including DNS queries recursive name servers, including DNS queries
and replies caused by the ALTO Cross-Domain and replies caused by the ALTO Cross-Domain
Server Discovery Procedure. Server Discovery Procedure.
</t> </dd>
</list> </dl>
</t> </section>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document does not require any IANA action.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.kiesel-alto-alto4alto" to="ALTO4ALTO" />
<?rfc include="reference.RFC.2119" ?> <displayreference target="I-D.kiesel-alto-ip-based-srv-disc" to="ALTO-ANYCAST" /
<?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" ?>
</references>
<references title="Informative References"> <references>
<?rfc include="reference.RFC.1918" ?> <name>References</name>
<?rfc include="reference.RFC.2317" ?> <references>
<?rfc include="reference.RFC.2818" ?> <name>Normative References</name>
<?rfc include="reference.RFC.4033" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.4291" ?> ence.RFC.2119.xml"/>
<?rfc include="reference.RFC.4632" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.5389" ?> ence.RFC.3403.xml"/>
<?rfc include="reference.RFC.5693" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.6708" ?> ence.RFC.4848.xml"/>
<?rfc include="reference.RFC.7216" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.7285" ?> ence.RFC.1035.xml"/>
<?rfc include="reference.RFC.7286" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.7624" ?> ence.RFC.3596.xml"/>
<?rfc include="reference.RFC.7626" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.7858" ?> ence.RFC.8174.xml"/>
<?rfc include="reference.RFC.7971" ?> </references>
<?rfc include="reference.RFC.8484" ?> <references>
<?rfc include="reference.I-D.kiesel-alto-ip-based-srv-disc" ?> <name>Informative References</name>
<?rfc include="reference.I-D.kiesel-alto-alto4alto" ?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</references> ence.RFC.1918.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2317.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2818.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4033.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4291.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4632.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5389.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5693.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6708.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7216.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7285.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7286.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7624.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7626.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7858.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7971.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8484.xml"/>
<section anchor="sec.multiplesources" <!-- draft-kiesel-alto-ip-based-srv-disc-03 is expired -->
title="Solution Approaches for Partitioned ALTO Knowledge"> <xi:include
<t> href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D
The ALTO base protocol document <xref target="RFC7285"/> .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/refe
rence.I-D.kiesel-alto-alto4alto.xml"/>
</references>
</references>
<section anchor="sec.multiplesources" numbered="true" toc="default">
<name>Solution Approaches for Partitioned ALTO Knowledge</name>
<t>
The ALTO base protocol document <xref target="RFC7285" format="defau
lt"/>
specifies the communication between an ALTO client and a specifies the communication between an ALTO client and a
single ALTO server. It is implicitly assumed that this single ALTO server. It is implicitly assumed that this
server can answer any query, possibly with some kind of server can answer any query, possibly with some kind of
default value if no exact data is known. No special default value if no exact data is known. No special
provisions were made for the case that the ALTO information provisions were made for the case that the ALTO information
originates from multiple sources, which are possibly under originates from multiple sources, which are possibly under
the control of different administrative entities (e.g., the control of different administrative entities (e.g.,
different ISPs) or that the overall ALTO information is different ISPs) or that the overall ALTO information is
partitioned and stored on several ALTO servers. partitioned and stored on several ALTO servers.
</t> </t>
<section numbered="true" toc="default">
<section title="Classification of Solution Approaches"> <name>Classification of Solution Approaches</name>
<t> <t>
Various protocol extensions and other solutions have been Various protocol extensions and other solutions have been
proposed to deal with multiple information sources and proposed to deal with multiple information sources and
partitioned knowledge. They can be classified as follows: partitioned knowledge. They can be classified as follows:
<list style='hanging' hangIndent='5'> </t>
<t hangText="1">
Ensure that all ALTO servers have the same
knowledge
</t>
<t hangText="1.1">
Ensure data replication and synchronization
within the provisioning protocol (cf.
<xref target="RFC5693">RFC 5693, Fig 1</xref>).
</t>
<t hangText="1.2">
Use an Inter-ALTO-server data replication
protocol. Possibly, the ALTO protocol itself -
maybe with some extensions - could be used for
that purpose; however, this has not been studied
in detail so far.
</t>
<t hangText="2">
Accept that different ALTO servers (possibly
operated by different organizations, e.g., ISPs)
do not have the same knowledge
</t>
<t hangText="2.1">
Allow ALTO clients to send arbitrary queries to
any ALTO server (e.g. the one discovered using
<xref target="RFC7286"/>). If this server
cannot answer the query itself, it will fetch
the data on behalf of the client, using the ALTO
protocol or a to-be-defined inter-ALTO-server
request forwarding protocol.
</t>
<t hangText="2.2">
Allow ALTO clients to send arbitrary queries to
any ALTO server (e.g. the one discovered using
<xref target="RFC7286"/>). If this server
cannot answer the query itself, it will redirect
the client to the "right" ALTO server that has
the desired information, using a small
to-be-defined extension of the ALTO protocol.
</t>
<t hangText="2.3">
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">
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> <ol>
</t> <!-- Item 1 -->
</section> <li><t>
Ensure that all ALTO servers have the same
knowledge.</t>
<!-- 1.1 -->
<ol type="1.%d">
<li>
Ensure data replication and synchronization
within the provisioning protocol (cf.&nbsp;<xref target="RFC5693" format="de
fault"/>, Figure 1).
</li>
<!-- 1.2 -->
<li>
Use an inter-ALTO-server data replication
protocol. Possibly, the ALTO protocol itself --
maybe with some extensions -- could be used for
that purpose; however, this has not been studied
in detail so far.
</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>
<section title="Discussion of Solution Approaches"> <!-- 2.1 -->
<t> <ol type="2.%d">
The provisioning or initialization protocol for <li>
Allow ALTO clients to send arbitrary queries to
any ALTO server (e.g., the one discovered using
<xref 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.
</li>
<!-- 2.2 -->
<li>
Allow ALTO clients to send arbitrary queries to
any ALTO server (e.g., the one discovered using
<xref 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.
</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.
</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.
</li>
</ol>
</li>
</ol>
</section>
<section numbered="true" toc="default">
<name>Discussion of Solution Approaches</name>
<t>
The provisioning or initialization protocol for
ALTO servers 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 is currently not standardized. It was a conscious
decision not to include this in the scope of the decision not to include this in the scope of the
IETF ALTO working group. The reason is that there IETF ALTO working group. The reason is that there
are many different kinds of information sources. are many different kinds of information sources.
This implementation specific protocol will adapt them This implementation-specific protocol will adapt them
to the ALTO server, which offers a standardized protocol to the ALTO server, which offers a standardized protocol
to the ALTO clients. However, adding the task of to the ALTO clients. However, adding the task of
synchronization between ALTO servers to this protocol synchronization between ALTO servers to this protocol
(i.e., approach 1.1) would overload this protocol with a (i.e., Approach 1.1) would overload this protocol with a
second functionality that requires standardization for second functionality that requires standardization for
seamless multi-domain operation. seamless multidomain operation.
</t> </t>
<t> <t>
For the 1.? solution approaches, in addition to general For Approaches 1.1 and 1.2, in addition to general technical
technical feasibility and issues like overhead and feasibility and issues like overhead and caching efficiency, another
caching efficiency, another aspect to consider is aspect to consider is legal liability. Operator "A" might prefer not to
legal liability. Operator "A" might prefer not to publish information about nodes in, or paths between,
publish information about nodes in or paths between
the networks of operators "B" and "C" through A's the networks of operators "B" and "C" through A's
ALTO server, even if A knew that information. This is ALTO server, even if A knew that information. This is
not only a question of map size and processing load on not only a question of map size and processing load on
A's ALTO server. Operator A could also face legal A's ALTO server. Operator A could also face legal
liability issues if that information had a bad liability issues if that information had a bad
impact on the traffic engineering between B's and C's impact on the traffic engineering between B's and C's
networks, or on their business models. networks or on their business models.
</t> </t>
<t> <t>
No specific actions to build a "search engine" based No specific actions to build a solution based on a "search
solution (approach 2.3) are currently known and it is engine" (Approach 2.3) are currently known, and it is
unclear what could be the incentives to operate such an unclear what could be the incentives to operate such an
engine. Therefore, this approach is not considered in the engine. Therefore, this approach is not considered in the
remainder of this document. remainder of this document.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<name>The Need for Cross-Domain ALTO Server Discovery</name>
<section title="The Need for Cross-Domain ALTO Server Discovery"> <t>
<t> Approaches 1.1, 1.2, 2.1, and 2.2 require more than just the
Approaches 1.1, 1.2, 2.1, and 2.2 do not only require the specification of an ALTO protocol extension or a new protocol that
specification of an ALTO protocol extension or a new runs between ALTO servers. A large-scale,
protocol that runs between ALTO servers. A large-scale, maybe Internet-wide, multidomain deployment would also need
maybe Internet-wide, multi-domain deployment would also need
mechanisms by which an ALTO server could discover other ALTO mechanisms by which an ALTO server could discover other ALTO
servers, learn which information is available where, and servers, learn which information is available where, and
ideally also who is authorized to publish information ideally also who is authorized to publish information
related to a given part of the network. Approach 2.4 needs related to a given part of the network. Approach 2.4 needs
the same mechanisms, except that they are used on the the same mechanisms, except that they are used on the
client-side instead of the server-side. client side instead of the server side.
</t> </t>
<t> <t>
It is sometimes questioned whether there is a need for a It is sometimes questioned whether there is a need for a
solution that allows clients to ask arbitrary queries, even solution that allows clients to ask arbitrary queries, even
if the ALTO information is partitioned and stored on many if the ALTO information is partitioned and stored on many
ALTO servers. The main argument is, that clients are ALTO servers. The main argument is that clients are
supposed to optimize the traffic from and to themselves, and supposed to optimize the traffic from and to themselves, and
that the information needed for that is most likely stored that the information needed for that is most likely stored
on a "nearby" ALTO server, i.e., the one that can be on a "nearby" ALTO server -- i.e., the one that can be
discovered using <xref target="RFC7286"/>. However, there discovered using <xref target="RFC7286" format="default"/>. How
ever, there
are scenarios where the ALTO client is not co-located with are scenarios where the ALTO client is not co-located with
an endpoint of the to-be-optimized data transmission. an endpoint of the to-be-optimized data transmission.
Instead, the ALTO client is located at a third party, which Instead, the ALTO client is located at a third party that
takes part in the application signaling, e.g., a so-called takes part in the application signaling -- e.g., a so-called
"tracker" in a peer-to-peer application. One such scenario, "tracker" in a peer-to-peer application. One such scenario,
where it is advantageous to place the ALTO client not at an where it is advantageous to place the ALTO client not at an
endpoint of the user data transmission, is analyzed in <xref endpoint of the user data transmission, is analyzed in <xref tar
target="apx.alto_p2p"/>. get="apx.alto_p2p" format="default"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Our Solution Approach"> <name>Our Solution Approach</name>
<t> <t>
Several solution approaches for cross-domain ALTO server Several solution approaches for cross-domain ALTO server
discovery have been evaluated, using the criteria discovery have been evaluated, using the criteria
documented in <xref target="sec.xdom-disc-reqs"/>. documented in <xref target="sec.xdom-disc-reqs" format="default" />.
One of them was to use the ALTO protocol itself for One of them was to use the ALTO protocol itself for
the exchange of information availability the exchange of information availability
<xref target="I-D.kiesel-alto-alto4alto"/>. <xref target="I-D.kiesel-alto-alto4alto" format="default"/>.
However, the drawback of that approach is that a new However, the drawback of that approach is that a new
registration administration authority would have to registration administration authority would have to
be established. be established.
</t> </t>
<t> <t>
This document specifies a DNS-based procedure for This document specifies a DNS-based procedure for
cross-domain ALTO server discovery, which was inspired by cross-domain ALTO server discovery, which was inspired by
"Location Information Server (LIS) Discovery Using IP "Location Information Server (LIS) Discovery Using IP
Addresses and Reverse DNS" <xref target="RFC7216"/>. The Addresses and Reverse DNS" <xref target="RFC7216" format="defaul t"/>. The
primary goal is that this procedure can be used on the primary goal is that this procedure can be used on the
client-side (i.e., approach 2.4), but together with new client side (i.e., Approach 2.4), but together with new
protocols or protocol extensions it could also be used to protocols or protocol extensions, it could also be used to
implement the other solution approaches itemized above. implement the other solution approaches itemized above.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Relation to the ALTO Requirements"> <name>Relation to the ALTO Requirements</name>
<t>During the design phase of the overall ALTO solution, two <t>During the design phase of the overall ALTO solution, two
different server discovery scenarios have been identified and different server discovery scenarios were identified and
documented in the ALTO requirements document documented in the ALTO requirements document
<xref target="RFC6708"/>. The first scenario, documented in <xref target="RFC6708" format="default"/>. The first scenario,
documented in
Req. AR-32, can be supported using the discovery mechanisms Req. AR-32, can be supported using the discovery mechanisms
specified in <xref target="RFC7286"/>. specified in <xref target="RFC7286" format="default"/>.
An alternative approach, based on IP anycast An alternative approach, based on IP anycast
<xref target="I-D.kiesel-alto-ip-based-srv-disc"/>, <xref target="I-D.kiesel-alto-ip-based-srv-disc" format="default"/>,
has also been studied. has also been studied.
This document, in contrast, tries to address Req. AR-33. This document, in contrast, tries to address Req. AR-33.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sec.xdom-disc-reqs" numbered="true" toc="default">
<section anchor="sec.xdom-disc-reqs" <name>Requirements for Cross-Domain Server Discovery</name>
title="Requirements for Cross-Domain Server Discovery"> <t>This appendix itemizes requirements that were
collected before the design phase and are reflected
<t>This appendix itemizes requirements that have been in the design of the ALTO Cross-Domain Server Discovery Procedure.
collected before the design phase and that are reflected </t>
by the design of the ALTO Cross-Domain Server Discovery Procedure. <section numbered="true" toc="default">
</t> <name>Discovery Client Application Programming Interface</name>
<t>The discovery client will be called through some kind of
<section title="Discovery Client Application Programming Interface"> application programming interface (API), and the parameters
<t>The discovery client will be called through some kind of
application programming interface (API) and the parameters
will be an IP address and, for purposes of extensibility, will be an IP address and, for purposes of extensibility,
a service identifier such as "ALTO". It will return one or more a service identifier such as "ALTO". The client will return one or m
URI(s) that offers the requested service ("ALTO") for the given ore
URIs that offer the requested service ("ALTO") for the given
IP address. IP address.
</t> </t>
<t>In other words, the client would be used to retrieve a
<t>In other words, the client would be used to retrieve a
mapping:</t> mapping:</t>
<t>(IP address, "ALTO") -> IRD-URI(s)</t> <t>(IP address, "ALTO") -&gt; IRD-URI(s)</t>
<t>where IRD-URI(s) is one or more URI(s) of <t>where IRD-URI(s) is one or more URIs of
Information Resource Directories Information Resource Directories
(IRD, see Section 9 of <xref target="RFC7285"/>) (IRDs, see <xref target="RFC7285" format="default"
of ALTO server(s) that can give reasonable guidance sectionFormat="of" section="9"/>)
of ALTO servers that can give reasonable guidance
to a resource consumer with the indicated IP address.</t> to a resource consumer with the indicated IP address.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Data Storage and Authority Requirements"> <name>Data Storage and Authority Requirements</name>
<t>The information for mapping IP addresses and service <t>The information for mapping IP addresses and service
parameters to URIs should be stored in a - preferably parameters to URIs should be stored in a -- preferably
distributed - database. It must be possible to delegate distributed -- database. It must be possible to delegate
administration of parts of this database. Usually, the administration of parts of this database. Usually, the
mapping from a specific IP address to an URI is defined mapping from a specific IP address to a URI is defined
by the authority that has administrative control over by the authority that has administrative control over
this IP address, e.g., the ISP in residential access networks this IP address -- e.g., the ISP in residential access networks
or the IT department in enterprise, university, or similar or the IT department in enterprise, university, or similar
networks. networks.
</t> </t>
</section>
</section> <section numbered="true" toc="default">
<name>Cross-Domain Operations Requirements</name>
<section title="Cross-Domain Operations Requirements"> <t>The cross-domain server discovery mechanism should
<t>The cross-domain server discovery mechanism should
be designed in such a way that it works across the be designed in such a way that it works across the
public Internet and also in other IP-based networks. public Internet and also in other IP-based networks.
This in turn means that such mechanisms cannot rely on This, in turn, means that such mechanisms cannot rely on
protocols that are not widely deployed across the Internet protocols that are not widely deployed across the Internet
or protocols that require special handling within or protocols that require special handling within
participating networks. An example is multicast, which participating networks. An example is multicast, which
is not generally available across the Internet. is not generally available across the Internet.
</t> </t>
<t>The ALTO Cross-Domain Server Discovery Protocol must
<t>The ALTO Cross-Domain Server Discovery protocol must
support gradual deployment without a network-wide flag day. support gradual deployment without a network-wide flag day.
If the mechanism needs some kind of well-known "rendezvous If the mechanism needs some kind of well-known "rendezvous
point", re-using an existing infrastructure (such as the DNS point", reusing an existing infrastructure (such as the DNS
root servers or the WHOIS database) should be preferred over root servers or the WHOIS database) should be preferred over
establishing a new one.</t> establishing a new one.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Protocol Requirements</name>
<section title="Protocol Requirements"> <t>The protocol must be able to operate across middleboxes,
<t>The protocol must be able to operate across middleboxes, especially NATs and firewalls.
especially across NATs and firewalls. </t>
</t> <t>The protocol shall not require any preknowledge from
<t>The protocol shall not require any pre-knowledge from
the client other than any information that is known to the client other than any information that is known to
a regular IP host on the Internet. a regular IP host on the Internet.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Further Requirements"> <name>Further Requirements</name>
<t>The ALTO cross domain server discovery cannot assume that <t>The ALTO cross-domain server discovery cannot assume that
the server discovery client and the server discovery the server-discovery client and the server-discovery
responding entity are under the same administrative responding entity are under the same administrative
control. control.
</t> </t>
</section> </section>
</section> </section>
<section anchor="apx.alto_p2p" numbered="true" toc="default">
<section anchor="apx.alto_p2p" title="ALTO and Tracker-based Peer-to-Peer Ap <name>ALTO and Tracker-Based Peer-to-Peer Applications</name>
plications"> <t>This appendix provides a complete example of using ALTO and
<t>This appendix provides a complete example of using ALTO and
the ALTO Cross-Domain Server Discovery Procedure in one the ALTO Cross-Domain Server Discovery Procedure in one
specific application scenario, namely a tracker-based peer-to-peer specific application scenario -- namely, a tracker-based peer-to-peer
application. First, in application. First, in
subsection <xref target="apx.alto_p2p_app" format="counter"/>, <xref target="apx.alto_p2p_app"/>,
we introduce a generic model of such an we introduce a generic model of such an
application and show why ALTO optimization is desirable. Then, application and show why ALTO optimization is desirable. Then,
in <xref target="apx.alto_p2p_arch" format="counter"/>, in <xref target="apx.alto_p2p_arch"/>,
we introduce two architectural options for integrating ALTO we introduce two architectural options for integrating ALTO
into the tracker-based peer-to-peer application - one option into the tracker-based peer-to-peer application; one option
is based on the "regular" ALTO server discovery is based on the "regular" ALTO server discovery
procedure <xref target="RFC7286"/>, one relies on the procedure <xref target="RFC7286" format="default"/>, and one relies on t he
ALTO Cross-Domain Server Discovery Procedure. ALTO Cross-Domain Server Discovery Procedure.
In <xref target="apx.alto_p2p_eval" format="counter"/>, In <xref target="apx.alto_p2p_eval"/>,
a simple mathematical a simple mathematical
model is used to show that the latter approach is expected to model is used to show that the latter approach is expected to
yield significantly better optimization results. The appendix concludes yield significantly better optimization results. The appendix concludes
with subsection <xref target="apx.alto_p2p_example" format="counter"/>, with <xref target="apx.alto_p2p_example" />,
which details an exemplary complete walk-through of the which details an exemplary complete walk-through of the
ALTO Cross-Domain Server Discovery Procedure.</t> ALTO Cross-Domain Server Discovery Procedure.</t>
<section anchor="apx.alto_p2p_app" numbered="true" toc="default">
<section anchor="apx.alto_p2p_app" <name>A Generic Tracker-Based Peer-to-Peer Application</name>
title="A generic Tracker-based Peer-to-Peer Application"> <t>The optimization of peer-to-peer (P2P) applications such
<t>The optimization of peer-to-peer (P2P) applications such
as BitTorrent was one of the first use cases that lead to the as BitTorrent was one of the first use cases that lead to the
inception of the IETF ALTO working group. Further use cases inception of the IETF ALTO working group. Further use cases
have been identified as well, yet we will use this scenario have been identified as well, yet we will use this scenario
to illustrate the operation and usefulness of the to illustrate the operation and usefulness of the
ALTO Cross-Domain Server Discovery Procedure.</t> ALTO Cross-Domain Server Discovery Procedure.</t>
<t>For the remainder of this chapter, we consider a generic,
<t>For the remainder of this chapter we consider a generic, tracker-based peer-to-peer file-sharing application.
tracker-based peer-to-peer file sharing application.
The goal is the dissemination of a large file, without using one The goal is the dissemination of a large file, without using one
large server with a correspondingly high upload bandwidth. large server with a correspondingly high upload bandwidth.
The file is split into chunks. The file is split into chunks.
So-called "peers" assume the role of both a client and a server. So-called "peers" assume the role of both a client and a server.
That is, they may request chunks from other peers and they may That is, they may request chunks from other peers, and they may
serve the chunks they already possess to other peers at the same serve the chunks they already possess to other peers at the same
time, thereby contributing their upload bandwidth. time, thereby contributing their upload bandwidth.
Peers that want to share the same file participate in a "swarm". Peers that want to share the same file participate in a "swarm".
They use the peer-to-peer protocol to inform each other about They use the peer-to-peer protocol to inform each other about
the availability of chunks and to request and transfer chunks the availability of chunks and request and transfer chunks
from one peer to another. from one peer to another.
A swarm may consist of a very large number of peers. A swarm may consist of a very large number of peers.
Consequently, peers usually maintain logical connections only to Consequently, peers usually maintain logical connections to only
a subset of all peers in the swarm. a subset of all peers in the swarm.
If a new peer wants to join a swarm, it first contacts a If a new peer wants to join a swarm, it first contacts a
well-known server, the "tracker", which provides a list of IP well-known server, the "tracker", which provides a list of IP
addresses of peers in the swarm.</t> addresses of peers in the swarm.</t>
<t>A swarm is an overlay network on top of the IP network.
<t>A swarm is an overlay network on top of the IP network.
Algorithms that determine the overlay topology and the traffic Algorithms that determine the overlay topology and the traffic
distribution in the overlay may consider information about distribution in the overlay may consider information about
the underlying IP network, such as topological distance, the underlying IP network, such as topological distance,
link bandwidth, (monetary) costs for sending traffic from link bandwidth, (monetary) costs for sending traffic from
one host to another, etc. one host to another, etc.
ALTO is a protocol for retrieving such information. ALTO is a protocol for retrieving such information.
The goal of such "topology aware" decisions is to improve The goal of such "topology-aware" decisions is to improve
performance or Quality of Experience in the application while performance or Quality of Experience in the application while
reducing the utilization of the underlying network reducing the utilization of the underlying network
infrastructure. infrastructure.
</t> </t>
</section>
</section> <section anchor="apx.alto_p2p_arch" numbered="true" toc="default">
<name>Architectural Options for Placing the ALTO Client</name>
<section anchor="apx.alto_p2p_arch" <t>The ALTO protocol specification <xref target="RFC7285" format="defaul
title="Architectural Options for Placing the ALTO Client"> t"/> details how an ALTO client
<t>The ALTO protocol specification <xref
target="RFC7285"/> details how an ALTO client
can query an ALTO server for guiding information and receive can query an ALTO server for guiding information and receive
the corresponding replies. However, in the considered the corresponding replies. However, in the considered
scenario of a tracker-based P2P application, there are two scenario of a tracker-based P2P application, there are two
fundamentally different possibilities where to place the fundamentally different possible locations for where to place the
ALTO client: ALTO client:
<list style='numbers'> </t>
<t>ALTO client in the resource consumer ("peer")</t> <ol spacing="normal" type="1">
<t>ALTO client in the resource directory ("tracker")</t> <li>ALTO client in the resource consumer ("peer")</li>
</list></t> <li>ALTO client in the resource directory ("tracker")</li>
</ol>
<t>In the following, both scenarios are compared in order to <t>In the following, both scenarios are compared in order to
explain the need for ALTO queries on behalf of remote resource explain the need for ALTO queries on behalf of remote resource
consumers.</t> consumers.</t>
<t>In the first scenario (see <xref target="fig.rcq" format="default"/>)
<t>In the first scenario (see <xref target="fig.rcq"/>), the , the
resource consumer queries the resource directory for the resource consumer queries the resource directory for the
desired resource (F1). The resource directory returns a desired resource (F1). The resource directory returns a
list of potential resource providers without considering list of potential resource providers without considering
ALTO (F2). It is then the duty of the resource consumer to ALTO (F2). It is then the duty of the resource consumer to
invoke ALTO (F3/F4), in order to solicit guidance regarding invoke ALTO (F3/F4), in order to solicit guidance regarding
this list.</t> this list.</t>
<t>In the second scenario (see <xref target="fig.3pq" format="default"/>
<t>In the second scenario (see <xref target="fig.3pq"/>), ),
the resource directory has an embedded ALTO client. After the resource directory has an embedded ALTO client. After
receiving a query for a given resource (F1) the resource directory receiving a query for a given resource (F1), the resource directory
invokes this ALTO client to evaluate all resource providers it invokes this ALTO client to evaluate all resource providers it
knows (F2/F3). Then it returns a, possibly shortened, list knows (F2/F3). Then it returns a list, possibly shortened,
containing the "best" resource providers to the resource containing the "best" resource providers to the resource
consumer (F4).</t> consumer (F4).</t>
<figure anchor="fig.tracker_random_preselect">
<t><figure anchor="fig.tracker_random_preselect" <name>Tracker-Based P2P Application with Random Peer Preselection</nam
title="Tracker-based P2P Application with random peer preselection"> e>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
............................. ............................. ............................. .............................
: Tracker : : Peer : : Tracker : : Peer :
: ______ : : : : ______ : : :
: +-______-+ : : k good : : +-______-+ : : k good :
: | | +--------+ : P2P App. : +--------+ peers +------+ : : | | +--------+ : P2P App. : +--------+ peers +------+ :
: | N | | random | : Protocol : | ALTO- |------>| data | : : | N | | random | : Protocol : | ALTO- |------>| data | :
: | known |====>| pre- |*************>| biased | | ex- | : : | known |====>| pre- |*************>| biased | | ex- | :
: | peers, | | selec- | : transmit : | peer |------>| cha- | : : | peers, | | selec- | : transmit : | peer |------>| cha- | :
: | M good | | tion | : n peer : | select | n-k | nge | : : | M good | | tion | : n peer : | select | n-k | nge | :
: +-______-+ +--------+ : IDs : +--------+ bad p.+------+ : : +-______-+ +--------+ : IDs : +--------+ bad p.+------+ :
:...........................: :.....^.....................: :...........................: :.....^.....................:
| |
| ALTO protocol | ALTO protocol
__|___ __|___
+-______-+ +-______-+
| | | |
| ALTO | | ALTO |
| server | | server |
+-______-+ +-______-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<figure anchor="fig.rcq">
<t><figure anchor="fig.rcq" <name>Basic Message Sequence Chart for Resource Consumer-Initiated ALT
title="Basic message sequence chart for resource consumer-initiated AL O Query</name>
TO query"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
Peer w. ALTO cli. Tracker ALTO Server Peer w. ALTO cli. Tracker ALTO Server
--------+-------- --------+-------- --------+-------- --------+-------- --------+-------- --------+--------
| F1 Tracker query | | | F1 Tracker query | |
|======================>| | |======================>| |
| F2 Tracker reply | | | F2 Tracker reply | |
|<======================| | |<======================| |
| F3 ALTO query | | | F3 ALTO query | |
|---------------------------------------------->| |---------------------------------------------->|
| F4 ALTO reply | | | F4 ALTO reply | |
|<----------------------------------------------| |<----------------------------------------------|
| | | | | |
==== Application protocol (i.e., tracker-based P2P app protocol) ==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO protocol ---- ALTO protocol
]]></artwork> ]]></artwork>
</figure></t> </figure>
<figure anchor="fig.tracker_alto_client">
<t><figure anchor="fig.tracker_alto_client" <name>Tracker-Based P2P Application with ALTO Client in Tracker</name>
title="Tracker-based P2P Application with ALTO client in tracker"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
............................. ............................. ............................. .............................
: Tracker : : Peer : : Tracker : : Peer :
: ______ : : : : ______ : : :
: +-______-+ : : : : +-______-+ : : :
: | | +--------+ : P2P App. : k good peers & +------+ : : | | +--------+ : P2P App. : k good peers & +------+ :
: | N | | ALTO- | : Protocol : n-k bad peers | data | : : | N | | ALTO- | : Protocol : n-k bad peers | data | :
: | known |====>| biased |******************************>| ex- | : : | known |====>| biased |******************************>| ex- | :
: | peers, | | peer | : transmit : | cha- | : : | peers, | | peer | : transmit : | cha- | :
: | M good | | select | : n peer : | nge | : : | M good | | select | : n peer : | nge | :
: +-______-+ +--------+ : IDs : +------+ : : +-______-+ +--------+ : IDs : +------+ :
:.....................^.....: :...........................: :.....................^.....: :...........................:
| |
| ALTO protocol | ALTO protocol
__|___ __|___
+-______-+ +-______-+
| | | |
| ALTO | | ALTO |
| server | | server |
+-______-+ +-______-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<figure anchor="fig.3pq">
<t><figure anchor="fig.3pq" <name>Basic Message Sequence Chart for ALTO Query on Behalf of Remote
title="Basic message sequence chart for ALTO query on behalf of remote Resource Consumer</name>
resource consumer"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
Peer Tracker w. ALTO cli. ALTO Server Peer Tracker w. ALTO cli. ALTO Server
--------+-------- --------+-------- --------+-------- --------+-------- --------+-------- --------+--------
| F1 Tracker query | | | F1 Tracker query | |
|======================>| | |======================>| |
| | F2 ALTO query | | | F2 ALTO query |
| |---------------------->| | |---------------------->|
| | F3 ALTO reply | | | F3 ALTO reply |
| |<----------------------| | |<----------------------|
| F4 Tracker reply | | | F4 Tracker reply | |
|<======================| | |<======================| |
| | | | | |
==== Application protocol (i.e., tracker-based P2P app protocol) ==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO protocol ---- ALTO protocol
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Note: the message sequences depicted in <xref <aside><t>Note: The message sequences depicted in Figures <xref target="
target="fig.rcq"/> and <xref target="fig.3pq"/> may occur fig.rcq"
format="counter"/> and <xref target="fig.3pq" format="counter"/> may
occur
both in the target-aware and the target-independent query both in the target-aware and the target-independent query
mode (c.f. <xref target="RFC6708"/>). In the mode (cf.&nbsp;<xref target="RFC6708" format="default"/>). In the
target-independent query mode no message exchange with the target-independent query mode, no message exchange with the
ALTO server might be needed after the tracker query, because ALTO server might be needed after the tracker query, because
the candidate resource providers could be evaluated using a the candidate resource providers could be evaluated using a
locally cached "map", which has been retrieved from the ALTO locally cached "map", which has been retrieved from the ALTO
server some time ago.</t> server some time ago.</t></aside>
</section>
</section> <section anchor="apx.alto_p2p_eval" numbered="true" toc="default">
<name>Evaluation</name>
<section anchor="apx.alto_p2p_eval" title="Evaluation"> <t>The problem with the first approach is that while the
<t>The problem with the first approach is, that while the
resource directory might know thousands of peers taking part resource directory might know thousands of peers taking part
in a swarm, the list returned to the resource consumer is in a swarm, the list returned to the resource consumer is
usually shortened for efficiency reasons. Therefore, the usually shortened for efficiency reasons. Therefore, the
"best" (in the sense of ALTO) potential resource providers "best" (in the sense of ALTO) potential resource providers
might not be contained in that list anymore, even before might not be contained in that list anymore, even before
ALTO can consider them.</t> ALTO can consider them.</t>
<t>For illustration, consider a simple model of a swarm, in
<t>For illustration, consider a simple model of a swarm, in
which all peers fall into one of only two categories: assume which all peers fall into one of only two categories: assume
that there are "good" ("good" in the sense of ALTO's that there are only "good" (in the sense of ALTO's
better-than-random peer selection, based on an arbitrary better-than-random peer selection, based on an arbitrary
desired rating criterion) and "bad' peers only. Having more desired rating criterion) and "bad" peers. Having more
different categories makes the maths more complex but does different categories makes the math more complex but does
not change anything to the basic outcome of this analysis. not change anything about the basic outcome of this analysis.
Assume that the swarm has a total number of N peers, out of Assume that the swarm has a total number of N peers, out of
which are M "good" and N-M "bad" peers, which are all known 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 to the tracker. A new peer wants to join the swarm and
therefore asks the tracker for a list of peers.</t> therefore asks the tracker for a list of peers.</t>
<t>If, according to the first approach, the tracker randomly
<t>If, according to the first approach, the tracker randomly
picks n peers from the N known peers, the result can be picks n peers from the N known peers, the result can be
described with the hypergeometric distribution. The described with the hypergeometric distribution. The
probability that the tracker reply contains exactly k "good" probability that the tracker reply contains exactly k "good"
peers (and n-k "bad" peers) is:</t> peers (and n-k "bad" peers) is:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t><figure><artwork><![CDATA[
/ M \ / N - M \ / M \ / N - M \
\ k / \ n - k / \ k / \ n - k /
P(X=k) = --------------------- P(X=k) = ---------------------
/ N \ / N \
\ n / \ n /
/ n \ n! / n \ n!
with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1 with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1
k! (n-k)! k! (n-k)!
]]></artwork>
]]></artwork></figure></t> <t>The probability that the reply contains at most k "good"
peers is: P(X&lt;=k) = P(X=0) + P(X=1) + .. + P&wj;(X=k).</t>
<t>The probability that the reply contains at most k "good" <t>For example, consider a swarm with N=10,000 peers known
peers is: P(X&lt;=k)=P(X=0)+P(X=1)+..+P(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 to the tracker, out of which M=100 are "good" peers. If the
tracker randomly selects n=100 peers, the formula yields for tracker randomly selects n=100 peers, the formula yields for
the reply: P(X=0)=36%, P(X&lt;=4)=99%. That is, with a the reply: P&wj;(X=0)=36%, P(X&lt;=4)=99%. That is, with a
probability of approx. 36% this list does not contain a probability of approximately 36%, this list does not contain a
single "good" peer, and with 99% probability there are only single "good" peer, and with 99% probability, there are only
four or less of the "good" peers on the list. Processing four or fewer of the "good" peers on the list. Processing
this list with the guiding ALTO information will ensure that this list with the guiding ALTO information will ensure that
the few favorable peers are ranked to the top of the list; the few favorable peers are ranked to the top of the list;
however, the benefit is rather limited as the number of however, the benefit is rather limited as the number of
favorable peers in the list is just too small.</t> favorable peers in the list is just too small.</t>
<t>Much better traffic optimization could be achieved if the
<t>Much better traffic optimization could be achieved if the tracker would evaluate all known peers using ALTO and
tracker would evaluate all known peers using ALTO, and
return a list of 100 peers afterwards. This list would then return a list of 100 peers afterwards. This list would then
include a significantly higher fraction of "good" include a significantly higher fraction of "good"
peers. (Note, that if the tracker returned "good" peers peers. (Note that if the tracker returned "good" peers
only, there might be a risk that the swarm might disconnect only, there might be a risk that the swarm might disconnect
and split into several disjunct partitions. However, and split into several disjunct partitions. However,
finding the right mix of ALTO-biased and random peer finding the right mix of ALTO-biased and random peer
selection is out of the scope of this document.) </t> selection is out of the scope of this document.) </t>
<t>Therefore, from an overall optimization perspective, the
<t>Therefore, from an overall optimization perspective, the
second scenario with the ALTO client embedded in the second scenario with the ALTO client embedded in the
resource directory is advantageous, because it is ensured resource directory is advantageous, because it is ensured
that the addresses of the "best" resource providers are that the addresses of the "best" resource providers are
actually delivered to the resource consumer. An actually delivered to the resource consumer. An
architectural implication of this insight is that the ALTO architectural implication of this insight is that the ALTO
server discovery procedures must support ALTO queries on server discovery procedures must support ALTO queries on
behalf of remote resource consumers. behalf of remote resource consumers.
That is, as the tracker issues ALTO queries on That is, as the tracker issues ALTO queries on
behalf of the peer which contacted the tracker, the tracker behalf of the peer that contacted the tracker, the tracker
must be able to discover an ALTO server that can give must be able to discover an ALTO server that can give
guidance suitable for that respective peer. guidance suitable for that peer.
This task can be solved using the ALTO Cross-Domain Server This task can be solved using the ALTO Cross-Domain Server
Discovery Procedure. Discovery Procedure.
</t> </t>
<t/>
<!-- force a page break --> </section>
<t><vspace blankLines="99"/></t> <section anchor="apx.alto_p2p_example" numbered="true" toc="default">
</section> <name>Example</name>
<t>This section provides a complete example of the
<section anchor="apx.alto_p2p_example" title="Example">
<t>This section provides a complete example of the
ALTO Cross-Domain Server Discovery Procedure in a tracker-based ALTO Cross-Domain Server Discovery Procedure in a tracker-based
peer-to-peer scenario.</t> peer-to-peer scenario.</t>
<t>The example is based on the network topology shown in
<t>The example is based on the network topology shown in <xref target="fig.example_network_topology" format="default"/>.
<xref target="fig.example_network_topology"/>. Five access networks -- Networks a, b, c, x, and t -- are
Five access networks - Networks a, b, c, x, and t - are
operated by five different network operators. They are operated by five different network operators. They are
interconnected by a backbone structure. interconnected by a backbone structure.
Each network operator Each network operator
runs an ALTO server in their network, i.e., ALTO_SRV_A, runs an ALTO server in their network -- i.e., ALTO_SRV_A,
ALTO_SRV_B, ALTO_SRV_C, ALTO_SRV_X, and ALTO_SRV_T, ALTO_SRV_B, ALTO_SRV_C, ALTO_SRV_X, and ALTO_SRV_T,
respectively. respectively.
<figure anchor="fig.example_network_topology" </t>
title="Example network topology"> <figure anchor="fig.example_network_topology">
<artwork><![CDATA[ <name>Example Network Topology</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
_____ __ _____ __ _____ __ _____ __ _____ __ _____ __
__( )__( )_ __( )__( )_ __( )__( )_ __( )__( )_ __( )__( )_ __( )__( )_
( Network a ) ( Network b ) ( Network c ) ( Network a ) ( Network b ) ( Network c )
( Res. Provider A ) ( Res. Provider B ) ( Res. Provider C ) ( Res. Provider A ) ( Res. Provider B ) ( Res. Provider C )
(__ ALTO_SRV_A __) (__ ALTO_SRV_B __) (__ ALTO_SRV_C __) (__ ALTO_SRV_A __) (__ ALTO_SRV_B __) (__ ALTO_SRV_C __)
(___)--(____) \ (___)--(____) / (___)--(____) (___)--(____) \ (___)--(____) / (___)--(____)
\ / / \ / /
---+---------+-----------------+---- ---+---------+-----------------+----
( Backbone ) ( Backbone )
------------+------------------+---- ------------+------------------+----
_____ __/ _____ \__ _____ __/ _____ \__
__( )__( )_ __( )__( )_ __( )__( )_ __( )__( )_
( Network x ) ( Network t ) ( Network x ) ( Network t )
( Res. Consumer X ) (Resource Directory) ( Res. Consumer X ) (Resource Directory)
(_ ALTO_SRV_X __) (_ ALTO_SRV_T __) (_ ALTO_SRV_X __) (_ ALTO_SRV_T __)
(___)--(____) (___)--(____) (___)--(____) (___)--(____)
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>A new peer of a peer-to-peer application wants to join a
<t>A new peer of a peer-to-peer application wants to join a
specific swarm (overlay network), in order to access a specific specific swarm (overlay network), in order to access a specific
resource. This new peer will be called "Resource Consumer X" resource. This new peer will be called "Resource Consumer X",
in accordance to the terminology of <xref target="RFC6708"/> and it in accordance with the terminology of <xref target="RFC6708"
is format="default"/>, and is
located in Network x. It contacts the tracker ("Resource located in Network x. It contacts the tracker ("Resource
Directory"), which is located in Network t. The mechanism by which Directory"), which is located in Network t. The mechanism by which
the new peer discovers the tracker is out of the scope of this the new peer discovers the tracker is out of the scope of this
document. The tracker maintains a list of peers that take part document. The tracker maintains a list of peers that take part
in the overlay network, and hence it can determine that in the overlay network, and hence it can determine that
Resource Providers A, B, and C are candidate peers for Resource Providers A, B, and C are candidate peers for
Resource Consumer X.</t> Resource Consumer X.</t>
<t>As shown in the previous section, a tracker-side ALTO
<t>As shown in the previous section, a tracker-side ALTO optimization (cf.&nbsp;Figures <xref target="fig.tracker_alto_client
optimization (c.f.&nbsp;<xref target="fig.tracker_alto_client"/> "
and <xref target="fig.3pq"/>) format="counter"/>
and <xref target="fig.3pq" format="counter"/>)
is more efficient than a client-side optimization. is more efficient than a client-side optimization.
Consequently, the tracker wants to use the ALTO Endpoint Consequently, the tracker wants to use the ALTO Endpoint
Cost Service (ECS) to learn the routing costs between Cost Service (ECS) to learn the routing costs between
X and A, X and B, as well as X and C, in order to sort X and A, X and B, and X and C, in order to sort
A, B, and C by their respective routing costs to X.</t> A, B, and C by their respective routing costs to X.</t>
<t>In theory, there are many options for how the
<t>In theory, there are many options how the
ALTO Cross-Domain Server Discovery Procedure could be used. ALTO Cross-Domain Server Discovery Procedure could be used.
For example, For example,
the tracker could do the following steps: the tracker could do the following steps:
<figure><artwork><![CDATA[ </t>
<sourcecode type="pseudocode">
IRD_URIS_A = XDOMDISC(A,"ALTO:https") IRD_URIS_A = XDOMDISC(A,"ALTO:https")
COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_A COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_A
IRD_URIS_B = XDOMDISC(B,"ALTO:https") IRD_URIS_B = XDOMDISC(B,"ALTO:https")
COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_B COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_B
IRD_URIS_C = XDOMDISC(C,"ALTO:https") IRD_URIS_C = XDOMDISC(C,"ALTO:https")
COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_C COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_C
]]></artwork></figure> </sourcecode>
Maybe, the ALTO Cross-Domain Server Discovery Procedure <t>
queries would yield in this scenario: IRD_URIS_A = ALTO_SRV_A,
In this scenario, the ALTO Cross-Domain Server Discovery Procedure
queries might yield: IRD_URIS_A = ALTO_SRV_A,
IRD_URIS_B = ALTO_SRV_B, and IRD_URIS_C = ALTO_SRV_C. IRD_URIS_B = ALTO_SRV_B, and IRD_URIS_C = ALTO_SRV_C.
That is, each ECS query would be sent to a different That is, each ECS query would be sent to a different
ALTO server. The problem with this approach is that we are ALTO server. The problem with this approach is that we are
not neccessarily able to not necessarily able to
compare COST_X_A, COST_X_B, and COST_X_C with each compare COST_X_A, COST_X_B, and COST_X_C with each
other. The specification of the routingcost metric other. The specification of the routingcost metric
mandates that "A lower value indicates a higher preference", mandates that "A lower value indicates a higher preference",
but "an ISP may internally compute routing cost using any method but "an ISP may internally compute routing cost using any method
that it chooses" that it chooses"
(see section 6.1.1.1. of <xref target="RFC7285"/>). (see <xref target="RFC7285" format="default"
sectionFormat="of" section="6.1.1.1"/>).
Thus, COST_X_A could be 10 (milliseconds round-trip time), while Thus, COST_X_A could be 10 (milliseconds round-trip time), while
COST_X_B could be 200 (kilometers great circle distance COST_X_B could be 200 (kilometers great circle distance
between the approximate geographic locations of the hosts) between the approximate geographic locations of the hosts)
and COST_X_C could and COST_X_C could
be 3 (router hops, corresponding to a decrease of the TTL field be 3 (router hops, corresponding to a decrease of the TTL field
in the IP header). Each of these metrics fulfills the in the IP header). Each of these metrics fulfills the
"lower value is more preferable" requirement on its own, "lower value is more preferable" requirement on its own,
but obviously, but they obviously cannot be compared with each other. Even if there
they cannot be compared with each other. Even if there was were
a reasonable formula to compare, for example, kilometers a reasonable formula to compare, for example, kilometers
with milliseconds, we could not use it, as the units of measurement with milliseconds, we could not use it, as the units of measurement
(or any other information about the computation method (or any other information about the computation method
for the routingcost) are for the routingcost) are
not sent along with the value in the ECS reply.</t> not sent along with the value in the ECS reply.</t>
<t>To avoid this problem, the tracker tries to send all
<t>To avoid this problem, the tracker tries to send all
ECS queries to the same ALTO server. As specified ECS queries to the same ALTO server. As specified
in <xref target="sec.ecs"/> of this document, case 2, it uses in <xref target="sec.ecs" format="default"/> of this document, Case
the IP address of Resource Consumer x as parameter to 2, it uses
the IP address of Resource Consumer x as a parameter of
the discovery procedure: the discovery procedure:
<figure><artwork><![CDATA[ </t>
<sourcecode type="pseudocode">
IRD_URIS_X = XDOMDISC(X,"ALTO:https") IRD_URIS_X = XDOMDISC(X,"ALTO:https")
COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_X COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_X
COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_X COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_X
COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_X COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_X
]]></artwork></figure> </sourcecode>
<t>
This strategy ensures that COST_X_A, COST_X_B, and COST_X_C This strategy ensures that COST_X_A, COST_X_B, and COST_X_C
can be compared with each other.</t> can be compared with each other.</t>
<t/>
<!-- force a page break --> <t>As discussed above, the tracker calls the ALTO Cross-Domain
<t><vspace blankLines="99"/></t>
<t>As discussed above, the tracker calls the ALTO Cross-Domain
Server Discovery Procedure with IP address X as a Server Discovery Procedure with IP address X as a
parameter. For the reminder of this example, we assume parameter. For the remainder of this example, we assume
that X = 2001:DB8:1:2:227:eff:fe6a:de42. Thus, the that X = 2001:DB8:1:2:227:eff:fe6a:de42. Thus, the
procedure call is <vspace blankLines="1"/> procedure call is
IRD_URIS_X = XDOMDISC(2001:DB8:1:2:227:eff:fe6a:de42,"ALTO:https"). IRD_URIS_X = XDOMDISC(2001:DB8:1:2:227:eff:fe6a:de42,"ALTO:https").
</t> </t>
<t>The first parameter, 2001:DB8:1:2:227:eff:fe6a:de42, is a
<t>The first parameter 2001:DB8:1:2:227:eff:fe6a:de42 is a
single IPv6 address. Thus, we get AT = IPv6, single IPv6 address. Thus, we get AT = IPv6,
A = 2001:DB8:1:2:227:eff:fe6a:de42, L = 128, A = 2001:DB8:1:2:227:eff:fe6a:de42, L = 128,
and SP = "ALTO:https". and SP = "ALTO:https".
</t> </t>
<t>The procedure constructs
(see Step 1 in <xref target="sec.3pdisc-spec-step1"
format="default"/>)
</t>
<t>The procedure constructs <sourcecode type="pseudocode">
(see Step 1 in <xref target="sec.3pdisc-spec-step1"/>)<vspace/> R128 = "2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.2.0.0.0.1.0.0.0.
R128 = "2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.2.0.0.0.1.0.0.0. 8.B.D.0.1.0.0.2.IP6.ARPA."
8.B.D.0.1.0.0.2.IP6.ARPA.", as well as </sourcecode>
(see Step 2 in <xref target="sec.3pdisc-spec-step2"/>)<vspace/> <t>as well as the following
R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",<vspace/> (see Step 2 in <xref target="sec.3pdisc-spec-step1"
R56 = "0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",<vspace/> format="default"/>):
R48 = "1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",<vspace/> </t>
R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and<vspace/> <sourcecode type="pseudocode">
R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.". R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
</t> R56 = "0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R48 = "1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R32 = "8.B.D.0.1.0.0.2.IP6.ARPA."
</sourcecode>
<t>In order to illustrate the third step of the <t>In order to illustrate the third step of the
ALTO Cross-Domain Server Discovery Procedure, we use ALTO Cross-Domain Server Discovery Procedure, we use
the "dig" (domain information groper) DNS lookup utility the "dig" (domain information groper) DNS lookup utility
that is available for many operating systems (e.g., Linux). that is available for many operating systems (e.g., Linux).
A real implementation of the ALTO Cross-Domain Server Discovery A real implementation of the ALTO Cross-Domain Server Discovery
Procedure would not be based on the "dig" utility, but use Procedure would not be based on the "dig" utility but instead would
appropriate libraries and/or operating system APIs. use
appropriate libraries and/or operating-system APIs.
Please note that the following steps have been performed in a Please note that the following steps have been performed in a
controlled lab environment with a appropriately configured controlled lab environment with an appropriately configured
name server. A suitable DNS configuration will be needed name server. A suitable DNS configuration will be needed
to reproduce these results. Please also note that the rather to reproduce these results. Please also note that the rather
verbose output of the "dig" tool has been shortened to the verbose output of the "dig" tool has been shortened to the
relevant lines.</t> relevant lines.</t>
<t>Since AT = IPv6 and L = 128, in the table given
<t>Since AT = IPv6 and L = 128, in the table given in <xref target="sec.3pdisc-spec-step3" format="default"/>, the sixt
in <xref target="sec.3pdisc-spec-step3"/>, the sixth row h row
(not counting the column headers) applies.</t> (not counting the column headers) applies.</t>
<t>As mandated by the third column, we start with a lookup
<t>As mandated by the third column, we start with a lookup
of R128, looking for NAPTR resource records: 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.\ | user@labpc:~$ dig -tNAPTR 2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.\
| 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. | 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| |
| ;; Got answer: | ;; Got answer:
| ;; ->>HEADER<&lt;- opcode: QUERY, status: NXDOMAIN, id: 26553 | ;; ->>HEADER<&lt;- opcode: QUERY, status: NXDOMAIN, id: 26553
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0
]]></artwork></figure> </artwork>
<t>
The domain name R128 does not exist (status: NXDOMAIN), so we The domain name R128 does not exist (status: NXDOMAIN), so we
cannot get a useful result. Therefore, we continue with the cannot get a useful result. Therefore, we continue with the
fourth column of the table and do a lookup of R64: 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. | user@labpc:~$ dig -tNAPTR 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| |
| ;; Got answer: | ;; Got answer:
| ;; ->>HEADER<&lt;- opcode: QUERY, status: NOERROR, id: 33193 | ;; ->>HEADER<&lt;- opcode: QUERY, status: NOERROR, id: 33193
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0
]]></artwork></figure> </artwork>
<t>
The domain name R64 could be looked up (status: NOERROR), The domain name R64 could be looked up (status: NOERROR),
but there are no NAPTR resource records associated with it (ANSWER: but there are no NAPTR resource records associated with it (ANSWER:
0). Maybe, there are some other resource records such as 0). There may be some other resource records such as
PTR, NS, or SOA, but we are not interested in them. PTR, NS, or SOA, but we are not interested in them.
Thus, we do not get a useful result and we continue with Thus, we do not get a useful result, and we continue with
looking up R56: 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. | user@labpc:~$ dig -tNAPTR 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| |
| ;; Got answer: | ;; Got answer:
| ;; ->>HEADER<&lt;- opcode: QUERY, status: NOERROR, id: 35966 | ;; ->>HEADER<&lt;- opcode: QUERY, status: NOERROR, id: 35966
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
| |
| ;; ANSWER SECTION: | ;; ANSWER SECTION:
| 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u" | 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
| "LIS:HELD" "!.*!https://lis1.example.org:4802/?c=ex!" . | "LIS:HELD" "!.*!https://lis1.example.org:4802/?c=ex!" .
| 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 20 "u" | 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 20 "u"
| "LIS:HELD" "!.*!https://lis2.example.org:4802/?c=ex!" . | "LIS:HELD" "!.*!https://lis2.example.org:4802/?c=ex!" .
]]></artwork></figure> </artwork>
<t>
The domain name R56 could be looked up and there are The domain name R56 could be looked up, and there are
NAPTR resource records associated with it. However, NAPTR resource records associated with it. However,
each of these records has a service parameter that each of these records has a service parameter that
does not match our SP = "ALTO:https" does not match our SP = "ALTO:https"
(see <xref target="RFC7216"/> for "LIS:HELD"), (see <xref target="RFC7216" format="default"/> for "LIS:HELD"),
and therefore, we have to ignore them. and therefore we have to ignore them.
Consequently, we still do not have a useful result and Consequently, we still do not have a useful result and
continue with a lookup of R48: 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. | user@labpc:~$ dig -tNAPTR 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| |
| ;; Got answer: | ;; Got answer:
| ;; ->>HEADER<&lt;- opcode: QUERY, status: NOERROR, id: 50459 | ;; ->>HEADER<&lt;- opcode: QUERY, status: NOERROR, id: 50459
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
| |
| ;; ANSWER SECTION: | ;; ANSWER SECTION:
| 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u" | 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!" . | "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" | 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!" . | "LIS:HELD" "!.*!https://lis.example.net:4802/?c=ex!" .
]]></artwork></figure> </artwork>
<t>
This lookup yields two NAPTR resource records. We have This lookup yields two NAPTR resource records. We have
to ignore the second one as its service parameter does to ignore the second one as its service parameter does
not match our SP, but the first NAPTR resource record has not match our SP, but the first NAPTR resource record has
a matching service parameter. Therefore, the procedure a matching service parameter. Therefore, the procedure
terminates successfully and the final outcome is: terminates successfully and the final outcome is:
IRD_URIS_X = "https://alto1.example.net/ird". IRD_URIS_X = "https://alto1.example.net/ird".
</t> </t>
<t>The ALTO client that is embedded in the tracker will
<t>The ALTO client that is embedded in the tracker will
access the ALTO Information Resource Directory access the ALTO Information Resource Directory
(IRD, see Section 9 of <xref target="RFC7285"/>) (IRD, see <xref target="RFC7285" format="default"
sectionFormat="of" section="9"/>)
at this URI, look for the Endpoint Cost Service at this URI, look for the Endpoint Cost Service
(ECS, see Section 11.5 of <xref target="RFC7285"/>), (ECS, see <xref target="RFC7285" format="default"
sectionFormat="of" section="11.5"/>),
and query the ECS for the costs between A and X, and query the ECS for the costs between A and X,
B and X, as well as C and X, before returning B and X, and C and X, before returning
an ALTO-optimized list of candidate resource providers an ALTO-optimized list of candidate resource providers
to resource consumer X.</t> to resource consumer X.</t>
</section> </section>
</section> </section>
<section title="Contributors List and Acknowledgments"> <!-- [rfced] FYI, we have changed the title from "Contributors List and
Acknowledgements" to simply "Acknowledgements", as those are typically
<t>The initial version of this document was co-authored by separate sections. Please let us know if you'd like to move text into a
Marco Tomsu (Alcatel-Lucent).</t> "Contributors" section.
-->
<t>This document borrows some text from <xref target="RFC7286"/>, <section numbered="false" toc="default">
as historically, it has been part of the draft that <name>Acknowledgments</name>
<t>The initial draft version of this document was co-authored by
<contact fullname="Marco Tomsu"/> (Alcatel-Lucent).</t>
<t>This document borrows some text from <xref target="RFC7286" format="def
ault"/>,
as historically, it was part of the draft that
eventually became said RFC. eventually became said RFC.
Special thanks to Michael Scharf and Nico Schwan.</t> Special thanks to <contact fullname="Michael Scharf"/> and <contact full
name="Nico Schwan"/>.</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 334 change blocks. 
1203 lines changed or deleted 1328 lines changed or added

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