<?xml version="1.0"encoding="UTF-8"?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>encoding="utf-8"?> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 --> <!DOCTYPE rfc SYSTEM"rfc2629.dtd" [ ]> <?rfc toc="yes"?> <?rfc sortrefs="yes"?> <?rfc symrefs="yes"?>"rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-mboned-driad-amt-discovery-13" number="8777" submissionType="IETF" category="std"updates="7450">consensus="true" updates="7450" obsoletes="" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 2.39.0 --> <front> <title abbrev="DRIAD">DNS Reverse IPAMT (AutomaticAutomatic MulticastTunneling)Tunneling (AMT) Discovery</title> <seriesInfo name="RFC" value="8777"/> <author initials="J." surname="Holland" fullname="Jake Holland"> <organization>Akamai Technologies, Inc.</organization> <address> <postal> <street>150 Broadway</street><city>Cambridge, MA 02144</city><city>Cambridge</city><region>MA</region><code>02144</code> <country>United States of America</country> </postal> <email>jakeholland.net@gmail.com</email> </address> </author> <dateyear="2019" month="December" day="20"/>year="2020" month="April"/> <area>Ops</area> <workgroup>Mboned</workgroup><keyword>Internet-Draft</keyword><keyword>example</keyword> <abstract> <t>This document updates RFC7450 (Automatic7450, "Automatic MulticastTunneling, or AMT)Tunneling" (or AMT), by modifying the relay discovery process. A new DNS resource record named AMTRELAY is defined for publishing AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicastsender’ssender's IP address is 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 tunnel. Other extensions and clarifications to the relay discovery process are also defined.</t> </abstract> </front> <middle> <section anchor="intro"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>This document defines DNS Reverse IP AMT Discovery (DRIAD), a mechanism for AMT gateways to discover AMT relays that are capable of forwarding multicast traffic from a known source IP address.</t> <t>AMT (Automatic Multicast Tunneling) is defined in <xreftarget="RFC7450"/>,target="RFC7450" format="default"/> and provides a method to transport multicast traffic over a unicasttunnel,tunnel in order to traversenon-multicast-capablenetworksegments.</t> <t>Section 4.1.5 of <xref target="RFC7450"/>segments that are not multicast capable.</t> <t><xref target="RFC7450" sectionFormat="of" section="4.1.5"/> explains that the relay selection process for AMT is intended to be more flexible than the particular discovery method described in thatdocument, anddocument. That section further explains that the selection process 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>That section<t><xref target="RFC7450" sectionFormat="of" section="4.1.5"/> goes on to suggest DNS-based queries as a possiblesolution.solution: DRIAD isa DNS-based solution, as suggested there.DNS based. This solution also addresses the relay discovery issues in the“Disadvantages”"Disadvantages of this configuration" lists inSection 3.3 ofSections <xreftarget="RFC8313"/>target="RFC8313" sectionFormat="bare" section="3.3"/> andSection 3.4<xref target="RFC8313" sectionFormat="bare" section="3.4"/> of <xref target="RFC8313"/>.</t> <t>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 receiving network is connected to a multicast-enabledbackbone, without pre-configuring any peering arrangement between the networks.</t>backbone.</t> <t>This document extends the relay discovery procedure described inSection 5.2.3.4 of<xreftarget="RFC7450"/>.</t>target="RFC7450" sectionFormat="of" section="5.2.3.4"/>.</t> <section anchor="background"title="Background">numbered="true" toc="default"> <name>Background</name> <t>The reader is assumed to be familiar with the basic DNS concepts described in <xreftarget="RFC1034"/>,target="RFC1034" format="default"/>, <xreftarget="RFC1035"/>,target="RFC1035" format="default"/>, and the subsequent documents that update them, particularly <xreftarget="RFC2181"/>.</t>target="RFC2181" format="default"/>.</t> <t>The reader is also assumed to be familiar with the concepts and terminology regarding source-specific multicast as described in <xreftarget="RFC4607"/>target="RFC4607" format="default"/> and the use ofIGMPv3Internet Group Management Protocol Version 3 (IGMPv3) <xreftarget="RFC3376"/>target="RFC3376" format="default"/> andMLDv2Multicast Listener Discovery Version 2 (MLDv2) <xreftarget="RFC3810"/>target="RFC3810" format="default"/> for group management of source-specific multicast channels, as described in <xreftarget="RFC4604"/>.</t>target="RFC4604" format="default"/>.</t> <t>The reader should also be familiar with AMT, particularly the terminology listed inSection 3.2 ofSections <xreftarget="RFC7450"/>target="RFC7450" sectionFormat="bare" section="3.2"/> andSection 3.3<xref target="RFC7450" sectionFormat="bare" section="3.3"/> of <xref target="RFC7450"/>.</t> </section> <section anchor="terminology"title="Terminology">numbered="true" toc="default"> <name>Terminology</name> <section anchor="relays-and-gateways"title="Relaysnumbered="true" toc="default"> <name>Relays andGateways">Gateways</name> <t>When reading this document,it’sit's especially helpful to recall that once an AMT tunnel is established, the relay receives native multicast traffic and sends unicast tunnel-encapsulated traffic to thegateway, and thegateway. The gateway receives the tunnel-encapsulated packets, decapsulates them, and forwards them as native multicast packets, as illustrated in <xreftarget="figtunnel"/>.</t>target="figtunnel" format="default"/>.</t> <figuretitle="AMTanchor="figtunnel"> <name>AMT TunnelIllustration" anchor="figtunnel"><artwork><![CDATA[Illustration</name> <artwork name="" type="" align="left" alt=""><![CDATA[ Multicast +-----------+ Unicast +-------------+ Multicast >---------> | AMT relay | >=======> | AMT gateway | >---------> +-----------+ +-------------+]]></artwork></figure>]]></artwork> </figure> </section> <section anchor="definitions"title="Definitions"> <texttable> <ttcol align='right'>Term</ttcol> <ttcol align='left'>Definition</ttcol> <c>(S,G)</c> <c>Anumbered="true" toc="default"> <name>Definitions</name> <table align="center"> <name>Definitions</name> <thead> <tr> <th align="right">Term</th> <th align="left">Definition</th> </tr> </thead> <tbody> <tr> <td align="right">(S,G)</td> <td align="left">A source-specific multicast channel, as described in <xreftarget="RFC4607"/>.target="RFC4607" format="default"/>. A pair of IP addresses with a source host IP and destination groupIP.</c> <c>discovery broker</c> <c>AIP.</td> </tr> <tr> <td align="right">CMTS</td> <td align="left">Cable Modem Termination System</td> </tr> <tr> <td align="right">discovery broker</td> <td align="left">A broker or load balancer for AMT relay discovery, as mentioned insection 4.2.1.1 of<xreftarget="RFC7450"/>.</c> <c>downstream</c> <c>Furthertarget="RFC7450" sectionFormat="of" section="4.2.1.1"/>.</td> </tr> <tr> <td align="right">downstream</td> <td align="left">Further from the source of traffic, as described in <xreftarget="RFC7450"/>.</c> <c>FQDN</c> <c>Fullytarget="RFC7450" format="default"/>.</td> </tr> <tr> <td align="right">FQDN</td> <td align="left">Fully Qualified Domain Name, as described in <xreftarget="RFC8499"/></c> <c>gateway</c> <c>Antarget="RFC8499" format="default"/>.</td> </tr> <tr> <td align="right">gateway</td> <td align="left">An AMT gateway, as described in <xreftarget="RFC7450"/></c> <c>L flag</c> <c>The “Limit”target="RFC7450" format="default"/>.</td> </tr> <tr> <td align="right">L flag</td> <td align="left">The "Limit" flag described inSection 5.1.4.4 of<xreftarget="RFC7450"/></c> <c>relay</c> <c>Antarget="RFC7450" sectionFormat="of" section="5.1.4.4"/>.</td> </tr> <tr> <td align="right">OLT</td> <td align="left">Optical Line Terminal</td> </tr> <tr> <td align="right">relay</td> <td align="left">An AMT relay, as described in <xreftarget="RFC7450"/></c> <c>RPF</c> <c>Reversetarget="RFC7450" format="default"/>.</td> </tr> <tr> <td align="right">RPF</td> <td align="left">Reverse Path Forwarding, as described in <xreftarget="RFC5110"/></c> <c>RR</c> <c>Atarget="RFC5110" format="default"/>.</td> </tr> <tr> <td align="right">RR</td> <td align="left">A DNS Resource Record, as described in <xreftarget="RFC1034"/></c> <c>RRType</c> <c>Atarget="RFC1034" format="default"/>.</td> </tr> <tr> <td align="right">RRType</td> <td align="left">A DNS Resource Record Type, as described in <xreftarget="RFC1034"/></c> <c>SSM</c> <c>Source-specifictarget="RFC1034" format="default"/>.</td> </tr> <tr> <td align="right">SSM</td> <td align="left">Source-specific multicast, as described in <xreftarget="RFC4607"/></c> <c>upstream</c> <c>Closertarget="RFC4607" format="default"/>.</td> </tr> <tr> <td align="right">upstream</td> <td align="left">Closer to the source of traffic, as described in <xreftarget="RFC7450"/>.</c> <c>CMTS</c> <c>Cable Modem Termination System</c> <c>OLT</c> <c>Optical Line Terminal</c> </texttable> <t>Thetarget="RFC7450" format="default"/>.</td> </tr> </tbody> </table> </section> <section anchor="reqs" numbered="true" toc="default"> <name>Requirements Language</name> <t> The key words“MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”,"<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and“OPTIONAL”"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> </section> </section> <section anchor="relay-discovery-overview"title="Relaynumbered="true" toc="default"> <name>Relay DiscoveryOverview">Overview</name> <section anchor="basic-mechanics"title="Basic Mechanics">numbered="true" toc="default"> <name>Basic Mechanics</name> <t>The AMTRELAY resource record (RR) defined in this document is used to 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 a particular sender.</t> <t>The sender is the owner of theRR,RR and configures the zone so that it contains a set of RRs that provide the addresses or domain names of AMT relays (or discovery brokers that advertise relays) that can receive multicast IP traffic from that sender.</t> <t>This enables AMT gateways in remote networks to discover an AMT relay that is capable of forwarding traffic from the sender.ThisThis, inturnturn, enables those AMT gateways to receive the multicast traffic tunneled over a unicast AMT tunnel from thoserelays,relays and thentopass the multicast packets into networks or applications that are using the gateway to subscribe to traffic from that sender.</t> <t>This mechanism only works for source-specific multicast (SSM) channels. The source address of the (S,G) is reversed and used as an index into one of the reverse mapping trees (in-addr.arpa for IPv4, as described inSection 3.5 of<xreftarget="RFC1035"/>,target="RFC1035" sectionFormat="of" section="3.5"/>, or ip6.arpa for IPv6, as described inSection 2.5 of<xreftarget="RFC3596"/>).</t>target="RFC3596" sectionFormat="of" section="2.5"/>).</t> <t>This mechanism should be treated as an extension of the AMT relay discovery procedure described inSection 5.2.3.4 of<xreftarget="RFC7450"/>.target="RFC7450" sectionFormat="of" section="5.2.3.4"/>. A gateway that supports this method of AMT relay discoverySHOULD<bcp14>SHOULD</bcp14> use this method wheneverit’sit's performing the relay discovery procedure,andthe source IP addresses for desired (S,G)s are known to the gateway, and conditions match the requirements outlined in <xreftarget="priority"/>.</t>target="priority" format="default"/>.</t> <t>Some detailed example use cases are provided in <xreftarget="exampledeployments"/>,target="exampledeployments" format="default"/>, and other applicable example topologies appear inSection 3.3 ofSections <xreftarget="RFC8313"/>, Section 3.4 oftarget="RFC8313" sectionFormat="bare" section="3.3"/>, <xreftarget="RFC8313"/>,target="RFC8313" sectionFormat="bare" section="3.4"/>, andSection 3.5<xref target="RFC8313" sectionFormat="bare" section="3.5"/> of <xref target="RFC8313"/>.</t> </section> <section anchor="signaling-and-discovery"title="Signalingnumbered="true" toc="default"> <name>Signaling andDiscovery">Discovery</name> <t>This section describes a typical example of the end-to-end process for signaling areceiver’sreceiver's join of an SSM channel that relies on an AMTRELAY RR.</t> <t>The example in <xreftarget="figmessaging"/>target="figmessaging" format="default"/> contains2two multicast-enabled networks that are both connected to the internet with non-multicast-capablelinks,links and which have no direct association with each other.</t> <t>A content provider operates a sender, which is a source of multicast traffic inside a multicast-capable network.</t> <t>An end user who is a customer of the content provider has a multicast-capableinternet service provider,Internet Service Provider (ISP), which operates a receiving network that uses an AMT gateway. The AMT gateway isDRIAD-capable.</t>DRIAD capable.</t> <t>The content provider provides the user with a receiving application that tries to subscribe to at least one (S,G). This receiving applicationcouldcould, forexampleexample, be a file transfer system usingFLUTEFile Delivery over Unidirectional Transport (FLUTE) <xreftarget="RFC6726"/> ortarget="RFC6726" format="default"/>, a live video stream using RTP <xreftarget="RFC3550"/>,target="RFC3550" format="default"/>, or any other application that might subscribe to an SSM channel.</t> <figuretitle="DRIAD Messaging" anchor="figmessaging"><artwork><![CDATA[anchor="figmessaging"> <name>DRIAD Messaging</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +---------------+ | Sender | | | | 2001:db8::a | | | +---------------+ |Data| | |Flow| Multicast | \| |/ Network | \ / | 5: Propagate RPF for Join(S,G) \ / +---------------+ \/ | AMTRelayrelay | | 2001:db8:c::f | +---------------+ | 4: Gateway connects to Relay, sends Join(S,G) over tunnel | Unicast Tunnel | 3: --> DNS Query: type=AMTRELAY, / 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.arpa | | / <-- Response: Join/Leave +-------------+ AMTRELAY=2001:db8:c::f Signals | AMT gateway | | +-------------+ | | 2: Propagate RPF for Join(S,G) | Multicast | Network | | 1: Join(S=2001:db8::a,G=ff3e::8000:d) +-------------+ | Receiver | | (end user) | +-------------+]]></artwork></figure>]]></artwork> </figure> <t>In this simple example, the sender IP is 2001:db8::a,itwhich is sending traffic to the group address ff3e::8000:d, and the relay IP is 2001:db8::c:f.</t> <t>The content provider has previously configured the DNS zone that contains the reverse IP domain name for thesender’ssender's IP address so that it provides an AMTRELAY RR with therelay’srelay's IPaddress. (Seeaddress (see <xreftarget="rpformat"/>target="rpformat" format="default"/> for details about the AMTRELAY RR format andsemantics.)semantics). As described inSection 2.5 of<xreftarget="RFC3596"/>,target="RFC3596" sectionFormat="of" section="2.5"/>, the reverse IP FQDN of thesender’ssender's address“2001:db8::a”"2001:db8::a" is:</t><figure><artwork><![CDATA[<sourcecode name="" type=""><![CDATA[ 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. arpa.]]></artwork></figure>]]></sourcecode> <t>The sequence of events depicted in <xreftarget="figmessaging"/>target="figmessaging" format="default"/> is as follows:</t><t><list style="numbers"> <t>The<ol spacing="normal" type="1"> <li>The end user starts the app, which issues a join to the (S,G): (2001:db8::a,ff3e::8000:d).</t> <t>Theff3e::8000:d).</li> <li>The join propagates with RPF through thereceiver’sreceiver's multicast-enabled network with PIM <xreftarget="RFC7761"/>target="RFC7761" format="default"/> or another multicast routingmechanism,mechanism until the AMT gateway receives a signal to join the(S,G).</t>(S,G).</li> <li> <t>The AMT gateway performs a reverse DNS lookup for the AMTRELAYRRType,RRType by sending an AMTRELAY RRType query for the reverse IP domain name for thesender’ssender's source IP address (the S from the (S,G)).<vspace blankLines='1'/></t> <t> The DNS resolver for the AMT gateway uses ordinary DNS recursive resolution until it has the authoritative result that the content provider configured, which informs the AMT gateway that the relay address is 2001:db8::c:f.</t><t>The</li> <li>The AMT gateway performs AMT handshakes with the AMT relay as described inSection 4 of<xreftarget="RFC7450"/>,target="RFC7450" section="4" sectionFormat="of"/>, then forwards aMembershipmembership report to therelayrelay, indicating subscription to the(S,G).</t> <t>The(S,G).</li> <li>The relay propagates the join through its network toward thesender,sender and then forwards the appropriate AMT-encapsulated traffic to the gateway, which decapsulates and forwards it as a native multicast through its downstream network to the enduser.</t> </list></t>user.</li> </ol> <t>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 inSection 3.5 of<xreftarget="RFC1035"/>,target="RFC1035" sectionFormat="of" section="3.5"/>, 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“12.100.51.198.in-addr.arpa.”.</t>"12.100.51.198.in-addr.arpa.".</t> <t>Note that the address family of the AMT tunnel is independent of the address family for the multicast traffic.</t> </section> <section anchor="exampledeployments"title="Example Deployments">numbered="true" toc="default"> <name>Example Deployments</name> <section anchor="exrx"title="Examplenumbered="true" toc="default"> <name>Example ReceivingNetworks">Networks</name> <section anchor="exrxisp"title="Internetnumbered="true" toc="default"> <name>Internet ServiceProvider">Provider</name> <t>One example of a receiving network is an Internet Service Provider (ISP) that offers multicast ingest services to its subscribers, illustrated in <xreftarget="figrxisp"/>.</t>target="figrxisp" format="default"/>.</t> <t>In the example network below, subscribers can join (S,G)s with MLDv2 or IGMPv3 as described in <xreftarget="RFC4604"/>,target="RFC4604" format="default"/>, and the AMT gateway in this ISP can receive and forward multicast traffic from one of the example sending networks in <xreftarget="extx"/>target="extx" format="default"/> by discovering the appropriate AMT relays with a DNS lookup for the AMTRELAY RR with the reverse IP of the source in the (S,G).</t> <figuretitle="Receivinganchor="figrxisp"> <name>Receiving ISPExample" anchor="figrxisp"><artwork><![CDATA[Example</name> <artwork name="" type="" align="left" alt=""><![CDATA[ Internet ^ ^ Multicast-enabled | | Receiving Network +------|------------|-------------------------+ | | | | | +--------+ +--------+ +=========+ | | | Border |---| Border | | AMT | | | | Router | | Router | | gateway | | | +--------+ +--------+ +=========+ | | | | | | | +-----+------+-----------+--+ | | | | | | +-------------+ +-------------+ | | | Agg Routers | .. | Agg Routers | | | +-------------+ +-------------+ | | / \ \ / \ | | +---------------+ +---------------+ | | |Access Systems | ....... |Access Systems | | | |(CMTS/OLT/etc.)| |(CMTS/OLT/etc.)| | | +---------------+ +---------------+ | | | | | +--------|------------------------|-----------+ | | +---+-+-+---+---+ +---+-+-+---+---+ | | | | | | | | | | /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ /-\ |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| Subscribers]]></artwork></figure>]]></artwork> </figure> </section> <section anchor="exoffice"title="Small Office">numbered="true" toc="default"> <name>Small Office</name> <t>Another example receiving network is a small branch office that regularly accesses some multicast content, illustrated in <xreftarget="figrxofficenm"/>.</t>target="figrxofficenm" format="default"/>.</t> <t>This office has desktop devices that need to receive some multicast traffic, so an AMT gateway runs on a LAN with thesedevices,devices to pull traffic in through a non-multicastnext-hop.</t>next hop.</t> <t>The office also hosts some mobile devices that have AMT gateway instances embedded insideapps,apps in order to receive multicast traffic over their non-multicast wireless LAN. (Note that the“Legacy Router”"Legacy Router" is a simplificationthat’sthat's meant to describe a variety of possible conditions; forexampleexample, it could be a device providing a split-tunnel VPN as described in <xreftarget="RFC7359"/>,target="RFC7359" format="default"/>, deliberately excluding multicast traffic for a VPN tunnel, rather than a devicewhichthat is incapable of multicast forwarding.)</t> <figuretitle="Smallanchor="figrxofficenm"> <name>Small Office(no multicast up)" anchor="figrxofficenm"><artwork><![CDATA[(No Multicast Up)</name> <artwork name="" type="" align="left" alt=""><![CDATA[ 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>]]></artwork> </figure> <t>By adding an AMT relay to this office network as in <xreftarget="figrxoffice"/>, it’starget="figrxoffice" format="default"/>, it's possible to make use of multicast services from the example multicast-capable ISP in <xreftarget="exrxisp"/>.</t>target="exrxisp" format="default"/>.</t> <figuretitle="Smallanchor="figrxoffice"> <name>Small OfficeExample" anchor="figrxoffice"><artwork><![CDATA[Example</name> <artwork name="" type="" align="left" alt=""><![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>]]></artwork> </figure> <t>When multicast-capable networks are chained like this, with a network like the one in <xreftarget="figrxoffice"/>target="figrxoffice" format="default"/> receivinginternetInternet services from a multicast-capable network like the one in <xreftarget="figrxisp"/>, it’starget="figrxisp" format="default"/>, it's important for AMT gateways to reach the more local AMTrelay,relay in order to avoid accidentally tunneling multicast traffic from a more distant AMT relay withunicast,unicast and failing to utilize the multicast transport capabilities of the network in <xreftarget="figrxisp"/>.</t>target="figrxisp" format="default"/>.</t> </section> </section> <section anchor="extx"title="Examplenumbered="true" toc="default"> <name>Example SendingNetworks">Networks</name> <section anchor="extxsnd"title="Sender-controlled Relays">numbered="true" toc="default"> <name>Sender-Controlled Relays</name> <t>When a sender network is also operating AMT relays to distribute multicast traffic, as in <xreftarget="figtxrelay"/>,target="figtxrelay" format="default"/>, each address could appear as an AMTRELAY RR for the reverse IP of thesender, orsender. Alternately, 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> <figuretitle="Smallanchor="figtxrelay"> <name>Small OfficeExample" anchor="figtxrelay"><artwork><![CDATA[Example</name> <artwork name="" type="" align="left" alt=""><![CDATA[ Sender Network +-----------------------------------+ | | | +--------+ +=======+ +=======+ | | | Sender | | AMT | | AMT | | | +--------+ | relay | | relay | | | | +=======+ +=======+ | | | | | | | +-----+------+----------+ | | | | +-----------|-----------------------+ v Internet (non-multicast)]]></artwork></figure>]]></artwork> </figure> </section> <section anchor="extxprv"title="Provider-controlled Relays">numbered="true" toc="default"> <name>Provider-Controlled Relays</name> <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 <xreftarget="figtxisp"/>.target="figtxisp" format="default"/>. In thiscase it’scase, 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>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 theISP,ISP to allow for address reassignment of the relays without forcing the sender to reconfigure the corresponding AMTRELAY RRs.</t> <figuretitle="Sendinganchor="figtxisp"> <name>Sending ISPExample" anchor="figtxisp"><artwork><![CDATA[Example</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +--------+ | Sender | +---+----+ Multicast-enabled | Sending Network +-----------|-------------------------------+ | v | | +------------+ +=======+ +=======+ | | | Agg Router | | AMT | | AMT | | | +------------+ | relay | | relay | | | | +=======+ +=======+ | | | | | | | +-----+------+--------+---------+ | | | | | | +--------+ +--------+ | | | Border |---| Border | | | | Router | | Router | | | +--------+ +--------+ | +-----|------------|------------------------+ | | v v Internet (non-multicast)]]></artwork></figure>]]></artwork> </figure> </section> </section> </section> </section> <section anchor="relay-discovery-operation"title="Relaynumbered="true" toc="default"> <name>Relay DiscoveryOperation">Operation</name> <section anchor="priority"title="Optimalnumbered="true" toc="default"> <name>Optimal RelaySelection">Selection</name> <section anchor="overview"title="Overview">numbered="true" toc="default"> <name>Overview</name> <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 isNOT*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 is able to receive and forward multicast traffic from the sender, that relay is better for the gateway touse,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, itwon’twon't be advertised in thesender’ssender's reverse IP DNS record. An example network that illustrates this scenario is outlined in <xreftarget="figrxoffice"/>target="figrxoffice" format="default"/> from <xreftarget="exoffice"/>.</t> <t>It’starget="exoffice" format="default"/>.</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<ol spacing="normal" type="1"> <li>The gateway needs to propagate a join of an (S,G) overAMT,AMT because in thegateway’sgateway's network, no RPF next hop toward the source can propagate a native multicast join of the(S,G); and</t> <t>The(S,G);</li> <li>The gateway is not already connected to a relay that forwards multicast traffic from the source of the(S,G); and</t> <t>The(S,G);</li> <li>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(S,G);</li> <li>The gateway is not able to find an upstream AMT relay withDNS-SDDNS-based Service Discovery (DNS-SD) <xreftarget="RFC6763"/>,target="RFC6763" format="default"/> using“_amt._udp”"_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 <xreftarget="trafficabsent"/> ortarget="trafficabsent" format="default"/> and <xreftarget="loaded"/>); and</t> <t>Thetarget="loaded" format="counter"/>); and</li> <li>The gateway is not able to find an upstream AMT relay with the well-known anycast addresses fromSection 7 of<xreftarget="RFC7450"/>.</t> </list></t>target="RFC7450" sectionFormat="of" section="7"/>.</li> </ol> <t>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>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 theDNS-SD service is not source-specific, so even though when available, several methods of finding a more local source of multicast traffic connectivityabove conditions arepreferreddesigned tousingprefer the use of a local AMT relayprovided by an AMTRELAY RR, a gateway furtherif one can be discovered. However, note also that the network upstream of the locally discovered relay would stillbe usingneed to receive traffic from theAMTRELAY RRsender of the (S,G) in order to forward it. Therefore, unless the upstream networkhas a peeringcontains the sender or has a multicast-capable peering with a network thatprovides an alternative end-to-end multicast transport path forcan forward traffic from the(S,G)’s traffic.</t>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"/> connected as one of the customers to the network in <xref target="figrxisp"/>.</t> </section> <section anchor="ordering"title="Preference Ordering">numbered="true" toc="default"> <name>Preference Ordering</name> <t>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"/> algorithm to try candidate relaysconcurrently,concurrently (see <xref target="happy"/>), but even gateways that do not implement a Happy Eyeballs algorithmSHOULD<bcp14>SHOULD</bcp14> use this ordering, except as noted.</t> <t>When establishing an AMT tunnel to forward multicast data,it’sit's very important for the discovery process to prioritizethenetwork topology considerations ahead of address selectionconsiderations,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 joinlatency,latency while still prioritizing network efficiency considerations overAddress Selectionaddress selection considerations.</t><t>Section 4 of <xref target="RFC8305"/><t><xref target="RFC8305" sectionFormat="of" section="4"/> requires a Happy Eyeballs algorithm to sort the addresses with the Destination Address Selection defined inSection 6 of<xreftarget="RFC6724"/>,target="RFC6724" sectionFormat="of" section="6"/>, but for the above reasons, that requirement is superseded in the AMT discovery use case by the following considerations:</t><t><list style="symbols"><ul spacing="normal"> <li> <t>Prefer Local Relays<vspace blankLines='1'/> <xref target="figrxoffice"/></t> <t><xref target="figrxoffice" format="default"/> and <xreftarget="exoffice"/>target="exoffice" format="default"/> provide a motivating example to prefer DNS-SD <xreftarget="RFC6763"/>target="RFC6763" format="default"/> for discovery strictly ahead of using the AMTRELAY RR controlled by the sender for AMTdiscovery. <vspace blankLines='1'/>discovery.</t> <t> For this reason,it’s RECOMMENDEDit's <bcp14>RECOMMENDED</bcp14> that AMT gateways by default perform service discovery using DNS Service Discovery (DNS-SD) <xreftarget="RFC6763"/>target="RFC6763" format="default"/> for _amt._udp.<domain> (with <domain> chosen as described inSection 11 of<xreftarget="RFC6763"/>)target="RFC6763" sectionFormat="of" section="11"/>) and use the AMT relays discovered that way in preference to AMT relays discoverable via the mechanism defined in this document (DRIAD).</t> </li> <li> <t>Prefer Relays Managed by the Containing Network<vspace blankLines='1'/></t> <t> 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'/></t> <t> In this case, when the network cannot make the relay discoverable via DNS-SD, the networkSHOULD<bcp14>SHOULD</bcp14> use the well-known anycast addresses fromSection 7 of<xreftarget="RFC7450"/>target="RFC7450" format="default" section="7"/> to route discovery traffic to the relay most appropriate to thereceiver’s gateway. <vspace blankLines='1'/>receiver's gateway.</t> <t> Accordingly, the gatewaySHOULD<bcp14>SHOULD</bcp14> by default discover a relay with the well-known AMT anycast addresses as thesecond preferencenext-best option after DNS-SD when searching for a local relay.</t> </li> <li> <t>Let Sender Manage Relay Provisioning<vspace blankLines='1'/></t> <t> A related motivating example is provided by considering a sender whose traffic can be forwarded by relays in a sender-controlled network like <xreftarget="figtxrelay"/>target="figtxrelay" format="default"/> in <xreftarget="extxsnd"/>,target="extxsnd" format="default"/> andalsoby relays in a provider-controlled network like <xreftarget="figtxisp"/>target="figtxisp" format="default"/> in <xreftarget="extxprv"/>,target="extxprv" format="default"/>, with different cost and scalability profiles for the different options.<vspace blankLines='1'/></t> <t> In this example about the sending-side network, the precedence field described in <xreftarget="rrdef-precedence"/>target="rrdef-precedence" format="default"/> is a critical method of control so that senders can provide the appropriate guidance to gateways during the discoveryprocess,process in order to manage load and failover scenarios in a manner that operates well with thesender’ssender's provisioning strategy for horizontal scaling of AMT relays.<vspace blankLines='1'/></t> <t> Therefore, after DNS-SD, the precedence from the RRMUST<bcp14>MUST</bcp14> be used for sorting preference ahead of the Destination Address Selection ordering fromSection 6 of<xreftarget="RFC6724"/>,target="RFC6724" section="6" sectionFormat="of"/> so that only relay IPs with the same precedence are directly compared according to the Destination Address Selection ordering.</t></list></t></li> </ul> <t>Accordingly, AMT gatewaysSHOULD<bcp14>SHOULD</bcp14> by default prefer relays in this order:</t><figure><artwork><![CDATA[ 1. DNS-SD 2. Anycast<ol> <li>DNS-SD</li> <li>Anycast addresses fromSection 7 of [RFC7450] 3. DRIAD ]]></artwork></figure><xref target="RFC7450" sectionFormat="of" section="7"/></li> <li>DRIAD</li> </ol> <t>This default behaviorMAY<bcp14>MAY</bcp14> 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 AMTSHOULD<bcp14>SHOULD</bcp14> use the Destination Address Selection defined inSection 6 of<xreftarget="RFC6724"/>.</t>target="RFC6724" sectionFormat="of" section="6"/>.</t> <t>Among relay addresses that still have an equivalent preference after the above orderings, a gatewaySHOULD<bcp14>SHOULD</bcp14> make a non-deterministic choice (such as a pseudorandom selection) for relay preferenceordering,ordering in order to support load balancing by DNS configurations that provide many relay options.</t> <t>The gatewayMAY<bcp14>MAY</bcp14> introduce a bias in the non-deterministic choice according to informationobtained out of band or from a historical record about network topology, timing information, or the response to a probing mechanism,that indicatessomeexpected benefits from selecting some relays in preference to others. Details about the structure and collection of this information are out of scope for thisdocument,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 informationMAY<bcp14>MAY</bcp14> use it to prefer topologically closer relays.</t> <t>Within the above constraints, gatewaysMAY<bcp14>MAY</bcp14> make use of other considerations fromSection 4 of<xreftarget="RFC8305"/>,target="RFC8305" sectionFormat="of" section="4"/>, such as the address family interleaving 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 <xreftarget="trafficabsent"/>target="trafficabsent" format="default"/> or <xreftarget="loaded"/>.target="loaded" format="counter"/>. These relays constitute“unusable destinations”"unusable destinations" under Rule 1 of the Destination AddressSelection,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 orderingMAY<bcp14>MAY</bcp14> operate in parallel, subject to delays prescribed by the Happy Eyeballs requirements described inSection 5 of<xreftarget="RFC8305"/>target="RFC8305" sectionFormat="of" section="5"/> for successively launched concurrent connection attempts.</t> </section> <section anchor="connecting-to-multiple-relays"title="Connectingnumbered="true" toc="default"> <name>Connecting to MultipleRelays">Relays</name> <t>In some deployments, it may be useful for a gateway to connect to multiple upstream relays and subscribe to the sametraffic,traffic in order to support an active/active failover model. A gatewaySHOULD NOT<bcp14>SHOULD NOT</bcp14> be configured to do so without guaranteeing that adequate bandwidth is available.</t> <t>A gateway configured to do thisSHOULD<bcp14>SHOULD</bcp14> still use the samepreference orderingpreference-ordering logic from <xreftarget="ordering"/>target="ordering" format="default"/> 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">numbered="true" toc="default"> <name>Happy Eyeballs</name> <section anchor="overview-1"title="Overview">numbered="true" toc="default"> <name>Overview</name> <t>Often, multiple choices of relay will exist for a gateway using DRIAD for relay discovery. Happy Eyeballs <xreftarget="RFC8305"/>target="RFC8305" format="default"/> provides a widely deployed and generalizable strategy for probing multiple possible connections inparallel, thereforeparallel. Therefore, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that DRIAD-capable gateways implement a Happy Eyeballs algorithm to support fast discovery of the most preferred availablerelay,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 <xreftarget="ordering"/> takentarget="ordering" format="default"/> 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 <xreftarget="connection-def"/>target="connection-def" format="default"/> of this document, establishing the connection occurs before sending a membership report. As described inSection 5 of<xreftarget="RFC8305"/>,target="RFC8305" sectionFormat="of" section="5"/>, 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 chosenconnection,connection after the Happy Eyeballs algorithm resolves.</t> </section> <section anchor="algorithm-guidelines"title="Algorithm Guidelines">numbered="true" toc="default"> <name>Algorithm Guidelines</name> <t>During the“Initiation"Initiation of asynchronous DNSqueries”queries" phase described inSection 3 of<xreftarget="RFC8305"/>),target="RFC8305" sectionFormat="of" section="3"/>, a gateway attempts to resolve the domain names listed in <xreftarget="priority"/>.target="priority" format="default"/>. 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 mightcontain onecontain:</t> <ul spacing="normal"> <li>one or more IPaddresses,addresses (as with type 1 or type 2 AMTRELAYresponses,responses or when the SRV Additional Data section of the SRV response contains the address records for the target, as urged by <xreftarget="RFC2782"/>), or they might containtarget="RFC2782" format="default"/>), or</li> <li> only domain names (as with type 3 responses from <xreftarget="rtype"/>,target="rtype" format="default"/> or an SRV response without an additional datasection).</t>section).</li></ul> <t>When present, IP addresses in the initial response provide resolved destination address candidates for the“Sorting"Sorting of resolved destinationaddresses”addresses" phase described inSection 4 of<xreftarget="RFC8305"/>),target="RFC8305" sectionFormat="of" section="4"/>), 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 responsesdon’tdon't have a bound on the count of queries that might be generated aside from the bounds imposed by the DNS resolver,it’sit'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 gatewayMAY<bcp14>MAY</bcp14> use an existing DNS client implementation that doesso,so andMAY<bcp14>MAY</bcp14> rely on thatclient’s rate limitingclient's rate-limiting logic to avoid issuing excessive queries. Otherwise, a gatewayMUST<bcp14>MUST</bcp14> provide a rate limit for the DNS queries, and its default settingsSHOULD NOT<bcp14>SHOULD NOT</bcp14> permit more than 10 queries for any 100-millisecond period (though thisMAY<bcp14>MAY</bcp14> be overridable by the administrative configuration).</t> <t>As the resolved IP addresses arrive, the Happy Eyeballs algorithm sorts them according to the requirements and recommendations given in <xreftarget="ordering"/>,target="ordering" format="default"/> and attempts connections with the corresponding relays under the algorithm restrictions and guidelines given in <xreftarget="RFC8305"/>target="RFC8305" format="default"/> for the“Establishment"Establishment of one connection, which cancels all otherattempts”attempts" phase. As described inSection 3 of<xreftarget="RFC8305"/>,target="RFC8305" sectionFormat="of" section="3"/>, 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"/>numbered="true" toc="default"> <name>Connection Definition</name> <t><xref target="RFC8305" sectionFormat="of" section="5"/> non-normatively describessuccess ata successful connection attempt as“generally"generally when the TCP handshakecompletes”.</t>completes".</t> <t>There is no normative definition of a connection in the AMT specification <xreftarget="RFC7450"/>,target="RFC7450" format="default"/>, and there is no TCP connection involved in an AMT tunnel.</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<ul spacing="normal"> <li>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"/>)(<xref target="RFC7450" sectionFormat="of" section="5.1.4"/>) that does not have the L flagset.</t> </list></t>set.</li> </ul> <t>See <xreftarget="loaded"/>target="loaded" format="default"/> of this document for further information about the relevance of the L flag to the establishment of a Happy Eyeballs connection. See <xreftarget="flowhealth"/>target="flowhealth" format="default"/> for an overview of how to respond if the connection does not provide multicast connectivity to the source.</t> <t>To“cancel”"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="Guidelinesnumbered="true" toc="default"> <name>Guidelines for RestartingDiscovery">Discovery</name> <section anchor="overview-2"title="Overview"> <t>It’snumbered="true" toc="default"> <name>Overview</name> <t>It's expected that gateways deployed in different environments will use a variety of heuristics to decide whenit’sit's appropriate to restart the relay discoveryprocess,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 thissection,section but may cause a disruption in the forwarded traffic if the discovery process results in choosing a differentrelay,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="Updatesnumbered="true" toc="default"> <name>Updates to RestartingEvents"> <t>Section 5.2.3.4.1 of <xref target="RFC7450"/>Events</name> <t><xref target="RFC7450" sectionFormat="of" section="5.2.3.4.1"/> lists several events that may cause 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 first5five events are copied here and numbered for easier reference, and the remaining4four events are newly added for consideration in this document:</t><t><list style="numbers"> <t>When<ol spacing="normal" type="1"> <li>When a gateway pseudo-interface is started(enabled).</t> <t>When(enabled).</li> <li>When the gateway wishes to report a group subscription when none currentlyexist.</t> <t>Beforeexists.</li> <li>Before sending the next Request message in a membership updatecycle.</t> <t>Aftercycle.</li> <li>After the gateway fails to receive a response to a Requestmessage.</t> <t>Aftermessage.</li> <li>After the gateway receives a Membership Query message with the L flag set to1.</t> <t>When1.</li> <li>When the gateway wishes to report an (S,G) subscription with a source address that does not currently have other groupsubscriptions.</t> <t>Whensubscriptions.</li> <li>When there is a network changedetected,detected; forexampleexample, when a gateway is operating inside an end user device orapplication,application and the device joins a differentnetwork,network or when the domain portion of a DNS-SD domain name changes in response to a DHCP message or administrativeconfiguration.</t> <t>Whenconfiguration.</li> <li>When substantial loss, persistent congestion, or network overload is detected in the stream of AMT packets from arelay.</t> <t>Whenrelay.</li> <li>When the gateway has reported one or more (S,G)subscriptions,subscriptions but no traffic is received from the source for sometimeout. (Seetimeout (see <xreftarget="trafficabsent"/>).</t> </list></t>target="trafficabsent" format="default"/>).</li> </ol> <t>This list is not exhaustive, nor are any of the listed events strictly required to always force a restart of the discovery process.</t> <t>Note that during event #1, a gateway may useDNS-SD,DNS-SD but does not have sufficient information to use DRIAD, since no source is known.</t> </section> <section anchor="stability"title="Tunnel Stability">numbered="true" toc="default"> <name>Tunnel Stability</name> <t>In general, subscribers to active traffic flows that are being forwarded by an AMT gateway are less likely to experience a degradation in service (for example, from missing or duplicated packets) when the gateway continues using the samerelay,relay as long as the relay is not overloaded and the network conditions remain stable.</t> <t>Therefore, gatewaysSHOULD<bcp14>SHOULD</bcp14> avoid performing a full restart of the discovery process during routine cases of event #3 (sending a new Request message), since it occurs frequently in normal operation.</t> <t>However, see Sections <xreftarget="flowhealth"/>,target="flowhealth" format="counter"/>, <xreftarget="discoverymessage"/>,target="discoverymessage" format="counter"/>, and <xreftarget="ancient"/>target="ancient" format="counter"/> for more information about exceptional cases when it may be appropriate to use event #3.</t> </section> <section anchor="flowhealth"title="Traffic Health">numbered="true" toc="default"> <name>Traffic Health</name> <section anchor="trafficabsent"title="Absencenumbered="true" toc="default"> <name>Absence ofTraffic">Traffic</name> <t>If a gateway indicates one or more (S,G) subscriptions in a Membership Updatemessage,message but no traffic for any of the (S,G)s is received in a reasonable time,it’sit's appropriate for the gateway to restart the discovery process.</t> <t>If the gateway restarts the discovery process multiple times consecutively for this reason, the timeout periodSHOULD<bcp14>SHOULD</bcp14> be adjusted to provide a random exponential back-off.</t> <t>TheRECOMMENDED<bcp14>RECOMMENDED</bcp14> timeout is a random value in the range [initial_timeout, MIN(initial_timeout * 2^retry_count, maximum_timeout)], with aRECOMMENDED<bcp14>RECOMMENDED</bcp14> initial_timeout of 4 seconds and aRECOMMENDED<bcp14>RECOMMENDED</bcp14> maximum_timeout of 120 seconds (which is the recommended minimum NAT mapping timeout described in <xreftarget="RFC4787"/>).</t>target="RFC4787" format="default"/>).</t> <t>Note that the recommended initial_timeout is larger than the initialtimouttimeout recommended in the similar algorithm fromSection 5.2.3.4.3 of<xreftarget="RFC7450"/>.target="RFC7450" sectionFormat="of" section="5.2.3.4.3"/>. This is to provide time for RPF Join propagation in the sending network. Although the timeout values may be administratively adjusted to support performance requirements, operators are advised to consider the possibility of join propagation delays between the sender and the relay when choosing an appropriate timeout value.</t> <t>Gateways restarting the discovery process because of an absence of trafficMUST<bcp14>MUST</bcp14> use a hold-down timer that removes this relay from consideration during subsequent rounds of discovery while active. The hold-downSHOULD<bcp14>SHOULD</bcp14> last for no less than 3 minutes and no more than 10 minutes.</t> </section> <section anchor="loss-and-congestion"title="Lossnumbered="true" toc="default"> <name>Loss andCongestion">Congestion</name> <t>In some gateway deployments, it is also feasible to monitor the health of traffic flows through thegateway,gateway -- forexampleexample, by detecting the rate of packet loss by communicating out of band withreceivers,receivers or monitoring the packets of known protocols with sequence numbers. Where feasible,it’sit's encouraged for gateways to use such traffic health information to trigger a restart of the discovery process during event #3 (before sending a new Request message).</t> <t>However,to avoid synchronized rediscovery by many gateways simultaneously afterif a transient network eventupstream of athat affects the tunneled multicast stream -- as opposed to an event that affects the tunnel connection between the relayresults in many receivers detectingand gateway -- occurs, poorflowhealthat the same time, it’s recommended to adddetection could be triggered for many gateways simultaneously. In this situation, adding a random delaybefore restarting the discovery process in this case.</t>to avoid synchronized rediscovery by many gateways is recommended.</t> <t>The span of the random portion of the delay should be no less than 10 seconds bydefault,default but may be administratively configured to support different performance requirements.</t> </section> <section anchor="ancient"title="Ancientnumbered="true" toc="default"> <name>Ancient DiscoveryInformation">Information</name> <t>In most cases, a gateway actively receiving healthy traffic from a relay that has not indicated load with the L flag should prefer to remain connected to the same relay, as described in <xreftarget="stability"/>.</t>target="stability" format="default"/>.</t> <t>However, a relay that appears healthy but has been forwarding traffic for days or weeks may have an increased chance of becoming unstable. Gateways may benefit from restarting the discovery process during event #3 (before sending a Request message) after the expiration of a long-termtimeout,timeout on the order of multiplehours,hours or even days in some deployments.</t> <t>It may be beneficial for such timers to consider the amount of traffic currently beingforwarded,forwarded and to give a higher probability of restarting discovery during periods with an unusually low datarate,rate to reduce the impact on active traffic while still avoiding relying on the results of a very old discovery.</t> <t>Other issues may also be worth considering as part of this heuristic; for example, if the DNS expiry time of the record that was used to discover the current relay has not passed, thelong termlong-term timer might be restarted without restarting the discovery process.</t> </section> </section> <section anchor="loaded"title="Relaynumbered="true" toc="default"> <name>Relay Loaded or ShuttingDown">Down</name> <t>The L flag (seeSection 5.1.4.4 of<xreftarget="RFC7450"/>)target="RFC7450" sectionFormat="of" section="5.1.4.4"/>) is the preferred mechanism for a relay to signal overloading or a graceful shutdown to gateways.</t> <t>A gateway that supports handling of the L flag should generally restart 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 discovery process isunder wayunderway for multiple candidate relays (<xreftarget="happy"/>),target="happy" format="default"/>), the relay sending the L flagSHOULD NOT<bcp14>SHOULD NOT</bcp14> be considered for the relay selection.</t> <t>It is alsoRECOMMENDED<bcp14>RECOMMENDED</bcp14> that gateways avoid choosing a relay that has recently sent an L flag, with approximately a 10-minute hold-down. GatewaysSHOULD<bcp14>SHOULD</bcp14> treat this hold-down timer in the same way as the hold-down in <xreftarget="trafficabsent"/>,target="trafficabsent" format="default"/> so that the relay is removed from consideration forshort-termsubsequent short-term rounds of discovery.</t> </section> <section anchor="discoverymessage"title="Relaynumbered="true" toc="default"> <name>Relay Discovery Messages vs. RestartingDiscovery">Discovery</name> <t>All AMT relays are required by <xreftarget="RFC7450"/>target="RFC7450" format="default"/> to support handling of Relay Discovery messages(e.g.(e.g., inSection 5.3.3.2 of<xreftarget="RFC7450"/>).</t>target="RFC7450" sectionFormat="of" section="5.3.3.2"/>).</t> <t>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 conditions with an unloaded relay,it’sit's expected that the relay will return its own unicast address in the RelayAdvertisement,Advertisement in response to such a Relay Discovery message. Since this will not result in the gateway changing to another relay unless the relay directs the gateway away, this is a reasonable exception to the advice against handling event #3 described in <xreftarget="stability"/>.</t>target="stability" format="default"/>.</t> <t>This behavior is discouraged for gateways that do support the Lflag,flag to avoid sending unnecessary packets over the network.</t> <t>However, gateways that do not support the L flag may be able to avoid a disruption in the forwarded traffic by sending such Relay Discovery 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 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 simply stops responding to Requestmessages,messages and stops forwarding traffic.</t> <t>This style of Relay Discovery message (one sent to the unicast address of a relaythat’sthat's already forwarding traffic to this gateway)SHOULD NOT<bcp14>SHOULD NOT</bcp14> be considered a full restart of the relay discovery process. It isRECOMMENDED for<bcp14>RECOMMENDED</bcp14> that gatewaystosupport the L flag, but for gateways that do not support the L flag, sending this message during event #3 may help mitigate service degradation when relays become unstable.</t> </section> <section anchor="independent-discovery-per-traffic-source"title="Independentnumbered="true" toc="default"> <name>Independent DiscoveryPerper TrafficSource">Source</name> <t>Relays discovered via the AMTRELAY RR are source-specific relayaddresses,addresses and may use different pseudo-interfaces from each other and from relays discovered via DNS-SD or via a non-source-specific address, as described inSection 4.1.2.1 of<xreftarget="RFC7450"/>.</t>target="RFC7450" sectionFormat="of" section="4.1.2.1"/>.</t> <t>Restarting the discovery process for one pseudo-interface does not require restarting the discovery process for other pseudo-interfaces. Gateway heuristics about restarting the discovery process should operate independently for different tunnels torelays,relays when responding to events that are specific to the different tunnels.</t> </section> </section> <section anchor="dns-configuration"title="DNS Configuration"> <t>Oftennumbered="true" toc="default"> <name>DNS Configuration</name> <t>Often, an AMT gateway will only have access to the source and group IP addresses of the desiredtraffic,traffic and will not know any other name for the source of the traffic. Because of this,typicallytypically, the best way of looking up AMTRELAY RRs 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 inSection 3.5 of<xreftarget="RFC1035"/>,target="RFC1035" sectionFormat="of" section="3.5"/>, or ip6.arpa for IPv6, as described inSection 2.5 of<xreftarget="RFC3596"/>).</t>target="RFC3596" sectionFormat="of" section="2.5"/>).</t> <t>Therefore, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that AMTRELAY RRs be added to reverse IP zones as appropriate. AMTRELAY recordsMAY<bcp14>MAY</bcp14> also appear in other zones, since this may be necessary to perform delegation from the reverse zones(see(see, forexample Section 5.2 ofexample, <xreftarget="RFC2317"/>),target="RFC2317" sectionFormat="of" section="5.2"/>), but the use case enabled 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 not define semantics for the use of AMTRELAY records obtained in a way other than by a reverse IP lookup.</t> <t>When performing the AMTRELAY RR lookup, any CNAMEs or DNAMEs foundMUST<bcp14>MUST</bcp14> be followed. This is necessary to support zone delegation. Some examples outlining this need are described in <xreftarget="RFC2317"/>.</t>target="RFC2317" format="default"/>.</t> <t>See Sections <xreftarget="rrdef"/>target="rrdef" format="counter"/> and <xreftarget="rpformat"/>target="rpformat" format="counter"/> for a detailed explanation of the contentsforof a DNSZonezone file.</t> </section> <section anchor="waiting-for-dns-resolution"title="Waitingnumbered="true" toc="default"> <name>Waiting for DNSresolution"> <t>The DNSResolution</name> <t>DNS query functionality is expected to follow ordinary standards and best practices for DNS clients. A gatewayMAY<bcp14>MAY</bcp14> use an existing DNS client implementation that doesso,so andMAY<bcp14>MAY</bcp14> rely on thatclient’sclient's retry logic to determine the timeouts between retries.</t> <t>Otherwise, a gatewayMAY re-send<bcp14>MAY</bcp14> resend a DNS query if it does not receive an appropriate DNS response within some timeout period. If the gateway retries multiple times, the timeout periodSHOULD<bcp14>SHOULD</bcp14> be adjusted to provide a random exponential back-off.</t> <t>As with the waiting process for the Relay Advertisement message fromSection 5.2.3.4.3 of<xreftarget="RFC7450"/>,target="RFC7450" sectionFormat="of" section="5.2.3.4.3"/>, theRECOMMENDED<bcp14>RECOMMENDED</bcp14> timeout is a random value in the range [initial_timeout, MIN(initial_timeout * 2^retry_count, maximum_timeout)], with aRECOMMENDED<bcp14>RECOMMENDED</bcp14> initial_timeout of 1 second and aRECOMMENDED<bcp14>RECOMMENDED</bcp14> maximum_timeout of 120 seconds.</t> </section> </section> <section anchor="rrdef"title="AMTRELAYnumbered="true" toc="default"> <name>AMTRELAY Resource RecordDefinition">Definition</name> <section anchor="amtrelay-rrtype"title="AMTRELAY RRType">numbered="true" toc="default"> <name>AMTRELAY RRType</name> <t>The AMTRELAY RRType has the mnemonic AMTRELAY and type code 260 (decimal).</t> <t>The AMTRELAY RR is class independent.</t> </section> <section anchor="amtrelay-rdata-format"title="AMTRELAYnumbered="true" toc="default"> <name>AMTRELAY RDataFormat">Format</name> <t>The AMTRELAY RData consists ofaan 8-bit precedence field, a 1-bit“Discovery Optional”"Discovery Optional" field, a 7-bit type field, and a variable length relay field.</t><figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | precedence |D| type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ relay ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork></figure>]]></artwork> <section anchor="rrdef-precedence"title="RDatanumbered="true" toc="default"> <name>RData Format -Precedence">Precedence</name> <t>This is an 8-bit precedence for this record. It is interpreted in the same way as the PREFERENCE field described inSection 3.3.9 of<xreftarget="RFC1035"/>.</t>target="RFC1035" sectionFormat="of" section="3.3.9"/>.</t> <t>Relays listed in AMTRELAY records with a lower value for precedence are to be attempted first.</t> </section> <section anchor="rrdef-dbit"title="RDatanumbered="true" toc="default"> <name>RData Format - Discovery Optional(D-bit)">(D-bit)</name> <t>TheD bitD-bit is a“Discovery Optional”"Discovery Optional" flag.</t> <t>If theD bitD-bit is set to 0, a gateway using this RRMUST<bcp14>MUST</bcp14> perform AMT relay discovery as described inSection 4.2.1.1 of<xreftarget="RFC7450"/>,target="RFC7450" sectionFormat="of" section="4.2.1.1"/> rather than directly sending an AMT Request message to the relay.</t> <t>That is, the gatewayMUST<bcp14>MUST</bcp14> receive an AMT Relay Advertisement message(Section 5.1.2 of <xref target="RFC7450"/>)(<xref target="RFC7450" sectionFormat="of" section="5.1.2"/>) for an address before sending an AMT Request message(Section 5.1.3 of <xref target="RFC7450"/>)(<xref target="RFC7450" sectionFormat="of" section="5.1.3"/>) to that address. Before receiving the Relay 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 devices that are not fully functional AMTrelays,relays but rather load balancers or brokers, as mentioned inSection 4.2.1.1 of<xreftarget="RFC7450"/>.</t>target="RFC7450" sectionFormat="of" section="4.2.1.1"/>.</t> <t>If theD bitD-bit is set to 1, the gatewayMAY<bcp14>MAY</bcp14> send an AMT Request message directly to the discovered relay address without first sending an AMT Discovery message.</t> <t>This bit should be set according to advice from the AMT relay operator. TheD bit MUSTD-bit <bcp14>MUST</bcp14> be set to zero when no information is available from the AMT relay operator about its suitability.</t> </section> <section anchor="rtype"title="RDatanumbered="true" toc="default"> <name>RData Format -Type">Type</name> <t>The type field indicates the format of the information that is stored in the relay field.</t> <t>The following values are defined:</t><t><list style="symbols"> <t>type<ul spacing="normal"> <li>type = 0: The relay field is empty (0bytes).</t> <t>typebytes).</li> <li>type = 1: The relay field contains a 4-octet IPv4address.</t> <t>typeaddress.</li> <li>type = 2: The relay field contains a 16-octet IPv6address.</t> <t>typeaddress.</li> <li>type = 3: The relay field contains a wire-encoded domain name. The wire-encoded format is self-describing, so the length is implicit. The domain nameMUST NOT<bcp14>MUST NOT</bcp14> becompressed. (See Section 3.3 ofcompressed (see <xreftarget="RFC1035"/>target="RFC1035" sectionFormat="of" section="3.3"/> andSection 4 of<xreftarget="RFC3597"/>.)</t> </list></t>target="RFC3597" sectionFormat="of" section="4"/>).</li> </ul> <t>RRs with an undefined value in the Type fieldSHOULD NOT<bcp14>SHOULD NOT</bcp14> be considered by receiving gateways for AMT relay discovery.</t> </section> <section anchor="rdformat"title="RDatanumbered="true" toc="default"> <name>RData Format -Relay">Relay</name> <t>The relay field is the address or domain name of the AMT relay. It is formatted according to the type field.</t> <t>When the type field is 0, the length of the relay field is 0, and it indicates that no AMT relay should be used for multicast traffic from this source.</t> <t>When the type field is 1, the length of the relay field is 4 octets, and a 32-bit IPv4 address is present. This is an IPv4 address as described inSection 3.4.1 of<xreftarget="RFC1035"/>.target="RFC1035" sectionFormat="of" section="3.4.1"/>. This is a 32-bit number in network byte order.</t> <t>When the type field is 2, the length of the relay field is 16 octets, and a 128-bit IPv6 address is present. This is an IPv6 address as described inSection 2.2 of<xreftarget="RFC3596"/>.target="RFC3596" sectionFormat="of" section="2.2"/>. 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 name, as described inSection 3.3 of<xreftarget="RFC1035"/>. Compression MUST NOT be used, fortarget="RFC1035" sectionFormat="of" section="3.3"/>. For the reasons given inSection 4 of<xreftarget="RFC3597"/>.</t>target="RFC3597" sectionFormat="of" section="4"/>, compression <bcp14>MUST NOT</bcp14> be used.</t> <t>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 result of the discovery process whenit’sit's obtained by type 1 or type 2 AMTRELAY records with identical D-bit and preferencefields,fields vs. when 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> </section> </section> <section anchor="rpformat"title="AMTRELAYnumbered="true" toc="default"> <name>AMTRELAY Record PresentationFormat">Format</name> <section anchor="representation-of-amtrelay-rrs"title="Representationnumbered="true" toc="default"> <name>Representation of AMTRELAYRRs">RRs</name> <t>AMTRELAY RRs may appear in a zone data master file. The precedence, D-bit, relay type, and relay fields areREQUIRED.</t><bcp14>REQUIRED</bcp14>.</t> <t>If the relay type field is 0, the relay fieldMUST<bcp14>MUST</bcp14> be“.”.</t>".".</t> <t>The presentation for the record is as follows:</t><figure><artwork><![CDATA[<sourcecode name="" type=""><![CDATA[ IN AMTRELAY precedence D-bit type relay]]></artwork></figure>]]></sourcecode> </section> <section anchor="examples"title="Examples">numbered="true" toc="default"> <name>Examples</name> <t>In a DNS authoritative nameserver that understands the AMTRELAY type, the zone might contain a set of entries like this:</t><figure><artwork><![CDATA[<sourcecode name="" type=""><![CDATA[ $ORIGIN 100.51.198.in-addr.arpa. 12 IN AMTRELAY 10 0 1 203.0.113.15 12 IN AMTRELAY 10 0 2 2001:db8::15 12 IN AMTRELAY 128 1 3 amtrelays.example.com.]]></artwork></figure>]]></sourcecode> <t>This configuration advertises an IPv4 discovery address, an IPv6 discovery address, and a domain name for AMT relayswhichthat can receive 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 described in <xreftarget="rrdef-dbit"/>),target="rrdef-dbit" format="default"/>) and a precedence 10 (meaningthey’rethey're preferred ahead of the last entry, which has precedence 128).</t> <t>For zone files in name servers thatdon’tdon't support the AMTRELAY RRType natively,it’sit's possible to use the format for unknown RR types, as described in <xreftarget="RFC3597"/>.target="RFC3597" format="default"/>. This approach would replace the AMTRELAY entries in the example above with the entries below:</t><figure><artwork><![CDATA[<sourcecode name="" type=""><![CDATA[ 10 IN TYPE260 \# ( 6 ; length 0a ; precedence=10 01 ; D=0, relay type=1, an IPv4 address cb00710f ) ; 203.0.113.15 10 IN TYPE260 \# ( 18 ; length 0a ; precedence=10 02 ; D=0, relay type=2, an IPv6 address 20010db800000000000000000000000f ) ; 2001:db8::15 10 IN TYPE260 \# ( 24 ; length 80 ; precedence=128 83 ; D=1, relay type=3, a wire-encoded domain name 09616d7472656c617973076578616d706c6503636f6d ) ; domain name]]></artwork></figure>]]></sourcecode> <t>See <xreftarget="extranslate"/>target="extranslate" format="default"/> for more details.</t> </section> </section> </section> <section anchor="iana"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>This document updates theIANA Registry forDNSResource"Resource RecordTypes(RR) TYPEs" registry by assigning type 260 to the AMTRELAY record.</t> <t>This document creates a new registry named“AMTRELAY"AMTRELAY Resource RecordParameters”,Parameters" with asub-registrysubregistry for the“Relay"Relay TypeField”.Field". The initial values in thesub-registrysubregistry are:</t><figure><artwork><![CDATA[ +-------+---------------------------------------+ | Value | Description | +-------+---------------------------------------+ | 0 | No relay is present. | | 1 | A<table align="left"> <name>Initial Contents of the "Relay Type Field" Registry</name> <thead> <tr> <th align="left">Value</th> <th align="left">Description</th> </tr> </thead> <tbody> <tr> <td align="left">0</td> <td align="left">No relay is present</td> </tr> <tr> <td align="left">1</td> <td align="left">A 4-byte IPv4 address ispresent | | 2 | Apresent</td> </tr> <tr> <td align="left">2</td> <td align="left">A 16-byte IPv6 address ispresent | | 3 | Apresent</td> </tr> <tr> <td align="left">3</td> <td align="left">A wire-encoded domain name ispresent | | 4-255 | Unassigned | +-------+---------------------------------------+ ]]></artwork></figure>present</td> </tr> <tr> <td align="left">4-255</td> <td align="left">Unassigned</td> </tr> </tbody> </table> <t>Values 0, 1, 2, and 3 are further explained in Sections <xreftarget="rtype"/>target="rtype" format="counter"/> and <xreftarget="rdformat"/>.target="rdformat" format="counter"/>. Relay type numbers 4 through 255 can be assigned with a policy of Specification Required (as described in <xreftarget="RFC8126"/>).</t>target="RFC8126" format="default"/>).</t> </section> <section anchor="security-considerations"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <section anchor="use-of-amt"title="Usenumbered="true" toc="default"> <name>Use ofAMT">AMT</name> <t>This document defines a mechanism that enables a more widespread and automated use of AMT, even without access to a multicast backbone. Operators of networks and applications that include a DRIAD-capable AMT gateway are advised to carefully consider the security considerations inSection 6 of<xreftarget="RFC7450"/>.</t>target="RFC7450" sectionFormat="of" section="6"/>.</t> <t>AMT gateway operators also are encouraged to take appropriate steps to ensure the integrity of the data received via AMT, forexampleexample, by the opportunistic use ofIPSecIPsec <xreftarget="RFC4301"/>target="RFC4301" format="default"/> to secure traffic received from AMTrelays,relays when IPSECKEY records <xreftarget="RFC4025"/>target="RFC4025" format="default"/> are available or when a trust relationship with the AMT relays can be otherwise established and secured.</t> <t>Note that AMT does not itself provide any integrity protectiononfor Multicast Data packets(Section 5.1.6 of <xref target="RFC7450"/>),(<xref target="RFC7450" sectionFormat="of" section="5.1.6"/>), so absent protections like those mentioned above, even an off-path attacker who discovers the gateway IP, the relay IP, and the relay source port for 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 to the gateway IP that spoof the relay as the source.</t> </section> <section anchor="record-spoofing"title="Record-spoofing">numbered="true" toc="default"> <name>Record-Spoofing</name> <t>The AMTRELAY resource record contains information thatSHOULD<bcp14>SHOULD</bcp14> be communicated to the DNS client without being modified. The method used to ensure the result was unmodified is up to the client.</t> <t>There must be a trust relationship between the end consumer of this resource record and the DNS server. This relationship may be end-to-end DNSSECvalidation,validation or a secure connection to a trusted DNS server that provides end-to-endsafety,safety to prevent record-spoofing of the response from the trusted server. The connection to the trusted server can use any secure channel, such as with a TSIG <xreftarget="RFC2845"/>target="RFC2845" format="default"/> or SIG(0) <xreftarget="RFC2931"/>target="RFC2931" format="default"/> channel, a secure local channel on the host, DNS over TLS <xreftarget="RFC7858"/>,target="RFC7858" format="default"/>, DNS over HTTPS <xreftarget="RFC8484"/>,target="RFC8484" format="default"/>, or some other mechanism that provides authentication of the RR.</t> <t>If an AMT gateway accepts a maliciously crafted AMTRELAY record, the result could be a Denial ofService,Service or receivers processing multicast traffic from a source under theattacker’sattacker's control.</t> </section> <section anchor="congestion"title="Congestion">numbered="true" toc="default"> <name>Congestion</name> <t>Multicast traffic, particularly interdomain multicast traffic, carries some congestion risks, as described inSection 4 of<xreftarget="RFC8085"/>.</t>target="RFC8085" sectionFormat="of" section="4"/>.</t> <t>Application implementors and network operators that use AMT gateways are advised to takeprecautionsprecautions, including monitoring of application traffic behavior, traffic authentication at ingest, rate-limiting of multicast traffic, and the use of circuit-breaker techniques such as those described inSection 3.1.10 of<xreftarget="RFC8085"/>target="RFC8085" sectionFormat="of" section="3.1.10"/> and similar protections at the networklevel,level in order to ensure network health in the event of misconfiguration, poorly written applications thatdon’tdon't follow UDP congestion control principles, or a deliberate attack.</t><t>Section 4.1.4.2 of <xref target="RFC7450"/><t><xref target="RFC7450" sectionFormat="of" section="4.1.4.2"/> andSection 6.1 of<xreftarget="RFC7450"/>target="RFC7450" sectionFormat="of" section="6.1"/> provide some further considerations and advice about mitigating congestion risk.</t> </section> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3376.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3596.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3597.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4604.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4607.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6724.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7450.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8305.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2317.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2845.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2931.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4025.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4787.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5110.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6726.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7359.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8313.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/> </references> </references> <sectionanchor="acknowledgements" title="Acknowledgements"> <t>This specification was inspired byanchor="extranslate" numbered="true" toc="default"> <name>Unknown RRType Construction</name> <t>In a DNS resolver that understands theprevious 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> <back> <references title='Normative References'> <reference anchor="RFC1034" target='https://www.rfc-editor.org/info/rfc1034'> <front> <title>Domain names - concepts and facilities</title> <author initials='P.V.' surname='Mockapetris' fullname='P.V. Mockapetris'><organization /></author> <date year='1987' month='November' /> <abstract><t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t></abstract> </front> <seriesInfo name='STD' value='13'/> <seriesInfo name='RFC' value='1034'/> <seriesInfo name='DOI' value='10.17487/RFC1034'/> </reference> <reference anchor="RFC1035" target='https://www.rfc-editor.org/info/rfc1035'> <front> <title>Domain names - implementation and specification</title> <author initials='P.V.' surname='Mockapetris' fullname='P.V. Mockapetris'><organization /></author> <date year='1987' month='November' /> <abstract><t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t></abstract> </front> <seriesInfo name='STD' value='13'/> <seriesInfo name='RFC' value='1035'/> <seriesInfo name='DOI' value='10.17487/RFC1035'/> </reference> <reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author> <date year='1997' month='March' /> <abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract> </front> <seriesInfo name='BCP' value='14'/> <seriesInfo name='RFC' value='2119'/> <seriesInfo name='DOI' value='10.17487/RFC2119'/> </reference> <reference anchor="RFC2181" target='https://www.rfc-editor.org/info/rfc2181'> <front> <title>Clarifications to the DNS Specification</title> <author initials='R.' surname='Elz' fullname='R. Elz'><organization /></author> <author initials='R.' surname='Bush' fullname='R. Bush'><organization /></author> <date year='1997' month='July' /> <abstract><t>This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='2181'/> <seriesInfo name='DOI' value='10.17487/RFC2181'/> </reference> <reference anchor="RFC2782" target='https://www.rfc-editor.org/info/rfc2782'> <front> <title>A DNS RR for specifying the location of services (DNS SRV)</title> <author initials='A.' surname='Gulbrandsen' fullname='A. Gulbrandsen'><organization /></author> <author initials='P.' surname='Vixie' fullname='P. Vixie'><organization /></author> <author initials='L.' surname='Esibov' fullname='L. Esibov'><organization /></author> <date year='2000' month='February' /> <abstract><t>This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='2782'/> <seriesInfo name='DOI' value='10.17487/RFC2782'/> </reference> <reference anchor="RFC3376" target='https://www.rfc-editor.org/info/rfc3376'> <front> <title>Internet Group Management Protocol, Version 3</title> <author initials='B.' surname='Cain' fullname='B. Cain'><organization /></author> <author initials='S.' surname='Deering' fullname='S. Deering'><organization /></author> <author initials='I.' surname='Kouvelas' fullname='I. Kouvelas'><organization /></author> <author initials='B.' surname='Fenner' fullname='B. Fenner'><organization /></author> <author initials='A.' surname='Thyagarajan' fullname='A. Thyagarajan'><organization /></author> <date year='2002' month='October' /> </front> <seriesInfo name='RFC' value='3376'/> <seriesInfo name='DOI' value='10.17487/RFC3376'/> </reference> <reference anchor="RFC3596" target='https://www.rfc-editor.org/info/rfc3596'> <front> <title>DNS Extensions to Support IP Version 6</title> <author initials='S.' surname='Thomson' fullname='S. Thomson'><organization /></author> <author initials='C.' surname='Huitema' fullname='C. Huitema'><organization /></author> <author initials='V.' surname='Ksinant' fullname='V. Ksinant'><organization /></author> <author initials='M.' surname='Souissi' fullname='M. Souissi'><organization /></author> <date year='2003' month='October' /> <abstract><t>This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='STD' value='88'/> <seriesInfo name='RFC' value='3596'/> <seriesInfo name='DOI' value='10.17487/RFC3596'/> </reference> <reference anchor="RFC3597" target='https://www.rfc-editor.org/info/rfc3597'> <front> <title>Handling of Unknown DNS Resource Record (RR) Types</title> <author initials='A.' surname='Gustafsson' fullname='A. Gustafsson'><organization /></author> <date year='2003' month='September' /> <abstract><t>Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='3597'/> <seriesInfo name='DOI' value='10.17487/RFC3597'/> </reference> <reference anchor="RFC3810" target='https://www.rfc-editor.org/info/rfc3810'> <front> <title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</title> <author initials='R.' surname='Vida' fullname='R. Vida' role='editor'><organization /></author> <author initials='L.' surname='Costa' fullname='L. Costa' role='editor'><organization /></author> <date year='2004' month='June' /> <abstract><t>This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='3810'/> <seriesInfo name='DOI' value='10.17487/RFC3810'/> </reference> <reference anchor="RFC4604" target='https://www.rfc-editor.org/info/rfc4604'> <front> <title>Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast</title> <author initials='H.' surname='Holbrook' fullname='H. Holbrook'><organization /></author> <author initials='B.' surname='Cain' fullname='B. Cain'><organization /></author> <author initials='B.' surname='Haberman' fullname='B. Haberman'><organization /></author> <date year='2006' month='August' /> <abstract><t>The Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively. Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an "SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast. This document updates the IGMPv3 and MLDv2 specifications. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='4604'/> <seriesInfo name='DOI' value='10.17487/RFC4604'/> </reference> <reference anchor="RFC4607" target='https://www.rfc-editor.org/info/rfc4607'> <front> <title>Source-Specific Multicast for IP</title> <author initials='H.' surname='Holbrook' fullname='H. Holbrook'><organization /></author> <author initials='B.' surname='Cain' fullname='B. Cain'><organization /></author> <date year='2006' month='August' /> <abstract><t>IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='4607'/> <seriesInfo name='DOI' value='10.17487/RFC4607'/> </reference> <reference anchor="RFC6724" target='https://www.rfc-editor.org/info/rfc6724'> <front> <title>Default Address Selection for Internet Protocol Version 6 (IPv6)</title> <author initials='D.' surname='Thaler' fullname='D. Thaler' role='editor'><organization /></author> <author initials='R.' surname='Draves' fullname='R. Draves'><organization /></author> <author initials='A.' surname='Matsumoto' fullname='A. Matsumoto'><organization /></author> <author initials='T.' surname='Chown' fullname='T. Chown'><organization /></author> <date year='2012' month='September' /> <abstract><t>This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa.</t><t>Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='6724'/> <seriesInfo name='DOI' value='10.17487/RFC6724'/> </reference> <reference anchor="RFC6763" target='https://www.rfc-editor.org/info/rfc6763'> <front> <title>DNS-Based Service Discovery</title> <author initials='S.' surname='Cheshire' fullname='S. Cheshire'><organization /></author> <author initials='M.' surname='Krochmal' fullname='M. Krochmal'><organization /></author> <date year='2013' month='February' /> <abstract><t>This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.</t></abstract> </front> <seriesInfo name='RFC' value='6763'/> <seriesInfo name='DOI' value='10.17487/RFC6763'/> </reference> <reference anchor="RFC7450" target='https://www.rfc-editor.org/info/rfc7450'> <front> <title>Automatic Multicast Tunneling</title> <author initials='G.' surname='Bumgardner' fullname='G. Bumgardner'><organization /></author> <date year='2015' month='February' /> <abstract><t>This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality.</t><t>The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure.</t></abstract> </front> <seriesInfo name='RFC' value='7450'/> <seriesInfo name='DOI' value='10.17487/RFC7450'/> </reference> <reference anchor="RFC8085" target='https://www.rfc-editor.org/info/rfc8085'> <front> <title>UDP Usage Guidelines</title> <author initials='L.' surname='Eggert' fullname='L. Eggert'><organization /></author> <author initials='G.' surname='Fairhurst' fullname='G. Fairhurst'><organization /></author> <author initials='G.' surname='Shepherd' fullname='G. Shepherd'><organization /></author> <date year='2017' month='March' /> <abstract><t>The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.</t><t>Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP.</t><t>Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.</t><t>This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage.</t></abstract> </front> <seriesInfo name='BCP' value='145'/> <seriesInfo name='RFC' value='8085'/> <seriesInfo name='DOI' value='10.17487/RFC8085'/> </reference> <reference anchor="RFC8305" target='https://www.rfc-editor.org/info/rfc8305'> <front> <title>Happy Eyeballs Version 2: Better Connectivity Using Concurrency</title> <author initials='D.' surname='Schinazi' fullname='D. Schinazi'><organization /></author> <author initials='T.' surname='Pauly' fullname='T. Pauly'><organization /></author> <date year='2017' month='December' /> <abstract><t>Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555.</t></abstract> </front> <seriesInfo name='RFC' value='8305'/> <seriesInfo name='DOI' value='10.17487/RFC8305'/> </reference> <reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author> <date year='2017' month='May' /> <abstract><t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t></abstract> </front> <seriesInfo name='BCP' value='14'/> <seriesInfo name='RFC' value='8174'/> <seriesInfo name='DOI' value='10.17487/RFC8174'/> </reference> <reference anchor="RFC8499" target='https://www.rfc-editor.org/info/rfc8499'> <front> <title>DNS Terminology</title> <author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author> <author initials='A.' surname='Sullivan' fullname='A. Sullivan'><organization /></author> <author initials='K.' surname='Fujiwara' fullname='K. Fujiwara'><organization /></author> <date year='2019' month='January' /> <abstract><t>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</t><t>This document obsoletes RFC 7719 and updates RFC 2308.</t></abstract> </front> <seriesInfo name='BCP' value='219'/> <seriesInfo name='RFC' value='8499'/> <seriesInfo name='DOI' value='10.17487/RFC8499'/> </reference> </references> <references title='Informative References'> <reference anchor="RFC2317" target='https://www.rfc-editor.org/info/rfc2317'> <front> <title>Classless IN-ADDR.ARPA delegation</title> <author initials='H.' surname='Eidnes' fullname='H. Eidnes'><organization /></author> <author initials='G.' surname='de Groot' fullname='G. de Groot'><organization /></author> <author initials='P.' surname='Vixie' fullname='P. Vixie'><organization /></author> <date year='1998' month='March' /> <abstract><t>This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract> </front> <seriesInfo name='BCP' value='20'/> <seriesInfo name='RFC' value='2317'/> <seriesInfo name='DOI' value='10.17487/RFC2317'/> </reference> <reference anchor="RFC2845" target='https://www.rfc-editor.org/info/rfc2845'> <front> <title>Secret Key Transaction Authentication for DNS (TSIG)</title> <author initials='P.' surname='Vixie' fullname='P. Vixie'><organization /></author> <author initials='O.' surname='Gudmundsson' fullname='O. Gudmundsson'><organization /></author> <author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organization /></author> <author initials='B.' surname='Wellington' fullname='B. Wellington'><organization /></author> <date year='2000' month='May' /> <abstract><t>This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='2845'/> <seriesInfo name='DOI' value='10.17487/RFC2845'/> </reference> <reference anchor="RFC2931" target='https://www.rfc-editor.org/info/rfc2931'> <front> <title>DNS Request and Transaction Signatures ( SIG(0)s )</title> <author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organization /></author> <date year='2000' month='September' /> <abstract><t>This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='2931'/> <seriesInfo name='DOI' value='10.17487/RFC2931'/> </reference> <reference anchor="RFC3550" target='https://www.rfc-editor.org/info/rfc3550'> <front> <title>RTP: A Transport Protocol for Real-Time Applications</title> <author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'><organization /></author> <author initials='S.' surname='Casner' fullname='S. Casner'><organization /></author> <author initials='R.' surname='Frederick' fullname='R. Frederick'><organization /></author> <author initials='V.' surname='Jacobson' fullname='V. Jacobson'><organization /></author> <date year='2003' month='July' /> <abstract><t>This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='STD' value='64'/> <seriesInfo name='RFC' value='3550'/> <seriesInfo name='DOI' value='10.17487/RFC3550'/> </reference> <reference anchor="RFC4025" target='https://www.rfc-editor.org/info/rfc4025'> <front> <title>A Method for Storing IPsec Keying Material in DNS</title> <author initials='M.' surname='Richardson' fullname='M. Richardson'><organization /></author> <date year='2005' month='March' /> <abstract><t>This document describes a new resource record for the Domain Name System (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question. </t><t> This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='4025'/> <seriesInfo name='DOI' value='10.17487/RFC4025'/> </reference> <reference anchor="RFC4301" target='https://www.rfc-editor.org/info/rfc4301'> <front> <title>Security Architecture for the Internet Protocol</title> <author initials='S.' surname='Kent' fullname='S. Kent'><organization /></author> <author initials='K.' surname='Seo' fullname='K. Seo'><organization /></author> <date year='2005' month='December' /> <abstract><t>This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='4301'/> <seriesInfo name='DOI' value='10.17487/RFC4301'/> </reference> <reference anchor="RFC4787" target='https://www.rfc-editor.org/info/rfc4787'> <front> <title>Network Address Translation (NAT) Behavioral Requirements for Unicast UDP</title> <author initials='F.' surname='Audet' fullname='F. Audet' role='editor'><organization /></author> <author initials='C.' surname='Jennings' fullname='C. Jennings'><organization /></author> <date year='2007' month='January' /> <abstract><t>This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract> </front> <seriesInfo name='BCP' value='127'/> <seriesInfo name='RFC' value='4787'/> <seriesInfo name='DOI' value='10.17487/RFC4787'/> </reference> <reference anchor="RFC5110" target='https://www.rfc-editor.org/info/rfc5110'> <front> <title>Overview of the Internet Multicast Routing Architecture</title> <author initials='P.' surname='Savola' fullname='P. Savola'><organization /></author> <date year='2008' month='January' /> <abstract><t>This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications.</t><t>This memo also reclassifies several older RFCs to Historic. These RFCs describe multicast routing protocols that were never widely deployed or have fallen into disuse. This memo provides information for the Internet community.</t></abstract> </front> <seriesInfo name='RFC' value='5110'/> <seriesInfo name='DOI' value='10.17487/RFC5110'/> </reference> <reference anchor="RFC6726" target='https://www.rfc-editor.org/info/rfc6726'> <front> <title>FLUTE - File Delivery over Unidirectional Transport</title> <author initials='T.' surname='Paila' fullname='T. Paila'><organization /></author> <author initials='R.' surname='Walsh' fullname='R. Walsh'><organization /></author> <author initials='M.' surname='Luby' fullname='M. Luby'><organization /></author> <author initials='V.' surname='Roca' fullname='V. Roca'><organization /></author> <author initials='R.' surname='Lehtonen' fullname='R. Lehtonen'><organization /></author> <date year='2012' month='November' /> <abstract><t>This document defines File Delivery over Unidirectional Transport (FLUTE), a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This document obsoletes RFC 3926. [STANDARDS-TRACK]</t></abstract> </front> <seriesInfo name='RFC' value='6726'/> <seriesInfo name='DOI' value='10.17487/RFC6726'/> </reference> <reference anchor="RFC7359" target='https://www.rfc-editor.org/info/rfc7359'> <front> <title>Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks</title> <author initials='F.' surname='Gont' fullname='F. Gont'><organization /></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 Virtual Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel traffic leakages. That is, traffic meant to be transferred over an encrypted and 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 discusses some scenarios in which such VPN tunnel traffic leakages may occur as a result of employing IPv6-unaware VPN software. Additionally, this document offers 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/rfc7761'> <front> <title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)</title> <author initials='B.' surname='Fenner' fullname='B. Fenner'><organization /></author> <author initials='M.' surname='Handley' fullname='M. Handley'><organization /></author> <author initials='H.' surname='Holbrook' fullname='H. Holbrook'><organization /></author> <author initials='I.' surname='Kouvelas' fullname='I. Kouvelas'><organization /></author> <author initials='R.' surname='Parekh' fullname='R. Parekh'><organization /></author> <author initials='Z.' surname='Zhang' fullname='Z. Zhang'><organization /></author> <author initials='L.' surname='Zheng' fullname='L. Zheng'><organization /></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 underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (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 Router features and authentication using IPsec that lack sufficient deployment experience (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/rfc7858'> <front> <title>Specification for DNS over Transport Layer Security (TLS)</title> <author initials='Z.' surname='Hu' fullname='Z. Hu'><organization /></author> <author initials='L.' surname='Zhu' fullname='L. Zhu'><organization /></author> <author initials='J.' surname='Heidemann' fullname='J. Heidemann'><organization /></author> <author initials='A.' surname='Mankin' fullname='A. Mankin'><organization /></author> <author initials='D.' surname='Wessels' fullname='D. Wessels'><organization /></author> <author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author> <date year='2016' month='May' /> <abstract><t>This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize 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 applications 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/rfc8126'> <front> <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <author initials='M.' surname='Cotton' fullname='M. Cotton'><organization /></author> <author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author> <author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author> <date year='2017' month='June' /> <abstract><t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations 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 describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t><t>This is the third edition of this document; it obsoletes RFC 5226.</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/rfc8313'> <front> <title>Use of Multicast across Inter-domain Peering Points</title> <author initials='P.' surname='Tarapore' fullname='P. Tarapore' role='editor'><organization /></author> <author initials='R.' surname='Sayko' fullname='R. Sayko'><organization /></author> <author initials='G.' surname='Shepherd' fullname='G. Shepherd'><organization /></author> <author initials='T.' surname='Eckert' fullname='T. Eckert' role='editor'><organization /></author> <author initials='R.' surname='Krishnan' fullname='R. Krishnan'><organization /></author> <date year='2018' month='January' /> <abstract><t>This document examines the use of Source-Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios. The objectives are to (1) describe the setup process for multicast-based delivery across administrative domains for these scenarios and (2) document supporting 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/rfc8484'> <front> <title>DNS Queries over HTTPS (DoH)</title> <author initials='P.' surname='Hoffman' fullname='P. Hoffman'><organization /></author> <author initials='P.' surname='McManus' fullname='P. McManus'><organization /></author> <date year='2018' month='October' /> <abstract><t>This document defines a protocol for sending DNS queries and getting 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> <section anchor="extranslate" title="Unknown RRType construction"> <t>In a DNS resolver that understands the AMTRELAY type,AMTRELAY type, the zone file might contain this line:</t><figure><artwork><![CDATA[<sourcecode name="" type=""><![CDATA[ IN AMTRELAY 128 0 3 amtrelays.example.com.]]></artwork></figure>]]></sourcecode> <t>In order to translate this example to appear as an unknown RRType as defined in <xreftarget="RFC3597"/>,target="RFC3597" format="default"/>, one could run the following program:</t><figure><artwork><![CDATA[ <CODE BEGINS><sourcecode name="" type="python" markers="true"><![CDATA[ $ cat translate.py #!/usr/bin/env python3 import sys name=sys.argv[1] wire='' for dn in name.split('.'): if len(dn) > 0: wire += ('%02x' % len(dn)) wire += (''.join('%02x'%ord(x) for x in dn)) print(len(wire)//2) + 2 print(wire) $ ./translate.py amtrelays.example.com 24 09616d7472656c617973076578616d706c6503636f6d<CODE ENDS> ]]></artwork></figure>]]></sourcecode> <t>The length of the RData and the hex string for the domain name“amtrelays.example.com”"amtrelays.example.com" are the outputs of this program.</t><t>22 is the<t>The length of the wire-encoded domainname,name is 22, so 2 was added to 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 octets ahead of the domain name, we encode the precedence, D-bit, and relay type fields, as described in <xreftarget="rrdef"/>.</t>target="rrdef" format="default"/>.</t> <t>This results in a zone file entry like this:</t><figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ IN TYPE260 \# ( 24 ; length 80 ; precedence = 128 03 ; D-bit=0, relay type=3 (wire-encoded domain name) 09616d7472656c617973076578616d706c6503636f6d ) ; domain name]]></artwork></figure>]]></artwork> </section> <section anchor="acknowledgements" numbered="false" toc="default"> <name>Acknowledgements</name> <t>This specification was inspired by the previous 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>Thanks to <contact fullname="Jeff Goldsmith"/>, <contact fullname="Toerless Eckert"/>, <contact fullname="Mikael Abrahamsson"/>, <contact fullname="Lenny Giuliano"/>, <contact fullname="Mark Andrews"/>, <contact fullname="Sandy Zheng"/>, <contact fullname="Kyle Rose"/>, <contact fullname="Ben Kaduk"/>, <contact fullname="Bill Atwood"/>, <contact fullname="Tim Chown"/>, <contact fullname="Christian Worm Mortensen"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Dan Romanescu"/>, <contact fullname="Bernard Aboba"/>, <contact fullname="Carlos Pignataro"/>, <contact fullname="Niclas Comstedt"/>, <contact fullname="Mirja Kühlewind"/>, <contact fullname="Henning Rogge"/>, <contact fullname="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 comments.</t> </section> </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>