File: rfc8686.html

package info (click to toggle)
doc-rfc 20201128-1
links: PTS, VCS
area: non-free
in suites: bullseye
size: 1,307,124 kB
file content (3602 lines) | stat: -rw-r--r-- 190,226 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8686: Application-Layer Traffic Optimization (ALTO) Cross‑Domain Server Discovery</title>
<meta content="Sebastian Kiesel" name="author">
<meta content="Martin Stiemerling" name="author">
<meta content="
       The goal of Application-Layer Traffic Optimization (ALTO) is to
        provide guidance to applications that have to select one or several
        hosts from a set of candidates capable of providing a desired
        resource.  ALTO is realized by a client-server protocol.  Before an
        ALTO client can ask for guidance, it needs to discover one or more
        ALTO servers that can provide suitable guidance. 
       In some deployment scenarios, in particular if the information
 about the network topology is partitioned and distributed over several
 ALTO servers, it may be necessary to discover an ALTO server outside
 of the ALTO client's own network domain, in order to get appropriate
 guidance.  This document details applicable scenarios, itemizes
 requirements, and specifies a procedure for ALTO cross-domain server
 discovery. 
       Technically, the procedure specified in this document takes one
        IP address or prefix and a U-NAPTR Service Parameter
        (typically, &quot;ALTO:https&quot;) as parameters. It performs DNS lookups (for
        NAPTR resource records in the &quot;in-addr.arpa.&quot; or &quot;ip6.arpa.&quot; trees)
        and returns one or more URIs of information resources related 
        to that IP address or prefix. 
    " name="description">
<meta content="xml2rfc 2.39.0" name="generator">
<meta content="Application-Layer Traffic Optimization (ALTO)" name="keyword">
<meta content="ALTO cross-domain server discovery" name="keyword">
<meta content="ALTO third-party server discovery" name="keyword">
<meta content="8686" name="rfc.number">
<link href="rfc8686.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin: 0 0 0.25em 0;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/*
  The margin-left: 0 on <dd> removes all distinction
  between levels from nested <dl>s.  Undo that.
*/
dl.olPercent > dd,
dd {
  margin-left: revert;
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8686" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-alto-xdom-disc-06" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8686</td>
<td class="center">ALTO Cross-Domain Server Discovery</td>
<td class="right">February 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Kiesel &amp; Stiemerling</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8686" class="eref">8686</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-02" class="published">February 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">S. Kiesel</div>
<div class="org">University of Stuttgart</div>
</div>
<div class="author">
      <div class="author-name">M. Stiemerling</div>
<div class="org">H-DA</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8686</h1>
<h1 id="title">Application-Layer Traffic Optimization (ALTO) Cross‑Domain Server Discovery</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">The goal of Application-Layer Traffic Optimization (ALTO) is to
        provide guidance to applications that have to select one or several
        hosts from a set of candidates capable of providing a desired
        resource.  ALTO is realized by a client-server protocol.  Before an
        ALTO client can ask for guidance, it needs to discover one or more
        ALTO servers that can provide suitable guidance.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">In some deployment scenarios, in particular if the information
 about the network topology is partitioned and distributed over several
 ALTO servers, it may be necessary to discover an ALTO server outside
 of the ALTO client's own network domain, in order to get appropriate
 guidance.  This document details applicable scenarios, itemizes
 requirements, and specifies a procedure for ALTO cross-domain server
 discovery.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
<p id="section-abstract-3">Technically, the procedure specified in this document takes one
        IP address or prefix and a U-NAPTR Service Parameter
        (typically, "ALTO:https") as parameters. It performs DNS lookups (for
        NAPTR resource records in the "in-addr.arpa." or "ip6.arpa." trees)
        and returns one or more URIs of information resources related 
        to that IP address or prefix.<a href="#section-abstract-3" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            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).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8686">https://www.rfc-editor.org/info/rfc8686</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-terminology-and-requirement" class="xref">Terminology and Requirements Language</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-alto-cross-domain-server-di" class="xref">ALTO Cross-Domain Server Discovery Procedure: Overview</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-alto-cross-domain-server-dis" class="xref">ALTO Cross-Domain Server             Discovery Procedure: Specification</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-interface" class="xref">Interface</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-step-1-prepare-domain-name-" class="xref">Step 1: Prepare Domain Name for Reverse DNS Lookup</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-step-2-prepare-shortened-do" class="xref">Step 2: Prepare Shortened Domain Names</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-step-3-perform-dns-u-naptr-" class="xref">Step 3: Perform DNS U-NAPTR Lookups</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-error-handling" class="xref">Error Handling</a><a href="#section-toc.1-1.3.2.5.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-using-the-alto-protocol-wit" class="xref">Using the ALTO Protocol with Cross-Domain Server Discovery</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-network-and-cost-map-servic" class="xref">Network and Cost Map Service</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-map-filtering-service" class="xref">Map-Filtering Service</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-endpoint-property-service" class="xref">Endpoint Property Service</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-endpoint-cost-service" class="xref">Endpoint Cost Service</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-summary-and-further-extensi" class="xref">Summary and Further Extensions</a><a href="#section-toc.1-1.4.2.5.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-implementation-deployment-a" class="xref">Implementation, Deployment, and Operational Considerations</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-considerations-for-alto-cli" class="xref">Considerations for ALTO Clients</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-considerations-for-network-" class="xref">Considerations for Network Operators</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-integrity-of-the-alto-serve" class="xref">Integrity of the ALTO Server's URI</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-availability-of-the-alto-se" class="xref">Availability of the ALTO Server Discovery Procedure</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-confidentiality-of-the-alto" class="xref">Confidentiality of the ALTO Server's URI</a><a href="#section-toc.1-1.6.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.6.2.4">
                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-privacy-for-alto-clients" class="xref">Privacy for ALTO Clients</a><a href="#section-toc.1-1.6.2.4.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-solution-approaches-for-par" class="xref">Solution Approaches for Partitioned ALTO Knowledge</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-classification-of-solution-" class="xref">Classification of Solution Approaches</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-a.2" class="xref">A.2</a>.  <a href="#name-discussion-of-solution-appr" class="xref">Discussion of Solution Approaches</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.3">
                <p id="section-toc.1-1.9.2.3.1"><a href="#section-a.3" class="xref">A.3</a>.  <a href="#name-the-need-for-cross-domain-a" class="xref">The Need for Cross-Domain ALTO Server Discovery</a><a href="#section-toc.1-1.9.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.4">
                <p id="section-toc.1-1.9.2.4.1"><a href="#section-a.4" class="xref">A.4</a>.  <a href="#name-our-solution-approach" class="xref">Our Solution Approach</a><a href="#section-toc.1-1.9.2.4.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.5">
                <p id="section-toc.1-1.9.2.5.1"><a href="#section-a.5" class="xref">A.5</a>.  <a href="#name-relation-to-the-alto-requir" class="xref">Relation to the ALTO Requirements</a><a href="#section-toc.1-1.9.2.5.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.b" class="xref">Appendix B</a>.  <a href="#name-requirements-for-cross-doma" class="xref">Requirements for Cross-Domain Server Discovery</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-b.1" class="xref">B.1</a>.  <a href="#name-discovery-client-applicatio" class="xref">Discovery Client Application Programming Interface</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-b.2" class="xref">B.2</a>.  <a href="#name-data-storage-and-authority-" class="xref">Data Storage and Authority Requirements</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.10.2.3">
                <p id="section-toc.1-1.10.2.3.1"><a href="#section-b.3" class="xref">B.3</a>.  <a href="#name-cross-domain-operations-req" class="xref">Cross-Domain Operations Requirements</a><a href="#section-toc.1-1.10.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.10.2.4">
                <p id="section-toc.1-1.10.2.4.1"><a href="#section-b.4" class="xref">B.4</a>.  <a href="#name-protocol-requirements" class="xref">Protocol Requirements</a><a href="#section-toc.1-1.10.2.4.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.10.2.5">
                <p id="section-toc.1-1.10.2.5.1"><a href="#section-b.5" class="xref">B.5</a>.  <a href="#name-further-requirements" class="xref">Further Requirements</a><a href="#section-toc.1-1.10.2.5.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.c" class="xref">Appendix C</a>.  <a href="#name-alto-and-tracker-based-peer" class="xref">ALTO and Tracker-Based Peer-to-Peer Applications</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-c.1" class="xref">C.1</a>.  <a href="#name-a-generic-tracker-based-pee" class="xref">A Generic Tracker-Based Peer-to-Peer Application</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-c.2" class="xref">C.2</a>.  <a href="#name-architectural-options-for-p" class="xref">Architectural Options for Placing the ALTO Client</a><a href="#section-toc.1-1.11.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.11.2.3">
                <p id="section-toc.1-1.11.2.3.1"><a href="#section-c.3" class="xref">C.3</a>.  <a href="#name-evaluation" class="xref">Evaluation</a><a href="#section-toc.1-1.11.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.11.2.4">
                <p id="section-toc.1-1.11.2.4.1"><a href="#section-c.4" class="xref">C.4</a>.  <a href="#name-example" class="xref">Example</a><a href="#section-toc.1-1.11.2.4.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-appendix.e" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
</ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">
            The goal of Application-Layer Traffic Optimization (ALTO) is to
            provide guidance to applications that have to select one or several
            hosts from a set of candidates capable of providing a desired
            resource <span>[<a href="#RFC5693" class="xref">RFC5693</a>]</span>. ALTO is realized by an
            HTTP-based client-server protocol <span>[<a href="#RFC7285" class="xref">RFC7285</a>]</span>,
            which can be used in various scenarios
            <span>[<a href="#RFC7971" class="xref">RFC7971</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
            The ALTO base protocol document <span>[<a href="#RFC7285" class="xref">RFC7285</a>]</span> specifies
            the communication between an ALTO client and one ALTO server.
            In principle, the client may send any ALTO query.
            For example, it might ask for the routing cost between any two IP
            addresses, or it might request network and
            cost maps for the whole network, which might be the worldwide
            Internet. It is assumed that the server can answer any query,
            possibly with some kind of default value if no exact data is
            known.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
            No special provisions were made for deployment scenarios with
            multiple ALTO servers, with some servers having more accurate
            information about some parts of the network topology while others
            have better information about other parts of the network
            ("partitioned knowledge"). Various ALTO use cases have been
            studied in the context of such scenarios. In some cases, one
            cannot assume that a topologically nearby ALTO server (e.g., a
            server discovered with the procedure specified in
            <span>[<a href="#RFC7286" class="xref">RFC7286</a>]</span>) will always provide useful information
            to the client. One such scenario is detailed in
            <a href="#apx.alto_p2p" class="xref">Appendix C</a>.  Several solution
            approaches, such as redirecting a client to a server that has more
            accurate information or forwarding the request to such a server on behalf
            of the client, have been proposed and analyzed (see
            <a href="#sec.multiplesources" class="xref">Appendix A</a>), but no
     solution has been specified so far.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
            <a href="#sec.3pdisc-spec" class="xref">Section 3</a> of this document specifies
            the "ALTO Cross-Domain Server Discovery Procedure"
            for client-side usage in these scenarios.
            An ALTO client that wants to send an ALTO query related to a
            specific IP address or prefix X may call this procedure
            with X as a parameter.
            It will use Domain Name System (DNS) lookups to find one or
            more ALTO servers that can provide a competent answer.
            The above wording "related to" was intentionally kept somewhat
            unspecific, as the exact semantics depends on the ALTO service to
            be used; see <a href="#sec.xdom-usage" class="xref">Section 4</a>.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">
            Those who are in control of the "reverse DNS"
            for a given IP address or prefix
            (i.e., the corresponding subdomain of "in-addr.arpa." or "ip6.arpa.")
            -- typically an Internet Service Provider (ISP), a
            corporate IT department, or a university's computing center --
            may add resource records to the DNS that point to one or more
            relevant ALTO servers.  In many cases, it may be
            an ALTO server run by that ISP or IT department, as they
            naturally have good insight into routing costs from and
            to their networks.  However, they may also refer to an
            ALTO server provided by someone else, e.g., their upstream ISP.<a href="#section-1-5" class="pilcrow">¶</a></p>
<section id="section-1.1">
        <h3 id="name-terminology-and-requirement">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-terminology-and-requirement" class="section-name selfRef">Terminology and Requirements Language</a>
        </h3>
<p id="section-1.1-1">This document makes use of the ALTO terminology defined in
        RFC 5693 <span>[<a href="#RFC5693" class="xref">RFC5693</a>]</span>.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>",
    "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be
    interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals, as
    shown here.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
</section>
</section>
<div id="sec.3pdisc-overview">
<section id="section-2">
      <h2 id="name-alto-cross-domain-server-di">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-alto-cross-domain-server-di" class="section-name selfRef">ALTO Cross-Domain Server Discovery Procedure: Overview</a>
      </h2>
<p id="section-2-1">This section gives a non-normative overview of the
        ALTO Cross-Domain Server Discovery Procedure. The detailed
        specification will follow in the next section.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">This procedure was inspired by "Location Information
        Server (LIS) Discovery Using IP Addresses and Reverse DNS"
        <span>[<a href="#RFC7216" class="xref">RFC7216</a>]</span> and reuses parts of the basic
        ALTO Server Discovery Procedure <span>[<a href="#RFC7286" class="xref">RFC7286</a>]</span>.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">The basic idea is to use the Domain Name System (DNS),
        more specifically the "in-addr.arpa." or "ip6.arpa." trees,
        which are mostly used for "reverse mapping" of IP addresses
        to host names by means of PTR resource records.
        There, URI-enabled Naming Authority Pointer (U-NAPTR)
        resource records <span>[<a href="#RFC4848" class="xref">RFC4848</a>]</span>,
        which allow the mapping of domain names to 
        Uniform Resource Identifiers (URIs), are installed
        as needed. Thereby, it is possible to store a mapping from
        an IP address or prefix to one or more ALTO server URIs in the DNS.<a href="#section-2-3" class="pilcrow">¶</a></p>
<p id="section-2-4">The ALTO Cross-Domain Server Discovery Procedure is called
        with one IP address or prefix and a U-NAPTR Service
        Parameter <span>[<a href="#RFC4848" class="xref">RFC4848</a>]</span> as parameters.<a href="#section-2-4" class="pilcrow">¶</a></p>
<p id="section-2-5">The service parameter is usually 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.<a href="#section-2-5" class="pilcrow">¶</a></p>
<p id="section-2-6">The procedure performs DNS lookups and returns one or more
        URIs of information resources related to said IP address or
        prefix, usually the URIs of one or more ALTO Information
        Resource Directories (IRDs; see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-9" class="relref">Section 9</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>).
        The U-NAPTR records also provide preference values, which should
        be considered if more than one URI is returned.<a href="#section-2-6" class="pilcrow">¶</a></p>
<p id="section-2-7">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 not yield a usable result, the procedure
        tries further lookups with truncated domain names, which correspond
        to shorter prefix lengths.  The goal is to allow deployment
        scenarios that require fine-grained discovery on a per-IP basis, as
        well as large-scale scenarios where discovery is to be enabled for a
        large number of IP addresses with a small number of additional DNS
        resource records.<a href="#section-2-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec.3pdisc-spec">
<section id="section-3">
      <h2 id="name-alto-cross-domain-server-dis">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-alto-cross-domain-server-dis" class="section-name selfRef">ALTO Cross-Domain Server             Discovery Procedure: Specification</a>
      </h2>
<div id="sec.3pdisc-spec-interface">
<section id="section-3.1">
        <h3 id="name-interface">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-interface" class="section-name selfRef">Interface</a>
        </h3>
<p id="section-3.1-1">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.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">The parameter X may be an IPv4 or an IPv6 address
            or prefix in Classless Inter-Domain Routing (CIDR) notation (see
     <span>[<a href="#RFC4632" class="xref">RFC4632</a>]</span>
            for the IPv4 CIDR notation and <span>[<a href="#RFC4291" class="xref">RFC4291</a>]</span> for IPv6).
            Consequently, the address type AT is either "IPv4" or "IPv6".
            In both cases, X consists of an IP address A and a
            prefix length L.
            From the definitions of IPv4 and IPv6, it follows that 
            syntactically valid values for L are
            0 &lt;= L &lt;= 32 when AT=IPv4 and
            0 &lt;= L &lt;= 128 when AT=IPv6.
            However, not all syntactically valid values of L are actually
            supported by this procedure; Step 1 (see below) will
            check for unsupported values and report an error if
            necessary.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">For example, for X=198.51.100.0/24, we get AT=IPv4,
            A=198.51.100.0, and L=24.  Similarly, for X=2001:0DB8::20/128,
            we get AT=IPv6, A=2001:0DB8::20, and L=128.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">In the intended usage scenario, the procedure is normally
            always called with the parameter SP set to "ALTO:https".
            However, for general applicability and in order to support
            future extensions, the procedure <span class="bcp14">MUST</span> support being called
            with any valid U-NAPTR Service Parameter
            (see <span><a href="https://www.rfc-editor.org/rfc/rfc4848#section-4.5" class="relref">Section 4.5</a> of [<a href="#RFC4848" class="xref">RFC4848</a>]</span> for the
            syntax of U-NAPTR Service Parameters and Section <a href="https://www.rfc-editor.org/rfc/rfc4848#section-5" class="relref">5</a> of the
            same document for information about the IANA registries).<a href="#section-3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.1-5">The procedure performs DNS lookups and returns one or more
            URIs of information resources related to that IP address or
            prefix, usually the URIs of one or more ALTO Information
            Resource Directories (IRDs; see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-9" class="relref">Section 9</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>).
            For each URI, the procedure also returns order and preference values
            (see <span><a href="https://www.rfc-editor.org/rfc/rfc3403#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC3403" class="xref">RFC3403</a>]</span>),
     which
            should be considered if more than one URI is returned.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
<p id="section-3.1-6">During execution of this procedure, various
            error conditions may occur and have to be reported to
            the caller; see
            <a href="#sec.3pdisc-spec-errorhandling" class="xref">Section 3.5</a>.<a href="#section-3.1-6" class="pilcrow">¶</a></p>
<p id="section-3.1-7">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")<a href="#section-3.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec.3pdisc-spec-step1">
<section id="section-3.2">
        <h3 id="name-step-1-prepare-domain-name-">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-step-1-prepare-domain-name-" class="section-name selfRef">Step 1: Prepare Domain Name for Reverse DNS Lookup</a>
        </h3>
<p id="section-3.2-1">First, the procedure checks the prefix length L for unsupported
            values: If AT=IPv4 (i.e., if A is an IPv4 address) and L &lt; 8,
            the procedure aborts and indicates an "unsupported prefix length"
            error to the caller. Similarly, if AT=IPv6
            and L &lt; 32, the procedure aborts and indicates an
            "unsupported prefix length" error to the caller. Otherwise,
            the procedure continues.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">If AT=IPv4, the procedure will then produce a 
            DNS domain name,
            which will be referred to as R32. This domain name is
            constructed according to the rules specified in
            <span><a href="https://www.rfc-editor.org/rfc/rfc1035#section-3.5" class="relref">Section 3.5</a> of [<a href="#RFC1035" class="xref">RFC1035</a>]</span>, and it is rooted in
            the special domain "IN-ADDR.ARPA.".<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.2-3">For example, A=198.51.100.3 yields
            R32="3.100.51.198.IN-ADDR.ARPA.".<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2-4">If AT=IPv6, a domain name, which will be called R128,
            is constructed according to the rules specified in
            <span><a href="https://www.rfc-editor.org/rfc/rfc3596#section-2.5" class="relref">Section 2.5</a> of [<a href="#RFC3596" class="xref">RFC3596</a>]</span>, and the
            special domain "IP6.ARPA." is used.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<p id="section-3.2-5">
For example (note: a line break was added after the second line),<a href="#section-3.2-5" class="pilcrow">¶</a></p>
<div id="section-3.2-6">
<pre class="sourcecode lang-pseudocode">
A = 2001:0DB8::20    yields
R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
        1.0.0.2.IP6.ARPA."
</pre><a href="#section-3.2-6" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="sec.3pdisc-spec-step2">
<section id="section-3.3">
        <h3 id="name-step-2-prepare-shortened-do">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-step-2-prepare-shortened-do" class="section-name selfRef">Step 2: Prepare Shortened Domain Names</a>
        </h3>
<p id="section-3.3-1">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 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.".<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">If AT=IPv4, the following additional
            domain names are generated from the result of the previous step:<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-3.3-3.1">R24=skip(R32,1),<a href="#section-3.3-3.1" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-3.3-3.2">R16=skip(R32,2), and<a href="#section-3.3-3.2" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-3.3-3.3">R8=skip(R32,3).<a href="#section-3.3-3.3" class="pilcrow">¶</a>
</li>
</ul>
<p id="section-3.3-4">
            Removing one label from a domain name (i.e., one number of the
            "dotted quad notation") corresponds to shortening the prefix length
            by 8 bits.<a href="#section-3.3-4" class="pilcrow">¶</a></p>
<p id="section-3.3-5">For example,<a href="#section-3.3-5" class="pilcrow">¶</a></p>
<div id="section-3.3-6">
<pre class="sourcecode lang-pseudocode">
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."
</pre><a href="#section-3.3-6" class="pilcrow">¶</a>
</div>
<p id="section-3.3-7">If AT=IPv6, the following additional
            domain names are generated from the result of the previous step:<a href="#section-3.3-7" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-3.3-8.1">R64=skip(R128,16),<a href="#section-3.3-8.1" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-3.3-8.2">R56=skip(R128,18),<a href="#section-3.3-8.2" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-3.3-8.3">R48=skip(R128,20),<a href="#section-3.3-8.3" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-3.3-8.4">R40=skip(R128,22), and<a href="#section-3.3-8.4" class="pilcrow">¶</a>
</li>
<li class="ulEmpty" id="section-3.3-8.5">R32=skip(R128,24).<a href="#section-3.3-8.5" class="pilcrow">¶</a>
</li>
</ul>
<p id="section-3.3-9">
            Removing one label from a domain name (i.e., one hex digit)
            corresponds to shortening the prefix length by 4 bits.<a href="#section-3.3-9" class="pilcrow">¶</a></p>
<p id="section-3.3-10">
For example (note: a line break was added after the first line),<a href="#section-3.3-10" class="pilcrow">¶</a></p>
<div id="section-3.3-11">
<pre class="sourcecode lang-pseudocode">
R128 = "0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.
        1.0.0.2.IP6.ARPA."    yields
R64  = "0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA."
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."
</pre><a href="#section-3.3-11" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="sec.3pdisc-spec-step3">
<section id="section-3.4">
        <h3 id="name-step-3-perform-dns-u-naptr-">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-step-3-perform-dns-u-naptr-" class="section-name selfRef">Step 3: Perform DNS U-NAPTR Lookups</a>
        </h3>
<p id="section-3.4-1">The address type and the prefix length of X
            are matched against the first and the second column of the
            following table, respectively:<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<span id="name-perform-dns-u-naptr-lookups"></span><div id="U-NAPTR">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-perform-dns-u-naptr-lookups" class="selfRef">Perform DNS U-NAPTR lookups</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">1: Address Type AT</th>
              <th class="text-left" rowspan="1" colspan="1">2: Prefix Length L</th>
              <th class="text-left" rowspan="1" colspan="1">3: MUST do 1st lookup</th>
              <th class="text-left" rowspan="1" colspan="1">4: SHOULD do further lookups in that order</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">IPv4</td>
              <td class="text-left" rowspan="1" colspan="1">32</td>
              <td class="text-left" rowspan="1" colspan="1">R32</td>
              <td class="text-left" rowspan="1" colspan="1">R24, R16, R8</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">IPv4</td>
              <td class="text-left" rowspan="1" colspan="1">24 .. 31</td>
              <td class="text-left" rowspan="1" colspan="1">R24</td>
              <td class="text-left" rowspan="1" colspan="1">R16, R8</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">IPv4</td>
              <td class="text-left" rowspan="1" colspan="1">16 .. 23</td>
              <td class="text-left" rowspan="1" colspan="1">R16</td>
              <td class="text-left" rowspan="1" colspan="1">R8</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">IPv4</td>
              <td class="text-left" rowspan="1" colspan="1">8 .. 15</td>
              <td class="text-left" rowspan="1" colspan="1">R8</td>
              <td class="text-left" rowspan="1" colspan="1">(none)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">IPv4</td>
              <td class="text-left" rowspan="1" colspan="1">0 .. 7</td>
              <td class="text-left" rowspan="1" colspan="2">(none, abort: unsupported prefix length)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">IPv6</td>
              <td class="text-left" rowspan="1" colspan="1">128</td>
              <td class="text-left" rowspan="1" colspan="1">R128</td>
              <td class="text-left" rowspan="1" colspan="1">R64, R56, R48, R40, R32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">IPv6</td>
              <td class="text-left" rowspan="1" colspan="1">64 (..127)</td>
              <td class="text-left" rowspan="1" colspan="1">R64</td>
              <td class="text-left" rowspan="1" colspan="1">R56, R48, R40, R32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">IPv6</td>
              <td class="text-left" rowspan="1" colspan="1">56 .. 63</td>
              <td class="text-left" rowspan="1" colspan="1">R56</td>
              <td class="text-left" rowspan="1" colspan="1">R48, R40, R32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">IPv6</td>
              <td class="text-left" rowspan="1" colspan="1">48 .. 55</td>
              <td class="text-left" rowspan="1" colspan="1">R48</td>
              <td class="text-left" rowspan="1" colspan="1">R40, R32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">IPv6</td>
              <td class="text-left" rowspan="1" colspan="1">40 .. 47</td>
              <td class="text-left" rowspan="1" colspan="1">R40</td>
              <td class="text-left" rowspan="1" colspan="1">R32</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">IPv6</td>
              <td class="text-left" rowspan="1" colspan="1">32 .. 39</td>
              <td class="text-left" rowspan="1" colspan="1">R32</td>
              <td class="text-left" rowspan="1" colspan="1">(none)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">IPv6</td>
              <td class="text-left" rowspan="1" colspan="1">0 .. 31</td>
              <td class="text-left" rowspan="1" colspan="2">(none, abort: unsupported prefix length)</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-3.4-3">Then, the domain name given in the 3rd column and the
            U-NAPTR Service Parameter SP with which the procedure was called
            (usually "ALTO:https") <span class="bcp14">MUST</span> be used for a
            U-NAPTR <span>[<a href="#RFC4848" class="xref">RFC4848</a>]</span> lookup, in order
            to obtain one or more URIs (indicating protocol, host, and
            possibly path elements) for the ALTO server's Information Resource
            Directory (IRD).  If such URIs can be found, the
            ALTO Cross-Domain Server Discovery Procedure returns that
            information to the caller and terminates successfully.<a href="#section-3.4-3" class="pilcrow">¶</a></p>
<p id="section-3.4-4">For example, the following two U-NAPTR resource records can be
            used for mapping "100.51.198.IN-ADDR.ARPA." (i.e., R24 from the
            example in the previous step) to the HTTPS URIs
            "https://alto1.example.net/ird" and
            "https://alto2.example.net/ird", with the former being preferred.<a href="#section-3.4-4" class="pilcrow">¶</a></p>
<div id="section-3.4-5">
<pre class="sourcecode lang-dns-rr">
    100.51.198.IN-ADDR.ARPA.  IN NAPTR 100  10  "u"  "ALTO:https"
         "!.*!https://alto1.example.net/ird!"  ""

    100.51.198.IN-ADDR.ARPA.  IN NAPTR 100  20  "u"  "ALTO:https"
         "!.*!https://alto2.example.net/ird!"  ""
</pre><a href="#section-3.4-5" class="pilcrow">¶</a>
</div>
<p id="section-3.4-6">If no matching U-NAPTR records can be found,
            the procedure <span class="bcp14">SHOULD</span> try further lookups, using the domain
            names from the fourth column in the indicated order, until one
            lookup
            succeeds.  If no IRD URI can be found after looking up
            all domain names from the 3rd and 4th columns, the procedure
            terminates unsuccessfully, returning an empty URI list.<a href="#section-3.4-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec.3pdisc-spec-errorhandling">
<section id="section-3.5">
        <h3 id="name-error-handling">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-error-handling" class="section-name selfRef">Error Handling</a>
        </h3>
<p id="section-3.5-1">The ALTO Cross-Domain Server Discovery Procedure may fail
            for several reasons.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<p id="section-3.5-2">If the procedure is called with syntactically invalid
            parameters or unsupported parameter values (in particular, the 
            prefix length L; see <a href="#sec.3pdisc-spec-step1" class="xref">Section 3.2</a>),
            the procedure aborts, no URI list will be returned, and 
            the error has to be reported to the caller.<a href="#section-3.5-2" class="pilcrow">¶</a></p>
<p id="section-3.5-3">The procedure performs one or more DNS lookups in a
            well-defined order (corresponding to descending prefix lengths,
            see <a href="#sec.3pdisc-spec-step3" class="xref">Section 3.4</a>) until one produces
            a usable result.  Each of these DNS
            lookups might fail to produce a usable result, due to either a
            normal condition (e.g., a domain name exists, but no ALTO-specific
            NAPTR resource records are associated with it), a permanent error
            (e.g., nonexistent domain name), or a temporary error
            (e.g., timeout).  In all three
            cases, and as long as there are further domain names that can be
            looked up, the procedure <span class="bcp14">SHOULD</span> immediately try to
     look up the
            next domain name (from Column 4 in the table given in 
            <a href="#sec.3pdisc-spec-step3" class="xref">Section 3.4</a>).
            Only after all domain names have been tried at least once, the
            procedure <span class="bcp14">MAY</span> retry those domain names that had caused temporary
            lookup errors.<a href="#section-3.5-3" class="pilcrow">¶</a></p>
<p id="section-3.5-4">Generally speaking, ALTO provides advisory
            information for the optimization of applications (peer-to-peer
     applications, overlay networks, etc.), but 
            applications should not rely on the availability of such 
            information for their basic functionality (see
            <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-8.3.4.3" class="relref">Section 8.3.4.3</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>).

            Consequently, the speedy detection of an ALTO server, even
            though it may give less accurate answers than other servers, or
            the quick realization that there is no suitable ALTO server, is
            in general preferable to causing long delays by retrying
            failed queries. 

      Nevertheless, if DNS queries have failed due to temporary errors, the
      ALTO Cross-Domain Server Discovery Procedure SHOULD inform its caller
      that DNS queries have failed for that reason and that retrying the
      discovery at a later point in time might give more accurate results.<a href="#section-3.5-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sec.xdom-usage">
<section id="section-4">
      <h2 id="name-using-the-alto-protocol-wit">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-using-the-alto-protocol-wit" class="section-name selfRef">Using the ALTO Protocol with Cross-Domain Server Discovery</a>
      </h2>
<p id="section-4-1">Based on a modular design principle, ALTO provides several ALTO
        services, each consisting of a set of information resources
        that can be accessed using the ALTO protocol.
        The information resources that are available at a specific 
        ALTO server are listed in its Information Resource Directory 
        (IRD, see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-9" class="relref">Section 9</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>).
        The ALTO protocol specification defines the following ALTO
        services and their corresponding information resources:<a href="#section-4-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-4-2.1">Network and Cost Map Service, see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-11.2" class="relref">Section 11.2</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span><a href="#section-4-2.1" class="pilcrow">¶</a>
</li>
<li id="section-4-2.2">Map-Filtering Service, see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-11.3" class="relref">Section 11.3</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span><a href="#section-4-2.2" class="pilcrow">¶</a>
</li>
<li id="section-4-2.3">Endpoint Property Service,
                    see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-11.4" class="relref">Section 11.4</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span><a href="#section-4-2.3" class="pilcrow">¶</a>
</li>
<li id="section-4-2.4">Endpoint Cost Service,
                    see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-11.5" class="relref">Section 11.5</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span><a href="#section-4-2.4" class="pilcrow">¶</a>
</li>
</ul>
<p id="section-4-3">
        The ALTO Cross-Domain Server Discovery Procedure is
        most useful in conjunction with the Endpoint Property Service and
        the Endpoint Cost Service.  However, for the sake of completeness,
        possible interaction with all four services is discussed below.
        Extension documents may specify further information resources;
        however, these are out of scope of this document.<a href="#section-4-3" class="pilcrow">¶</a></p>
<div id="sec.mapservice">
<section id="section-4.1">
        <h3 id="name-network-and-cost-map-servic">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-network-and-cost-map-servic" class="section-name selfRef">Network and Cost Map Service</a>
        </h3>
<p id="section-4.1-1"> An ALTO client may invoke the ALTO Cross-Domain Server
                Discovery Procedure (as specified in
                <a href="#sec.3pdisc-spec" class="xref">Section 3</a>) for an IP address
                or prefix X
                and get a list of one or more IRD URIs, including
                order and preference values:
                IRD_URIS_X = XDOMDISC(X,"ALTO:https"). The IRD(s)
                referenced by these URIs
                will always contain a network and a cost map, as these
                are mandatory information resources (see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-11.2" class="relref">Section 11.2</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>).
 However, the cost matrix
                may be very sparse. If, according to the network map,
                PID_X is the Provider-defined Identifier (PID; see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-5.1" class="relref">Section 5.1</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>) that contains the IP address or prefix X, and
                PID_1, PID_2, PID_3, ... are other PIDs, the cost map
                may look like this:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<span id="name-cost-map"></span><div id="PID">
<table class="center" id="table-2">
          <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-cost-map" class="selfRef">Cost Map</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">From</th>
              <th class="text-left" rowspan="1" colspan="1">To PID_1</th>
              <th class="text-left" rowspan="1" colspan="1">PID_2</th>
              <th class="text-left" rowspan="1" colspan="1">PID_X</th>
              <th class="text-left" rowspan="1" colspan="1">PID_3</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PID_1</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
              <td class="text-left" rowspan="1" colspan="1"></td>
              <td class="text-left" rowspan="1" colspan="1">92</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PID_2</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
              <td class="text-left" rowspan="1" colspan="1"></td>
              <td class="text-left" rowspan="1" colspan="1">6</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PID_X</td>
              <td class="text-left" rowspan="1" colspan="1">46</td>
              <td class="text-left" rowspan="1" colspan="1">3</td>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">19</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PID_3</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
              <td class="text-left" rowspan="1" colspan="1"></td>
              <td class="text-left" rowspan="1" colspan="1">38</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-4.1-3">
          In this example, all cells outside Column X and Row X are
          unspecified. A cost map with this structure contains the same
          information as what could be retrieved using the Endpoint Cost
          Service, Cases 1 and 2 in <a href="#sec.ecs" class="xref">Section 4.4</a>.
          Accessing cells that are neither in Column X nor Row X
          may not yield useful results.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">Trying to assemble a more densely populated cost map from several
          cost maps with this very sparse structure may be a nontrivial
          task, as different ALTO servers may use different PID definitions
          (i.e., network maps) and incompatible scales for the costs,
          in particular for the "routingcost" metric.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec.mfs">
<section id="section-4.2">
        <h3 id="name-map-filtering-service">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-map-filtering-service" class="section-name selfRef">Map-Filtering Service</a>
        </h3>
<p id="section-4.2-1"> An ALTO client may invoke the ALTO Cross-Domain Server
                Discovery Procedure (as specified in
                <a href="#sec.3pdisc-spec" class="xref">Section 3</a>) for an IP address
                or prefix X
                and get a list of one or more IRD URIs, including
                order and preference values:
                IRD_URIS_X = XDOMDISC(X,"ALTO:https"). These IRDs
                may provide the optional Map-Filtering Service
                (see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-11.3" class="relref">Section 11.3</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>).
                This service returns a subset of the full map,
                as specified by the client. As discussed in
                <a href="#sec.mapservice" class="xref">Section 4.1</a>, a cost map may
                be very sparse in the envisioned deployment scenario.
                Therefore, depending on the filtering criteria provided
                by the client, this service may return results similar
                to the Endpoint Cost Service, or it may not return any
                useful result.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec.eps">
<section id="section-4.3">
        <h3 id="name-endpoint-property-service">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-endpoint-property-service" class="section-name selfRef">Endpoint Property Service</a>
        </h3>
<p id="section-4.3-1">
                If an ALTO client wants to query an Endpoint Property Service
                (see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-11.4" class="relref">Section 11.4</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>)
                about an endpoint with IP address X or a group of endpoints
                within IP prefix X, respectively, it has to 
                invoke the ALTO Cross-Domain Server Discovery Procedure 
                (as specified in <a href="#sec.3pdisc-spec" class="xref">Section 3</a>):
                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 <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-9" class="relref">Section 9</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>).
                Considering the order and preference values, the client has
                to check these IRDs for a suitable Endpoint Property Service 
                and query it.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">
                If the ALTO client wants to do a similar Endpoint Property
                query for a different IP address or prefix "Y", the whole
                procedure has to be repeated, as IRD_URIS_Y =
                XDOMDISC(Y,"ALTO:https") may yield a different list of IRD
                URIs.  Of course, the results of individual DNS queries may
                be cached as indicated by their respective time-to-live
                (TTL) values.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec.ecs">
<section id="section-4.4">
        <h3 id="name-endpoint-cost-service">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-endpoint-cost-service" class="section-name selfRef">Endpoint Cost Service</a>
        </h3>
<p id="section-4.4-1">
                The optional ALTO Endpoint Cost Service (ECS;
                see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-11.5" class="relref">Section 11.5</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>)
                provides information about costs between individual endpoints
                and also supports ranking.
                The ECS allows endpoints to be denoted by IP
                addresses or prefixes.
                The ECS is called with a list of
                one or more source IP addresses or prefixes, which we will call
                (S1, S2, S3, ...), and a list of one or more destination
                IP addresses or prefixes, called (D1, D2, D3, ...).<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">This specification distinguishes several cases, regarding
            the number of elements in the list of source and destination
            addresses, respectively:<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-4.4-3">
          <li id="section-4.4-3.1">
            <p id="section-4.4-3.1.1">Exactly one source address S1 and more than one
                    destination addresses (D1, D2, D3, ...).  In this case,
                    the ALTO client has to invoke the ALTO Cross-Domain
                    Server Discovery Procedure (as specified in
                    <a href="#sec.3pdisc-spec" class="xref">Section 3</a>) 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 <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-9" class="relref">Section 9</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>).
                    Considering the order and preference values, the client has
                    to check these IRDs for a suitable Endpoint Cost Service
                    and query it. The ECS is an optional service (see 
                    <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-11.5.1" class="relref">Section 11.5.1</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>), and therefore, it may well be that an IRD does not
                    refer to an ECS.<a href="#section-4.4-3.1.1" class="pilcrow">¶</a></p>
<p id="section-4.4-3.1.2">
                    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 when 
                    cost metrics lack a well-defined base unit -- e.g.,
                    the "routingcost" metric.<a href="#section-4.4-3.1.2" class="pilcrow">¶</a></p>
</li>
<li id="section-4.4-3.2">More than one source address (S1, S2, S3, ...)
                    and exactly one destination address D1.  In this case,
                    the ALTO client has to invoke the ALTO Cross-Domain
                    Server Discovery Procedure with that single
                    destination address as a parameter:
                    IRD_URIS_D1 = XDOMDISC(D1,"ALTO:https").
                    The result, IRD_URIS_D1, is a list of one or more URIs of
                    IRDs.
                    Considering the order and preference values, the client has
                    to check these IRDs for a suitable ECS and query it.<a href="#section-4.4-3.2" class="pilcrow">¶</a>
</li>
<li id="section-4.4-3.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 specified above. As an alternative,
                    it may also perform the same steps as in
                    Case 2, as specified above.<a href="#section-4.4-3.3" class="pilcrow">¶</a>
</li>
<li id="section-4.4-3.4">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 separately
                    for each source address the same steps as in Case 1,
                    as specified above.  As an alternative, the ALTO
                    client may also group the list based on destination
                    addresses and perform separately for each destination
                    address the same steps as in Case 2, as specified
                    above.  However, comparing results between these
                    subqueries may be difficult, in particular if
                    the cost metric is a relative preference without
                    a well-defined base unit (e.g., the "routingcost"
                    metric).<a href="#section-4.4-3.4" class="pilcrow">¶</a>
</li>
</ol>
<p id="section-4.4-4">

                See <a href="#apx.alto_p2p" class="xref">Appendix C</a> 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.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sec.ext">
<section id="section-4.5">
        <h3 id="name-summary-and-further-extensi">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-summary-and-further-extensi" class="section-name selfRef">Summary and Further Extensions</a>
        </h3>
<p id="section-4.5-1">Considering the four services defined in the ALTO base
            protocol specification <span>[<a href="#RFC7285" class="xref">RFC7285</a>]</span>, 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 addresses.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<p id="section-4.5-2">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).<a href="#section-4.5-2" class="pilcrow">¶</a></p>
<p id="section-4.5-3">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.<a href="#section-4.5-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-5">
      <h2 id="name-implementation-deployment-a">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-implementation-deployment-a" class="section-name selfRef">Implementation, Deployment, and Operational Considerations</a>
      </h2>
<section id="section-5.1">
        <h3 id="name-considerations-for-alto-cli">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-considerations-for-alto-cli" class="section-name selfRef">Considerations for ALTO Clients</a>
        </h3>
<div id="sec.rcid">
<section id="section-5.1.1">
          <h4 id="name-resource-consumer-initiated">
<a href="#section-5.1.1" class="section-number selfRef">5.1.1. </a><a href="#name-resource-consumer-initiated" class="section-name selfRef">Resource-Consumer-Initiated Discovery</a>
          </h4>
<p id="section-5.1.1-1">Resource-consumer-initiated
                ALTO server discovery
                (cf. ALTO requirement AR-32 <span>[<a href="#RFC6708" class="xref">RFC6708</a>]</span>)
                can be seen as a special case of
                cross-domain ALTO server discovery.  To that end, an ALTO
                client embedded in a resource consumer would have to
                perform the ALTO Cross-Domain Server Discovery Procedure 
                with its own IP address as a parameter.
                However, due to the widespread deployment of Network Address
                Translators (NATs), additional protocols and mechanisms such
                as Session Traversal Utilities for NAT (STUN) <span>[<a href="#RFC5389" class="xref">RFC5389</a>]</span> are usually needed to
                detect the client's "public" IP address before it can
                be used as a parameter for the discovery procedure.
                Note that a different approach for
                resource-consumer-initiated ALTO server discovery,
                which is based on DHCP, is
                specified in
                <span>[<a href="#RFC7286" class="xref">RFC7286</a>]</span>.<a href="#section-5.1.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-5.1.2">
          <h4 id="name-ipv4-v6-dual-stack-multihom">
<a href="#section-5.1.2" class="section-number selfRef">5.1.2. </a><a href="#name-ipv4-v6-dual-stack-multihom" class="section-name selfRef">IPv4/v6 Dual Stack, Multihoming and                 Host Mobility</a>
          </h4>
<p id="section-5.1.2-1">The procedure specified in this document can discover
                ALTO server URIs for a given IP address or prefix.
                The intention is that a third party (e.g., a
                resource directory) that receives query messages from
                a resource consumer can use the source address in
                these messages to discover suitable ALTO servers for this
                specific resource consumer.<a href="#section-5.1.2-1" class="pilcrow">¶</a></p>
<p id="section-5.1.2-2">However, resource consumers (as defined in
                <span><a href="https://www.rfc-editor.org/rfc/rfc5693#section-2" class="relref">Section 2</a> of [<a href="#RFC5693" class="xref">RFC5693</a>]</span>) may reside on hosts with more than
                one IP address -- for example, due to IPv4/v6 dual stack operation
                and/or multihoming.
                IP packets sent with different source addresses may be
                subject to different routing policies and path costs.  In
                some deployment scenarios, it may even be required to ask
                different sets of ALTO servers for guidance.
                Furthermore, source addresses in IP packets may be modified
                en route by Network Address Translators (NATs).<a href="#section-5.1.2-2" class="pilcrow">¶</a></p>
<p id="section-5.1.2-3">If a resource consumer queries a resource directory for
                candidate resource providers, the locally selected (and
                possibly en-route-translated) source address of the query
 message -- as
                observed by the resource directory -- will become the
                basis for the ALTO server discovery and the subsequent
                optimization of the resource directory's reply.  If,
                however, the resource consumer then selects different source
                addresses to contact returned resource providers, the
                desired better-than-random "ALTO effect" may not
                occur.<a href="#section-5.1.2-3" class="pilcrow">¶</a></p>
<p id="section-5.1.2-4">One solution approach for this problem is that
                a dual-stack or multihomed resource consumer could
                always use the same address for contacting the 
                resource directory and all resource providers, thus
                overriding the operating system's automatic selection of
 source IP addresses.
 For example, when using the
                BSD socket API, one could always bind() the socket to one of
                the local IP addresses before trying to connect() to the
                resource directory or the resource providers, respectively.
                Another solution approach is to perform ALTO-influenced 
                resource provider selection (and source-address selection)
                locally in the resource consumer,
                in addition to, or instead of, performing it in the resource
                directory. See <a href="#sec.rcid" class="xref">Section 5.1.1</a> for
 a discussion of
                how to discover ALTO servers for local usage in the
                resource consumer.<a href="#section-5.1.2-4" class="pilcrow">¶</a></p>
<p id="section-5.1.2-5">Similarly, resource
                consumers on mobile hosts <span class="bcp14">SHOULD</span> query the resource
                directory again after a change of IP address, in order to
                get a list of candidate resource providers that is optimized
                for the new IP address.<a href="#section-5.1.2-5" class="pilcrow">¶</a></p>
</section>
<section id="section-5.1.3">
          <h4 id="name-interaction-with-network-ad">
<a href="#section-5.1.3" class="section-number selfRef">5.1.3. </a><a href="#name-interaction-with-network-ad" class="section-name selfRef">Interaction with Network Address Translation</a>
          </h4>
<p id="section-5.1.3-1">The ALTO Cross-Domain Server Discovery Procedure has
                been designed to enable the ALTO-based optimization
                of applications such as large-scale overlay networks, that
                span -- on the IP layer -- multiple administrative domains,
                possibly the whole Internet. 
                Due to the widespread usage of Network Address Translators
                (NATs), it may well be that nodes of the overlay network
                (i.e., resource consumers or resource providers) are located
                behind a NAT, maybe even behind several cascaded NATs.<a href="#section-5.1.3-1" class="pilcrow">¶</a></p>
<p id="section-5.1.3-2">If a resource directory is located in the public Internet
                (i.e., not behind a NAT) and
                receives a message from a resource consumer behind one or
                more NATs, the message's source address will be the
                public IP address of the outermost NAT in front of the
                resource consumer. The same applies if the resource
                directory is behind a different NAT than the resource 
                consumer. The resource directory may call the
                ALTO Cross-Domain Server Discovery Procedure with the
                message's source address as a parameter. In effect,
                not the resource consumer's (private) IP address, but
                the public IP address of the outermost NAT in front of it,
                will be used as a basis for ALTO optimization. This will 
                work fine as long as the network behind the NAT is not too
                big (e.g., if the NAT is in a residential gateway).<a href="#section-5.1.3-2" class="pilcrow">¶</a></p>
<p id="section-5.1.3-3">If a resource directory receives a message from a resource
                consumer and the message's source address is a "private"
                IP address <span>[<a href="#RFC1918" class="xref">RFC1918</a>]</span>, this may be a sign
                that both of them are behind the same NAT. An invocation
                of the ALTO Cross-Domain Server Discovery Procedure with
                this private address may be problematic, as this will only
                yield usable results if a DNS "split horizon" and DNSSEC
                trust anchors are configured correctly. In this situation,
                it may be more advisable to query an ALTO server that has
                been discovered using <span>[<a href="#RFC7286" class="xref">RFC7286</a>]</span> or any
                other local configuration.
                The interaction between intradomain ALTO for
                large private domains (e.g., behind a "carrier-grade NAT")
                and cross-domain, Internet-wide optimization, is beyond
                the scope of this document.<a href="#section-5.1.3-3" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-5.2">
        <h3 id="name-considerations-for-network-">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-considerations-for-network-" class="section-name selfRef">Considerations for Network Operators</a>
        </h3>
<section id="section-5.2.1">
          <h4 id="name-flexibility-vs-load-on-the-">
<a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-flexibility-vs-load-on-the-" class="section-name selfRef">Flexibility vs. Load on the DNS</a>
          </h4>
<p id="section-5.2.1-1">The ALTO Cross-Domain Server Discovery Procedure, as
 specified in <a href="#sec.3pdisc-spec" class="xref">Section 3</a>, first
                produces a list of domain names (Steps 1 and 2) and
                then looks for relevant NAPTR records associated with 
                these names, until a useful result can be found (Step 3).
                The number of candidate domain names on this
                list is a compromise between flexibility when installing
                NAPTR records and avoiding excess load on the DNS.<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
<p id="section-5.2.1-2">A single invocation of the ALTO Cross-Domain Server
                Discovery Procedure, with an IPv6 address as a parameter, may
                cause up to, but no more than, six DNS lookups for NAPTR
                records. For IPv4, the maximum is four lookups.
                Should the load on the DNS infrastructure caused by these
                lookups become a problem, one solution approach is to
                populate the DNS with ALTO-specific NAPTR records.
                If such records can be found for individual IP addresses
                (possibly installed using a wildcarding mechanism in
                the name server) or long prefixes, the
                procedure will terminate successfully and not perform
                lookups for shorter prefix lengths, thus reducing the
                total number of DNS queries.
                Another approach for reducing the load on the DNS
                infrastructure is to increase the TTL for caching negative
                answers.<a href="#section-5.2.1-2" class="pilcrow">¶</a></p>
<p id="section-5.2.1-3">On the other hand, the ALTO Cross-Domain Server Discovery
                Procedure trying to look up truncated domain names allows for
                efficient configuration of large-scale scenarios, where
                discovery is to be enabled for a large number of IP
                addresses with a small number of additional DNS resource
                records.  
                Note that it expressly has not been a design goal of this
                procedure to give clients a means of understanding the IP
                prefix delegation structure. Furthermore, this specification
                does not assume or recommend that prefix delegations should
                preferably occur at those prefix lengths that are used
                in Step 2 of this procedure 
                (see <a href="#sec.3pdisc-spec-step2" class="xref">Section 3.3</a>).
                A network operator that uses, for example, an IPv4 /18
                prefix and wants to install the NAPTR records efficiently
                could either install 64 NAPTR records (one for each of the
                /24 prefixes contained within the /18 prefix), or they could
                try to team up with the owners of the other fragments of the
                enclosing /16 prefix, in order to run a common ALTO server
                to which only one NAPTR would point.<a href="#section-5.2.1-3" class="pilcrow">¶</a></p>
</section>
<section id="section-5.2.2">
          <h4 id="name-bcp-20-and-missing-delegati">
<a href="#section-5.2.2" class="section-number selfRef">5.2.2. </a><a href="#name-bcp-20-and-missing-delegati" class="section-name selfRef">BCP 20 and Missing Delegations of the Reverse DNS</a>
          </h4>
<p id="section-5.2.2-1"><span>[<a href="#RFC2317" class="xref">RFC2317</a>]</span>, also known as BCP 20,
                describes a way to delegate the "reverse DNS" (i.e.,
                subdomains of "in-addr.arpa.") for IPv4 address ranges
                with fewer than 256 addresses (i.e., less than a whole
                /24 prefix). The ALTO Cross-Domain Server Discovery Procedure
                is compatible with this method.<a href="#section-5.2.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2.2-2">In some deployment scenarios -- e.g., residential Internet
                access -- where customers often dynamically receive a single
                IPv4 address (and/or a small IPv6 address block) from a pool
                of addresses, ISPs typically will not delegate the "reverse
                DNS" to their customers. This practice makes it impossible
                for these customers to populate the DNS with NAPTR resource
                records that point to an ALTO server of their choice. Yet,
                the ISP may publish NAPTR resource records in the
                "reverse DNS" for individual addresses or larger
                address pools (i.e., shorter prefix lengths).<a href="#section-5.2.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2.2-3">While ALTO is by no means technologically tied
                to the Border Gateway Protocol (BGP),
                it is anticipated that BGP will be an important
                source of information for ALTO and that the operator of the
                outermost BGP-enabled router will have a strong incentive to
                publish a digest of their routing policies and costs through
                ALTO.  In contrast, an individual user or an organization
                that has been assigned only a small address range 
                (i.e., an IPv4 prefix with a prefix length longer than /24)
                will typically connect to the Internet using only a single ISP,
                and they might not be interested in publishing their
                own ALTO information. Consequently, they might wish to leave
                the operation of an ALTO server up to their ISP.
                This ISP may install NAPTR resource records, which are
                needed for the ALTO Cross-Domain Server Discovery Procedure,
                in the subdomain of "in-addr.arpa." that corresponds to 
                the whole /24 prefix (cf. R24 in 
                <a href="#sec.3pdisc-spec-step2" class="xref">Section 3.3</a> of this document),
                even if delegations in the style of BCP 20 or no delegations
   at all are in use.<a href="#section-5.2.2-3" class="pilcrow">¶</a></p>
</section>
</section>
</section>
<div id="seccons">
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">A high-level discussion of security issues related to ALTO
            is part of the ALTO problem statement
            <span>[<a href="#RFC5693" class="xref">RFC5693</a>]</span>.  A classification of unwanted
            information disclosure risks, as well as specific
            security-related requirements, can be found in the ALTO
            requirements document <span>[<a href="#RFC6708" class="xref">RFC6708</a>]</span>.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">The remainder of this section focuses on security threats
            and protection mechanisms for the Cross-Domain ALTO Server Discovery
            Procedure as such.  Once the ALTO server's URI has been
            discovered, and the communication between the ALTO client and
            the ALTO server starts, the security threats and protection
            mechanisms discussed in the ALTO protocol specification
            <span>[<a href="#RFC7285" class="xref">RFC7285</a>]</span> apply.<a href="#section-6-2" class="pilcrow">¶</a></p>
<div id="sec.sec.integrity">
<section id="section-6.1">
        <h3 id="name-integrity-of-the-alto-serve">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-integrity-of-the-alto-serve" class="section-name selfRef">Integrity of the ALTO Server's URI</a>
        </h3>
<dl class="dlNewline" id="section-6.1-1">
          <dt id="section-6.1-1.1">Scenario Description</dt>
<dd id="section-6.1-1.2">
            An attacker could compromise the ALTO server
            discovery procedure or the underlying infrastructure
            in such a way that ALTO clients would discover a "wrong"
            ALTO server URI.<a href="#section-6.1-1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-6.1-1.3">Threat Discussion</dt>
<dd id="section-6.1-1.4">
            The Cross-Domain ALTO Server Discovery Procedure
            relies on a series of DNS lookups, in order to
            produce one or more URIs.
            If an attacker were able to modify or spoof any of
            the DNS records, the resulting
            URIs could be replaced by forged URIs.
            This is probably the most serious security
            concern related to ALTO server discovery. The
            discovered "wrong" ALTO server might not be able
            to give guidance to a given ALTO client at all,
            or it might give suboptimal or forged
            information. In the latter case, an attacker
            could try to use ALTO to affect the traffic
            distribution in the network or the performance
            of applications (see also
            <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-15.1" class="relref">Section 15.1</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>).
            Furthermore, a hostile ALTO server could
            threaten user privacy (see also Case (5a) in <span><a href="https://www.rfc-editor.org/rfc/rfc6708#section-5.2.1" class="relref">Section 5.2.1</a> of [<a href="#RFC6708" class="xref">RFC6708</a>]</span>).<a href="#section-6.1-1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-6.1-1.5">Protection Strategies and Mechanisms</dt>
<dd id="section-6.1-1.6">                       
            The application of DNS security (DNSSEC)
            <span>[<a href="#RFC4033" class="xref">RFC4033</a>]</span> provides a means of
            detecting and averting attacks that rely on modification
            of the DNS records while in transit. All
            implementations of the Cross-Domain ALTO Server
            Discovery Procedure <span class="bcp14">MUST</span> support DNSSEC or be able to
            use such functionality provided by the underlying
            operating system. Network operators that publish
            U-NAPTR resource records to be used for the
            Cross-Domain ALTO Server Discovery Procedure
            <span class="bcp14">SHOULD</span> use DNSSEC to protect their subdomains
            of "in-addr.arpa." and/or "ip6.arpa.", respectively.
            Additional operational precautions for safely operating
            the DNS infrastructure are required in order
            to ensure that name servers do not sign forged
            (or otherwise "wrong") resource records.
            Security considerations specific to U-NAPTR are
            described in more detail in <span>[<a href="#RFC4848" class="xref">RFC4848</a>]</span>.<a href="#section-6.1-1.6" class="pilcrow">¶</a>
</dd>
<dt id="section-6.1-1.7"></dt>
<dd id="section-6.1-1.8">
            In addition to active protection mechanisms,
            users and network operators can monitor
            application performance and network traffic
            patterns for poor performance or
            abnormalities.  If it turns out that relying on
            the guidance of a specific ALTO server does not
            result in better-than-random results, the usage
            of the ALTO server may be discontinued (see also
            <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-15.2" class="relref">Section 15.2</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>).<a href="#section-6.1-1.8" class="pilcrow">¶</a>
</dd>
<dt id="section-6.1-1.9">Note</dt>
<dd id="section-6.1-1.10">
            <p id="section-6.1-1.10.1">
            The Cross-Domain ALTO Server Discovery Procedure
            finishes successfully when it has discovered one
            or more URIs. Once an ALTO server's URI has been
            discovered and the communication between the ALTO
            client and the ALTO server starts, the security
            threats and protection mechanisms discussed in the
            ALTO protocol specification <span>[<a href="#RFC7285" class="xref">RFC7285</a>]</span>
            apply.<a href="#section-6.1-1.10.1" class="pilcrow">¶</a></p>
<p id="section-6.1-1.10.2">
            A threat related to the one considered above is the
            impersonation of an ALTO server after its correct
            URI has been discovered.  This threat and protection
            strategies are discussed in
            <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-15.1" class="relref">Section 15.1</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>.
     
            The ALTO protocol's primary mechanism for protecting
            authenticity and integrity (as well as confidentiality)
            is the use of
            HTTPS-based transport -- i.e., HTTP over TLS
            <span>[<a href="#RFC2818" class="xref">RFC2818</a>]</span>.
     
            Typically, when the URI's host component is a host
            name, a further DNS lookup is needed to map it to an
            IP address before the communication with the server
            can begin.  This last DNS lookup (for A or AAAA
            resource records) does not necessarily have to be
            protected by DNSSEC, as the server identity checks
            specified in <span>[<a href="#RFC2818" class="xref">RFC2818</a>]</span> are able to
            detect DNS spoofing or similar attacks after the
            connection to the (possibly wrong) host has been 
            established.  
            However, this validation, which is based on the
            server certificate, can only protect the steps that
            occur after the server URI has been discovered.
            It cannot detect attacks against the authenticity
            of the U-NAPTR lookups needed for the
            Cross-Domain ALTO Server Discovery Procedure,
            and therefore, these resource records have to
            be secured using DNSSEC.<a href="#section-6.1-1.10.2" class="pilcrow">¶</a></p>
</dd>
</dl>
</section>
</div>
<section id="section-6.2">
        <h3 id="name-availability-of-the-alto-se">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-availability-of-the-alto-se" class="section-name selfRef">Availability of the ALTO Server Discovery Procedure</a>
        </h3>
<dl class="dlNewline" id="section-6.2-1">
          <dt id="section-6.2-1.1">Scenario Description</dt>
<dd id="section-6.2-1.2">
            An attacker could compromise the Cross-Domain ALTO
            Server Discovery Procedure or the underlying
            infrastructure in such a way that ALTO clients would not
            be able to discover any ALTO server.<a href="#section-6.2-1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-6.2-1.3">Threat Discussion</dt>
<dd id="section-6.2-1.4">
            If no ALTO server can be discovered (although a
            suitable one exists), applications have to make
            their decisions without ALTO guidance. As ALTO
            could be temporarily unavailable for many
            reasons, applications must be prepared to do so.
            However, the resulting application performance
            and traffic distribution will correspond to a
            deployment scenario without ALTO.<a href="#section-6.2-1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-6.2-1.5">Protection Strategies and Mechanisms</dt>
<dd id="section-6.2-1.6">
            Operators should follow best current practices
            to secure their DNS and ALTO servers (see
            <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-15.5" class="relref">Section 15.5</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>)
            against Denial-of-Service (DoS) attacks.<a href="#section-6.2-1.6" class="pilcrow">¶</a>
</dd>
</dl>
</section>
<section id="section-6.3">
        <h3 id="name-confidentiality-of-the-alto">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-confidentiality-of-the-alto" class="section-name selfRef">Confidentiality of the ALTO Server's URI</a>
        </h3>
<dl class="dlNewline" id="section-6.3-1">
          <dt id="section-6.3-1.1">Scenario Description</dt>
<dd id="section-6.3-1.2">
            An unauthorized party could invoke the Cross-Domain ALTO
            Server Discovery Procedure or intercept
            discovery messages between an authorized ALTO
            client and the DNS servers, in order to
            acquire knowledge of the ALTO server URI for
            a specific IP address.<a href="#section-6.3-1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-6.3-1.3">Threat Discussion</dt>
<dd id="section-6.3-1.4">
                        In the ALTO use cases that have been described
                        in the ALTO problem statement
                        <span>[<a href="#RFC5693" class="xref">RFC5693</a>]</span> and/or discussed in the
                        ALTO working group, the ALTO server's URI as
                        such has always been considered as public
                        information that does not need protection of
                        confidentiality.<a href="#section-6.3-1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-6.3-1.5">Protection Strategies and Mechanisms</dt>
<dd id="section-6.3-1.6">
                        No protection mechanisms for this scenario have
                        been provided, as it has not been identified as
                        a relevant threat. However, if a new use case is
                        identified that requires this kind of
                        protection, the suitability of this ALTO server
                        discovery procedure as well as possible security
                        extensions have to be re-evaluated thoroughly.<a href="#section-6.3-1.6" class="pilcrow">¶</a>
</dd>
</dl>
</section>
<section id="section-6.4">
        <h3 id="name-privacy-for-alto-clients">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-privacy-for-alto-clients" class="section-name selfRef">Privacy for ALTO Clients</a>
        </h3>
<dl class="dlNewline" id="section-6.4-1">
          <dt id="section-6.4-1.1">Scenario Description</dt>
<dd id="section-6.4-1.2">
                        An unauthorized party could eavesdrop on the
                        messages between an ALTO 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 in order to optimize traffic
                        from/to a specific IP address.<a href="#section-6.4-1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-6.4-1.3">Threat Discussion</dt>
<dd id="section-6.4-1.4">
                        In the ALTO use cases that have been described
                        in the ALTO problem statement
                        <span>[<a href="#RFC5693" class="xref">RFC5693</a>]</span> and/or discussed in the
                        ALTO working group, this scenario has not been
                        identified as a relevant threat. However,
                        pervasive surveillance <span>[<a href="#RFC7624" class="xref">RFC7624</a>]</span>
                        and DNS privacy considerations <span>[<a href="#RFC7626" class="xref">RFC7626</a>]</span>
                        have seen significant attention in the Internet
                        community in recent years.<a href="#section-6.4-1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-6.4-1.5">Protection Strategies and Mechanisms</dt>
<dd id="section-6.4-1.6">
                        DNS over TLS <span>[<a href="#RFC7858" class="xref">RFC7858</a>]</span> and
                        DNS over HTTPS <span>[<a href="#RFC8484" class="xref">RFC8484</a>]</span> provide
                        means for protecting confidentiality (and integrity)
                        of DNS traffic between a client (stub) and its 
                        recursive name servers, including DNS queries
                        and replies caused by the ALTO Cross-Domain 
                        Server Discovery Procedure.<a href="#section-6.4-1.6" class="pilcrow">¶</a>
</dd>
</dl>
</section>
</section>
</div>
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-7-1">This document has no IANA actions.<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
<section id="section-8">
      <h2 id="name-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-normative-references">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC1035">[RFC1035]</dt>
<dd>
<span class="refAuthor">Mockapetris, P.</span>, <span class="refTitle">"Domain names - implementation and specification"</span>, <span class="seriesInfo">STD 13</span>, <span class="seriesInfo">RFC 1035</span>, <span class="seriesInfo">DOI 10.17487/RFC1035</span>, <time datetime="1987-11">November 1987</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1035">https://www.rfc-editor.org/info/rfc1035</a>&gt;</span>. </dd>
<dt id="RFC2119">[RFC2119]</dt>
<dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dt id="RFC3403">[RFC3403]</dt>
<dd>
<span class="refAuthor">Mealling, M.</span>, <span class="refTitle">"Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database"</span>, <span class="seriesInfo">RFC 3403</span>, <span class="seriesInfo">DOI 10.17487/RFC3403</span>, <time datetime="2002-10">October 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3403">https://www.rfc-editor.org/info/rfc3403</a>&gt;</span>. </dd>
<dt id="RFC3596">[RFC3596]</dt>
<dd>
<span class="refAuthor">Thomson, S.</span><span class="refAuthor">, Huitema, C.</span><span class="refAuthor">, Ksinant, V.</span><span class="refAuthor">, and M. Souissi</span>, <span class="refTitle">"DNS Extensions to Support IP Version 6"</span>, <span class="seriesInfo">STD 88</span>, <span class="seriesInfo">RFC 3596</span>, <span class="seriesInfo">DOI 10.17487/RFC3596</span>, <time datetime="2003-10">October 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3596">https://www.rfc-editor.org/info/rfc3596</a>&gt;</span>. </dd>
<dt id="RFC4848">[RFC4848]</dt>
<dd>
<span class="refAuthor">Daigle, L.</span>, <span class="refTitle">"Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)"</span>, <span class="seriesInfo">RFC 4848</span>, <span class="seriesInfo">DOI 10.17487/RFC4848</span>, <time datetime="2007-04">April 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4848">https://www.rfc-editor.org/info/rfc4848</a>&gt;</span>. </dd>
<dt id="RFC8174">[RFC8174]</dt>
<dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
</dl>
</section>
<section id="section-8.2">
        <h3 id="name-informative-references">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.kiesel-alto-ip-based-srv-disc">[ALTO-ANYCAST]</dt>
<dd>
<span class="refAuthor">Kiesel, S.</span><span class="refAuthor"> and R. Penno</span>, <span class="refTitle">"Application-Layer Traffic Optimization (ALTO) Anycast Address"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-kiesel-alto-ip-based-srv-disc-03</span>, <time datetime="2014-07-01">1 July 2014</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-kiesel-alto-ip-based-srv-disc-03">https://tools.ietf.org/html/draft-kiesel-alto-ip-based-srv-disc-03</a>&gt;</span>. </dd>
<dt id="I-D.kiesel-alto-alto4alto">[ALTO4ALTO]</dt>
<dd>
<span class="refAuthor">Kiesel, S.</span>, <span class="refTitle">"Using ALTO for ALTO server selection"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-kiesel-alto-alto4alto-00</span>, <time datetime="2010-07-05">5 July 2010</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-kiesel-alto-alto4alto-00">https://tools.ietf.org/html/draft-kiesel-alto-alto4alto-00</a>&gt;</span>. </dd>
<dt id="RFC1918">[RFC1918]</dt>
<dd>
<span class="refAuthor">Rekhter, Y.</span><span class="refAuthor">, Moskowitz, B.</span><span class="refAuthor">, Karrenberg, D.</span><span class="refAuthor">, de Groot, G. J.</span><span class="refAuthor">, and E. Lear</span>, <span class="refTitle">"Address Allocation for Private Internets"</span>, <span class="seriesInfo">BCP 5</span>, <span class="seriesInfo">RFC 1918</span>, <span class="seriesInfo">DOI 10.17487/RFC1918</span>, <time datetime="1996-02">February 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1918">https://www.rfc-editor.org/info/rfc1918</a>&gt;</span>. </dd>
<dt id="RFC2317">[RFC2317]</dt>
<dd>
<span class="refAuthor">Eidnes, H.</span><span class="refAuthor">, de Groot, G.</span><span class="refAuthor">, and P. Vixie</span>, <span class="refTitle">"Classless IN-ADDR.ARPA delegation"</span>, <span class="seriesInfo">BCP 20</span>, <span class="seriesInfo">RFC 2317</span>, <span class="seriesInfo">DOI 10.17487/RFC2317</span>, <time datetime="1998-03">March 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2317">https://www.rfc-editor.org/info/rfc2317</a>&gt;</span>. </dd>
<dt id="RFC2818">[RFC2818]</dt>
<dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"HTTP Over TLS"</span>, <span class="seriesInfo">RFC 2818</span>, <span class="seriesInfo">DOI 10.17487/RFC2818</span>, <time datetime="2000-05">May 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2818">https://www.rfc-editor.org/info/rfc2818</a>&gt;</span>. </dd>
<dt id="RFC4033">[RFC4033]</dt>
<dd>
<span class="refAuthor">Arends, R.</span><span class="refAuthor">, Austein, R.</span><span class="refAuthor">, Larson, M.</span><span class="refAuthor">, Massey, D.</span><span class="refAuthor">, and S. Rose</span>, <span class="refTitle">"DNS Security Introduction and Requirements"</span>, <span class="seriesInfo">RFC 4033</span>, <span class="seriesInfo">DOI 10.17487/RFC4033</span>, <time datetime="2005-03">March 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4033">https://www.rfc-editor.org/info/rfc4033</a>&gt;</span>. </dd>
<dt id="RFC4291">[RFC4291]</dt>
<dd>
<span class="refAuthor">Hinden, R.</span><span class="refAuthor"> and S. Deering</span>, <span class="refTitle">"IP Version 6 Addressing Architecture"</span>, <span class="seriesInfo">RFC 4291</span>, <span class="seriesInfo">DOI 10.17487/RFC4291</span>, <time datetime="2006-02">February 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4291">https://www.rfc-editor.org/info/rfc4291</a>&gt;</span>. </dd>
<dt id="RFC4632">[RFC4632]</dt>
<dd>
<span class="refAuthor">Fuller, V.</span><span class="refAuthor"> and T. Li</span>, <span class="refTitle">"Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan"</span>, <span class="seriesInfo">BCP 122</span>, <span class="seriesInfo">RFC 4632</span>, <span class="seriesInfo">DOI 10.17487/RFC4632</span>, <time datetime="2006-08">August 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4632">https://www.rfc-editor.org/info/rfc4632</a>&gt;</span>. </dd>
<dt id="RFC5389">[RFC5389]</dt>
<dd>
<span class="refAuthor">Rosenberg, J.</span><span class="refAuthor">, Mahy, R.</span><span class="refAuthor">, Matthews, P.</span><span class="refAuthor">, and D. Wing</span>, <span class="refTitle">"Session Traversal Utilities for NAT (STUN)"</span>, <span class="seriesInfo">RFC 5389</span>, <span class="seriesInfo">DOI 10.17487/RFC5389</span>, <time datetime="2008-10">October 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5389">https://www.rfc-editor.org/info/rfc5389</a>&gt;</span>. </dd>
<dt id="RFC5693">[RFC5693]</dt>
<dd>
<span class="refAuthor">Seedorf, J.</span><span class="refAuthor"> and E. Burger</span>, <span class="refTitle">"Application-Layer Traffic Optimization (ALTO) Problem Statement"</span>, <span class="seriesInfo">RFC 5693</span>, <span class="seriesInfo">DOI 10.17487/RFC5693</span>, <time datetime="2009-10">October 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5693">https://www.rfc-editor.org/info/rfc5693</a>&gt;</span>. </dd>
<dt id="RFC6708">[RFC6708]</dt>
<dd>
<span class="refAuthor">Kiesel, S., Ed.</span><span class="refAuthor">, Previdi, S.</span><span class="refAuthor">, Stiemerling, M.</span><span class="refAuthor">, Woundy, R.</span><span class="refAuthor">, and Y. Yang</span>, <span class="refTitle">"Application-Layer Traffic Optimization (ALTO) Requirements"</span>, <span class="seriesInfo">RFC 6708</span>, <span class="seriesInfo">DOI 10.17487/RFC6708</span>, <time datetime="2012-09">September 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6708">https://www.rfc-editor.org/info/rfc6708</a>&gt;</span>. </dd>
<dt id="RFC7216">[RFC7216]</dt>
<dd>
<span class="refAuthor">Thomson, M.</span><span class="refAuthor"> and R. Bellis</span>, <span class="refTitle">"Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS"</span>, <span class="seriesInfo">RFC 7216</span>, <span class="seriesInfo">DOI 10.17487/RFC7216</span>, <time datetime="2014-04">April 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7216">https://www.rfc-editor.org/info/rfc7216</a>&gt;</span>. </dd>
<dt id="RFC7285">[RFC7285]</dt>
<dd>
<span class="refAuthor">Alimi, R., Ed.</span><span class="refAuthor">, Penno, R., Ed.</span><span class="refAuthor">, Yang, Y., Ed.</span><span class="refAuthor">, Kiesel, S.</span><span class="refAuthor">, Previdi, S.</span><span class="refAuthor">, Roome, W.</span><span class="refAuthor">, Shalunov, S.</span><span class="refAuthor">, and R. Woundy</span>, <span class="refTitle">"Application-Layer Traffic Optimization (ALTO) Protocol"</span>, <span class="seriesInfo">RFC 7285</span>, <span class="seriesInfo">DOI 10.17487/RFC7285</span>, <time datetime="2014-09">September 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7285">https://www.rfc-editor.org/info/rfc7285</a>&gt;</span>. </dd>
<dt id="RFC7286">[RFC7286]</dt>
<dd>
<span class="refAuthor">Kiesel, S.</span><span class="refAuthor">, Stiemerling, M.</span><span class="refAuthor">, Schwan, N.</span><span class="refAuthor">, Scharf, M.</span><span class="refAuthor">, and H. Song</span>, <span class="refTitle">"Application-Layer Traffic Optimization (ALTO) Server Discovery"</span>, <span class="seriesInfo">RFC 7286</span>, <span class="seriesInfo">DOI 10.17487/RFC7286</span>, <time datetime="2014-11">November 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7286">https://www.rfc-editor.org/info/rfc7286</a>&gt;</span>. </dd>
<dt id="RFC7624">[RFC7624]</dt>
<dd>
<span class="refAuthor">Barnes, R.</span><span class="refAuthor">, Schneier, B.</span><span class="refAuthor">, Jennings, C.</span><span class="refAuthor">, Hardie, T.</span><span class="refAuthor">, Trammell, B.</span><span class="refAuthor">, Huitema, C.</span><span class="refAuthor">, and D. Borkmann</span>, <span class="refTitle">"Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement"</span>, <span class="seriesInfo">RFC 7624</span>, <span class="seriesInfo">DOI 10.17487/RFC7624</span>, <time datetime="2015-08">August 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7624">https://www.rfc-editor.org/info/rfc7624</a>&gt;</span>. </dd>
<dt id="RFC7626">[RFC7626]</dt>
<dd>
<span class="refAuthor">Bortzmeyer, S.</span>, <span class="refTitle">"DNS Privacy Considerations"</span>, <span class="seriesInfo">RFC 7626</span>, <span class="seriesInfo">DOI 10.17487/RFC7626</span>, <time datetime="2015-08">August 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7626">https://www.rfc-editor.org/info/rfc7626</a>&gt;</span>. </dd>
<dt id="RFC7858">[RFC7858]</dt>
<dd>
<span class="refAuthor">Hu, Z.</span><span class="refAuthor">, Zhu, L.</span><span class="refAuthor">, Heidemann, J.</span><span class="refAuthor">, Mankin, A.</span><span class="refAuthor">, Wessels, D.</span><span class="refAuthor">, and P. Hoffman</span>, <span class="refTitle">"Specification for DNS over Transport Layer Security (TLS)"</span>, <span class="seriesInfo">RFC 7858</span>, <span class="seriesInfo">DOI 10.17487/RFC7858</span>, <time datetime="2016-05">May 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7858">https://www.rfc-editor.org/info/rfc7858</a>&gt;</span>. </dd>
<dt id="RFC7971">[RFC7971]</dt>
<dd>
<span class="refAuthor">Stiemerling, M.</span><span class="refAuthor">, Kiesel, S.</span><span class="refAuthor">, Scharf, M.</span><span class="refAuthor">, Seidel, H.</span><span class="refAuthor">, and S. Previdi</span>, <span class="refTitle">"Application-Layer Traffic Optimization (ALTO) Deployment Considerations"</span>, <span class="seriesInfo">RFC 7971</span>, <span class="seriesInfo">DOI 10.17487/RFC7971</span>, <time datetime="2016-10">October 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7971">https://www.rfc-editor.org/info/rfc7971</a>&gt;</span>. </dd>
<dt id="RFC8484">[RFC8484]</dt>
<dd>
<span class="refAuthor">Hoffman, P.</span><span class="refAuthor"> and P. McManus</span>, <span class="refTitle">"DNS Queries over HTTPS (DoH)"</span>, <span class="seriesInfo">RFC 8484</span>, <span class="seriesInfo">DOI 10.17487/RFC8484</span>, <time datetime="2018-10">October 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8484">https://www.rfc-editor.org/info/rfc8484</a>&gt;</span>. </dd>
</dl>
</section>
</section>
<div id="sec.multiplesources">
<section id="section-appendix.a">
      <h2 id="name-solution-approaches-for-par">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-solution-approaches-for-par" class="section-name selfRef">Solution Approaches for Partitioned ALTO Knowledge</a>
      </h2>
<p id="section-appendix.a-1">
            The ALTO base protocol document <span>[<a href="#RFC7285" class="xref">RFC7285</a>]</span>
            specifies the communication between an ALTO client and a
            single ALTO server. It is implicitly assumed that this
            server can answer any query, possibly with some kind of
            default value if no exact data is known. No special
            provisions were made for the case that the ALTO information
            originates from multiple sources, which are possibly under
            the control of different administrative entities (e.g.,
            different ISPs) or that the overall ALTO information is
            partitioned and stored on several ALTO servers.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<section id="section-a.1">
        <h2 id="name-classification-of-solution-">
<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-classification-of-solution-" class="section-name selfRef">Classification of Solution Approaches</a>
        </h2>
<p id="section-a.1-1">
                Various protocol extensions and other solutions have been
                proposed to deal with multiple information sources and
                partitioned knowledge.  They can be classified as follows:<a href="#section-a.1-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-a.1-2">
          <li id="section-a.1-2.1">
            <p id="section-a.1-2.1.1">
    Ensure that all ALTO servers have the same
    knowledge.<a href="#section-a.1-2.1.1" class="pilcrow">¶</a></p>
<dl class="olPercent" id="section-a.1-2.1.2">
              <dt>1.1</dt>
<dd id="section-a.1-2.1.2.1">
    Ensure data replication and synchronization
    within the provisioning protocol (cf. <span>[<a href="#RFC5693" class="xref">RFC5693</a>]</span>, Figure 1).<a href="#section-a.1-2.1.2.1" class="pilcrow">¶</a>
</dd>
<dt>1.2</dt>
<dd id="section-a.1-2.1.2.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.<a href="#section-a.1-2.1.2.2" class="pilcrow">¶</a>
</dd>
</dl>
</li>
<li id="section-a.1-2.2">
            <p id="section-a.1-2.2.1">
    Accept that different ALTO servers (possibly
    operated by different organizations, e.g., ISPs)
    do not have the same knowledge.<a href="#section-a.1-2.2.1" class="pilcrow">¶</a></p>
<dl class="olPercent" id="section-a.1-2.2.2">
              <dt>2.1</dt>
<dd id="section-a.1-2.2.2.1">
      Allow ALTO clients to send arbitrary queries to
      any ALTO server (e.g., the one discovered using
      <span>[<a href="#RFC7286" class="xref">RFC7286</a>]</span>).  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.<a href="#section-a.1-2.2.2.1" class="pilcrow">¶</a>
</dd>
<dt>2.2</dt>
<dd id="section-a.1-2.2.2.2">
      Allow ALTO clients to send arbitrary queries to
      any ALTO server (e.g., the one discovered using
      <span>[<a href="#RFC7286" class="xref">RFC7286</a>]</span>).  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.<a href="#section-a.1-2.2.2.2" class="pilcrow">¶</a>
</dd>
<dt>2.3</dt>
<dd id="section-a.1-2.2.2.3">
      ALTO clients need to use some kind of "search
      engine" that indexes ALTO servers and redirects
      and/or gives cached results.<a href="#section-a.1-2.2.2.3" class="pilcrow">¶</a>
</dd>
<dt>2.4</dt>
<dd id="section-a.1-2.2.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 href="#section-a.1-2.2.2.4" class="pilcrow">¶</a>
</dd>
</dl>
</li>
</ol>
</section>
<section id="section-a.2">
        <h2 id="name-discussion-of-solution-appr">
<a href="#section-a.2" class="section-number selfRef">A.2. </a><a href="#name-discussion-of-solution-appr" class="section-name selfRef">Discussion of Solution Approaches</a>
        </h2>
<p id="section-a.2-1">
          The provisioning or initialization protocol for
                ALTO servers
                (cf. <span>[<a href="#RFC5693" class="xref">RFC5693</a>]</span>, Figure 1)
                is currently not standardized.  It was a conscious
                decision not to include this in the scope of the
                IETF ALTO working group.  The reason is that there
                are many different kinds of information sources.
                This implementation-specific protocol will adapt them
                to the ALTO server, which offers a standardized protocol
                to the ALTO clients. However, adding the task of
                synchronization between ALTO servers to this protocol
                (i.e., Approach 1.1) would overload this protocol with a
                second functionality that requires standardization for
                seamless multidomain operation.<a href="#section-a.2-1" class="pilcrow">¶</a></p>
<p id="section-a.2-2">
   For Approaches 1.1 and 1.2, in addition to general technical
   feasibility and issues like overhead and caching efficiency, another
   aspect to consider is legal liability. Operator "A" might prefer not to
                publish information about nodes in, or paths between,
                the networks of operators "B" and "C" through A's
                ALTO server, even if A knew that information. This is
                not only a question of map size and processing load on
                A's ALTO server. Operator A could also face legal
                liability issues if that information had a bad
                impact on the traffic engineering between B's and C's
                networks or on their business models.<a href="#section-a.2-2" class="pilcrow">¶</a></p>
<p id="section-a.2-3">
                No specific actions to build a solution based on a "search
 engine" (Approach 2.3) are currently known, and it is
                unclear what could be the incentives to operate such an
                engine. Therefore, this approach is not considered in the
                remainder of this document.<a href="#section-a.2-3" class="pilcrow">¶</a></p>
</section>
<section id="section-a.3">
        <h2 id="name-the-need-for-cross-domain-a">
<a href="#section-a.3" class="section-number selfRef">A.3. </a><a href="#name-the-need-for-cross-domain-a" class="section-name selfRef">The Need for Cross-Domain ALTO Server Discovery</a>
        </h2>
<p id="section-a.3-1">
Approaches 1.1, 1.2, 2.1, and 2.2 require more than just the
specification of an ALTO protocol extension or a new protocol that
runs between ALTO servers. A large-scale,
                maybe Internet-wide, multidomain deployment would also need
                mechanisms by which an ALTO server could discover other ALTO
                servers, learn which information is available where, and
                ideally also who is authorized to publish information
                related to a given part of the network.  Approach 2.4 needs
                the same mechanisms, except that they are used on the
                client side instead of the server side.<a href="#section-a.3-1" class="pilcrow">¶</a></p>
<p id="section-a.3-2">
                It is sometimes questioned whether there is a need for a
                solution that allows clients to ask arbitrary queries, even
                if the ALTO information is partitioned and stored on many
                ALTO servers.  The main argument is that clients are
                supposed to optimize the traffic from and to themselves, and
                that the information needed for that is most likely stored
                on a "nearby" ALTO server -- i.e., the one that can be
                discovered using <span>[<a href="#RFC7286" class="xref">RFC7286</a>]</span>.  However, there
                are scenarios where the ALTO client is not co-located with
                an endpoint of the to-be-optimized data transmission.
                Instead, the ALTO client is located at a third party that
                takes part in the application signaling -- e.g., a so-called
                "tracker" in a peer-to-peer application. One such scenario,
                where it is advantageous to place the ALTO client not at an
                endpoint of the user data transmission, is analyzed in <a href="#apx.alto_p2p" class="xref">Appendix C</a>.<a href="#section-a.3-2" class="pilcrow">¶</a></p>
</section>
<section id="section-a.4">
        <h2 id="name-our-solution-approach">
<a href="#section-a.4" class="section-number selfRef">A.4. </a><a href="#name-our-solution-approach" class="section-name selfRef">Our Solution Approach</a>
        </h2>
<p id="section-a.4-1">
                Several solution approaches for cross-domain ALTO server
                discovery have been evaluated, using the criteria
                documented in <a href="#sec.xdom-disc-reqs" class="xref">Appendix B</a>.
                One of them was to use the ALTO protocol itself for
                the exchange of information availability
                <span>[<a href="#I-D.kiesel-alto-alto4alto" class="xref">ALTO4ALTO</a>]</span>.
                However, the drawback of that approach is that a new
                registration administration authority would have to
                be established.<a href="#section-a.4-1" class="pilcrow">¶</a></p>
<p id="section-a.4-2">
                This document specifies a DNS-based procedure for
                cross-domain ALTO server discovery, which was inspired by
                "Location Information Server (LIS) Discovery Using IP
                Addresses and Reverse DNS" <span>[<a href="#RFC7216" class="xref">RFC7216</a>]</span>.  The
                primary goal is that this procedure can be used on the
                client side (i.e., Approach 2.4), but together with new
                protocols or protocol extensions, it could also be used to
                implement the other solution approaches itemized above.<a href="#section-a.4-2" class="pilcrow">¶</a></p>
</section>
<section id="section-a.5">
        <h2 id="name-relation-to-the-alto-requir">
<a href="#section-a.5" class="section-number selfRef">A.5. </a><a href="#name-relation-to-the-alto-requir" class="section-name selfRef">Relation to the ALTO Requirements</a>
        </h2>
<p id="section-a.5-1">During the design phase of the overall ALTO solution, two
            different server discovery scenarios were identified and
            documented in the ALTO requirements document
            <span>[<a href="#RFC6708" class="xref">RFC6708</a>]</span>.  The first scenario,
     documented in
            Req. AR-32, can be supported using the discovery mechanisms
            specified in <span>[<a href="#RFC7286" class="xref">RFC7286</a>]</span>.
            An alternative approach, based on IP anycast
            <span>[<a href="#I-D.kiesel-alto-ip-based-srv-disc" class="xref">ALTO-ANYCAST</a>]</span>,
            has also been studied.
            This document, in contrast, tries to address Req. AR-33.<a href="#section-a.5-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="sec.xdom-disc-reqs">
<section id="section-appendix.b">
      <h2 id="name-requirements-for-cross-doma">
<a href="#section-appendix.b" class="section-number selfRef">Appendix B. </a><a href="#name-requirements-for-cross-doma" class="section-name selfRef">Requirements for Cross-Domain Server Discovery</a>
      </h2>
<p id="section-appendix.b-1">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.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<section id="section-b.1">
        <h2 id="name-discovery-client-applicatio">
<a href="#section-b.1" class="section-number selfRef">B.1. </a><a href="#name-discovery-client-applicatio" class="section-name selfRef">Discovery Client Application Programming Interface</a>
        </h2>
<p id="section-b.1-1">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.<a href="#section-b.1-1" class="pilcrow">¶</a></p>
<p id="section-b.1-2">In other words, the client would be used to retrieve a
            mapping:<a href="#section-b.1-2" class="pilcrow">¶</a></p>
<p id="section-b.1-3">(IP address, "ALTO") -&gt; IRD-URI(s)<a href="#section-b.1-3" class="pilcrow">¶</a></p>
<p id="section-b.1-4">where IRD-URI(s) is one or more URIs of
            Information Resource Directories
            (IRDs, see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-9" class="relref">Section 9</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>)
            of ALTO servers that can give reasonable guidance
            to a resource consumer with the indicated IP address.<a href="#section-b.1-4" class="pilcrow">¶</a></p>
</section>
<section id="section-b.2">
        <h2 id="name-data-storage-and-authority-">
<a href="#section-b.2" class="section-number selfRef">B.2. </a><a href="#name-data-storage-and-authority-" class="section-name selfRef">Data Storage and Authority Requirements</a>
        </h2>
<p id="section-b.2-1">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.<a href="#section-b.2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-b.3">
        <h2 id="name-cross-domain-operations-req">
<a href="#section-b.3" class="section-number selfRef">B.3. </a><a href="#name-cross-domain-operations-req" class="section-name selfRef">Cross-Domain Operations Requirements</a>
        </h2>
<p id="section-b.3-1">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.<a href="#section-b.3-1" class="pilcrow">¶</a></p>
<p id="section-b.3-2">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.<a href="#section-b.3-2" class="pilcrow">¶</a></p>
</section>
<section id="section-b.4">
        <h2 id="name-protocol-requirements">
<a href="#section-b.4" class="section-number selfRef">B.4. </a><a href="#name-protocol-requirements" class="section-name selfRef">Protocol Requirements</a>
        </h2>
<p id="section-b.4-1">The protocol must be able to operate across middleboxes,
            especially NATs and firewalls.<a href="#section-b.4-1" class="pilcrow">¶</a></p>
<p id="section-b.4-2">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.<a href="#section-b.4-2" class="pilcrow">¶</a></p>
</section>
<section id="section-b.5">
        <h2 id="name-further-requirements">
<a href="#section-b.5" class="section-number selfRef">B.5. </a><a href="#name-further-requirements" class="section-name selfRef">Further Requirements</a>
        </h2>
<p id="section-b.5-1">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.<a href="#section-b.5-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="apx.alto_p2p">
<section id="section-appendix.c">
      <h2 id="name-alto-and-tracker-based-peer">
<a href="#section-appendix.c" class="section-number selfRef">Appendix C. </a><a href="#name-alto-and-tracker-based-peer" class="section-name selfRef">ALTO and Tracker-Based Peer-to-Peer Applications</a>
      </h2>
<p id="section-appendix.c-1">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 
        <a href="#apx.alto_p2p_app" class="xref">Appendix C.1</a>,
        we introduce a generic model of such an 
        application and show why ALTO optimization is desirable. Then,
        in <a href="#apx.alto_p2p_arch" class="xref">Appendix C.2</a>,
        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 <span>[<a href="#RFC7286" class="xref">RFC7286</a>]</span>, and one relies on the 
        ALTO Cross-Domain Server Discovery Procedure. 
        In <a href="#apx.alto_p2p_eval" class="xref">Appendix C.3</a>,
        a simple mathematical
        model is used to show that the latter approach is expected to
        yield significantly better optimization results. The appendix concludes
        with <a href="#apx.alto_p2p_example" class="xref">Appendix C.4</a>,
        which details an exemplary complete walk-through of the
        ALTO Cross-Domain Server Discovery Procedure.<a href="#section-appendix.c-1" class="pilcrow">¶</a></p>
<div id="apx.alto_p2p_app">
<section id="section-c.1">
        <h2 id="name-a-generic-tracker-based-pee">
<a href="#section-c.1" class="section-number selfRef">C.1. </a><a href="#name-a-generic-tracker-based-pee" class="section-name selfRef">A Generic Tracker-Based Peer-to-Peer Application</a>
        </h2>
<p id="section-c.1-1">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.<a href="#section-c.1-1" class="pilcrow">¶</a></p>
<p id="section-c.1-2">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 href="#section-c.1-2" class="pilcrow">¶</a></p>
<p id="section-c.1-3">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.<a href="#section-c.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="apx.alto_p2p_arch">
<section id="section-c.2">
        <h2 id="name-architectural-options-for-p">
<a href="#section-c.2" class="section-number selfRef">C.2. </a><a href="#name-architectural-options-for-p" class="section-name selfRef">Architectural Options for Placing the ALTO Client</a>
        </h2>
<p id="section-c.2-1">The ALTO protocol specification <span>[<a href="#RFC7285" class="xref">RFC7285</a>]</span> details how an ALTO client
            can query an ALTO server for guiding information and receive
            the corresponding replies. However, in the considered
            scenario of a tracker-based P2P application, there are two
            fundamentally different possible locations for where to place the
            ALTO client:<a href="#section-c.2-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-c.2-2">
          <li id="section-c.2-2.1">ALTO client in the resource consumer ("peer")<a href="#section-c.2-2.1" class="pilcrow">¶</a>
</li>
<li id="section-c.2-2.2">ALTO client in the resource directory ("tracker")<a href="#section-c.2-2.2" class="pilcrow">¶</a>
</li>
</ol>
<p id="section-c.2-3">In the following, both scenarios are compared in order to
            explain the need for ALTO queries on behalf of remote resource
            consumers.<a href="#section-c.2-3" class="pilcrow">¶</a></p>
<p id="section-c.2-4">In the first scenario (see <a href="#fig.rcq" class="xref">Figure 2</a>), the
            resource consumer queries the resource directory for the
            desired resource (F1).  The resource directory returns a
            list of potential resource providers without considering
            ALTO (F2).  It is then the duty of the resource consumer to
            invoke ALTO (F3/F4), in order to solicit guidance regarding
            this list.<a href="#section-c.2-4" class="pilcrow">¶</a></p>
<p id="section-c.2-5">In the second scenario (see <a href="#fig.3pq" class="xref">Figure 4</a>),
            the resource directory has an embedded ALTO client. After 
            receiving a query for a given resource (F1), the resource directory
            invokes this ALTO client to evaluate all resource providers it 
            knows (F2/F3).  Then it returns a list, possibly shortened,
            containing the "best" resource providers to the resource
            consumer (F4).<a href="#section-c.2-5" class="pilcrow">¶</a></p>
<span id="name-tracker-based-p2p-applicati"></span><div id="fig.tracker_random_preselect">
<figure id="figure-1">
          <div class="artwork art-text alignLeft" id="section-c.2-6.1">
<pre>
 .............................          .............................
 : Tracker                   :          : Peer                      :
 :   ______                  :          :                           :
 : +-______-+                :          :            k good         :
 : |        |     +--------+ : P2P App. : +--------+ peers +------+ :
 : |   N    |     | random | : Protocol : | ALTO-  |------&gt;| data | :
 : | known  |====&gt;| pre-   |*************&gt;| biased |       | ex-  | :
 : | peers, |     | selec- | : transmit : | peer   |------&gt;| cha- | :
 : | M good |     | tion   | : n peer   : | select | n-k   | nge  | :
 : +-______-+     +--------+ : IDs      : +--------+ bad p.+------+ :
 :...........................:          :.....^.....................:
                                              |
                                              | ALTO protocol
                                            __|___
                                          +-______-+
                                          |        |
                                          | ALTO   |
                                          | server |
                                          +-______-+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-tracker-based-p2p-applicati" class="selfRef">Tracker-Based P2P Application with Random Peer Preselection</a>
          </figcaption></figure>
</div>
<span id="name-basic-message-sequence-char"></span><div id="fig.rcq">
<figure id="figure-2">
          <div class="artwork art-text alignLeft" id="section-c.2-7.1">
<pre>
Peer w. ALTO cli.            Tracker               ALTO Server
--------+--------       --------+--------       --------+--------
        | F1 Tracker query      |                       |
        |======================&gt;|                       |
        | F2 Tracker reply      |                       |
        |&lt;======================|                       |
        | F3 ALTO query         |                       |
        |----------------------------------------------&gt;|
        | F4 ALTO reply         |                       |
        |&lt;----------------------------------------------|
        |                       |                       |

====  Application protocol (i.e., tracker-based P2P app protocol)
----  ALTO protocol
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-basic-message-sequence-char" class="selfRef">Basic Message Sequence Chart for Resource Consumer-Initiated ALTO Query</a>
          </figcaption></figure>
</div>
<span id="name-tracker-based-p2p-applicatio"></span><div id="fig.tracker_alto_client">
<figure id="figure-3">
          <div class="artwork art-text alignLeft" id="section-c.2-8.1">
<pre>
 .............................          .............................
 : Tracker                   :          : Peer                      :
 :   ______                  :          :                           :
 : +-______-+                :          :                           :
 : |        |     +--------+ : P2P App. :  k good peers &amp;  +------+ :
 : |   N    |     | ALTO-  | : Protocol :  n-k bad peers   | data | :
 : | known  |====&gt;| biased |******************************&gt;| ex-  | :
 : | peers, |     | peer   | : transmit :                  | cha- | :
 : | M good |     | select | : n peer   :                  | nge  | :
 : +-______-+     +--------+ : IDs      :                  +------+ :
 :.....................^.....:          :...........................:
                       |
                       | ALTO protocol
                     __|___
                   +-______-+
                   |        |
                   | ALTO   |
                   | server |
                   +-______-+
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-tracker-based-p2p-applicatio" class="selfRef">Tracker-Based P2P Application with ALTO Client in Tracker</a>
          </figcaption></figure>
</div>
<span id="name-basic-message-sequence-chart"></span><div id="fig.3pq">
<figure id="figure-4">
          <div class="artwork art-text alignLeft" id="section-c.2-9.1">
<pre>
      Peer             Tracker w. ALTO cli.       ALTO Server
--------+--------       --------+--------       --------+--------
        | F1 Tracker query      |                       |
        |======================&gt;|                       |
        |                       | F2 ALTO query         |
        |                       |----------------------&gt;|
        |                       | F3 ALTO reply         |
        |                       |&lt;----------------------|
        | F4 Tracker reply      |                       |
        |&lt;======================|                       |
        |                       |                       |

====  Application protocol (i.e., tracker-based P2P app protocol)
----  ALTO protocol
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-basic-message-sequence-chart" class="selfRef">Basic Message Sequence Chart for ALTO Query on Behalf of Remote Resource Consumer</a>
          </figcaption></figure>
</div>
<aside id="section-c.2-10">
          <p id="section-c.2-10.1">Note: The message sequences depicted in Figures <a href="#fig.rcq" class="xref">2</a> and <a href="#fig.3pq" class="xref">4</a> may
 occur
            both in the target-aware and the target-independent query
            mode (cf. <span>[<a href="#RFC6708" class="xref">RFC6708</a>]</span>). In the
            target-independent query mode, no message exchange with the
            ALTO server might be needed after the tracker query, because
            the candidate resource providers could be evaluated using a
            locally cached "map", which has been retrieved from the ALTO
            server some time ago.<a href="#section-c.2-10.1" class="pilcrow">¶</a></p>
</aside>
</section>
</div>
<div id="apx.alto_p2p_eval">
<section id="section-c.3">
        <h2 id="name-evaluation">
<a href="#section-c.3" class="section-number selfRef">C.3. </a><a href="#name-evaluation" class="section-name selfRef">Evaluation</a>
        </h2>
<p id="section-c.3-1">The problem with the first approach is that while the
            resource directory might know thousands of peers taking part
            in a swarm, the list returned to the resource consumer is
            usually shortened for efficiency reasons. Therefore, the
            "best" (in the sense of ALTO) potential resource providers
            might not be contained in that list anymore, even before
            ALTO can consider them.<a href="#section-c.3-1" class="pilcrow">¶</a></p>
<p id="section-c.3-2">For illustration, consider a simple model of a swarm, in
            which all peers fall into one of only two categories: assume
            that there are only "good" (in the sense of ALTO's
            better-than-random peer selection, based on an arbitrary
            desired rating criterion) and "bad" peers. Having more
            different categories makes the math more complex but does
            not change anything about the basic outcome of this analysis.
            Assume that the swarm has a total number of N peers, out of
            which there are M "good" and N-M "bad" peers, which are all known
            to the tracker. A new peer wants to join the swarm and
            therefore asks the tracker for a list of peers.<a href="#section-c.3-2" class="pilcrow">¶</a></p>
<p id="section-c.3-3">If, according to the first approach, the tracker randomly
            picks n peers from the N known peers, the result can be
            described with the hypergeometric distribution. The
            probability that the tracker reply contains exactly k "good"
            peers (and n-k "bad" peers) is:<a href="#section-c.3-3" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-c.3-4">
<pre>
            / 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)!
</pre><a href="#section-c.3-4" class="pilcrow">¶</a>
</div>
<p id="section-c.3-5">The probability that the reply contains at most k "good"
            peers is: P(X&lt;=k) = P(X=0) + P(X=1) + .. + P⁠(X=k).<a href="#section-c.3-5" class="pilcrow">¶</a></p>
<p id="section-c.3-6">For example, consider a swarm with N=10,000 peers known
            to the tracker, out of which M=100 are "good" peers. If the
            tracker randomly selects n=100 peers, the formula yields for
            the reply: P⁠(X=0)=36%, P(X&lt;=4)=99%. That is, with a
            probability of approximately 36%, this list does not contain a
            single "good" peer, and with 99% probability, there are only
            four or fewer of the "good" peers on the list.  Processing
            this list with the guiding ALTO information will ensure that
            the few favorable peers are ranked to the top of the list;
            however, the benefit is rather limited as the number of
            favorable peers in the list is just too small.<a href="#section-c.3-6" class="pilcrow">¶</a></p>
<p id="section-c.3-7">Much better traffic optimization could be achieved if the
            tracker would evaluate all known peers using ALTO and
            return a list of 100 peers afterwards.  This list would then
            include a significantly higher fraction of "good"
            peers. (Note that if the tracker returned "good" peers
            only, there might be a risk that the swarm might disconnect
            and split into several disjunct partitions.  However,
            finding the right mix of ALTO-biased and random peer
            selection is out of the scope of this document.)<a href="#section-c.3-7" class="pilcrow">¶</a></p>
<p id="section-c.3-8">Therefore, from an overall optimization perspective, the
            second scenario with the ALTO client embedded in the
            resource directory is advantageous, because it is ensured
            that the addresses of the "best" resource providers are
            actually delivered to the resource consumer. An
            architectural implication of this insight is that the ALTO
            server discovery procedures must support ALTO queries on
            behalf of remote resource consumers.
            That is, as the tracker issues ALTO queries on
            behalf of the peer that contacted the tracker, 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.<a href="#section-c.3-8" class="pilcrow">¶</a></p>
<p id="section-c.3-9"><a href="#section-c.3-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="apx.alto_p2p_example">
<section id="section-c.4">
        <h2 id="name-example">
<a href="#section-c.4" class="section-number selfRef">C.4. </a><a href="#name-example" class="section-name selfRef">Example</a>
        </h2>
<p id="section-c.4-1">This section provides a complete example of the
            ALTO Cross-Domain Server Discovery Procedure in a tracker-based
            peer-to-peer scenario.<a href="#section-c.4-1" class="pilcrow">¶</a></p>
<p id="section-c.4-2">The example is based on the network topology shown in 
            <a href="#fig.example_network_topology" class="xref">Figure 5</a>.
            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.<a href="#section-c.4-2" class="pilcrow">¶</a></p>
<span id="name-example-network-topology"></span><div id="fig.example_network_topology">
<figure id="figure-5">
          <div class="artwork art-text alignLeft" id="section-c.4-3.1">
<pre>
     _____    __             _____    __             _____    __
  __(     )__(  )_        __(     )__(  )_        __(     )__(  )_
 (    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 __)
              (___)--(____)           (___)--(____)  
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-example-network-topology" class="selfRef">Example Network Topology</a>
          </figcaption></figure>
</div>
<p id="section-c.4-4">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 with the terminology of <span>[<a href="#RFC6708" class="xref">RFC6708</a>]</span>, and 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.<a href="#section-c.4-4" class="pilcrow">¶</a></p>
<p id="section-c.4-5">As shown in the previous section, a tracker-side ALTO 
            optimization (cf. Figures <a href="#fig.tracker_alto_client" class="xref">3</a>
            and <a href="#fig.3pq" class="xref">4</a>)
            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, and X and C, in order to sort
            A, B, and C by their respective routing costs to X.<a href="#section-c.4-5" class="pilcrow">¶</a></p>
<p id="section-c.4-6">In theory, there are many options for how the
            ALTO Cross-Domain Server Discovery Procedure could be used.
            For example,
            the tracker could do the following steps:<a href="#section-c.4-6" class="pilcrow">¶</a></p>
<div id="section-c.4-7">
<pre class="sourcecode lang-pseudocode">
IRD_URIS_A = XDOMDISC(A,"ALTO:https")
COST_X_A   = query the ECS(X,A,routingcost) found in IRD_URIS_A

IRD_URIS_B = XDOMDISC(B,"ALTO:https")
COST_X_B   = query the ECS(X,B,routingcost) found in IRD_URIS_B

IRD_URIS_C = XDOMDISC(C,"ALTO:https")
COST_X_C   = query the ECS(X,C,routingcost) found in IRD_URIS_C
</pre><a href="#section-c.4-7" class="pilcrow">¶</a>
</div>
<p id="section-c.4-8">

            In this scenario, the ALTO Cross-Domain Server Discovery Procedure 
            queries might yield:  IRD_URIS_A = ALTO_SRV_A, 
            IRD_URIS_B = ALTO_SRV_B, and IRD_URIS_C = ALTO_SRV_C.
            That is, each ECS query would be sent to a different
            ALTO server. The problem with this approach is that we are
            not necessarily able to
            compare COST_X_A, COST_X_B, and COST_X_C with each
            other. The specification of the routingcost metric
            mandates that "A lower value indicates a higher preference",
            but "an ISP may internally compute routing cost using any method
            that it chooses" 
            (see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-6.1.1.1" class="relref">Section 6.1.1.1</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>).
            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 they obviously cannot be compared with each other. Even if there were
            a reasonable formula to compare, for example, kilometers
            with milliseconds, we could not use it, as the units of measurement
            (or any other information about the computation method 
            for the routingcost) are
            not sent along with the value in the ECS reply.<a href="#section-c.4-8" class="pilcrow">¶</a></p>
<p id="section-c.4-9">To avoid this problem, the tracker tries to send all
            ECS queries to the same ALTO server. As specified
            in <a href="#sec.ecs" class="xref">Section 4.4</a> of this document, Case 2, it uses
            the IP address of Resource Consumer x as a parameter of
            the discovery procedure:<a href="#section-c.4-9" class="pilcrow">¶</a></p>
<div id="section-c.4-10">
<pre class="sourcecode lang-pseudocode">
IRD_URIS_X = XDOMDISC(X,"ALTO:https")
COST_X_A   = query the ECS(X,A,routingcost) found in IRD_URIS_X
COST_X_B   = query the ECS(X,B,routingcost) found in IRD_URIS_X
COST_X_C   = query the ECS(X,C,routingcost) found in IRD_URIS_X
</pre><a href="#section-c.4-10" class="pilcrow">¶</a>
</div>
<p id="section-c.4-11">
    
            This strategy ensures that COST_X_A, COST_X_B, and COST_X_C
            can be compared with each other.<a href="#section-c.4-11" class="pilcrow">¶</a></p>
<p id="section-c.4-12"><a href="#section-c.4-12" class="pilcrow">¶</a></p>
<p id="section-c.4-13">As discussed above, the tracker calls the ALTO Cross-Domain
            Server Discovery Procedure with IP address X as a 
            parameter.  For the remainder 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").<a href="#section-c.4-13" class="pilcrow">¶</a></p>
<p id="section-c.4-14">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".<a href="#section-c.4-14" class="pilcrow">¶</a></p>
<p id="section-c.4-15">The procedure constructs
            (see Step 1 in <a href="#sec.3pdisc-spec-step1" class="xref">Section 3.2</a>)<a href="#section-c.4-15" class="pilcrow">¶</a></p>
<div id="section-c.4-16">
<pre class="sourcecode lang-pseudocode">
R128 = "2.4.E.D.A.6.E.F.F.F.E.0.7.2.2.0.2.0.0.0.1.0.0.0.
        8.B.D.0.1.0.0.2.IP6.ARPA."
</pre><a href="#section-c.4-16" class="pilcrow">¶</a>
</div>
<p id="section-c.4-17">as well as the following
            (see Step 2 in <a href="#sec.3pdisc-spec-step1" class="xref">Section 3.2</a>):<a href="#section-c.4-17" class="pilcrow">¶</a></p>
<div id="section-c.4-18">
<pre class="sourcecode lang-pseudocode">
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."
</pre><a href="#section-c.4-18" class="pilcrow">¶</a>
</div>
<p id="section-c.4-19">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 instead would use
            appropriate libraries and/or operating-system APIs.
            Please note that the following steps have been performed in a
            controlled lab environment with an appropriately configured
            name server. A suitable DNS configuration will be needed
            to reproduce these results. Please also note that the rather
            verbose output of the "dig" tool has been shortened to the
            relevant lines.<a href="#section-c.4-19" class="pilcrow">¶</a></p>
<p id="section-c.4-20">Since AT = IPv6 and L = 128, in the table given
            in <a href="#sec.3pdisc-spec-step3" class="xref">Section 3.4</a>, the sixth row
            (not counting the column headers) applies.<a href="#section-c.4-20" class="pilcrow">¶</a></p>
<p id="section-c.4-21">As mandated by the third column, we start with a lookup
            of R128, looking for NAPTR resource records:<a href="#section-c.4-21" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-c.4-22">
<pre>
| 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:
| ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NXDOMAIN, id: 26553
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0
</pre><a href="#section-c.4-22" class="pilcrow">¶</a>
</div>
<p id="section-c.4-23">

            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:<a href="#section-c.4-23" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-c.4-24">
<pre>
| user@labpc:~$ dig -tNAPTR 2.0.0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| 
| ;; Got answer:
| ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 33193
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADD'L: 0
</pre><a href="#section-c.4-24" class="pilcrow">¶</a>
</div>
<p id="section-c.4-25">

            The domain name R64 could be looked up (status: NOERROR),
            but there are no NAPTR resource records associated with it (ANSWER:
            0). There may be some other resource records such as 
            PTR, NS, or SOA, but we are not interested in them.
            Thus, we do not get a useful result, and we continue with 
            looking up R56:<a href="#section-c.4-25" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-c.4-26">
<pre>
| user@labpc:~$ dig -tNAPTR 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| 
| ;; Got answer:
| ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 35966
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
| 
| ;; ANSWER SECTION:
| 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u" 
|  "LIS:HELD" "!.*!https://lis1.example.org:4802/?c=ex!" .
| 0.0.1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 20 "u"
|  "LIS:HELD" "!.*!https://lis2.example.org:4802/?c=ex!" .
</pre><a href="#section-c.4-26" class="pilcrow">¶</a>
</div>
<p id="section-c.4-27">

            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 <span>[<a href="#RFC7216" class="xref">RFC7216</a>]</span> 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:<a href="#section-c.4-27" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-c.4-28">
<pre>
| user@labpc:~$ dig -tNAPTR 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA.
| 
| ;; Got answer:
| ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 50459
| ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADD'L: 2
| 
| ;; ANSWER SECTION:
| 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
|  "ALTO:https" "!.*!https://alto1.example.net/ird!" .
| 1.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA. 604800 IN NAPTR 100 10 "u"
|  "LIS:HELD" "!.*!https://lis.example.net:4802/?c=ex!" .
</pre><a href="#section-c.4-28" class="pilcrow">¶</a>
</div>
<p id="section-c.4-29">

            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".<a href="#section-c.4-29" class="pilcrow">¶</a></p>
<p id="section-c.4-30">The ALTO client that is embedded in the tracker will
            access the ALTO Information Resource Directory 
            (IRD, see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-9" class="relref">Section 9</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>)
            at this URI, look for the Endpoint Cost Service
            (ECS, see <span><a href="https://www.rfc-editor.org/rfc/rfc7285#section-11.5" class="relref">Section 11.5</a> of [<a href="#RFC7285" class="xref">RFC7285</a>]</span>),
            and query the ECS for the costs between A and X,
            B and X, and C and X, before returning
            an ALTO-optimized list of candidate resource providers
            to resource consumer X.<a href="#section-c.4-30" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-appendix.d">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="section-appendix.d-1">The initial draft version of this document was co-authored by
        <span class="contact-name">Marco Tomsu</span> (Alcatel-Lucent).<a href="#section-appendix.d-1" class="pilcrow">¶</a></p>
<p id="section-appendix.d-2">This document borrows some text from <span>[<a href="#RFC7286" class="xref">RFC7286</a>]</span>,
        as historically, it was part of the draft that
        eventually became said RFC.
        Special thanks to <span class="contact-name">Michael Scharf</span> and <span class="contact-name">Nico Schwan</span>.<a href="#section-appendix.d-2" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="section-appendix.e">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Sebastian Kiesel</span></div>
<div dir="auto" class="left"><span class="org">University of Stuttgart Information Center</span></div>
<div dir="auto" class="left"><span class="street-address">Allmandring 30</span></div>
<div dir="auto" class="left">
<span class="postal-code">70550</span> <span class="locality">Stuttgart</span>
</div>
<div dir="auto" class="left"><span class="country-name">Germany</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ietf-alto@skiesel.de" class="email">ietf-alto@skiesel.de</a>
</div>
<div class="url">
<span>URI:</span>
<a href="http://www.izus.uni-stuttgart.de" class="url">http://www.izus.uni-stuttgart.de</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Martin Stiemerling</span></div>
<div dir="auto" class="left"><span class="org">University of Applied Sciences Darmstadt, Computer Science Dept.</span></div>
<div dir="auto" class="left"><span class="street-address">Haardtring 100</span></div>
<div dir="auto" class="left">
<span class="postal-code">64295</span> <span class="locality">Darmstadt</span>
</div>
<div dir="auto" class="left"><span class="country-name">Germany</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+49%206151%2016%2037938" class="tel">+49 6151 16 37938</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:mls.ietf@gmail.com" class="email">mls.ietf@gmail.com</a>
</div>
<div class="url">
<span>URI:</span>
<a href="https://danet.fbi.h-da.de" class="url">https://danet.fbi.h-da.de</a>
</div>
</address>
</section>
</div>
<script>var toc = document.getElementById("toc");
var tocToggle = toc.querySelector("h2");
var tocNav = toc.querySelector("nav");

// mobile menu toggle
tocToggle.onclick = function(event) {
    if (window.innerWidth < 1024) {
 var tocNavDisplay = tocNav.currentStyle ? tocNav.currentStyle.display : getComputedStyle(tocNav, null).display;
 if (tocNavDisplay == "none") {
     tocNav.style.display = "block";
 } else {
     tocNav.style.display = "none";
 }
    }
}

// toc anchor scroll to anchor
tocNav.addEventListener("click", function (event) {
    event.preventDefault();
    if (event.target.nodeName == 'A') {
 if (window.innerWidth < 1024) {
     tocNav.style.display = "none";
 }
 var href = event.target.getAttribute("href");
 var anchorId = href.substr(1);
 var anchor =  document.getElementById(anchorId);
 anchor.scrollIntoView(true);
 window.history.pushState("","",href);
    }
});

// switch toc mode when window resized
window.onresize = function () {
    if (window.innerWidth < 1024) {
 tocNav.style.display = "none";
    } else {
 tocNav.style.display = "block";
    }
}
</script>
</body>
</html>