draft-ietf-alto-xdom-disc-02.txt   draft-ietf-alto-xdom-disc-03.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: September 6, 2018 H-DA Expires: April 12, 2019 H-DA
March 5, 2018 October 9, 2018
Application Layer Traffic Optimization (ALTO) Cross-Domain Server Application Layer Traffic Optimization (ALTO) Cross-Domain Server
Discovery Discovery
draft-ietf-alto-xdom-disc-02 draft-ietf-alto-xdom-disc-03
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.
skipping to change at page 2, line 11 skipping to change at page 2, line 11
NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and
returns one or more URI(s) of information resources related to that returns one or more URI(s) of information resources related to that
IP address or prefix. IP 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 6, 2018. This Internet-Draft will expire on April 12, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. ALTO Cross-Domain Server Discovery Procedure Specification . . 5 2. Overview on the ALTO Cross-Domain Server Discovery
2.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 5 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Step 1: Prepare Domain Name for Reverse DNS Lookup . . . . 6 3. ALTO Cross-Domain Server Discovery Procedure Specification . . 6
2.3. Step 2: Prepare Shortened Domain Names . . . . . . . . . . 6 3.1. Interface . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Step 3: Perform DNS U-NAPTR lookups . . . . . . . . . . . 7 3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup . . . . 7
3. Using the ALTO Protocol with ALTO Cross-Domain Server 3.3. Step 2: Prepare Shortened Domain Names . . . . . . . . . . 7
Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Step 3: Perform DNS U-NAPTR lookups . . . . . . . . . . . 8
3.1. Network and Cost Map Service . . . . . . . . . . . . . . . 8 4. Using the ALTO Protocol with Cross-Domain Server Discovery . . 9
3.2. Map-Filtering Service . . . . . . . . . . . . . . . . . . 9 4.1. Network and Cost Map Service . . . . . . . . . . . . . . . 9
3.3. Endpoint Property Service . . . . . . . . . . . . . . . . 9 4.2. Map-Filtering Service . . . . . . . . . . . . . . . . . . 10
3.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 10 4.3. Endpoint Property Service . . . . . . . . . . . . . . . . 10
4. Implementation, Deployment, and Operational Considerations . . 12 4.4. Endpoint Cost Service . . . . . . . . . . . . . . . . . . 11
4.1. Considerations for ALTO Clients . . . . . . . . . . . . . 12 4.5. Summary and Further Extensions . . . . . . . . . . . . . . 12
4.2. Deployment Considerations for Network Operators . . . . . 13 5. Implementation, Deployment, and Operational Considerations . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5.1. Considerations for ALTO Clients . . . . . . . . . . . . . 13
5.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 14 5.2. Deployment Considerations for Network Operators . . . . . 14
5.2. Availability of the ALTO Server Discovery Procedure . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 16 6.1. Integrity of the ALTO Server's URI . . . . . . . . . . . . 15
5.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 16 6.2. Availability of the ALTO Server Discovery Procedure . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6.3. Confidentiality of the ALTO Server's URI . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Multiple Information Sources and Partitioned Appendix A. Multiple Information Sources and Partitioned
Knowledge . . . . . . . . . . . . . . . . . . . . . . 20 Knowledge . . . . . . . . . . . . . . . . . . . . . . 21
A.1. Classification of Solution Approaches . . . . . . . . . . 20 A.1. Classification of Solution Approaches . . . . . . . . . . 21
A.2. Discussion of Solution Approaches . . . . . . . . . . . . 21 A.2. Discussion of Solution Approaches . . . . . . . . . . . . 22
A.3. The Need for Cross-Domain ALTO Server Discovery . . . . . 21 A.3. The Need for Cross-Domain ALTO Server Discovery . . . . . 22
A.4. Our Solution Approach . . . . . . . . . . . . . . . . . . 22 A.4. Our Solution Approach . . . . . . . . . . . . . . . . . . 23
A.5. Relation to the ALTO Requirements . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . . . . . . . 23 Discovery . . . . . . . . . . . . . . . . . . . . . . 24
B.1. Discovery Client Application Programming Interface . . . . 23 B.1. Discovery Client Application Programming Interface . . . . 24
B.2. Data Storage and Authority Requirements . . . . . . . . . 23 B.2. Data Storage and Authority Requirements . . . . . . . . . 24
B.3. Cross-Domain Operations Requirements . . . . . . . . . . . 23 B.3. Cross-Domain Operations Requirements . . . . . . . . . . . 24
B.4. Protocol Requirements . . . . . . . . . . . . . . . . . . 24 B.4. Protocol Requirements . . . . . . . . . . . . . . . . . . 25
B.5. Further Requirements . . . . . . . . . . . . . . . . . . . 24 B.5. Further Requirements . . . . . . . . . . . . . . . . . . . 25
Appendix C. ALTO and Tracker-based Peer-to-Peer Applications . . 25 Appendix C. ALTO and Tracker-based Peer-to-Peer Applications . . 26
Appendix D. Contributors List and Acknowledgments . . . . . . . . 30 C.1. Architectural Options . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 C.2. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . 29
C.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix D. Contributors List and Acknowledgments . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
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 35 skipping to change at page 4, line 35
("partitioned knowledge"). Various ALTO use cases have been studied ("partitioned knowledge"). Various ALTO use cases have been studied
in the context of such scenarios. In some cases, one cannot assume in the context of such scenarios. In some cases, one cannot assume
that a topologically nearby ALTO server (e.g., a server discovered that a topologically nearby ALTO server (e.g., a server discovered
with the procedure specified in [RFC7286]) will always provide useful with the procedure specified in [RFC7286]) will always provide useful
information to the client. One such scenario is detailed in information to the client. One such scenario is detailed in
Appendix C. Several solution approaches, such as redirecting a Appendix C. Several solution approaches, such as redirecting a
client to a server that has more accurate information or forwarding client to a server that has more accurate information or forwarding
the request to it on behalf of the client, have been proposed and the request to 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.
This document specifies an ALTO server discovery procedure that runs Section 3 of this document specifies the "ALTO Cross-Domain Server
on the client side. An ALTO client, which wants to send a query Discovery Procedure" for client-side usage in these scenarios. An
related to a specific IP address or prefix X, may use the procedure ALTO client that wants to send an ALTO query related to a specific IP
specified in Section 2 with X as a parameter, in order to perform DNS address or prefix X, may call this procedure with X as a paramenter.
lookups and find an ALTO server that can provide a competent answer. It will use DNS lookups to find the IRD URI(s) of one ore more ALTO
The wording "related to" in the previous sentence is intentionally server(s) that can provide a competent answer. The above wording
kept somewhat vague, as the exact semantics depends on the ALTO "related to" was intentionally kept somewhat vague, as the exact
service to be used; see Section 3 for details. semantics depends on the ALTO service to be used; see Section 4.
Those who are in control of the "reverse DNS" (i.e., the Those who are in control of the "reverse DNS" for a given IP address
corresponding subdomain of in-addr.arpa. or ip6.arpa.) for a given IP or prefix (i.e., the corresponding subdomain of in-addr.arpa. or
address or prefix - 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 a suitable ALTO server. In resource records to the DNS that point to one or more relevant ALTO
many cases, it may be an ALTO server run by that ISP or IT server(s). In many cases, it may be an ALTO server run by that ISP
department, as they naturally have good insight into routing costs or IT department, as they naturally have good insight into routing
from and to their networks. However, they may also refer to an ALTO costs from and to their networks. However, they may also refer to an
server run by a different organization, e.g., their upstream ISP. ALTO server provided by someone else, e.g., their upstream ISP.
2. ALTO Cross-Domain Server Discovery Procedure Specification 2. Overview on the ALTO Cross-Domain Server Discovery Procedure
This procedure was inspired by [RFC7216] and re-uses parts of This procedure was inspired by the "Location Information Server (LIS)
[RFC7286]. Discovery Using IP Addresses and Reverse DNS" [RFC7216] and re-uses
parts of the basic ALTO Server Discovery Procedure [RFC7286].
The procedure sequentially tries two different lookup strategies. The basic idea is to use the Domain Name System (DNS), more
First, an ALTO-specific U-NAPTR record is searched in the "reverse specifically the "in-addr.arpa." or "ip6.arpa." trees, which are
tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa. mostly used for "reverse mapping" of IP addresses to host names by
means of PTR resource records. There, U-NAPTR resource records
[RFC4848], which allow the mapping of domain names to URIs, are
installed as needed. Thereby, it is possible to store a mapping from
an IP address or prefix to one or more ALTO server URIs in the DNS.
The ALTO Cross-Domain Server Discovery Procedure is called with one
IP address or prefix X and a U-NAPTR Service Parameter [RFC4848] SP
as parameters.
The service parameter SP SHOULD always be set to "ALTO:https".
However, other parameter values MAY be used in some scenarios, e.g.,
"ALTO:http" to search for a server that supports unencrypted
transmission for debugging purposes, or other application protocol or
service tags if applicable.
The procedure performs DNS lookups and returns one or more URI(s) of
information resources related to the IP address or prefix X, usually
the URI(s) of one or more ALTO Information Resource Directory (IRD,
see Section 9 of [RFC7285]). The U-NAPTR records also provide
preference values, which should be considered if more than one URI is
returned.
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
strategies: First, an ALTO-specific U-NAPTR record is searched in the
"reverse tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa.
corresponding to the given IP address or prefix. If this lookup does 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, further lookups with truncated domain
names may be tried. The goal is to allow deployment scenarios that names may be tried. The goal is to allow deployment scenarios that
require fine-grained discovery on a per-IP basis, as well as large- require fine-grained discovery on a per-IP basis, as well as large-
scale scenarios where discovery is to be enabled for a large number scale scenarios where discovery is to be enabled for a large number
of IP addresses with a small number of additional DNS resource of IP addresses with a small number of additional DNS resource
records. records.
2.1. Interface 3. ALTO Cross-Domain Server Discovery Procedure Specification
The procedure specified in this document takes one IP address or 3.1. Interface
prefix X and a U-NAPTR Service Parameter as parameters.
The procedure specified in this document takes two parameters, X and
SP, where X is an IP address or prefix and SP is a U-NAPTR Service
Parameter.
The parameter X may be an IPv4 or an IPv6 address or prefix in CIDR 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). In both cases, it consists of an IP address A and a prefix IPv6). Consequently, the address type AT is either "IPv4" or "IPv6".
length L. For IPv4, it holds: 0 <= L <= 32 and for IPv6, it holds: 0 In both cases, X consists of an IP address A and a prefix length L.
<= L <= 128. For AT="IPv4", it holds: 0 <= L <= 32 and for AT="IPv6", it holds:
0 <= L <= 128.
For example, for X=198.51.100.0/24, we get A=198.51.100.0 and L=24. For example, for X=198.51.100.0/24, we get AT="IPv4", A=198.51.100.0
Similarly, for X=2001:0DB8::20/128, we get A=2001:0DB8::20 and L=128. and L=24. Similarly, for X=2001:0DB8::20/128, we get AT="IPv6",
A=2001:0DB8::20 and L=128.
The procedure SHOULD always be called with the U-NAPTR Service In the intended usage scenario, the procedure SHOULD always be called
Parameter [RFC4848] set to "ALTO:https". However, other parameter with the parameter SP set to "ALTO:https". However, for general
values MAY be used in some scenarios, e.g., "ALTO:http" to request applicabiliy and in order to support future extensions, the procedure
unencrypted transmission for debugging purposes, or other application MUST support being called with any valid U-NAPTR Service Parameter
protocol or service tags if applicable. (see Section 4.5. of [RFC4848] for the syntax of U-NAPTR Service
Parameters and Section 5. of the same document for information about
the IANA registries).
The procedure performs DNS lookups and returns one or more URI(s) of 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]). see Section 9 of [RFC7285]). For each URI, it also returns order and
preference values (see Section 4.1 of [RFC3403]), which should be
considered if more than one URI is returned.
For the remainder of the document, we use the notation: The procedure may fail for various reasons, including syntactically
IRD_URIS_X := XDOMDISC(X,"ALTO:https") invalid parameters, unsupported parameter values, temporary or
permanent errors when performing DNS lookups, etc. These error
conditions have to be reported to the caller in an appropriate way.
2.2. Step 1: Prepare Domain Name for Reverse DNS Lookup For the remainder of the document, we use the following notation for
calling the ALTO Cross-Domain Server Discovery Procedure:
IRD_URIS_X = XDOMDISC(X,"ALTO:https")
3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup
If A is an IPv4 address, a domain name R32 is constructed according If A is an IPv4 address, a domain name R32 is constructed according
to the rules specified in Section 3.5 of [RFC1035] and it is rooted to the rules specified in Section 3.5 of [RFC1035] and it is rooted
in the special domain "IN-ADDR.ARPA.". 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 A is an IPv6 address, the domain name R128 is constructed
according to the rules specified in Section 2.5 of [RFC3596] and the according to the rules specified in Section 2.5 of [RFC3596] and the
special domain "IP6.ARPA." is used. special domain "IP6.ARPA." is used.
For example (note: a line break was added after the second line), For example (note: a line break was added after the second line),
A = 2001:0DB8::20 yields A = 2001:0DB8::20 yields
R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0. R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
1.0.0.2.IP6.ARPA." 1.0.0.2.IP6.ARPA."
2.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 A is an IPv4 address, the following additional domain names are
generated from the result of the previous step: R24=skip(R32,1), generated from the result of the previous step: R24=skip(R32,1),
R16=skip(R32,2), and R8=skip(R32,3). Removing one label from a R16=skip(R32,2), and R8=skip(R32,3). Removing one label from a
domain name (i.e., one number of the "dotted quad notation") domain name (i.e., one number of the "dotted quad notation")
skipping to change at page 7, line 5 skipping to change at page 8, line 5
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."
2.4. Step 3: Perform DNS U-NAPTR lookups 3.4. Step 3: Perform DNS U-NAPTR lookups
The address type of A (i.e., IPv4 or IPv6) and the value of L are The address type of A and the prefix length are matched against the
matched against the first and the second column of the following first and the second column of the following table, respectively:
table, respectively:
+-------------+-------------+-------------+-----------------------+ +------------+------------+------------+------------------------+
| 1: Addresss | 2: Prefix | 3: MUST | 4: SHOULD do further | | 1: Address | 2: Prefix | 3: MUST do | 4: SHOULD do further |
| Type of A | Length L | lookup first| 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, procedure fails w/o result) |
+-------------+-------------+-------------+-----------------------+ +------------+------------+------------+------------------------+
| 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, procedure fails w/o result) |
+-------------+-------------+-------------+-----------------------+ +------------+------------+------------+------------------------+
Then, the domain name given in column 3 and the U-NAPTR Service Then, the domain name given in the 3rd column and the U-NAPTR Service
Parameter the procedure was called with (usually "ALTO:https") MUST Parameter SP the procedure was called with (usually "ALTO:https")
be used for an U-NAPTR [RFC4848] lookup, in order to obtain one or MUST be used for an U-NAPTR [RFC4848] lookup, in order to obtain one
more URIs (indicating protocol, host, and possibly path elements) for or more URIs (indicating protocol, host, and possibly path elements)
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
for mapping "100.51.198.IN-ADDR.ARPA." (i.e., R24 from the example in for mapping "100.51.198.IN-ADDR.ARPA." (i.e., R24 from the example in
the previous step) to the HTTPS URIs "https://alto1.example.net/ird" the previous step) to the HTTPS URIs "https://alto1.example.net/ird"
and "https://alto2.example.net/ird", with the former being preferred. and "https://alto2.example.net/ird", with the former being preferred.
100.51.198.IN-ADDR.ARPA. IN NAPTR 100 10 "u" "ALTO:https" 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://alto1.example.net/ird!" "" "!.*!https://alto1.example.net/ird!" ""
100.51.198.IN-ADDR.ARPA. IN NAPTR 100 20 "u" "ALTO:https" 100.51.198.IN-ADDR.ARPA. IN NAPTR 100 20 "u" "ALTO:https"
"!.*!https://alto2.example.net/ird!" "" "!.*!https://alto2.example.net/ird!" ""
If no matching U-NAPTR records can be found, the procedure SHOULD try If no matching U-NAPTR records can be found, the procedure SHOULD try
further lookups, using the domain names from column 4 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 column 3 and column 4, 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, without producing a result.
3. Using the ALTO Protocol with ALTO 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 ALTO protocol specification
defines the following ALTO services and their corresponding defines the following ALTO services and their corresponding
information resouces: 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]
skipping to change at page 8, line 31 skipping to change at page 9, line 31
Extension documents may specify further information resources; Extension documents may specify further information resources;
however, these are out of scope of this document. The information however, these are out of scope of this document. The information
resources that are available at a specific ALTO server are listed in resources that are available at a specific ALTO server are listed in
its Information Resource Directory (IRD, see Section 9 of [RFC7285]). 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.
3.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 2) 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): and get a list of one or more IRD URI(s), including order and
IRD_URIS_X := XDOMDISC(X,"ALTO:https"). These IRD(s) will always preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These
contain a network and a cost map, as these are mandatory information IRD(s) will always contain a network and a cost map, as these are
ressources (see Section 11.2 of [RFC7285]). However, the cost matrix mandatory information resources (see Section 11.2 of [RFC7285]).
may be very sparse. If, according to the network map, PID_X is the However, the cost matrix may be very sparse. If, according to the
PID that contains the IP address or prefix X, and PID_1, PID_2, network map, PID_X is the PID that contains the IP address or prefix
PID_3, ... are other PIDS, the cost map may look like this: X, and PID_1, PID_2, PID_3, ... are other PIDS, the cost map may look
like this:
From \ To PID_1 PID_2 PID_X PID_3 From \ To PID_1 PID_2 PID_X PID_3
------+----------------------------------- ------+-----------------------------------
PID_1 | 92 PID_1 | 92
PID_2 | 6 PID_2 | 6
PID_X | 46 3 1 19 PID_X | 46 3 1 19
PID_3 | 38 PID_3 | 38
In this example, all cells outside column "X" and row "X" are 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 ECS, cases 1 and 2 information as what could be retrieved using the ECS, cases 1 and 2
in Section 3.4. Accessing cells outside column "X" and row "X" may in Section 4.4. Accessing cells outside column "X" and row "X" may
not yield useful results. not yield useful results.
Trying to assemble a more densely populated cost map from several Trying to assemble a more densely populated cost map from several
cost maps with this very sparse structure may be a non-trivial task, cost maps with this very sparse structure may be a non-trivial task,
as different ALTO servers may use different PID definitions (i.e., as different ALTO servers may use different PID definitions (i.e.,
network maps) and incompatible scales for the costs, in particular network maps) and incompatible scales for the costs, in particular
for the "routingcost" metric. for the "routingcost" metric.
3.2. Map-Filtering Service 4.2. Map-Filtering Service
An ALTO client may invoke the ALTO Cross-Domain Server Discovery An ALTO client may invoke the ALTO Cross-Domain Server Discovery
Procedure (as specified in Section 2) 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): IRD_URIS_X := and get a list of one or more IRD URI(s), including order and
XDOMDISC(X,"ALTO:https"). These IRD(s) may provide the optional Map- preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These
Filtering Service (see Section 11.3 of [RFC7285]). This service IRD(s) may provide the optional Map-Filtering Service (see Section
returns a subset of the full map, as specified by the client. As 11.3 of [RFC7285]). This service returns a subset of the full map,
discussed in Section 3.1, a cost map may be very sparse in the as specified by the client. As discussed in Section 4.1, a cost map
envisioned deployment scenario. Therefore, depending on the may be very sparse in the envisioned deployment scenario. Therefore,
filtering criteria provided by the client, this service may return depending on the filtering criteria provided by the client, this
results similar to the Endpoint Cost Service, or it may not return service may return results similar to the Endpoint Cost Service, or
any useful result. it may not return any useful result.
3.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 perform the following steps:
1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as 1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as
specified in Section 2): IRD_URIS_X := XDOMDISC(X,"ALTO:https") specified in Section 3): IRD_URIS_X = XDOMDISC(X,"ALTO:https")
2. The result IRD_URIS_X is a list of one or more Information 2. The result IRD_URIS_X is a list of one or more Information
Resource Directories (IRD, see Section 9 of [RFC7285]). Check Resource Directories (IRD, see Section 9 of [RFC7285]).
each of these IRDs for a suitable Endpoint Property Service and Considering the order and preference values, check these IRDs for
query it. 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 IRDs. 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.
3.4. Endpoint Cost Service 4.4. Endpoint Cost Service
The ALTO Endpoint Cost Service (ECS, see Section 11.5 of RFC 7285 The ALTO Endpoint Cost Service (ECS, see Section 11.5 of RFC 7285
[RFC7285]) provides information about costs between individual [RFC7285]) provides information about costs between individual
endpoints and it also supports ranking. The ECS allows that endpoints and 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, which we will call (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: perform the following steps:
1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as 1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as
specified in Section 2): specified in Section 3):
IRD_URIS_S1 := XDOMDISC(S1,"ALTO:https") IRD_URIS_S1 = XDOMDISC(S1,"ALTO:https")
2. The result IRD_URIS_S1 is a list of one or more Information 2. The result IRD_URIS_S1 is a list of one or more Information
Resource Directories (IRD, see Section 9 of [RFC7285]). Resource Directories (IRD, see Section 9 of [RFC7285]).
Check each of these IRDs for a suitable ECS and query it. Considering the order and preference values, check these IRDs
for a suitable ECS and query it.
Calling the Cross-Domain Server Discovery Procedure only once
with the single source address as a parameter - as opposed to
multiple calls, e.g., one for each destination address - is not
only a matter of efficiency. In the given scenario, it is
advisable to send all ECS queries to the same ALTO server. This
ensures that the results can be compared (e.g., for sorting
candidate resource providers), even with cost metrics without a
well-defined base unit, e.g., the "routingcost" metric.
2. More than one source addresses S1, S2, S3, ... and exactly one 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: perform the following steps:
1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as 1. Invoke the ALTO Cross-Domain Server Discovery Procedure (as
specified in Section 2): specified in Section 3):
IRD_URIS_D1 := XDOMDISC(D1,"ALTO:https") IRD_URIS_D1 = XDOMDISC(D1,"ALTO:https")
2. The result IRD_URIS_D1 is a list of one or more Information 2. The result IRD_URIS_D1 is a list of one or more Information
Resource Directories (IRD, see Section 9 of [RFC7285]). Resource Directories (IRD, see Section 9 of [RFC7285]).
Check each of these IRDs for a suitable ECS and query it. 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 source addresses, and perform
separately for each source address the same steps as in case 1, separately for each source address the same steps as in case 1,
as specified above. As an alternative, the ALTO client may also as specified above. As an alternative, the ALTO client may also
split the list of destination addresses, and perform separately split the list of destination addresses, and perform separately
for each destination address the same steps as in case 2, as for each destination address the same steps as in case 2, as
specified above. However, comparing results between these sub- specified above. However, comparing results between these sub-
queries may be difficult, in particular if the cost metric is a queries may be difficult, in particular if the cost metric is a
relative preference without a well-defined base unit (e.g., the relative preference without a well-defined base unit (e.g., the
"routingcost" metric). "routingcost" metric).
4. Implementation, Deployment, and Operational Considerations See Appendix C for a detailed example showing the interaction of a
tracker-based peer-to-peer application, the ALTO Endpoint Cost
Service, and the ALTO Cross-Domain Server Discovery Procedure.
4.1. Considerations for ALTO Clients 4.5. Summary and Further Extensions
4.1.1. Resource Consumer Initiated Discovery Considering the four services defined in the ALTO base protocol
specification [RFC7285], the ALTO Cross-Domain Server Discovery
Procedure works best with the Endpoint Property Service (EPS) and the
Endpoint Cost Service (ECS). Both the EPS and the ECS take one or
more IP addresses as a parameter. The previous sections specify how
the parameter for calling the ALTO Cross-Domain Server Discovery
Procedure has to be derived from these IP adresses.
In contrast, the ALTO Cross-Domain Server Discovery Procedure seems
less useful if the goal is to retrieve network and cost maps that
cover the whole network topology. However, the procedure may be
useful if a map centered at a specific IP address is desired (i.e., a
map detailing the vicinity of said IP address or a map giving costs
from said IP address to all potential destinations).
The interaction between further ALTO services (and their
corresponding information resources) needs to be investigated and
defined once such further ALTO services are specified in an extension
document.
5. Implementation, Deployment, and Operational Considerations
5.1. Considerations for ALTO Clients
5.1.1. Resource Consumer Initiated Discovery
To some extent, ALTO requirement AR-32 [RFC6708], i.e., resource To some extent, ALTO requirement AR-32 [RFC6708], i.e., resource
consumer initiated ALTO server discovery, can be seen as a special consumer initiated ALTO server discovery, can be seen as a special
case of cross-domain ALTO server discovery. To that end, an ALTO case of cross-domain ALTO server discovery. To that end, an ALTO
client embedded in a resouce consumer would have to figure out its client embedded in a resource consumer would have to figure out its
own "public" IP address and perform the procedures described in this own "public" IP address and perform the procedures described in this
document on that address. However, due to the widespread deployment document on that address. However, due to the widespread deployment
of Network Address Translators (NAT), additional protocols and of Network Address Translators (NAT), additional protocols and
mechanisms such as STUN [RFC5389] would be needed and considerations mechanisms such as STUN [RFC5389] would be needed and considerations
for UNSAF [RFC3424] apply. Therefore, using the procedures specified for UNSAF [RFC3424] apply. Therefore, using the procedures specified
in this document for resource consumer based ALTO server discovery is in this document for resource consumer based ALTO server discovery is
generally NOT RECOMMENDED. Note that a less versatile yet simpler generally NOT RECOMMENDED. Note that a less versatile yet simpler
approach for resource consumer initiated ALTO server discovery is approach for resource consumer initiated ALTO server discovery is
specified in [RFC7286]. specified in [RFC7286].
4.1.2. IPv4/v6 Dual Stack, Multihoming, NAT, and Host Mobility 5.1.2. IPv4/v6 Dual Stack, Multihoming, NAT, and Host Mobility
The procedure specified in this document can discover ALTO server The procedure specified in this document can discover ALTO server
URIs for a given IP address or prefix. The intention is, that a URIs for a given IP address or prefix. The intention is, that a
third party (e.g., a resource directory) that receives query messages third party (e.g., a resource directory) that receives query messages
from a resource consumer can use the source address in these messages from a resource consumer can use the source address in these messages
to discover suitable ALTO servers for this specific resource to discover suitable ALTO servers for this specific resource
consumer. consumer.
However, resource consumers (as defined in Section 2 of [RFC5693]) However, resource consumers (as defined in Section 2 of [RFC5693])
may reside on hosts with more than one IP address, e.g., due to may reside on hosts with more than one IP address, e.g., due to
skipping to change at page 13, line 14 skipping to change at page 14, line 14
always use the same address for contacting the resource directory and always use the same address for contacting the resource directory and
the resource providers, i.e., overriding the operating system's the resource providers, i.e., overriding the operating system's
automatic source IP address selection, or use resource consumer based automatic source IP address selection, or use resource consumer based
ALTO server discovery [RFC7286] to discover suitable ALTO servers for ALTO server discovery [RFC7286] to discover suitable ALTO servers for
every local address and then locally perform ALTO-influenced resource every local address and then locally perform ALTO-influenced resource
consumer selection and source address selection. Similarly, resource consumer selection and source address selection. Similarly, resource
consumers on mobile hosts SHOULD query the resource directory again consumers on mobile hosts SHOULD query the resource directory again
after a change of IP address, in order to get a list of candidate after a change of IP address, in order to get a list of candidate
resource providers that is optimized for the new IP address. resource providers that is optimized for the new IP address.
4.2. Deployment Considerations for Network Operators 5.2. Deployment Considerations for Network Operators
4.2.1. Separation of Interests 5.2.1. Separation of Interests
We assume that if two organizations share parts of their DNS We assume that if two organizations share parts of their DNS
infrastructure, i.e., have common in-addr.arpa. and/or ip6.arpa. infrastructure, i.e., have common in-addr.arpa. and/or ip6.arpa.
subdomains, they will also be able to operate a common ALTO server, subdomains, they will also be able to operate a common ALTO server,
which still may do redirections if desired or required by policies. which still may do redirections if desired or required by policies.
Note that the ALTO server discovery procedure is supposed to produce Note that the ALTO server discovery procedure is supposed to produce
only a first URI of an ALTO server that can give reasonable guidance only a first URI of an ALTO server that can give reasonable guidance
to the client. An ALTO server can still return different results to the client. An ALTO server can still return different results
based on the client's address (or other identifying properties) or based on the client's address (or other identifying properties) or
redirect the client to another ALTO server using mechanisms of the redirect the client to another ALTO server using mechanisms of the
ALTO protocol (see Sect. 9 of [RFC7285]). ALTO protocol (see Sect. 9 of [RFC7285]).
5. Security Considerations 6. Security Considerations
A high-level discussion of security issues related to ALTO is part of A high-level discussion of security issues related to ALTO is part of
the ALTO problem statement [RFC5693]. A classification of unwanted the ALTO problem statement [RFC5693]. A classification of unwanted
information disclosure risks, as well as specific security-related information disclosure risks, as well as specific security-related
requirements can be found in the ALTO requirements document requirements can be found in the ALTO requirements document
[RFC6708]. [RFC6708].
The remainder of this section focuses on security threats and The remainder of this section focuses on security threats and
protection mechanisms for the cross-domain ALTO server discovery protection mechanisms for the cross-domain ALTO server discovery
procedure as such. Once the ALTO server's URI has been discovered procedure as such. Once the ALTO server's URI has been discovered
and the communication between the ALTO client and the ALTO server and the communication between the ALTO client and the ALTO server
starts, the security threats and protection mechanisms discussed in starts, the security threats and protection mechanisms discussed in
the ALTO protocol specification [RFC7285] apply. the ALTO protocol specification [RFC7285] apply.
5.1. Integrity of the ALTO Server's URI 6.1. Integrity of the ALTO Server's URI
Scenario Description Scenario Description
An attacker could compromise the ALTO server discovery procedure An attacker could compromise the ALTO server discovery procedure
or infrastructure in a way that ALTO clients would discover a or infrastructure in a way that ALTO clients would discover a
"wrong" ALTO server URI. "wrong" ALTO server URI.
Threat Discussion Threat Discussion
This is probably the most serious security concern related to ALTO This is probably the most serious security concern related to ALTO
server discovery. The discovered "wrong" ALTO server might not be server discovery. The discovered "wrong" ALTO server might not be
able to give guidance to a given ALTO client at all, or it might able to give guidance to a given ALTO client at all, or it might
skipping to change at page 15, line 25 skipping to change at page 16, line 25
procedure needs to be secured as described above, e.g., by using procedure needs to be secured as described above, e.g., by using
DNSSEC. DNSSEC.
In addition to active protection mechanisms, users and network In addition to active protection mechanisms, users and network
operators can monitor application performance and network traffic operators can monitor application performance and network traffic
patterns for poor performance or abnormalities. If it turns out patterns for poor performance or abnormalities. If it turns out
that relying on the guidance of a specific ALTO server does not that relying on the guidance of a specific ALTO server does not
result in better-than-random results, the usage of the ALTO server result in better-than-random results, the usage of the ALTO server
may be discontinued (see also Section 15.2 of [RFC7285]). may be discontinued (see also Section 15.2 of [RFC7285]).
5.2. Availability of the ALTO Server Discovery Procedure 6.2. Availability of the ALTO Server Discovery Procedure
Scenario Description Scenario Description
An attacker could compromise the cross-domain ALTO server An attacker could compromise the cross-domain ALTO server
discovery procedure or infrastructure in a way that ALTO clients discovery procedure or infrastructure in a way that ALTO clients
would not be able to discover any ALTO server. would not be able to discover any ALTO server.
Threat Discussion Threat Discussion
If no ALTO server can be discovered (although a suitable one If no ALTO server can be discovered (although a suitable one
exists) applications have to make their decisions without ALTO exists) applications have to make their decisions without ALTO
guidance. As ALTO could be temporarily unavailable for many guidance. As ALTO could be temporarily unavailable for many
reasons, applications must be prepared to do so. However, The reasons, applications must be prepared to do so. However, The
resulting application performance and traffic distribution will resulting application performance and traffic distribution will
correspond to a deployment scenario without ALTO. correspond to a deployment scenario without ALTO.
Protection Strategies and Mechanisms Protection Strategies and Mechanisms
Operators should follow best current practices to secure their DNS Operators should follow best current practices to secure their DNS
and ALTO (see Section 15.5 of [RFC7285]) servers against Denial- and ALTO (see Section 15.5 of [RFC7285]) servers against Denial-
of-Service (DoS) attacks. of-Service (DoS) attacks.
5.3. Confidentiality of the ALTO Server's URI 6.3. Confidentiality of the ALTO Server's URI
Scenario Description Scenario Description
An unauthorized party could invoke the cross-domain ALTO server An unauthorized party could invoke the cross-domain ALTO server
discovery procedure, or intercept discovery messages between an discovery procedure, or intercept discovery messages between an
authorized ALTO client and the DNS servers, in order to acquire authorized ALTO client and the DNS servers, in order to acquire
knowledge of the ALTO server URI for a specific IP address. knowledge of the ALTO server URI for a specific IP address.
Threat Discussion Threat Discussion
In the ALTO use cases that have been described in the ALTO problem In the ALTO use cases that have been described in the ALTO problem
statement [RFC5693] and/or discussed in the ALTO working group, statement [RFC5693] and/or discussed in the ALTO working group,
the ALTO server's URI as such has always been considered as public the ALTO server's URI as such has always been considered as public
information that does not need protection of confidentiality. information that does not need protection of confidentiality.
Protection Strategies and Mechanisms Protection Strategies and Mechanisms
No protection mechanisms for this scenario have been provided, as No protection mechanisms for this scenario have been provided, as
it has not been identified as a relevant threat. However, if a it has not been identified as a relevant threat. However, if a
new use case is identified that requires this kind of protection, new use case is identified that requires this kind of protection,
the suitability of this ALTO server discovery procedure as well as the suitability of this ALTO server discovery procedure as well as
possible security extensions have to be re-evaluated thoroughly. possible security extensions have to be re-evaluated thoroughly.
5.4. Privacy for ALTO Clients 6.4. Privacy for ALTO Clients
Scenario Description Scenario Description
An unauthorized party could intercept messages between an ALTO An unauthorized party could intercept messages between an ALTO
client and the DNS servers, and thereby find out the fact that client and the DNS servers, and thereby find out the fact that
said ALTO client uses (or at least tries to use) the ALTO service said ALTO client uses (or at least tries to use) the ALTO service
in order to optimize traffic from/to a specific IP address. in order to optimize traffic from/to a specific IP address.
Threat Discussion Threat Discussion
In the ALTO use cases that have been described in the ALTO problem In the ALTO use cases that have been described in the ALTO problem
statement [RFC5693] and/or discussed in the ALTO working group, statement [RFC5693] and/or discussed in the ALTO working group,
this scenario has not been identified as a relevant threat. this scenario has not been identified as a relevant threat.
Protection Strategies and Mechanisms Protection Strategies and Mechanisms
No protection mechanisms for this scenario have been provided, as No protection mechanisms for this scenario have been provided, as
it has not been identified as a relevant threat. However, if a it has not been identified as a relevant threat. However, if a
new use case is identified that requires this kind of protection, new use case is identified that requires this kind of protection,
the suitability of this ALTO server discovery procedure as well as the suitability of this ALTO server discovery procedure as well as
possible security extensions have to be re-evaluated thoroughly. possible security extensions have to be re-evaluated thoroughly.
6. IANA Considerations 7. IANA Considerations
This document does not require any IANA action. This document does not require any IANA action.
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596, "DNS Extensions to Support IP Version 6", RFC 3596,
October 2003. October 2003.
[RFC4848] Daigle, L., "Domain-Based Application Service Location [RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007. (DDDS)", RFC 4848, April 2007.
7.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[I-D.kiesel-alto-alto4alto] [I-D.kiesel-alto-alto4alto]
Kiesel, S., "Using ALTO for ALTO server selection", Kiesel, S., "Using ALTO for ALTO server selection",
draft-kiesel-alto-alto4alto-00 (work in progress), draft-kiesel-alto-alto4alto-00 (work in progress),
July 2010. July 2010.
[I-D.kiesel-alto-ip-based-srv-disc] [I-D.kiesel-alto-ip-based-srv-disc]
Kiesel, S. and R. Penno, "Application-Layer Traffic Kiesel, S. and R. Penno, "Application-Layer Traffic
Optimization (ALTO) Anycast Address", Optimization (ALTO) Anycast Address",
draft-kiesel-alto-ip-based-srv-disc-03 (work in progress), draft-kiesel-alto-ip-based-srv-disc-03 (work in progress),
skipping to change at page 20, line 23 skipping to change at page 21, line 23
control of different administrative entities (e.g., different ISPs) control of different administrative entities (e.g., different ISPs)
or that the overall ALTO information is partitioned and stored on or that the overall ALTO information is partitioned and stored on
several ALTO servers. several ALTO servers.
A.1. Classification of Solution Approaches A.1. Classification of Solution Approaches
Various protocol extensions and other solutions have been proposed to Various protocol extensions and other solutions have been proposed to
deal with multiple information sources and partitioned knowledge. deal with multiple information sources and partitioned knowledge.
They can be classified as follows: They can be classified as follows:
1 Ensure that all ALTO servers have the same knowlegde 1 Ensure that all ALTO servers have the same knowledge
1.1 Ensure data replication and synchronization within the 1.1 Ensure data replication and synchronization within the
provisioning protocol (cf. RFC 5693, Fig 1 [RFC5693]). provisioning protocol (cf. RFC 5693, Fig 1 [RFC5693]).
1.2 Use an Inter-ALTO-server data replication protocol. Possibly, 1.2 Use an Inter-ALTO-server data replication protocol. Possibly,
the ALTO protocol itself - maybe with some extensions - could be the ALTO protocol itself - maybe with some extensions - could be
used for that purpose; however, this has not been studied in used for that purpose; however, this has not been studied in
detail so far. detail so far.
2 Accept that different ALTO servers (possibly operated by 2 Accept that different ALTO servers (possibly operated by
skipping to change at page 25, line 10 skipping to change at page 26, line 10
The ALTO cross domain server discovery cannot assume that the server The ALTO cross domain server discovery cannot assume that the server
discovery client and the server discovery responding entity are under discovery client and the server discovery responding entity are under
the same administrative control. the same administrative control.
Appendix C. ALTO and Tracker-based Peer-to-Peer Applications Appendix C. ALTO and Tracker-based Peer-to-Peer Applications
This appendix illustrates one ALTO use case and shows that ALTO This appendix illustrates one ALTO use case and shows that ALTO
Cross-Domain Server Discovery is beneficial in that scenario. Cross-Domain Server Discovery is beneficial in that scenario.
C.1. Architectural Options
The ALTO protocol specification [RFC7285] details how an ALTO client The ALTO protocol specification [RFC7285] details how an ALTO client
can query an ALTO server for guiding information and receive the can query an ALTO server for guiding information and receive the
corresponding replies. However, in the considered scenario of a corresponding replies. However, in the considered scenario of a
tracker-based P2P application, there are two fundamentally different tracker-based P2P application, there are two fundamentally different
possibilities where to place the ALTO client: possibilities where to place the ALTO client:
1. ALTO client in the resource consumer ("peer") 1. ALTO client in the resource consumer ("peer")
2. ALTO client in the resource directory ("tracker") 2. ALTO client in the resource directory ("tracker")
skipping to change at page 28, line 6 skipping to change at page 29, line 6
remote resource consumer remote resource consumer
Note: the message sequences depicted in Figure 2 and Figure 4 may Note: the message sequences depicted in Figure 2 and Figure 4 may
occur both in the target-aware and the target-independent query mode occur both in the target-aware and the target-independent query mode
(c.f. [RFC6708]). In the target-independent query mode no message (c.f. [RFC6708]). In the target-independent query mode no message
exchange with the ALTO server might be needed after the tracker exchange with the ALTO server might be needed after the tracker
query, because the candidate resource providers could be evaluated query, because the candidate resource providers could be evaluated
using a locally cached "map", which has been retrieved from the ALTO using a locally cached "map", which has been retrieved from the ALTO
server some time ago. server some time ago.
C.2. Evaluation
The problem with the first approach is, that while the resource The problem with the first approach is, that while the resource
directory might know thousands of peers taking part in a swarm, the directory might know thousands of peers taking part in a swarm, the
list returned to the resource consumer is usually shortened for list returned to the resource consumer is usually shortened for
efficiency reasons. Therefore, the "best" (in the sense of ALTO) efficiency reasons. Therefore, the "best" (in the sense of ALTO)
potential resource providers might not be contained in that list potential resource providers might not be contained in that list
anymore, even before ALTO can consider them. anymore, even before ALTO can consider them.
For illustration, consider a simple model of a swarm, in which all For illustration, consider a simple model of a swarm, in which all
peers fall into one of only two categories: assume that there are peers fall into one of only two categories: assume that there are
"good" ("good" in the sense of ALTO's better-than-random peer "good" ("good" in the sense of ALTO's better-than-random peer
skipping to change at page 29, line 27 skipping to change at page 30, line 29
Therefore, from an overall optimization perspective, the second Therefore, from an overall optimization perspective, the second
scenario with the ALTO client embedded in the resource directory is scenario with the ALTO client embedded in the resource directory is
advantageous, because it is ensured that the addresses of the "best" advantageous, because it is ensured that the addresses of the "best"
resource providers are actually delivered to the resource consumer. resource providers are actually delivered to the resource consumer.
An architectural implication of this insight is that the ALTO server An architectural implication of this insight is that the ALTO server
discovery procedures must support ALTO queries on behalf of remote discovery procedures must support ALTO queries on behalf of remote
resource consumers. That is, as the tracker issues ALTO queries on resource consumers. That is, as the tracker issues ALTO queries on
behalf of the peer which contacted the tracker, the tracker must be behalf of the peer which contacted the tracker, the tracker must be
able to discover an ALTO server that can give guidance suitable for able to discover an ALTO server that can give guidance suitable for
that respective peer. that respective peer. This task can be solved using the ALTO Cross-
Domain Server Discovery Procedure.
C.3. Example
This section provides a complete example of the ALTO Cross-Domain
Server Discovery Procedure in a tracker-based peer-to-peer scenario.
The example is based on the network topology shown in Figure 5. Five
access networks - Networks a, b, c, x, and t - are operated by five
different network operators. They are interconnected by a backbone
structure. Each network operator runs an ALTO server in their
network, i.e., ALTO_SRV_A, ALTO_SRV_B, ALTO_SRV_C, ALTO_SRV_X, and
ALTO_SRV_T, respectively.
_____ __ _____ __ _____ __
__( )__( )_ __( )__( )_ __( )__( )_
( Network a ) ( Network b ) ( Network c )
( Res. Provider A ) ( Res. Provider B ) ( Res. Provider C )
(__ ALTO_SRV_A __) (__ ALTO_SRV_B __) (__ ALTO_SRV_C __)
(___)--(____) \ (___)--(____) / (___)--(____)
\ / /
---+---------+-----------------+----
( Backbone )
------------+------------------+----
_____ __/ _____ \__
__( )__( )_ __( )__( )_
( Network x ) ( Network t )
( Res. Consumer X ) (Resource Directory)
(_ ALTO_SRV_X __) (_ ALTO_SRV_T __)
(___)--(____) (___)--(____)
Figure 5: Example network topology
A new peer of a peer-to-peer application wants to join a specific
swarm (overlay network), in order to access a specific resource.
This new peer will be called "Resource Consumer X" in accordance to
the terminology of [RFC6708] and it is located in Network x. It
contacts the tracker ("Resource Directory"), which is located in
Network t. The mechanism by which the new peer discovers the tracker
is out of the scope of this document. The tracker maintains a list
of peers that take part in the overlay network, and hence it can
determine that Resource Providers A, B, and C are candidate peers for
Resource Consumer X.
As shown in the previous section, a tracker-side ALTO optimization
(c.f. Figure 3 and Figure 4) is more efficient than a client-side
optimization. Consequently, the tracker wants to use the ALTO
Endpoint Cost Service (ECS) to learn the routing costs between X and
A, X and B, as well as X and C, in order to sort A, B, and C by their
respective routing costs to X.
In theory, there are many options how the ALTO Cross-Domain Server
Discovery Procedure could be used. For example, the tracker could do
the following steps:
IRD_URIS_A = XDOMDISC(A,"ALTO:https")
COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_A
IRD_URIS_B = XDOMDISC(B,"ALTO:https")
COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_B
IRD_URIS_C = XDOMDISC(C,"ALTO:https")
COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_C
Maybe, the ALTO Cross-Domain Server Discovery Procedure queries would
yield in this scenario: IRD_URIS_A = ALTO_SRV_A, IRD_URIS_B =
ALTO_SRV_B, and IRD_URIS_C = ALTO_SRV_C. That is, each ECS query
would be sent to a different ALTO server. The problem with this
approach is that we are not neccessarily able to compare COST_X_A,
COST_X_B, and COST_X_C with each other. The specification of the
routingcost metric mandates that "A lower value indicates a higher
preference", but "an ISP may internally compute routing cost using
any method that it chooses" (see section 6.1.1.1. of [RFC7285]).
Thus, COST_X_A could be 10 (milliseconds round-trip time), while
COST_X_B could be 200 (kilometers great circle distance between the
approximate geographic locations of the hosts) and COST_X_C could be
3 (router hops, corresponding to a decrease of the TTL field in the
IP header). Each of these metrics fulfills the "lower value is more
preferable" requirement on its own, but obviously, they cannot be
compared with each other. Even if there was a reasonable formula to
compare, for example, kilometers with milliseconds, we could not use
it, as the units of measurement (or any other computation method for
the routingcost) are sent not along with the value in the ECS reply.
To avoid this problem, the tracker tries to send all ECS queries to
the same ALTO server. As specified in Section 4.4 of this document,
case 2, it uses the IP address of Resource Consumer x as parameter to
the discovery procedure:
IRD_URIS_X = XDOMDISC(X,"ALTO:https")
COST_X_A = query the ECS(X,A,routingcost) found in IRD_URIS_X
COST_X_B = query the ECS(X,B,routingcost) found in IRD_URIS_X
COST_X_C = query the ECS(X,C,routingcost) found in IRD_URIS_X
This strategy ensures that COST_X_A, COST_X_B, and COST_X_C can be
compared with each other.
As been said, the tracker calls the ALTO Cross-Domain Server
Discovery Procedure with IP address X as a parameter. For the
reminder of this example, we assume that X = 2001:DB8:1:2:227:eff:
fe6a:de42. Thus, the procedure call is
IRD_URIS_X = XDOMDISC(2001:DB8:1:2:227:eff:fe6a:de42,"ALTO:https").
The first parameter 2001:DB8:1:2:227:eff:fe6a:de42 is a single IPv6
address. Thus, we get AT = "IPv6", A = 2001:DB8:1:2:227:eff:fe6a:
de42, L = 128, and SP = "ALTO:https".
The procedure constructs (see Step 1 in Section 3.2)
R128 = "2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.2.0.0.0.1.0.0.0.
8.B.D.0.1.0.0.2.IP6.ARPA.", as well as (see Step 2 in Section 3.3)
R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
R56 = "0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.",
R48 = "1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.", and
R32 = "8.B.D.0.1.0.0.2.IP6.ARPA.".
In order to illustrate the third step of the ALTO Cross-Domain Server
Discovery Procedure, we use the "dig" (domain information groper) DNS
lookup utility that is available for many operating systems (e.g.,
Linux). A real implementation of the ALTO Cross-Domain Server
Discovery Procedure would not be based on the "dig" utility, but use
appropriate libraries and/or operating system APIs. Please note that
the following steps have been performed in a controlled lab
environment with a appropriately configured name server. A suitable
DNS configuration will be needed to reproduce these results. Please
also note that the rather verbose output of the "dig" tool has been
shortened to the relevant lines.
Since AT = "IPv6" and L = 128, in the table given in Section 3.4, the
sixth row (not counting the column headers) applies.
As mandated by the third column, we start with a lookup of R128,
looking for NAPTR resource records:
| sk@labpc12:~$ dig -tNAPTR 2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.\
| 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
|
| ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26553
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0
The domain name R128 does not exist (status: NXDOMAIN), so we cannot
get a useful result. Therefore, we continue with the fourth column
of the table and do a lookup of R64:
| sk@labpc12:~$ dig -tNAPTR 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
|
| ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33193
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0
The domain name R64 could be looked up (status: NOERROR), but there
are no NAPTR resource records associated with it (ANSWER: 0). Maybe,
there are some other resource records such as PTR, NS, or SOA, but we
are not interested in them. Thus, we do not get a useful result and
we continue with looking up R56:
| sk@labpc12:~$ dig -tNAPTR 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
|
| ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35966
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
|
| ;; ANSWER SECTION:
| 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
| "LIS:HELD" "!.*!https://lis1.example.org:4802/?c=ex!" .
| 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 20 "u"
| "LIS:HELD" "!.*!https://lis2.example.org:4802/?c=ex!" .
The domain name R56 could be looked up and there are NAPTR resource
records associated with it. However, each of these records has a
service parameter that does not match our SP = "ALTO:https" (see
[RFC7216] for "LIS:HELD"), and therefore, we have to ignore them.
Consequently, we still do not have a useful result and continue with
a lookup of R48:
| sk@labpc12:~$ dig -tNAPTR 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
|
| ;; Got answer:
| ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50459
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
|
| ;; ANSWER SECTION:
| 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
| "ALTO:https" "!.*!https://alto1.example.net/ird!" .
| 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
| "LIS:HELD" "!.*!https://lis.example.net:4802/?c=ex!" .
This lookup yields two NAPTR resource records. We have to ignore the
second one as its service parameter does not match our SP, but the
first NAPTR resource record has a matching service parameter.
Therefore, the procedure terminates successfully and the final
outcome is: IRD_URIS_X = "https://alto1.example.net/ird".
The ALTO client that is embedded in the tracker will access the ALTO
Information Resource Directory (IRD, see Section 9 of [RFC7285]) at
this URI, look for the Endpoint Cost Service (ECS, see Section 11.5
of [RFC7285]), and query the ECS for the costs between A and X, B and
X, as well as C and X, before returning an ALTO-optimized list of
candidate resource providers to resource consumer X.
Appendix D. Contributors List and Acknowledgments Appendix D. Contributors List and Acknowledgments
The initial version of this document was co-authored by Marco Tomsu The initial version of this document was co-authored by Marco Tomsu
(Alcatel-Lucent). (Alcatel-Lucent).
This document borrows some text from [RFC7286], as historically, it This document borrows some text from [RFC7286], as historically, it
has been part of the draft that eventually became said RFC. Special has been part of the draft that eventually became said RFC. Special
thanks to Michael Scharf and Nico Schwan. thanks to Michael Scharf and Nico Schwan.
skipping to change at page 31, line 17 skipping to change at page 37, line 17
Sebastian Kiesel Sebastian Kiesel
University of Stuttgart Information Center University of Stuttgart Information Center
Allmandring 30 Allmandring 30
Stuttgart 70550 Stuttgart 70550
Germany Germany
Email: ietf-alto@skiesel.de Email: ietf-alto@skiesel.de
URI: http://www.izus.uni-stuttgart.de URI: http://www.izus.uni-stuttgart.de
Martin Stiemerling Martin Stiemerling
University of Applied Sciences Darmstadt, Computer Science Dept. University of Applied Sciences Darmstadt, Computer Science Dept.
Haardtring 100 Haardtring 100
Darmstadt 64295 Darmstadt 64295
Germany Germany
Phone: +49 6151 16 37938 Phone: +49 6151 16 37938
Email: mls.ietf@gmail.com Email: mls.ietf@gmail.com
URI: http://ietf.stiemerling.org URI: http://ietf.stiemerling.org
 End of changes. 66 change blocks. 
168 lines changed or deleted 468 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/