draft-ietf-alto-xdom-disc-03.txt   draft-ietf-alto-xdom-disc-04.txt 
ALTO S. Kiesel ALTO S. Kiesel
Internet-Draft University of Stuttgart Internet-Draft University of Stuttgart
Intended status: Standards Track M. Stiemerling Intended status: Standards Track M. Stiemerling
Expires: April 12, 2019 H-DA Expires: May 18, 2019 H-DA
October 9, 2018 November 14, 2018
Application Layer Traffic Optimization (ALTO) Cross-Domain Server Application Layer Traffic Optimization (ALTO) Cross-Domain Server
Discovery Discovery
draft-ietf-alto-xdom-disc-03 draft-ietf-alto-xdom-disc-04
Abstract Abstract
The goal of Application-Layer Traffic Optimization (ALTO) is to The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications that have to select one or several provide guidance to applications that have to select one or several
hosts from a set of candidates capable of providing a desired hosts from a set of candidates capable of providing a desired
resource. ALTO is realized by a client-server protocol. Before an resource. ALTO is realized by a client-server protocol. Before an
ALTO client can ask for guidance it needs to discover one or more ALTO client can ask for guidance it needs to discover one or more
ALTO servers that can provide suitable guidance. ALTO servers that can provide suitable guidance.
In some deployment scenarios, in particular if the information about In some deployment scenarios, in particular if the information about
the network topology is partitioned and distributed over several ALTO the network topology is partitioned and distributed over several ALTO
servers, it may be needed to discover an ALTO server outside of the servers, it may be needed to discover an ALTO server outside of the
own network domain, in order to get appropriate guidance. This own network domain, in order to get appropriate guidance. This
document details applicable scenarios, itemizes requirements, and document details applicable scenarios, itemizes requirements, and
specifies a procedure for ALTO cross-domain server discovery. specifies a procedure for ALTO cross-domain server discovery.
Technically, the procedure specified in this document takes one Technically, the procedure specified in this document takes one
IP address or prefix and a U-NAPTR Service Parameter (i.e., "ALTO: IP address or prefix and a U-NAPTR Service Parameter (typically,
http" or "ALTO:https") as parameters. It performs DNS lookups (for "ALTO:https") as parameters. It performs DNS lookups (for NAPTR
NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and resource records in the in-addr.arpa. or ip6.arpa. tree) and returns
returns one or more URI(s) of information resources related to that one or more URI(s) of information resources related to that IP
IP address or prefix. address or prefix.
Terminology and Requirements Language Terminology and Requirements Language
This document makes use of the ALTO terminology defined in RFC 5693 This document makes use of the ALTO terminology defined in RFC 5693
[RFC5693]. [RFC5693].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
skipping to change at page 2, line 31 skipping to change at page 2, line 31
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 12, 2019. This Internet-Draft will expire on May 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 12 skipping to change at page 3, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview on the ALTO Cross-Domain Server Discovery 2. Overview on the ALTO Cross-Domain Server Discovery
Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. ALTO Cross-Domain Server Discovery Procedure Specification . . 6 3. ALTO Cross-Domain Server Discovery Procedure Specification . . 6
3.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup . . . . 7 3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup . . . . 6
3.3. Step 2: Prepare Shortened Domain Names . . . . . . . . . . 7 3.3. Step 2: Prepare Shortened Domain Names . . . . . . . . . . 7
3.4. Step 3: Perform DNS U-NAPTR lookups . . . . . . . . . . . 8 3.4. Step 3: Perform DNS U-NAPTR lookups . . . . . . . . . . . 8
4. Using the ALTO Protocol with Cross-Domain Server Discovery . . 9 3.5. Error Handling . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Network and Cost Map Service . . . . . . . . . . . . . . . 9 4. Using the ALTO Protocol with Cross-Domain Server Discovery . . 10
4.2. Map-Filtering Service . . . . . . . . . . . . . . . . . . 10 4.1. Network and Cost Map Service . . . . . . . . . . . . . . . 10
4.3. Endpoint Property Service . . . . . . . . . . . . . . . . 10 4.2. Map-Filtering Service . . . . . . . . . . . . . . . . . . 11
4.3. Endpoint Property Service . . . . . . . . . . . . . . . . 11
4.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 11 4.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 11
4.5. Summary and Further Extensions . . . . . . . . . . . . . . 12 4.5. Summary and Further Extensions . . . . . . . . . . . . . . 13
5. Implementation, Deployment, and Operational Considerations . . 13 5. Implementation, Deployment, and Operational Considerations . . 14
5.1. Considerations for ALTO Clients . . . . . . . . . . . . . 13 5.1. Considerations for ALTO Clients . . . . . . . . . . . . . 14
5.2. Deployment Considerations for Network Operators . . . . . 14 5.2. Deployment Considerations for Network Operators . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 15 6.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 16
6.2. Availability of the ALTO Server Discovery Procedure . . . 16 6.2. Availability of the ALTO Server Discovery Procedure . . . 17
6.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 17 6.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 18
6.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 17 6.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Multiple Information Sources and Partitioned Appendix A. Solution Approaches for Partitioned ALTO Knowledge . 22
Knowledge . . . . . . . . . . . . . . . . . . . . . . 21 A.1. Classification of Solution Approaches . . . . . . . . . . 22
A.1. Classification of Solution Approaches . . . . . . . . . . 21 A.2. Discussion of Solution Approaches . . . . . . . . . . . . 23
A.2. Discussion of Solution Approaches . . . . . . . . . . . . 22 A.3. The Need for Cross-Domain ALTO Server Discovery . . . . . 23
A.3. The Need for Cross-Domain ALTO Server Discovery . . . . . 22 A.4. Our Solution Approach . . . . . . . . . . . . . . . . . . 24
A.4. Our Solution Approach . . . . . . . . . . . . . . . . . . 23 A.5. Relation to the ALTO Requirements . . . . . . . . . . . . 24
A.5. Relation to the ALTO Requirements . . . . . . . . . . . . 23
Appendix B. Requirements for ALTO Cross-Domain Server Appendix B. Requirements for ALTO Cross-Domain Server
Discovery . . . . . . . . . . . . . . . . . . . . . . 24 Discovery . . . . . . . . . . . . . . . . . . . . . . 25
B.1. Discovery Client Application Programming Interface . . . . 24 B.1. Discovery Client Application Programming Interface . . . . 25
B.2. Data Storage and Authority Requirements . . . . . . . . . 24 B.2. Data Storage and Authority Requirements . . . . . . . . . 25
B.3. Cross-Domain Operations Requirements . . . . . . . . . . . 24 B.3. Cross-Domain Operations Requirements . . . . . . . . . . . 25
B.4. Protocol Requirements . . . . . . . . . . . . . . . . . . 25 B.4. Protocol Requirements . . . . . . . . . . . . . . . . . . 26
B.5. Further Requirements . . . . . . . . . . . . . . . . . . . 25 B.5. Further Requirements . . . . . . . . . . . . . . . . . . . 26
Appendix C. ALTO and Tracker-based Peer-to-Peer Applications . . 26 Appendix C. ALTO and Tracker-based Peer-to-Peer Applications . . 27
C.1. Architectural Options . . . . . . . . . . . . . . . . . . 26 C.1. Architectural Options . . . . . . . . . . . . . . . . . . 27
C.2. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 29 C.2. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 30
C.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 31 C.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix D. Contributors List and Acknowledgments . . . . . . . . 36 Appendix D. Contributors List and Acknowledgments . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
The goal of Application-Layer Traffic Optimization (ALTO) is to The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications that have to select one or several provide guidance to applications that have to select one or several
hosts from a set of candidates capable of providing a desired hosts from a set of candidates capable of providing a desired
resource [RFC5693]. ALTO is realized by an HTTP-based client-server resource [RFC5693]. ALTO is realized by an HTTP-based client-server
protocol [RFC7285], which can be used in various scenarios [RFC7971]. protocol [RFC7285], which can be used in various scenarios [RFC7971].
The ALTO base protocol document [RFC7285] specifies the communication The ALTO base protocol document [RFC7285] specifies the communication
skipping to change at page 4, line 39 skipping to change at page 4, line 39
information to the client. One such scenario is detailed in information to the client. One such scenario is detailed in
Appendix C. Several solution approaches, such as redirecting a Appendix C. Several solution approaches, such as redirecting a
client to a server that has more accurate information or forwarding client to a server that has more accurate information or forwarding
the request to it on behalf of the client, have been proposed and the request to it on behalf of the client, have been proposed and
analyzed (see Appendix A), but none has been specified so far. analyzed (see Appendix A), but none has been specified so far.
Section 3 of this document specifies the "ALTO Cross-Domain Server Section 3 of this document specifies the "ALTO Cross-Domain Server
Discovery Procedure" for client-side usage in these scenarios. An Discovery Procedure" for client-side usage in these scenarios. An
ALTO client that wants to send an ALTO query related to a specific IP ALTO client that wants to send an ALTO query related to a specific IP
address or prefix X, may call this procedure with X as a paramenter. address or prefix X, may call this procedure with X as a paramenter.
It will use DNS lookups to find the IRD URI(s) of one ore more ALTO It will use Domain Name System (DNS) lookups to find of one ore more
server(s) that can provide a competent answer. The above wording ALTO servers that can provide a competent answer. The above wording
"related to" was intentionally kept somewhat vague, as the exact "related to" was intentionally kept somewhat vague, as the exact
semantics depends on the ALTO service to be used; see Section 4. semantics depends on the ALTO service to be used; see Section 4.
Those who are in control of the "reverse DNS" for a given IP address Those who are in control of the "reverse DNS" for a given IP address
or prefix (i.e., the corresponding subdomain of in-addr.arpa. or or prefix (i.e., the corresponding subdomain of in-addr.arpa. or
ip6.arpa.) - typically an Internet Service Provider (ISP), a ip6.arpa.) - typically an Internet Service Provider (ISP), a
corporate IT department, or a university's computing center - may add corporate IT department, or a university's computing center - may add
resource records to the DNS that point to one or more relevant ALTO resource records to the DNS that point to one or more relevant ALTO
server(s). In many cases, it may be an ALTO server run by that ISP server(s). In many cases, it may be an ALTO server run by that ISP
or IT department, as they naturally have good insight into routing or IT department, as they naturally have good insight into routing
skipping to change at page 5, line 14 skipping to change at page 5, line 14
2. Overview on the ALTO Cross-Domain Server Discovery Procedure 2. Overview on the ALTO Cross-Domain Server Discovery Procedure
This procedure was inspired by the "Location Information Server (LIS) This procedure was inspired by the "Location Information Server (LIS)
Discovery Using IP Addresses and Reverse DNS" [RFC7216] and re-uses Discovery Using IP Addresses and Reverse DNS" [RFC7216] and re-uses
parts of the basic ALTO Server Discovery Procedure [RFC7286]. parts of the basic ALTO Server Discovery Procedure [RFC7286].
The basic idea is to use the Domain Name System (DNS), more The basic idea is to use the Domain Name System (DNS), more
specifically the "in-addr.arpa." or "ip6.arpa." trees, which are specifically the "in-addr.arpa." or "ip6.arpa." trees, which are
mostly used for "reverse mapping" of IP addresses to host names by mostly used for "reverse mapping" of IP addresses to host names by
means of PTR resource records. There, U-NAPTR resource records means of PTR resource records. There, URI-enabled Naming Authority
[RFC4848], which allow the mapping of domain names to URIs, are Pointer (U-NAPTR) resource records [RFC4848], which allow the mapping
installed as needed. Thereby, it is possible to store a mapping from of domain names to Uniform Resource Identifiers (URIs), are installed
an IP address or prefix to one or more ALTO server URIs in the DNS. as needed. Thereby, it is possible to store a mapping from an IP
address or prefix to one or more ALTO server URIs in the DNS.
The ALTO Cross-Domain Server Discovery Procedure is called with one The ALTO Cross-Domain Server Discovery Procedure is called with one
IP address or prefix X and a U-NAPTR Service Parameter [RFC4848] SP IP address or prefix and a U-NAPTR Service Parameter [RFC4848] as
as parameters. parameters.
The service parameter SP SHOULD always be set to "ALTO:https". The service parameter SHOULD always be set to "ALTO:https". However,
However, other parameter values MAY be used in some scenarios, e.g., 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 or transmission for debugging purposes, or other application protocol or
service tags if applicable. service tags if applicable.
The procedure performs DNS lookups and returns one or more URI(s) of The procedure performs DNS lookups and returns one or more URI(s) of
information resources related to the IP address or prefix X, usually information resources related to said IP address or prefix, usually
the URI(s) of one or more ALTO Information Resource Directory (IRD, the URI(s) of one or more ALTO Information Resource Directory (IRD,
see Section 9 of [RFC7285]). The U-NAPTR records also provide see Section 9 of [RFC7285]). The U-NAPTR records also provide
preference values, which should be considered if more than one URI is preference values, which should be considered if more than one URI is
returned. returned.
For the remainder of the document, we use the notation:
IRD_URIS_X = XDOMDISC(X,"ALTO:https")
The discovery procedure sequentially tries two different lookup The discovery procedure sequentially tries two different lookup
strategies: First, an ALTO-specific U-NAPTR record is searched in the strategies: First, an ALTO-specific U-NAPTR record is searched in the
"reverse tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa. "reverse tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa.
corresponding to the given IP address or prefix. If this lookup does corresponding to the given IP address or prefix. If this lookup does
not yield a usable result, further lookups with truncated domain not yield a usable result, the procedure tries further lookups with
names may be tried. The goal is to allow deployment scenarios that truncated domain names, which correspond to shorter prefix lengths.
require fine-grained discovery on a per-IP basis, as well as large- The goal is to allow deployment scenarios that require fine-grained
scale scenarios where discovery is to be enabled for a large number discovery on a per-IP basis, as well as large-scale scenarios where
of IP addresses with a small number of additional DNS resource discovery is to be enabled for a large number of IP addresses with a
records. small number of additional DNS resource records.
3. ALTO Cross-Domain Server Discovery Procedure Specification 3. ALTO Cross-Domain Server Discovery Procedure Specification
3.1. Interface 3.1. Interface
The procedure specified in this document takes two parameters, X and The procedure specified in this document takes two parameters, X and
SP, where X is an IP address or prefix and SP is a U-NAPTR Service SP, where X is an IP address or prefix and SP is a U-NAPTR Service
Parameter. Parameter.
The parameter X may be an IPv4 or an IPv6 address or prefix in CIDR The parameter X may be an IPv4 or an IPv6 address or prefix in CIDR
notation (see [RFC4632] for the IPv4 CIDR notation and [RFC4291] for notation (see [RFC4632] for the IPv4 CIDR notation and [RFC4291] for
IPv6). Consequently, the address type AT is either "IPv4" or "IPv6". IPv6). Consequently, the address type AT is either "IPv4" or "IPv6".
In both cases, X consists of an IP address A and a prefix length L. In both cases, X consists of an IP address A and a prefix length L.
For AT="IPv4", it holds: 0 <= L <= 32 and for AT="IPv6", it holds: For AT=IPv4, it holds: 0 <= L <= 32 and for AT=IPv6, it holds:
0 <= L <= 128. 0 <= L <= 128.
For example, for X=198.51.100.0/24, we get AT="IPv4", A=198.51.100.0 For example, for X=198.51.100.0/24, we get AT=IPv4, A=198.51.100.0
and L=24. Similarly, for X=2001:0DB8::20/128, we get AT="IPv6", and L=24. Similarly, for X=2001:0DB8::20/128, we get AT=IPv6,
A=2001:0DB8::20 and L=128. A=2001:0DB8::20 and L=128.
In the intended usage scenario, the procedure SHOULD always be called In the intended usage scenario, the procedure SHOULD always be called
with the parameter SP set to "ALTO:https". However, for general with the parameter SP set to "ALTO:https". However, for general
applicabiliy and in order to support future extensions, the procedure applicabiliy and in order to support future extensions, the procedure
MUST support being called with any valid U-NAPTR Service Parameter MUST support being called with any valid U-NAPTR Service Parameter
(see Section 4.5. of [RFC4848] for the syntax of U-NAPTR Service (see Section 4.5. of [RFC4848] for the syntax of U-NAPTR Service
Parameters and Section 5. of the same document for information about Parameters and Section 5. of the same document for information about
the IANA registries). the IANA registries).
The procedure performs DNS lookups and returns one or more URI(s) of The procedure performs DNS lookups and returns one or more URI(s) of
information resources related to that IP address or prefix, usually information resources related to that IP address or prefix, usually
the URI(s) of one or more ALTO Information Resource Directory (IRD, the URI(s) of one or more ALTO Information Resource Directory (IRD,
see Section 9 of [RFC7285]). For each URI, it also returns order and see Section 9 of [RFC7285]). For each URI, it also returns order and
preference values (see Section 4.1 of [RFC3403]), which should be preference values (see Section 4.1 of [RFC3403]), which should be
considered if more than one URI is returned. considered if more than one URI is returned.
The procedure may fail for various reasons, including syntactically During execution of this procedure, various error conditions may
invalid parameters, unsupported parameter values, temporary or occur and have to be reported to the caller; see Section 3.5.
permanent errors when performing DNS lookups, etc. These error
conditions have to be reported to the caller in an appropriate way.
For the remainder of the document, we use the following notation for For the remainder of the document, we use the following notation for
calling the ALTO Cross-Domain Server Discovery Procedure: calling the ALTO Cross-Domain Server Discovery Procedure:
IRD_URIS_X = XDOMDISC(X,"ALTO:https") IRD_URIS_X = XDOMDISC(X,"ALTO:https")
3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup 3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup
If A is an IPv4 address, a domain name R32 is constructed according First, the procedure checks the prefix length L for unsupported
to the rules specified in Section 3.5 of [RFC1035] and it is rooted values: If AT=IPv4 (i.e., if A is an IPv4 address) and L < 8, the
in the special domain "IN-ADDR.ARPA.". procedure aborts and indicates an "invalid prefix length" error to
the caller. Similarly, if AT=IPv6 and L < 32, the procedure aborts
and indicates an "invalid prefix length" error to the caller.
Otherwise, the procedure continues.
If AT=IPv4, a domain name R32 is constructed according to the rules
specified in Section 3.5 of [RFC1035] and it is rooted in the special
domain "IN-ADDR.ARPA.".
For example, A=198.51.100.3 yields R32="3.100.51.198.IN-ADDR.ARPA.". For example, A=198.51.100.3 yields R32="3.100.51.198.IN-ADDR.ARPA.".
If A is an IPv6 address, the domain name R128 is constructed If AT=IPv6, the domain name R128 is constructed according to the
according to the rules specified in Section 2.5 of [RFC3596] and the rules specified in Section 2.5 of [RFC3596] and the special domain
special domain "IP6.ARPA." is used. "IP6.ARPA." is used.
For example (note: a line break was added after the second line), For example (note: a line break was added after the second line),
A = 2001:0DB8::20 yields A = 2001:0DB8::20 yields
R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0. R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
1.0.0.2.IP6.ARPA." 1.0.0.2.IP6.ARPA."
3.3. Step 2: Prepare Shortened Domain Names 3.3. Step 2: Prepare Shortened Domain Names
For this step, an auxiliary function "skip" is defined as follows: For this step, an auxiliary function "skip" is defined as follows:
skip(str,n) will skip all characters in the string str, up to and skip(str,n) will skip all characters in the string str, up to and
including the n-th dot, and return the remaining part of str. For including the n-th dot, and return the remaining part of str. For
example, skip("foo.bar.baz.qux.quux.",2) will return "baz.qux.quux.". example, skip("foo.bar.baz.qux.quux.",2) will return "baz.qux.quux.".
If A is an IPv4 address, the following additional domain names are If AT=IPv4, the following additional domain names are generated from
generated from the result of the previous step: R24=skip(R32,1), the result of the previous step: R24=skip(R32,1), R16=skip(R32,2),
R16=skip(R32,2), and R8=skip(R32,3). Removing one label from a and R8=skip(R32,3). Removing one label from a domain name (i.e., one
domain name (i.e., one number of the "dotted quad notation") number of the "dotted quad notation") corresponds to shortening the
corresponds to shortening the prefix length by 8 bits. prefix length by 8 bits.
For example, R32="3.100.51.198.IN-ADDR.ARPA." yields For example, R32="3.100.51.198.IN-ADDR.ARPA." yields
R24="100.51.198.IN-ADDR.ARPA.", R16="51.198.IN-ADDR.ARPA.", and R24="100.51.198.IN-ADDR.ARPA.", R16="51.198.IN-ADDR.ARPA.", and
R8="198.IN-ADDR.ARPA.". R8="198.IN-ADDR.ARPA.".
If A is an IPv6 address, the following additional domain names are If AT=IPv6, the following additional domain names are generated from
generated from the result of the previous step: R64=skip(R128,16), the result of the previous step: R64=skip(R128,16),
R56=skip(R128,18), R48=skip(R128,20), and R32=skip(R128,24). R56=skip(R128,18), R48=skip(R128,20), and R32=skip(R128,24).
Removing one label from a domain name (i.e., one hex digit) Removing one label from a domain name (i.e., one hex digit)
corresponds to shortening the prefix length by 4 bits. corresponds to shortening the prefix length by 4 bits.
For example (note: a line break was added after the first line), For example (note: a line break was added after the first line),
R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0. R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
1.0.0.2.IP6.ARPA." yields 1.0.0.2.IP6.ARPA." yields
R64 = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R64 = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
R56 = "0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R56 = "0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
R48 = "0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and R48 = "0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and
R32 = "8.B.D.0.1.0.0.2.IP6.ARPA." R32 = "8.B.D.0.1.0.0.2.IP6.ARPA."
3.4. Step 3: Perform DNS U-NAPTR lookups 3.4. Step 3: Perform DNS U-NAPTR lookups
The address type of A and the prefix length are matched against the The address type of A and the prefix length are matched against the
first and the second column of the following table, respectively: first and the second column of the following table, respectively:
+------------+------------+------------+------------------------+ +------------+------------+------------+----------------------------+
| 1: Address | 2: Prefix | 3: MUST do | 4: SHOULD do further | | 1: Address | 2: Prefix | 3: MUST do | 4: SHOULD do further |
| Type AT | Length L | 1st lookup | lookups in that order | | Type AT | Length L | 1st lookup | lookups in that order |
+------------+------------+------------+------------------------+ +------------+------------+------------+----------------------------+
| IPv4 | 32 | R32 | R24, R16, R8 | | IPv4 | 32 | R32 | R24, R16, R8 |
| IPv4 | 24 .. 31 | R24 | R16, R8 | | IPv4 | 24 .. 31 | R24 | R16, R8 |
| IPv4 | 16 .. 23 | R16 | R8 | | IPv4 | 16 .. 23 | R16 | R8 |
| IPv4 | 8 .. 15 | R8 | (none) | | IPv4 | 8 .. 15 | R8 | (none) |
| IPv4 | 0 .. 7 | (none, procedure fails w/o result) | | IPv4 | 0 .. 7 | (none, abort: invalid prefix length L) |
+------------+------------+------------+------------------------+ +------------+------------+------------+----------------------------+
| IPv6 | 128 | R128 | R64, R56, R48, R32 | | IPv6 | 128 | R128 | R64, R56, R48, R32 |
| IPv6 | 64 (..127) | R64 | R56, R48, R32 | | IPv6 | 64 (..127) | R64 | R56, R48, R32 |
| IPv6 | 56 .. 63 | R56 | R48, R32 | | IPv6 | 56 .. 63 | R56 | R48, R32 |
| IPv6 | 48 .. 55 | R48 | R32 | | IPv6 | 48 .. 55 | R48 | R32 |
| IPv6 | 32 .. 47 | R32 | (none) | | IPv6 | 32 .. 47 | R32 | (none) |
| IPv6 | 0 .. 31 | (none, procedure fails w/o result) | | IPv6 | 0 .. 31 | (none, abort: invalid prefix length L) |
+------------+------------+------------+------------------------+ +------------+------------+------------+----------------------------+
Then, the domain name given in the 3rd column and the U-NAPTR Service Then, the domain name given in the 3rd column and the U-NAPTR Service
Parameter SP the procedure was called with (usually "ALTO:https") Parameter SP the procedure was called with (usually "ALTO:https")
MUST be used for an U-NAPTR [RFC4848] lookup, in order to obtain one MUST be used for an U-NAPTR [RFC4848] lookup, in order to obtain one
or more URIs (indicating protocol, host, and possibly path elements) or more URIs (indicating protocol, host, and possibly path elements)
for the ALTO server's Information Resource Directory (IRD). If such for the ALTO server's Information Resource Directory (IRD). If such
URI(s) can be found, the ALTO Cross-Domain Server Discovery Procedure URI(s) can be found, the ALTO Cross-Domain Server Discovery Procedure
returns that information to the caller and terminates successfully. returns that information to the caller and terminates successfully.
For example, the following two U-NAPTR resource records can be used For example, the following two U-NAPTR resource records can be used
skipping to change at page 8, line 51 skipping to change at page 8, line 51
100.51.198.IN-ADDR.ARPA. IN NAPTR 100 10 "u" "ALTO:https" 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://alto1.example.net/ird!" "" "!.*!https://alto1.example.net/ird!" ""
100.51.198.IN-ADDR.ARPA. IN NAPTR 100 20 "u" "ALTO:https" 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 20 "u" "ALTO:https"
"!.*!https://alto2.example.net/ird!" "" "!.*!https://alto2.example.net/ird!" ""
If no matching U-NAPTR records can be found, the procedure SHOULD try If no matching U-NAPTR records can be found, the procedure SHOULD try
further lookups, using the domain names from the fourth column in the further lookups, using the domain names from the fourth column in the
indicated order, until one lookup succeeds. If no IRD URI could be indicated order, until one lookup succeeds. If no IRD URI could be
found after looking up all domain names from the 3rd and 4th column, found after looking up all domain names from the 3rd and 4th column,
the procedure terminates unsuccessfully, without producing a result. the procedure terminates unsuccessfully, returning an empty URI list.
3.5. Error Handling
The ALTO Cross-Domain Server Discovery Procedure may fail for several
reasons.
If the procedure is called with syntactically invalid parameters or
unsupported parameter values (in particular the prefix length L, see
Section 3.2), the procedure aborts, no URI list will be returned and
the error has to be reported to the caller.
The procedure performs one or more DNS lookups in a well-defined
order (corresponding to descending prefix lenghts, see Section 3.4),
until one produces a usable result. Each of these DNS lookups might
not produce a usable result, either due to a normal condition (e.g.,
domain name exists, but no ALTO-specific NAPTR resource records are
associated with it), a permanent error (e.g., non-existent domain
name), or due to a temporary error (e.g., timeout). In all three
cases, and as long as there are further domain names that can be
looked up, the procedure SHOULD immediately try to lookup the next
domain name (from column 4 in the table given in Section 3.4). Only
after all domain names have been tried at least once, the procedure
MAY retry those domain names that had caused temporary lookup errors.
Generally speaking, ALTO provides advisory information for the
optimization of applications (e.g., peer-to-peer applications,
overlay networks, etc.), but applications should not rely on the
availability of such information for their basic functionality (see
Section 8.3.4.3 of RFC 7285 [RFC7285]). Consequently, the speedy
detection of an ALTO server, even though it may give less accurate
answers than other servers, or the quick realization that there is no
suitable ALTO server, is in general more preferable than causing long
delays by retrying failed queries. Nevertheless, the ALTO Cross-
Domain Server Discovery Procedure SHOULD inform its caller, if DNS
queries have failed due to temporary errors and that retrying the
discovery at a later point in time might give more accurate results.
4. Using the ALTO Protocol with Cross-Domain Server Discovery 4. Using the ALTO Protocol with Cross-Domain Server Discovery
Based on a modular design principle, ALTO provides several ALTO Based on a modular design principle, ALTO provides several ALTO
services, each consisting of a set of information resouces that can services, each consisting of a set of information resouces that can
be accessed using the ALTO protocol. The ALTO protocol specification be accessed using the ALTO protocol. The information resources that
defines the following ALTO services and their corresponding are available at a specific ALTO server are listed in its Information
information resouces: Resource Directory (IRD, see Section 9 of [RFC7285]). The ALTO
protocol specification defines the following ALTO services and their
corresponding information resouces:
o Network and Cost Map Service, see Section 11.2 of [RFC7285] o Network and Cost Map Service, see Section 11.2 of [RFC7285]
o Map-Filtering Service, see Section 11.3 of [RFC7285] o Map-Filtering Service, see Section 11.3 of [RFC7285]
o Endpoint Property Service, see Section 11.4 of [RFC7285] o Endpoint Property Service, see Section 11.4 of [RFC7285]
o Endpoint Cost Service, see Section 11.5 of [RFC7285] o Endpoint Cost Service, see Section 11.5 of [RFC7285]
Extension documents may specify further information resources;
however, these are out of scope of this document. The information
resources that are available at a specific ALTO server are listed in
its Information Resource Directory (IRD, see Section 9 of [RFC7285]).
The ALTO Cross-Domain Server Discovery Procedure is most useful in The ALTO Cross-Domain Server Discovery Procedure is most useful in
conjunction with the Endpoint Property Service and the Endpoint Cost conjunction with the Endpoint Property Service and the Endpoint Cost
Service. However, for the sake of completeness, possible interaction Service. However, for the sake of completeness, possible interaction
with all four services is discussed below. with all four services is discussed below. Extension documents may
specify further information resources; however, these are out of
scope of this document.
4.1. Network and Cost Map Service 4.1. Network and Cost Map Service
An ALTO client may invoke the ALTO Cross-Domain Server Discovery An ALTO client may invoke the ALTO Cross-Domain Server Discovery
Procedure (as specified in Section 3) for an IP address or prefix "X" Procedure (as specified in Section 3) for an IP address or prefix "X"
and get a list of one or more IRD URI(s), including order and and get a list of one or more IRD URI(s), including order and
preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These
IRD(s) will always contain a network and a cost map, as these are IRD(s) will always contain a network and a cost map, as these are
mandatory information resources (see Section 11.2 of [RFC7285]). mandatory information resources (see Section 11.2 of [RFC7285]).
However, the cost matrix may be very sparse. If, according to the However, the cost matrix may be very sparse. If, according to the
skipping to change at page 10, line 33 skipping to change at page 11, line 32
may be very sparse in the envisioned deployment scenario. Therefore, may be very sparse in the envisioned deployment scenario. Therefore,
depending on the filtering criteria provided by the client, this depending on the filtering criteria provided by the client, this
service may return results similar to the Endpoint Cost Service, or service may return results similar to the Endpoint Cost Service, or
it may not return any useful result. it may not return any useful result.
4.3. Endpoint Property Service 4.3. Endpoint Property Service
If an ALTO client wants to query an Endpoint Property Service (see If an ALTO client wants to query an Endpoint Property Service (see
Section 11.4 of RFC 7285 [RFC7285]) about an endpoint with IP address Section 11.4 of RFC 7285 [RFC7285]) about an endpoint with IP address
"X" or a group of endpoints within IP prefix "X", respectively, it "X" or a group of endpoints within IP prefix "X", respectively, it
has to perform the following steps: has to invoke the ALTO Cross-Domain Server Discovery Procedure (as
specified in Section 3): IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The
1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as result IRD_URIS_X is a list of one or more URIs of Information
specified in Section 3): IRD_URIS_X = XDOMDISC(X,"ALTO:https") Resource Directories (IRD, see Section 9 of [RFC7285]). Considering
the order and preference values, the client has to check these IRDs
2. The result IRD_URIS_X is a list of one or more Information for a suitable Endpoint Property Service and query it.
Resource Directories (IRD, see Section 9 of [RFC7285]).
Considering the order and preference values, check these IRDs for
a suitable Endpoint Property Service and query it.
If the ALTO client wants to do a similar Endpoint Property query for If the ALTO client wants to do a similar Endpoint Property query for
a different IP address or prefix "Y", the whole procedure has to be a different IP address or prefix "Y", the whole procedure has to be
repeated, as IRD_URIS_Y = XDOMDISC(Y,"ALTO:https") may yield a repeated, as IRD_URIS_Y = XDOMDISC(Y,"ALTO:https") may yield a
different list of IRDs. Of course, the results of individual DNS different list of IRD URIs. Of course, the results of individual DNS
queries may be cached as indicated by their respective time-to-live queries may be cached as indicated by their respective time-to-live
(TTL) values. (TTL) values.
4.4. Endpoint Cost Service 4.4. Endpoint Cost Service
The ALTO Endpoint Cost Service (ECS, see Section 11.5 of RFC 7285 The optional ALTO Endpoint Cost Service (ECS, see Section 11.5 of RFC
[RFC7285]) provides information about costs between individual 7285 [RFC7285]) provides information about costs between individual
endpoints and it also supports ranking. The ECS allows that endpoints and it also supports ranking. The ECS allows that
endpoints may be denoted by IP addresses or prefixes. The ECS is endpoints may be denoted by IP addresses or prefixes. The ECS is
called with a list of one or more source IP addresses or prefixes, called with a list of one or more source IP addresses or prefixes,
which we will call (S1, S2, S3, ...), and a list of one or more which we will call (S1, S2, S3, ...), and a list of one or more
destination IP addresses or prefixes, called (D1, D2, D3, ...). destination IP addresses or prefixes, called (D1, D2, D3, ...).
This specification distinguishes several cases, regarding the number This specification distinguishes several cases, regarding the number
of elements in the list of source and destination addresses, of elements in the list of source and destination addresses,
respectively: respectively:
1. Exactly one source address S1 and more than one destination 1. Exactly one source address S1 and more than one destination
addresses D1, D2, D3, ... In this case, the ALTO client has to addresses D1, D2, D3, ... In this case, the ALTO client has to
perform the following steps: invoke the ALTO Cross-Domain Server Discovery Procedure (as
specified in Section 3) with that single source address as a
1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as parameter: IRD_URIS_S1 = XDOMDISC(S1,"ALTO:https"). The result
specified in Section 3): IRD_URIS_S1 is a list of one or more URIs of Information Resource
IRD_URIS_S1 = XDOMDISC(S1,"ALTO:https") Directories (IRD, see Section 9 of [RFC7285]). Considering the
order and preference values, the client has to check these IRDs
2. The result IRD_URIS_S1 is a list of one or more Information for a suitable Endpoint Cost Service and query it. The ECS is an
Resource Directories (IRD, see Section 9 of [RFC7285]). optional service (see Section 11.5.1 of RFC 7285 [RFC7285]) and
Considering the order and preference values, check these IRDs therefore, it may well be that an IRD does not refer to an ECS.
for a suitable ECS and query it.
Calling the Cross-Domain Server Discovery Procedure only once Calling the Cross-Domain Server Discovery Procedure only once
with the single source address as a parameter - as opposed to with the single source address as a parameter - as opposed to
multiple calls, e.g., one for each destination address - is not multiple calls, e.g., one for each destination address - is not
only a matter of efficiency. In the given scenario, it is only a matter of efficiency. In the given scenario, it is
advisable to send all ECS queries to the same ALTO server. This advisable to send all ECS queries to the same ALTO server. This
ensures that the results can be compared (e.g., for sorting ensures that the results can be compared (e.g., for sorting
candidate resource providers), even with cost metrics without a candidate resource providers), even with cost metrics without a
well-defined base unit, e.g., the "routingcost" metric. well-defined base unit, e.g., the "routingcost" metric.
2. More than one source addresses S1, S2, S3, ... and exactly one 2. More than one source addresses S1, S2, S3, ... and exactly one
destination address D1. In this case, the ALTO client has to destination address D1. In this case, the ALTO client has to
perform the following steps: invoke the ALTO Cross-Domain Server Discovery Procedure with that
single destination address as a parameter:
1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as IRD_URIS_D1 = XDOMDISC(D1,"ALTO:https"). The result IRD_URIS_D1
specified in Section 3): is a list of one or more URIs of IRDs. Considering the order and
IRD_URIS_D1 = XDOMDISC(D1,"ALTO:https") preference values, the client has to check these IRDs for a
suitable ECS and query it.
2. The result IRD_URIS_D1 is a list of one or more Information
Resource Directories (IRD, see Section 9 of [RFC7285]).
Considering the order and preference values, check these IRDs
for a suitable ECS and query it.
3. Exactly one source address S1 and exactly one destination address 3. Exactly one source address S1 and exactly one destination address
D1. The ALTO client may perform the same steps as in case 1, as D1. The ALTO client may perform the same steps as in case 1, as
specified above. As an alternative, it may also perform the same specified above. As an alternative, it may also perform the same
steps as in case 2, as specified above. steps as in case 2, as specified above.
4. More than one source addresses S1, S2, S3, ... and more than one 4. More than one source addresses S1, S2, S3, ... and more than one
destination addresses D1, D2, D3, ... In this case, the ALTO destination addresses D1, D2, D3, ... In this case, the ALTO
client should split the list of source addresses, and perform client should split the list of desired queries based on source
separately for each source address the same steps as in case 1, addresses and perform separately for each source address the same
as specified above. As an alternative, the ALTO client may also steps as in case 1, as specified above. As an alternative, the
split the list of destination addresses, and perform separately ALTO client may also group the list based on destination
for each destination address the same steps as in case 2, as addresses and perform separately for each destination address the
specified above. However, comparing results between these sub- same steps as in case 2, as specified above. However, comparing
queries may be difficult, in particular if the cost metric is a results between these sub-queries may be difficult, in particular
relative preference without a well-defined base unit (e.g., the if the cost metric is a relative preference without a well-
"routingcost" metric). defined base unit (e.g., the "routingcost" metric).
See Appendix C for a detailed example showing the interaction of a See Appendix C for a detailed example showing the interaction of a
tracker-based peer-to-peer application, the ALTO Endpoint Cost tracker-based peer-to-peer application, the ALTO Endpoint Cost
Service, and the ALTO Cross-Domain Server Discovery Procedure. Service, and the ALTO Cross-Domain Server Discovery Procedure.
4.5. Summary and Further Extensions 4.5. Summary and Further Extensions
Considering the four services defined in the ALTO base protocol Considering the four services defined in the ALTO base protocol
specification [RFC7285], the ALTO Cross-Domain Server Discovery specification [RFC7285], the ALTO Cross-Domain Server Discovery
Procedure works best with the Endpoint Property Service (EPS) and the Procedure works best with the Endpoint Property Service (EPS) and the
skipping to change at page 21, line 5 skipping to change at page 22, line 5
[RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and [RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
H. Song, "Application-Layer Traffic Optimization (ALTO) H. Song, "Application-Layer Traffic Optimization (ALTO)
Server Discovery", RFC 7286, June 2014. Server Discovery", RFC 7286, June 2014.
[RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and
S. Previdi, "Application-Layer Traffic Optimization (ALTO) S. Previdi, "Application-Layer Traffic Optimization (ALTO)
Deployment Considerations", RFC 7971, DOI 10.17487/ Deployment Considerations", RFC 7971, DOI 10.17487/
RFC7971, October 2016, RFC7971, October 2016,
<http://www.rfc-editor.org/info/rfc7971>. <http://www.rfc-editor.org/info/rfc7971>.
Appendix A. Multiple Information Sources and Partitioned Knowledge Appendix A. Solution Approaches for Partitioned ALTO Knowledge
The ALTO base protocol document [RFC7285] specifies the communication The ALTO base protocol document [RFC7285] specifies the communication
between an ALTO client and a single ALTO server. It is implicitly between an ALTO client and a single ALTO server. It is implicitly
assumed that this server can answer any query, possibly with some assumed that this server can answer any query, possibly with some
kind of default value if no exact data is known. No special kind of 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 the originates from multiple sources, which are possibly under the
control of different administrative entities (e.g., different ISPs) control of different administrative entities (e.g., different ISPs)
or that the overall ALTO information is partitioned and stored on or that the overall ALTO information is partitioned and stored on
several ALTO servers. several ALTO servers.
skipping to change at page 32, line 35 skipping to change at page 33, line 35
preference", but "an ISP may internally compute routing cost using preference", but "an ISP may internally compute routing cost using
any method that it chooses" (see section 6.1.1.1. of [RFC7285]). any method that it chooses" (see section 6.1.1.1. of [RFC7285]).
Thus, COST_X_A could be 10 (milliseconds round-trip time), while Thus, COST_X_A could be 10 (milliseconds round-trip time), while
COST_X_B could be 200 (kilometers great circle distance between the COST_X_B could be 200 (kilometers great circle distance between the
approximate geographic locations of the hosts) and COST_X_C could be approximate geographic locations of the hosts) and COST_X_C could be
3 (router hops, corresponding to a decrease of the TTL field in the 3 (router hops, corresponding to a decrease of the TTL field in the
IP header). Each of these metrics fulfills the "lower value is more IP header). Each of these metrics fulfills the "lower value is more
preferable" requirement on its own, but obviously, they cannot be preferable" requirement on its own, but obviously, they cannot be
compared with each other. Even if there was a reasonable formula to compared with each other. Even if there was a reasonable formula to
compare, for example, kilometers with milliseconds, we could not use compare, for example, kilometers with milliseconds, we could not use
it, as the units of measurement (or any other computation method for it, as the units of measurement (or any other information about the
the routingcost) are sent not along with the value in the ECS reply. computation method for the routingcost) are not sent along with the
value in the ECS reply.
To avoid this problem, the tracker tries to send all ECS queries to To avoid this problem, the tracker tries to send all ECS queries to
the same ALTO server. As specified in Section 4.4 of this document, the same ALTO server. As specified in Section 4.4 of this document,
case 2, it uses the IP address of Resource Consumer x as parameter to case 2, it uses the IP address of Resource Consumer x as parameter to
the discovery procedure: the discovery procedure:
IRD_URIS_X = XDOMDISC(X,"ALTO:https") IRD_URIS_X = XDOMDISC(X,"ALTO:https")
COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_X COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_X
COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_X COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_X
COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_X COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_X
This strategy ensures that COST_X_A, COST_X_B, and COST_X_C can be This strategy ensures that COST_X_A, COST_X_B, and COST_X_C can be
compared with each other. compared with each other.
As been said, the tracker calls the ALTO Cross-Domain Server As discussed above, the tracker calls the ALTO Cross-Domain Server
Discovery Procedure with IP address X as a parameter. For the Discovery Procedure with IP address X as a parameter. For the
reminder of this example, we assume that X = 2001:DB8:1:2:227:eff: reminder of this example, we assume that X = 2001:DB8:1:2:227:eff:
fe6a:de42. Thus, the procedure call is fe6a:de42. Thus, the procedure call is
IRD_URIS_X = XDOMDISC(2001:DB8:1:2:227:eff:fe6a:de42,"ALTO:https"). IRD_URIS_X = XDOMDISC(2001:DB8:1:2:227:eff:fe6a:de42,"ALTO:https").
The first parameter 2001:DB8:1:2:227:eff:fe6a:de42 is a single IPv6 The first parameter 2001:DB8:1:2:227:eff:fe6a:de42 is a single IPv6
address. Thus, we get AT = "IPv6", A = 2001:DB8:1:2:227:eff:fe6a: address. Thus, we get AT = IPv6, A = 2001:DB8:1:2:227:eff:fe6a:de42,
de42, L = 128, and SP = "ALTO:https". L = 128, and SP = "ALTO:https".
The procedure constructs (see Step 1 in Section 3.2) The procedure constructs (see Step 1 in Section 3.2)
R128 = "2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.2.0.0.0.1.0.0.0. R128 = "2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.2.0.0.0.1.0.0.0.
8.B.D.0.1.0.0.2.IP6.ARPA.", as well as (see Step 2 in Section 3.3) 8.B.D.0.1.0.0.2.IP6.ARPA.", as well as (see Step 2 in Section 3.3)
R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
R56 = "0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", 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.", and R48 = "1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and
R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.". R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.".
In order to illustrate the third step of the ALTO Cross-Domain Server In order to illustrate the third step of the ALTO Cross-Domain Server
skipping to change at page 33, line 36 skipping to change at page 34, line 36
lookup utility that is available for many operating systems (e.g., lookup utility that is available for many operating systems (e.g.,
Linux). A real implementation of the ALTO Cross-Domain Server Linux). A real implementation of the ALTO Cross-Domain Server
Discovery Procedure would not be based on the "dig" utility, but use Discovery Procedure would not be based on the "dig" utility, but use
appropriate libraries and/or operating system APIs. Please note that appropriate libraries and/or operating system APIs. Please note that
the following steps have been performed in a controlled lab the following steps have been performed in a controlled lab
environment with a appropriately configured name server. A suitable environment with a appropriately configured name server. A suitable
DNS configuration will be needed to reproduce these results. Please DNS configuration will be needed to reproduce these results. Please
also note that the rather verbose output of the "dig" tool has been also note that the rather verbose output of the "dig" tool has been
shortened to the relevant lines. shortened to the relevant lines.
Since AT = "IPv6" and L = 128, in the table given in Section 3.4, the Since AT = IPv6 and L = 128, in the table given in Section 3.4, the
sixth row (not counting the column headers) applies. sixth row (not counting the column headers) applies.
As mandated by the third column, we start with a lookup of R128, As mandated by the third column, we start with a lookup of R128,
looking for NAPTR resource records: looking for NAPTR resource records:
| sk@labpc12:~$ 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<<- opcode: QUERY, status: NXDOMAIN, id: 26553 | ;; ->>HEADER<<- 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
The domain name R128 does not exist (status: NXDOMAIN), so we cannot The domain name R128 does not exist (status: NXDOMAIN), so we cannot
get a useful result. Therefore, we continue with the fourth column get a useful result. Therefore, we continue with the fourth column
of the table and do a lookup of R64: of the table and do a lookup of R64:
| sk@labpc12:~$ dig -tNAPTR 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. | user@labpc:~$ dig -tNAPTR 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| |
| ;; Got answer: | ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33193 | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33193
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0
The domain name R64 could be looked up (status: NOERROR), but there The domain name R64 could be looked up (status: NOERROR), but there
are no NAPTR resource records associated with it (ANSWER: 0). Maybe, are no NAPTR resource records associated with it (ANSWER: 0). Maybe,
there are some other resource records such as PTR, NS, or SOA, but we there are some other resource records such as PTR, NS, or SOA, but we
are not interested in them. Thus, we do not get a useful result and are not interested in them. Thus, we do not get a useful result and
we continue with looking up R56: we continue with looking up R56:
| sk@labpc12:~$ dig -tNAPTR 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. | user@labpc:~$ dig -tNAPTR 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| |
| ;; Got answer: | ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35966 | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35966
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
| |
| ;; ANSWER SECTION: | ;; ANSWER SECTION:
| 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u" | 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
| "LIS:HELD" "!.*!https://lis1.example.org:4802/?c=ex!" . | "LIS:HELD" "!.*!https://lis1.example.org:4802/?c=ex!" .
| 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 20 "u" | 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 20 "u"
| "LIS:HELD" "!.*!https://lis2.example.org:4802/?c=ex!" . | "LIS:HELD" "!.*!https://lis2.example.org:4802/?c=ex!" .
The domain name R56 could be looked up and there are NAPTR resource The domain name R56 could be looked up and there are NAPTR resource
records associated with it. However, each of these records has a records associated with it. However, each of these records has a
service parameter that does not match our SP = "ALTO:https" (see service parameter that does not match our SP = "ALTO:https" (see
[RFC7216] for "LIS:HELD"), and therefore, we have to ignore them. [RFC7216] for "LIS:HELD"), and therefore, we have to ignore them.
Consequently, we still do not have a useful result and continue with Consequently, we still do not have a useful result and continue with
a lookup of R48: a lookup of R48:
| sk@labpc12:~$ dig -tNAPTR 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. | user@labpc:~$ dig -tNAPTR 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| |
| ;; Got answer: | ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50459 | ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50459
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2 | ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
| |
| ;; ANSWER SECTION: | ;; ANSWER SECTION:
| 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!" .
 End of changes. 42 change blocks. 
165 lines changed or deleted 196 lines changed or added

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