RFC 8686
Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery
RFC 8686: Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery 🦋
The basics: This is a Standards Track doc from the IETF, published in February 2020 as ISSN 2070-1721. The authors are S. Kiesel (University of Stuttgart) and M. Stiemerling (H-DA). It doesn't list any obsoletes or updates in its title block. 💅
Abstract
okay so ALTO (Application-Layer Traffic Optimization) is all about giving apps guidance 🧭 Like, when an app has to pick one or a few hosts out of a bunch of candidates that can all provide the thing it wants, ALTO helps it choose well. ALTO runs as a client-server protocol, and before a client can ask for any of that guidance, it first has to find the ALTO servers that can actually help.
Here's the tea 🍵 Sometimes the info about the network topology is split up and spread across several ALTO servers. In that case, a client might need to find a server that lives outside its own network domain to get good guidance. This doc walks through the scenarios where that happens, lists the requirements, and specifies a procedure for cross-domain server discovery ✨
Technically, the procedure takes one IP address or prefix and a U-NAPTR Service Parameter (usually ALTO:https) as inputs. Then it does DNS lookups for NAPTR resource records in the in-addr.arpa. or ip6.arpa. trees, and it hands back one or more URIs for information resources related to that IP address or prefix 🎀
Status of This Memo
This is an Internet Standards Track document. 🌸
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841 🧚
For info on the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8686 💜
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info (in effect on the date this document was published). Read these carefully, bestie, because they spell out your rights and restrictions for this document. Code components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Simplified BSD License 🫶
Table of Contents
1. Introduction
1.1. Terminology and Requirements Language
2. ALTO Cross-Domain Server Discovery Procedure: Overview
3. ALTO Cross-Domain Server Discovery Procedure: Specification
3.1. Interface
3.2. Step 1: Prepare Domain Name for Reverse DNS Lookup
3.3. Step 2: Prepare Shortened Domain Names
3.4. Step 3: Perform DNS U-NAPTR Lookups
3.5. Error Handling
4. Using the ALTO Protocol with Cross-Domain Server Discovery
4.1. Network and Cost Map Service
4.2. Map-Filtering Service
4.3. Endpoint Property Service
4.4. Endpoint Cost Service
4.5. Summary and Further Extensions
5. Implementation, Deployment, and Operational Considerations
5.1. Considerations for ALTO Clients
5.2. Considerations for Network Operators
6. Security Considerations
6.1. Integrity of the ALTO Server's URI
6.2. Availability of the ALTO Server Discovery Procedure
6.3. Confidentiality of the ALTO Server's URI
6.4. Privacy for ALTO Clients
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Solution Approaches for Partitioned ALTO Knowledge
A.1. Classification of Solution Approaches
A.2. Discussion of Solution Approaches
A.3. The Need for Cross-Domain ALTO Server Discovery
A.4. Our Solution Approach
A.5. Relation to the ALTO Requirements
Appendix B. Requirements for Cross-Domain Server Discovery
B.1. Discovery Client Application Programming Interface
B.2. Data Storage and Authority Requirements
B.3. Cross-Domain Operations Requirements
B.4. Protocol Requirements
B.5. Further Requirements
Appendix C. ALTO and Tracker-Based Peer-to-Peer Applications
C.1. A Generic Tracker-Based Peer-to-Peer Application
C.2. Architectural Options for Placing the ALTO Client
C.3. Evaluation
C.4. Example
Acknowledgments
Authors' Addresses1. Introduction ✨
ALTO's whole thing is giving guidance to apps that need to select one or several hosts from a set of candidates that can all provide a resource they want [RFC5693]. It's realized as an HTTP-based client-server protocol [RFC7285], and it can be used in a bunch of different scenarios [RFC7971] 💖
The ALTO base protocol document [RFC7285] covers the communication between one ALTO client and one ALTO server. In principle, the client can send any ALTO query it likes. For example, it could ask for the routing cost between any two IP addresses, or request network and cost maps for the entire network, which might be the whole worldwide Internet 🌍 The assumption is that the server can answer any query, maybe with some kind of default value when it doesn't know the exact answer.
Here's the plot twist 😭 The base protocol didn't make any special plans for deployments with multiple ALTO servers, where some servers know more about some parts of the network and other servers know more about other parts. That's called "partitioned knowledge." People have studied a bunch of ALTO use cases in this setting. In some cases, you can't assume that a topologically nearby ALTO server (for example, one found with the procedure in [RFC7286]) will always give the client useful info. Appendix C walks through one such scenario. Several solution approaches have been proposed and analyzed (see Appendix A), like redirecting a client to a server with more accurate info, or forwarding the request to that server on the client's behalf. But so far, no solution has been specified 🙈
Section 3 of this document is where the "ALTO Cross-Domain Server Discovery Procedure" gets specified, for client-side use in these situations. An ALTO client that wants to send an ALTO query related to a specific IP address or prefix X can call this procedure with X as the parameter. It uses Domain Name System (DNS) lookups to find one or more ALTO servers that can give a competent answer 🧠 The phrase "related to" was kept a bit vague on purpose, since what it actually means depends on the ALTO service being used. More on that in Section 4.
Now, who gets to add these records? Whoever controls the "reverse DNS" for a given IP address or prefix can do it. That means the corresponding subdomain of in-addr.arpa. or ip6.arpa., and that's usually an Internet Service Provider (ISP), a corporate IT department, or a university's computing center 🏫 Those folks can add resource records to the DNS that point to one or more relevant ALTO servers. Often it'll be an ALTO server run by that ISP or IT department, since they naturally have great insight into routing costs to and from their networks. But they could also point to an ALTO server run by someone else, like their upstream ISP 💜
1.1. Terminology and Requirements Language
This document uses the ALTO terminology defined in RFC 5693 [RFC5693] 📚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. That's the rule for the caps 🎀
2. ALTO Cross-Domain Server Discovery Procedure: Overview 🗺️
This section is a non-normative overview of the ALTO Cross-Domain Server Discovery Procedure. The detailed spec comes in the next section, so don't worry 💅
This procedure was inspired by "Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS" [RFC7216], and it reuses parts of the basic ALTO Server Discovery Procedure [RFC7286] 🦋
The big idea is to use the Domain Name System (DNS), specifically the in-addr.arpa. or ip6.arpa. trees. Those are mostly used for "reverse mapping," which turns IP addresses back into host names using PTR resource records. On top of that, URI-enabled Naming Authority Pointer (U-NAPTR) resource records [RFC4848] get installed as needed. U-NAPTR records map domain names to Uniform Resource Identifiers (URIs). So you can store a mapping from an IP address or prefix to one or more ALTO server URIs in the DNS, and that's the whole trick ✨
The ALTO Cross-Domain Server Discovery Procedure gets called with one IP address or prefix, plus a U-NAPTR Service Parameter [RFC4848], as its parameters 🧚
The service parameter is usually ALTO:https. Other values can work in some scenarios, though. For instance, ALTO:http can be used to find a server that supports unencrypted transmission for debugging purposes, and other application protocol or service tags work too if they apply 🔍
The procedure performs DNS lookups and returns one or more URIs of information resources related to that IP address or prefix. Usually those are the URIs of one or more ALTO Information Resource Directories (IRDs; see Section 9 of [RFC7285]). The U-NAPTR records also carry preference values, which should be considered if more than one URI comes back 🌈
Here's how the discovery procedure works: it tries two lookup strategies, one after the other. First, it searches for an ALTO-specific U-NAPTR record in the "reverse tree." That means subdomains of in-addr.arpa. or ip6.arpa. that match the given IP address or prefix. If that lookup doesn't give a usable result, it tries more lookups with truncated domain names, which match shorter prefix lengths. The point is to support deployments that need fine-grained discovery on a per-IP basis, and also large-scale setups where discovery is enabled for a huge number of IP addresses using only a small number of extra DNS resource records 🍓
Part 1 of 9. Next up: Section 3, the actual Cross-Domain Server Discovery Procedure specification.
3.1. Interface 💖
okay so this procedure takes two parameters, X and SP 🎀. X is an IP address or prefix, and SP is a U-NAPTR Service Parameter.
X can be an IPv4 or IPv6 address or prefix in Classless Inter-Domain Routing (CIDR) notation. For IPv4 that's the notation from [RFC4632], and for IPv6 it's from [RFC4291] ✨. So the address type AT is either IPv4 or IPv6, and in both cases X is made of an IP address A and a prefix length L. Based on the IPv4 and IPv6 definitions, syntactically valid values for L are 0 <= L <= 32 when AT=IPv4 and 0 <= L <= 128 when AT=IPv6. 👀 But not every syntactically valid L is actually supported. Step 1 checks for the unsupported ones and reports an error if needed.
For example, X=198.51.100.0/24 gives us AT=IPv4, A=198.51.100.0, and L=24. And X=2001:0DB8::20/128 gives us AT=IPv6, A=2001:0DB8::20, and L=128 🦋.
In the intended usage scenario, the procedure is almost always called with SP set to ALTO:https. But for general applicability and to support future extensions, the procedure MUST support being called with any valid U-NAPTR Service Parameter 🔥. (See Section 4.5 of [RFC4848] for the syntax of U-NAPTR Service Parameters, and Section 5 of that same document for the IANA registries.) Main character energy for future-proofing, honestly 💅.
The procedure does DNS lookups and returns one or more URIs of information resources related to that IP address or prefix. Usually those are the URIs of one or more ALTO Information Resource Directories (IRDs; 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 comes back.
Various error conditions may happen while this runs, and they have to be reported to the caller. See Section 3.5 for those 🚨.
For the rest of the document, we use this 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 🧚
First, the procedure checks the prefix length L for unsupported values. If AT=IPv4 (so A is an IPv4 address) and L < 8, the procedure aborts and reports an "unsupported prefix length" error to the caller 🙈. Same deal for AT=IPv6 with L < 32: abort, and report "unsupported prefix length". Otherwise, it keeps going.
If AT=IPv4, the procedure then produces a DNS domain name called R32. This name is built using the rules in Section 3.5 of [RFC1035], and it's rooted in the special domain IN-ADDR.ARPA. 🍓.
For example, A=198.51.100.3 gives us:
R32="3.100.51.198.IN-ADDR.ARPA."If AT=IPv6, a domain name called R128 is built using the rules in Section 2.5 of [RFC3596], and this time the special domain IP6.ARPA. is used 💜.
For example (note: a line break was added after the second line):
A = 2001:0DB8::20 yields
R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
1.0.0.2.IP6.ARPA."3.3. Step 2: Prepare Shortened Domain Names ✂️
For this step there's an auxiliary function called "skip". skip(str,n) skips all characters in the string str, up to and including the n-th dot, and then returns whatever's left of str. For example, skip("foo.bar.baz.qux.quux.",2) returns "baz.qux.quux." 🫶.
If AT=IPv4, these extra domain names come from the result of the previous step:
R24=skip(R32,1),R16=skip(R32,2), andR8=skip(R32,3).
Dropping one label (one number of the "dotted quad notation") is the same as shortening the prefix length by 8 bits 🌈.
For example:
R32="3.100.51.198.IN-ADDR.ARPA." yields
R24="100.51.198.IN-ADDR.ARPA."
R16="51.198.IN-ADDR.ARPA."
R8="198.IN-ADDR.ARPA."If AT=IPv6, these extra domain names come from the result of the previous step:
R64=skip(R128,16),R56=skip(R128,18),R48=skip(R128,20),R40=skip(R128,22), andR32=skip(R128,24).
Dropping one label (one hex digit) is the same as shortening the prefix length by 4 bits ⭐.
For example (note: a line break was added after the first line):
R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
1.0.0.2.IP6.ARPA." yields
R64 = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R56 = "0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R48 = "0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R32 = "8.B.D.0.1.0.0.2.IP6.ARPA."3.4. Step 3: Perform DNS U-NAPTR Lookups 🔍
The address type and prefix length of X get matched against the first and second columns of this table. Those are the sweet spots, babe 🥰.
+------------+-----------+------------+-----------------------+
| 1: Address | 2: Prefix | 3: MUST do | 4: SHOULD do further |
| Type AT | Length L | 1st lookup | lookups in that order |
+============+===========+============+=======================+
| IPv4 | 32 | R32 | R24, R16, R8 |
+------------+-----------+------------+-----------------------+
| IPv4 | 24 .. 31 | R24 | R16, R8 |
+------------+-----------+------------+-----------------------+
| IPv4 | 16 .. 23 | R16 | R8 |
+------------+-----------+------------+-----------------------+
| IPv4 | 8 .. 15 | R8 | (none) |
+------------+-----------+------------+-----------------------+
| IPv4 | 0 .. 7 | (none, abort: unsupported prefix |
| | | length) |
+------------+-----------+------------+-----------------------+
| IPv6 | 128 | R128 | R64, R56, R48, R40, |
| | | | R32 |
+------------+-----------+------------+-----------------------+
| IPv6 | 64 | R64 | R56, R48, R40, R32 |
| | (..127) | | |
+------------+-----------+------------+-----------------------+
| IPv6 | 56 .. 63 | R56 | R48, R40, R32 |
+------------+-----------+------------+-----------------------+
| IPv6 | 48 .. 55 | R48 | R40, R32 |
+------------+-----------+------------+-----------------------+
| IPv6 | 40 .. 47 | R40 | R32 |
+------------+-----------+------------+-----------------------+
| IPv6 | 32 .. 39 | R32 | (none) |
+------------+-----------+------------+-----------------------+
| IPv6 | 0 .. 31 | (none, abort: unsupported prefix |
| | | length) |
+------------+-----------+------------------------------------+
Table 1: Perform DNS U-NAPTR lookupsThen the domain name from the 3rd column and the U-NAPTR Service Parameter SP that the procedure was called with (usually "ALTO:https") MUST be used for a U-NAPTR lookup, per [RFC4848] 🎯. The goal is to get one or more URIs (protocol, host, and maybe path elements) for the ALTO server's Information Resource Directory (IRD). If you find those URIs, the ALTO Cross-Domain Server Discovery Procedure returns that info to the caller and ends successfully 🎉.
For example, these two U-NAPTR resource records map "100.51.198.IN-ADDR.ARPA." (aka R24 from the example in the previous step) to the HTTPS URIs "https://alto1.example.net/ird" and "https://alto2.example.net/ird", with the first one preferred:
100.51.198.IN-ADDR.ARPA. IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://alto1.example.net/ird!" ""
100.51.198.IN-ADDR.ARPA. IN NAPTR 100 20 "u" "ALTO:https"
"!.*!https://alto2.example.net/ird!" ""If there are no matching U-NAPTR records, the procedure SHOULD try further lookups, using the domain names from the fourth column in the listed order, until one of them works 🌟. If no IRD URI turns up after looking up every domain name from the 3rd and 4th columns, the procedure ends unsuccessfully and returns an empty URI list 😭.
3.5. Error Handling 🚨
The ALTO Cross-Domain Server Discovery Procedure can fail for a bunch of reasons, bestie 💀.
If the procedure gets called with syntactically invalid parameters or unsupported parameter values (in particular the prefix length L; see Section 3.2), it aborts. No URI list gets returned, and the error has to be reported to the caller 🙅♀️.
The procedure does one or more DNS lookups in a well-defined order (descending prefix lengths, see Section 3.4) until one of them gives a usable result. Each lookup might not produce something usable, and there are three flavours of that. There's a normal condition (for example, a domain name exists but has no ALTO-specific NAPTR resource records attached). There's a permanent error (for example, a nonexistent domain name). And there's a temporary error (for example, a timeout) 🥺. In all three cases, and as long as there are more domain names to look up, the procedure SHOULD immediately try the next domain name (from Column 4 in the table in Section 3.4). Only after every domain name has been tried at least once MAY the procedure retry the domain names that hit temporary lookup errors 🔁.
Generally speaking, ALTO gives advisory info for optimising applications (peer-to-peer applications, overlay networks, etc.). Applications should not rely on that info being available for their basic functionality (see Section 8.3.4.3 of [RFC7285]) 🫠. So a fast detection of an ALTO server is usually better, even if it gives less accurate answers than other servers. The same goes for quickly realising there's no suitable ALTO server, rather than causing long delays by retrying failed queries ⏩. Still, if DNS queries failed because of temporary errors, the ALTO Cross-Domain Server Discovery Procedure SHOULD tell its caller that the DNS queries failed for that reason, and that retrying discovery at a later point might give more accurate results ⭐.
4. Using the ALTO Protocol with Cross-Domain Server Discovery ✨
okay so ALTO is built like a modular wardrobe 👗, where each ALTO service is its own outfit made of information resources you can access through the ALTO protocol. The list of resources on a given ALTO server lives in its Information Resource Directory (IRD, see Section 9 of [RFC7285]) 💅. The ALTO protocol spec defines these services and their resources:
- Network and Cost Map Service, see Section 11.2 of [RFC7285]
- Map-Filtering Service, see Section 11.3 of [RFC7285]
- Endpoint Property Service, see Section 11.4 of [RFC7285]
- Endpoint Cost Service, see Section 11.5 of [RFC7285]
The ALTO Cross-Domain Server Discovery Procedure is most useful together with the Endpoint Property Service and the Endpoint Cost Service 🎀. Still, for completeness, we talk through how it interacts with all four services below. Extension documents can define more information resources too, but those are outside the scope of this document 🦋.
4.1. Network and Cost Map Service
An ALTO client can run the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) for an IP address or prefix X and get back a list of one or more IRD URIs, with order and preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The IRDs behind these URIs will always contain a network map and a cost map, because those are mandatory information resources (see Section 11.2 of [RFC7285]) 🫶. Heads up though, the cost matrix can be super sparse 🙈. If PID_X is the Provider-defined Identifier (PID; see Section 5.1 of [RFC7285]) that contains the IP address or prefix X, and PID_1, PID_2, PID_3, ... are other PIDs, the cost map might look like this:
+-------+----------+-------+-------+-------+
| From | To PID_1 | PID_2 | PID_X | PID_3 |
+=======+==========+=======+=======+=======+
| PID_1 | | | 92 | |
+-------+----------+-------+-------+-------+
| PID_2 | | | 6 | |
+-------+----------+-------+-------+-------+
| PID_X | 46 | 3 | 1 | 19 |
+-------+----------+-------+-------+-------+
| PID_3 | | | 38 | |
+-------+----------+-------+-------+-------+
Table 2: Cost MapIn this example, every cell outside Column X and Row X is unspecified 🌸. A cost map shaped like this holds the same info you could get from the Endpoint Cost Service, Cases 1 and 2 in Section 4.4. Accessing cells that are neither in Column X nor Row X may not give useful results 💀.
Building a denser cost map by stitching together several of these sparse ones can be a nontrivial task 😭. The reason is that different ALTO servers may use different PID definitions (i.e., network maps) and incompatible scales for the costs, especially for the "routingcost" metric.
4.2. Map-Filtering Service
An ALTO client can run the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) for an IP address or prefix X and get back a list of one or more IRD URIs, with order and preference values: IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These IRDs may offer the optional Map-Filtering Service (see Section 11.3 of [RFC7285]) ✨. This service returns a subset of the full map, based on what the client asks for. As we saw in Section 4.1, a cost map can be very sparse in this deployment scenario 🍓. So depending on the filtering criteria the client provides, this service might return results that look like the Endpoint Cost Service, or it might not return anything useful at all 🤷♀️.
4.3. Endpoint Property Service
If an ALTO client wants to query the Endpoint Property Service (see Section 11.4 of [RFC7285]) about an endpoint with IP address X, or about a group of endpoints within IP prefix X, it has to run the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3): IRD_URIS_X = XDOMDISC(X,"ALTO:https") 🧚. The result, IRD_URIS_X, is a list of one or more URIs of Information Resource Directories (IRDs, see Section 9 of [RFC7285]). The client looks at the order and preference values, then checks those IRDs for a suitable Endpoint Property Service and queries it 💜.
If the client wants to do a similar Endpoint Property query for a different IP address or prefix "Y", the whole procedure has to be repeated 🔁. That's because IRD_URIS_Y = XDOMDISC(Y,"ALTO:https") may give back a different list of IRD URIs. Of course, the results of individual DNS queries can be cached for as long as their respective time-to-live (TTL) values say 🦋.
4.4. Endpoint Cost Service
The optional ALTO Endpoint Cost Service (ECS; see Section 11.5 of [RFC7285]) gives you the costs between individual endpoints and also supports ranking 📊. The ECS lets endpoints be denoted by IP addresses or prefixes. The ECS is called with a list of one or more source IP addresses or prefixes, which we'll call (S1, S2, S3, ...), and a list of one or more destination IP addresses or prefixes, called (D1, D2, D3, ...) 💖.
This specification distinguishes several cases, depending on how many elements are in the source and destination lists:
- Exactly one source address S1 and more than one destination address (D1, D2, D3, ...). In this case, the ALTO client has to run the ALTO Cross-Domain Server Discovery Procedure (as specified in Section 3) with that single source address as a parameter:
IRD_URIS_S1 = XDOMDISC(S1,"ALTO:https"). The result, IRD_URIS_S1, is a list of one or more URIs of Information Resource Directories (IRDs, see Section 9 of [RFC7285]). The client looks at the order and preference values, then checks those IRDs for a suitable Endpoint Cost Service and queries it. The ECS is an optional service (see Section 11.5.1 of [RFC7285]), so it's totally possible that an IRD doesn't refer to an ECS 🥺.
Calling the Cross-Domain Server Discovery Procedure only once, with the single source address as a parameter, is not only about efficiency 🧠. Compared with making multiple calls (for example, one per destination address), it's advisable to send all ECS queries to the same ALTO server. That way the results can be compared (e.g., for sorting candidate resource providers), even when cost metrics lack a well-defined base unit, like the "routingcost" metric 💅.
- More than one source address (S1, S2, S3, ...) and exactly one destination address D1. In this case, the ALTO client has to run the ALTO Cross-Domain Server Discovery Procedure with that single destination address as a parameter:
IRD_URIS_D1 = XDOMDISC(D1,"ALTO:https"). The result, IRD_URIS_D1, is a list of one or more URIs of IRDs. The client looks at the order and preference values, then checks those IRDs for a suitable ECS and queries it 🌈. - Exactly one source address S1 and exactly one destination address D1. The ALTO client may do the same steps as in Case 1, as specified above. As an alternative, it may also do the same steps as in Case 2, as specified above 🦄.
- More than one source address (S1, S2, S3, ...) and more than one destination address (D1, D2, D3, ...). In this case, the ALTO client should split the list of desired queries based on source addresses, and perform the same steps as in Case 1 separately for each source address, as specified above. As an alternative, the ALTO client may also group the list based on destination addresses, and perform the same steps as in Case 2 separately for each destination address, as specified above. Just know that comparing results between these subqueries may be difficult, especially if the cost metric is a relative preference without a well-defined base unit (e.g., the "routingcost" metric) 😵💫.
See Appendix C for a detailed example of how a tracker-based peer-to-peer application, the ALTO Endpoint Cost Service, and the ALTO Cross-Domain Server Discovery Procedure all work together 🎬.
4.5. Summary and Further Extensions
Of the four services 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 earlier sections explain how the parameter for the ALTO Cross-Domain Server Discovery Procedure gets derived from those IP addresses 💕.
By contrast, the procedure seems less useful if the goal is to retrieve network and cost maps that cover the whole network topology 🗺️. It can still be useful if you want a map centered on a specific IP address (i.e., a map detailing the vicinity of that IP address, or a map giving costs from that IP address to all potential destinations) ⭐.
How the other ALTO services (and their corresponding information resources) interact needs to be investigated and defined once those services get specified in an extension document 🔮.
5. Implementation, Deployment, and Operational Considerations ✨
5.1. Considerations for ALTO Clients
5.1.1. Resource-Consumer-Initiated Discovery
Resource-consumer-initiated ALTO server discovery (cf. ALTO requirement AR-32 [RFC6708]) can be seen as a special case of cross-domain ALTO server discovery 🌟. To do that, an ALTO client embedded in a resource consumer would have to run the ALTO Cross-Domain Server Discovery Procedure with its own IP address as a parameter 🪞. But because Network Address Translators (NATs) are so widely deployed, extra protocols and mechanisms are usually needed first, such as Session Traversal Utilities for NAT (STUN) [RFC5389], to detect the client's "public" IP address before it can be used as a parameter for the discovery procedure 😤. Heads up: a different approach to resource-consumer-initiated ALTO server discovery, which is based on DHCP, is specified in [RFC7286] 📡.
5.1.2. IPv4/v6 Dual Stack, Multihoming and Host Mobility 🌸
okay so this bit is about what happens when one device has more than one IP address, bestie 💅 ALTO server discovery works off a given IP address or prefix. The idea is that a third party, like a resource directory, gets query messages from a resource consumer and uses the source address in those messages to find suitable ALTO servers for that specific consumer 🦋
BUT here's the twist. Resource consumers (as defined in Section 2 of [RFC5693]) can live on hosts with more than one IP address. Think IPv4/v6 dual stack or multihoming 🫶 Packets sent with different source addresses can take different routing policies and path costs, so it's giving "different routes, different costs." In some deployments, you might even need to ask different sets of ALTO servers for guidance 👑 And source addresses can get rewritten en route by Network Address Translators (NATs) 🙈
Now the tea ☕ If a resource consumer asks a resource directory for candidate resource providers, the source address the directory sees (the one the consumer picked locally, possibly translated by a NAT on the way) becomes the basis for both the ALTO server discovery and the optimization of the directory's reply. If the consumer then picks a different source address to contact the returned providers, the better-than-random "ALTO effect" may not happen 😭 Not it!!
One fix is for a dual-stack or multihomed consumer to always use the same address for the resource directory and all resource providers. That basically overrides the operating system's automatic source address picking 💖 For example, with the BSD socket API, you could always bind() the socket to one local IP address before calling connect() to the resource directory or the resource providers 🎀 Another approach is to do ALTO-influenced provider selection (and source-address selection) locally in the resource consumer, either on top of the directory's work or instead of it 🧚 Check out Section 5.1.1 to see how a resource consumer can discover ALTO servers for its own local use ✨
And one more thing, bestie: resource consumers on mobile hosts SHOULD query the resource directory again after a change of IP address, so they get a list of candidate providers that's optimized for the new address 🍓
5.1.3. Interaction with Network Address Translation 🦋
The ALTO Cross-Domain Server Discovery Procedure was designed to power apps like large-scale overlay networks that span multiple administrative domains at the IP layer, possibly the whole Internet 🌈 Because NATs are everywhere, overlay nodes (resource consumers or resource providers) may sit behind a NAT, or even behind several cascaded NATs 💀
Here's how it plays out. If a resource directory lives on the public Internet (not behind a NAT) and gets a message from a consumer behind one or more NATs, the message's source address will be the public IP address of the outermost NAT in front of that consumer 🫶 Same deal if the directory sits behind a different NAT than the consumer. The directory may call the ALTO Cross-Domain Server Discovery Procedure with that source address as a parameter. So the consumer's private IP isn't what gets used. The public IP of the outermost NAT is what becomes the basis for ALTO optimization 🌸 This works fine as long as the network behind the NAT isn't too big (think a residential gateway) 🏠
Now, if a resource directory gets a message from a consumer and the source address is a "private" IP address [RFC1918], that might mean both of them are behind the same NAT 👀 Calling the discovery procedure with that private address can be problematic. It only yields usable results if a DNS "split horizon" and DNSSEC trust anchors are configured correctly 😭 In this situation, it may be more advisable to query an ALTO server discovered using [RFC7286] or through any other local configuration 🧚 How intradomain ALTO works for large private domains (like behind a "carrier-grade NAT") versus cross-domain, Internet-wide optimization is beyond the scope of this document 💜
5.2. Considerations for Network Operators 🎀
5.2.1. Flexibility vs. Load on the DNS 💅
Okay, so the procedure from Section 3 first builds a list of domain names (Steps 1 and 2), then looks for relevant NAPTR records tied to those names until it finds something useful (Step 3) ✨ The number of candidate domain names on that list is a compromise between flexibility when installing NAPTR records and avoiding excess load on the DNS 🫶
A single invocation with an IPv6 address as a parameter may cause up to, but no more than, six DNS lookups for NAPTR records. For IPv4, the max is four lookups 🔥 If DNS load from these lookups becomes a problem, one approach is to populate the DNS with ALTO-specific NAPTR records. If such records can be found for individual IP addresses (maybe installed using a wildcarding mechanism in the name server) or long prefixes, the procedure terminates successfully and doesn't do lookups for shorter prefix lengths, which cuts down on total DNS queries 🌈 Another way to reduce DNS load is to increase the TTL for caching negative answers 💖
On the flip side, trying truncated domain names lets the procedure set up large-scale scenarios really efficiently. You can enable discovery for a huge number of IP addresses with just a few extra DNS resource records 🦋 Note that it expressly was not a design goal to give clients a way to understand the IP prefix delegation structure 🙈 Also, this spec doesn't assume or recommend that prefix delegations should happen at the prefix lengths used in Step 2 (see Section 3.3) 🍓 For example, an operator with an IPv4 /18 prefix who wants to install NAPTR records efficiently could either install 64 NAPTR records (one for each /24 inside the /18), or team up with the owners of the other fragments of the enclosing /16 prefix to run a common ALTO server that only one NAPTR points to 🧚
5.2.2. BCP 20 and Missing Delegations of the Reverse DNS 🌸
[RFC2317], also known as BCP 20, describes a way to delegate the "reverse DNS" (subdomains of "in-addr.arpa.") for IPv4 address ranges with fewer than 256 addresses (less than a whole /24 prefix) 💜 The ALTO Cross-Domain Server Discovery Procedure is compatible with this method ✨
In some deployments, like residential Internet access, customers often get a single IPv4 address (and/or a small IPv6 block) dynamically from a pool. ISPs typically won't delegate the "reverse DNS" to those customers 😭 That makes it impossible for them to populate the DNS with NAPTR records pointing to an ALTO server of their choice. But the ISP can still publish NAPTR records in the "reverse DNS" for individual addresses or larger address pools (shorter prefix lengths) 🫶
ALTO isn't technologically tied to the Border Gateway Protocol (BGP), but BGP is expected to be an important source of information for ALTO. The operator of the outermost BGP-enabled router will have a strong incentive to publish a digest of their routing policies and costs through ALTO 👑 By contrast, an individual user or organization assigned only a small address range (an IPv4 prefix longer than /24) usually connects through a single ISP and may not be interested in publishing their own ALTO info 🎀 So they might leave ALTO server operation up to their ISP 💅 That ISP may install the NAPTR records needed for the discovery procedure in the "in-addr.arpa." subdomain for the whole /24 prefix (cf. R24 in Section 3.3), even if BCP 20 delegations or no delegations at all are in use 🦋
6. Security Considerations 🔥
A high-level discussion of security issues related to ALTO is part of the ALTO problem statement [RFC5693] 🍓 A classification of unwanted information disclosure risks, plus specific security-related requirements, can be found in the ALTO requirements document [RFC6708] 💀
The rest of this section focuses on security threats and protection mechanisms for the Cross-Domain ALTO Server Discovery Procedure itself. Once the ALTO server's URI has been discovered and communication between the ALTO client and the ALTO server starts, the security threats and protection mechanisms discussed in the ALTO protocol specification [RFC7285] apply 😭🌈
6.1. Integrity of the ALTO Server's URI
Scenario Description 🕵️
Picture this: an attacker messes with the ALTO server discovery procedure, or with the infrastructure under it, so ALTO clients end up discovering a "wrong" ALTO server URI 💀.
Threat Discussion 😱
The Cross-Domain ALTO Server Discovery Procedure runs a series of DNS lookups to produce one or more URIs. If an attacker can modify or spoof any of those DNS records, the URIs can get replaced with forged ones. This is probably the biggest security worry for ALTO server discovery 😭. The "wrong" ALTO server might not be able to guide the ALTO client at all, or it might give suboptimal or forged info. In that second case, an attacker could try to use ALTO to mess with traffic distribution in the network or with application performance (see also Section 15.1 of [RFC7285]). And a hostile ALTO server could threaten user privacy too (see also Case (5a) in Section 5.2.1 of [RFC6708]).
Protection Strategies and Mechanisms 🔐
DNSSEC [RFC4033] is the move for detecting and averting attacks that rely on changing DNS records while they're in transit ✨. All implementations of the Cross-Domain ALTO Server Discovery Procedure MUST support DNSSEC, or be able to use that functionality from the underlying operating system. Network operators who publish U-NAPTR resource records for this procedure SHOULD use DNSSEC to protect their subdomains of in-addr.arpa. and/or ip6.arpa., respectively. Extra operational precautions are required for safely running the DNS infrastructure, so name servers don't sign forged (or otherwise "wrong") resource records 🙅♀️. Security considerations specific to U-NAPTR get a deeper dive in [RFC4848].
Beyond active protection, users and network operators can also watch application performance and network traffic patterns for poor performance or abnormalities 👀. If relying on a specific ALTO server's guidance doesn't do better than random, the usage of that ALTO server may be discontinued (see also Section 15.2 of [RFC7285]).
Note 📝
The Cross-Domain ALTO Server Discovery Procedure is a success once it has discovered one or more URIs 🎉. After an ALTO server's URI has been discovered and the ALTO client and ALTO server start talking, the security threats and protection mechanisms in the ALTO protocol specification [RFC7285] apply.
A related threat is impersonating an ALTO server after its correct URI has been discovered 🎭. That threat and its protection strategies are covered in Section 15.1 of [RFC7285]. The ALTO protocol's main mechanism for protecting authenticity, integrity (and confidentiality) is HTTPS-based transport, i.e., HTTP over TLS [RFC2818]. When the URI's host component is a host name, a further DNS lookup is usually needed to map it to an IP address before the communication can begin. That last lookup (for A or AAAA resource records) doesn't necessarily have to be protected by DNSSEC, because the server identity checks specified in [RFC2818] can detect DNS spoofing or similar attacks after the connection to the (possibly wrong) host has been made 🧐. But that validation, which is based on the server certificate, can only protect the steps that happen after the server URI has been discovered. It can't detect attacks on the authenticity of the U-NAPTR lookups needed for the Cross-Domain ALTO Server Discovery Procedure, so those resource records have to be secured using DNSSEC 🔒.
6.2. Availability of the ALTO Server Discovery Procedure
Scenario Description 🚫
An attacker could mess with the Cross-Domain ALTO Server Discovery Procedure, or the infrastructure under it, so ALTO clients can't discover any ALTO server 😩.
Threat Discussion 📉
If no ALTO server can be discovered (even though a suitable one exists), applications have to make their decisions without ALTO guidance 🤷♀️. ALTO could be temporarily unavailable for lots of reasons, so applications need to be ready for that. Still, the resulting application performance and traffic distribution will look like a deployment without ALTO at all.
Protection Strategies and Mechanisms 🛡️
Operators should follow best current practices to secure their DNS and ALTO servers (see Section 15.5 of [RFC7285]) against Denial-of-Service (DoS) attacks 💪.
6.3. Confidentiality of the ALTO Server's URI
Scenario Description 🤫
An unauthorized party could run the Cross-Domain ALTO Server Discovery Procedure, or intercept discovery messages between an authorized ALTO client and the DNS servers, to learn the ALTO server URI for a specific IP address 👂.
Threat Discussion 📣
In the ALTO use cases described in the ALTO problem statement [RFC5693] and/or discussed in the ALTO working group, the ALTO server's URI itself has always been treated as public information that doesn't need confidentiality protection 🌍.
Protection Strategies and Mechanisms 🫤
No protection mechanisms have been provided for this scenario, since it hasn't been identified as a relevant threat. However, if a new use case shows up that does need this kind of protection, the suitability of this ALTO server discovery procedure, as well as possible security extensions, will have to be re-evaluated thoroughly 🔁.
6.4. Privacy for ALTO Clients
Scenario Description 🥸
An unauthorized party could eavesdrop on the messages between an ALTO client and the DNS servers, and thereby find out that the ALTO client uses (or at least tries to use) the ALTO service to optimize traffic from/to a specific IP address 👀.
Threat Discussion 🌐
In the ALTO use cases described in the ALTO problem statement [RFC5693] and/or discussed in the ALTO working group, this scenario hasn't been identified as a relevant threat. However, pervasive surveillance [RFC7624] and DNS privacy considerations [RFC7626] have gotten a lot of attention in the Internet community in recent years 🕰️.
Protection Strategies and Mechanisms 💜
DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] are the tools for protecting the confidentiality (and integrity) of DNS traffic between a client (stub) and its recursive name servers 🔐🎀. That includes DNS queries and replies caused by the ALTO Cross-Domain Server Discovery Procedure.
7. IANA Considerations 🌸
Good news, bestie: this document has no IANA actions 💖.
8. References 📚
8.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, DOI 10.17487/RFC3403, October 2002,
<https://www.rfc-editor.org/info/rfc3403>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", STD 88,
RFC 3596, DOI 10.17487/RFC3596, October 2003,
<https://www.rfc-editor.org/info/rfc3596>.
[RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007,
<https://www.rfc-editor.org/info/rfc4848>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.8.2. Informative References ✨
okay bestie, these are the informative references 🎀 they're the extra reading list, not the must-read stuff. the spec leans on them for background, so they're worth knowing about 🧚
[ALTO-ANYCAST] Kiesel, S. and R. Penno, "Application-Layer Traffic Optimization (ALTO) Anycast Address", Work in Progress, Internet-Draft, draft-kiesel-alto-ip-based-srv-disc-03, 1 July 2014, <https://tools.ietf.org/html/draft-kiesel-alto- ip-based-srv-disc-03>.
[ALTO4ALTO] Kiesel, S., "Using ALTO for ALTO server selection", Work in Progress, Internet-Draft, draft-kiesel-alto-alto4alto- 00, 5 July 2010, <https://tools.ietf.org/html/draft- kiesel-alto-alto4alto-00>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998, <https://www.rfc-editor.org/info/rfc2317>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, DOI 10.17487/RFC5693, October 2009, <https://www.rfc-editor.org/info/rfc5693>.
[RFC6708] Kiesel, S., Ed., Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", RFC 6708, DOI 10.17487/RFC6708, September 2012, <https://www.rfc-editor.org/info/rfc6708>.
[RFC7216] Thomson, M. and R. Bellis, "Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS", RFC 7216, DOI 10.17487/RFC7216, April 2014, <https://www.rfc-editor.org/info/rfc7216>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, <https://www.rfc-editor.org/info/rfc7285>.
[RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and H. Song, "Application-Layer Traffic Optimization (ALTO) Server Discovery", RFC 7286, DOI 10.17487/RFC7286, November 2014, <https://www.rfc-editor.org/info/rfc7286>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, <https://www.rfc-editor.org/info/rfc7624>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, DOI 10.17487/RFC7626, August 2015, <https://www.rfc-editor.org/info/rfc7626>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and S. Previdi, "Application-Layer Traffic Optimization (ALTO) Deployment Considerations", RFC 7971, DOI 10.17487/RFC7971, October 2016, <https://www.rfc-editor.org/info/rfc7971>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.
Appendix A. Solution Approaches for Partitioned ALTO Knowledge 🦋
Okay so the ALTO base protocol document [RFC7285] describes how an ALTO client talks to a single ALTO server. 💖 The assumption is that this one server can answer any query, maybe with some kind of default value if it doesn't know the exact data. 🌸 Nothing special was planned for when the ALTO info comes from several sources, possibly run by different administrative entities (like different ISPs), or when the whole ALTO info is split up and stored across several ALTO servers. 😭
A.1. Classification of Solution Approaches 🎀
Various protocol extensions and other solutions have been proposed to deal with multiple information sources and partitioned knowledge. 💅 They can be sorted like this:
- Ensure that all ALTO servers have the same knowledge.
1.1 Ensure data replication and synchronization within the provisioning protocol (cf. [RFC5693], Figure 1).
1.2 Use an inter-ALTO-server data replication protocol. Possibly, the ALTO protocol itself -- maybe with some extensions -- could be used for that purpose; however, this has not been studied in detail so far.
- Accept that different ALTO servers (possibly operated by different organizations, e.g., ISPs) do not have the same knowledge.
2.1 Allow ALTO clients to send arbitrary queries to any ALTO server (e.g., the one discovered using [RFC7286]). If this server cannot answer the query itself, it will fetch the data on behalf of the client, using the ALTO protocol or a to-be-defined inter-ALTO-server request forwarding protocol.
2.2 Allow ALTO clients to send arbitrary queries to any ALTO server (e.g., the one discovered using [RFC7286]). If this server cannot answer the query itself, it will redirect the client to the "right" ALTO server that has the desired information, using a small to-be-defined extension of the ALTO protocol.
2.3 ALTO clients need to use some kind of "search engine" that indexes ALTO servers and redirects and/or gives cached results.
2.4 ALTO clients need to use a new discovery mechanism to discover the ALTO server that has the desired information and contact it directly.
A.2. Discussion of Solution Approaches 🧚
The provisioning or initialization protocol for ALTO servers (cf. [RFC5693], Figure 1) isn't standardized, and that was a deliberate call. 🫶 The IETF ALTO working group decided it was out of scope, because there are so many different kinds of information sources. 🌈 This implementation-specific protocol adapts them to the ALTO server, which then offers a standardized protocol to the ALTO clients. ✨ Adding ALTO server synchronization to it (that's Approach 1.1) would overload it with a second job that needs standardizing for seamless multidomain operation. 💀
For Approaches 1.1 and 1.2, the big questions are technical feasibility, overhead, and caching efficiency, but legal liability is another thing to consider. 😳 Say Operator "A" doesn't want to publish info about nodes in, or paths between, the networks of operators "B" and "C" through A's ALTO server, even if A knew that info. 🙈 That's not just about map size and processing load on A's server. 💅 Operator A could also get into legal trouble if that information messed up the traffic engineering between B's and C's networks, or hurt their business models. 💀
No specific actions for a "search engine" approach (Approach 2.3) are known so far, and it's unclear why anyone would run such an engine. 🤷♀️ So this approach isn't considered in the rest of this document. 🌸
A.3. The Need for Cross-Domain ALTO Server Discovery 👑
Approaches 1.1, 1.2, 2.1, and 2.2 need more than just a protocol extension for ALTO or a new protocol that runs between ALTO servers. 🔥 A big, maybe Internet-wide, multidomain deployment would also need ways for an ALTO server to discover other ALTO servers, learn what info is available where, and ideally figure out who is authorized to publish info about a given part of the network. 🧠 Approach 2.4 needs the same mechanisms, just used on the client side instead of the server side. 🦋
People sometimes ask whether clients really need a way to send arbitrary queries when the ALTO info is split across lots of servers. 💭 The main argument is that clients are supposed to optimize traffic to and from themselves, and the info they need is most likely on a "nearby" ALTO server, the one you can find using [RFC7286]. 🎀 But there are situations where the ALTO client isn't located with an endpoint of the data transmission being optimized. 😮 Instead, it sits at a third party that takes part in the application signaling, like a so-called "tracker" in a peer-to-peer app. 🧚 One such scenario, where putting the ALTO client somewhere other than an endpoint is actually useful, is analyzed in Appendix C. 🌈
A.4. Our Solution Approach 💜
Several solution approaches for cross-domain ALTO server discovery were evaluated, using the criteria documented in Appendix B. 📝 One of them was to use the ALTO protocol itself to exchange info about availability [ALTO4ALTO]. 🤔 The downside is that a brand new registration administration authority would have to be set up. 😩
This document specifies a DNS-based procedure for cross-domain ALTO server discovery, inspired by "Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS" [RFC7216]. ✨ The main goal is that clients can use this procedure (that's Approach 2.4). 🫶 Together with new protocols or protocol extensions, it could also implement the other solution approaches listed above. 🌟
The "Appendix A.5" heading and its last paragraph come first, so the continuation starts there.
A.5. Relation to the ALTO Requirements
During the design phase of the overall ALTO solution, two different server discovery scenarios were identified and documented in the ALTO requirements document [RFC6708]. The first scenario, documented in Req. AR-32, can be supported using the discovery mechanisms specified in [RFC7286]. An alternative approach, based on IP anycast [ALTO-ANYCAST], has also been studied. This document, in contrast, tries to address Req. AR-33.
Appendix B. Requirements for Cross-Domain Server Discovery
This appendix itemizes requirements that were collected before the design phase and are reflected in the design of the ALTO Cross-Domain Server Discovery Procedure.
B.1. Discovery Client Application Programming Interface
The discovery client will be called through some kind of application programming interface (API), and the parameters will be an IP address and, for purposes of extensibility, a service identifier such as "ALTO". The client will return one or more URIs that offer the requested service ("ALTO") for the given IP address.
In other words, the client would be used to retrieve a mapping:
(IP address, "ALTO") -> IRD-URI(s)where IRD-URI(s) is one or more URIs of Information Resource Directories (IRDs, see Section 9 of [RFC7285]) of ALTO servers that can give reasonable guidance to a resource consumer with the indicated IP address.
B.2. Data Storage and Authority Requirements
The information for mapping IP addresses and service parameters to URIs should be stored in a -- preferably distributed -- database. It must be possible to delegate administration of parts of this database. Usually, the mapping from a specific IP address to a URI is defined by the authority that has administrative control over this IP address -- e.g., the ISP in residential access networks or the IT department in enterprise, university, or similar networks.
B.3. Cross-Domain Operations Requirements
The cross-domain server discovery mechanism should be designed in such a way that it works across the public Internet and also in other IP-based networks. This, in turn, means that such mechanisms cannot rely on protocols that are not widely deployed across the Internet or protocols that require special handling within participating networks. An example is multicast, which is not generally available across the Internet.
The ALTO Cross-Domain Server Discovery Protocol must support gradual deployment without a network-wide flag day. If the mechanism needs some kind of well-known "rendezvous point", reusing an existing infrastructure (such as the DNS root servers or the WHOIS database) should be preferred over establishing a new one.
B.4. Protocol Requirements
The protocol must be able to operate across middleboxes, especially NATs and firewalls.
The protocol shall not require any preknowledge from the client other than any information that is known to a regular IP host on the Internet.
B.5. Further Requirements
The ALTO cross-domain server discovery cannot assume that the server-discovery client and the server-discovery responding entity are under the same administrative control.
Appendix C. ALTO and Tracker-Based Peer-to-Peer Applications
This appendix provides a complete example of using ALTO and the ALTO Cross-Domain Server Discovery Procedure in one specific application scenario -- namely, a tracker-based peer-to-peer application. First, in Appendix C.1, we introduce a generic model of such an application and show why ALTO optimization is desirable. Then, in Appendix C.2, we introduce two architectural options for integrating ALTO into the tracker-based peer-to-peer application; one option is based on the "regular" ALTO server discovery procedure [RFC7286], and one relies on the ALTO Cross-Domain Server Discovery Procedure. In Appendix C.3, a simple mathematical model is used to show that the latter approach is expected to yield significantly better optimization results. The appendix concludes with Appendix C.4, which details an exemplary complete walk-through of the ALTO Cross-Domain Server Discovery Procedure.
C.1. A Generic Tracker-Based Peer-to-Peer Application
The optimization of peer-to-peer (P2P) applications such as BitTorrent was one of the first use cases that lead to the inception of the IETF ALTO working group. Further use cases have been identified as well, yet we will use this scenario to illustrate the operation and usefulness of the ALTO Cross-Domain Server Discovery Procedure.
For the remainder of this chapter, we consider a generic, tracker-based peer-to-peer file-sharing application. The goal is the dissemination of a large file, without using one large server with a correspondingly high upload bandwidth. The file is split into chunks. So-called "peers" assume the role of both a client and a server. That is, they may request chunks from other peers, and they may serve the chunks they already possess to other peers at the same time, thereby contributing their upload bandwidth. Peers that want to share the same file participate in a "swarm". They use the peer-to-peer protocol to inform each other about the availability of chunks and request and transfer chunks from one peer to another. A swarm may consist of a very large number of peers. Consequently, peers usually maintain logical connections to only a subset of all peers in the swarm. If a new peer wants to join a swarm, it first contacts a well-known server, the "tracker", which provides a list of IP addresses of peers in the swarm.
A swarm is an overlay network on top of the IP network. Algorithms that determine the overlay topology and the traffic distribution in the overlay may consider information about the underlying IP network, such as topological distance, link bandwidth, (monetary) costs for sending traffic from one host to another, etc. ALTO is a protocol for retrieving such information. The goal of such "topology-aware" decisions is to improve performance or Quality of Experience in the application while reducing the utilization of the underlying network infrastructure.
C.2. Architectural Options for Placing the ALTO Client ✨
okay so the ALTO protocol spec [RFC7285] explains how an ALTO client can ask an ALTO server for guidance and get the replies back 💅 but in a tracker-based P2P app there are two totally different spots where the ALTO client could live 🦋
- ALTO client in the resource consumer ("peer")
- ALTO client in the resource directory ("tracker")
let's compare both so you can see why ALTO queries on behalf of remote resource consumers are a whole thing 🫶
in scenario one (see Figure 2), the peer asks the tracker for the resource (F1) 🌸 the tracker sends back a list of potential resource providers without touching ALTO at all (F2). so then it's the peer's job to call ALTO (F3/F4) and ask for guidance on that list 😭
............................. .............................
: Tracker : : Peer :
: ______ : : :
: +-______-+ : : k good :
: | | +--------+ : P2P App. : +--------+ peers +------+ :
: | N | | random | : Protocol : | ALTO- |------>| data | :
: | known |====>| pre- |*************>| biased | | ex- | :
: | peers, | | selec- | : transmit : | peer |------>| cha- | :
: | M good | | tion | : n peer : | select | n-k | nge | :
: +-______-+ +--------+ : IDs : +--------+ bad p.+------+ :
:...........................: :.....^.....................:
|
| ALTO protocol
__|___
+-______-+
| |
| ALTO |
| server |
+-______-+
Figure 1: Tracker-Based P2P Application with Random Peer Preselection Peer w. ALTO cli. Tracker ALTO Server
--------+-------- --------+-------- --------+--------
| F1 Tracker query | |
|======================>| |
| F2 Tracker reply | |
|<======================| |
| F3 ALTO query | |
|---------------------------------------------->|
| F4 ALTO reply | |
|<----------------------------------------------|
| | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO protocol
Figure 2: Basic Message Sequence Chart for Resource Consumer-
Initiated ALTO Queryin scenario two (see Figure 4), the tracker has its very own embedded ALTO client 🧚 when a query for a given resource comes in (F1), the tracker runs that client over every resource provider it knows (F2/F3). then it sends back a list, maybe trimmed down, with the "best" providers for the peer (F4) 👑
............................. .............................
: Tracker : : Peer :
: ______ : : :
: +-______-+ : : :
: | | +--------+ : P2P App. : k good peers & +------+ :
: | N | | ALTO- | : Protocol : n-k bad peers | data | :
: | known |====>| biased |******************************>| ex- | :
: | peers, | | peer | : transmit : | cha- | :
: | M good | | select | : n peer : | nge | :
: +-______-+ +--------+ : IDs : +------+ :
:.....................^.....: :...........................:
|
| ALTO protocol
__|___
+-______-+
| |
| ALTO |
| server |
+-______-+
Figure 3: Tracker-Based P2P Application with ALTO Client in Tracker Peer Tracker w. ALTO cli. ALTO Server
--------+-------- --------+-------- --------+--------
| F1 Tracker query | |
|======================>| |
| | F2 ALTO query |
| |---------------------->|
| | F3 ALTO reply |
| |<----------------------|
| F4 Tracker reply | |
|<======================| |
| | |
==== Application protocol (i.e., tracker-based P2P app protocol)
---- ALTO protocol
Figure 4: Basic Message Sequence Chart for ALTO Query on Behalf
of Remote Resource Consumerheads up 👀 the message sequences in Figures 2 and 4 can happen in both the target-aware and the target-independent query modes (cf. [RFC6708]). in target-independent mode, there might not be any message exchange with the ALTO server after the tracker query at all, because the candidates can be judged using a locally cached "map" that was grabbed from the ALTO server a while back 🙈
C.3. Evaluation 💜
okay so the problem with the first approach is that the resource directory might know thousands of peers in a swarm, but the list it sends back to the resource consumer is usually shortened for efficiency 😭 which means the "best" (in the ALTO sense) potential providers might already be gone from that list before ALTO even gets a chance to look at them 💀
to illustrate, let's use a simple model of a swarm where every peer is either "good" (in terms of ALTO's better-than-random peer selection, based on some arbitrary rating criterion we want) or "bad" 🍓 more categories would make the math messier but wouldn't change the basic outcome. say the swarm has N peers in total, with M "good" ones and N-M "bad" ones, and the tracker knows all of them. a brand new peer joins and asks the tracker for a list of peers 🦋
if the tracker randomly picks n peers out of the N known ones (approach one), the result follows the hypergeometric distribution ✨ the probability that the reply has exactly k "good" peers (and n-k "bad" peers) is:
/ M \ / N - M \
\ k / \ n - k /
P(X=k) = ---------------------
/ N \
\ n /
/ n \ n!
with \ k / = ----------- and n! = n * (n-1) * (n-2) * .. * 1
k! (n-k)!and the probability that the reply has at most k "good" peers is:
P(X<=k) = P(X=0) + P(X=1) + .. + P(X=k).for example, say the tracker knows N=10,000 peers in a swarm, and M=100 of them are "good" 🌈 if the tracker randomly selects n=100 peers, the formula gives: P(X=0)=36%, P(X<=4)=99%. so there's about a 36% chance the list doesn't have a single "good" peer on it 😭 and a 99% chance there are only four or fewer "good" peers on it. ALTO can totally rank those few favorable peers to the top 🔥 but the benefit is pretty tiny, because there are just too few of them in the list to work with 🥲
now, a way better traffic optimization happens if the tracker evaluates all known peers with ALTO and then returns a list of 100 peers 👑 that list would have a way higher fraction of "good" peers. (side note: if the tracker only returned "good" peers, the swarm might disconnect and split into several disjoint partitions 🙈 but finding the right mix of ALTO-biased and random peer selection is out of scope for this document.)
so from an overall optimization perspective, the second scenario, with the ALTO client embedded in the resource directory, is the winner 🏆 because it makes sure the addresses of the "best" resource providers actually reach the resource consumer 💖 the architectural takeaway is that ALTO server discovery procedures have to support ALTO queries on behalf of remote resource consumers 🫶 in other words, since the tracker issues ALTO queries for the peer that contacted it, the tracker must be able to discover an ALTO server that can give guidance suitable for that peer ✨ this task can be solved using the ALTO Cross-Domain Server Discovery Procedure 🎀
C.4. Example
This section walks through a full example of the ALTO Cross-Domain Server Discovery Procedure in a tracker-based peer-to-peer scenario, and yes, it's a super satisfying one 🦋
The example is built on the network topology in Figure 5. Five access networks, Networks a, b, c, x, and t, are run by five different network operators, and they're all linked up by a backbone structure 🌸 Each operator runs its own ALTO server in its network: 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 TopologySo a brand new peer in a peer-to-peer app wants to join a specific swarm (overlay network) so it can get a specific resource 💖 This new peer is called "Resource Consumer X", following the terminology of [RFC6708], and it lives in Network x. It reaches out to the tracker, which is the "Resource Directory" sitting in Network t. How the new peer finds the tracker is out of scope for this document 🧚 The tracker keeps a list of the peers in the overlay network, so it can figure out that Resource Providers A, B, and C are candidate peers for Resource Consumer X.
As we covered in the previous section, a tracker-side ALTO optimization (cf. Figures 3 and 4) is more efficient than a client-side one ✨ So the tracker wants to use the ALTO Endpoint Cost Service (ECS) to learn the routing costs between X and A, X and B, and X and C, so it can sort A, B, and C by their routing costs to X.
In theory there are lots of ways the ALTO Cross-Domain Server Discovery Procedure could be used. For example, the tracker could do this:
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_CIn this case, the discovery queries might give back: IRD_URIS_A = ALTO_SRV_A, IRD_URIS_B = ALTO_SRV_B, and IRD_URIS_C = ALTO_SRV_C. So each ECS query would go to a different ALTO server 🙈 The problem is that we can't necessarily compare COST_X_A, COST_X_B, and COST_X_C with each other. The routingcost metric spec says 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]). So COST_X_A could be 10 (milliseconds round-trip time), 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 fulfills the "lower value is more preferable" rule on its own, but they obviously can't be compared with each other 💀 Even if there were a reasonable formula to compare, say, kilometers with milliseconds, we still couldn't use it, because the units of measurement (or any other info about how the routingcost was computed) aren't sent along with the value in the ECS reply.
To dodge 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 a parameter of 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_XThis strategy makes sure COST_X_A, COST_X_B, and COST_X_C can be compared with each other. Iconic, right? 🎀
As we discussed above, the tracker calls the ALTO Cross-Domain Server Discovery Procedure with IP address X as a parameter. For the rest of this example, we assume that X = 2001:DB8:1:2:227:eff:fe6a:de42. So 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. So 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 the following (see Step 2 in Section 3.2):
R64 = "2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R56 = "0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R48 = "1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R40 = "0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
R32 = "8.B.D.0.1.0.0.2.IP6.ARPA."To show the third step of the ALTO Cross-Domain Server Discovery Procedure, we use the "dig" (domain information groper) DNS lookup utility, which is available on lots of operating systems (e.g., Linux) 🔥 A real implementation wouldn't use the "dig" utility, though. It would use appropriate libraries and/or operating-system APIs instead. Please note that the following steps were done in a controlled lab environment with an appropriately configured name server, and you'll need a suitable DNS configuration to reproduce these results. Also, the super verbose output of the "dig" tool has been trimmed down to the relevant lines 💅
Since AT = IPv6 and L = 128, the sixth row (not counting the column headers) of the table in Section 3.4 applies 🧠
As the third column mandates, we start by looking up R128 for NAPTR resource records:
user@labpc:~$ dig -tNAPTR 2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.\
2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26553
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0The domain name R128 does not exist (status: NXDOMAIN), so we can't get a useful result 😭 Therefore, we move on to the fourth column of the table and look up R64:
user@labpc:~$ dig -tNAPTR 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33193
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0The domain name R64 could be looked up (status: NOERROR), but there are no NAPTR resource records tied to it (ANSWER: 0). There might be other resource records such as PTR, NS, or SOA, but we don't care about those. So no useful result yet, and we keep going with a lookup of R56:
user@labpc:~$ dig -tNAPTR 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35966
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
;; ANSWER SECTION:
0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
"LIS:HELD" "!.*!https://lis1.example.org:4802/?c=ex!" .
0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 20 "u"
"LIS:HELD" "!.*!https://lis2.example.org:4802/?c=ex!" .The domain name R56 could be looked up, and there are NAPTR resource records tied to it. However, each of those records has a service parameter that doesn't match our SP = "ALTO:https" (see [RFC7216] for "LIS:HELD"), so we have to ignore them 🙈 Still no useful result, so we keep going and look up R48:
user@labpc:~$ dig -tNAPTR 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50459
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
;; ANSWER SECTION:
1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
"ALTO:https" "!.*!https://alto1.example.net/ird!" .
1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
"LIS:HELD" "!.*!https://lis.example.net:4802/?c=ex!" .This lookup gives us two NAPTR resource records. We ignore the second one because its service parameter doesn't match our SP, but the first NAPTR resource record has a matching service parameter 🎉 So the procedure wraps up successfully, and the final outcome is: IRD_URIS_X = "https://alto1.example.net/ird" 👑
The ALTO client 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, and C and X, before sending back an ALTO-optimized list of candidate resource providers to resource consumer X 🫶
Acknowledgments
The initial draft version of this document was co-authored by Marco Tomsu (Alcatel-Lucent).
This document borrows some text from [RFC7286], as historically it was part of the draft that eventually became said RFC. Special thanks to Michael Scharf and Nico Schwan 💜
Authors' Addresses
Sebastian Kiesel
University of Stuttgart Information Center
Allmandring 30
70550 Stuttgart
Germany
Email: ietf-alto@skiesel.de
URI: http://www.izus.uni-stuttgart.deMartin Stiemerling
University of Applied Sciences Darmstadt, Computer Science Dept.
Haardtring 100
64295 Darmstadt
Germany
Phone: +49 6151 16 37938
Email: mls.ietf@gmail.com
URI: https://danet.fbi.h-da.de📦 where this page comes from
- ietf: rfc8686 2020-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms