rfc8777xml2.original.xml   rfc8777.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 --> nsus="true" docName="draft-ietf-mboned-driad-amt-discovery-13" indexInclude="tru
e" ipr="trust200902" number="8777" prepTime="2020-04-23T09:39:05" scripts="Commo
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ n,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocIn
]> clude="true" updates="7450" xml:lang="en">
<link href="https://datatracker.ietf.org/doc/draft-ietf-mboned-driad-amt-disco
<?rfc toc="yes"?> very-13" rel="prev"/>
<?rfc sortrefs="yes"?> <link href="https://dx.doi.org/10.17487/rfc8777" rel="alternate"/>
<?rfc symrefs="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<rfc ipr="trust200902" docName="draft-ietf-mboned-driad-amt-discovery-13" catego
ry="std" updates="7450">
<front> <front>
<title abbrev="DRIAD">DNS Reverse IP AMT (Automatic Multicast Tunneling) Dis <title abbrev="DRIAD">DNS Reverse IP Automatic Multicast Tunneling (AMT) Dis
covery</title> covery</title>
<seriesInfo name="RFC" value="8777" stream="IETF"/>
<author initials="J." surname="Holland" fullname="Jake Holland"> <author initials="J." surname="Holland" fullname="Jake Holland">
<organization>Akamai Technologies, Inc.</organization> <organization showOnFrontPage="true">Akamai Technologies, Inc.</organizati on>
<address> <address>
<postal> <postal>
<street>150 Broadway</street> <street>150 Broadway</street>
<city>Cambridge, MA 02144</city> <city>Cambridge</city>
<region>MA</region>
<code>02144</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>jakeholland.net@gmail.com</email> <email>jakeholland.net@gmail.com</email>
</address> </address>
</author> </author>
<date month="04" year="2020"/>
<date year="2019" month="December" day="20"/>
<area>Ops</area> <area>Ops</area>
<workgroup>Mboned</workgroup> <workgroup>Mboned</workgroup>
<keyword>Internet-Draft</keyword> <keyword>example</keyword>
<abstract pn="section-abstract">
<abstract> <t pn="section-abstract-1">This document updates RFC 7450, "Automatic Mult
icast Tunneling" (or AMT), by
<t>This document updates RFC 7450 (Automatic Multicast Tunneling, or AMT) by modifying the relay discovery process. A new DNS resource record named
modifying the relay discovery process. A new DNS resource record named AMTRELAY is defined for publishing AMT relays for source-specific multicast
AMTRELAY is defined for publishing AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is
channels. The reverse IP DNS zone for a multicast sender’s IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays
configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT
that can receive and forward multicast traffic from that sender over an AMT tunnel. Other extensions and clarifications to the relay discovery
tunnel. Other extensions and clarifications to the relay discovery process are also defined.</t>
process are also defined.</t>
</abstract> </abstract>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t pn="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.
</t>
<t pn="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
<eref target="https://www.rfc-editor.org/info/rfc8777" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) 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.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter
" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-introduction">Introduction</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.1.2">
<li pn="section-toc.1-1.1.2.1">
<t keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derive
dContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-background">B
ackground</xref></t>
</li>
<li pn="section-toc.1-1.1.2.2">
<t pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" forma
t="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-terminology">Terminology</xref></
t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.1.2.2.2">
<li pn="section-toc.1-1.1.2.2.2.1">
<t keepWithNext="true" pn="section-toc.1-1.1.2.2.2.1.1"><xre
f derivedContent="1.2.1" format="counter" sectionFormat="of" target="section-1.2
.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-r
elays-and-gateways">Relays and Gateways</xref></t>
</li>
<li pn="section-toc.1-1.1.2.2.2.2">
<t keepWithNext="true" pn="section-toc.1-1.1.2.2.2.2.1"><xre
f derivedContent="1.2.2" format="counter" sectionFormat="of" target="section-1.2
.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-d
efinitions">Definitions</xref></t>
</li>
<li pn="section-toc.1-1.1.2.2.2.3">
<t pn="section-toc.1-1.1.2.2.2.3.1"><xref derivedContent="1.
2.3" format="counter" sectionFormat="of" target="section-1.2.3"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-requirements-language
">Requirements Language</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.2">
<t pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter
" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-relay-discovery-overview">Relay Discovery Ove
rview</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" forma
t="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-basic-mechanics">Basic Mechanics<
/xref></t>
</li>
<li pn="section-toc.1-1.2.2.2">
<t pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" forma
t="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-signaling-and-discovery">Signalin
g and Discovery</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3">
<t pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" forma
t="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-example-deployments">Example Depl
oyments</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.2.2.3.2">
<li pn="section-toc.1-1.2.2.3.2.1">
<t pn="section-toc.1-1.2.2.3.2.1.1"><xref derivedContent="2.
3.1" format="counter" sectionFormat="of" target="section-2.3.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-example-receiving-net
works">Example Receiving Networks</xref></t>
</li>
<li pn="section-toc.1-1.2.2.3.2.2">
<t pn="section-toc.1-1.2.2.3.2.2.1"><xref derivedContent="2.
3.2" format="counter" sectionFormat="of" target="section-2.3.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-example-sending-netwo
rks">Example Sending Networks</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter
" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-relay-discovery-operation">Relay Discovery Op
eration</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" forma
t="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-optimal-relay-selection">Optimal
Relay Selection</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.1.2">
<li pn="section-toc.1-1.3.2.1.2.1">
<t pn="section-toc.1-1.3.2.1.2.1.1"><xref derivedContent="3.
1.1" format="counter" sectionFormat="of" target="section-3.1.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-overview">Overview</x
ref></t>
</li>
<li pn="section-toc.1-1.3.2.1.2.2">
<t pn="section-toc.1-1.3.2.1.2.2.1"><xref derivedContent="3.
1.2" format="counter" sectionFormat="of" target="section-3.1.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-preference-ordering">
Preference Ordering</xref></t>
</li>
<li pn="section-toc.1-1.3.2.1.2.3">
<t pn="section-toc.1-1.3.2.1.2.3.1"><xref derivedContent="3.
1.3" format="counter" sectionFormat="of" target="section-3.1.3"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-connecting-to-multipl
e-rela">Connecting to Multiple Relays</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3.2.2">
<t pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" forma
t="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-happy-eyeballs">Happy Eyeballs</x
ref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.2.2">
<li pn="section-toc.1-1.3.2.2.2.1">
<t pn="section-toc.1-1.3.2.2.2.1.1"><xref derivedContent="3.
2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-overview-2">Overview<
/xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.2">
<t pn="section-toc.1-1.3.2.2.2.2.1"><xref derivedContent="3.
2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-algorithm-guidelines"
>Algorithm Guidelines</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.3">
<t pn="section-toc.1-1.3.2.2.2.3.1"><xref derivedContent="3.
2.3" format="counter" sectionFormat="of" target="section-3.2.3"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-connection-definition
">Connection Definition</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3.2.3">
<t pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" forma
t="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-guidelines-for-restarting-d">Guid
elines for Restarting Discovery</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.3.2">
<li pn="section-toc.1-1.3.2.3.2.1">
<t pn="section-toc.1-1.3.2.3.2.1.1"><xref derivedContent="3.
3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-overview-3">Overview<
/xref></t>
</li>
<li pn="section-toc.1-1.3.2.3.2.2">
<t pn="section-toc.1-1.3.2.3.2.2.1"><xref derivedContent="3.
3.2" format="counter" sectionFormat="of" target="section-3.3.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-updates-to-restarting
-event">Updates to Restarting Events</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3.2.3">
<t pn="section-toc.1-1.3.2.3.2.3.1"><xref derivedContent="3.
3.3" format="counter" sectionFormat="of" target="section-3.3.3"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-tunnel-stability">Tun
nel Stability</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3.2.4">
<t pn="section-toc.1-1.3.2.3.2.4.1"><xref derivedContent="3.
3.4" format="counter" sectionFormat="of" target="section-3.3.4"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-traffic-health">Traff
ic Health</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3.2.5">
<t pn="section-toc.1-1.3.2.3.2.5.1"><xref derivedContent="3.
3.5" format="counter" sectionFormat="of" target="section-3.3.5"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-relay-loaded-or-shutt
ing-do">Relay Loaded or Shutting Down</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3.2.6">
<t pn="section-toc.1-1.3.2.3.2.6.1"><xref derivedContent="3.
3.6" format="counter" sectionFormat="of" target="section-3.3.6"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-relay-discovery-messa
ges-vs">Relay Discovery Messages vs. Restarting Discovery</xref></t>
</li>
<li pn="section-toc.1-1.3.2.3.2.7">
<t pn="section-toc.1-1.3.2.3.2.7.1"><xref derivedContent="3.
3.7" format="counter" sectionFormat="of" target="section-3.3.7"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-independent-discovery
-per-t">Independent Discovery per Traffic Source</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3.2.4">
<t pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" forma
t="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-dns-configuration">DNS Configurat
ion</xref></t>
</li>
<li pn="section-toc.1-1.3.2.5">
<t pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" forma
t="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-waiting-for-dns-resolution">Waiti
ng for DNS Resolution</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter
" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-amtrelay-resource-record-de">AMTRELAY Resourc
e Record Definition</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" forma
t="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-amtrelay-rrtype">AMTRELAY RRType<
/xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" forma
t="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-amtrelay-rdata-format">AMTRELAY R
Data Format</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.2.2">
<li pn="section-toc.1-1.4.2.2.2.1">
<t pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.
2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-rdata-format-preceden
ce">RData Format - Precedence</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2.2.2">
<t pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.
2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-rdata-format-discover
y-opti">RData Format - Discovery Optional (D-bit)</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2.2.3">
<t pn="section-toc.1-1.4.2.2.2.3.1"><xref derivedContent="4.
2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-rdata-format-type">RD
ata Format - Type</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2.2.4">
<t pn="section-toc.1-1.4.2.2.2.4.1"><xref derivedContent="4.
2.4" format="counter" sectionFormat="of" target="section-4.2.4"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-rdata-format-relay">R
Data Format - Relay</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4.2.3">
<t pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" forma
t="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-amtrelay-record-presentatio">AMTR
ELAY Record Presentation Format</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.4.2.3.2">
<li pn="section-toc.1-1.4.2.3.2.1">
<t pn="section-toc.1-1.4.2.3.2.1.1"><xref derivedContent="4.
3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-representation-of-amt
relay-">Representation of AMTRELAY RRs</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3.2.2">
<t pn="section-toc.1-1.4.2.3.2.2.1"><xref derivedContent="4.
3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>.  <xref derive
dContent="" format="title" sectionFormat="of" target="name-examples">Examples</x
ref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter
" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xre
f></t>
</li>
<li pn="section-toc.1-1.6">
<t pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter
" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-security-considerations">Security Considerati
ons</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" forma
t="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-use-of-amt">Use of AMT</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" forma
t="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-record-spoofing">Record-Spoofing<
/xref></t>
</li>
<li pn="section-toc.1-1.6.2.3">
<t pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" forma
t="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-congestion">Congestion</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter
" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="titl
e" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.7.2">
<li pn="section-toc.1-1.7.2.1">
<t pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" forma
t="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-normative-references">Normative R
eferences</xref></t>
</li>
<li pn="section-toc.1-1.7.2.2">
<t pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" forma
t="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent=""
format="title" sectionFormat="of" target="name-informative-references">Informati
ve References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.8">
<t pn="section-toc.1-1.8.1"><xref derivedContent="Appendix A" format
="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedConte
nt="" format="title" sectionFormat="of" target="name-unknown-rrtype-construction
">Unknown RRType Construction</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" se
ctionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="ti
tle" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></
t>
</li>
<li pn="section-toc.1-1.10">
<t pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" s
ectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="t
itle" sectionFormat="of" target="name-authors-address">Author's Address</xref></
t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn
="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t pn="section-1-1">This document defines DNS Reverse IP AMT Discovery (DR
IAD), a mechanism for
AMT gateways to discover AMT relays that are capable of forwarding multicast
traffic from a known source IP address.</t>
<t pn="section-1-2">AMT (Automatic Multicast Tunneling) is defined in <xre
f target="RFC7450" format="default" sectionFormat="of" derivedContent="RFC7450"/
> and provides
a method to transport multicast traffic over a unicast tunnel in order to
traverse network segments that are not multicast capable.</t>
<t pn="section-1-3"><xref target="RFC7450" sectionFormat="of" section="4.1
.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7450#section-4.1
.5" derivedContent="RFC7450"/> explains that the relay selection process
for AMT is intended to be more flexible than the particular discovery method
described in that document. That section further explains that the selection pr
ocess
might need to depend on the source of the multicast traffic in some
deployments, since a relay must be able to receive multicast traffic from the
desired source in order to forward it.</t>
<t pn="section-1-4"><xref target="RFC7450" sectionFormat="of" section="4.1
.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7450#section-4.1
.5" derivedContent="RFC7450"/> goes on
to suggest DNS-based queries as a possible solution: DRIAD is DNS based.
This solution also
addresses the relay discovery issues in the "Disadvantages of this configuratio
n" lists in Sections
<xref target="RFC8313" sectionFormat="bare" section="3.3" format="default" deri
vedLink="https://rfc-editor.org/rfc/rfc8313#section-3.3" derivedContent="RFC8313
"/> and
<xref target="RFC8313" sectionFormat="bare" section="3.4" format="default" deri
vedLink="https://rfc-editor.org/rfc/rfc8313#section-3.4" derivedContent="RFC8313
"/> of <xref target="RFC8313" format="default" sectionFormat="of" derivedContent
="RFC8313"/>.</t>
<t pn="section-1-5">The goal for DRIAD is to enable multicast connectivity
between separate
multicast-enabled networks without preconfiguring any
peering arrangements between the networks when neither the sending nor the rece
iving network
is connected to a multicast-enabled backbone.</t>
<t pn="section-1-6">This document extends the relay discovery procedure de
scribed in <xref target="RFC7450" sectionFormat="of" section="5.2.3.4" format="d
efault" derivedLink="https://rfc-editor.org/rfc/rfc7450#section-5.2.3.4" derived
Content="RFC7450"/>.</t>
<section anchor="background" numbered="true" toc="include" removeInRFC="fa
lse" pn="section-1.1">
<name slugifiedName="name-background">Background</name>
<t pn="section-1.1-1">The reader is assumed to be familiar with the basi
c DNS concepts
described in <xref target="RFC1034" format="default" sectionFormat="of" derived
Content="RFC1034"/>, <xref target="RFC1035" format="default" sectionFormat="of"
derivedContent="RFC1035"/>, and the subsequent documents that update them, parti
cularly <xref target="RFC2181" format="default" sectionFormat="of" derivedConten
t="RFC2181"/>.</t>
<t pn="section-1.1-2">The reader is also assumed to be familiar with the
concepts and terminology
regarding source-specific multicast as described in <xref target="RFC4607" form
at="default" sectionFormat="of" derivedContent="RFC4607"/> and the
use of Internet Group Management Protocol Version 3 (IGMPv3) <xref target="RFC3
376" format="default" sectionFormat="of" derivedContent="RFC3376"/> and Multicas
t Listener Discovery Version 2
(MLDv2) <xref target="RFC3810" format="default" sectionFormat="of" derivedConte
nt="RFC3810"/> for group management of
source-specific multicast channels, as described in <xref target="RFC4604" form
at="default" sectionFormat="of" derivedContent="RFC4604"/>.</t>
<t pn="section-1.1-3">The reader should also be familiar with AMT, parti
cularly the terminology
listed in Sections <xref target="RFC7450" sectionFormat="bare" section="3.2" fo
rmat="default" derivedLink="https://rfc-editor.org/rfc/rfc7450#section-3.2" deri
vedContent="RFC7450"/>
and <xref target="RFC7450" sectionFormat="bare" section="3.3" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc7450#section-3.3" derivedConte
nt="RFC7450"/> of <xref target="RFC7450" format="default" sectionFormat="of" der
ivedContent="RFC7450"/>.</t>
</section>
<section anchor="terminology" numbered="true" toc="include" removeInRFC="f
alse" pn="section-1.2">
<name slugifiedName="name-terminology">Terminology</name>
<section anchor="relays-and-gateways" numbered="true" toc="include" remo
veInRFC="false" pn="section-1.2.1">
<name slugifiedName="name-relays-and-gateways">Relays and Gateways</na
me>
<t pn="section-1.2.1-1">When reading this document, it's especially he
lpful to recall that once
an AMT tunnel is established, the relay receives native multicast traffic
and sends unicast tunnel-encapsulated traffic to the gateway. The gateway
receives the tunnel-encapsulated packets, decapsulates them, and forwards
them as native multicast packets, as illustrated in <xref target="figtunnel" fo
rmat="default" sectionFormat="of" derivedContent="Figure 1"/>.</t>
<figure anchor="figtunnel" align="left" suppress-title="false" pn="fig
ure-1">
<name slugifiedName="name-amt-tunnel-illustration">AMT Tunnel Illust
ration</name>
<artwork name="" type="" align="left" alt="" pn="section-1.2.1-2.1">
<section anchor="intro" title="Introduction"> Multicast +-----------+ Unicast +-------------+ Multicast
&gt;---------&gt; | AMT relay | &gt;=======&gt; | AMT gateway | &gt;---------&g
<t>This document defines DNS Reverse IP AMT Discovery (DRIAD), a mechanism for t;
AMT gateways to discover AMT relays that are capable of forwarding multicast +-----------+ +-------------+
traffic from a known source IP address.</t> </artwork>
</figure>
<t>AMT (Automatic Multicast Tunneling) is defined in <xref target="RFC7450"/>, a </section>
nd provides <section anchor="definitions" numbered="true" toc="include" removeInRFC=
a method to transport multicast traffic over a unicast tunnel, in order to "false" pn="section-1.2.2">
traverse non-multicast-capable network segments.</t> <name slugifiedName="name-definitions">Definitions</name>
<table align="center" pn="table-1">
<t>Section 4.1.5 of <xref target="RFC7450"/> explains that the relay selection p <name slugifiedName="name-definitions-2">Definitions</name>
rocess <thead>
for AMT is intended to be more flexible than the particular discovery method <tr>
described in that document, and further explains that the selection process <th align="right" colspan="1" rowspan="1">Term</th>
might need to depend on the source of the multicast traffic in some <th align="left" colspan="1" rowspan="1">Definition</th>
deployments, since a relay must be able to receive multicast traffic from the </tr>
desired source in order to forward it.</t> </thead>
<tbody>
<t>That section goes on to suggest DNS-based queries as a possible solution. <tr>
DRIAD is a DNS-based solution, as suggested there. This solution also <td align="right" colspan="1" rowspan="1">(S,G)</td>
addresses the relay discovery issues in the “Disadvantages” lists in Section <td align="left" colspan="1" rowspan="1">A source-specific multi
3.3 of <xref target="RFC8313"/> and Section 3.4 of <xref target="RFC8313"/>.</t> cast channel, as described in <xref target="RFC4607" format="default" sectionFor
mat="of" derivedContent="RFC4607"/>. A pair of IP addresses with a source host I
<t>The goal for DRIAD is to enable multicast connectivity between separate P and destination group IP.</td>
multicast-enabled networks when neither the sending nor the receiving network </tr>
is connected to a multicast-enabled backbone, without pre-configuring any <tr>
peering arrangement between the networks.</t> <td align="right" colspan="1" rowspan="1">CMTS</td>
<td align="left" colspan="1" rowspan="1">Cable Modem Termination
<t>This document extends the relay discovery procedure described in Section System</td>
5.2.3.4 of <xref target="RFC7450"/>.</t> </tr>
<tr>
<section anchor="background" title="Background"> <td align="right" colspan="1" rowspan="1">discovery broker</td>
<td align="left" colspan="1" rowspan="1">A broker or load balanc
<t>The reader is assumed to be familiar with the basic DNS concepts er for AMT relay
described in <xref target="RFC1034"/>, <xref target="RFC1035"/>, and the subsequ discovery, as mentioned in <xref target="RFC7450" sectionFormat=
ent documents that "of" section="4.2.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/
update them, particularly <xref target="RFC2181"/>.</t> rfc7450#section-4.2.1.1" derivedContent="RFC7450"/>.</td>
</tr>
<t>The reader is also assumed to be familiar with the concepts and terminology <tr>
regarding source-specific multicast as described in <xref target="RFC4607"/> and <td align="right" colspan="1" rowspan="1">downstream</td>
the <td align="left" colspan="1" rowspan="1">Further from the source
use of IGMPv3 <xref target="RFC3376"/> and MLDv2 <xref target="RFC3810"/> for gr of traffic, as described in <xref target="RFC7450" format="default" sectionForm
oup management of at="of" derivedContent="RFC7450"/>.</td>
source-specific multicast channels, as described in <xref target="RFC4604"/>.</t </tr>
> <tr>
<td align="right" colspan="1" rowspan="1">FQDN</td>
<t>The reader should also be familiar with AMT, particularly the terminology <td align="left" colspan="1" rowspan="1">Fully Qualified Domain
listed in Section 3.2 of <xref target="RFC7450"/> and Section 3.3 of <xref targe Name, as described in <xref target="RFC8499" format="default" sectionFormat="of"
t="RFC7450"/>.</t> derivedContent="RFC8499"/>.</td>
</tr>
</section> <tr>
<section anchor="terminology" title="Terminology"> <td align="right" colspan="1" rowspan="1">gateway</td>
<td align="left" colspan="1" rowspan="1">An AMT gateway, as desc
<section anchor="relays-and-gateways" title="Relays and Gateways"> ribed in <xref target="RFC7450" format="default" sectionFormat="of" derivedConte
nt="RFC7450"/>.</td>
<t>When reading this document, it’s especially helpful to recall that once </tr>
an AMT tunnel is established, the relay receives native multicast traffic <tr>
and sends unicast tunnel-encapsulated traffic to the gateway, and the gateway <td align="right" colspan="1" rowspan="1">L flag</td>
receives the tunnel-encapsulated packets, decapsulates them, and forwards <td align="left" colspan="1" rowspan="1">The "Limit" flag descri
them as native multicast packets, as illustrated in <xref target="figtunnel"/>.< bed in <xref target="RFC7450" sectionFormat="of" section="5.1.4.4" format="defau
/t> lt" derivedLink="https://rfc-editor.org/rfc/rfc7450#section-5.1.4.4" derivedCont
ent="RFC7450"/>.</td>
<figure title="AMT Tunnel Illustration" anchor="figtunnel"><artwork><![CDATA[ </tr>
<tr>
Multicast +-----------+ Unicast +-------------+ Multicast <td align="right" colspan="1" rowspan="1">OLT</td>
>---------> | AMT relay | >=======> | AMT gateway | >---------> <td align="left" colspan="1" rowspan="1">Optical Line Terminal</
+-----------+ +-------------+ td>
]]></artwork></figure> </tr>
<tr>
</section> <td align="right" colspan="1" rowspan="1">relay</td>
<section anchor="definitions" title="Definitions"> <td align="left" colspan="1" rowspan="1">An AMT relay, as descri
bed in <xref target="RFC7450" format="default" sectionFormat="of" derivedContent
<texttable> ="RFC7450"/>.</td>
<ttcol align='right'>Term</ttcol> </tr>
<ttcol align='left'>Definition</ttcol> <tr>
<c>(S,G)</c> <td align="right" colspan="1" rowspan="1">RPF</td>
<c>A source-specific multicast channel, as described in <xref target="RFC4 <td align="left" colspan="1" rowspan="1">Reverse Path Forwarding
607"/>. A pair of IP addresses with a source host IP and destination group IP.</ , as described in <xref target="RFC5110" format="default" sectionFormat="of" der
c> ivedContent="RFC5110"/>.</td>
<c>discovery broker</c> </tr>
<c>A broker or load balancer for AMT relay discovery, as mentioned in sect <tr>
ion 4.2.1.1 of <xref target="RFC7450"/>.</c> <td align="right" colspan="1" rowspan="1">RR</td>
<c>downstream</c> <td align="left" colspan="1" rowspan="1">A DNS Resource Record,
<c>Further from the source of traffic, as described in <xref target="RFC74 as described in <xref target="RFC1034" format="default" sectionFormat="of" deriv
50"/>.</c> edContent="RFC1034"/>.</td>
<c>FQDN</c> </tr>
<c>Fully Qualified Domain Name, as described in <xref target="RFC8499"/></ <tr>
c> <td align="right" colspan="1" rowspan="1">RRType</td>
<c>gateway</c> <td align="left" colspan="1" rowspan="1">A DNS Resource Record T
<c>An AMT gateway, as described in <xref target="RFC7450"/></c> ype, as described in <xref target="RFC1034" format="default" sectionFormat="of"
<c>L flag</c> derivedContent="RFC1034"/>.</td>
<c>The “Limit” flag described in Section 5.1.4.4 of <xref target="RFC7450" </tr>
/></c> <tr>
<c>relay</c> <td align="right" colspan="1" rowspan="1">SSM</td>
<c>An AMT relay, as described in <xref target="RFC7450"/></c> <td align="left" colspan="1" rowspan="1">Source-specific multica
<c>RPF</c> st, as described in <xref target="RFC4607" format="default" sectionFormat="of" d
<c>Reverse Path Forwarding, as described in <xref target="RFC5110"/></c> erivedContent="RFC4607"/>.</td>
<c>RR</c> </tr>
<c>A DNS Resource Record, as described in <xref target="RFC1034"/></c> <tr>
<c>RRType</c> <td align="right" colspan="1" rowspan="1">upstream</td>
<c>A DNS Resource Record Type, as described in <xref target="RFC1034"/></c <td align="left" colspan="1" rowspan="1">Closer to the source of
> traffic, as described in <xref target="RFC7450" format="default" sectionFormat=
<c>SSM</c> "of" derivedContent="RFC7450"/>.</td>
<c>Source-specific multicast, as described in <xref target="RFC4607"/></c> </tr>
<c>upstream</c> </tbody>
<c>Closer to the source of traffic, as described in <xref target="RFC7450" </table>
/>.</c> </section>
<c>CMTS</c> <section anchor="reqs" numbered="true" toc="include" removeInRFC="false"
<c>Cable Modem Termination System</c> pn="section-1.2.3">
<c>OLT</c> <name slugifiedName="name-requirements-language">Requirements Language
<c>Optical Line Terminal</c> </name>
</texttable> <t pn="section-1.2.3-1">
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQ
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL UIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOU
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, LD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>
“MAY”, and “OPTIONAL” in this document are to be interpreted as NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be interpreted as
appear in all capitals, as shown here.</t> described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="
of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFo
</section> rmat="of" derivedContent="RFC8174"/>
</section> when, and only when, they appear in all capitals, as shown here.
</section> </t>
<section anchor="relay-discovery-overview" title="Relay Discovery Overview"> </section>
</section>
<section anchor="basic-mechanics" title="Basic Mechanics"> </section>
<section anchor="relay-discovery-overview" numbered="true" toc="include" rem
<t>The AMTRELAY resource record (RR) defined in this document is used to oveInRFC="false" pn="section-2">
publish the IP address or domain name of a set of AMT relays or discovery <name slugifiedName="name-relay-discovery-overview">Relay Discovery Overvi
brokers that can receive, encapsulate, and forward multicast traffic from ew</name>
a particular sender.</t> <section anchor="basic-mechanics" numbered="true" toc="include" removeInRF
C="false" pn="section-2.1">
<t>The sender is the owner of the RR, and configures the zone so that it <name slugifiedName="name-basic-mechanics">Basic Mechanics</name>
contains a set of RRs that provide the addresses or domain names of AMT <t pn="section-2.1-1">The AMTRELAY resource record (RR) defined in this
relays (or discovery brokers that advertise relays) that can receive document is used to
multicast IP traffic from that sender.</t> publish the IP address or domain name of a set of AMT relays or discovery
brokers that can receive, encapsulate, and forward multicast traffic from
<t>This enables AMT gateways in remote networks to discover an AMT relay that a particular sender.</t>
is capable of forwarding traffic from the sender. This in turn enables those <t pn="section-2.1-2">The sender is the owner of the RR and configures t
AMT gateways to receive the multicast traffic tunneled over a unicast AMT he zone so that it
tunnel from those relays, and then to pass the multicast packets into contains a set of RRs that provide the addresses or domain names of AMT
networks or applications that are using the gateway to subscribe to traffic relays (or discovery brokers that advertise relays) that can receive
from that sender.</t> multicast IP traffic from that sender.</t>
<t pn="section-2.1-3">This enables AMT gateways in remote networks to di
<t>This mechanism only works for source-specific multicast (SSM) channels. The scover an AMT relay that
source address of the (S,G) is reversed and used as an index into one of the is capable of forwarding traffic from the sender. This, in turn, enables those
reverse mapping trees (in-addr.arpa for IPv4, as described in Section 3.5 of AMT gateways to receive the multicast traffic tunneled over a unicast AMT
<xref target="RFC1035"/>, or ip6.arpa for IPv6, as described in Section 2.5 of < tunnel from those relays and then pass the multicast packets into
xref target="RFC3596"/>).</t> networks or applications that are using the gateway to subscribe to traffic
from that sender.</t>
<t>This mechanism should be treated as an extension of the AMT relay discovery <t pn="section-2.1-4">This mechanism only works for source-specific mult
procedure described in Section 5.2.3.4 of <xref target="RFC7450"/>. A gateway t icast (SSM) channels. The
hat source address of the (S,G) is reversed and used as an index into one of the
supports this method of AMT relay discovery SHOULD use this method reverse mapping trees (in-addr.arpa for IPv4, as described in <xref target="RFC
whenever it’s performing the relay discovery procedure, and the source IP 1035" sectionFormat="of" section="3.5" format="default" derivedLink="https://rfc
addresses for desired (S,G)s are known to the gateway, and conditions match -editor.org/rfc/rfc1035#section-3.5" derivedContent="RFC1035"/>, or ip6.arpa for
the requirements outlined in <xref target="priority"/>.</t> IPv6, as
described in <xref target="RFC3596" sectionFormat="of" section="2.5" for
<t>Some detailed example use cases are provided in <xref target="exampledeployme mat="default" derivedLink="https://rfc-editor.org/rfc/rfc3596#section-2.5" deriv
nts"/>, and edContent="RFC3596"/>).</t>
other applicable example topologies appear in Section 3.3 of <xref target="RFC83 <t pn="section-2.1-5">This mechanism should be treated as an extension o
13"/>, f the AMT relay discovery
Section 3.4 of <xref target="RFC8313"/>, and Section 3.5 of <xref target="RFC831 procedure described in <xref target="RFC7450" sectionFormat="of" section="5.2.3
3"/>.</t> .4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7450#section-5.2
.3.4" derivedContent="RFC7450"/>. A gateway that
</section> supports this method of AMT relay discovery <bcp14>SHOULD</bcp14> use this meth
<section anchor="signaling-and-discovery" title="Signaling and Discovery"> od
whenever it's performing the relay discovery procedure, the source IP
<t>This section describes a typical example of the end-to-end process for addresses for desired (S,G)s are known to the gateway, and conditions match
signaling a receiver’s join of an SSM channel that relies on an AMTRELAY the requirements outlined in <xref target="priority" format="default" sectionFo
RR.</t> rmat="of" derivedContent="Section 3.1"/>.</t>
<t pn="section-2.1-6">Some detailed example use cases are provided in <x
<t>The example in <xref target="figmessaging"/> contains 2 multicast-enabled ref target="exampledeployments" format="default" sectionFormat="of" derivedConte
networks that are both connected to the internet with non-multicast-capable nt="Section 2.3"/>, and
links, and which have no direct association with each other.</t> other applicable example topologies appear in Sections <xref target="RFC8313" s
ectionFormat="bare" section="3.3" format="default" derivedLink="https://rfc-edit
<t>A content provider operates a sender, which is a source of multicast traffic or.org/rfc/rfc8313#section-3.3" derivedContent="RFC8313"/>,
inside a multicast-capable network.</t> <xref target="RFC8313" sectionFormat="bare" section="3.4" format="default" deri
vedLink="https://rfc-editor.org/rfc/rfc8313#section-3.4" derivedContent="RFC8313
<t>An end user who is a customer of the content provider has a multicast-capable "/>, and <xref target="RFC8313" sectionFormat="bare" section="3.5" format="defau
internet service provider, which operates a receiving network that uses an lt" derivedLink="https://rfc-editor.org/rfc/rfc8313#section-3.5" derivedContent=
AMT gateway. The AMT gateway is DRIAD-capable.</t> "RFC8313"/> of <xref target="RFC8313" format="default" sectionFormat="of" derive
dContent="RFC8313"/>.</t>
<t>The content provider provides the user with a receiving application that </section>
tries to subscribe to at least one (S,G). This receiving application could <section anchor="signaling-and-discovery" numbered="true" toc="include" re
for example be a file transfer system using FLUTE <xref target="RFC6726"/> or a moveInRFC="false" pn="section-2.2">
live <name slugifiedName="name-signaling-and-discovery">Signaling and Discove
video stream using RTP <xref target="RFC3550"/>, or any other application that m ry</name>
ight <t pn="section-2.2-1">This section describes a typical example of the en
subscribe to an SSM channel.</t> d-to-end process for
signaling a receiver's join of an SSM channel that relies on an AMTRELAY
<figure title="DRIAD Messaging" anchor="figmessaging"><artwork><![CDATA[ RR.</t>
+---------------+ <t pn="section-2.2-2">The example in <xref target="figmessaging" format=
| Sender | "default" sectionFormat="of" derivedContent="Figure 2"/> contains two multicast-
| | | 2001:db8::a | enabled
| | +---------------+ networks that are both connected to the internet with non-multicast-capable
|Data| | links and which have no direct association with each other.</t>
|Flow| Multicast | <t pn="section-2.2-3">A content provider operates a sender, which is a s
\| |/ Network | ource of multicast traffic
\ / | 5: Propagate RPF for Join(S,G) inside a multicast-capable network.</t>
\ / +---------------+ <t pn="section-2.2-4">An end user who is a customer of the content provi
\/ | AMT Relay | der has a multicast-capable
| 2001:db8:c::f | Internet Service Provider (ISP), which operates a receiving network that uses a
+---------------+ n
| 4: Gateway connects to Relay, AMT gateway. The AMT gateway is DRIAD capable.</t>
sends Join(S,G) over tunnel <t pn="section-2.2-5">The content provider provides the user with a rece
| iving application that
Unicast tries to subscribe to at least one (S,G). This receiving application could,
Tunnel | 3: --> DNS Query: type=AMTRELAY, for example, be a file transfer system using File Delivery over Unidirectional
/ a.0.0.0.0.0.0.0.0.0.0.0. Transport (FLUTE) <xref target="RFC6726" format="default" sectionFormat="of" de
^ | / 0.0.0.0.0.0.0.0.0.0.0.0. rivedContent="RFC6726"/>, a live
| / 8.b.d.0.1.0.0.2.ip6.arpa video stream using RTP <xref target="RFC3550" format="default" sectionFormat="o
| | / <-- Response: f" derivedContent="RFC3550"/>, or any other application that might
Join/Leave +-------------+ AMTRELAY=2001:db8:c::f subscribe to an SSM channel.</t>
Signals | AMT gateway | <figure anchor="figmessaging" align="left" suppress-title="false" pn="fi
| +-------------+ gure-2">
| | 2: Propagate RPF for Join(S,G) <name slugifiedName="name-driad-messaging">DRIAD Messaging</name>
| Multicast | <artwork name="" type="" align="left" alt="" pn="section-2.2-6.1">
Network | +---------------+
| 1: Join(S=2001:db8::a,G=ff3e::8000:d) | Sender |
+-------------+ | | | 2001:db8::a |
| Receiver | | | +---------------+
| (end user) | |Data| |
+-------------+ |Flow| Multicast |
]]></artwork></figure> \| |/ Network |
\ / | 5: Propagate RPF for Join(S,G)
<t>In this simple example, the sender IP is 2001:db8::a, it is sending \ / +---------------+
traffic to the group address ff3e::8000:d, and the relay IP is \/ | AMT relay |
2001:db8::c:f.</t> | 2001:db8:c::f |
+---------------+
<t>The content provider has previously configured the DNS zone that | 4: Gateway connects to Relay,
contains the reverse IP domain name for the sender’s IP address sends Join(S,G) over tunnel
so that it provides an AMTRELAY RR with the relay’s IP address. |
(See <xref target="rpformat"/> for details about the AMTRELAY RR format and Unicast
semantics.) As described in Section 2.5 of <xref target="RFC3596"/>, the Tunnel | 3: --&gt; DNS Query: type=AMTRELAY,
reverse IP FQDN of the sender’s address “2001:db8::a” is:</t> / a.0.0.0.0.0.0.0.0.0.0.0.
^ | / 0.0.0.0.0.0.0.0.0.0.0.0.
<figure><artwork><![CDATA[ | / 8.b.d.0.1.0.0.2.ip6.arpa
a.0.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. | | / &lt;-- Response:
arpa. Join/Leave +-------------+ AMTRELAY=2001:db8:c::f
]]></artwork></figure> Signals | AMT gateway |
| +-------------+
<t>The sequence of events depicted in <xref target="figmessaging"/> is as follow | | 2: Propagate RPF for Join(S,G)
s:</t> | Multicast |
Network |
<t><list style="numbers"> | 1: Join(S=2001:db8::a,G=ff3e::8000:d)
<t>The end user starts the app, which issues a join to the (S,G): +-------------+
(2001:db8::a, ff3e::8000:d).</t> | Receiver |
<t>The join propagates with RPF through the receiver’s multicast-enabled | (end user) |
network with PIM <xref target="RFC7761"/> or another multicast routing mechanism +-------------+
, </artwork>
until the AMT gateway receives a signal to join the (S,G).</t> </figure>
<t>The AMT gateway performs a reverse DNS lookup for the AMTRELAY RRType, <t pn="section-2.2-7">In this simple example, the sender IP is 2001:db8:
by sending an AMTRELAY RRType query for the reverse IP domain name :a, which is sending
for the sender’s source IP address (the S from the (S,G)). <vspace blankLines=' traffic to the group address ff3e::8000:d, and the relay IP is
1'/> 2001:db8::c:f.</t>
The DNS resolver for the AMT gateway uses ordinary DNS recursive <t pn="section-2.2-8">The content provider has previously configured the
resolution until it has the authoritative result that the content DNS zone that
provider configured, which informs the AMT gateway that the relay address contains the reverse IP domain name for the sender's IP address
is 2001:db8::c:f.</t> so that it provides an AMTRELAY RR with the relay's IP address
<t>The AMT gateway performs AMT handshakes with the AMT relay as described (see <xref target="rpformat" format="default" sectionFormat="of" derivedContent
in Section 4 of <xref target="RFC7450"/>, then forwards a Membership report to t ="Section 4.3"/> for details about the AMTRELAY RR format and
he semantics). As described in <xref target="RFC3596" sectionFormat="of" section=
relay indicating subscription to the (S,G).</t> "2.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3596#section-2
<t>The relay propagates the join through its network toward the sender, .5" derivedContent="RFC3596"/>, the
then forwards the appropriate AMT-encapsulated traffic to the reverse IP FQDN of the sender's address "2001:db8::a" is:</t>
gateway, which decapsulates and forwards it as native multicast through <sourcecode name="" type="" markers="false" pn="section-2.2-9">
its downstream network to the end user.</t> a.0.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.
</list></t> arpa.
</sourcecode>
<t>In the case of an IPv4 (S,G), the only difference in the AMT relay <t pn="section-2.2-10">The sequence of events depicted in <xref target="
discovery process is the use of the in-addr.arpa reverse IP domain name, figmessaging" format="default" sectionFormat="of" derivedContent="Figure 2"/> is
as described in Section 3.5 of <xref target="RFC1035"/>, instead of the in6.arpa as follows:</t>
domain name. For example, if the (S,G) is (198.51.100.12, 232.252.0.2), <ol spacing="normal" type="1" start="1" pn="section-2.2-11">
the reverse IP FQDN for the AMTRELAY query would be <li pn="section-2.2-11.1" derivedCounter="1.">The end user starts the
“12.100.51.198.in-addr.arpa.”.</t> app, which issues a join to the (S,G):
(2001:db8::a, ff3e::8000:d).</li>
<t>Note that the address family of the AMT tunnel is independent of the <li pn="section-2.2-11.2" derivedCounter="2.">The join propagates with
address family for the multicast traffic.</t> RPF through the receiver's multicast-enabled
network with PIM <xref target="RFC7761" format="default" sectionFormat="of" der
</section> ivedContent="RFC7761"/> or another
<section anchor="exampledeployments" title="Example Deployments"> multicast routing mechanism until the AMT gateway receives a signal to
join the (S,G).</li>
<section anchor="exrx" title="Example Receiving Networks"> <li pn="section-2.2-11.3" derivedCounter="3.">
<t pn="section-2.2-11.3.1">The AMT gateway performs a reverse DNS lo
<section anchor="exrxisp" title="Internet Service Provider"> okup for the AMTRELAY
RRType by sending an AMTRELAY RRType query for the reverse IP domain
<t>One example of a receiving network is an Internet Service Provider (ISP) name
that offers multicast ingest services to its subscribers, illustrated in for the sender's source IP address (the S from the (S,G)). </t>
<xref target="figrxisp"/>.</t> <t pn="section-2.2-11.3.2">
The DNS resolver for the AMT gateway uses ordinary DNS recursive
<t>In the example network below, subscribers can join (S,G)s with MLDv2 or resolution until it has the authoritative result that the content
IGMPv3 as described in <xref target="RFC4604"/>, and the AMT gateway in this provider configured, which informs the AMT gateway that the relay address
ISP can receive and forward multicast traffic from one of the example sending is 2001:db8::c:f.</t>
networks in <xref target="extx"/> by discovering the appropriate AMT relays with </li>
a DNS <li pn="section-2.2-11.4" derivedCounter="4.">The AMT gateway performs
lookup for the AMTRELAY RR with the reverse IP of the source in the (S,G).</t> AMT handshakes with the AMT relay as described
in <xref target="RFC7450" section="4" sectionFormat="of" format="default" deriv
<figure title="Receiving ISP Example" anchor="figrxisp"><artwork><![CDATA[ edLink="https://rfc-editor.org/rfc/rfc7450#section-4" derivedContent="RFC7450"/>
Internet , then forwards a membership report to the
^ ^ Multicast-enabled relay, indicating subscription to the (S,G).</li>
| | Receiving Network <li pn="section-2.2-11.5" derivedCounter="5.">The relay propagates the
+------|------------|-------------------------+ join through its network toward the
| | | | sender and then forwards the appropriate AMT-encapsulated traffic to t
| +--------+ +--------+ +=========+ | he
| | Border |---| Border | | AMT | | gateway, which decapsulates and forwards it as a native multicast through
| | Router | | Router | | gateway | | its downstream network to the end user.</li>
| +--------+ +--------+ +=========+ | </ol>
| | | | | <t pn="section-2.2-12">In the case of an IPv4 (S,G), the only difference
| +-----+------+-----------+--+ | in the AMT relay
| | | | discovery process is the use of the in-addr.arpa reverse IP domain name,
| +-------------+ +-------------+ | as described in <xref target="RFC1035" sectionFormat="of" section="3.5" format=
| | Agg Routers | .. | Agg Routers | | "default" derivedLink="https://rfc-editor.org/rfc/rfc1035#section-3.5" derivedCo
| +-------------+ +-------------+ | ntent="RFC1035"/>, instead of the in6.arpa
| / \ \ / \ | domain name. For example, if the (S,G) is (198.51.100.12, 232.252.0.2),
| +---------------+ +---------------+ | the reverse IP FQDN for the AMTRELAY query would be
| |Access Systems | ....... |Access Systems | | "12.100.51.198.in-addr.arpa.".</t>
| |(CMTS/OLT/etc.)| |(CMTS/OLT/etc.)| | <t pn="section-2.2-13">Note that the address family of the AMT tunnel is
| +---------------+ +---------------+ | independent of the
| | | | address family for the multicast traffic.</t>
+--------|------------------------|-----------+ </section>
| | <section anchor="exampledeployments" numbered="true" toc="include" removeI
+---+-+-+---+---+ +---+-+-+---+---+ nRFC="false" pn="section-2.3">
| | | | | | | | | | <name slugifiedName="name-example-deployments">Example Deployments</name
/-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ >
|_| |_| |_| |_| |_| |_| |_| |_| |_| |_| <section anchor="exrx" numbered="true" toc="include" removeInRFC="false"
pn="section-2.3.1">
Subscribers <name slugifiedName="name-example-receiving-networks">Example Receivin
]]></artwork></figure> g Networks</name>
<section anchor="exrxisp" numbered="true" toc="exclude" removeInRFC="f
</section> alse" pn="section-2.3.1.1">
<section anchor="exoffice" title="Small Office"> <name slugifiedName="name-internet-service-provider">Internet Servic
e Provider</name>
<t>Another example receiving network is a small branch office that regularly <t pn="section-2.3.1.1-1">One example of a receiving network is an I
accesses some multicast content, illustrated in <xref target="figrxofficenm"/>.< nternet Service Provider (ISP)
/t> that offers multicast ingest services to its subscribers, illustrated in
<xref target="figrxisp" format="default" sectionFormat="of" derivedContent="Fig
<t>This office has desktop devices that need to receive some multicast traffic, ure 3"/>.</t>
so an AMT gateway runs on a LAN with these devices, to pull traffic in <t pn="section-2.3.1.1-2">In the example network below, subscribers
through a non-multicast next-hop.</t> can join (S,G)s with MLDv2 or
IGMPv3 as described in <xref target="RFC4604" format="default" sectionFormat="o
<t>The office also hosts some mobile devices that have AMT gateway instances f" derivedContent="RFC4604"/>, and the AMT gateway in this
embedded inside apps, in order to receive multicast traffic over their ISP can receive and forward multicast traffic from one of the example sending
non-multicast wireless LAN. (Note that the “Legacy Router” is a networks in <xref target="extx" format="default" sectionFormat="of" derivedCont
simplification that’s meant to describe a variety of possible conditions; ent="Section 2.3.2"/> by discovering the appropriate AMT relays with a DNS
for example it could be a device providing a split-tunnel VPN as described lookup for the AMTRELAY RR with the reverse IP of the source in the (S,G).</t>
in <xref target="RFC7359"/>, deliberately excluding multicast traffic for a VPN <figure anchor="figrxisp" align="left" suppress-title="false" pn="fi
tunnel, rather than a device which is incapable of multicast forwarding.)</t> gure-3">
<name slugifiedName="name-receiving-isp-example">Receiving ISP Exa
<figure title="Small Office (no multicast up)" anchor="figrxofficenm"><artwork>< mple</name>
![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-2.3.1.1-3
Internet .1">
(non-multicast) Internet
^ ^ ^ Multicast-enabled
| Office Network | | Receiving Network
+----------|----------------------------------+ +------|------------|-------------------------+
| | | | | | |
| +---------------+ (Wifi) Mobile apps | | +--------+ +--------+ +=========+ |
| | Modem+ | Wifi | - - - - w/ embedded | | | Border |---| Border | | AMT | |
| | Router | AP | AMT gateways | | | Router | | Router | | gateway | |
| +---------------+ | | +--------+ +--------+ +=========+ |
| | | | | | | |
| | | | +-----+------+-----------+--+ |
| +----------------+ | | | | |
| | Legacy Router | | | +-------------+ +-------------+ |
| | (unicast) | | | | Agg Routers | .. | Agg Routers | |
| +----------------+ | | +-------------+ +-------------+ |
| / | \ | | / \ \ / \ |
| / | \ | | +---------------+ +---------------+ |
| +--------+ +--------+ +--------+=========+ | | |Access Systems | ....... |Access Systems | |
| | Phones | | ConfRm | | Desks | AMT | | | |(CMTS/OLT/etc.)| |(CMTS/OLT/etc.)| |
| | subnet | | subnet | | subnet | gateway | | | +---------------+ +---------------+ |
| +--------+ +--------+ +--------+=========+ | | | | |
| | +--------|------------------------|-----------+
+---------------------------------------------+ | |
]]></artwork></figure> +---+-+-+---+---+ +---+-+-+---+---+
| | | | | | | | | |
<t>By adding an AMT relay to this office network as in <xref target="figrxoffice /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\
"/>, it’s |_| |_| |_| |_| |_| |_| |_| |_| |_| |_|
possible to make use of multicast services from the example multicast-capable
ISP in <xref target="exrxisp"/>.</t>
<figure title="Small Office Example" anchor="figrxoffice"><artwork><![CDATA[
Multicast-capable ISP
^
| Office Network
+----------|----------------------------------+
| | |
| +---------------+ (Wifi) Mobile apps |
| | Modem+ | Wifi | - - - - w/ embedded |
| | Router | AP | AMT gateways |
| +---------------+ |
| | +=======+ |
| +---Wired LAN---| AMT | |
| | | relay | |
| +----------------+ +=======+ |
| | Legacy Router | |
| | (unicast) | |
| +----------------+ |
| / | \ |
| / | \ |
| +--------+ +--------+ +--------+=========+ |
| | Phones | | ConfRm | | Desks | AMT | |
| | subnet | | subnet | | subnet | gateway | |
| +--------+ +--------+ +--------+=========+ |
| |
+---------------------------------------------+
]]></artwork></figure>
<t>When multicast-capable networks are chained like this, with a network like
the one in <xref target="figrxoffice"/> receiving internet services from a
multicast-capable network like the one in <xref target="figrxisp"/>, it’s import
ant for
AMT gateways to reach the more local AMT relay, in order to avoid
accidentally tunneling multicast traffic from a more distant AMT relay with
unicast, and failing to utilize the multicast transport capabilities of the
network in <xref target="figrxisp"/>.</t>
</section>
</section>
<section anchor="extx" title="Example Sending Networks">
<section anchor="extxsnd" title="Sender-controlled Relays">
<t>When a sender network is also operating AMT relays to distribute multicast
traffic, as in <xref target="figtxrelay"/>, each address could appear as an AMTR
ELAY RR
for the reverse IP of the sender, or one or more domain names could appear
in AMTRELAY RRs, and the AMT relay addresses can be discovered by finding
A or AAAA records from those domain names.</t>
<figure title="Small Office Example" anchor="figtxrelay"><artwork><![CDATA[
Sender Network
+-----------------------------------+
| |
| +--------+ +=======+ +=======+ |
| | Sender | | AMT | | AMT | |
| +--------+ | relay | | relay | |
| | +=======+ +=======+ |
| | | | |
| +-----+------+----------+ |
| | |
+-----------|-----------------------+
v
Internet
(non-multicast)
]]></artwork></figure>
</section>
<section anchor="extxprv" title="Provider-controlled Relays">
<t>When an ISP offers a service to transmit outbound multicast traffic through
a forwarding network, it might also offer AMT relays in order to reach
receivers without multicast connectivity to the forwarding network, as in
<xref target="figtxisp"/>. In this case it’s recommended that the ISP also provi
de at
least one domain name for the AMT relays for use with the AMTRELAY RR.</t>
<t>When the sender wishes to use the relays provided by the ISP for
forwarding multicast traffic, an AMTRELAY RR should be configured to use
the domain name provided by the ISP, to allow for address reassignment of the
relays without forcing the sender to reconfigure the corresponding AMTRELAY
RRs.</t>
<figure title="Sending ISP Example" anchor="figtxisp"><artwork><![CDATA[
+--------+
| Sender |
+---+----+ Multicast-enabled
| Sending Network
+-----------|-------------------------------+
| v |
| +------------+ +=======+ +=======+ |
| | Agg Router | | AMT | | AMT | |
| +------------+ | relay | | relay | |
| | +=======+ +=======+ |
| | | | |
| +-----+------+--------+---------+ |
| | | |
| +--------+ +--------+ |
| | Border |---| Border | |
| | Router | | Router | |
| +--------+ +--------+ |
+-----|------------|------------------------+
| |
v v
Internet
(non-multicast)
]]></artwork></figure>
</section>
</section>
</section>
</section>
<section anchor="relay-discovery-operation" title="Relay Discovery Operation">
<section anchor="priority" title="Optimal Relay Selection">
<section anchor="overview" title="Overview">
<t>The reverse source IP DNS query of an AMTRELAY RR is a good way for a gateway
to discover a relay that is known to the sender.</t>
<t>However, it is NOT necessarily a good way to discover the best relay for that
gateway to use, because the RR will only provide information about relays
known to the source.</t>
<t>If there is an upstream relay in a network that is topologically closer to
the gateway and able to receive and forward multicast traffic from the sender,
that relay is better for the gateway to use, since more of the network path
uses native multicast, allowing more chances for packet replication. But since
that relay is not known to the sender, it won’t be advertised in the sender’s
reverse IP DNS record. An example network that illustrates this scenario is
outlined in <xref target="figrxoffice"/> from <xref target="exoffice"/>.</t>
<t>It’s only appropriate for an AMT gateway to discover an AMT relay by querying
an AMTRELAY RR owned by a sender when all of these conditions are met:</t>
<t><list style="numbers">
<t>The gateway needs to propagate a join of an (S,G) over AMT, because in
the gateway’s network, no RPF next hop toward the source can
propagate a native multicast join of the (S,G); and</t>
<t>The gateway is not already connected to a relay that forwards multicast
traffic from the source of the (S,G); and</t>
<t>The gateway is not configured to use a particular IP address for AMT
discovery, or a relay discovered with that IP is not able to forward
traffic from the source of the (S,G); and</t>
<t>The gateway is not able to find an upstream AMT relay with DNS-SD
<xref target="RFC6763"/>, using “_amt._udp” as the Service section of the querie
s, or a
relay discovered this way is not able to forward traffic from the source of
the (S,G) (as described in <xref target="trafficabsent"/> or <xref target="loade
d"/>); and</t>
<t>The gateway is not able to find an upstream AMT relay with the well-known
anycast addresses from Section 7 of <xref target="RFC7450"/>.</t>
</list></t>
<t>When the above conditions are met, the gateway has no path within its local
network that can receive multicast traffic from the source IP of the (S,G).</t>
<t>In this situation, the best way to find a relay that can forward the
required traffic is to use information that comes from the operator of the
sender. When the sender has configured an AMTRELAY RR, gateways can use the
DRIAD mechanism defined in this document to discover the relay information
provided by the sender.</t>
<t>Note that the DNS-SD service is not source-specific, so even though
when available, several methods of finding a more local source of
multicast traffic connectivity are preferred to using a relay
provided by an AMTRELAY RR, a gateway further upstream would still be
using the AMTRELAY RR unless the upstream network has a peering
that provides an alternative end-to-end multicast transport path for
the (S,G)’s traffic.</t>
</section>
<section anchor="ordering" title="Preference Ordering">
<t>This section defines a preference ordering for relay addresses during
the relay discovery process. Gateways are encouraged to implement a
Happy Eyeballs algorithm to try candidate relays concurrently, but even
gateways that do not implement a Happy Eyeballs algorithm SHOULD use
this ordering, except as noted.</t>
<t>When establishing an AMT tunnel to forward multicast data, it’s
very important for the discovery process to prioritize the network
topology considerations ahead of address selection considerations, in
order to gain the packet replication benefits from using multicast
instead of unicast tunneling in the multicast-capable portions of the
network path.</t>
<t>The intent of the advice and requirements in this section is to describe
how a gateway should make use of the concurrency provided by a Happy
Eyeballs algorithm to reduce the join latency, while still prioritizing
network efficiency considerations over Address Selection considerations.</t>
<t>Section 4 of <xref target="RFC8305"/> requires a Happy Eyeballs algorithm to
sort
the addresses with the Destination Address Selection defined in Section
6 of <xref target="RFC6724"/>, but for the above reasons, that requirement is su
perseded
in the AMT discovery use case by the following considerations:</t>
<t><list style="symbols">
<t>Prefer Local Relays <vspace blankLines='1'/>
<xref target="figrxoffice"/> and <xref target="exoffice"/> provide a motivating
example to prefer
DNS-SD <xref target="RFC6763"/> for discovery strictly ahead of using the AMTRE
LAY RR
controlled by the sender for AMT discovery. <vspace blankLines='1'/>
For this reason, it’s RECOMMENDED that AMT gateways by default perform
service discovery using DNS Service Discovery (DNS-SD) <xref target="RFC6763"/>
for
_amt._udp.&lt;domain&gt; (with &lt;domain&gt; chosen as described in Section 11
of
<xref target="RFC6763"/>) and use the AMT relays discovered that way in prefere
nce to
AMT relays discoverable via the mechanism defined in this document
(DRIAD).</t>
<t>Prefer Relays Managed by the Containing Network <vspace blankLines='1'/>
When no local relay is discoverable with DNS-SD, it still may be the
case that a relay local to the receiver is operated by the network
providing transit services to the receiver. <vspace blankLines='1'/>
In this case, when the network cannot make the relay discoverable via
DNS-SD, the network SHOULD use the well-known anycast addresses from
Section 7 of <xref target="RFC7450"/> to route discovery traffic to the relay m
ost
appropriate to the receiver’s gateway. <vspace blankLines='1'/>
Accordingly, the gateway SHOULD by default discover a relay with the
well-known AMT anycast addresses as the second preference after DNS-SD
when searching for a local relay.</t>
<t>Let Sender Manage Relay Provisioning <vspace blankLines='1'/>
A related motivating example is provided by considering a sender whose
traffic can be forwarded by relays in a sender-controlled network
like <xref target="figtxrelay"/> in <xref target="extxsnd"/>, and also by relay
s in a
provider-controlled network like <xref target="figtxisp"/> in <xref target="ext
xprv"/>, with
different cost and scalability profiles for the different options. <vspace bla
nkLines='1'/>
In this example about the sending-side network, the precedence field
described in <xref target="rrdef-precedence"/> is a critical method of control
so
that senders can provide the appropriate guidance to gateways
during the discovery process, in order to manage load and failover
scenarios in a manner that operates well with the sender’s
provisioning strategy for horizontal scaling of AMT relays. <vspace blankLines
='1'/>
Therefore, after DNS-SD, the precedence from the RR MUST be used for
sorting preference ahead of the Destination Address Selection ordering
from Section 6 of <xref target="RFC6724"/>, so that only relay IPs with the sam
e
precedence are directly compared according to the Destination Address
Selection ordering.</t>
</list></t>
<t>Accordingly, AMT gateways SHOULD by default prefer relays in this order:</t>
<figure><artwork><![CDATA[
1. DNS-SD
2. Anycast addresses from Section 7 of [RFC7450]
3. DRIAD
]]></artwork></figure>
<t>This default behavior MAY be overridden by administrative configuration where
other behavior is more appropriate for the gateway within its network.</t>
<t>Among relay addresses that have an equivalent preference as described above,
a
Happy Eyeballs algorithm for AMT SHOULD use the Destination Address Selection
defined in Section 6 of <xref target="RFC6724"/>.</t>
<t>Among relay addresses that still have an equivalent preference after the
above orderings, a gateway SHOULD make a non-deterministic choice (such as
a pseudorandom selection) for relay preference ordering, in order to
support load balancing by DNS configurations that provide many relay
options.</t>
<t>The gateway MAY introduce a bias in the non-deterministic choice according
to information obtained out of band or from a historical record about
network topology, timing information, or the response to a probing
mechanism, that indicates some expected benefits from selecting some relays
in preference to others. Details about the structure and collection of
this information are out of scope for this document, but a gateway in
possession of such information MAY use it to prefer topologically closer
relays.</t>
<t>Within the above constraints, gateways MAY make use of other considerations
from Section 4 of <xref target="RFC8305"/>, such as the address family interleav
ing
strategies, to produce a final ordering of candidate relay addresses.</t>
<t>Note also that certain relay addresses might be excluded from consideration
by the hold-down timers described in <xref target="trafficabsent"/> or <xref tar
get="loaded"/>. These
relays constitute “unusable destinations” under Rule 1 of the Destination
Address Selection, and are also not part of the superseding considerations
described above.</t>
<t>The discovery and connection process for the relay addresses in the above
described ordering MAY operate in parallel, subject to delays prescribed
by the Happy Eyeballs requirements described in Section 5 of <xref target="RFC83
05"/>
for successively launched concurrent connection attempts.</t>
</section>
<section anchor="connecting-to-multiple-relays" title="Connecting to Multiple Re
lays">
<t>In some deployments, it may be useful for a gateway to connect to
multiple upstream relays and subscribe to the same traffic, in order to
support an active/active failover model. A gateway SHOULD NOT be
configured to do so without guaranteeing that adequate bandwidth is
available.</t>
<t>A gateway configured to do this SHOULD still use the same preference
ordering logic from <xref target="ordering"/> for each connection. (Note that
this ordering allows for overriding by explicit administrative
configuration where required.)</t>
</section>
</section>
<section anchor="happy" title="Happy Eyeballs">
<section anchor="overview-1" title="Overview">
<t>Often, multiple choices of relay will exist for a gateway using DRIAD
for relay discovery. Happy Eyeballs <xref target="RFC8305"/> provides a widely
deployed and generalizable strategy for probing multiple possible
connections in parallel, therefore it is RECOMMENDED that DRIAD-capable
gateways implement a Happy Eyeballs algorithm to support fast discovery
of the most preferred available relay, by probing multiple relays
concurrently.</t>
<t>The parallel discovery logic of a Happy Eyeballs algorithm serves to
reduce join latency for the initial join of an SSM channel. This section
and the preference ordering of relays defined in <xref target="ordering"/> taken
together provide guidance on use of a Happy Eyeballs algorithm for the
case of establishing AMT connections.</t>
<t>Note that according to the definition in <xref target="connection-def"/> of t
his
document, establishing the connection occurs before sending a membership
report. As described in Section 5 of <xref target="RFC8305"/>, only one of the
successful connections will be used, and the others are all canceled
or ignored. In the context of an AMT connection, this means the gateway
will send the membership reports that subscribe to traffic only for the
chosen connection, after the Happy Eyeballs algorithm resolves.</t>
</section>
<section anchor="algorithm-guidelines" title="Algorithm Guidelines">
<t>During the “Initiation of asynchronous DNS queries” phase described in
Section 3 of <xref target="RFC8305"/>), a gateway attempts to resolve the domain
names
listed in <xref target="priority"/>. This consists of resolving the SRV queries
for
DNS-SD domains for the AMT service, as well as the AMTRELAY query for the
reverse IP domain defined in this document.</t>
<t>Each of the SRV and AMTRELAY responses might contain one or more IP
addresses, (as with type 1 or type 2 AMTRELAY responses, or when the
SRV Additional Data section of the SRV response contains the address
records for the target, as urged by <xref target="RFC2782"/>), or they might
contain only domain names (as with type 3 responses from <xref target="rtype"/>,
or
an SRV response without an additional data section).</t>
<t>When present, IP addresses in the initial response provide resolved
destination address candidates for the “Sorting of resolved
destination addresses” phase described in Section 4 of <xref target="RFC8305"/>)
,
whereas domain names without IP addresses in the initial response result
in another set of queries for AAAA and A records, whose responses provide
the candidate resolved destination addresses.</t>
<t>Since the SRV or AMTRELAY responses don’t have a bound on the count of
queries that might be generated aside from the bounds imposed by the
DNS resolver, it’s important for the gateway to provide a rate limit on
the DNS queries. The DNS query functionality is expected to follow
ordinary standards and best practices for DNS clients. A gateway MAY
use an existing DNS client implementation that does so, and MAY rely on
that client’s rate limiting logic to avoid issuing excessive queries.
Otherwise, a gateway MUST provide a rate limit for the DNS queries, and
its default settings SHOULD NOT permit more than 10 queries for any
100-millisecond period (though this MAY be overridable by administrative
configuration).</t>
<t>As the resolved IP addresses arrive, the Happy Eyeballs algorithm
sorts them according to the requirements and recommendations given in
<xref target="ordering"/>, and attempts connections with the corresponding relay
s
under the algorithm restrictions and guidelines given in <xref target="RFC8305"/
> for
the “Establishment of one connection, which cancels all other attempts”
phase. As described in Section 3 of <xref target="RFC8305"/>, DNS resolution is
treated as asynchronous, and connection initiation does not wait
for lagging DNS responses.</t>
</section>
<section anchor="connection-def" title="Connection Definition">
<t>Section 5 of <xref target="RFC8305"/> non-normatively describes success at a
connection attempt as “generally when the TCP handshake completes”.</t>
<t>There is no normative definition of a connection in the AMT specification
<xref target="RFC7450"/>, and there is no TCP connection involved in an AMT tunn
el.</t>
<t>However, the concept of an AMT connection in the context of a Happy
Eyeballs algorithm is a useful one, and so this section provides the
following normative definition:</t>
<t><list style="symbols">
<t>An AMT connection is established successfully when the gateway receives
from a newly discovered relay a valid Membership Query message
(Section 5.1.4 of <xref target="RFC7450"/>) that does not have the L flag set.</
t>
</list></t>
<t>See <xref target="loaded"/> of this document for further information about th
e
relevance of the L flag to the establishment of a Happy Eyeballs
connection. See <xref target="flowhealth"/> for an overview of how to respond
if the connection does not provide multicast connectivity to the
source.</t>
<t>To “cancel” this kind of AMT connection for the Happy Eyeballs algorithm,
a gateway that has not sent a membership report with a subscription
would simply stop sending AMT packets for that connection. A
gateway only sends a membership report to a connection it has chosen as
the most preferred available connection.</t>
</section>
</section>
<section anchor="guidelines-for-restarting-discovery" title="Guidelines for Rest
arting Discovery">
<section anchor="overview-2" title="Overview">
<t>It’s expected that gateways deployed in different environments will use a
variety of heuristics to decide when it’s appropriate to restart the relay
discovery process, in order to meet different performance goals (for example,
to fulfill different kinds of service level agreements).</t>
<t>In general, restarting the discovery process is always safe for
the gateway and relay during any of the events listed in this section,
but may cause a disruption in the forwarded traffic if the discovery
process results in choosing a different relay, because this changes
the RPF forwarding tree for the multicast traffic upstream of the gateway.
This is likely to result in some dropped or duplicated packets from channels
actively being tunneled from the old relay to the gateway.</t>
<t>The degree of impact on the traffic from choosing a different relay may
depend on network conditions between the gateway and the new relay, as well
as the network conditions and topology between the sender and the new relay,
as this may cause the relay to propagate a new RPF join toward the sender.</t>
<t>Balancing the expected impact on the tunneled traffic against likely
or observed problems with an existing connection to the relay is the goal
of the heuristics that gateways use to determine when to restart the
discovery process.</t>
<t>The non-normative advice in this section should be treated as guidelines to
operators and implementors working with AMT systems that can use DRIAD as
part of the relay discovery process.</t>
</section>
<section anchor="updates-to-restarting-events" title="Updates to Restarting Even
ts">
<t>Section 5.2.3.4.1 of <xref target="RFC7450"/> lists several events that may c
ause a
gateway to start or restart the discovery procedure.</t>
<t>This document provides some updates and recommendations regarding the
handling of these and similar events. The first 5 events are copied
here and numbered for easier reference, and the remaining 4 events are
newly added for consideration in this document:</t>
<t><list style="numbers"> Subscribers
<t>When a gateway pseudo-interface is started (enabled).</t> </artwork>
<t>When the gateway wishes to report a group subscription when none </figure>
currently exist.</t> </section>
<t>Before sending the next Request message in a membership update <section anchor="exoffice" numbered="true" toc="exclude" removeInRFC="
cycle.</t> false" pn="section-2.3.1.2">
<t>After the gateway fails to receive a response to a Request <name slugifiedName="name-small-office">Small Office</name>
message.</t> <t pn="section-2.3.1.2-1">Another example receiving network is a sma
<t>After the gateway receives a Membership Query message with the ll branch office that regularly
L flag set to 1.</t> accesses some multicast content, illustrated in <xref target="figrxofficenm" fo
<t>When the gateway wishes to report an (S,G) subscription with a source rmat="default" sectionFormat="of" derivedContent="Figure 4"/>.</t>
address that does not currently have other group subscriptions.</t> <t pn="section-2.3.1.2-2">This office has desktop devices that need
<t>When there is a network change detected, for example when a gateway is to receive some multicast traffic,
operating inside an end user device or application, and the device so an AMT gateway runs on a LAN with these devices to pull traffic in
joins a different network, or when the domain portion of a DNS-SD through a non-multicast next hop.</t>
<t pn="section-2.3.1.2-3">The office also hosts some mobile devices
that have AMT gateway instances
embedded inside apps in order to receive multicast traffic over their
non-multicast wireless LAN. (Note that the "Legacy Router" is a
simplification that's meant to describe a variety of possible conditions;
for example, it could be a device providing a split-tunnel VPN as described
in <xref target="RFC7359" format="default" sectionFormat="of" derivedContent="R
FC7359"/>, deliberately excluding multicast traffic for a VPN
tunnel, rather than a device that is incapable of multicast forwarding.)</t>
<figure anchor="figrxofficenm" align="left" suppress-title="false" p
n="figure-4">
<name slugifiedName="name-small-office-no-multicast-u">Small Offic
e (No Multicast Up)</name>
<artwork name="" type="" align="left" alt="" pn="section-2.3.1.2-4
.1">
Internet
(non-multicast)
^
| Office Network
+----------|----------------------------------+
| | |
| +---------------+ (Wifi) Mobile apps |
| | Modem+ | Wifi | - - - - w/ embedded |
| | Router | AP | AMT gateways |
| +---------------+ |
| | |
| | |
| +----------------+ |
| | Legacy Router | |
| | (unicast) | |
| +----------------+ |
| / | \ |
| / | \ |
| +--------+ +--------+ +--------+=========+ |
| | Phones | | ConfRm | | Desks | AMT | |
| | subnet | | subnet | | subnet | gateway | |
| +--------+ +--------+ +--------+=========+ |
| |
+---------------------------------------------+
</artwork>
</figure>
<t pn="section-2.3.1.2-5">By adding an AMT relay to this office netw
ork as in <xref target="figrxoffice" format="default" sectionFormat="of" derived
Content="Figure 5"/>, it's
possible to make use of multicast services from the example multicast-capable
ISP in <xref target="exrxisp" format="default" sectionFormat="of" derivedConten
t="Section 2.3.1.1"/>.</t>
<figure anchor="figrxoffice" align="left" suppress-title="false" pn=
"figure-5">
<name slugifiedName="name-small-office-example">Small Office Examp
le</name>
<artwork name="" type="" align="left" alt="" pn="section-2.3.1.2-6
.1">
Multicast-capable ISP
^
| Office Network
+----------|----------------------------------+
| | |
| +---------------+ (Wifi) Mobile apps |
| | Modem+ | Wifi | - - - - w/ embedded |
| | Router | AP | AMT gateways |
| +---------------+ |
| | +=======+ |
| +---Wired LAN---| AMT | |
| | | relay | |
| +----------------+ +=======+ |
| | Legacy Router | |
| | (unicast) | |
| +----------------+ |
| / | \ |
| / | \ |
| +--------+ +--------+ +--------+=========+ |
| | Phones | | ConfRm | | Desks | AMT | |
| | subnet | | subnet | | subnet | gateway | |
| +--------+ +--------+ +--------+=========+ |
| |
+---------------------------------------------+
</artwork>
</figure>
<t pn="section-2.3.1.2-7">When multicast-capable networks are chaine
d like this, with a network like
the one in <xref target="figrxoffice" format="default" sectionFormat="of" deriv
edContent="Figure 5"/> receiving Internet services from a
multicast-capable network like the one in <xref target="figrxisp" format="defau
lt" sectionFormat="of" derivedContent="Figure 3"/>, it's important for
AMT gateways to reach the more local AMT relay in order to avoid
accidentally tunneling multicast traffic from a more distant AMT relay with
unicast and failing to utilize the multicast transport capabilities of the
network in <xref target="figrxisp" format="default" sectionFormat="of" derivedC
ontent="Figure 3"/>.</t>
</section>
</section>
<section anchor="extx" numbered="true" toc="include" removeInRFC="false"
pn="section-2.3.2">
<name slugifiedName="name-example-sending-networks">Example Sending Ne
tworks</name>
<section anchor="extxsnd" numbered="true" toc="exclude" removeInRFC="f
alse" pn="section-2.3.2.1">
<name slugifiedName="name-sender-controlled-relays">Sender-Controlle
d Relays</name>
<t pn="section-2.3.2.1-1">When a sender network is also operating AM
T relays to distribute multicast
traffic, as in <xref target="figtxrelay" format="default" sectionFormat="of" de
rivedContent="Figure 6"/>, each address could appear as an AMTRELAY RR
for the reverse IP of the sender. Alternately, one or more domain names could a
ppear
in AMTRELAY RRs, and the AMT relay addresses can be discovered by finding
A or AAAA records from those domain names.</t>
<figure anchor="figtxrelay" align="left" suppress-title="false" pn="
figure-6">
<name slugifiedName="name-small-office-example-2">Small Office Exa
mple</name>
<artwork name="" type="" align="left" alt="" pn="section-2.3.2.1-2
.1">
Sender Network
+-----------------------------------+
| |
| +--------+ +=======+ +=======+ |
| | Sender | | AMT | | AMT | |
| +--------+ | relay | | relay | |
| | +=======+ +=======+ |
| | | | |
| +-----+------+----------+ |
| | |
+-----------|-----------------------+
v
Internet
(non-multicast)
</artwork>
</figure>
</section>
<section anchor="extxprv" numbered="true" toc="exclude" removeInRFC="f
alse" pn="section-2.3.2.2">
<name slugifiedName="name-provider-controlled-relays">Provider-Contr
olled Relays</name>
<t pn="section-2.3.2.2-1">When an ISP offers a service to transmit o
utbound multicast traffic through
a forwarding network, it might also offer AMT relays in order to reach
receivers without multicast connectivity to the forwarding network, as in
<xref target="figtxisp" format="default" sectionFormat="of" derivedContent="Fig
ure 7"/>. In this case, it's recommended that the ISP also provide at
least one domain name for the AMT relays for use with the AMTRELAY RR.</t>
<t pn="section-2.3.2.2-2">When the sender wishes to use the relays p
rovided by the ISP for
forwarding multicast traffic, an AMTRELAY RR should be configured to use
the domain name provided by the ISP to allow for address reassignment of the
relays without forcing the sender to reconfigure the corresponding AMTRELAY
RRs.</t>
<figure anchor="figtxisp" align="left" suppress-title="false" pn="fi
gure-7">
<name slugifiedName="name-sending-isp-example">Sending ISP Example
</name>
<artwork name="" type="" align="left" alt="" pn="section-2.3.2.2-3
.1">
+--------+
| Sender |
+---+----+ Multicast-enabled
| Sending Network
+-----------|-------------------------------+
| v |
| +------------+ +=======+ +=======+ |
| | Agg Router | | AMT | | AMT | |
| +------------+ | relay | | relay | |
| | +=======+ +=======+ |
| | | | |
| +-----+------+--------+---------+ |
| | | |
| +--------+ +--------+ |
| | Border |---| Border | |
| | Router | | Router | |
| +--------+ +--------+ |
+-----|------------|------------------------+
| |
v v
Internet
(non-multicast)
</artwork>
</figure>
</section>
</section>
</section>
</section>
<section anchor="relay-discovery-operation" numbered="true" toc="include" re
moveInRFC="false" pn="section-3">
<name slugifiedName="name-relay-discovery-operation">Relay Discovery Opera
tion</name>
<section anchor="priority" numbered="true" toc="include" removeInRFC="fals
e" pn="section-3.1">
<name slugifiedName="name-optimal-relay-selection">Optimal Relay Selecti
on</name>
<section anchor="overview" numbered="true" toc="include" removeInRFC="fa
lse" pn="section-3.1.1">
<name slugifiedName="name-overview">Overview</name>
<t pn="section-3.1.1-1">The reverse source IP DNS query of an AMTRELAY
RR is a good way for a gateway
to discover a relay that is known to the sender.</t>
<t pn="section-3.1.1-2">However, it is *not* necessarily a good way to
discover the best relay for that
gateway to use, because the RR will only provide information about relays
known to the source.</t>
<t pn="section-3.1.1-3">If there is an upstream relay in a network tha
t is topologically closer to
the gateway and is able to receive and forward multicast traffic from the sende
r,
that relay is better for the gateway to use since more of the network path
uses native multicast, allowing more chances for packet replication. But since
that relay is not known to the sender, it won't be advertised in the sender's
reverse IP DNS record. An example network that illustrates this scenario is
outlined in <xref target="figrxoffice" format="default" sectionFormat="of" deri
vedContent="Figure 5"/> from <xref target="exoffice" format="default" sectionFor
mat="of" derivedContent="Section 2.3.1.2"/>.</t>
<t pn="section-3.1.1-4">It's only appropriate for an AMT gateway to di
scover an AMT relay by querying
an AMTRELAY RR owned by a sender when all of these conditions are met:</t>
<ol spacing="normal" type="1" start="1" pn="section-3.1.1-5">
<li pn="section-3.1.1-5.1" derivedCounter="1.">The gateway needs to
propagate a join of an (S,G) over AMT because in
the gateway's network, no RPF next hop toward the source can
propagate a native multicast join of the (S,G);</li>
<li pn="section-3.1.1-5.2" derivedCounter="2.">The gateway is not al
ready connected to a relay that forwards multicast
traffic from the source of the (S,G);</li>
<li pn="section-3.1.1-5.3" derivedCounter="3.">The gateway is not co
nfigured to use a particular IP address for AMT
discovery, or a relay discovered with that IP is not able to forward
traffic from the source of the (S,G);</li>
<li pn="section-3.1.1-5.4" derivedCounter="4.">The gateway is not ab
le to find an upstream AMT relay with
DNS-based Service Discovery (DNS-SD)
<xref target="RFC6763" format="default" sectionFormat="of" derivedContent="RFC6
763"/> using "_amt._udp" as the Service section of the queries, or a
relay discovered this way is not able to forward traffic from the source of
the (S,G) (as described in <xref target="trafficabsent" format="default" sectio
nFormat="of" derivedContent="Section 3.3.4.1"/> and <xref target="loaded" format
="counter" sectionFormat="of" derivedContent="3.3.5"/>); and</li>
<li pn="section-3.1.1-5.5" derivedCounter="5.">The gateway is not ab
le to find an upstream AMT relay with the well-known
anycast addresses from <xref target="RFC7450" sectionFormat="of" section="7" fo
rmat="default" derivedLink="https://rfc-editor.org/rfc/rfc7450#section-7" derive
dContent="RFC7450"/>.</li>
</ol>
<t pn="section-3.1.1-6">When all of the above conditions are met, the
gateway has no path within its local
network that can receive multicast traffic from the source IP of the (S,G).</t>
<t pn="section-3.1.1-7">In this situation, the best way to find a rela
y that can forward the
required traffic is to use information that comes from the operator of the
sender. When the sender has configured an AMTRELAY RR, gateways can use the
DRIAD mechanism defined in this document to discover the relay information
provided by the sender.</t>
<t pn="section-3.1.1-8">Note that the above conditions are designed to
prefer the use of
a local AMT relay if one can be discovered. However, note also
that the network upstream of the locally discovered relay would
still need to receive traffic from the sender of the (S,G) in order
to forward it. Therefore, unless the upstream network contains the
sender or has a multicast-capable peering with a network that can
forward traffic from the sender, the upstream network might still
use AMT to ingest the traffic from a network that can receive
traffic from the sender. If this is the case, the upstream AMT
gateway could still rely on the AMTRELAY RR provided by the sender,
even though the AMTRELAY RR is not directly used by gateways
topologically closer to the receivers. For a concrete example of
such a situation, consider the network in <xref target="figrxoffice" f
ormat="default" sectionFormat="of" derivedContent="Figure 5"/> connected as one
of the customers to the network in <xref target="figrxisp" format="def
ault" sectionFormat="of" derivedContent="Figure 3"/>.</t>
</section>
<section anchor="ordering" numbered="true" toc="include" removeInRFC="fa
lse" pn="section-3.1.2">
<name slugifiedName="name-preference-ordering">Preference Ordering</na
me>
<t pn="section-3.1.2-1">This section defines a preference ordering for
relay addresses during
the relay discovery process. Gateways are encouraged to implement a
Happy Eyeballs <xref target="RFC8305" format="default" sectionFormat="of" deriv
edContent="RFC8305"/> algorithm to try candidate relays
concurrently (see <xref target="happy" format="default" sectionFormat="of" deri
vedContent="Section 3.2"/>), but even
gateways that do not implement a Happy Eyeballs algorithm <bcp14>SHOULD</bcp14>
use
this ordering, except as noted.</t>
<t pn="section-3.1.2-2">When establishing an AMT tunnel to forward mul
ticast data, it's
very important for the discovery process to prioritize network
topology considerations ahead of address selection considerations in
order to gain the packet replication benefits from using multicast
instead of unicast tunneling in the multicast-capable portions of the
network path.</t>
<t pn="section-3.1.2-3">The intent of the advice and requirements in t
his section is to describe
how a gateway should make use of the concurrency provided by a Happy
Eyeballs algorithm to reduce the join latency while still prioritizing
network efficiency considerations over address selection considerations.</t>
<t pn="section-3.1.2-4"><xref target="RFC8305" sectionFormat="of" sect
ion="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8305#section
-4" derivedContent="RFC8305"/> requires a Happy Eyeballs algorithm to sort
the addresses with the Destination Address Selection defined in <xref target="R
FC6724" sectionFormat="of" section="6" format="default" derivedLink="https://rfc
-editor.org/rfc/rfc6724#section-6" derivedContent="RFC6724"/>, but for the above
reasons, that requirement is superseded
in the AMT discovery use case by the following considerations:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-3.1.2-5">
<li pn="section-3.1.2-5.1">
<t pn="section-3.1.2-5.1.1">Prefer Local Relays </t>
<t pn="section-3.1.2-5.1.2"><xref target="figrxoffice" format="def
ault" sectionFormat="of" derivedContent="Figure 5"/> and <xref target="exoffice"
format="default" sectionFormat="of" derivedContent="Section 2.3.1.2"/> provide
a motivating example to prefer
DNS-SD <xref target="RFC6763" format="default" sectionFormat="of" derivedConte
nt="RFC6763"/> for discovery strictly ahead of using the AMTRELAY RR
controlled by the sender for AMT discovery.</t>
<t pn="section-3.1.2-5.1.3">
For this reason, it's <bcp14>RECOMMENDED</bcp14> that AMT gateways by default p
erform
service discovery using DNS Service Discovery (DNS-SD) <xref target="RFC6763"
format="default" sectionFormat="of" derivedContent="RFC6763"/> for
_amt._udp.&lt;domain&gt; (with &lt;domain&gt; chosen as described in <xref tar
get="RFC6763" sectionFormat="of" section="11" format="default" derivedLink="http
s://rfc-editor.org/rfc/rfc6763#section-11" derivedContent="RFC6763"/>) and use t
he AMT relays discovered that way in preference to
AMT relays discoverable via the mechanism defined in this document
(DRIAD).</t>
</li>
<li pn="section-3.1.2-5.2">
<t pn="section-3.1.2-5.2.1">Prefer Relays Managed by the Containin
g Network </t>
<t pn="section-3.1.2-5.2.2">
When no local relay is discoverable with DNS-SD, it still may be the
case that a relay local to the receiver is operated by the network
providing transit services to the receiver. </t>
<t pn="section-3.1.2-5.2.3">
In this case, when the network cannot make the relay discoverable via
DNS-SD, the network <bcp14>SHOULD</bcp14> use the well-known anycast addresses
from <xref target="RFC7450" format="default" section="7" sectionFormat="of" der
ivedLink="https://rfc-editor.org/rfc/rfc7450#section-7" derivedContent="RFC7450"
/> to route discovery traffic to the relay most
appropriate to the receiver's gateway.</t>
<t pn="section-3.1.2-5.2.4">
Accordingly, the gateway <bcp14>SHOULD</bcp14> by default discover a relay with
the
well-known AMT anycast addresses as the next-best option after DNS-SD
when searching for a local relay.</t>
</li>
<li pn="section-3.1.2-5.3">
<t pn="section-3.1.2-5.3.1">Let Sender Manage Relay Provisioning
</t>
<t pn="section-3.1.2-5.3.2">
A related motivating example is provided by considering a sender whose
traffic can be forwarded by relays in a sender-controlled network
like <xref target="figtxrelay" format="default" sectionFormat="of" derivedCont
ent="Figure 6"/> in <xref target="extxsnd" format="default" sectionFormat="of" d
erivedContent="Section 2.3.2.1"/> and by relays in a
provider-controlled network like <xref target="figtxisp" format="default" sect
ionFormat="of" derivedContent="Figure 7"/> in <xref target="extxprv" format="def
ault" sectionFormat="of" derivedContent="Section 2.3.2.2"/>, with
different cost and scalability profiles for the different options. </t>
<t pn="section-3.1.2-5.3.3">
In this example about the sending-side network, the precedence field
described in <xref target="rrdef-precedence" format="default" sectionFormat="o
f" derivedContent="Section 4.2.1"/> is a critical method of control so
that senders can provide the appropriate guidance to gateways
during the discovery process in order to manage load and failover
scenarios in a manner that operates well with the sender's
provisioning strategy for horizontal scaling of AMT relays. </t>
<t pn="section-3.1.2-5.3.4">
Therefore, after DNS-SD, the precedence from the RR <bcp14>MUST</bcp14> be used
for
sorting preference ahead of the Destination Address Selection ordering
from <xref target="RFC6724" section="6" sectionFormat="of" format="default" de
rivedLink="https://rfc-editor.org/rfc/rfc6724#section-6" derivedContent="RFC6724
"/> so that only relay IPs with the same
precedence are directly compared according to the Destination Address
Selection ordering.</t>
</li>
</ul>
<t pn="section-3.1.2-6">Accordingly, AMT gateways <bcp14>SHOULD</bcp14
> by default prefer relays in this
order:</t>
<ol spacing="normal" start="1" type="1" pn="section-3.1.2-7">
<li pn="section-3.1.2-7.1" derivedCounter="1.">DNS-SD</li>
<li pn="section-3.1.2-7.2" derivedCounter="2.">Anycast addresses fro
m <xref target="RFC7450" sectionFormat="of" section="7" format="default" derived
Link="https://rfc-editor.org/rfc/rfc7450#section-7" derivedContent="RFC7450"/></
li>
<li pn="section-3.1.2-7.3" derivedCounter="3.">DRIAD</li>
</ol>
<t pn="section-3.1.2-8">This default behavior <bcp14>MAY</bcp14> be ov
erridden by administrative configuration where
other behavior is more appropriate for the gateway within its network.</t>
<t pn="section-3.1.2-9">Among relay addresses that have an equivalent
preference as described above, a
Happy Eyeballs algorithm for AMT <bcp14>SHOULD</bcp14> use the Destination Addr
ess Selection
defined in <xref target="RFC6724" sectionFormat="of" section="6" format="defaul
t" derivedLink="https://rfc-editor.org/rfc/rfc6724#section-6" derivedContent="RF
C6724"/>.</t>
<t pn="section-3.1.2-10">Among relay addresses that still have an equi
valent preference after the
above orderings, a gateway <bcp14>SHOULD</bcp14> make a non-deterministic choic
e (such as
a pseudorandom selection) for relay preference ordering in order to
support load balancing by DNS configurations that provide many relay
options.</t>
<t pn="section-3.1.2-11">The gateway <bcp14>MAY</bcp14> introduce a bi
as in the non-deterministic choice according
to information that indicates expected benefits from selecting some relays in
preference to others. Details about the structure and collection of this
information are out of scope for this document but could, for example, be
obtained by out-of-band methods or from a historical record about
network topology, timing information, or the response to a probing
mechanism. A gateway in possession of such information <bcp14>MAY</bcp14> use i
t to prefer topologically closer relays.</t>
<t pn="section-3.1.2-12">Within the above constraints, gateways <bcp14
>MAY</bcp14> make use of other considerations
from <xref target="RFC8305" sectionFormat="of" section="4" format="default" der
ivedLink="https://rfc-editor.org/rfc/rfc8305#section-4" derivedContent="RFC8305"
/>, such as the address family interleaving
strategies, to produce a final ordering of candidate relay addresses.</t>
<t pn="section-3.1.2-13">Note also that certain relay addresses might
be excluded from consideration
by the hold-down timers described in <xref target="trafficabsent" format="defau
lt" sectionFormat="of" derivedContent="Section 3.3.4.1"/> or <xref target="loade
d" format="counter" sectionFormat="of" derivedContent="3.3.5"/>. These
relays constitute "unusable destinations" under Rule 1 of the Destination
Address Selection and are also not part of the superseding considerations
described above.</t>
<t pn="section-3.1.2-14">The discovery and connection process for the
relay addresses in the above
described ordering <bcp14>MAY</bcp14> operate in parallel, subject to delays pr
escribed
by the Happy Eyeballs requirements described in <xref target="RFC8305" sectionF
ormat="of" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/
rfc8305#section-5" derivedContent="RFC8305"/>
for successively launched concurrent connection attempts.</t>
</section>
<section anchor="connecting-to-multiple-relays" numbered="true" toc="inc
lude" removeInRFC="false" pn="section-3.1.3">
<name slugifiedName="name-connecting-to-multiple-rela">Connecting to M
ultiple Relays</name>
<t pn="section-3.1.3-1">In some deployments, it may be useful for a ga
teway to connect to
multiple upstream relays and subscribe to the same traffic in order to
support an active/active failover model. A gateway <bcp14>SHOULD NOT</bcp14> b
e
configured to do so without guaranteeing that adequate bandwidth is
available.</t>
<t pn="section-3.1.3-2">A gateway configured to do this <bcp14>SHOULD<
/bcp14> still use the same preference-ordering logic from <xref target="ordering
" format="default" sectionFormat="of" derivedContent="Section 3.1.2"/> for each
connection. (Note that
this ordering allows for overriding by explicit administrative
configuration where required.)</t>
</section>
</section>
<section anchor="happy" numbered="true" toc="include" removeInRFC="false"
pn="section-3.2">
<name slugifiedName="name-happy-eyeballs">Happy Eyeballs</name>
<section anchor="overview-1" numbered="true" toc="include" removeInRFC="
false" pn="section-3.2.1">
<name slugifiedName="name-overview-2">Overview</name>
<t pn="section-3.2.1-1">Often, multiple choices of relay will exist fo
r a gateway using DRIAD
for relay discovery. Happy Eyeballs <xref target="RFC8305" format="default" se
ctionFormat="of" derivedContent="RFC8305"/> provides a widely
deployed and generalizable strategy for probing multiple possible
connections in parallel. Therefore, it is <bcp14>RECOMMENDED</bcp14> that DRIAD
-capable
gateways implement a Happy Eyeballs algorithm to support fast discovery
of the most preferred available relay by probing multiple relays
concurrently.</t>
<t pn="section-3.2.1-2">The parallel discovery logic of a Happy Eyebal
ls algorithm serves to
reduce join latency for the initial join of an SSM channel. This section
and the preference ordering of relays defined in <xref target="ordering" format
="default" sectionFormat="of" derivedContent="Section 3.1.2"/> together provide
guidance on use of a Happy Eyeballs algorithm for the
case of establishing AMT connections.</t>
<t pn="section-3.2.1-3">Note that according to the definition in <xref
target="connection-def" format="default" sectionFormat="of" derivedContent="Sec
tion 3.2.3"/> of this
document, establishing the connection occurs before sending a membership
report. As described in <xref target="RFC8305" sectionFormat="of" section="5"
format="default" derivedLink="https://rfc-editor.org/rfc/rfc8305#section-5" deri
vedContent="RFC8305"/>, only one of the
successful connections will be used, and the others are all canceled
or ignored. In the context of an AMT connection, this means the gateway
will send the membership reports that subscribe to traffic only for the
chosen connection after the Happy Eyeballs algorithm resolves.</t>
</section>
<section anchor="algorithm-guidelines" numbered="true" toc="include" rem
oveInRFC="false" pn="section-3.2.2">
<name slugifiedName="name-algorithm-guidelines">Algorithm Guidelines</
name>
<t pn="section-3.2.2-1">During the "Initiation of asynchronous DNS que
ries" phase
described in <xref target="RFC8305" sectionFormat="of" section="3" for
mat="default" derivedLink="https://rfc-editor.org/rfc/rfc8305#section-3" derived
Content="RFC8305"/>, a gateway attempts to resolve the domain names
listed in <xref target="priority" format="default" sectionFormat="of" derivedCo
ntent="Section 3.1"/>. This consists of resolving the SRV queries for
DNS-SD domains for the AMT service, as well as the AMTRELAY query for the
reverse IP domain defined in this document.</t>
<t pn="section-3.2.2-2">Each of the SRV and AMTRELAY responses might c
ontain:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-3.2.2-3">
<li pn="section-3.2.2-3.1">one
or more IP addresses (as with type 1 or type 2 AMTRELAY
responses or when the SRV Additional Data section of the
SRV response contains the address records for the target,
as urged by <xref target="RFC2782" format="default" sectionFormat="of"
derivedContent="RFC2782"/>),
or</li>
<li pn="section-3.2.2-3.2">
only domain names (as with type 3
responses from <xref target="rtype" format="default" sectionFormat="of
" derivedContent="Section 4.2.3"/> or
an SRV response without an additional data section).</li>
</ul>
<t pn="section-3.2.2-4">When present, IP addresses in the initial resp
onse provide resolved
destination address candidates for the "Sorting of resolved
destination addresses" phase described in <xref target="RFC8305" sectionFormat=
"of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc830
5#section-4" derivedContent="RFC8305"/>),
whereas domain names without IP addresses in the initial response result
in another set of queries for AAAA and A records, whose responses provide
the candidate resolved destination addresses.</t>
<t pn="section-3.2.2-5">Since the SRV or AMTRELAY responses don't have
a bound on the count of
queries that might be generated aside from the bounds imposed by the
DNS resolver, it's important for the gateway to provide a rate limit on
the DNS queries. The DNS query functionality is expected to follow
ordinary standards and best practices for DNS clients. A gateway <bcp14>MAY</b
cp14>
use an existing DNS client implementation that does so and <bcp14>MAY</bcp14> r
ely on
that client's rate-limiting logic to avoid issuing excessive queries.
Otherwise, a gateway <bcp14>MUST</bcp14> provide a rate limit for the DNS queri
es, and
its default settings <bcp14>SHOULD NOT</bcp14> permit more than 10 queries for
any
100-millisecond period (though this <bcp14>MAY</bcp14> be overridable by the ad
ministrative
configuration).</t>
<t pn="section-3.2.2-6">As the resolved IP addresses arrive, the Happy
Eyeballs algorithm
sorts them according to the requirements and recommendations given in
<xref target="ordering" format="default" sectionFormat="of" derivedContent="Sec
tion 3.1.2"/> and attempts connections with the corresponding relays
under the algorithm restrictions and guidelines given in <xref target="RFC8305"
format="default" sectionFormat="of" derivedContent="RFC8305"/> for
the "Establishment of one connection, which cancels all other attempts"
phase. As described in <xref target="RFC8305" sectionFormat="of" section="3" f
ormat="default" derivedLink="https://rfc-editor.org/rfc/rfc8305#section-3" deriv
edContent="RFC8305"/>, DNS resolution is
treated as asynchronous, and connection initiation does not wait
for lagging DNS responses.</t>
</section>
<section anchor="connection-def" numbered="true" toc="include" removeInR
FC="false" pn="section-3.2.3">
<name slugifiedName="name-connection-definition">Connection Definition
</name>
<t pn="section-3.2.3-1"><xref target="RFC8305" sectionFormat="of" sect
ion="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8305#section
-5" derivedContent="RFC8305"/>
non-normatively describes a successful connection attempt as "generall
y when the TCP handshake completes".</t>
<t pn="section-3.2.3-2">There is no normative definition of a connecti
on in the AMT specification
<xref target="RFC7450" format="default" sectionFormat="of" derivedContent="RFC7
450"/>, and there is no TCP connection involved in an AMT tunnel.</t>
<t pn="section-3.2.3-3">However, the concept of an AMT connection in t
he context of a Happy
Eyeballs algorithm is a useful one, and so this section provides the
following normative definition:</t>
<ul spacing="normal" bare="false" empty="false" pn="section-3.2.3-4">
<li pn="section-3.2.3-4.1">An AMT connection is established successf
ully when the gateway receives
from a newly discovered relay a valid Membership Query message
(<xref target="RFC7450" sectionFormat="of" section="5.1.4" format="default" der
ivedLink="https://rfc-editor.org/rfc/rfc7450#section-5.1.4" derivedContent="RFC7
450"/>) that does not have the L flag set.</li>
</ul>
<t pn="section-3.2.3-5">See <xref target="loaded" format="default" sec
tionFormat="of" derivedContent="Section 3.3.5"/> of this document for further in
formation about the
relevance of the L flag to the establishment of a Happy Eyeballs
connection. See <xref target="flowhealth" format="default" sectionFormat="of"
derivedContent="Section 3.3.4"/> for an overview of how to respond
if the connection does not provide multicast connectivity to the
source.</t>
<t pn="section-3.2.3-6">To "cancel" this kind of AMT connection for th
e Happy Eyeballs algorithm,
a gateway that has not sent a membership report with a subscription
would simply stop sending AMT packets for that connection. A
gateway only sends a membership report to a connection it has chosen as
the most preferred available connection.</t>
</section>
</section>
<section anchor="guidelines-for-restarting-discovery" numbered="true" toc=
"include" removeInRFC="false" pn="section-3.3">
<name slugifiedName="name-guidelines-for-restarting-d">Guidelines for Re
starting Discovery</name>
<section anchor="overview-2" numbered="true" toc="include" removeInRFC="
false" pn="section-3.3.1">
<name slugifiedName="name-overview-3">Overview</name>
<t pn="section-3.3.1-1">It's expected that gateways deployed in differ
ent environments will use a
variety of heuristics to decide when it's appropriate to restart the relay
discovery process in order to meet different performance goals (for example,
to fulfill different kinds of service level agreements).</t>
<t pn="section-3.3.1-2">In general, restarting the discovery process i
s always safe for
the gateway and relay during any of the events listed in this section
but may cause a disruption in the forwarded traffic if the discovery
process results in choosing a different relay because this changes
the RPF forwarding tree for the multicast traffic upstream of the gateway.
This is likely to result in some dropped or duplicated packets from channels
actively being tunneled from the old relay to the gateway.</t>
<t pn="section-3.3.1-3">The degree of impact on the traffic from choos
ing a different relay may
depend on network conditions between the gateway and the new relay, as well
as the network conditions and topology between the sender and the new relay,
as this may cause the relay to propagate a new RPF join toward the sender.</t>
<t pn="section-3.3.1-4">Balancing the expected impact on the tunneled
traffic against likely
or observed problems with an existing connection to the relay is the goal
of the heuristics that gateways use to determine when to restart the
discovery process.</t>
<t pn="section-3.3.1-5">The non-normative advice in this section shoul
d be treated as guidelines to
operators and implementors working with AMT systems that can use DRIAD as
part of the relay discovery process.</t>
</section>
<section anchor="updates-to-restarting-events" numbered="true" toc="incl
ude" removeInRFC="false" pn="section-3.3.2">
<name slugifiedName="name-updates-to-restarting-event">Updates to Rest
arting Events</name>
<t pn="section-3.3.2-1"><xref target="RFC7450" sectionFormat="of" sect
ion="5.2.3.4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7450
#section-5.2.3.4.1" derivedContent="RFC7450"/> lists several events that may cau
se a
gateway to start or restart the discovery procedure.</t>
<t pn="section-3.3.2-2">This document provides some updates and recomm
endations regarding the
handling of these and similar events. The first five events are copied
here and numbered for easier reference, and the remaining four events are
newly added for consideration in this document:</t>
<ol spacing="normal" type="1" start="1" pn="section-3.3.2-3">
<li pn="section-3.3.2-3.1" derivedCounter="1.">When a gateway pseudo
-interface is started (enabled).</li>
<li pn="section-3.3.2-3.2" derivedCounter="2.">When the gateway wish
es to report a group subscription when none
currently exists.</li>
<li pn="section-3.3.2-3.3" derivedCounter="3.">Before sending the ne
xt Request message in a membership update
cycle.</li>
<li pn="section-3.3.2-3.4" derivedCounter="4.">After the gateway fai
ls to receive a response to a Request
message.</li>
<li pn="section-3.3.2-3.5" derivedCounter="5.">After the gateway rec
eives a Membership Query message with the
L flag set to 1.</li>
<li pn="section-3.3.2-3.6" derivedCounter="6.">When the gateway wish
es to report an (S,G) subscription with a source
address that does not currently have other group subscriptions.</li>
<li pn="section-3.3.2-3.7" derivedCounter="7.">When there is a netwo
rk change detected; for example, when a gateway is
operating inside an end user device or application and the device
joins a different network or when the domain portion of a DNS-SD
domain name changes in response to a DHCP message or administrative domain name changes in response to a DHCP message or administrative
configuration.</t> configuration.</li>
<t>When substantial loss, persistent congestion, or network overload is <li pn="section-3.3.2-3.8" derivedCounter="8.">When substantial loss
detected in the stream of AMT packets from a relay.</t> , persistent congestion, or network overload is
<t>When the gateway has reported one or more (S,G) subscriptions, but detected in the stream of AMT packets from a relay.</li>
no traffic is received from the source for some timeout. (See <li pn="section-3.3.2-3.9" derivedCounter="9.">When the gateway has
<xref target="trafficabsent"/>).</t> reported one or more (S,G) subscriptions but
</list></t> no traffic is received from the source for some timeout (see
<xref target="trafficabsent" format="default" sectionFormat="of" derivedContent=
<t>This list is not exhaustive, nor are any of the listed events strictly "Section 3.3.4.1"/>).</li>
</ol>
<t pn="section-3.3.2-4">This list is not exhaustive, nor are any of th
e listed events strictly
required to always force a restart of the discovery process.</t> required to always force a restart of the discovery process.</t>
<t pn="section-3.3.2-5">Note that during event #1, a gateway may use D
<t>Note that during event #1, a gateway may use DNS-SD, but does not NS-SD but does not
have sufficient information to use DRIAD, since no source is known.</t> have sufficient information to use DRIAD, since no source is known.</t>
</section>
</section> <section anchor="stability" numbered="true" toc="include" removeInRFC="f
<section anchor="stability" title="Tunnel Stability"> alse" pn="section-3.3.3">
<name slugifiedName="name-tunnel-stability">Tunnel Stability</name>
<t>In general, subscribers to active traffic flows that are being forwarded <t pn="section-3.3.3-1">In general, subscribers to active traffic flow
s that are being forwarded
by an AMT gateway are less likely to experience a degradation in service by an AMT gateway are less likely to experience a degradation in service
(for example, from missing or duplicated packets) when the gateway continues (for example, from missing or duplicated packets) when the gateway continues
using the same relay, as long as the relay is not overloaded and the network using the same relay as long as the relay is not overloaded and the network
conditions remain stable.</t> conditions remain stable.</t>
<t pn="section-3.3.3-2">Therefore, gateways <bcp14>SHOULD</bcp14> avoi
<t>Therefore, gateways SHOULD avoid performing a full restart of the discovery d performing a full restart of the discovery
process during routine cases of event #3 (sending a new Request message), process during routine cases of event #3 (sending a new Request message),
since it occurs frequently in normal operation.</t> since it occurs frequently in normal operation.</t>
<t pn="section-3.3.3-3">However, see Sections <xref target="flowhealth
<t>However, see <xref target="flowhealth"/>, <xref target="discoverymessage"/>, " format="counter" sectionFormat="of" derivedContent="3.3.4"/>, <xref target="di
and <xref target="ancient"/> for more scoverymessage" format="counter" sectionFormat="of" derivedContent="3.3.6"/>, an
d <xref target="ancient" format="counter" sectionFormat="of" derivedContent="3.3
.4.3"/> for more
information about exceptional cases when it may be appropriate to use information about exceptional cases when it may be appropriate to use
event #3.</t> event #3.</t>
</section>
</section> <section anchor="flowhealth" numbered="true" toc="include" removeInRFC="
<section anchor="flowhealth" title="Traffic Health"> false" pn="section-3.3.4">
<name slugifiedName="name-traffic-health">Traffic Health</name>
<section anchor="trafficabsent" title="Absence of Traffic"> <section anchor="trafficabsent" numbered="true" toc="exclude" removeIn
RFC="false" pn="section-3.3.4.1">
<t>If a gateway indicates one or more (S,G) subscriptions in a Membership <name slugifiedName="name-absence-of-traffic">Absence of Traffic</na
Update message, but no traffic for any of the (S,G)s is received in a me>
reasonable time, it’s appropriate for the gateway to restart the <t pn="section-3.3.4.1-1">If a gateway indicates one or more (S,G) s
ubscriptions in a Membership
Update message but no traffic for any of the (S,G)s is received in a
reasonable time, it's appropriate for the gateway to restart the
discovery process.</t> discovery process.</t>
<t pn="section-3.3.4.1-2">If the gateway restarts the discovery proc
<t>If the gateway restarts the discovery process multiple times consecutively ess multiple times consecutively
for this reason, the timeout period SHOULD be adjusted to provide a random for this reason, the timeout period <bcp14>SHOULD</bcp14> be adjusted to provide
a random
exponential back-off.</t> exponential back-off.</t>
<t pn="section-3.3.4.1-3">The <bcp14>RECOMMENDED</bcp14> timeout is
<t>The RECOMMENDED timeout is a random value in the range a random value in the range
[initial_timeout, MIN(initial_timeout * 2^retry_count, maximum_timeout)], [initial_timeout, MIN(initial_timeout * 2^retry_count, maximum_timeout)],
with a RECOMMENDED initial_timeout of 4 seconds and a RECOMMENDED with a <bcp14>RECOMMENDED</bcp14> initial_timeout of 4 seconds and a <bcp14>RECO MMENDED</bcp14>
maximum_timeout of 120 seconds (which is the recommended minimum NAT maximum_timeout of 120 seconds (which is the recommended minimum NAT
mapping timeout described in <xref target="RFC4787"/>).</t> mapping timeout described in <xref target="RFC4787" format="default" sectionForm
at="of" derivedContent="RFC4787"/>).</t>
<t>Note that the recommended initial_timeout is larger than the initial <t pn="section-3.3.4.1-4">Note that the recommended initial_timeout
timout recommended in the similar algorithm from Section 5.2.3.4.3 of is larger than the initial
<xref target="RFC7450"/>. This is to provide time for RPF Join propagation in t timeout recommended in the similar algorithm from <xref target="RFC7450" section
he Format="of" section="5.2.3.4.3" format="default" derivedLink="https://rfc-editor
.org/rfc/rfc7450#section-5.2.3.4.3" derivedContent="RFC7450"/>. This is to prov
ide time for RPF Join propagation in the
sending network. Although the timeout values may be administratively sending network. Although the timeout values may be administratively
adjusted to support performance requirements, operators are advised to adjusted to support performance requirements, operators are advised to
consider the possibility of join propagation delays between the sender consider the possibility of join propagation delays between the sender
and the relay when choosing an appropriate timeout value.</t> and the relay when choosing an appropriate timeout value.</t>
<t pn="section-3.3.4.1-5">Gateways restarting the discovery process
<t>Gateways restarting the discovery process because of an absence of because of an absence of
traffic MUST use a hold-down timer that removes this relay from traffic <bcp14>MUST</bcp14> use a hold-down timer that removes this relay from
consideration during subsequent rounds of discovery while active. consideration during subsequent rounds of discovery while active.
The hold-down SHOULD last for no less than 3 minutes and no more than The hold-down <bcp14>SHOULD</bcp14> last for no less than 3 minutes and no more than
10 minutes.</t> 10 minutes.</t>
</section>
</section> <section anchor="loss-and-congestion" numbered="true" toc="exclude" re
<section anchor="loss-and-congestion" title="Loss and Congestion"> moveInRFC="false" pn="section-3.3.4.2">
<name slugifiedName="name-loss-and-congestion">Loss and Congestion</
<t>In some gateway deployments, it is also feasible to monitor the health of name>
traffic flows through the gateway, for example by detecting the rate of <t pn="section-3.3.4.2-1">In some gateway deployments, it is also fe
packet loss by communicating out of band with receivers, or monitoring the asible to monitor the health of
traffic flows through the gateway -- for example, by detecting the rate of
packet loss by communicating out of band with receivers or monitoring the
packets of known protocols with sequence numbers. Where feasible, packets of known protocols with sequence numbers. Where feasible,
it’s encouraged for gateways to use such traffic health information to it's encouraged for gateways to use such traffic health information to
trigger a restart of the discovery process during event #3 (before trigger a restart of the discovery process during event #3 (before
sending a new Request message).</t> sending a new Request message).</t>
<t pn="section-3.3.4.2-2">However, if a transient network event that
<t>However, to avoid synchronized rediscovery by many gateways simultaneously affects the tunneled
after a transient network event upstream of a relay results in multicast stream -- as opposed to an event that affects the tunnel
many receivers detecting poor flow health at the same time, it’s recommended connection between the relay and gateway -- occurs, poor health
to add a random delay before restarting the discovery process in this case.</t> detection could be triggered for many gateways simultaneously. In
this situation, adding a random delay to avoid synchronized
<t>The span of the random portion of the delay should be no less than 10 rediscovery by many gateways is recommended.</t>
seconds by default, but may be administratively configured <t pn="section-3.3.4.2-3">The span of the random portion of the dela
y should be no less than 10
seconds by default but may be administratively configured
to support different performance requirements.</t> to support different performance requirements.</t>
</section>
</section> <section anchor="ancient" numbered="true" toc="exclude" removeInRFC="f
<section anchor="ancient" title="Ancient Discovery Information"> alse" pn="section-3.3.4.3">
<name slugifiedName="name-ancient-discovery-informati">Ancient Disco
<t>In most cases, a gateway actively receiving healthy traffic from a relay very Information</name>
<t pn="section-3.3.4.3-1">In most cases, a gateway actively receivin
g healthy traffic from a relay
that has not indicated load with the L flag should prefer to remain that has not indicated load with the L flag should prefer to remain
connected to the same relay, as described in <xref target="stability"/>.</t> connected to the same relay, as described in <xref target="stability" format="de
fault" sectionFormat="of" derivedContent="Section 3.3.3"/>.</t>
<t>However, a relay that appears healthy but has been forwarding traffic for <t pn="section-3.3.4.3-2">However, a relay that appears healthy but
has been forwarding traffic for
days or weeks may have an increased chance of becoming unstable. Gateways days or weeks may have an increased chance of becoming unstable. Gateways
may benefit from restarting the discovery process during event #3 (before may benefit from restarting the discovery process during event #3 (before
sending a Request message) after the expiration of a long-term timeout, on sending a Request message) after the expiration of a long-term timeout on
the order of multiple hours, or even days in some deployments.</t> the order of multiple hours or even days in some deployments.</t>
<t pn="section-3.3.4.3-3">It may be beneficial for such timers to co
<t>It may be beneficial for such timers to consider the amount of traffic nsider the amount of traffic
currently being forwarded, and to give a higher probability of restarting currently being forwarded and to give a higher probability of restarting
discovery during periods with an unusually low data rate, to reduce the discovery during periods with an unusually low data rate to reduce the
impact on active traffic while still avoiding relying on the results of a impact on active traffic while still avoiding relying on the results of a
very old discovery.</t> very old discovery.</t>
<t pn="section-3.3.4.3-4">Other issues may also be worth considering
<t>Other issues may also be worth considering as part of this heuristic; for as part of this heuristic; for
example, if the DNS expiry time of the record that was used to discover example, if the DNS expiry time of the record that was used to discover
the current relay has not passed, the long term timer might be restarted the current relay has not passed, the long-term timer might be restarted
without restarting the discovery process.</t> without restarting the discovery process.</t>
</section>
</section> </section>
</section> <section anchor="loaded" numbered="true" toc="include" removeInRFC="fals
<section anchor="loaded" title="Relay Loaded or Shutting Down"> e" pn="section-3.3.5">
<name slugifiedName="name-relay-loaded-or-shutting-do">Relay Loaded or
<t>The L flag (see Section 5.1.4.4 of <xref target="RFC7450"/>) is the preferred Shutting Down</name>
mechanism for <t pn="section-3.3.5-1">The L flag (see <xref target="RFC7450" section
Format="of" section="5.1.4.4" format="default" derivedLink="https://rfc-editor.o
rg/rfc/rfc7450#section-5.1.4.4" derivedContent="RFC7450"/>) is the preferred mec
hanism for
a relay to signal overloading or a graceful shutdown to gateways.</t> a relay to signal overloading or a graceful shutdown to gateways.</t>
<t pn="section-3.3.5-2">A gateway that supports handling of the L flag
<t>A gateway that supports handling of the L flag should generally restart the should generally restart the
discovery process when it processes a Membership Query packet with the discovery process when it processes a Membership Query packet with the
L flag set. If an L flag is received while a concurrent Happy Eyeballs L flag set. If an L flag is received while a concurrent Happy Eyeballs
discovery process is under way for multiple candidate relays (<xref target="happ discovery process is underway for multiple candidate relays (<xref target="happy
y"/>), " format="default" sectionFormat="of" derivedContent="Section 3.2"/>),
the relay sending the L flag SHOULD NOT be considered for the relay selection.</ the relay sending the L flag <bcp14>SHOULD NOT</bcp14> be considered for the rel
t> ay selection.</t>
<t pn="section-3.3.5-3">It is also <bcp14>RECOMMENDED</bcp14> that gat
<t>It is also RECOMMENDED that gateways avoid choosing a relay eways avoid choosing a relay
that has recently sent an L flag, with approximately a 10-minute hold-down. that has recently sent an L flag, with approximately a 10-minute hold-down.
Gateways SHOULD treat this hold-down timer in the same way as the hold-down Gateways <bcp14>SHOULD</bcp14> treat this hold-down timer in the same way as the
in <xref target="trafficabsent"/>, so that the relay is removed from considerati hold-down
on in <xref target="trafficabsent" format="default" sectionFormat="of" derivedConte
for short-term subsequent rounds of discovery.</t> nt="Section 3.3.4.1"/> so that the relay is removed from consideration
for subsequent short-term rounds of discovery.</t>
</section> </section>
<section anchor="discoverymessage" title="Relay Discovery Messages vs. Restartin <section anchor="discoverymessage" numbered="true" toc="include" removeI
g Discovery"> nRFC="false" pn="section-3.3.6">
<name slugifiedName="name-relay-discovery-messages-vs">Relay Discovery
<t>All AMT relays are required by <xref target="RFC7450"/> to support handling o Messages vs. Restarting Discovery</name>
f <t pn="section-3.3.6-1">All AMT relays are required by <xref target="R
Relay Discovery messages (e.g. in Section 5.3.3.2 of <xref target="RFC7450"/>).< FC7450" format="default" sectionFormat="of" derivedContent="RFC7450"/> to suppor
/t> t handling of
Relay Discovery messages (e.g., in <xref target="RFC7450" sectionFormat="of" sec
<t>So a gateway with an existing connection to a relay can send a Relay tion="5.3.3.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7450#
section-5.3.3.2" derivedContent="RFC7450"/>).</t>
<t pn="section-3.3.6-2">So a gateway with an existing connection to a
relay can send a Relay
Discovery message to the unicast address of that AMT relay. Under stable Discovery message to the unicast address of that AMT relay. Under stable
conditions with an unloaded relay, it’s expected that the relay will conditions with an unloaded relay, it's expected that the relay will
return its own unicast address in the Relay Advertisement, in response return its own unicast address in the Relay Advertisement in response
to such a Relay Discovery message. Since this will not result in the to such a Relay Discovery message. Since this will not result in the
gateway changing to another relay unless the relay directs the gateway gateway changing to another relay unless the relay directs the gateway
away, this is a reasonable exception to the advice against handling event #3 away, this is a reasonable exception to the advice against handling event #3
described in <xref target="stability"/>.</t> described in <xref target="stability" format="default" sectionFormat="of" derive
dContent="Section 3.3.3"/>.</t>
<t>This behavior is discouraged for gateways that do support the L flag, to <t pn="section-3.3.6-3">This behavior is discouraged for gateways that
do support the L flag to
avoid sending unnecessary packets over the network.</t> avoid sending unnecessary packets over the network.</t>
<t pn="section-3.3.6-4">However, gateways that do not support the L fl
<t>However, gateways that do not support the L flag may be able to avoid a ag may be able to avoid a
disruption in the forwarded traffic by sending such Relay Discovery disruption in the forwarded traffic by sending such Relay Discovery
messages regularly. When a relay is under load or has started a graceful messages regularly. When a relay is under load or has started a graceful
shutdown, it may respond with a different relay address, which the gateway shutdown, it may respond with a different relay address, which the gateway
can use to connect to a different relay. This kind of coordinated handoff can use to connect to a different relay. This kind of coordinated handoff
will likely result in a smaller disruption to the traffic than if the relay will likely result in a smaller disruption to the traffic than if the relay
simply stops responding to Request messages, and stops forwarding traffic.</t> simply stops responding to Request messages and stops forwarding traffic.</t>
<t pn="section-3.3.6-5">This style of Relay Discovery message (one sen
<t>This style of Relay Discovery message (one sent to the unicast address t to the unicast address
of a relay that’s already forwarding traffic to this gateway) SHOULD NOT be of a relay that's already forwarding traffic to this gateway) <bcp14>SHOULD NOT<
considered a full restart of the relay discovery process. It is RECOMMENDED /bcp14> be
for gateways to support the L flag, but for gateways that do not support the considered a full restart of the relay discovery process. It is <bcp14>RECOMMEN
DED</bcp14>
that gateways support the L flag, but for gateways that do not support the
L flag, sending this message during event #3 may help mitigate service L flag, sending this message during event #3 may help mitigate service
degradation when relays become unstable.</t> degradation when relays become unstable.</t>
</section>
</section> <section anchor="independent-discovery-per-traffic-source" numbered="tru
<section anchor="independent-discovery-per-traffic-source" title="Independent Di e" toc="include" removeInRFC="false" pn="section-3.3.7">
scovery Per Traffic Source"> <name slugifiedName="name-independent-discovery-per-t">Independent Dis
covery per Traffic Source</name>
<t>Relays discovered via the AMTRELAY RR are source-specific relay addresses, an <t pn="section-3.3.7-1">Relays discovered via the AMTRELAY RR are sour
d ce-specific relay addresses and
may use different pseudo-interfaces from each other and from relays may use different pseudo-interfaces from each other and from relays
discovered via DNS-SD or a non-source-specific address, as described in discovered via DNS-SD or via a non-source-specific address, as described in
Section 4.1.2.1 of <xref target="RFC7450"/>.</t> <xref target="RFC7450" sectionFormat="of" section="4.1.2.1" format="default" der
ivedLink="https://rfc-editor.org/rfc/rfc7450#section-4.1.2.1" derivedContent="RF
<t>Restarting the discovery process for one pseudo-interface does not require C7450"/>.</t>
<t pn="section-3.3.7-2">Restarting the discovery process for one pseud
o-interface does not require
restarting the discovery process for other pseudo-interfaces. Gateway restarting the discovery process for other pseudo-interfaces. Gateway
heuristics about restarting the discovery process should operate heuristics about restarting the discovery process should operate
independently for different tunnels to relays, when responding to events independently for different tunnels to relays when responding to events
that are specific to the different tunnels.</t> that are specific to the different tunnels.</t>
</section>
</section> </section>
</section> <section anchor="dns-configuration" numbered="true" toc="include" removeIn
<section anchor="dns-configuration" title="DNS Configuration"> RFC="false" pn="section-3.4">
<name slugifiedName="name-dns-configuration">DNS Configuration</name>
<t>Often an AMT gateway will only have access to the source and group IP address <t pn="section-3.4-1">Often, an AMT gateway will only have access to the
es source and group IP addresses
of the desired traffic, and will not know any other name for the source of the of the desired traffic and will not know any other name for the source of the
traffic. Because of this, typically the best way of looking up AMTRELAY RRs traffic. Because of this, typically, the best way of looking up AMTRELAY RRs
will be by using the source IP address as an index into one of the reverse will be by using the source IP address as an index into one of the reverse
mapping trees (in-addr.arpa for IPv4, as described in Section 3.5 of mapping trees (in-addr.arpa for IPv4, as described in <xref target="RFC1035" sec
<xref target="RFC1035"/>, or ip6.arpa for IPv6, as described in Section 2.5 of < tionFormat="of" section="3.5" format="default" derivedLink="https://rfc-editor.o
xref target="RFC3596"/>).</t> rg/rfc/rfc1035#section-3.5" derivedContent="RFC1035"/>, or ip6.arpa for IPv6, as
described in <xref target="RFC3596" sectionFormat="of" section="2.5" format="de
<t>Therefore, it is RECOMMENDED that AMTRELAY RRs be added to reverse IP fault" derivedLink="https://rfc-editor.org/rfc/rfc3596#section-2.5" derivedConte
zones as appropriate. AMTRELAY records MAY also appear in other zones, nt="RFC3596"/>).</t>
<t pn="section-3.4-2">Therefore, it is <bcp14>RECOMMENDED</bcp14> that A
MTRELAY RRs be added to reverse IP
zones as appropriate. AMTRELAY records <bcp14>MAY</bcp14> also appear in other
zones,
since this may be necessary to perform delegation from the reverse zones since this may be necessary to perform delegation from the reverse zones
(see for example Section 5.2 of <xref target="RFC2317"/>), but the use case enab led (see, for example, <xref target="RFC2317" sectionFormat="of" section="5.2" forma t="default" derivedLink="https://rfc-editor.org/rfc/rfc2317#section-5.2" derived Content="RFC2317"/>), but the use case enabled
by this document requires a reverse IP mapping for the source from an by this document requires a reverse IP mapping for the source from an
(S,G) in order to be useful to most AMT gateways. This document does (S,G) in order to be useful to most AMT gateways. This document does
not define semantics for the use of AMTRELAY records obtained in a way not define semantics for the use of AMTRELAY records obtained in a way
other than by a reverse IP lookup.</t> other than by a reverse IP lookup.</t>
<t pn="section-3.4-3">When performing the AMTRELAY RR lookup, any CNAMEs
<t>When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs found MUST be or DNAMEs found <bcp14>MUST</bcp14> be
followed. This is necessary to support zone delegation. Some examples followed. This is necessary to support zone delegation. Some examples
outlining this need are described in <xref target="RFC2317"/>.</t> outlining this need are described in <xref target="RFC2317" format="default" sec
tionFormat="of" derivedContent="RFC2317"/>.</t>
<t>See <xref target="rrdef"/> and <xref target="rpformat"/> for a detailed expla <t pn="section-3.4-4">See Sections <xref target="rrdef" format="counter"
nation of the contents sectionFormat="of" derivedContent="4"/> and <xref target="rpformat" format="cou
for a DNS Zone file.</t> nter" sectionFormat="of" derivedContent="4.3"/> for a detailed explanation of th
e contents
</section> of a DNS zone file.</t>
<section anchor="waiting-for-dns-resolution" title="Waiting for DNS resolution"> </section>
<section anchor="waiting-for-dns-resolution" numbered="true" toc="include"
<t>The DNS query functionality is expected to follow ordinary standards and best removeInRFC="false" pn="section-3.5">
practices for DNS clients. A gateway MAY use an existing DNS client <name slugifiedName="name-waiting-for-dns-resolution">Waiting for DNS Re
implementation that does so, and MAY rely on that client’s retry logic solution</name>
<t pn="section-3.5-1">DNS query functionality is expected to follow ordi
nary standards and best
practices for DNS clients. A gateway <bcp14>MAY</bcp14> use an existing DNS cli
ent
implementation that does so and <bcp14>MAY</bcp14> rely on that client's retry l
ogic
to determine the timeouts between retries.</t> to determine the timeouts between retries.</t>
<t pn="section-3.5-2">Otherwise, a gateway <bcp14>MAY</bcp14> resend a D
<t>Otherwise, a gateway MAY re-send a DNS query if it does not receive an NS query if it does not receive an
appropriate DNS response within some timeout period. If the gateway retries appropriate DNS response within some timeout period. If the gateway retries
multiple times, the timeout period SHOULD be adjusted to provide a random multiple times, the timeout period <bcp14>SHOULD</bcp14> be adjusted to provide a random
exponential back-off.</t> exponential back-off.</t>
<t pn="section-3.5-3">As with the waiting process for the Relay Advertis
<t>As with the waiting process for the Relay Advertisement message from ement message from
Section 5.2.3.4.3 of <xref target="RFC7450"/>, the RECOMMENDED timeout is a rand <xref target="RFC7450" sectionFormat="of" section="5.2.3.4.3" format="default" d
om value erivedLink="https://rfc-editor.org/rfc/rfc7450#section-5.2.3.4.3" derivedContent
="RFC7450"/>, the <bcp14>RECOMMENDED</bcp14> timeout is a random value
in the range [initial_timeout, MIN(initial_timeout * 2^retry_count, in the range [initial_timeout, MIN(initial_timeout * 2^retry_count,
maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and maximum_timeout)], with a <bcp14>RECOMMENDED</bcp14> initial_timeout of 1 second
a RECOMMENDED maximum_timeout of 120 seconds.</t> and
a <bcp14>RECOMMENDED</bcp14> maximum_timeout of 120 seconds.</t>
</section> </section>
</section> </section>
<section anchor="rrdef" title="AMTRELAY Resource Record Definition"> <section anchor="rrdef" numbered="true" toc="include" removeInRFC="false" pn
="section-4">
<section anchor="amtrelay-rrtype" title="AMTRELAY RRType"> <name slugifiedName="name-amtrelay-resource-record-de">AMTRELAY Resource R
ecord Definition</name>
<t>The AMTRELAY RRType has the mnemonic AMTRELAY and type code 260 (decimal).</t <section anchor="amtrelay-rrtype" numbered="true" toc="include" removeInRF
> C="false" pn="section-4.1">
<name slugifiedName="name-amtrelay-rrtype">AMTRELAY RRType</name>
<t>The AMTRELAY RR is class independent.</t> <t pn="section-4.1-1">The AMTRELAY RRType has the mnemonic AMTRELAY and
type code 260 (decimal).</t>
</section> <t pn="section-4.1-2">The AMTRELAY RR is class independent.</t>
<section anchor="amtrelay-rdata-format" title="AMTRELAY RData Format"> </section>
<section anchor="amtrelay-rdata-format" numbered="true" toc="include" remo
<t>The AMTRELAY RData consists of a 8-bit precedence field, a 1-bit veInRFC="false" pn="section-4.2">
“Discovery Optional” field, a 7-bit type field, and a variable <name slugifiedName="name-amtrelay-rdata-format">AMTRELAY RData Format</
name>
<t pn="section-4.2-1">The AMTRELAY RData consists of an 8-bit precedence
field, a 1-bit
"Discovery Optional" field, a 7-bit type field, and a variable
length relay field.</t> length relay field.</t>
<artwork name="" type="" align="left" alt="" pn="section-4.2-2">
<figure><artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| precedence |D| type | | | precedence |D| type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ relay ~ ~ relay ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> </artwork>
<section anchor="rrdef-precedence" numbered="true" toc="include" removeI
<section anchor="rrdef-precedence" title="RData Format - Precedence"> nRFC="false" pn="section-4.2.1">
<name slugifiedName="name-rdata-format-precedence">RData Format - Prec
<t>This is an 8-bit precedence for this record. It is interpreted in edence</name>
the same way as the PREFERENCE field described in Section 3.3.9 of <t pn="section-4.2.1-1">This is an 8-bit precedence for this record.
<xref target="RFC1035"/>.</t> It is interpreted in
the same way as the PREFERENCE field described in <xref target="RFC1035" section
<t>Relays listed in AMTRELAY records with a lower value for precedence are to be Format="of" section="3.3.9" format="default" derivedLink="https://rfc-editor.org
/rfc/rfc1035#section-3.3.9" derivedContent="RFC1035"/>.</t>
<t pn="section-4.2.1-2">Relays listed in AMTRELAY records with a lower
value for precedence are to be
attempted first.</t> attempted first.</t>
</section>
</section> <section anchor="rrdef-dbit" numbered="true" toc="include" removeInRFC="
<section anchor="rrdef-dbit" title="RData Format - Discovery Optional (D-bit)"> false" pn="section-4.2.2">
<name slugifiedName="name-rdata-format-discovery-opti">RData Format -
<t>The D bit is a “Discovery Optional” flag.</t> Discovery Optional (D-bit)</name>
<t pn="section-4.2.2-1">The D-bit is a "Discovery Optional" flag.</t>
<t>If the D bit is set to 0, a gateway using this RR MUST perform AMT relay <t pn="section-4.2.2-2">If the D-bit is set to 0, a gateway using this
discovery as described in Section 4.2.1.1 of <xref target="RFC7450"/>, rather th RR <bcp14>MUST</bcp14> perform AMT relay
an directly discovery as described in <xref target="RFC7450" sectionFormat="of" section="4.2
.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7450#section-4
.2.1.1" derivedContent="RFC7450"/> rather than directly
sending an AMT Request message to the relay.</t> sending an AMT Request message to the relay.</t>
<t pn="section-4.2.2-3">That is, the gateway <bcp14>MUST</bcp14> recei
<t>That is, the gateway MUST receive an AMT Relay Advertisement message (Section ve an AMT Relay Advertisement message (<xref target="RFC7450" sectionFormat="of"
5.1.2 of <xref target="RFC7450"/>) for an address before sending an AMT Request section="5.1.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc745
message 0#section-5.1.2" derivedContent="RFC7450"/>) for an address before sending an AM
(Section 5.1.3 of <xref target="RFC7450"/>) to that address. Before receiving th T Request message
e Relay (<xref target="RFC7450" sectionFormat="of" section="5.1.3" format="default" deri
vedLink="https://rfc-editor.org/rfc/rfc7450#section-5.1.3" derivedContent="RFC74
50"/>) to that address. Before receiving the Relay
Advertisement message, this record has only indicated that the address can be Advertisement message, this record has only indicated that the address can be
used for AMT relay discovery, not for a Request message. This is necessary for used for AMT relay discovery, not for a Request message. This is necessary for
devices that are not fully functional AMT relays, but rather load balancers or devices that are not fully functional AMT relays but rather load balancers or
brokers, as mentioned in Section 4.2.1.1 of <xref target="RFC7450"/>.</t> brokers, as mentioned in <xref target="RFC7450" sectionFormat="of" section="4.2.
1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7450#section-4.
<t>If the D bit is set to 1, the gateway MAY send an AMT Request message directl 2.1.1" derivedContent="RFC7450"/>.</t>
y <t pn="section-4.2.2-4">If the D-bit is set to 1, the gateway <bcp14>M
AY</bcp14> send an AMT Request message directly
to the discovered relay address without first sending an AMT Discovery message.< /t> to the discovered relay address without first sending an AMT Discovery message.< /t>
<t pn="section-4.2.2-5">This bit should be set according to advice fro
<t>This bit should be set according to advice from the AMT relay operator. The m the AMT relay operator. The
D bit MUST be set to zero when no information is available from the AMT relay D-bit <bcp14>MUST</bcp14> be set to zero when no information is available from t
he AMT relay
operator about its suitability.</t> operator about its suitability.</t>
</section>
</section> <section anchor="rtype" numbered="true" toc="include" removeInRFC="false
<section anchor="rtype" title="RData Format - Type"> " pn="section-4.2.3">
<name slugifiedName="name-rdata-format-type">RData Format - Type</name
<t>The type field indicates the format of the information that >
<t pn="section-4.2.3-1">The type field indicates the format of the inf
ormation that
is stored in the relay field.</t> is stored in the relay field.</t>
<t pn="section-4.2.3-2">The following values are defined:</t>
<t>The following values are defined:</t> <ul spacing="normal" bare="false" empty="false" pn="section-4.2.3-3">
<li pn="section-4.2.3-3.1">type = 0:
<t><list style="symbols"> The relay field is empty (0 bytes).</li>
<t>type = 0: <li pn="section-4.2.3-3.2">type = 1:
The relay field is empty (0 bytes).</t> The relay field contains a 4-octet IPv4 address.</li>
<t>type = 1: <li pn="section-4.2.3-3.3">type = 2:
The relay field contains a 4-octet IPv4 address.</t> The relay field contains a 16-octet IPv6 address.</li>
<t>type = 2: <li pn="section-4.2.3-3.4">type = 3:
The relay field contains a 16-octet IPv6 address.</t>
<t>type = 3:
The relay field contains a wire-encoded domain name. The wire-encoded The relay field contains a wire-encoded domain name. The wire-encoded
format is self-describing, so the length is implicit. The domain name format is self-describing, so the length is implicit. The domain name
MUST NOT be compressed. (See Section 3.3 of <xref target="RFC1035"/> and Sectio <bcp14>MUST NOT</bcp14> be compressed (see <xref target="RFC1035" sectionFormat=
n 4 of "of" section="3.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc1
<xref target="RFC3597"/>.)</t> 035#section-3.3" derivedContent="RFC1035"/> and <xref target="RFC3597" sectionFo
</list></t> rmat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/r
fc3597#section-4" derivedContent="RFC3597"/>).</li>
<t>RRs with an undefined value in the Type field SHOULD NOT be considered </ul>
<t pn="section-4.2.3-4">RRs with an undefined value in the Type field
<bcp14>SHOULD NOT</bcp14> be considered
by receiving gateways for AMT relay discovery.</t> by receiving gateways for AMT relay discovery.</t>
</section>
</section> <section anchor="rdformat" numbered="true" toc="include" removeInRFC="fa
<section anchor="rdformat" title="RData Format - Relay"> lse" pn="section-4.2.4">
<name slugifiedName="name-rdata-format-relay">RData Format - Relay</na
<t>The relay field is the address or domain name of the AMT relay. It is me>
<t pn="section-4.2.4-1">The relay field is the address or domain name
of the AMT relay. It is
formatted according to the type field.</t> formatted according to the type field.</t>
<t pn="section-4.2.4-2">When the type field is 0, the length of the re
<t>When the type field is 0, the length of the relay field is 0, and it lay field is 0, and it
indicates that no AMT relay should be used for multicast traffic from this indicates that no AMT relay should be used for multicast traffic from this
source.</t> source.</t>
<t pn="section-4.2.4-3">When the type field is 1, the length of the re
<t>When the type field is 1, the length of the relay field is 4 octets, and a lay field is 4 octets, and a
32-bit IPv4 address is present. This is an IPv4 address as described in 32-bit IPv4 address is present. This is an IPv4 address as described in
Section 3.4.1 of <xref target="RFC1035"/>. This is a 32-bit number in network by te <xref target="RFC1035" sectionFormat="of" section="3.4.1" format="default" deriv edLink="https://rfc-editor.org/rfc/rfc1035#section-3.4.1" derivedContent="RFC103 5"/>. This is a 32-bit number in network byte
order.</t> order.</t>
<t pn="section-4.2.4-4">When the type field is 2, the length of the re
<t>When the type field is 2, the length of the relay field is 16 octets, and lay field is 16 octets, and
a 128-bit IPv6 address is present. This is an IPv6 address as described in a 128-bit IPv6 address is present. This is an IPv6 address as described in
Section 2.2 of <xref target="RFC3596"/>. This is a 128-bit number in network byt <xref target="RFC3596" sectionFormat="of" section="2.2" format="default" derived
e order.</t> Link="https://rfc-editor.org/rfc/rfc3596#section-2.2" derivedContent="RFC3596"/>
. This is a 128-bit number in network byte order.</t>
<t>When the type field is 3, the relay field is a normal wire-encoded domain <t pn="section-4.2.4-5">When the type field is 3, the relay field is a
name, as described in Section 3.3 of <xref target="RFC1035"/>. Compression MUST normal wire-encoded domain
NOT be name, as described in <xref target="RFC1035" sectionFormat="of" section="3.3" fo
used, for the reasons given in Section 4 of <xref target="RFC3597"/>.</t> rmat="default" derivedLink="https://rfc-editor.org/rfc/rfc1035#section-3.3" deri
vedContent="RFC1035"/>. For the reasons given in <xref target="RFC3597" sectionF
<t>For a type 3 record, the D-bit and preference fields carry over to all ormat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/
rfc3597#section-4" derivedContent="RFC3597"/>, compression <bcp14>MUST NOT</bcp1
4> be
used.</t>
<t pn="section-4.2.4-6">For a type 3 record, the D-bit and preference
fields carry over to all
A or AAAA records for the domain name. There is no difference in the A or AAAA records for the domain name. There is no difference in the
result of the discovery process when it’s obtained by type 1 or type 2 result of the discovery process when it's obtained by type 1 or type 2
AMTRELAY records with identical D-bit and preference fields, vs. when AMTRELAY records with identical D-bit and preference fields vs. when
the result is obtained by a type 3 AMTRELAY record that resolves the result is obtained by a type 3 AMTRELAY record that resolves
to the same set of IPv4 and IPv6 addresses via A and AAAA lookups.</t> to the same set of IPv4 and IPv6 addresses via A and AAAA lookups.</t>
</section>
</section> </section>
</section> <section anchor="rpformat" numbered="true" toc="include" removeInRFC="fals
<section anchor="rpformat" title="AMTRELAY Record Presentation Format"> e" pn="section-4.3">
<name slugifiedName="name-amtrelay-record-presentatio">AMTRELAY Record P
<section anchor="representation-of-amtrelay-rrs" title="Representation of AMTREL resentation Format</name>
AY RRs"> <section anchor="representation-of-amtrelay-rrs" numbered="true" toc="in
clude" removeInRFC="false" pn="section-4.3.1">
<t>AMTRELAY RRs may appear in a zone data master file. The precedence, D-bit, <name slugifiedName="name-representation-of-amtrelay-">Representation
relay type, and relay fields are REQUIRED.</t> of AMTRELAY RRs</name>
<t pn="section-4.3.1-1">AMTRELAY RRs may appear in a zone data master
<t>If the relay type field is 0, the relay field MUST be “.”.</t> file. The precedence, D-bit,
relay type, and relay fields are <bcp14>REQUIRED</bcp14>.</t>
<t>The presentation for the record is as follows:</t> <t pn="section-4.3.1-2">If the relay type field is 0, the relay field
<bcp14>MUST</bcp14> be ".".</t>
<figure><artwork><![CDATA[ <t pn="section-4.3.1-3">The presentation for the record is as follows:
</t>
<sourcecode name="" type="" markers="false" pn="section-4.3.1-4">
IN AMTRELAY precedence D-bit type relay IN AMTRELAY precedence D-bit type relay
]]></artwork></figure> </sourcecode>
</section>
</section> <section anchor="examples" numbered="true" toc="include" removeInRFC="fa
<section anchor="examples" title="Examples"> lse" pn="section-4.3.2">
<name slugifiedName="name-examples">Examples</name>
<t>In a DNS authoritative nameserver that understands the AMTRELAY type, <t pn="section-4.3.2-1">In a DNS authoritative nameserver that underst
ands the AMTRELAY type,
the zone might contain a set of entries like this:</t> the zone might contain a set of entries like this:</t>
<sourcecode name="" type="" markers="false" pn="section-4.3.2-2">
<figure><artwork><![CDATA[
$ORIGIN 100.51.198.in-addr.arpa. $ORIGIN 100.51.198.in-addr.arpa.
12 IN AMTRELAY 10 0 1 203.0.113.15 12 IN AMTRELAY 10 0 1 203.0.113.15
12 IN AMTRELAY 10 0 2 2001:db8::15 12 IN AMTRELAY 10 0 2 2001:db8::15
12 IN AMTRELAY 128 1 3 amtrelays.example.com. 12 IN AMTRELAY 128 1 3 amtrelays.example.com.
]]></artwork></figure> </sourcecode>
<t pn="section-4.3.2-3">This configuration advertises an IPv4 discover
<t>This configuration advertises an IPv4 discovery address, an IPv6 y address, an IPv6
discovery address, and a domain name for AMT relays which can receive discovery address, and a domain name for AMT relays that can receive
traffic from the source 198.51.100.12. The IPv4 and IPv6 addresses traffic from the source 198.51.100.12. The IPv4 and IPv6 addresses
are configured with a D-bit of 0 (meaning discovery is mandatory, as are configured with a D-bit of 0 (meaning discovery is mandatory, as
described in <xref target="rrdef-dbit"/>), and a precedence 10 (meaning they’re described in <xref target="rrdef-dbit" format="default" sectionFormat="of" deriv edContent="Section 4.2.2"/>) and a precedence 10 (meaning they're
preferred ahead of the last entry, which has precedence 128).</t> preferred ahead of the last entry, which has precedence 128).</t>
<t pn="section-4.3.2-4">For zone files in name servers that don't supp
<t>For zone files in name servers that don’t support the AMTRELAY RRType ort the AMTRELAY RRType
natively, it’s possible to use the format for unknown RR types, as natively, it's possible to use the format for unknown RR types, as
described in <xref target="RFC3597"/>. This approach would replace the AMTRELAY described in <xref target="RFC3597" format="default" sectionFormat="of" derivedC
ontent="RFC3597"/>. This approach would replace the AMTRELAY
entries in the example above with the entries below:</t> entries in the example above with the entries below:</t>
<sourcecode name="" type="" markers="false" pn="section-4.3.2-5">
<figure><artwork><![CDATA[
10 IN TYPE260 \# ( 10 IN TYPE260 \# (
6 ; length 6 ; length
0a ; precedence=10 0a ; precedence=10
01 ; D=0, relay type=1, an IPv4 address 01 ; D=0, relay type=1, an IPv4 address
cb00710f ) ; 203.0.113.15 cb00710f ) ; 203.0.113.15
10 IN TYPE260 \# ( 10 IN TYPE260 \# (
18 ; length 18 ; length
0a ; precedence=10 0a ; precedence=10
02 ; D=0, relay type=2, an IPv6 address 02 ; D=0, relay type=2, an IPv6 address
20010db800000000000000000000000f ) ; 2001:db8::15 20010db800000000000000000000000f ) ; 2001:db8::15
10 IN TYPE260 \# ( 10 IN TYPE260 \# (
24 ; length 24 ; length
80 ; precedence=128 80 ; precedence=128
83 ; D=1, relay type=3, a wire-encoded domain name 83 ; D=1, relay type=3, a wire-encoded domain name
09616d7472656c617973076578616d706c6503636f6d ) ; domain name 09616d7472656c617973076578616d706c6503636f6d ) ; domain name
]]></artwork></figure> </sourcecode>
<t pn="section-4.3.2-6">See <xref target="extranslate" format="default
<t>See <xref target="extranslate"/> for more details.</t> " sectionFormat="of" derivedContent="Appendix A"/> for more details.</t>
</section>
</section> </section>
</section> </section>
</section> <section anchor="iana" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="iana" title="IANA Considerations"> "section-5">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>This document updates the IANA Registry for DNS Resource Record Types <t pn="section-5-1">This document updates the DNS "Resource Record (RR) TY
PEs" registry
by assigning type 260 to the AMTRELAY record.</t> by assigning type 260 to the AMTRELAY record.</t>
<t pn="section-5-2">This document creates a new registry named "AMTRELAY R
<t>This document creates a new registry named “AMTRELAY Resource Record esource Record
Parameters”, with a sub-registry for the “Relay Type Field”. The initial Parameters" with a subregistry for the "Relay Type Field". The initial
values in the sub-registry are:</t> values in the subregistry are:</t>
<table align="left" pn="table-2">
<figure><artwork><![CDATA[ <name slugifiedName="name-initial-contents-of-the-rel">Initial Contents
+-------+---------------------------------------+ of the "Relay Type Field" Registry</name>
| Value | Description | <thead>
+-------+---------------------------------------+ <tr>
| 0 | No relay is present. | <th align="left" colspan="1" rowspan="1">Value</th>
| 1 | A 4-byte IPv4 address is present | <th align="left" colspan="1" rowspan="1">Description</th>
| 2 | A 16-byte IPv6 address is present | </tr>
| 3 | A wire-encoded domain name is present | </thead>
| 4-255 | Unassigned | <tbody>
+-------+---------------------------------------+ <tr>
]]></artwork></figure> <td align="left" colspan="1" rowspan="1">0</td>
<td align="left" colspan="1" rowspan="1">No relay is present</td>
<t>Values 0, 1, 2, and 3 are further explained in <xref target="rtype"/> and <xr </tr>
ef target="rdformat"/>. <tr>
<td align="left" colspan="1" rowspan="1">1</td>
<td align="left" colspan="1" rowspan="1">A 4-byte IPv4 address is pr
esent</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">2</td>
<td align="left" colspan="1" rowspan="1">A 16-byte IPv6 address is p
resent</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">3</td>
<td align="left" colspan="1" rowspan="1">A wire-encoded domain name
is present</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">4-255</td>
<td align="left" colspan="1" rowspan="1">Unassigned</td>
</tr>
</tbody>
</table>
<t pn="section-5-4">Values 0, 1, 2, and 3 are further explained in Section
s <xref target="rtype" format="counter" sectionFormat="of" derivedContent="4.2.3
"/> and <xref target="rdformat" format="counter" sectionFormat="of" derivedConte
nt="4.2.4"/>.
Relay type numbers 4 through 255 can be assigned with a policy of Relay type numbers 4 through 255 can be assigned with a policy of
Specification Required (as described in <xref target="RFC8126"/>).</t> Specification Required (as described in <xref target="RFC8126" format="default"
sectionFormat="of" derivedContent="RFC8126"/>).</t>
</section> </section>
<section anchor="security-considerations" title="Security Considerations"> <section anchor="security-considerations" numbered="true" toc="include" remo
veInRFC="false" pn="section-6">
<section anchor="use-of-amt" title="Use of AMT"> <name slugifiedName="name-security-considerations">Security Considerations
</name>
<t>This document defines a mechanism that enables a more widespread and <section anchor="use-of-amt" numbered="true" toc="include" removeInRFC="fa
lse" pn="section-6.1">
<name slugifiedName="name-use-of-amt">Use of AMT</name>
<t pn="section-6.1-1">This document defines a mechanism that enables a m
ore widespread and
automated use of AMT, even without access to a multicast backbone. automated use of AMT, even without access to a multicast backbone.
Operators of networks and applications that include a DRIAD-capable Operators of networks and applications that include a DRIAD-capable
AMT gateway are advised to carefully consider the security considerations AMT gateway are advised to carefully consider the security considerations
in Section 6 of <xref target="RFC7450"/>.</t> in <xref target="RFC7450" sectionFormat="of" section="6" format="default" derive
dLink="https://rfc-editor.org/rfc/rfc7450#section-6" derivedContent="RFC7450"/>.
<t>AMT gateway operators also are encouraged to take appropriate steps to </t>
ensure the integrity of the data received via AMT, for example by the <t pn="section-6.1-2">AMT gateway operators also are encouraged to take
opportunistic use of IPSec <xref target="RFC4301"/> to secure traffic received f appropriate steps to
rom AMT ensure the integrity of the data received via AMT, for example, by the
relays, when IPSECKEY records <xref target="RFC4025"/> are available or when a t opportunistic use of IPsec <xref target="RFC4301" format="default" sectionFormat
rust ="of" derivedContent="RFC4301"/> to secure traffic received from AMT
relays when IPSECKEY records <xref target="RFC4025" format="default" sectionForm
at="of" derivedContent="RFC4025"/> are available or when a trust
relationship with the AMT relays can be otherwise established and secured.</t> relationship with the AMT relays can be otherwise established and secured.</t>
<t pn="section-6.1-3">Note that AMT does not itself provide any integrit
<t>Note that AMT does not itself provide any integrity protection on y protection for
Multicast Data packets (Section 5.1.6 of <xref target="RFC7450"/>), so absent Multicast Data packets (<xref target="RFC7450" sectionFormat="of" section="5.1.6
" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7450#section-5.1.6
" derivedContent="RFC7450"/>), so absent
protections like those mentioned above, even an off-path attacker who protections like those mentioned above, even an off-path attacker who
discovers the gateway IP, the relay IP, and the relay source port for discovers the gateway IP, the relay IP, and the relay source port for
an active AMT connection can inject multicast data packets for a an active AMT connection can inject multicast data packets for a
joined (S,G) into the data stream if he can get data packets delivered joined (S,G) into the data stream if he can get data packets delivered
to the gateway IP that spoof the relay as the source.</t> to the gateway IP that spoof the relay as the source.</t>
</section>
</section> <section anchor="record-spoofing" numbered="true" toc="include" removeInRF
<section anchor="record-spoofing" title="Record-spoofing"> C="false" pn="section-6.2">
<name slugifiedName="name-record-spoofing">Record-Spoofing</name>
<t>The AMTRELAY resource record contains information that SHOULD be <t pn="section-6.2-1">The AMTRELAY resource record contains information
that <bcp14>SHOULD</bcp14> be
communicated to the DNS client without being modified. The communicated to the DNS client without being modified. The
method used to ensure the result was unmodified is up to the client.</t> method used to ensure the result was unmodified is up to the client.</t>
<t pn="section-6.2-2">There must be a trust relationship between the end
<t>There must be a trust relationship between the end consumer of this consumer of this
resource record and the DNS server. This relationship may be end-to-end resource record and the DNS server. This relationship may be end-to-end
DNSSEC validation, or a secure connection to a trusted DNS server that DNSSEC validation or a secure connection to a trusted DNS server that
provides end-to-end safety, to prevent record-spoofing of the response provides end-to-end safety to prevent record-spoofing of the response
from the trusted server. The connection to the trusted server can use from the trusted server. The connection to the trusted server can use
any secure channel, such as with a TSIG <xref target="RFC2845"/> or SIG(0) <xref any secure channel, such as with a TSIG <xref target="RFC2845" format="default"
target="RFC2931"/> sectionFormat="of" derivedContent="RFC2845"/> or SIG(0) <xref target="RFC2931" f
channel, a secure local channel on the host, DNS over TLS <xref target="RFC7858" ormat="default" sectionFormat="of" derivedContent="RFC2931"/>
/>, channel, a secure local channel on the host, DNS over TLS <xref target="RFC7858"
DNS over HTTPS <xref target="RFC8484"/>, or some other mechanism that provides format="default" sectionFormat="of" derivedContent="RFC7858"/>,
DNS over HTTPS <xref target="RFC8484" format="default" sectionFormat="of" derive
dContent="RFC8484"/>, or some other mechanism that provides
authentication of the RR.</t> authentication of the RR.</t>
<t pn="section-6.2-3">If an AMT gateway accepts a maliciously crafted AM
<t>If an AMT gateway accepts a maliciously crafted AMTRELAY record, TRELAY record,
the result could be a Denial of Service, or receivers processing the result could be a Denial of Service or receivers processing
multicast traffic from a source under the attacker’s control.</t> multicast traffic from a source under the attacker's control.</t>
</section>
</section> <section anchor="congestion" numbered="true" toc="include" removeInRFC="fa
<section anchor="congestion" title="Congestion"> lse" pn="section-6.3">
<name slugifiedName="name-congestion">Congestion</name>
<t>Multicast traffic, particularly interdomain multicast traffic, carries <t pn="section-6.3-1">Multicast traffic, particularly interdomain multic
some congestion risks, as described in Section 4 of <xref target="RFC8085"/>.</t ast traffic, carries
> some congestion risks, as described in <xref target="RFC8085" sectionFormat="of"
section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8085#se
<t>Application implementors and network operators that use AMT gateways ction-4" derivedContent="RFC8085"/>.</t>
are advised to take precautions including monitoring of application <t pn="section-6.3-2">Application implementors and network operators tha
t use AMT gateways
are advised to take precautions, including monitoring of application
traffic behavior, traffic authentication at ingest, rate-limiting of traffic behavior, traffic authentication at ingest, rate-limiting of
multicast traffic, and the use of circuit-breaker techniques such as multicast traffic, and the use of circuit-breaker techniques such as
those described in Section 3.1.10 of <xref target="RFC8085"/> and similar those described in <xref target="RFC8085" sectionFormat="of" section="3.1.10" fo
protections at the network level, in order to ensure network health rmat="default" derivedLink="https://rfc-editor.org/rfc/rfc8085#section-3.1.10" d
erivedContent="RFC8085"/> and similar
protections at the network level in order to ensure network health
in the event of misconfiguration, poorly written applications that in the event of misconfiguration, poorly written applications that
don’t follow UDP congestion control principles, or deliberate attack.</t> don't follow UDP congestion control principles, or a deliberate attack.</t>
<t pn="section-6.3-3"><xref target="RFC7450" sectionFormat="of" section=
<t>Section 4.1.4.2 of <xref target="RFC7450"/> and Section 6.1 of <xref target=" "4.1.4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7450#secti
RFC7450"/> on-4.1.4.2" derivedContent="RFC7450"/> and <xref target="RFC7450" sectionFormat=
"of" section="6.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7
450#section-6.1" derivedContent="RFC7450"/>
provide some further considerations and advice about mitigating provide some further considerations and advice about mitigating
congestion risk.</t> congestion risk.</t>
</section>
</section> </section>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>This specification was inspired by the previous work of Doug Nortz,
Robert Sayko, David Segelstein, and Percy Tarapore, presented in
the MBONED working group at IETF 93.</t>
<t>Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny
Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, Bill
Atwood, Tim Chown, Christian Worm Mortensen, Warren Kumari, Dan
Romanescu, Bernard Aboba, Carlos Pignataro, Niclas Comstedt,
Mirja Kühlewind, Henning Rogge, Éric Vyncke, Barry Lieba,
Roman Danyliw, Alissa Cooper, Suresh Krishnan, Adam Roach,
and Daniel Franke for their very helpful reviews and comments.</t>
</section>
</middle> </middle>
<back> <back>
<references pn="section-7">
<references title='Normative References'> <name slugifiedName="name-references">References</name>
<references pn="section-7.1">
<reference anchor="RFC1034" target='https://www.rfc-editor.org/info/rfc1034'> <name slugifiedName="name-normative-references">Normative References</na
<front> me>
<title>Domain names - concepts and facilities</title> <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1
<author initials='P.V.' surname='Mockapetris' fullname='P.V. Mockapetris'><organ 034" quoteTitle="true" derivedAnchor="RFC1034">
ization /></author> <front>
<date year='1987' month='November' /> <title>Domain names - concepts and facilities</title>
<abstract><t>This RFC is the revised basic definition of The Domain Name System. <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockape
It obsoletes RFC-882. This memo describes the domain style names and their us tris">
ed for host address look up and electronic mail forwarding. It discusses the cl <organization showOnFrontPage="true"/>
ients and servers in the domain name system and the protocol used between them.< </author>
/t></abstract> <date year="1987" month="November"/>
</front> <abstract>
<seriesInfo name='STD' value='13'/> <t>This RFC is the revised basic definition of The Domain Name Sys
<seriesInfo name='RFC' value='1034'/> tem. It obsoletes RFC-882. This memo describes the domain style names and thei
<seriesInfo name='DOI' value='10.17487/RFC1034'/> r used for host address look up and electronic mail forwarding. It discusses th
</reference> e clients and servers in the domain name system and the protocol used between th
em.</t>
<reference anchor="RFC1035" target='https://www.rfc-editor.org/info/rfc1035'> </abstract>
<front> </front>
<title>Domain names - implementation and specification</title> <seriesInfo name="STD" value="13"/>
<author initials='P.V.' surname='Mockapetris' fullname='P.V. Mockapetris'><organ <seriesInfo name="RFC" value="1034"/>
ization /></author> <seriesInfo name="DOI" value="10.17487/RFC1034"/>
<date year='1987' month='November' /> </reference>
<abstract><t>This RFC is the revised specification of the protocol and format us <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1
ed in the implementation of the Domain Name System. It obsoletes RFC-883. This 035" quoteTitle="true" derivedAnchor="RFC1035">
memo documents the details of the domain name client - server communication.</t> <front>
</abstract> <title>Domain names - implementation and specification</title>
</front> <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockape
<seriesInfo name='STD' value='13'/> tris">
<seriesInfo name='RFC' value='1035'/> <organization showOnFrontPage="true"/>
<seriesInfo name='DOI' value='10.17487/RFC1035'/> </author>
</reference> <date year="1987" month="November"/>
<abstract>
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> <t>This RFC is the revised specification of the protocol and forma
<front> t used in the implementation of the Domain Name System. It obsoletes RFC-883. T
<title>Key words for use in RFCs to Indicate Requirement Levels</title> his memo documents the details of the domain name client - server communication.
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></ </t>
author> </abstract>
<date year='1997' month='March' /> </front>
<abstract><t>In many standards track documents several words are used to signify <seriesInfo name="STD" value="13"/>
the requirements in the specification. These words are often capitalized. This <seriesInfo name="RFC" value="1035"/>
document defines these words as they should be interpreted in IETF documents. <seriesInfo name="DOI" value="10.17487/RFC1035"/>
This document specifies an Internet Best Current Practices for the Internet Comm </reference>
unity, and requests discussion and suggestions for improvements.</t></abstract> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
</front> 119" quoteTitle="true" derivedAnchor="RFC2119">
<seriesInfo name='BCP' value='14'/> <front>
<seriesInfo name='RFC' value='2119'/> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
<seriesInfo name='DOI' value='10.17487/RFC2119'/> le>
</reference> <author initials="S." surname="Bradner" fullname="S. Bradner">
<organization showOnFrontPage="true"/>
<reference anchor="RFC2181" target='https://www.rfc-editor.org/info/rfc2181'> </author>
<front> <date year="1997" month="March"/>
<title>Clarifications to the DNS Specification</title> <abstract>
<author initials='R.' surname='Elz' fullname='R. Elz'><organization /></author> <t>In many standards track documents several words are used to sig
<author initials='R.' surname='Bush' fullname='R. Bush'><organization /></author nify the requirements in the specification. These words are often capitalized.
> This document defines these words as they should be interpreted in IETF document
<date year='1997' month='July' /> s. This document specifies an Internet Best Current Practices for the Internet
<abstract><t>This document considers some areas that have been identified as pro Community, and requests discussion and suggestions for improvements.</t>
blems with the specification of the Domain Name System, and proposes remedies fo </abstract>
r the defects identified. [STANDARDS-TRACK]</t></abstract> </front>
</front> <seriesInfo name="BCP" value="14"/>
<seriesInfo name='RFC' value='2181'/> <seriesInfo name="RFC" value="2119"/>
<seriesInfo name='DOI' value='10.17487/RFC2181'/> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference> </reference>
<reference anchor="RFC2181" target="https://www.rfc-editor.org/info/rfc2
<reference anchor="RFC2782" target='https://www.rfc-editor.org/info/rfc2782'> 181" quoteTitle="true" derivedAnchor="RFC2181">
<front> <front>
<title>A DNS RR for specifying the location of services (DNS SRV)</title> <title>Clarifications to the DNS Specification</title>
<author initials='A.' surname='Gulbrandsen' fullname='A. Gulbrandsen'><organizat <author initials="R." surname="Elz" fullname="R. Elz">
ion /></author> <organization showOnFrontPage="true"/>
<author initials='P.' surname='Vixie' fullname='P. Vixie'><organization /></auth </author>
or> <author initials="R." surname="Bush" fullname="R. Bush">
<author initials='L.' surname='Esibov' fullname='L. Esibov'><organization /></au <organization showOnFrontPage="true"/>
thor> </author>
<date year='2000' month='February' /> <date year="1997" month="July"/>
<abstract><t>This document describes a DNS RR which specifies the location of th <abstract>
e server(s) for a specific protocol and domain. [STANDARDS-TRACK]</t></abstract <t>This document considers some areas that have been identified as
> problems with the specification of the Domain Name System, and proposes remedie
</front> s for the defects identified. [STANDARDS-TRACK]</t>
<seriesInfo name='RFC' value='2782'/> </abstract>
<seriesInfo name='DOI' value='10.17487/RFC2782'/> </front>
</reference> <seriesInfo name="RFC" value="2181"/>
<seriesInfo name="DOI" value="10.17487/RFC2181"/>
<reference anchor="RFC3376" target='https://www.rfc-editor.org/info/rfc3376'> </reference>
<front> <reference anchor="RFC2782" target="https://www.rfc-editor.org/info/rfc2
<title>Internet Group Management Protocol, Version 3</title> 782" quoteTitle="true" derivedAnchor="RFC2782">
<author initials='B.' surname='Cain' fullname='B. Cain'><organization /></author <front>
> <title>A DNS RR for specifying the location of services (DNS SRV)</t
<author initials='S.' surname='Deering' fullname='S. Deering'><organization /></ itle>
author> <author initials="A." surname="Gulbrandsen" fullname="A. Gulbrandsen
<author initials='I.' surname='Kouvelas' fullname='I. Kouvelas'><organization /> ">
</author> <organization showOnFrontPage="true"/>
<author initials='B.' surname='Fenner' fullname='B. Fenner'><organization /></au </author>
thor> <author initials="P." surname="Vixie" fullname="P. Vixie">
<author initials='A.' surname='Thyagarajan' fullname='A. Thyagarajan'><organizat <organization showOnFrontPage="true"/>
ion /></author> </author>
<date year='2002' month='October' /> <author initials="L." surname="Esibov" fullname="L. Esibov">
</front> <organization showOnFrontPage="true"/>
<seriesInfo name='RFC' value='3376'/> </author>
<seriesInfo name='DOI' value='10.17487/RFC3376'/> <date year="2000" month="February"/>
</reference> <abstract>
<t>This document describes a DNS RR which specifies the location o
<reference anchor="RFC3596" target='https://www.rfc-editor.org/info/rfc3596'> f the server(s) for a specific protocol and domain. [STANDARDS-TRACK]</t>
<front> </abstract>
<title>DNS Extensions to Support IP Version 6</title> </front>
<author initials='S.' surname='Thomson' fullname='S. Thomson'><organization /></ <seriesInfo name="RFC" value="2782"/>
author> <seriesInfo name="DOI" value="10.17487/RFC2782"/>
<author initials='C.' surname='Huitema' fullname='C. Huitema'><organization /></ </reference>
author> <reference anchor="RFC3376" target="https://www.rfc-editor.org/info/rfc3
<author initials='V.' surname='Ksinant' fullname='V. Ksinant'><organization /></ 376" quoteTitle="true" derivedAnchor="RFC3376">
author> <front>
<author initials='M.' surname='Souissi' fullname='M. Souissi'><organization /></ <title>Internet Group Management Protocol, Version 3</title>
author> <author initials="B." surname="Cain" fullname="B. Cain">
<date year='2003' month='October' /> <organization showOnFrontPage="true"/>
<abstract><t>This document defines the changes that need to be made to the Domai </author>
n Name System (DNS) to support hosts running IP version 6 (IPv6). The changes i <author initials="S." surname="Deering" fullname="S. Deering">
nclude a resource record type to store an IPv6 address, a domain to support look <organization showOnFrontPage="true"/>
ups based on an IPv6 address, and updated definitions of existing query types th </author>
at return Internet addresses as part of additional section processing. The exte <author initials="I." surname="Kouvelas" fullname="I. Kouvelas">
nsions are designed to be compatible with existing applications and, in particul <organization showOnFrontPage="true"/>
ar, DNS implementations themselves. [STANDARDS-TRACK]</t></abstract> </author>
</front> <author initials="B." surname="Fenner" fullname="B. Fenner">
<seriesInfo name='STD' value='88'/> <organization showOnFrontPage="true"/>
<seriesInfo name='RFC' value='3596'/> </author>
<seriesInfo name='DOI' value='10.17487/RFC3596'/> <author initials="A." surname="Thyagarajan" fullname="A. Thyagarajan
</reference> ">
<organization showOnFrontPage="true"/>
<reference anchor="RFC3597" target='https://www.rfc-editor.org/info/rfc3597'> </author>
<front> <date year="2002" month="October"/>
<title>Handling of Unknown DNS Resource Record (RR) Types</title> </front>
<author initials='A.' surname='Gustafsson' fullname='A. Gustafsson'><organizatio <seriesInfo name="RFC" value="3376"/>
n /></author> <seriesInfo name="DOI" value="10.17487/RFC3376"/>
<date year='2003' month='September' /> </reference>
<abstract><t>Extending the Domain Name System (DNS) with new Resource Record (RR <reference anchor="RFC3596" target="https://www.rfc-editor.org/info/rfc3
) types currently requires changes to name server software. This document speci 596" quoteTitle="true" derivedAnchor="RFC3596">
fies the changes necessary to allow future DNS implementations to handle new RR <front>
types transparently. [STANDARDS-TRACK]</t></abstract> <title>DNS Extensions to Support IP Version 6</title>
</front> <author initials="S." surname="Thomson" fullname="S. Thomson">
<seriesInfo name='RFC' value='3597'/> <organization showOnFrontPage="true"/>
<seriesInfo name='DOI' value='10.17487/RFC3597'/> </author>
</reference> <author initials="C." surname="Huitema" fullname="C. Huitema">
<organization showOnFrontPage="true"/>
<reference anchor="RFC3810" target='https://www.rfc-editor.org/info/rfc3810'> </author>
<front> <author initials="V." surname="Ksinant" fullname="V. Ksinant">
<title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</title> <organization showOnFrontPage="true"/>
<author initials='R.' surname='Vida' fullname='R. Vida' role='editor'><organizat </author>
ion /></author> <author initials="M." surname="Souissi" fullname="M. Souissi">
<author initials='L.' surname='Costa' fullname='L. Costa' role='editor'><organiz <organization showOnFrontPage="true"/>
ation /></author> </author>
<date year='2004' month='June' /> <date year="2003" month="October"/>
<abstract><t>This document updates RFC 2710, and it specifies Version 2 of the u <abstract>
lticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to d <t>This document defines the changes that need to be made to the D
iscover the presence of multicast listeners on directly attached links, and to d omain Name System (DNS) to support hosts running IP version 6 (IPv6). The chang
iscover which multicast addresses are of interest to those neighboring nodes. M es include a resource record type to store an IPv6 address, a domain to support
LDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a n lookups based on an IPv6 address, and updated definitions of existing query type
ode to report interest in listening to packets with a particular multicast addre s that return Internet addresses as part of additional section processing. The
ss only from specific source addresses or from all sources except for specific s extensions are designed to be compatible with existing applications and, in part
ource addresses. [STANDARDS-TRACK]</t></abstract> icular, DNS implementations themselves. [STANDARDS-TRACK]</t>
</front> </abstract>
<seriesInfo name='RFC' value='3810'/> </front>
<seriesInfo name='DOI' value='10.17487/RFC3810'/> <seriesInfo name="STD" value="88"/>
</reference> <seriesInfo name="RFC" value="3596"/>
<seriesInfo name="DOI" value="10.17487/RFC3596"/>
<reference anchor="RFC4604" target='https://www.rfc-editor.org/info/rfc4604'> </reference>
<front> <reference anchor="RFC3597" target="https://www.rfc-editor.org/info/rfc3
<title>Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast 597" quoteTitle="true" derivedAnchor="RFC3597">
Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast</ti <front>
tle> <title>Handling of Unknown DNS Resource Record (RR) Types</title>
<author initials='H.' surname='Holbrook' fullname='H. Holbrook'><organization /> <author initials="A." surname="Gustafsson" fullname="A. Gustafsson">
</author> <organization showOnFrontPage="true"/>
<author initials='B.' surname='Cain' fullname='B. Cain'><organization /></author </author>
> <date year="2003" month="September"/>
<author initials='B.' surname='Haberman' fullname='B. Haberman'><organization /> <abstract>
</author> <t>Extending the Domain Name System (DNS) with new Resource Record
<date year='2006' month='August' /> (RR) types currently requires changes to name server software. This document s
<abstract><t>The Internet Group Management Protocol Version 3 (IGMPv3) and the M pecifies the changes necessary to allow future DNS implementations to handle new
ulticast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow RR types transparently. [STANDARDS-TRACK]</t>
a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 </abstract>
multicast transmissions, respectively. Source-specific multicast (SSM) is a form </front>
of multicast in which a receiver is required to specify both the network-layer <seriesInfo name="RFC" value="3597"/>
address of the source and the multicast destination address in order to receive <seriesInfo name="DOI" value="10.17487/RFC3597"/>
the multicast transmission. This document defines the notion of an &quot;SSM-aw </reference>
are&quot; router and host, and clarifies and (in some cases) modifies the behavi <reference anchor="RFC3810" target="https://www.rfc-editor.org/info/rfc3
or of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-spec 810" quoteTitle="true" derivedAnchor="RFC3810">
ific multicast. This document updates the IGMPv3 and MLDv2 specifications. [ST <front>
ANDARDS-TRACK]</t></abstract> <title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</titl
</front> e>
<seriesInfo name='RFC' value='4604'/> <author initials="R." surname="Vida" fullname="R. Vida" role="editor
<seriesInfo name='DOI' value='10.17487/RFC4604'/> ">
</reference> <organization showOnFrontPage="true"/>
</author>
<reference anchor="RFC4607" target='https://www.rfc-editor.org/info/rfc4607'> <author initials="L." surname="Costa" fullname="L. Costa" role="edit
<front> or">
<title>Source-Specific Multicast for IP</title> <organization showOnFrontPage="true"/>
<author initials='H.' surname='Holbrook' fullname='H. Holbrook'><organization /> </author>
</author> <date year="2004" month="June"/>
<author initials='B.' surname='Cain' fullname='B. Cain'><organization /></author <abstract>
> <t>This document updates RFC 2710, and it specifies Version 2 of t
<date year='2006' month='August' /> he ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router
<abstract><t>IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.25 to discover the presence of multicast listeners on directly attached links, and
5.255) range are designated as source-specific multicast (SSM) destination addre to discover which multicast addresses are of interest to those neighboring nodes
sses and are reserved for use by source-specific applications and protocols. Fo . MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for
r IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-speci a node to report interest in listening to packets with a particular multicast a
fic multicast use. This document defines an extension to the Internet network s ddress only from specific source addresses or from all sources except for specif
ervice that applies to datagrams sent to SSM addresses and defines the host and ic source addresses. [STANDARDS-TRACK]</t>
router requirements to support this extension. [STANDARDS-TRACK]</t></abstract> </abstract>
</front> </front>
<seriesInfo name='RFC' value='4607'/> <seriesInfo name="RFC" value="3810"/>
<seriesInfo name='DOI' value='10.17487/RFC4607'/> <seriesInfo name="DOI" value="10.17487/RFC3810"/>
</reference> </reference>
<reference anchor="RFC4604" target="https://www.rfc-editor.org/info/rfc4
<reference anchor="RFC6724" target='https://www.rfc-editor.org/info/rfc6724'> 604" quoteTitle="true" derivedAnchor="RFC4604">
<front> <front>
<title>Default Address Selection for Internet Protocol Version 6 (IPv6)</title> <title>Using Internet Group Management Protocol Version 3 (IGMPv3) a
<author initials='D.' surname='Thaler' fullname='D. Thaler' role='editor'><organ nd Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific M
ization /></author> ulticast</title>
<author initials='R.' surname='Draves' fullname='R. Draves'><organization /></au <author initials="H." surname="Holbrook" fullname="H. Holbrook">
thor> <organization showOnFrontPage="true"/>
<author initials='A.' surname='Matsumoto' fullname='A. Matsumoto'><organization </author>
/></author> <author initials="B." surname="Cain" fullname="B. Cain">
<author initials='T.' surname='Chown' fullname='T. Chown'><organization /></auth <organization showOnFrontPage="true"/>
or> </author>
<date year='2012' month='September' /> <author initials="B." surname="Haberman" fullname="B. Haberman">
<abstract><t>This document describes two algorithms, one for source address sele <organization showOnFrontPage="true"/>
ction and one for destination address selection. The algorithms specify default </author>
behavior for all Internet Protocol version 6 (IPv6) implementations. They do n <date year="2006" month="August"/>
ot override choices made by applications or upper-layer protocols, nor do they p <abstract>
reclude the development of more advanced mechanisms for address selection. The <t>The Internet Group Management Protocol Version 3 (IGMPv3) and t
two algorithms share a common context, including an optional mechanism for allow he Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that al
ing administrators to provide policy that can override the default behavior. In low a host to inform its neighboring routers of its desire to receive IPv4 and I
dual-stack implementations, the destination address selection algorithm can con Pv6 multicast transmissions, respectively. Source-specific multicast (SSM) is a
sider both IPv4 and IPv6 addresses -- depending on the available source addresse form of multicast in which a receiver is required to specify both the network-la
s, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa. yer address of the source and the multicast destination address in order to rece
</t><t>Default address selection as defined in this specification applies to all ive the multicast transmission. This document defines the notion of an "SSM-awa
IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484 re" router and host, and clarifies and (in some cases) modifies the behavior of
. [STANDARDS-TRACK]</t></abstract> IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific m
</front> ulticast. This document updates the IGMPv3 and MLDv2 specifications. [STANDARD
<seriesInfo name='RFC' value='6724'/> S-TRACK]</t>
<seriesInfo name='DOI' value='10.17487/RFC6724'/> </abstract>
</reference> </front>
<seriesInfo name="RFC" value="4604"/>
<reference anchor="RFC6763" target='https://www.rfc-editor.org/info/rfc6763'> <seriesInfo name="DOI" value="10.17487/RFC4604"/>
<front> </reference>
<title>DNS-Based Service Discovery</title> <reference anchor="RFC4607" target="https://www.rfc-editor.org/info/rfc4
<author initials='S.' surname='Cheshire' fullname='S. Cheshire'><organization /> 607" quoteTitle="true" derivedAnchor="RFC4607">
</author> <front>
<author initials='M.' surname='Krochmal' fullname='M. Krochmal'><organization /> <title>Source-Specific Multicast for IP</title>
</author> <author initials="H." surname="Holbrook" fullname="H. Holbrook">
<date year='2013' month='February' /> <organization showOnFrontPage="true"/>
<abstract><t>This document specifies how DNS resource records are named and stru </author>
ctured to facilitate service discovery. Given a type of service that a client i <author initials="B." surname="Cain" fullname="B. Cain">
s looking for, and a domain in which the client is looking for that service, thi <organization showOnFrontPage="true"/>
s mechanism allows clients to discover a list of named instances of that desired </author>
service, using standard DNS queries. This mechanism is referred to as DNS-based <date year="2006" month="August"/>
Service Discovery, or DNS-SD.</t></abstract> <abstract>
</front> <t>IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.25
<seriesInfo name='RFC' value='6763'/> 5.255.255) range are designated as source-specific multicast (SSM) destination a
<seriesInfo name='DOI' value='10.17487/RFC6763'/> ddresses and are reserved for use by source-specific applications and protocols.
</reference> For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-s
pecific multicast use. This document defines an extension to the Internet netwo
<reference anchor="RFC7450" target='https://www.rfc-editor.org/info/rfc7450'> rk service that applies to datagrams sent to SSM addresses and defines the host
<front> and router requirements to support this extension. [STANDARDS-TRACK]</t>
<title>Automatic Multicast Tunneling</title> </abstract>
<author initials='G.' surname='Bumgardner' fullname='G. Bumgardner'><organizatio </front>
n /></author> <seriesInfo name="RFC" value="4607"/>
<date year='2015' month='February' /> <seriesInfo name="DOI" value="10.17487/RFC4607"/>
<abstract><t>This document describes Automatic Multicast Tunneling (AMT), a prot </reference>
ocol for delivering multicast traffic from sources in a multicast-enabled networ <reference anchor="RFC6724" target="https://www.rfc-editor.org/info/rfc6
k to receivers that lack multicast connectivity to the source network. The prot 724" quoteTitle="true" derivedAnchor="RFC6724">
ocol uses UDP encapsulation and unicast replication to provide this functionalit <front>
y.</t><t>The AMT protocol is specifically designed to support rapid deployment b <title>Default Address Selection for Internet Protocol Version 6 (IP
y requiring minimal changes to existing network infrastructure.</t></abstract> v6)</title>
</front> <author initials="D." surname="Thaler" fullname="D. Thaler" role="ed
<seriesInfo name='RFC' value='7450'/> itor">
<seriesInfo name='DOI' value='10.17487/RFC7450'/> <organization showOnFrontPage="true"/>
</reference> </author>
<author initials="R." surname="Draves" fullname="R. Draves">
<reference anchor="RFC8085" target='https://www.rfc-editor.org/info/rfc8085'> <organization showOnFrontPage="true"/>
<front> </author>
<title>UDP Usage Guidelines</title> <author initials="A." surname="Matsumoto" fullname="A. Matsumoto">
<author initials='L.' surname='Eggert' fullname='L. Eggert'><organization /></au <organization showOnFrontPage="true"/>
thor> </author>
<author initials='G.' surname='Fairhurst' fullname='G. Fairhurst'><organization <author initials="T." surname="Chown" fullname="T. Chown">
/></author> <organization showOnFrontPage="true"/>
<author initials='G.' surname='Shepherd' fullname='G. Shepherd'><organization /> </author>
</author> <date year="2012" month="September"/>
<date year='2017' month='March' /> <abstract>
<abstract><t>The User Datagram Protocol (UDP) provides a minimal message-passing <t>This document describes two algorithms, one for source address
transport that has no inherent congestion control mechanisms. This document pr selection and one for destination address selection. The algorithms specify def
ovides guidelines on the use of UDP for the designers of applications, tunnels, ault behavior for all Internet Protocol version 6 (IPv6) implementations. They
and other protocols that use UDP. Congestion control guidelines are a primary f do not override choices made by applications or upper-layer protocols, nor do th
ocus, but the document also provides guidance on other topics, including message ey preclude the development of more advanced mechanisms for address selection.
sizes, reliability, checksums, middlebox traversal, the use of Explicit Congest The two algorithms share a common context, including an optional mechanism for a
ion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.< llowing administrators to provide policy that can override the default behavior.
/t><t>Because congestion control is critical to the stable operation of the Inte In dual-stack implementations, the destination address selection algorithm can
rnet, applications and other protocols that choose to use UDP as an Internet tra consider both IPv4 and IPv6 addresses -- depending on the available source addr
nsport must employ mechanisms to prevent congestion collapse and to establish so esses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice ve
me degree of fairness with concurrent traffic. They may also need to implement rsa.</t>
additional mechanisms, depending on how they use UDP.</t><t>Some guidance is als <t>Default address selection as defined in this specification appl
o applicable to the design of other protocols (e.g., protocols layered directly ies to all IPv6 nodes, including both hosts and routers. This document obsolete
on IP or via IP-based tunnels), especially when these protocols do not themselve s RFC 3484. [STANDARDS-TRACK]</t>
s provide congestion control.</t><t>This document obsoletes RFC 5405 and adds gu </abstract>
idelines for multicast UDP usage.</t></abstract> </front>
</front> <seriesInfo name="RFC" value="6724"/>
<seriesInfo name='BCP' value='145'/> <seriesInfo name="DOI" value="10.17487/RFC6724"/>
<seriesInfo name='RFC' value='8085'/> </reference>
<seriesInfo name='DOI' value='10.17487/RFC8085'/> <reference anchor="RFC6763" target="https://www.rfc-editor.org/info/rfc6
</reference> 763" quoteTitle="true" derivedAnchor="RFC6763">
<front>
<reference anchor="RFC8305" target='https://www.rfc-editor.org/info/rfc8305'> <title>DNS-Based Service Discovery</title>
<front> <author initials="S." surname="Cheshire" fullname="S. Cheshire">
<title>Happy Eyeballs Version 2: Better Connectivity Using Concurrency</title> <organization showOnFrontPage="true"/>
<author initials='D.' surname='Schinazi' fullname='D. Schinazi'><organization /> </author>
</author> <author initials="M." surname="Krochmal" fullname="M. Krochmal">
<author initials='T.' surname='Pauly' fullname='T. Pauly'><organization /></auth <organization showOnFrontPage="true"/>
or> </author>
<date year='2017' month='December' /> <date year="2013" month="February"/>
<abstract><t>Many communication protocols operating over the modern Internet use <abstract>
hostnames. These often resolve to multiple IP addresses, each of which may hav <t>This document specifies how DNS resource records are named and
e different performance and connectivity characteristics. Since specific addres structured to facilitate service discovery. Given a type of service that a clie
ses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on nt is looking for, and a domain in which the client is looking for that service,
a network, clients that attempt multiple connections in parallel have a chance this mechanism allows clients to discover a list of named instances of that des
of establishing a connection more quickly. This document specifies requirements ired service, using standard DNS queries. This mechanism is referred to as DNS-b
for algorithms that reduce this user-visible delay and provides an example algo ased Service Discovery, or DNS-SD.</t>
rithm, referred to as &quot;Happy Eyeballs&quot;. This document obsoletes the o </abstract>
riginal algorithm description in RFC 6555.</t></abstract> </front>
</front> <seriesInfo name="RFC" value="6763"/>
<seriesInfo name='RFC' value='8305'/> <seriesInfo name="DOI" value="10.17487/RFC6763"/>
<seriesInfo name='DOI' value='10.17487/RFC8305'/> </reference>
</reference> <reference anchor="RFC7450" target="https://www.rfc-editor.org/info/rfc7
450" quoteTitle="true" derivedAnchor="RFC7450">
<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'> <front>
<front> <title>Automatic Multicast Tunneling</title>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author initials="G." surname="Bumgardner" fullname="G. Bumgardner">
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth <organization showOnFrontPage="true"/>
or> </author>
<date year='2017' month='May' /> <date year="2015" month="February"/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s <abstract>
pecifications. This document aims to reduce the ambiguity by clarifying that on <t>This document describes Automatic Multicast Tunneling (AMT), a
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs protocol for delivering multicast traffic from sources in a multicast-enabled ne
tract> twork to receivers that lack multicast connectivity to the source network. The
</front> protocol uses UDP encapsulation and unicast replication to provide this function
<seriesInfo name='BCP' value='14'/> ality.</t>
<seriesInfo name='RFC' value='8174'/> <t>The AMT protocol is specifically designed to support rapid depl
<seriesInfo name='DOI' value='10.17487/RFC8174'/> oyment by requiring minimal changes to existing network infrastructure.</t>
</reference> </abstract>
</front>
<reference anchor="RFC8499" target='https://www.rfc-editor.org/info/rfc8499'> <seriesInfo name="RFC" value="7450"/>
<front> <seriesInfo name="DOI" value="10.17487/RFC7450"/>
<title>DNS Terminology</title> </reference>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></ <reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8
author> 085" quoteTitle="true" derivedAnchor="RFC8085">
<author initials='A.' surname='Sullivan' fullname='A. Sullivan'><organization /> <front>
</author> <title>UDP Usage Guidelines</title>
<author initials='K.' surname='Fujiwara' fullname='K. Fujiwara'><organization /> <author initials="L." surname="Eggert" fullname="L. Eggert">
</author> <organization showOnFrontPage="true"/>
<date year='2019' month='January' /> </author>
<abstract><t>The Domain Name System (DNS) is defined in literally dozens of diff <author initials="G." surname="Fairhurst" fullname="G. Fairhurst">
erent RFCs. The terminology used by implementers and developers of DNS protocol <organization showOnFrontPage="true"/>
s, and by operators of DNS systems, has sometimes changed in the decades since t </author>
he DNS was first defined. This document gives current definitions for many of t <author initials="G." surname="Shepherd" fullname="G. Shepherd">
he terms used in the DNS in a single document.</t><t>This document obsoletes RFC <organization showOnFrontPage="true"/>
7719 and updates RFC 2308.</t></abstract> </author>
</front> <date year="2017" month="March"/>
<seriesInfo name='BCP' value='219'/> <abstract>
<seriesInfo name='RFC' value='8499'/> <t>The User Datagram Protocol (UDP) provides a minimal message-pas
<seriesInfo name='DOI' value='10.17487/RFC8499'/> sing transport that has no inherent congestion control mechanisms. This documen
</reference> t provides guidelines on the use of UDP for the designers of applications, tunne
ls, and other protocols that use UDP. Congestion control guidelines are a prima
</references> ry focus, but the document also provides guidance on other topics, including mes
sage sizes, reliability, checksums, middlebox traversal, the use of Explicit Con
<references title='Informative References'> gestion Notification (ECN), Differentiated Services Code Points (DSCPs), and por
ts.</t>
<reference anchor="RFC2317" target='https://www.rfc-editor.org/info/rfc2317'> <t>Because congestion control is critical to the stable operation
<front> of the Internet, applications and other protocols that choose to use UDP as an I
<title>Classless IN-ADDR.ARPA delegation</title> nternet transport must employ mechanisms to prevent congestion collapse and to e
<author initials='H.' surname='Eidnes' fullname='H. Eidnes'><organization /></au stablish some degree of fairness with concurrent traffic. They may also need to
thor> implement additional mechanisms, depending on how they use UDP.</t>
<author initials='G.' surname='de Groot' fullname='G. de Groot'><organization /> <t>Some guidance is also applicable to the design of other protoco
</author> ls (e.g., protocols layered directly on IP or via IP-based tunnels), especially
<author initials='P.' surname='Vixie' fullname='P. Vixie'><organization /></auth when these protocols do not themselves provide congestion control.</t>
or> <t>This document obsoletes RFC 5405 and adds guidelines for multic
<date year='1998' month='March' /> ast UDP usage.</t>
<abstract><t>This document describes a way to do IN-ADDR.ARPA delegation on non- </abstract>
octet boundaries for address spaces covering fewer than 256 addresses. This doc </front>
ument specifies an Internet Best Current Practices for the Internet Community, a <seriesInfo name="BCP" value="145"/>
nd requests discussion and suggestions for improvements.</t></abstract> <seriesInfo name="RFC" value="8085"/>
</front> <seriesInfo name="DOI" value="10.17487/RFC8085"/>
<seriesInfo name='BCP' value='20'/> </reference>
<seriesInfo name='RFC' value='2317'/> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
<seriesInfo name='DOI' value='10.17487/RFC2317'/> 174" quoteTitle="true" derivedAnchor="RFC8174">
</reference> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
<reference anchor="RFC2845" target='https://www.rfc-editor.org/info/rfc2845'> tle>
<front> <author initials="B." surname="Leiba" fullname="B. Leiba">
<title>Secret Key Transaction Authentication for DNS (TSIG)</title> <organization showOnFrontPage="true"/>
<author initials='P.' surname='Vixie' fullname='P. Vixie'><organization /></auth </author>
or> <date year="2017" month="May"/>
<author initials='O.' surname='Gudmundsson' fullname='O. Gudmundsson'><organizat <abstract>
ion /></author> <t>RFC 2119 specifies common key words that may be used in protoco
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organiz l specifications. This document aims to reduce the ambiguity by clarifying tha
ation /></author> t only UPPERCASE usage of the key words have the defined special meanings.</t>
<author initials='B.' surname='Wellington' fullname='B. Wellington'><organizatio </abstract>
n /></author> </front>
<date year='2000' month='May' /> <seriesInfo name="BCP" value="14"/>
<abstract><t>This protocol allows for transaction level authentication using sha <seriesInfo name="RFC" value="8174"/>
red secrets and one way hashing. It can be used to authenticate dynamic updates <seriesInfo name="DOI" value="10.17487/RFC8174"/>
as coming from an approved client, or to authenticate responses as coming from </reference>
an approved recursive name server. [STANDARDS-TRACK]</t></abstract> <reference anchor="RFC8305" target="https://www.rfc-editor.org/info/rfc8
</front> 305" quoteTitle="true" derivedAnchor="RFC8305">
<seriesInfo name='RFC' value='2845'/> <front>
<seriesInfo name='DOI' value='10.17487/RFC2845'/> <title>Happy Eyeballs Version 2: Better Connectivity Using Concurren
</reference> cy</title>
<author initials="D." surname="Schinazi" fullname="D. Schinazi">
<reference anchor="RFC2931" target='https://www.rfc-editor.org/info/rfc2931'> <organization showOnFrontPage="true"/>
<front> </author>
<title>DNS Request and Transaction Signatures ( SIG(0)s )</title> <author initials="T." surname="Pauly" fullname="T. Pauly">
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organiz <organization showOnFrontPage="true"/>
ation /></author> </author>
<date year='2000' month='September' /> <date year="2017" month="December"/>
<abstract><t>This document describes the minor but non-interoperable changes in <abstract>
Request and Transaction signature resource records ( SIG(0)s ) that implementati <t>Many communication protocols operating over the modern Internet
on experience has deemed necessary. [STANDARDS-TRACK]</t></abstract> use hostnames. These often resolve to multiple IP addresses, each of which may
</front> have different performance and connectivity characteristics. Since specific ad
<seriesInfo name='RFC' value='2931'/> dresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optima
<seriesInfo name='DOI' value='10.17487/RFC2931'/> l on a network, clients that attempt multiple connections in parallel have a cha
</reference> nce of establishing a connection more quickly. This document specifies requirem
ents for algorithms that reduce this user-visible delay and provides an example
<reference anchor="RFC3550" target='https://www.rfc-editor.org/info/rfc3550'> algorithm, referred to as "Happy Eyeballs". This document obsoletes the origina
<front> l algorithm description in RFC 6555.</t>
<title>RTP: A Transport Protocol for Real-Time Applications</title> </abstract>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organizat </front>
ion /></author> <seriesInfo name="RFC" value="8305"/>
<author initials='S.' surname='Casner' fullname='S. Casner'><organization /></au <seriesInfo name="DOI" value="10.17487/RFC8305"/>
thor> </reference>
<author initials='R.' surname='Frederick' fullname='R. Frederick'><organization <reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8
/></author> 499" quoteTitle="true" derivedAnchor="RFC8499">
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /> <front>
</author> <title>DNS Terminology</title>
<date year='2003' month='July' /> <author initials="P." surname="Hoffman" fullname="P. Hoffman">
<abstract><t>This memorandum describes RTP, the real-time transport protocol. R <organization showOnFrontPage="true"/>
TP provides end-to-end network transport functions suitable for applications tra </author>
nsmitting real-time data, such as audio, video or simulation data, over multicas <author initials="A." surname="Sullivan" fullname="A. Sullivan">
t or unicast network services. RTP does not address resource reservation and do <organization showOnFrontPage="true"/>
es not guarantee quality-of- service for real-time services. The data transport </author>
is augmented by a control protocol (RTCP) to allow monitoring of the data deliv <author initials="K." surname="Fujiwara" fullname="K. Fujiwara">
ery in a manner scalable to large multicast networks, and to provide minimal con <organization showOnFrontPage="true"/>
trol and identification functionality. RTP and RTCP are designed to be independ </author>
ent of the underlying transport and network layers. The protocol supports the u <date year="2019" month="January"/>
se of RTP-level translators and mixers. Most of the text in this memorandum is i <abstract>
dentical to RFC 1889 which it obsoletes. There are no changes in the packet for <t>The Domain Name System (DNS) is defined in literally dozens of
mats on the wire, only changes to the rules and algorithms governing how the pro different RFCs. The terminology used by implementers and developers of DNS prot
tocol is used. The biggest change is an enhancement to the scalable timer algori ocols, and by operators of DNS systems, has sometimes changed in the decades sin
thm for calculating when to send RTCP packets in order to minimize transmission ce the DNS was first defined. This document gives current definitions for many
in excess of the intended rate when many participants join a session simultaneou of the terms used in the DNS in a single document.</t>
sly. [STANDARDS-TRACK]</t></abstract> <t>This document obsoletes RFC 7719 and updates RFC 2308.</t>
</front> </abstract>
<seriesInfo name='STD' value='64'/> </front>
<seriesInfo name='RFC' value='3550'/> <seriesInfo name="BCP" value="219"/>
<seriesInfo name='DOI' value='10.17487/RFC3550'/> <seriesInfo name="RFC" value="8499"/>
</reference> <seriesInfo name="DOI" value="10.17487/RFC8499"/>
</reference>
<reference anchor="RFC4025" target='https://www.rfc-editor.org/info/rfc4025'> </references>
<front> <references pn="section-7.2">
<title>A Method for Storing IPsec Keying Material in DNS</title> <name slugifiedName="name-informative-references">Informative References
<author initials='M.' surname='Richardson' fullname='M. Richardson'><organizatio </name>
n /></author> <reference anchor="RFC2317" target="https://www.rfc-editor.org/info/rfc2
<date year='2005' month='March' /> 317" quoteTitle="true" derivedAnchor="RFC2317">
<abstract><t>This document describes a new resource record for the Domain Name S <front>
ystem (DNS). This record may be used to store public keys for use in IP securit <title>Classless IN-ADDR.ARPA delegation</title>
y (IPsec) systems. The record also includes provisions for indicating what syst <author initials="H." surname="Eidnes" fullname="H. Eidnes">
em should be contacted when an IPsec tunnel is established with the entity in qu <organization showOnFrontPage="true"/>
estion. </t><t> This record replaces the functionality of the sub-type #4 of the </author>
KEY Resource Record, which has been obsoleted by RFC 3445. [STANDARDS-TRACK]</ <author initials="G." surname="de Groot" fullname="G. de Groot">
t></abstract> <organization showOnFrontPage="true"/>
</front> </author>
<seriesInfo name='RFC' value='4025'/> <author initials="P." surname="Vixie" fullname="P. Vixie">
<seriesInfo name='DOI' value='10.17487/RFC4025'/> <organization showOnFrontPage="true"/>
</reference> </author>
<date year="1998" month="March"/>
<reference anchor="RFC4301" target='https://www.rfc-editor.org/info/rfc4301'> <abstract>
<front> <t>This document describes a way to do IN-ADDR.ARPA delegation on
<title>Security Architecture for the Internet Protocol</title> non-octet boundaries for address spaces covering fewer than 256 addresses. This
<author initials='S.' surname='Kent' fullname='S. Kent'><organization /></author document specifies an Internet Best Current Practices for the Internet Communit
> y, and requests discussion and suggestions for improvements.</t>
<author initials='K.' surname='Seo' fullname='K. Seo'><organization /></author> </abstract>
<date year='2005' month='December' /> </front>
<abstract><t>This document describes an updated version of the &quot;Security Ar <seriesInfo name="BCP" value="20"/>
chitecture for IP&quot;, which is designed to provide security services for traf <seriesInfo name="RFC" value="2317"/>
fic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDA <seriesInfo name="DOI" value="10.17487/RFC2317"/>
RDS-TRACK]</t></abstract> </reference>
</front> <reference anchor="RFC2845" target="https://www.rfc-editor.org/info/rfc2
<seriesInfo name='RFC' value='4301'/> 845" quoteTitle="true" derivedAnchor="RFC2845">
<seriesInfo name='DOI' value='10.17487/RFC4301'/> <front>
</reference> <title>Secret Key Transaction Authentication for DNS (TSIG)</title>
<author initials="P." surname="Vixie" fullname="P. Vixie">
<reference anchor="RFC4787" target='https://www.rfc-editor.org/info/rfc4787'> <organization showOnFrontPage="true"/>
<front> </author>
<title>Network Address Translation (NAT) Behavioral Requirements for Unicast UDP <author initials="O." surname="Gudmundsson" fullname="O. Gudmundsson
</title> ">
<author initials='F.' surname='Audet' fullname='F. Audet' role='editor'><organiz <organization showOnFrontPage="true"/>
ation /></author> </author>
<author initials='C.' surname='Jennings' fullname='C. Jennings'><organization /> <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3
</author> rd">
<date year='2007' month='January' /> <organization showOnFrontPage="true"/>
<abstract><t>This document defines basic terminology for describing different ty </author>
pes of Network Address Translation (NAT) behavior when handling Unicast UDP and <author initials="B." surname="Wellington" fullname="B. Wellington">
also defines a set of requirements that would allow many applications, such as m <organization showOnFrontPage="true"/>
ultimedia communications or online gaming, to work consistently. Developing NAT </author>
s that meet this set of requirements will greatly increase the likelihood that t <date year="2000" month="May"/>
hese applications will function properly. This document specifies an Internet B <abstract>
est Current Practices for the Internet Community, and requests discussion and su <t>This protocol allows for transaction level authentication using
ggestions for improvements.</t></abstract> shared secrets and one way hashing. It can be used to authenticate dynamic upd
</front> ates as coming from an approved client, or to authenticate responses as coming f
<seriesInfo name='BCP' value='127'/> rom an approved recursive name server. [STANDARDS-TRACK]</t>
<seriesInfo name='RFC' value='4787'/> </abstract>
<seriesInfo name='DOI' value='10.17487/RFC4787'/> </front>
</reference> <seriesInfo name="RFC" value="2845"/>
<seriesInfo name="DOI" value="10.17487/RFC2845"/>
<reference anchor="RFC5110" target='https://www.rfc-editor.org/info/rfc5110'> </reference>
<front> <reference anchor="RFC2931" target="https://www.rfc-editor.org/info/rfc2
<title>Overview of the Internet Multicast Routing Architecture</title> 931" quoteTitle="true" derivedAnchor="RFC2931">
<author initials='P.' surname='Savola' fullname='P. Savola'><organization /></au <front>
thor> <title>DNS Request and Transaction Signatures ( SIG(0)s )</title>
<date year='2008' month='January' /> <author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3
<abstract><t>This document describes multicast routing architectures that are cu rd">
rrently deployed on the Internet. This document briefly describes those protoco <organization showOnFrontPage="true"/>
ls and references their specifications.</t><t>This memo also reclassifies severa </author>
l older RFCs to Historic. These RFCs describe multicast routing protocols that <date year="2000" month="September"/>
were never widely deployed or have fallen into disuse. This memo provides infor <abstract>
mation for the Internet community.</t></abstract> <t>This document describes the minor but non-interoperable changes
</front> in Request and Transaction signature resource records ( SIG(0)s ) that implemen
<seriesInfo name='RFC' value='5110'/> tation experience has deemed necessary. [STANDARDS-TRACK]</t>
<seriesInfo name='DOI' value='10.17487/RFC5110'/> </abstract>
</reference> </front>
<seriesInfo name="RFC" value="2931"/>
<reference anchor="RFC6726" target='https://www.rfc-editor.org/info/rfc6726'> <seriesInfo name="DOI" value="10.17487/RFC2931"/>
<front> </reference>
<title>FLUTE - File Delivery over Unidirectional Transport</title> <reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3
<author initials='T.' surname='Paila' fullname='T. Paila'><organization /></auth 550" quoteTitle="true" derivedAnchor="RFC3550">
or> <front>
<author initials='R.' surname='Walsh' fullname='R. Walsh'><organization /></auth <title>RTP: A Transport Protocol for Real-Time Applications</title>
or> <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
<author initials='M.' surname='Luby' fullname='M. Luby'><organization /></author ">
> <organization showOnFrontPage="true"/>
<author initials='V.' surname='Roca' fullname='V. Roca'><organization /></author </author>
> <author initials="S." surname="Casner" fullname="S. Casner">
<author initials='R.' surname='Lehtonen' fullname='R. Lehtonen'><organization /> <organization showOnFrontPage="true"/>
</author> </author>
<date year='2012' month='November' /> <author initials="R." surname="Frederick" fullname="R. Frederick">
<abstract><t>This document defines File Delivery over Unidirectional Transport ( <organization showOnFrontPage="true"/>
FLUTE), a protocol for the unidirectional delivery of files over the Internet, w </author>
hich is particularly suited to multicast networks. The specification builds on <author initials="V." surname="Jacobson" fullname="V. Jacobson">
Asynchronous Layered Coding, the base protocol designed for massively scalable m <organization showOnFrontPage="true"/>
ulticast distribution. This document obsoletes RFC 3926. [STANDARDS-TRACK]</t>< </author>
/abstract> <date year="2003" month="July"/>
</front> <abstract>
<seriesInfo name='RFC' value='6726'/> <t>This memorandum describes RTP, the real-time transport protocol
<seriesInfo name='DOI' value='10.17487/RFC6726'/> . RTP provides end-to-end network transport functions suitable for applications
</reference> transmitting real-time data, such as audio, video or simulation data, over mult
icast or unicast network services. RTP does not address resource reservation an
<reference anchor="RFC7359" target='https://www.rfc-editor.org/info/rfc7359'> d does not guarantee quality-of- service for real-time services. The data trans
<front> port is augmented by a control protocol (RTCP) to allow monitoring of the data d
<title>Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Sta elivery in a manner scalable to large multicast networks, and to provide minimal
ck Hosts/Networks</title> control and identification functionality. RTP and RTCP are designed to be inde
<author initials='F.' surname='Gont' fullname='F. Gont'><organization /></author pendent of the underlying transport and network layers. The protocol supports t
> he use of RTP-level translators and mixers. Most of the text in this memorandum
<date year='2014' month='August' /> is identical to RFC 1889 which it obsoletes. There are no changes in the packet
<abstract><t>The subtle way in which the IPv6 and IPv4 protocols coexist in typi formats on the wire, only changes to the rules and algorithms governing how the
cal networks, together with the lack of proper IPv6 support in popular Virtual P protocol is used. The biggest change is an enhancement to the scalable timer al
rivate Network (VPN) tunnel products, may inadvertently result in VPN tunnel tra gorithm for calculating when to send RTCP packets in order to minimize transmiss
ffic leakages. That is, traffic meant to be transferred over an encrypted and i ion in excess of the intended rate when many participants join a session simulta
ntegrity- protected VPN tunnel may leak out of such a tunnel and be sent in the neously. [STANDARDS-TRACK]</t>
clear on the local network towards the final destination. This document discuss </abstract>
es some scenarios in which such VPN tunnel traffic leakages may occur as a resul </front>
t of employing IPv6-unaware VPN software. Additionally, this document offers po <seriesInfo name="STD" value="64"/>
ssible mitigations for this issue.</t></abstract> <seriesInfo name="RFC" value="3550"/>
</front> <seriesInfo name="DOI" value="10.17487/RFC3550"/>
<seriesInfo name='RFC' value='7359'/> </reference>
<seriesInfo name='DOI' value='10.17487/RFC7359'/> <reference anchor="RFC4025" target="https://www.rfc-editor.org/info/rfc4
</reference> 025" quoteTitle="true" derivedAnchor="RFC4025">
<front>
<reference anchor="RFC7761" target='https://www.rfc-editor.org/info/rfc7761'> <title>A Method for Storing IPsec Keying Material in DNS</title>
<front> <author initials="M." surname="Richardson" fullname="M. Richardson">
<title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specifica <organization showOnFrontPage="true"/>
tion (Revised)</title> </author>
<author initials='B.' surname='Fenner' fullname='B. Fenner'><organization /></au <date year="2005" month="March"/>
thor> <abstract>
<author initials='M.' surname='Handley' fullname='M. Handley'><organization /></ <t>This document describes a new resource record for the Domain Na
author> me System (DNS). This record may be used to store public keys for use in IP sec
<author initials='H.' surname='Holbrook' fullname='H. Holbrook'><organization /> urity (IPsec) systems. The record also includes provisions for indicating what
</author> system should be contacted when an IPsec tunnel is established with the entity i
<author initials='I.' surname='Kouvelas' fullname='I. Kouvelas'><organization /> n question. </t>
</author> <t> This record replaces the functionality of the sub-type #4 of t
<author initials='R.' surname='Parekh' fullname='R. Parekh'><organization /></au he KEY Resource Record, which has been obsoleted by RFC 3445. [STANDARDS-TRACK]
thor> </t>
<author initials='Z.' surname='Zhang' fullname='Z. Zhang'><organization /></auth </abstract>
or> </front>
<author initials='L.' surname='Zheng' fullname='L. Zheng'><organization /></auth <seriesInfo name="RFC" value="4025"/>
or> <seriesInfo name="DOI" value="10.17487/RFC4025"/>
<date year='2016' month='March' /> </reference>
<abstract><t>This document specifies Protocol Independent Multicast - Sparse Mod <reference anchor="RFC4301" target="https://www.rfc-editor.org/info/rfc4
e (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying 301" quoteTitle="true" derivedAnchor="RFC4301">
unicast routing information base or a separate multicast-capable routing informa <front>
tion base. It builds unidirectional shared trees rooted at a Rendezvous Point ( <title>Security Architecture for the Internet Protocol</title>
RP) per group, and it optionally creates shortest-path trees per source.</t><t>T <author initials="S." surname="Kent" fullname="S. Kent">
his document obsoletes RFC 4601 by replacing it, addresses the errata filed agai <organization showOnFrontPage="true"/>
nst it, removes the optional (*,*,RP), PIM Multicast Border Router features and </author>
authentication using IPsec that lack sufficient deployment experience (see Appen <author initials="K." surname="Seo" fullname="K. Seo">
dix A), and moves the PIM specification to Internet Standard.</t></abstract> <organization showOnFrontPage="true"/>
</front> </author>
<seriesInfo name='STD' value='83'/> <date year="2005" month="December"/>
<seriesInfo name='RFC' value='7761'/> <abstract>
<seriesInfo name='DOI' value='10.17487/RFC7761'/> <t>This document describes an updated version of the "Security Arc
</reference> hitecture for IP", which is designed to provide security services for traffic at
the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TR
<reference anchor="RFC7858" target='https://www.rfc-editor.org/info/rfc7858'> ACK]</t>
<front> </abstract>
<title>Specification for DNS over Transport Layer Security (TLS)</title> </front>
<author initials='Z.' surname='Hu' fullname='Z. Hu'><organization /></author> <seriesInfo name="RFC" value="4301"/>
<author initials='L.' surname='Zhu' fullname='L. Zhu'><organization /></author> <seriesInfo name="DOI" value="10.17487/RFC4301"/>
<author initials='J.' surname='Heidemann' fullname='J. Heidemann'><organization </reference>
/></author> <reference anchor="RFC4787" target="https://www.rfc-editor.org/info/rfc4
<author initials='A.' surname='Mankin' fullname='A. Mankin'><organization /></au 787" quoteTitle="true" derivedAnchor="RFC4787">
thor> <front>
<author initials='D.' surname='Wessels' fullname='D. Wessels'><organization /></ <title>Network Address Translation (NAT) Behavioral Requirements for
author> Unicast UDP</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></ <author initials="F." surname="Audet" fullname="F. Audet" role="edit
author> or">
<date year='2016' month='May' /> <organization showOnFrontPage="true"/>
<abstract><t>This document describes the use of Transport Layer Security (TLS) t </author>
o provide privacy for DNS. Encryption provided by TLS eliminates opportunities <author initials="C." surname="Jennings" fullname="C. Jennings">
for eavesdropping and on-path tampering with DNS queries in the network, such as <organization showOnFrontPage="true"/>
discussed in RFC 7626. In addition, this document specifies two usage profiles </author>
for DNS over TLS and provides advice on performance considerations to minimize <date year="2007" month="January"/>
overhead from using TCP and TLS with DNS.</t><t>This document focuses on securin <abstract>
g stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It <t>This document defines basic terminology for describing differen
does not prevent future applications of the protocol to recursive-to-authoritat t types of Network Address Translation (NAT) behavior when handling Unicast UDP
ive traffic.</t></abstract> and also defines a set of requirements that would allow many applications, such
</front> as multimedia communications or online gaming, to work consistently. Developing
<seriesInfo name='RFC' value='7858'/> NATs that meet this set of requirements will greatly increase the likelihood th
<seriesInfo name='DOI' value='10.17487/RFC7858'/> at these applications will function properly. This document specifies an Intern
</reference> et Best Current Practices for the Internet Community, and requests discussion an
d suggestions for improvements.</t>
<reference anchor="RFC8126" target='https://www.rfc-editor.org/info/rfc8126'> </abstract>
<front> </front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <seriesInfo name="BCP" value="127"/>
<author initials='M.' surname='Cotton' fullname='M. Cotton'><organization /></au <seriesInfo name="RFC" value="4787"/>
thor> <seriesInfo name="DOI" value="10.17487/RFC4787"/>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth </reference>
or> <reference anchor="RFC5110" target="https://www.rfc-editor.org/info/rfc5
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></au 110" quoteTitle="true" derivedAnchor="RFC5110">
thor> <front>
<date year='2017' month='June' /> <title>Overview of the Internet Multicast Routing Architecture</titl
<abstract><t>Many protocols make use of points of extensibility that use constan e>
ts to identify various protocol parameters. To ensure that the values in these <author initials="P." surname="Savola" fullname="P. Savola">
fields do not have conflicting uses and to promote interoperability, their alloc <organization showOnFrontPage="true"/>
ations are often coordinated by a central record keeper. For IETF protocols, th </author>
at role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To ma <date year="2008" month="January"/>
ke assignments in a given registry prudently, guidance describing the conditions <abstract>
under which new values should be assigned, as well as when and how modification <t>This document describes multicast routing architectures that ar
s to existing values can be made, is needed. This document defines a framework e currently deployed on the Internet. This document briefly describes those pro
for the documentation of these guidelines by specification authors, in order to tocols and references their specifications.</t>
assure that the provided guidance for the IANA Considerations is clear and addre <t>This memo also reclassifies several older RFCs to Historic. Th
sses the various issues that are likely in the operation of a registry.</t><t>Th ese RFCs describe multicast routing protocols that were never widely deployed or
is is the third edition of this document; it obsoletes RFC 5226.</t></abstract> have fallen into disuse. This memo provides information for the Internet commu
</front> nity.</t>
<seriesInfo name='BCP' value='26'/> </abstract>
<seriesInfo name='RFC' value='8126'/> </front>
<seriesInfo name='DOI' value='10.17487/RFC8126'/> <seriesInfo name="RFC" value="5110"/>
</reference> <seriesInfo name="DOI" value="10.17487/RFC5110"/>
</reference>
<reference anchor="RFC8313" target='https://www.rfc-editor.org/info/rfc8313'> <reference anchor="RFC6726" target="https://www.rfc-editor.org/info/rfc6
<front> 726" quoteTitle="true" derivedAnchor="RFC6726">
<title>Use of Multicast across Inter-domain Peering Points</title> <front>
<author initials='P.' surname='Tarapore' fullname='P. Tarapore' role='editor'><o <title>FLUTE - File Delivery over Unidirectional Transport</title>
rganization /></author> <author initials="T." surname="Paila" fullname="T. Paila">
<author initials='R.' surname='Sayko' fullname='R. Sayko'><organization /></auth <organization showOnFrontPage="true"/>
or> </author>
<author initials='G.' surname='Shepherd' fullname='G. Shepherd'><organization /> <author initials="R." surname="Walsh" fullname="R. Walsh">
</author> <organization showOnFrontPage="true"/>
<author initials='T.' surname='Eckert' fullname='T. Eckert' role='editor'><organ </author>
ization /></author> <author initials="M." surname="Luby" fullname="M. Luby">
<author initials='R.' surname='Krishnan' fullname='R. Krishnan'><organization /> <organization showOnFrontPage="true"/>
</author> </author>
<date year='2018' month='January' /> <author initials="V." surname="Roca" fullname="V. Roca">
<abstract><t>This document examines the use of Source-Specific Multicast (SSM) a <organization showOnFrontPage="true"/>
cross inter-domain peering points for a specified set of deployment scenarios. </author>
The objectives are to (1) describe the setup process for multicast-based deliver <author initials="R." surname="Lehtonen" fullname="R. Lehtonen">
y across administrative domains for these scenarios and (2) document supporting <organization showOnFrontPage="true"/>
functionality to enable this process.</t></abstract> </author>
</front> <date year="2012" month="November"/>
<seriesInfo name='BCP' value='213'/> <abstract>
<seriesInfo name='RFC' value='8313'/> <t>This document defines File Delivery over Unidirectional Transpo
<seriesInfo name='DOI' value='10.17487/RFC8313'/> rt (FLUTE), a protocol for the unidirectional delivery of files over the Interne
</reference> t, which is particularly suited to multicast networks. The specification builds
on Asynchronous Layered Coding, the base protocol designed for massively scalab
<reference anchor="RFC8484" target='https://www.rfc-editor.org/info/rfc8484'> le multicast distribution. This document obsoletes RFC 3926. [STANDARDS-TRACK]<
<front> /t>
<title>DNS Queries over HTTPS (DoH)</title> </abstract>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></ </front>
author> <seriesInfo name="RFC" value="6726"/>
<author initials='P.' surname='McManus' fullname='P. McManus'><organization /></ <seriesInfo name="DOI" value="10.17487/RFC6726"/>
author> </reference>
<date year='2018' month='October' /> <reference anchor="RFC7359" target="https://www.rfc-editor.org/info/rfc7
<abstract><t>This document defines a protocol for sending DNS queries and gettin 359" quoteTitle="true" derivedAnchor="RFC7359">
g DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP <front>
exchange.</t></abstract> <title>Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages
</front> in Dual-Stack Hosts/Networks</title>
<seriesInfo name='RFC' value='8484'/> <author initials="F." surname="Gont" fullname="F. Gont">
<seriesInfo name='DOI' value='10.17487/RFC8484'/> <organization showOnFrontPage="true"/>
</reference> </author>
<date year="2014" month="August"/>
<abstract>
<t>The subtle way in which the IPv6 and IPv4 protocols coexist in
typical networks, together with the lack of proper IPv6 support in popular Virtu
al Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel
traffic leakages. That is, traffic meant to be transferred over an encrypted a
nd integrity- protected VPN tunnel may leak out of such a tunnel and be sent in
the clear on the local network towards the final destination. This document dis
cusses some scenarios in which such VPN tunnel traffic leakages may occur as a r
esult of employing IPv6-unaware VPN software. Additionally, this document offer
s possible mitigations for this issue.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7359"/>
<seriesInfo name="DOI" value="10.17487/RFC7359"/>
</reference>
<reference anchor="RFC7761" target="https://www.rfc-editor.org/info/rfc7
761" quoteTitle="true" derivedAnchor="RFC7761">
<front>
<title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protoc
ol Specification (Revised)</title>
<author initials="B." surname="Fenner" fullname="B. Fenner">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization showOnFrontPage="true"/>
</author>
<author initials="H." surname="Holbrook" fullname="H. Holbrook">
<organization showOnFrontPage="true"/>
</author>
<author initials="I." surname="Kouvelas" fullname="I. Kouvelas">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Parekh" fullname="R. Parekh">
<organization showOnFrontPage="true"/>
</author>
<author initials="Z." surname="Zhang" fullname="Z. Zhang">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Zheng" fullname="L. Zheng">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="March"/>
<abstract>
<t>This document specifies Protocol Independent Multicast - Sparse
Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underly
ing unicast routing information base or a separate multicast-capable routing inf
ormation base. It builds unidirectional shared trees rooted at a Rendezvous Poi
nt (RP) per group, and it optionally creates shortest-path trees per source.</t>
<t>This document obsoletes RFC 4601 by replacing it, addresses the
errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Ro
uter features and authentication using IPsec that lack sufficient deployment exp
erience (see Appendix A), and moves the PIM specification to Internet Standard.<
/t>
</abstract>
</front>
<seriesInfo name="STD" value="83"/>
<seriesInfo name="RFC" value="7761"/>
<seriesInfo name="DOI" value="10.17487/RFC7761"/>
</reference>
<reference anchor="RFC7858" target="https://www.rfc-editor.org/info/rfc7
858" quoteTitle="true" derivedAnchor="RFC7858">
<front>
<title>Specification for DNS over Transport Layer Security (TLS)</ti
tle>
<author initials="Z." surname="Hu" fullname="Z. Hu">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Zhu" fullname="L. Zhu">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Heidemann" fullname="J. Heidemann">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Mankin" fullname="A. Mankin">
<organization showOnFrontPage="true"/>
</author>
<author initials="D." surname="Wessels" fullname="D. Wessels">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization showOnFrontPage="true"/>
</author>
<date year="2016" month="May"/>
<abstract>
<t>This document describes the use of Transport Layer Security (TL
S) to provide privacy for DNS. Encryption provided by TLS eliminates opportunit
ies for eavesdropping and on-path tampering with DNS queries in the network, suc
h as discussed in RFC 7626. In addition, this document specifies two usage prof
iles for DNS over TLS and provides advice on performance considerations to minim
ize overhead from using TCP and TLS with DNS.</t>
<t>This document focuses on securing stub-to-recursive traffic, as
per the charter of the DPRIVE Working Group. It does not prevent future applic
ations of the protocol to recursive-to-authoritative traffic.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7858"/>
<seriesInfo name="DOI" value="10.17487/RFC7858"/>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126" quoteTitle="true" derivedAnchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author initials="M." surname="Cotton" fullname="M. Cotton">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="June"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in th
ese fields do not have conflicting uses and to promote interoperability, their a
llocations are often coordinated by a central record keeper. For IETF protocols
, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This documen
t defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Considerati
ons is clear and addresses the various issues that are likely in the operation o
f a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC8313" target="https://www.rfc-editor.org/info/rfc8
313" quoteTitle="true" derivedAnchor="RFC8313">
<front>
<title>Use of Multicast across Inter-domain Peering Points</title>
<author initials="P." surname="Tarapore" fullname="P. Tarapore" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Sayko" fullname="R. Sayko">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Shepherd" fullname="G. Shepherd">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Eckert" fullname="T. Eckert" role="ed
itor">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Krishnan" fullname="R. Krishnan">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="January"/>
<abstract>
<t>This document examines the use of Source-Specific Multicast (SS
M) across inter-domain peering points for a specified set of deployment scenario
s. The objectives are to (1) describe the setup process for multicast-based del
ivery across administrative domains for these scenarios and (2) document support
ing functionality to enable this process.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="213"/>
<seriesInfo name="RFC" value="8313"/>
<seriesInfo name="DOI" value="10.17487/RFC8313"/>
</reference>
<reference anchor="RFC8484" target="https://www.rfc-editor.org/info/rfc8
484" quoteTitle="true" derivedAnchor="RFC8484">
<front>
<title>DNS Queries over HTTPS (DoH)</title>
<author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="McManus" fullname="P. McManus">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="October"/>
<abstract>
<t>This document defines a protocol for sending DNS queries and ge
tting DNS responses over HTTPS. Each DNS query-response pair is mapped into an
HTTP exchange.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8484"/>
<seriesInfo name="DOI" value="10.17487/RFC8484"/>
</reference>
</references>
</references> </references>
<section anchor="extranslate" numbered="true" toc="include" removeInRFC="fal
<section anchor="extranslate" title="Unknown RRType construction"> se" pn="section-appendix.a">
<name slugifiedName="name-unknown-rrtype-construction">Unknown RRType Cons
<t>In a DNS resolver that understands the AMTRELAY type, the zone file might truction</name>
<t pn="section-appendix.a-1">In a DNS resolver that understands the AMTREL
AY type, the zone file might
contain this line:</t> contain this line:</t>
<sourcecode name="" type="" markers="false" pn="section-appendix.a-2">
<figure><artwork><![CDATA[
IN AMTRELAY 128 0 3 amtrelays.example.com. IN AMTRELAY 128 0 3 amtrelays.example.com.
]]></artwork></figure> </sourcecode>
<t pn="section-appendix.a-3">In order to translate this example to appear
<t>In order to translate this example to appear as an unknown RRType as an unknown RRType
as defined in <xref target="RFC3597"/>, one could run the following program:</t> as defined in <xref target="RFC3597" format="default" sectionFormat="of" derived
Content="RFC3597"/>, one could run the following program:</t>
<figure><artwork><![CDATA[ <sourcecode name="" type="python" markers="true" pn="section-appendix.a-4"
<CODE BEGINS> >
$ cat translate.py $ cat translate.py
#!/usr/bin/env python3 #!/usr/bin/env python3
import sys import sys
name=sys.argv[1] name=sys.argv[1]
wire='' wire=''
for dn in name.split('.'): for dn in name.split('.'):
if len(dn) > 0: if len(dn) &gt; 0:
wire += ('%02x' % len(dn)) wire += ('%02x' % len(dn))
wire += (''.join('%02x'%ord(x) for x in dn)) wire += (''.join('%02x'%ord(x) for x in dn))
print(len(wire)//2) + 2 print(len(wire)//2) + 2
print(wire) print(wire)
$ ./translate.py amtrelays.example.com $ ./translate.py amtrelays.example.com
24 24
09616d7472656c617973076578616d706c6503636f6d 09616d7472656c617973076578616d706c6503636f6d
<CODE ENDS> </sourcecode>
]]></artwork></figure> <t pn="section-appendix.a-5">The length of the RData and the hex string fo
r the domain name
<t>The length of the RData and the hex string for the domain name "amtrelays.example.com" are the outputs of this program.</t>
“amtrelays.example.com” are the outputs of this program.</t> <t pn="section-appendix.a-6">The length of the wire-encoded domain name is
22, so 2 was added to
<t>22 is the length of the wire-encoded domain name, so 2 was added to
that value (1 for the precedence field and 1 for the combined D-bit and that value (1 for the precedence field and 1 for the combined D-bit and
relay type fields) to get the full length 24 of the RData. For the 2 relay type fields) to get the full length 24 of the RData. For the 2
octets ahead of the domain name, we encode the precedence, D-bit, and octets ahead of the domain name, we encode the precedence, D-bit, and
relay type fields, as described in <xref target="rrdef"/>.</t> relay type fields, as described in <xref target="rrdef" format="default" section
Format="of" derivedContent="Section 4"/>.</t>
<t>This results in a zone file entry like this:</t> <t pn="section-appendix.a-7">This results in a zone file entry like this:<
/t>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt="" pn="section-appendix.a-8">
IN TYPE260 \# ( 24 ; length IN TYPE260 \# ( 24 ; length
80 ; precedence = 128 80 ; precedence = 128
03 ; D-bit=0, relay type=3 (wire-encoded domain name) 03 ; D-bit=0, relay type=3 (wire-encoded domain name)
09616d7472656c617973076578616d706c6503636f6d ) ; domain name 09616d7472656c617973076578616d706c6503636f6d ) ; domain name
]]></artwork></figure> </artwork>
</section>
</section> <section anchor="acknowledgements" numbered="false" toc="include" removeInRF
C="false" pn="section-appendix.b">
<name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t pn="section-appendix.b-1">This specification was inspired by the previo
us work of <contact fullname="Doug Nortz"/>, <contact fullname="Robert Sayko"/>,
<contact fullname="David Segelstein"/>, and <contact fullname="Percy Tarapore"/
>, presented in
the MBONED Working Group at IETF 93.</t>
<t pn="section-appendix.b-2">Thanks to <contact fullname="Jeff Goldsmith"/
>, <contact fullname="Toerless Eckert"/>, <contact fullname="Mikael Abrahamsson"
/>, <contact fullname="Lenny Giuliano"/>, <contact fullname="Mark Andrews"/>, <c
ontact fullname="Sandy Zheng"/>, <contact fullname="Kyle Rose"/>, <contact fulln
ame="Ben Kaduk"/>,
<contact fullname="Bill Atwood"/>, <contact fullname="Tim Chown"/>, <conta
ct fullname="Christian Worm Mortensen"/>, <contact fullname="Warren Kumari"/>, <
contact fullname="Dan Romanescu"/>, <contact fullname="Bernard Aboba"/>, <contac
t fullname="Carlos Pignataro"/>, <contact fullname="Niclas Comstedt"/>, <contact
fullname="Mirja Kühlewind"/>, <contact fullname="Henning Rogge"/>, <contact ful
lname="Eric Vyncke"/>, <contact fullname="Barry Lieba"/>,
<contact fullname="Roman Danyliw"/>, <contact fullname="Alissa Cooper"/>,
<contact fullname="Suresh Krishnan"/>, <contact fullname="Adam Roach"/>,
and <contact fullname="Daniel Franke"/> for their very helpful reviews and comme
nts.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.c">
<name slugifiedName="name-authors-address">Author's Address</name>
<author initials="J." surname="Holland" fullname="Jake Holland">
<organization showOnFrontPage="true">Akamai Technologies, Inc.</organiza
tion>
<address>
<postal>
<street>150 Broadway</street>
<city>Cambridge</city>
<region>MA</region>
<code>02144</code>
<country>United States of America</country>
</postal>
<email>jakeholland.net@gmail.com</email>
</address>
</author>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAISyF14AA+19W3fbyJXue/2KOtLMamlM0SR1sayMs47asruVWLYjqZOV
SSdZIAlKiEmAA4CS2bbzfv7TeZs/dva1LgAouZOel7OGPRlTBFCoy659+fal
9vb2TJ3V8/TEnr29spfpXVpWqT1/b08vru3O6aouFkmdTezFag7/JFVtr1d5
ns6z/GbXnmXVpIAn1iYZj8v0Dhq5PD89M9NikicLaHNaJrN6L0vr2d5iXOTp
dG9aZsl0L1nUe1N9eG+4b6ZJDbePBsPne8PR3mhgJvDDTVGuT2xVT43JluWJ
rctVVY8Gg+eDkUnKNDmx75aVuS/KDzdlsVqe2At6h/mQruHH6Yk9z+u0zNN6
7wz7YUxVJ/n0r8kc7jqx67Qyy+zE/qkuJj1bFWVdprMKvq0X+OXPxiSr+rYo
T4zdMxY+WV6d2N/07ffFfA7t0G88zN8kH9Lo56K8ObGnH5JFktnrdHKbF/Pi
Jkuh9fN80qdbKnhdWp/Y4eHAflsWyfQ+WdOFSVbDqF8mi3GZTW/Snr04tYPR
8OCArxarvMZp+SHP6nRqr2qYqMoWM3u6SEtYIborhRfPT+zfoF+33K0+TMP/
vsGf+5NiYcxqiVMOA3p2cDgwJi9KXOe7FEZrL1+/HA72D/zXQ/k6Gg6fu6/H
Q/367HgkX/f3nx3p18Pnwddn+vV4OJCvB0eDA/9Vbzh6NjpwX4/25St2Ur4e
D461O8f7A/d1+EwfOz54Dp00WT5rjGm0P9S3jI4P3Jie7w9dP91bDgYjveFg
f6A3HDw71hYOh24g0GUd6TMYqn59dqSPPTs+PHb9dPce7w/3XZePofdmb2/P
JmMgjGQCxHp9m1UWdtJqkea1lfXCu2nJHtmbPSBB3MK7drw2i2Kazdbwq61v
U1um82Rt3e6zy7KYpFXVt/bU5uk98YEyrYpVOcGbJ7CTiMynBtq7fPXm9I8W
O5bOMthrFibZLlfjeVbd4guQa9ALKrrCrexVy3SSzaCnC+2pmdwm2FV87TV1
yjEefP9PsEOpgcQ/Yqs0n6blNxXelEyn0McKemImRT7LblYldKYu7Aoacf1s
DKPCG5IpvKnO4LYEWqxp57hOm/o2qe0kyfGJFEjHwtbBjtwnMAu+K7BEMxzP
rCwWlp7hzlmcUngGmzQ1LQYM8B1Me2nTj3WaV1mRV9ToZJ6UOCewgvgT9Kxj
cYwsjgV2Z5N5Vei895laFtl0Ok+N2QZOVxbT1QQbs/L5tJ3hr1+apMRNVF0M
3zF0u0OcfLeHK5DiYmXVAicCicDeACne4xpDr7Wv4dLTjGCXJ8kyGc9TnGSZ
RCQSTwXRPCb2Q17c50I0wSrDYL9GGgVUmeX20yfhG1++9GjCYSrvsikwfRwR
MHYiF+hAXi2B93csLq+lXeXyM72ph20DLcGlusD+8/zlRb7nWtjTYQPPRekE
xHGDM48DuUp5jQ76w/4hzkvQTyCR5TzJcplATw9VOpfHhB7MjLc3jhkWGWmP
hjNO7aKAeZ/N048Z9gAayqmhZQJEP1kB0QVbn+fBwKRMymzM80avVlrhmZut
SqHgZvfaHVtkN7c1DJz7M02X0DdbcB9kYWHQ+Fd7wjNc+0UK/VnOizXNGIjj
LJ/gXuWZWIAGgKOk6YUX6DbduDWxtSpD5iBvD5bPbeys7uMmoW3Mw7kpUKjm
eFO1urlJoWHYLnvjpIKW/nMFkhauJ/B/dllUFU11VcxX+Gzf0NbBpUmCh/Ry
Dx+TNnGSYGJTYoJwv95DW90I9adVJ9vOqmqVVrxiqd2CnQucLcnrBBressCP
a7oo9Gb2+/uO2lDyALXh0io57vcPGpdpRlKYiGROnNgNCqYkzWn+/aQDD86x
pTvQXWB56vs0hbVMgeiAUxi/MfjBqW6Myt7fwo15mhF9MUXlxCNAIZFh4wLT
L/yMgS7I65jGAhHh2h8nkw+oC/bsPTRdrGqgz3RPJQW2luTAXNOUv5fABW5S
Yo7aeXy39rLf5KDEyqfd60IbYQriyEbbStfhsD/qh5PNOx/esL39LXQaFVnQ
IQ3LxATpFOkI1nrhdvgsWWTzDDYyjo36ABQGFI/8HIY4SZd1Fe9pehOqdMgL
9Y9DZYw07atxlQJd537v8zYXRRFvWvQCLjJfc0OoBzpiCXqMsuqxbmtnuRdp
uchIT16bMr0RUbFRgcBd1B4jKpJC2bj1URmAiT7/7uL93T7fgRqq3HHx5uxu
JL+CWgq/Ip2TKWEXSZ4IRRQzs7kXqsb0NvbnoDk7FdDjfMoz1JoW4OmNWcaJ
CucGd3ZEUrB3R01BEm/t/S5quw7ahD+3L1l045PfiXg35g+4PbHfrDwGewDk
YA2qWEpzksyho7fpfDlbzYUrw08sJnCNDWtEIkKRPoD5JaQ0ptNesI2EnVeg
cNadbN1g/yrafLFchq0PUreCSSO2IEJAtCrRVzy5yw/GvY9muaOhJezJFMXQ
NHW/VrIZAtUQFcd0gTTQ6rhrAS5m8/kK1ftaSQTYEb+VFuXvf/+7MSZQbuyT
Pf95YtHma/9OV9wz5tfu51/bz14pg++/fsEf/V0mAa/4Z4wNPo3Xd/4OV6jj
n07sthuOJUzhxRa+hjU0e65jB5rc+kIkd4baWkb6r8H3IklCb/zP+CO+4eTz
iX8d/Lhz1ftuF0fxAH+Qnbl5YwKj6EMLyyQriUk4dRMWmPZioirDbQHt4XVY
cGiqzvKElQRiFefv+8az/3FZfIBNjn2Tr8BT5mDeA5MGO3wCP6ju1pAc1FPc
WlkhKmzldMURaIvD1i6egraMMEKCs/ZalDTVe0Jti3fDhqnQ1mCuX//u7C01
hfv5d6tkDnMKd56B1g13vwUjcEMbaHN/+WI8RZ3mIYk9+GZj34C+mtzAU8gl
t95ki6ze4p+6RKg9hMk4aIlQ6L8Suryc/nzk1fC5fP8anlFD6H0CK//a2Sob
HkfrXx63l5e02mxNyaRfkr254WEWxAYevF4v000PW7z4SAvwubq6gBauNm2D
B8kfZLsjn5fzomKl+B+knZcX11fYDmmGF8UU2CGLGN4rV2sQWwvq8rs313Dj
uyX2cG7fgMGmd85ZUH5I1/ae7PWtix+urrd6/K99+46+X7763Q/nl6/O8PvV
96dv3rgvRu64+v7dD2/O/Df/5Mt3Fxev3p7xw/CrjX4yWxenf9xizr717v31
+bu3p2+2WMcO9T80bVmpQeOrBN0SOXrS0Lq+ffneDg9UTRrCBpHNMnwGq0eq
L7+qyGG78Z8w+WuTLJcpKAQZ2gFztKGzOhEVA5QHsJDJZgAWSjI7MNrfwf+/
y9J71iZRJ7xg231S8cxuQkbszuXlbmg9x+OF76uKFDkjWA9RSYDDAEubMpdA
qAgJpwNdobsctMHsUYzJAHLp2UAC974CgAGDPrBuGYgRlUtQmYwFPExdWqr5
eXnJbTv4iO8h5KkquFdZjehSTTavG8/lpfRZAAV6zIuOeCYqmQEjM7ATToGN
psADU3zvbmtmvCGFU78Jg1JrhW2hykaATYaNLYraGzcRhpMEnJPVf7S2OkGc
pp2tbxdTFmloVeauF2CFVWkLPFLzvRsPYF0C6K6BxHhwTd9euFlzOh7Z7ksw
QRqNiz6GO7cwbhIQalwu5x6OUwRrVSluqsKNIIEx73OBkEgz3bQOHj7jfU7v
exAcBf3m6mLXxhCpGCF+xzEZsyoErxEEdUrjp92K8EQO45ymH2m0FkmbHzOK
ty5g1LyaKSzSTpbvYfv9pFwm1Mfz93cHbd7vTQuEsExkUcJD2fIoauFocwuj
AARDj8GXL7vteROLCacbpFXthuYQVZ2MDq3KPGyP2w32OILhbsFxH1SrJcKE
FXNGARBD7hZsaxE6aH0Gdxvk8DjtbDkt0xIdFA+i8tjtwEZXXDRAhnCGFeAi
UmComIHULusH+NmUVW5Y+3pya/jl/7mCJtjqL1b13IOoyzIryqxek4FyVSxw
GoEh4q5MPyaL5TylcQLZpvxq4YryuNwTIHqCOpiCtFXZdMhetLm6WIq3zHpB
2GXMMk7VM5sxrF7DED5sY1zb21fZDWgejAlNA5cmU6Hq4Eo8KAjq9ZJUF+2x
UB/s+r262EsZaybYHgHzyrev/A6dGH8rMqJboGPU4WSzMwMBYsgYf2SGTDLb
XF6KVNP3qgkJYqZKbuANoFU4eTVqw2Ke3Tn2NoZliOE0HEkmflO2gzqxbQMj
+iDc9v42m9za2+QOcXCgYRgl4jNVMclY+aNm0gRuolVHPJ86irqF0AvIZdgR
ZF0nwkB70jABqV4jbWMCMFyUwyEQ2EDg8Y0oi4gzltBuwa1OwCQFmnZKQatT
t4TxtkfvZqhCjWviyN51OhhNC8Lk6V/RjslDmSjOsNA4h24S8qpvFhJodVS9
GzQMHiTbsP7tgYBjnlYTit2UZ9C1eYrTi+KCeIrK9O6mJsicySGhdIn4vJ1l
uJfRvTJD0IvUf5Gmr9/8cP2K9yH6ToFqydM3RxUHB1FYMUv49svr9yog2JuD
d+drG3EQNypLHggTDynaY4K02OYnRjUQ12jd8plMLlYq6W8jv30ObxkNBsOT
6fj45CTpvKXrRZ/Pkjr5bJsfevr1vLiXSwE2BJd+5Iaf8rW3Ql381I/409Pu
EeDn8MS+L4tlgoRGNjCu4G+AKdGS49B/jJ7vnp0fnzbaRtpls4S70Xq9m5zJ
ycms65avWIbWYA5OFLRUZkZ0TR3pbX4+/DCo6CaAdU7WMh/oQOuSg+j0035Y
ADHf+/0Ti2gdggC/W6UY3AESJn2hjP8rBuBWIekPOv/jJv7SNYRGC7a7AW2i
TaKtPlh73B/3p/DIkB4c9VUh3NzE56CFf9/bQzBkCToKhm7gkjx9k6J04U8L
/JSPzteLiMTgnSzhq+BlEfzZ0asmwPlwv/EzenQ7BTfHuzj+xLt4w8e1NDyR
l7wImE7vuxez2X56cnI8GAxOprsd7XQOsPWKS1FXuvsCd+yoSN3tvOMBnNjp
LAoVs3/xQn9GiPhccIgqI7Ei4qUXWJtoB8MN4dhBu7akt5Ef0TQ9AQTZqg0V
zpLXs1kVp5aNb3lyMtske1FJWIJFlRWrar62YUAK3O7iWUjmOv2sjqNeQvRk
VpTBGKOAF+OhCS/yAyUR0UjnX6OBRI/3zc5VmoI0LZccHSVOL9bpoaUx+krr
ECmCBvlW0tqrdJHkQLtVfxc23Fcbdb3I6IT+ENIsSpcbpi7LVrCeW7AKJyyw
N/G2Tf91caGvkwWbP8jF+uyoYXwJfaasl8Lg0HwCUyebhA6eUDsnXy7M5xwk
Og7LDvuk8TnNtKoTNjJTVGy8Bky+/oSNBiFlYiwnNKCdaANEex9GPOJ30LNL
5VHi40BOVd/CprhRknEGStt8wFepCktPvz+/EKv52dFQ1Lic1TKvpUPjNUX9
qD3P8mwFZDR3VrsyY+eQA42fuDaOlketQ4YR7fdberKY06xvM5nhxpsXxQfY
8LqjAqomeJ16Ml67qIN4JxE8j8Eea9dA946lZlq7thXHZHfw+pWHzGg8CHjg
89fCKxCand+Jn6g5PyuGGKGzCfSKb5+sygpVZ2yEHuYYEp5g4BPInoigKJw1
q9lDCXfCEvlQHuFq1IrjbJ6VOVLMeZqbHWtELCm7wtYiBk1s1B48sID4IxDK
tLpNPiiZxuBOCCZJZK7jPU0kp8dYoPppgTwu0sUY1vA2W0JzFPrFG0rmD1+Q
ATWgSYEBCGxHLNm+KCIyPOxL7CI+E+ysWneb7qwMtrSz/QqCsj2lMBHGvZT9
D02WGSoUMPaHHNzUgoN5eKEih3XoqkaS6HJUS2d5QpGRee+i77sCHcSt+iKi
Gf4RMAMRQ54hFtQEek6zGViBxCllK7vVNK1IVIXrJXqDAYkAl+zegz3zMEoZ
x72ABK7TZOrbFwU1aBCs3tfeqIVHGoDrzvD5cf9w2B8OQMSMena0P+qPDkco
anZ7psEsSN61uBDzlntBN83WcEStYaPQdjjo/hZM9tuiTv1Gc0oMBpCsQwjU
h1kg+IsReBzHQqTSeEz71EJVCBt7JRb9mcfv7KftDlCP/Pl696XDCd4q4IQP
lR/5tm0Ny4cVYvDkvfIbvi2rlnDnuzwNEbYuHCUj3WdzczvnV+93Oaa3QAIM
hBpMDUX1CX5D5iJSvcMNyqrXiNcwJM65e1887WsftVPjFIR7L2yIfDjEEASi
JZ7G4UdFaSQ86YEAIq+bRtAQq8cGBvlzQ5a9J8B1XxVmhxEKflt/BME+9tC0
AtYN9qQuPkGdQDKZzbI3VFHdFlFt0IVpBqy2G7CBj659++JfOv646FRpos/n
jj9a9Bw8JibO59DQif7YaGh93vzCjs/n+ElnWT2xjT/skxf6edL15Gf7Lce/
Yi/9H/p2XErtR+vJS1Dl5OboD/h/PvTjF+3tYzMU/NnxJL9KXhgFM0XxTB1P
dr6s/dPGd8ZjbP/UPc7TmxuZ1gr+6vdbP/3i7+QPAy8/MmYYADk/do+zhdC5
a+0r8ZOfTyck4TkahAdJn44rjSd3MMDk6bs310/TetLfDQDX1pVfqrddUxV+
wguf2zzhAUYQXujENze/M74bX/WE/mMCf7LxQvzc547/dV+Innu692Prf5su
RA9+/uvn1v82XTAPGelXXqyGcBJJZYWSPL9G0ShaicQcbl8tMKjmHcrClPSN
gr5+QQ8Rm64qEbv1DVtRA+MyydHNw+2I1+6GY3ZNQrScVpTOEIfJ1xw72xEI
WkpP8oVEDGeVNn/LusGHuljCv6Kv4Cs1z0JFf+N9GryFqFGSx4b2KmcHo31z
+tbJ4yrV9nsUPrHCKF6XnWHUnklinyB042O9d1ssBSCTXlOEM8ZO6jwUY/QJ
RQMgp2Gs1GCSJlw3aKZN2ZHM7r3lsoqybx5I/mDw/jbNShP39D4DPQX5DIwa
FPydWKXeepPeJJO1MNwtWm9D6KPL1KKbER1Jk7zmFBfxMyX2LimztCZV3GWF
eH/7ryIfWVaz44ydZTwnYnezq7iCl9Z7osr//v3b2Op1AXj7h89RP5ymc9wT
MImg06cfJ/NVnGnl1T9ytUF7RvOZ4CFOvkhy3xPnec3yIPzHN+cDgfq7G7Sz
DarZTrQgXdg0fP7S/XMHV5SNvFExe5ANdzPhz51fN31aIqMtVXb+AOSzC5cu
eAcgJXc9+ZnjJkEMWXwC/tmT/+z9U+v2Q+eTXhs7fR/1Owq5+prefu04//EZ
+ieebHZ3U3/bT3620ebe+P6uJ4FqJfZs94Ge/5K99UqY/P2j7fy0n3za+HvT
oxuUpCfdX0MtvaGY2fe3BaaT4teXRT67XNDXM5BXVcOmaD4JNjLa7Zu+BjbF
L9Xbn/PpVOm+6vMkVk1Urqt+EqkgwA8Dvrpa7m7ZE1BGviUM1WPSGpNZsEtM
RKwqJknVUiMI5QJJZZwogmcXWKhAcLUwsVowEAdMq5RqB76gRiXIgEdCGvz/
ohWGA0/9D6P3T/7/wOifRGb7Q0/im/9AEYqgdOEqCUd42Hbveudnl+LxwJOd
TPerevs/IuKhJ/9HRDw8Q7+AiOgUEIH9SumYG4McOf52cptQ9O48+8Dhxz3F
ZFVY4BXDrpm0Q2wEdm8zylEkRGI29kFf22ycJIXkjII9VZQ1mk9d9SRKihMl
lwRWMpgXGGkbpHOFBmByV2RTtLYz9HBQFmqt9SA2Qd8JtzvNKuqCF604S0b2
sKSdJBm1hGVFavj6U0eiglSPoGmAW+os1dB841CDeBb6ka/kSjzPkaekVk8J
hxpi4npdFnMMupY0Xb6ryqdKFRo0G2EVaIBzIGqjNgvnfNRgSwKja9fj6IUK
Rf2RHsLlo6VRBxKbrxKinTSjUEyHxzyK96AwTvJDlLIiYdZM2Dgau0HLVewN
ifzNKftaxqlzV2AxgLWdZezcOKWyOPBxFWGCBJKwAw+4HNofCQhtqyZfzxja
IODXMKJ2zFXE+CKx5792PfVZByG4nwpo//XRdwXC2X/teioa3Vf3sDUnLT1h
01ObvABtULzV8MZVaD8VrvImPfSBUFb43G2+utnNRZ8mphLmY38Uw+FhyYLM
Rt2mG9nNsrxz7CYnbFW8qokLg9eSOousxkSSMVaz6MrskliDJMwoE85FEXxc
RoYZGL4jZF4xBAgsSdP4y8qV+9hQmkQCGLpeShzPCMdjRm01AJHCG0h2IdtY
LKTejsKGOBPUVc0ITGrjQ+i7IvsaZbLQIgvjXJTV9WW2g4DHe6yZUGmlKxdw
U/m8m/HadQrla1fdpSCrNw4d9JlWrapapDGEY+l4IYHGCQa3Mc4okgIWqcJo
rkUQhhC4i3G94PaJepZlpAzwajckRqksKTB4KvJME2M28+snD+09z/U2PPnE
8wn7Ve5jaTb6NET8BpXxMdt1g+Fq77r74O990BDksXnO282DxfT0vkjPj1U6
dMqJTe8L5EOnpNjEgb+qnx3f4783uVG75cSTZt87jb+Nr/UXNpknTY/4g889
4L1/5LmNvvv/hn4+aVP0RvJ+RPNp78yI4Dtl5kZp+aCcDByIumOb7sNWvj3r
1kWOAhQLGoB0leyXK1cZ7dO2y6EkOeuT9K8D9dgHi2JQJweGcUBdyJ/JAXlT
FFOLRi/7crSWTZTHHaRw40NRPqhLT/6+uMe3a8g8lkMAUYnhyiWGhgVvCtvG
JsYYOsWvYJEGEi/IjwZx0YN7JonKKAr5AcWDggFVSroKneiGpMBzKcIY95Ym
BsOtSHCAJOCoL1e7QkM2AwtXh62ppBMyDSda4sKE6dxoSzSryX1V0Ucfv6k5
m5yuN07rOojebU4L17Mji0fsIe31MkEDtOqoftRjoUoyvGAbP59I9i/ns2Mo
q6bB9a39FiaTXtToW17UXbRAFHBf5N9wbT0tRDDVKCwNaTaNMp1sRGGydN4K
g+M1cH5uSZyuJiA6YTtgbkWcaBxjEDTHCDLrL0gAqIARBYWxZ7QJYt/2xooG
oKnQzkJTsLGzsDYEqTLOkKbSdKgt8zJVoS+XkJZFWgch/PpydMmTfuYCgjVu
n7dzkF1Gxb50m2S5xgFrU99UXjvNCwrVR0e7vS2WURQxcw6wezV22722FeOr
/XChdb+irA5NEQiSTpFSkjmW/lo3y+0FrMXFFHsIgQbR2ilR5cfwzfudb27X
dI1qfAQh9VJMiV4blFIqPA8MkADRsZNa8oZokLL3ZSg/t/8H3TOnjWbIXQJm
FcNNVB7y6ozeKemwR5S2zomvW39NFnX/r6vpcstKDL+GuGpauvRIKlLyuINA
9mDstP26uih8bvOYHV0y6e60A1Xl2WQMW6fmPJBPn7DoVTr98kVn6vCfmil8
/306n+8R+6IuJfmaKwH6agjYdw37ftaueueMKRA3d137uRexbAy7yQviy9QJ
GCuGCBMkaSI+F4bfPiQwnJAPKakfZrrVq4SrhDoxKxyNJyjcfPhSt3pkUlEV
B7+UmbMTQ1HLzxaL0N/HIGGhefDG1XJpmp84JcHmjJlozwO52DcR/lIO1Zfz
2FhmqKllqGR3fTdNm9OpMnEcD28rB0oIqTXqrWDNd0raQvgPwQhm+HdJNkei
hMso7ECh4/IdBOsKjqggMoPTfqO0lz5CH7g8RjpLS8fYtCwEJkKEg2tOrFPz
XDFet1E4faCqUb8aY81LtaND8bbKKeqJ0iqWjawOrnEgxVBNWNqIFK1kjto0
S5KgxEUXCk47BUEHR9sgw8J8gu33NHxKBHmHpgv29dN2IV+/tIpucKXqRKaN
U+30OWT9TfR3upJBPFTnXOtb0oJAm7B+yQ2vCGWaco0v8z2oGWv7ap2OQQtA
NP0GtfjbBYNca6TxaUbFUQXMwHqmK1jbvJ6DCBqDDobkZbx3g0srEzEGL7Ib
X+QLyRj2+svQexjilS45jwcof6q8zZXVDAIHtCJj0aHSQu8TCRPgosKha4ao
pZ2dQ6oNGTTqENHKvKJuk8KAIXulFFNKbiXVRoW2Lxsd34neHeOwvZsk09rV
TRUXCD0H2qiFhTHNex0kyO6Jq4SyUyv24jgXFg6d+tvw3yBVS2Rjxpm/wr1B
UaY4R9gNUQUdZWxKxsyHVWaa2+I+2M8CuYWRGZKOx7Q0WUdIm1CL6SZL4Cur
SeoT0DD7C1qgnDDM8SAm4VYvSPewKe7RjF7XWD1WVWXlrjasXFjZPCiyMzgk
fyLNTfUQpWMREph+EyQ2hbl/Z0HVzXZXAoGiZZaPXCfwQAlUqcYrT9Qs/hGW
JKITG8mtIOWPr5ZUTotjLRWz9btBix6pJOKcXqSveGLQQvg3y2zPviF5wZi6
Ea0vtnuQlkKzx0PKIHGABbMnz5dKEsZIbYnUCxRJzu12fUaH36RG+0k3ZKew
oMYCH0Aka131UtespK++prnNKplW8fUG5RV5miN3L6YVpbME81Al/ZOaUrkd
zjb2E01OVYDDkwpo3LvNgVNTToPu//jvDF7/+Gu7Q3QV/DBB/1++sUjZcKha
cPCKXS201gT0I507Yf2NMq+dBKsLaqzjGeJDd1nCHOpRjYmakZMa+iGhidvm
gqpYuxV8ybUHQiyaWiDRAYouqzMOLIg6FZgrhBYwK1mgUc1aHhFNUokWpooq
N+kOt5ByEijKuD6S61segOM+DJpUiyzO0gtbEtoL/TQ9NtxDYAUENYpcYrFt
zUDnPNhDvejxqJxbaIVssECooU1WCHFpRF8D6m7UqJCTDgoxpkOwozF82GBa
OYon4nQyoeTwG1RAQlNGxhBsuBZWqMyWGgoGiWTaHqjYoxV6aKYhcSczRL8C
w5aWo0qTcnKrWlsSkhoT7hvK3yQOw1QrOCo5JbHGHworHiM9hqTTwRGz2BGm
vFhC6hXYwVKUoZ0vMQOiH/Gj3tmoD4Z+0ZBcKeQlDpXwyZMYoiH5m1zxPWo5
IPfO9qO2ySnpW0Zv7BcO7hH0g3Os0birqFqHrWCSOSyFlAgsyVUFmp3eXyxV
hoebSafU1wSRFNE9Ssdw0BRpaEiRU1r/WZbOGUVpgAQlzOxsz98p5TDsBHWR
ibOzcL/IRIBKINiDK6rJlmVUeTXYHjcr0MeZwzohw11ZubzVlkIbhxRx4X+u
2K0xQHg7CyZBL4UsFlhOjNFvX+8Nd45XXBxy6hZaaNkyLHrDADrWZfgJufOc
1gyvR5VzfYkI2GgFFYUMtll7DdSuB8uPKiePUy4JqmIRdS18Sbhvb4N8+If1
LTVDqKkIc2mrXVqvhnBbrawTaHaVls8Iup9QfBZWEaRqOotlQliD8jblgh2d
FNbb7CiW/ws5Y6SEtFkjz0qwT73xdeL8zMN+wORGfXv6FWjUn0QM/Bmf2e/L
aXlSTYaPL6IOjNPb5A6UdHsBChmsHRJgmU1hdsgEmC5AiHMt/TvvqZdSi0gi
UlzTNYM1SBGvaOLmoYQIAK6gaOKigPluGtk+cwuLsILafJfMuSCSp6ZQlSJ1
u/eQRa1KZUPUPkiGpq32t+jv4SGwDvPIQGifoVhko0FJqgoxGek2KRicGzdN
+cwOWCaUL7cFhfpXK4yfwxOollW6mhag3YAO6s3h3QDT6EA84rOnpCJteLgA
bo7xWg+C8VTRKFi9wOqJjDl51h9is0h2mZwohiMaZ4k7aWjj6Nz+RE9kCDgW
45pDUlGOwPqMqeZ5qeGYQPh1UWasD1AxcpI4HmAVVAG4XLZgA961TYA3a0Rc
L449FDDQMXbElxwSdxTXddHEzPTjkt0aMZogy0GnzywU3DFNFZ7LTyKcdNYq
ngV7czWpMWqFS+7OHUOaMZATuT7RE8gzA5JpqTszOmsFjdckyJGkpA6gZHEB
EF2FbeICEu5bexux0xtqnHz5A+//CB1HHpPRKVyOW2LLIVbBnCa2eU3E+Zp4
QM/KNrCBsa/lSCjieJ4mGH5sRERmmo3q6HGGZwV4IBA1hhiL8ztdsWFSvhj6
TkukxxZL4JCzcSrpkygtcRjR0IxYK7fFfLo3JT9qtkCt5Oc4RLjKa+VioGii
sxptgq1VvqrIIAnOGam27IoU18sVXBh2yGjTYo6iceqpgWj+oP/MheAKutHG
K0yDbQtn8FqTFJHO43PfggJZ8ayGJBW07dYO6Ul0J7KSkxKoE9NSq9X4b1hH
mJAziXBz6a+yDA15EoFw3dW+G7RIUcpAjjgEkKVAgPNklU9u02kA5obDTeo6
XSzpJL/t7e2XcoF1EgoP4/o3DPCc83l2NjrPDoMb2WqGHYTnJUVRHNiOvA55
/EKbjKMduKBTXIVedCkf2tclKxDOR29E+pT/ceot6AdTOqvytCnUMCpknDZO
2ZwiXOeC925WsGqwcVPWseksA1gKXFLk9ffZtMZcYuN8K1QAWt/Tapl4n7yd
RbTqAxXHHSoXNo6KiK1p0IDzJjD+RUHrfgmjrO8YVucoC6ZlUblEouLJh9kE
C2dFupfp0L2UCqeYGL293SDRT9u3+EMzEugdaBmwZ91ys0glJFqN8znWG884
9TqgF0HGSJH0yoMH52xzk4TIrHfzwAtg/ddy9KKcInADYhG2Y/YTcaTIYBEJ
63usWYbGz3QVb+hajRcJN2pBg1Gda+81+SpPCRWxZhqfkWPDlXHX0ybRJvbO
N0eKmlYyXrfHJJI/dOsIO9RRBXyRSZAKVW3sJcJYBGIZAepDkN6xUDr8CuRb
d4V4d1akaMGaC9HlIVPyaRyMGmyQGkR5DgrbTUpyXDVEZ0gXuQr6B4YlHTda
BS7yQqFaH9BE5KttmXRTd/QX99Q/CDrnDAXpjNiD8apR9DLxnCi3LiZYGxHY
F5GdK/JoF64EoOESgP3NxUybIqPHpmxwlobID+TlIfHfs0OWDG+fssJao0hm
PNwHZhkjidFKu8kL5BsCwUhJxo+1jwMM2u9ZOVoikVqyGgZIr8WhCobcKHao
pk/HCSY8MLeYjImHb3S20GZSkOKVIh9P3e/frZC/oDPXmDMPxmydE61rKEtS
rUH4lkVerCoXB5nheabL26SKT/Dwxz40Fmg3tMxUXrNzjPrGhBbk+gRHKkbn
XchGI/0Ii5jQbsImtPdXl793Z8EisiIOGG7bq0S4cAJgU5oBIUSJK6EZlgLU
yW+XONzkAoCJfkUHK8xcl5DUwoOeyDBS/VbqD0eZV+GJIj2K72F4BsufDsnC
wm+jjkbJ/lK83eDLQROl/Qv8CyvaNwOV8BZnq0W1kLViqEvMktmrk/Im5XPM
VqU4M/hIrWfHI1ptvnEthf/9ALHuZJhTFg9sP5gaURxKvMAHDGB4YNRX1XVQ
g/JDnAZD3FUnPOqpxJqiIwVFEVbm7hpWlivUSacxO9DD5dqpeePnZetKMDxH
lt3Pdu+ejdbZbs+QGoMATjh5Ov6vGhPXlkWTWcsBy9lZwW7hNDyiVU3G6zE0
HyyMTA65hUMTj4drO4eLrmiKsVV6Y2ypuR2mFO7K4I/lPKVC2e6Kj33V3vpj
JZCfs1bEpxDhwjmwlRrh9NbKObZMWNK3KwE2AuHqIIfIkk00zyiVKjcS16RT
2PcFg4V1gN3CVIloP+H3Sxe0yd5p4woHY+7rlOvh5lMOM1uWaBJoVDFBSPOM
Di0PjQIw1+hUXTp9CeEfccvyvV5XC0LNpgXhLSwCL2gNSH5ypBE/iJlVbrRe
odcUXyqAzW4esdTcNJh3SF/3GTr+PNsn0LtzJnXGg6nk84io5K3gr0Ct2Isq
tIGWiHjVzDCpVtJwEJEzHig9HAz2FiB/M3WLweViimWfpcB2VjUgXVJBW5hu
bFcgYznVgvFC+dE2TKClO6mLv0kym0qEPx5T21S7IsOZw1kkzU3gw5sM4+Qo
P84rj4IxqISNdR93xHOYsSUKNaMZxPRDxYGiEzhgCI0PpzG4t0e2i4aZbb1S
BVDTy1C0hWoL17JiTaviiG7iSdrzLUP88QEdsKli9Hyh7pVE+JjwaLJAjek1
AZPMazy0MxCauU+ymqy3eXJzo1vKsaoYa4Dn/AG5YE82VGQfh9NUXAm5zRki
JKjDH2klGiwe/ZOYNtqBY9oSY1BOqqTVu3753lfqJkfNPAURtcVGUimBl9a9
M1TvyaKIpsXrShKgydBWVMtbtGjXNPYgauSOt0emJ2dJ3FeY7KLRVRg/16VZ
a1dC7Xtz0BW5MAXJoQPnCZkREKPyIJk7nMn4SKGuieF4odN2p6Izs623OcIF
aVbRN+qfw9SY+3kUDy5Anb0DgTENi6LTETSWTy0g19xOdPBuI55hN2DySMok
ULEvcqgvsFKKDUsDAFStOB/5i7Svga3ttCDWiOfpXZL7IHxpX0uSN5lA01w1
EQLE/ZnBOtymyby+FagIaKEQTAbbwEA9thuQgZnMRebporhRO8/KQ2nHxqUy
XRd2i/nRFk/EBwzuFo9v0L4Kq01MvWcC4JCdchLqzHBJy/pzB1sHVe2NBBCj
7EbNoFg6Sxm7o+dlap5XDKWdurQv0rf5EKWuF5NfJqRn7qyLvDIPgjTBO5EZ
emuSunWZ0rEZxDj98X0RwEa5Q14jwnE4gMlhXmhmuaCINL/LgIWzTLxXFDIx
QZHH2xQsWXSBSXwnliHhzUhqXiNwp+ReepS8Xfm+EYqQpnXQIYmQoz1wU+B5
RjtBQckeet2AHcywp/4hJCyyXDWmDnZRCtbnTZmyuJfsA+HuPe3lxmgJritC
81Yls9SJ4TCdTjBINvPppDYpNc4npHhzO2SSPYNOLoTGOR8qwXeXq2XIkn2A
jktxmMXdNNpNNkHIRAEaKyTQ3k+Mwn4uSREtfRBmNymTohzh5E+7Tb3LvB3m
7+B5GamLyuKzcCuK45mvhQxQxczUNwAksiSHCEwYxzfDX27TkQdKzoE1jNnP
0XlAfdLjcX0ax1wnPz76U504KS479hH2OjSmBk+Up7J5tnBxDJ8ngE+66Dqf
RTOGn9KGLFLgCwSQTrpgIEYwkI6G6CGNJg9blRCudqPcGCJijoK8O6qRjYdP
4frKaTqN8zhgsr513nQiW2UbjVnT6dfpSzBgHYiC1xoRvWJMiC+dBwpsbKHl
8QPjKWCJUfifnIGBG10h7JDdRAxsxX5v9coLD4pZTpvZCFFEWqGGtDcj2DtP
4A009LowmkLEi+cMQfwBVxfHSoMnDU+KfLs0JhwBpwmBJAgdlZuSOIi9/7Bk
SIRO+nNs6xVxmUAP5hN++8NmJOacUD3N8hHmxLa+50JhWjNPJjlZPCvvOLJX
qzc79cbpf7TlV9LtLkOrTG+U48CaoXKtwWA1paCSdgmGLGZBco8FCJhlJZDe
oQ6DKoEVyyydGlKX8bl8hUKZo8BsmlQZxTiJ0yA8/mwhQcIHQWuGFciEChNi
A5HbuAVLSmKslKZyZ/xQ1MseOflnCWdm0Uzi6cVSU4MCmUd9n3nmA5S08omo
FImc5hYd0XPPscy5BCSr34Y3HDa937ffxv4AZiSg6V/iaV4wi6L7SpCfV2V4
4bjh9YTcmJj/eepgcZejRfEgYUJ5I0BF3kRNyduwscOuxoIjsTZp6XHsrte8
8WVDbPjoq+ZTk5PjCRWNkXRXDkgWUDJW/P1UkwnAJnZ7gSiU8ZnvjuTzeyFA
Mph4GfLcng2LZt/H5JRxvJ+vcKaVwoOjfqWedXy+uyd2vkzNoDSoIqnnQlwD
kFtRUUkWYlMjiHYOK+SIPmEp2CRc/rPvwW7VtaNCORH6I/kXHgHCOTuWOcPJ
ROwQAdd5gTojhnKgSsWRCniqjUZG6aQif6IwMZkxnV2X3++Ul0jjZ8vRBWk/
7yAi1OGZfFCHCXwKbUqqKIyJ3p8XYY6qEPi0lSdLwRnIMTHIBgzBPtmiqWRi
NGJs3LnxyNY15TP9eAtsvCZ0LMeJJlboFFLRRIXLaXpMkEhbqK6L9YlkG9eB
eOoSTN69KRowNW+3hyFAueCz3FwAL+q+upUMbaBqJRlZdZy9W3hhqcUk8sKd
miOlPlg+ykGzV7XGgH/arvT7l1jtD08rwlFzdIhTDCkswh8ankogPyvjxuWr
eqUPk2ORR3i9F7WoMuOYStJEk6kTHWKcmMigYXJYZBVpo5368W4b+kDUJsuB
uQaJsBQ24nXPOQaEJpWNlC2kFt0mEv4Q6KYm0E1ZPloCHFKFujgouxlTzOC1
GG6sUyNis5GKnPUilMNHJ3KiWeXOmLTb+3bHO7NJm40l127PMGWg64B94LOS
jqqsKcaOkae5ck5iMA4fq1rYSA/+dn2UVyga9+kTasoc5TaTzW/aEA7nq7LT
jEcjdrIGQzWMZUx51cEKMQstfk+dAlIOesj1606REzBApDd/2o65BFWRCQMp
NR70EdbFqoAXv4ZVT51v3r8BV5vpEeVBmn8V8TrK/uBUOS6BACyu18YNOhxE
jyn157OG+hCcKdo2512wC3aAnd3pZMV2pnGRqJrTR3YPM2N1bmj4PNoOf1tV
4nAKfS8Y42xg+8Mcs9gaw+7dK2Z6nm4UCCSNk04g4dF3yXzlDgQrUaSaH/8k
Pse/ygM9e3H+dqfxo/03O/pLmdbl+q/k0+sBsX3MFquF3rD74597RhScsBfN
dmAZDyTVidX26HbTaBVvH44G7oEdd5gGcxxfQRClPjxo355eQyPLJTEsaaTj
LLhnx89YzsXVDsIWmz1HeYgOdDnfI/TWGriHiy6FjzPDFAsjCPEJI3rVokK3
SIjPa8REVoUkgF1hmA5M7t+Eh9B6ZMcoO9PUA2tP585r5mmOSKFyPCNSm/Dc
nYACNRwshM1CP1fPBhZryZZvRY8aNW3o1RzYxvITFvZvzQFIcGobpDDeoKII
PuR3HlzJY44Xjg8W2FUoeBSOUwCLPRmJY4Hu4GtyhTKg1ohatpL3vCjutDyT
lPTCJMbYvhOBhEyR5QjKJoEWfac4y5yVhz7tbf9K4RNzOT2G8k3FikAHG6zk
So1iPBFB3axmONBrLAe23xQV3/bSKbs+1Fa5XjPkVqshz9Du1cMQCtgJwl9Z
kITzpjqPPxvZHbAamiSUNlRrEDAxqJrmX4oWoIrOmYiLBdUi4JiNIBOC+I+r
YNpjMUQ9UxhAFXJ4glMyYfHrYlLMBU9yp1CzhV9x3RaYQB1tz5BgCUpd4BDC
qttIIBSWr8OXCYlVT5ic7OZGckYfVoQbyi9oLByFZx5WXCJHnXr/1Z2a/UR+
K/+u8ZpzWdxIgHGBPEvylE5iNxywlkgacWDSSbdC2FbTYD1wbCRPRmvL+nVe
FuivwjKnMk3CiTkA20vygLUiPA+Gs5dqU65IxlDE46h7kOEsYrNaJi6sStoM
jFI2bue+wMQ4jbfccGBUQPnUN1ZkNrDXIFLbBAy220MRslrZuKesKAap++cB
dX3aVkWSdjO5gkhTjML5FAH3Nep5BdbNIu/sYYmcYqrtTTllysUoKF7C8+SS
ZUTRV8chS5UOc6IhqL2F9SUk5qhyE9c1r1zfcdKxl+PUHwIt6e+qTpop0jcC
EWn6gSWgJq6Bpo/6GeYs3KqHdIyUh02scjFUfNkbw+tLKU88XY+S3+ObubmR
g2BRUP2y0sd4kv21h1C1dcqbxDex60vPpkH2CmsiPJEqNU0lIbOZVkHVAZVu
eWgT1HEkveNW03Q4u8IL92QhsV461cbDWA0rVzCjgqJRKG3tRiKmx4lXD/xM
Brq5zB4rzN4HgLk+K4qoQE5CoYQoPHpxIRfjvQ4Nqzys6UKMUkJs1iRhcg0Y
Im6GE88lftBHFNbueMdO96pSxYrT1FNE7evbOIO+CpKIsso7JH5FFNo8KRuD
WGjt16wDOkifkvykNkbFiclB6S8O9pPUG940uoOXSUXB1ITdoBXvqKj08Xmy
BMCkNGbxMfJm/sT1Bt6w/Q90c3W7qtmnjCL307ZELzDzFZ6xg8ZyFB7RESAh
ir/3a/vCHjhtjjMAS81uKLFNcAjBPRDnTiYUYVJBn6ZSvlOFXpRMI8HdSw71
bvgPGpzOR/Q8aFI6S13+7kaiRd1xQHQQ/mHtOSmn8lNoBYvCGCZbNcI2Oh3Q
HECmJXB91kyzINfOp0+cbvPFnchOEjEA/qVTUbKTI3pRlMIn5y4M4dxrla1U
FqeQsAIT+FQbcglngrgNR2zoJOmZLWgigG3JxzomILP3WBf2enXf2woyBvLQ
yQZtKPxq3qEAI3HKlOluM13Jiz6HPwLM2G7oTJIkrnsLFMhc/mGjIdx8XjO4
YDFS2TvQZrviO2BDtiAp2AjzeVhWJwnSsVzcuK/DohpMsE1MsyML7chO2r/p
R4khYAPv90fN7Y7RTkWgsjzi8dXdj15QytpIOH3QtLqg6odWNFM3DO3tJDjJ
BjbcD7RBWPKH2KUXPYJz6qE67fCYwHIFAWPKtF6VXB4A6anZCaEsnr1TLSDM
GTqB+4P1xsmtjrI90RicJdHbmcTdIOf3URPIXBzYiw4WiWPVSHPuc1DvUF3I
WE8iTpVJyJqrBbJIbADHObxSZ11rvYmP35GMqkTmQTWQYJGwHAPRbqctJjUC
lTY9j0K9wIhBJAwM8X2u1712XhtXPdNXcXBKaGclwvabnAEghjK/NDFfE5Az
9uyVFrqxzMbtJ3daslYZTTxvYf5OWnrBNUfVS+xloVFZ6FJqJU5PPZbN6BUh
VY0HDgnBVSsNk2/bTSi+pdF6k4ID6rFjSBDFbMbpV+L18EQrp0anZRjUJJTl
z0RBXT4IezBBSF6loxNqb6jbEmbMd7YNCKXAql7zQb4bNp/dQRy8klqsHczG
BIayHISsRaI7zBY9rFKmebedUqxSttsvsrmC53kzg9Q0AY2u/aMlAB/bBkYf
8IoCpdrxHDVtITLF0vnSYuoCRRipOyv0cpESVSpWOKE4kNz5kEACnuccWhVb
yO+BZNSZccUueHPZqjOnFePCiq8o+xoVb+ONoIkP6ooM7PhGmIa4gimRWkLn
86lajhTR3+iLJMKR7orxRc1+uK3YMJ99DUlQpUetiJ0+jv0RS3Ump4q1Qk1c
oIIoBOZRo5eaouG2JsRb0yaIytJDDB5pV9RvqXoAOpdbeEm/9CvBMWYSpIEz
3VNCCpkB+6+N88+6edas2mZ7RHFonr0MowwkDb3py/UHNzDgMNEqsIGnnhI2
KNYjTEwxDoeqwrrUzKucaEdIk51lNNfROUlR3XWFZvF8A4968xGH9XopdU3w
MVc3G67Pi4KCz6Bv4SFyRtNzx+ugCqYv0K2KDR9sh2v0EYuTFEHir5UsTe+6
KVNUFLN8D5/uJ+WSzreC5u4O2lCRSy7pHzo/ynCwzynGoCQsj6IWjja3MOr7
XI/9w+dHGgzh/NIbEu7D+WDAb8qmuE8/NT/RwZ1J5JXs2zChjtM1Ma2JbCE5
EBADmWk9qQH1R7sITUQjneqCziKGDhGyTMWx4qJBtDfUkiGTO0TgA6+Um4XR
/vAZ5YaOpSKPK9eqJzdRdl4YoxdUqQ2yb3VpGwTJIGNu2FUcBm37uh7kYaji
iqeqQbi3IlcyuAs4vxdExwJjeyY+z1PIvDXhrqoSqRfIiXi+SY2gQsHBMHAT
rJYuQdUHJDSlBt/Yo/348u3pxSvCHM/424yyJKWgnOSxUL66ev2iJVWB+hMd
gubWFRV8Lr5Ey6fHgDgxi+dncAW4lgOUV9Wlk1BBQVczt1wylqypHAjXJxnG
52LxjiRPQmSccnuQZ/KtyAr/A7uJFRKJOf4h4TxEzYX0uV6M//ysvEv7QN6l
+eq8S7s579L8nLxL28i7RP8451uaKIg48Lt69ybeTWmXG/Iu6TV7Ysj6SQK1
NqtDEazn7JjQCxpmvWk9ujD+SxBUBpTiGAfqlYmDGf4bwhVOg9TGeyGRZgWk
DhvY6Y7kWe1yo9soza3+2qgIE0ZF2H8wKqIZv4BREfbroiKGWgAWFcn47oeD
InCTeb6TClu9ZGg4ym/kXY57MuBT1+tlyhux8SMZizgjizxFL+rE30DwPd4y
KWClR0cDu4MpO2CXibRsnrQ1mSeEbDj1rB/3guobvCam03yeLoWFIxJ7vDcm
DDUulIqbZ4hXzFZ4rBgzlC1/zzN6mrqvv9EWw2wkAnnmaX5DfmRy4OMteiTi
wLY/w47fRh2/7ePjQ7i0bw/soT2yz+yxff5zfjNP9v7J/8znuDqo/XxGJ8TR
ZODnsZNyPz/eh0daeGL+/tBlnvQHP3//BeaB6oQiVhoQnt3Dkt86NbJbwiK7
xqUggeho06AP8JKTvNiyJksH7uMYYdMFGr+/fPX61eWrty9fMbltUm73+88b
6m3fmbA+E6yl3gj/QQ2jlAgwrjsVVYklhctImjJCaZgF0e+apfbusjtnOB27
btam8Je4d0BASNCI7d6X8+TGh9q5uyXkfhCKRDUuUAGXaryq7DrENvBybNLx
D9AeblnEPfQYOq1Pa+Z6tyxbcs28hjDRiFgfnZYXFwynjno5Le1slmyaJGzQ
C9YCxTW7Vq2qZkWmzn6aKPG4KSV3eRiJw6ZcXoePDXDi2HR2uhfSPkkOMnN9
nIADwoM6LHzGjsC2/pCq4Owx1HBYr2wMqFNTJt9+KtXt1YKnJii326uXgWOD
7RpZ+qD+K7q4oblxWXygUKIEUascH/8aYtpM0MMGbcA+ZRWvm74cHTr8oZl1
LtPpTv+l5KUGNbRdA4qj44EALqgFuxgVtBCk3pmPfo004I8OIjM8SC2PLSP9
KS0LzSGKgp+QF7h05HbbLv1NQCD0k1SrTJ0AnSyJ9BVgPlR1iPmOF/BBbLIA
7fiQmC/N47wMYbtYPMyFyUZ6wPVteECJBFGyjUVVpbjoAL38hR2cYILFddwI
GTbAY9d2ZwDWJXQLlCb/zLDzGVffKbEHewXYRDVBIW7DBg2MHmtgeORbOOpq
Yf+xFu6BKvcwBA5BjiBNh4+lC69S2QSecNoDc5ANzJOpCHPFVC0aV8YVCrE6
JLcUNI0NEYE5v/JiSdDYVFJZQjnpdiNLSVLwwipN2JhCPGgG7xo8+Dpw6WmJ
sChe+tpT1CYftxmH8VQOHN/A3zpJmSUD0PJUjHA93DYioJCTIswZpEoJYQc+
TFJEDDdXd5V/93slPNkv3EEVSuJgqSK3QngPZaxivSq/5RKK5/fj9wzHMf+N
B/1Bv12phw0dG35Fx2DRkeLFt5OY/RGpb+EW4vMuqNxY3waKXnTPJpA9TooV
3cy3YuV9HFRKWSMSPIn7n2uvbh7g6CsGODwKRwj243B0rEM8+oohHj06xFGg
ijAyGg5QX9c9QvvICPd7XWNKNLemg90YJPWHgOAmD+jbl8Ix8HrASQwXlfTB
KXSSlS+U1K7uJkzDmNekmbgSeLipeCCkDROpBaVEaVyo95QYOnbHGGcyn5tT
qyXcmgX7ItbKR1ZItR71Q2iCOflg0EO6MYjYF9NwcCcCt43ChKbbesjQZqe6
8g8MrUcRJvge4+Pl6ICi4IVuvhovshJBzzUvVd0hS0kK3vFGzKcRuWJYS5ZY
qX6Hc8iwa9UAGPgd75n4WdoLxwVOu3SclsJnluFdIV6Mvg4TIf0U5OdQ+kQA
WuTnC2BmeMQXoqAky7y51eNJ7Blx/sJ89IJiH0InqFNcvvrdD+eXr868Oukf
aXHmcPeoKrbV39Iyu+GgPLHTtGS061mroVPW6HP+1o88sBXPPHzC6hpO2itF
oDHemNHKZFXjUSw1F0OgyodYwEFSJSgsgSDcRvFOmg2iH5rLuNJmorQAI6Fq
cXSmD0oJf5iI/Zd3l+ffQeeHg0H/EFTz58f90I3Up5uGo9YYsQodIS+D/f6g
Pxzu94eHD987gnsHw5Pp+PjkZPO9wBqh1X2bLGo5IUDw+j7oMP3gyJK4ArY7
OtxLocC0dV5f5t6m8xKiWqFmEKkhlS/mpsapaQhf56PBOcSphBkdjqRKwobt
aLhcgqtDLuADUw2s3MDuYKFdVD58n8mThYUbipICwZsRQAGoQDVpaWQBTQ6D
VqHb62/K1AS1j8LjeChpBslnrdEraKyGbY2Od4W3/6R+DArKypkXlZTAIG4B
rHsZhkc0cdVc4v0lLEwre2uaSGCO4Nqscs5JubykbVB1TYWXP2IBE+qP4QRc
ewpP9kwmadQbo9tFFNngOKo7X/DAbapxCnwg2FDDAVP09R/fv0Ks1/64bXdM
gMgdWfsrUU/CnwcJ/Oxn9sVwEF0dwtWzF4NewNNeDHtNlSt8ZDIeDJ4NBzO7
C4+2t+lj3Rwe/yPdHHV0c9Rrqk3hI8gUBsAUBt0f7X6TczzW/dFBZ/ePB43u
j46jy/vU/2HU//3eA0ZcNPrnR8Oj6bODZ6Ojw6PJ0fDZ82f7g2dHh8+O6fcB
/HY42D/aP5odTWlYYTvE2di/mH6kvCEszx4kN4tfkWT1+enbU4yhCI9L/bSd
JXnypVkCRou+IM3SY5fpDebWrJ3br+kFwb1YUW59hXHhxCZI3YF5Fk2joY60
6s5MqFhPJblWpb4RBzq1W5v8L+Z9UsIdoAlUW84RVK3Ge2XYZXz/Ftt9ZGO+
Rhm+JXxWXEVGoAaNOw7bAJYbbFf6PNnjj/772OeJf/Sz/T1ZvZ/xWBRXu2Tz
5/Mv9FZL7pXP9m3hoxedtfLQW/HRIf17ag/2yN7YYNh1PjqSR4dH7tkui6nr
0X15dNNWCh+PHj3YGx0ewr8/5EyR8Nh/1wzTLvw9Ew9wMWAEI5ag+6RiaqlI
8uz7cw2kfrcGBCgWAVbPpddAJUcSTCPN7cRRyQmQbmBC9ctink0wjMhchUVJ
CfGkkKaddgIYFlwdjiQIZxsssRXWk2+wCVRAf3CRHc19688996kiJLw5eoUu
ICvCQzuqJcZfsgG9qosFAdc+aKTHiVOufLmL3koC/AI93GPQG/rmncuJhsfF
GpaUd18+RzSJLKdzklBRik7uaBYC8ZnVaEemjGtHaViVTlLjLKLOk90cWB2+
J8jlpiCk1sHuNZ3NFgQbgKWzpMJlaV6tylRw1Tq9KSWViyxSSsrSbBUy2nBK
GwnAaMkWpE+t5Eg0mf/z99B9Sd7fHwwl6wAH68N+4+o3SAxRpB808erlb195
05ZbG4wIIsTZdai0VinCfNdVVVM7NI+YpeMUpkCXFqIvNJIjqjBL8cTU1WlU
cYDOftZAjqxGdNSHT+TrYA4xS1mr/+fmwlEbQYcarh75eJqLvEtgKyeiGN+c
M6GwWLx3cMgxg0TvlBo728Oj27GKMb6MDn51NkeUCQCzHJqj+FecvC/ykc+X
4dMBJBmvUbF1QsGCdHCV317TcMDkGTJYRgDZh8SPqaOEjhPglOQM64tSezdp
owmsukfuFEUc/DB4japlESFuelivgpIIGCA17dGNmKwYxy+UqhCIre1Q9Kbj
wYfTGJ/g7jNlg8rwyoA4q3JRTIGZSuxYauTkV80EDHak4DGUJ5jrU5QisNSX
8AtczenFqqI0QNkFNtoFYZWGlOtyV6sF55wSbtscuZIBjoTNKDVhonYlpBGa
3KsLEKpTLPsPG5erK/ujChPd/c0kIOorjMy/hx07rnKgb5rqrtZrORKPw9DL
eDk93ippN8421vcEY2l2pn2blmg0uL91AFyU1B/mJxLz+ur8O4nWOz445KPv
4KedgZzPPnq+D3zQuMfdjPCJ0PK7pq/CDq+52Dphj9dvroQ9HB8ef/nSM+7K
99fX7+Xa8cHxgcTQUvAYh0U2BKnOK8rMW4YJw/jAy0tGr5plrSaYFUTiN0GP
D1UZAC0bc52nTW28FwKKE/UegLBMc4wqgzdd6aEwVFJSywwI9knnV3Z7GLQa
nw0K6QuP+6bSw5Npm4clMi6ajfUomzebcBoOx3yIHth6cY8gYIyxozn1deZs
mVUf2pH8XeeLDI45+OPUaxJxnVCq/aEl65xAZ+itSqNAWtNQLEi8o0GZrLRg
EyonzGtcMQ0MxPIvd8iRJmb1fCnXmCpI2cEBU7xFuueOqQDFsGOqlGmIFjDJ
yskqq/fGwNdRDIEUu80zdJnr5jEsyjZ4BRDDasxiWAc0EowSr+COD8dqz3FV
aWGuegeXINA4QuYmmICPYjJA9npU8wJrzYNopySBpjpoGFiSiNcfzt6HRKIH
eoPulU8wQpNz+lGQjfnsRybgvolSQA5akSSRV/SoFcKg/JJ3vpoJsVbJ2qyk
85GzXhJ3cMc1CJvCFCcIcM3T6Q1Xs9BcqsgguKcDcqulZprWjF7fIYuwTNAz
ewbmBliKZf1Tz1wWMHCQn8n6QwEcDugPx3WTzoHvZlKg8n1agvFxDdb4ksL4
xSrzMVkX3757++rM1dflDAwggfNX16/t832O7ck/kL7/m3Q2s98V82kFw73t
2esCD1oFW+AV8g0MFc0+JMB5T8dlcpssKqr39SbN87X5LlvNsySHfl4kMJLT
HMzMe1jBK+jk2v4H7JSbnv0tppZdFhgP/C3Qx2+T6eoDfMXc0VMgtWIKr8wW
9uUtpey9vKWkGeCvf8BIqAssIAmCCq78IcE8cPvb1SIpM5yZHOZqkYA5NFlh
02WO5ZpPx8U4gWaAcxWVfY9583VSQg/fZhi2iX4zFGB1z1xk5d8S+9v/+r+3
8/Q+y6Eb38OgcLouixuMAfqv/1PCjv/9Ood5gBeQp+tNlkLz/GLswnqe3ffs
KajGVQJtI3OC4cM+qm7tb2Ekt3kCXT+dgt52ibhmj4o/wYMZzOjrEtbA5bRk
pSX4GFPGME0AiQRmU44JWWg5CzCDySwDAvzBIazXHL6a8/nCHB8bolSBJ0OP
HPoaz4V1ngvEjRvnaNVcUzNPO30s6CcYbPYTYH8c53H95DbVgKpdzgjn2qyi
4ZqkcXihw5J7ctALAcgrzUfVIBdgBDdlspBO//vLd2ev7Levvjt/e/VrGca/
gEirfaf6y7WVK9v/6+mqKp+Os/xpmt/Z5RrYc74vF/nwJixhLT8gZvIC/uwn
5c3dn4Z/lp8RXnnxzTfyF6V15YrI9ytgnvXON/1vdk8cTAIK/zzNd6b5rv21
BOFY35R98sLufPOvg9HHb+y/6o27nTd900frQm7+V5j+nY8cgPeRTjjwjyE3
rnewLXx49+nT0a59YkfRVbpi3JT1n0YT1rnscvPoQL78HDw2WK1Xb89grcgw
iaMIOPZEhext+pEqtwZJOiGeu9XZxS2OHr2lk7eXq7pyNU2EboB0RyONWYlf
vwk3I1t1RJJAE6k4JY/jcXaGrn/NIHAai78M/RsTvTu3tWl6UCuKfkTDkKge
c2elk6ODaJpAw38tzY4MB1vErqVoAPeMmkzTRjfV+dvdl64qSJKbo4h0cBpD
EnAacmlF/lDHYSKPwiY3gm15EjAWLfYlIAGSOwFH0HCJ7NudTau522zjn3Eq
mP8HF313I2fxAAA=
</rfc> </rfc>
 End of changes. 98 change blocks. 
2489 lines changed or deleted 3062 lines changed or added

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