draft-ietf-dnssd-update-proxy.xml

<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.11 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>

<rfc ipr="trust200902" docName="draft-pusateri-dnssd-update-proxy-01" category="std">

  <front>
    <title>DNS Update Proxy for Service Discovery</title>

    <author initials="T." surname="Pusateri" fullname="Tom Pusateri">
      <organization>Unaffiliated</organization>
      <address>
        <postal>
          <street></street>
          <city>Raleigh</city>
          <code>NC 27608</code>
          <country>USA</country>
        </postal>
        <phone>+1 (919) 867-1330</phone>
        <email>pusateri@bangj.com</email>
      </address>
    </author>

    <date year="2019"/>

    <area>Internet</area>
    <workgroup>DNSSD Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document describes a method to dynamically map multicast DNS announcements into the unicast DNS namespace for use by service discovery clients. It does not define any new protocols but uses existing DNS protocols in new ways. This solves existing problems with service discovery across multiple IP subnets in a simple, yet efficient, manner.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>Multicast DNS is used today for link-local service discovery. While this has worked reasonably well on the local link, current deployment reveals two problems. First, mDNS wasn’t designed to traverse across multi-subnet campus networks. Second, IP multicast doesn’t work across all link types and can be problematic on 802.11 Wifi networks. Therefore, a solution is desired to contain legacy multicast DNS service discovery and transition to a unicast DNS service discovery model. By mapping the current mDNS discovered services into regular authoritative unicast DNS servers, clients from any IP subnet can make unicast queries through normal unicast DNS resolvers.</t>

<t>There are many ways to map services discovered using multicast DNS into the unicast namespace. This document describes a way to do the mapping using a proxy that sends DNS UPDATE messages <xref target="RFC2136"/> directly to an authoritative unicast DNS server. While it is possible for each host providing a service to send it’s own DNS UPDATE, key management has prevented widespread deployment of DNS UPDATEs across a domain. By having a limited number of proxies sitting on one or more IP subnets, it is possible to provide secure DNS updates at a manageable scale. Future work to automate secure DNS UPDATEs on a larger scale is needed.</t>

<t>This document will explain how services on each .local domain will be mapped into the unicast DNS namespace and how unicast clients will discover these services. It is important to note that no changes are required in either the clients, DNS authoritative servers, or DNS resolver infrastructure. In addition, while the Update proxy is a new logical concept, it requires no new protocols to be defined and can be built using existing DNS libraries.</t>

<t>An Update proxy is an ideal service to run on routers and/or switches to map local services into a larger network infrastructure.</t>

</section>
<section anchor="requirements-language" title="Requirements Language">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY”, and “OPTIONAL” in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.
These words may also appear in this document in
lower case as plain English words, absent their normative meanings.</t>

</section>
<section anchor="dns-subdomain-model" title="DNS Subdomain Model">

<t>Each .local domain which logically maps to an IP subnet is modeled as a separate subdomain in the unicast DNS hierarchy. Each of these subdomains must be browsable (respond to PTR queries for <spanx style="verb">b._dns-sd._udp.&lt;subdomain&gt;.</spanx>). See Section 11 of <xref target="RFC6763"/> for more details about browsing. In the context of the Update proxy, these subdomains are typically special use subdomains for mDNS mappings.</t>

<section anchor="subdomain" title="Subdomain Naming">

<t>The browseable subdomain label is prepended to the domain name and separated by a period. See <xref target="RFC7719"/> for more information on subdomains and labels. It is not important that the label be human readable or have organizational significance. End users will not be interacting with these labels. The main requirement is that they be unique within the domain for each IP subnet. Subdomain labels can be obtained by the proxy in several ways. The following methods should be attempted in order to assure consistency among redundant proxies:</t>

<t><list style="numbers">
  <t>address-derived domain enumeration through local resolver  <vspace blankLines='1'/>
The proxy issues a PTR query for the registration or browse domains based on the IP subnet. Separate queries are performed for IPv4 and IPv6 on the same link since they are different IP subnets. Since the Update proxy will be registering services with DNS UPDATE, it should begin querying for registration domains and fallback to browse domains if no registration domains are configured.  <vspace blankLines='1'/>
As an example, suppose a proxy was connected to IPv4 subnet <spanx style="verb">203.0.113.0/24</spanx>. In order to determine if there was a subdomain name for this subnet, the base domain name to query would be derived as <spanx style="verb">0.113.0.203.in-addr.arpa.</spanx> The proxy would issue a PTR query for the following names in order to find the subdomain for the IP subnet:  <vspace blankLines='1'/>
<spanx style="verb">dr._dns-sd._udp.0.113.0.203.in-addr.arpa.</spanx> <vspace />
 <spanx style="verb">r._dns-sd._udp.0.113.0.203.in-addr.arpa.</spanx> <vspace />
 <spanx style="verb">db._dns-sd._udp.0.113.0.203.in-addr.arpa.</spanx> <vspace />
 <spanx style="verb">b._dns-sd._udp.0.113.0.203.in-addr.arpa.</spanx> <vspace />
 <spanx style="verb">lb._dns-sd._udp.0.113.0.203.in-addr.arpa.</spanx>  <vspace blankLines='1'/>
The first response with an answer should be the subdomain name including the domain name for the IP subnet and further queries through this list are not needed. If multiple answers are returned in the same response, any one of the answers can be used but the proxy should only use a single subdomain name for the IP subnet.  <vspace blankLines='1'/>
The Update proxy should periodically rediscover the subdomain name at approximately 5 minute intervals for each IP subnet adding appropriate random jitter across IP subnets so as to prevent synchronization.</t>
  <t>proxy local configuration override  <vspace blankLines='1'/>
If no answer is returned, the proxy may have local configuration containing a subdomain name for the network. If so, this subdomain should be used.</t>
  <t>algorithmic subdomain label generation  <vspace blankLines='1'/>
If no local configuration is present for the IP subnet, the proxy may generate a unique label and use that for the subdomain by appending a common domain name. One such algorithm is to take the network form of an IPv4 subnet without a prefix length (host portion all zeros) and convert it to a hexadecimal string. This will give a 8 character unique string to use as a subdomain label. For the example above, this label would be <spanx style="verb">cb007100</spanx>.</t>
</list></t>

<t>In the cases where through either local configuration or algorithmic generation of subdomain names, a subdomain name is known by the proxy but cannot be address derived through a PTR query, the Update proxy SHOULD register the appropriate address-derived enumeration records through an UPDATE to the zone master. If the IP subnet is removed or becomes inactive on the Update proxy, the proxy MUST attempt to remove these records.</t>

</section>
<section anchor="domain-name-discovery" title="Domain Name Discovery">

<t>The base domain name to use for each subdomain also has to be discovered on a per IP subnet basis. In most cases, the domain name will be the same for all IP subnets because they are all contained in a single administrative domain. However, this is not required and a proxy administrator may need to span multiple administrative boundaries requiring different domain names on different IP subnets (and therefore, subdomains).</t>

<t>There is not a direct query to discover a separate domain name but the domain name is included with the subdomain in the response to the PTR query above in <xref target="subdomain"/>. If the PTR query returns an empty response, then the domain name can be obtained from local proxy configuration and if no domain name is specified there, the default domain for the host should be used.</t>

</section>
<section anchor="client-service-discovery" title="Client Service Discovery">

<t>Fortunately, clients performing service discovery require no changes in order to work with the Update proxy. Existing clients already support wide-area bonjour which specifies how to query search domains and subdomains for services. See section 11 of <xref target="RFC6763"/>.</t>

<t>However, in order for clients to discover the subdomain for each IP subnet, the subdomain MUST be browseable and a browse record for the domain must enumerate all of the subdomains. If the domain records do not exist, the Update proxy MUST create them in the domain and MUST ensure each subdomain is browseable.</t>

<t>In the future, authoritative unicast DNS servers may add support for DNS Push Notifications <xref target="I-D.ietf-dnssd-push"/> which would allow clients to maintain long lived subscriptions to services. Clients may also wish to add support for this feature to provide an efficient alternative to polling.</t>

</section>
</section>
<section anchor="update-proxy-behavior" title="Update Proxy Behavior">

<t>Since no new protocols are defined, this document mostly describes the expected behavior of the Update proxy and how it uses existing protocols to achieve multi IP subnet service discovery. The behavior is mostly intuitive but is described to ensure compatibility and completeness.</t>

<section anchor="mdns-service-announcements" title="mDNS Service Announcements">

<t>The Update proxy should listen to mDNS service announcements (responses) on all interfaces it is proxying for. Multiple Update proxies can be active on the same IP subnet at the same time. See <xref target="RFC6762"/> for more information on multicast DNS.</t>

</section>
<section anchor="service-caching-and-refresh" title="Service Caching and Refresh">

<t>As specified in Section 8.3 of <xref target="RFC6762"/>, service announcements are sent multiple times for redundancy. However, there is no need to send duplicate UPDATE messages to the authoritative unicast DNS server. Therefore, the Update proxy should cache service announcements and only send DNS UPDATE messages when needed.</t>

<t>As described in Section 8.4 of <xref target="RFC6762"/>, a host may send “goodbye” announcements by setting the TTL to 0. In this case, the record MUST be removed from the cache or otherwise marked as expired and a DNS UPDATE should be sent to the authoritative unicast DNS server removing the record.</t>

<t>The Update proxy MUST also remove/expire old cache entries and remove the records from the authoritative unicast DNS server when the cache-flush bit is set on new announcements as described in Section 10.2 of <xref target="RFC6762"/>.</t>

<t>A host providing a service may automatically refresh the TTL in the announcement from time to time keeping the service valid based on subsequent multicast queries it receives. However, if no mDNS clients are requesting the particular service for the length of the TTL value, the service announcement could timeout naturally. In order to keep accurate information regarding all of the services on the IP subnet, the Update proxy SHOULD send a unicast PTR query for the service name directly to the host announcing the service. This query should be sent at a random time between 5 and 10 seconds before the TTL value indicates the announcement will expire.</t>

<t>As described in Section 11 of <xref target="RFC6762"/>, the Update proxy should use an IP source address of the IP subnet of the interface it is transmitting over and that is on the same IP subnet as the service provider. It is also permissible to use a link-local IP address in the IPv6 case as long as the service itself is available on an IPv6 address that is reachable from outside the local link.</t>

<t>In order for the Update proxy to discover as many services available on each IP subnet as possible, it should periodically send a PTR multicast query for <spanx style="verb">_services._dns-sd._udp.local.</spanx> on each subnet. The unicast response bit SHOULD be set in the query in order to force unicast responses to the Update proxy. As PTR responses are received, The Update proxy can then send Service Instance Enumeration PTR queries (also with the unicast response bit set) for each service.</t>

<t>This was not the intended behavior of mDNS since local clients would just ask dynamically when they needed to know all of the providers of a service name but keeping this information up to date in the authoritative server provides benefits to remote clients such as faster response times and ability to use DNSSEC validation that were not previously possible with multicast DNS. These benefits are provided at the additional cost of a slight increase in network activity and processing time by the hosts announcing services. However, if the Update proxy uses unicast to query the service providers directly, other clients are not affected by these refresh queries and do not have to turn their radios on for queries/responses that they have no interest in.</t>

</section>
<section anchor="mdns-probing" title="mDNS Probing">

<t>While Section 8.2 of <xref target="RFC6762"/> recommends all potential answers be included in mDNS probe queries, because these records haven’t gone through conflict resolution, they should not be regarded as announcements of services. Therefore, an Update proxy MUST NOT rely on information in any section of DNS query messages.</t>

</section>
<section anchor="link-local-addressing" title="Link-local Addressing">

<t>In the IPv6 case, the source address of the announcements is a link-local IPv6 address that will probably be different than the IP subnet that the service is being provided on. However, it is certainly possible that link-local addressing is used with IPv4 as well. This is not as common but exists in a zero-conf environment where no IPv4 addresses are assigned via DHCP or statically and the hosts revert to link-local IPv4 addresses (<spanx style="verb">169.254/16</spanx>), see <xref target="RFC3927"/>.</t>

<t>If the service SRV target resolves to only a link-local address, then the service is not eligible to be advertised outside of the link and shouldn’t be sent to the authoritative unicast DNS server by the Update proxy.</t>

<t>In general, the Update proxy needs to ensure that the service is reachable outside of the link it is announced on before sending an UPDATE to the authoritative server for the subdomain.</t>

</section>
<section anchor="ipv6-and-ipv4-on-same-link" title="IPv6 and IPv4 on Same Link">

<t>Announced services may be available on IPv4, IPv6, or both on the same link. If both IPv4 A records <xref target="RFC1035"/> and IPv6 AAAA records <xref target="RFC3596"/> are published for an SRV target <xref target="RFC2782"/> name, the administrator should provide the service over both protocols.</t>

<t>In some cases, this won’t be possible. This will not incur any extra delays if clients attempt connections over both IPv4 and IPv6 protocols simultaneously but if one protocol is preferred over another, delays may occur.</t>

</section>
<section anchor="multiple-logical-ip-subnets" title="Multiple Logical IP Subnets">

<t>Multiple IP subnets on the same link is just a more general case of IPv4 and IPv6 on the same link. When multiple IP subnets exist for the same protocol on the same link, they appear as separate interfaces to the Update proxy and require a separate subdomain name just as IPv4 and IPv6 do.</t>

<t>This is required for a client on one logical IP subnet of an interface to communicate with a service provided by a host on a different IP subnet of the same link.</t>

<t>If a SRV target resolves to addresses on multiple logical IP subnets of the same interface, the service can be included in multiple subdomains on the appropriate server(s) for those subdomains.</t>

</section>
<section anchor="proxy-redundancy" title="Proxy Redundancy">

<t>Providing redundant Update proxies for the same IP subnet can be easily achieved by virtue of the DNS UPDATE protocol. None of the redundant proxies needs to be aware of any of the other redundant proxies on an IP subnet.</t>

<t>Alternatives for ways to format DNS UPDATE messages are defined below in <xref target="prereq"/> as to possible uses of the Prerequisite section for use with redundant Update proxies.</t>

<t>Alternatively, a proxy MAY choose to hibernate when it discovers another active Update proxy as described below in <xref target="unicast"/>.</t>

</section>
<section anchor="service-filtering-and-translation" title="Service Filtering and Translation">

<t>In the process of registering services with an authoritative unicast DNS server, the proxy can perform filtering and translation on the dynamically discovered services.</t>

<t>As an example, suppose legacy printers are discovered that do not support the current AirPrint feature set. The proxy can alter the TXT record associated with the printer to add the necessary keys as well as any additional service records to allow AirPrint clients to discover and use the legacy printer.</t>

<t>As another example, suppose there is a printer that is behind a locked door where students do not have access. In this case, the printer’s resource records MAY be filtered by the proxy so it does not show up during a browse operation on the subnet.</t>

<t>An Update proxy could have rulesets that define the translations it performs on the fly as is learns about matching services.</t>

</section>
</section>
<section anchor="dns-update" title="DNS UPDATE">

<t>While DNS UPDATE is well supported in authoritative DNS servers, it typically requires some form of authentication for the server to accept the update. The most common form is TSIG <xref target="RFC2845"/>,<xref target="RFC4635"/> which is based on a shared secret and a one way hash over the contents of the record.</t>

<t>The Update proxy doesn’t dictate a method of privacy or authentication for communication to an authoritative DNS UPDATE server. However, implementations SHOULD ensure some form of authentication exists and even refuse to operate in an environment without authentication.</t>

<section anchor="selection-of-authoritative-unicast-dns-server" title="Selection of Authoritative Unicast DNS Server">

<t>The Update proxy should attempt to locate the authoritative DNS UPDATE server for each subdomain in the following manner:</t>

<t><list style="numbers">
  <t>An Update proxy should first send an SRV query for <spanx style="verb">_dns-update-tls._tcp.&lt;subdomain&gt;.</spanx> If an answer is received, the target and port number will provide the parameters needed for where to send updates. The proxy can also try the TCP and UDP variants of this service name <spanx style="verb">_dns-update._tcp</spanx> and <spanx style="verb">_dns-update._udp</spanx> if the TLS variant does not exist. If no TLS variant is found, the proxy can still attempt a TLS connection on the SRV port of the TCP or UDP variant. The proxy can also attempt to connect to the target on the reserved port (853) for DNS over TLS as defined in Section 3.1 of <xref target="RFC7858"/>.</t>
  <t>The Update proxy can make a similar query for the same service in the domain if a subdomain specific answer isn’t returned: <spanx style="verb">_dns-update-tls._tcp.&lt;domain&gt;.</spanx> as well as the TCP and UDP variants.</t>
  <t>If no matching SRV records are returned, the Update proxy SHOULD consult local configuration policy to see if an DNS UPDATE server has been configured.</t>
  <t>If no local configuration exists for a DNS UPDATE server, the Update proxy can query the SOA records for the subdomain and try sending updates to the MNAME master server configured for the subdomain. Again, using TLS/TCP is encouraged if available.</t>
  <t>If DNS UPDATEs are not accepted by the server(s) represented by the SOA MNAME master server, then the Update proxy can assume that DNS UPDATEs are not available for the subdomain and listening to mDNS announcements on the IP subnet would be unproductive.</t>
</list></t>

</section>
<section anchor="dns-update-sections" title="DNS UPDATE Sections">

<t>A DNS UPDATE message contains four sections as specified in <xref target="RFC2136"/>.</t>

<section anchor="zone-section" title="Zone Section">

<t>When an Update proxy is adding or removing services to/from a subdomain, the zone section MUST contain a single zone (ZOCOUNT = 1) and the ZNAME MUST be the subdomain being updated. ZTYPE MUST be SOA and ZCLASS MUST be the same class as the records being added/removed.</t>

<t>DNS UPDATEs to multiple subdomains MUST be performed in separate DNS UPDATE messages with one subdomain per message.</t>

<t>If a new subdomain is being created for a domain by the Update proxy, the subdomain’s parent zone should be used for the ZNAME. ZTYPE MUST be SOA and ZCLASS MUST be the same class as the subdomain’s NS record CLASS that is going to be added. Similarly for removing a subdomain.</t>

</section>
<section anchor="prereq" title="Prerequisite Section">

<t>It is not necessary for the Update proxy to include any prerequisites when adding/removing records. However, if the Update proxy wants to have better error handling, it can add prerequisites to ensure the state of the authoritative server is consistent.</t>

<t>Given that multiple Update proxies may exist for the same IP subnet (and subdomain), it is possible that similar records may be added or deleted to/from the authoritative server before the Update proxy’s own messages are processed. This is not to be considered a fatal error and may happen during normal operation of redundant proxies. The use of prerequisite can be used to identify these cases if desired.</t>

</section>
<section anchor="update-section" title="Update Section">

<t>The Update section contains all of the records that the proxy wants to be added/removed in a single subdomain. If TIMEOUT resource records are being manually added to the authoritative server, they MUST be included as regular resource records in the Update section. See <xref target="lifetimes"/> below for more information.</t>

</section>
<section anchor="additional-data-section" title="Additional Data Section">

<t>The Update proxy may include additional data as needed. Instances where additional data might be included are:</t>

<t><list style="numbers">
  <t>When creating a subdomain by adding new NS records to a domain, A or AAAA glue records MAY be needed. Though, in most cases, the same authoritative server name / IP addresses should be used as in the parent domain.</t>
  <t>If including a lease lifetime as discussed below in <xref target="lifetimes"/>, the OPT recording containing the Update lease will be sent in the additional data section.</t>
  <t>The TSIG cryptographic signature of the DNS UPDATE message should be the last resource record in the additional data section.</t>
</list></t>

</section>
</section>
</section>
<section anchor="dns-authoritative-server-behavior" title="DNS Authoritative Server Behavior">

<t>The Update proxy will rely on the authoritative server to update the SERIAL number for the zone after each update is completed.</t>

<section anchor="dns-push-notifications" title="DNS Push Notifications">

<t>An authoritative unicast DNS server MAY support DNS Push notifications <xref target="I-D.ietf-dnssd-push"/> for client queries in order to provide more timely and more efficient responses. While this is outside of the scope of the Update proxy, it is mentioned here for completeness.</t>

</section>
<section anchor="dnssec-compatibility" title="DNSSEC Compatibility">

<t>With mDNS, the next domain name field in an NSEC record could not reference the next record in the zone because it was not possible to know all of the records in the zone a priori. By mapping all known records into a unicast subdomain, the NSEC next domain name field can contain the next known record as defined. As new services are discovered and UPDATEd in the authoritative unicast DNS server, the NSEC records can be kept up to date by the authoritative server.</t>

<t>The Update proxy will assume that DNS updates sent to zones with DNSSEC enabled will be updated as needed as specified in <xref target="RFC3007"/>.</t>

</section>
<section anchor="lifetimes" title="DNS Update Record Lifetimes">

<t>When the Update proxy sends an DNS UPDATE message to an authoritative unicast DNS server, it MAY include a lease lifetime to indicate how long the UPDATE server should keep the resource records active in the zone. This is different from the TTL which tells resolvers how long to keep the records in their cache. Lease lifetimes may be based on different origin data. For example, when an IP address is assigned to a host via DHCP, the DHCP server will provide a time period for which the address is assigned to the host.</t>

<t>There are several possibilities for how a DNS UPDATE server may limit the lifetime of records added via an update message.</t>

<t><list style="numbers">
  <t>The DNS update server MAY be configured to automatically delete the records after a certain fixed time period (such as 24 hours). This is a failsafe mechanism in case the origin of the record data goes offline and does not ever try to remove the records.</t>
  <t>A lease lifetime can be communicated via an OPT record as defined in Dynamic DNS Update Leases <xref target="I-D.sekar-dns-ul"/>. This provides a timeout period for all of the records added in the update message and is controlled by the sender of the update. This is a work in progress and does not yet have widespread adoption among authoritative unicast DNS server software.</t>
  <t>Individual DNS TIMEOUT resource records <xref target="I-D.pusateri-dnsop-update-timeout"/> can be added to the update message to indicate the timeout value for one or any number of the resource records contained in the update message. This is the most flexible but also does not have any adoption among authoritative unicast DNS server software. One advantage of the TIMEOUT resource records is that they are stored in the authoritative server like any other record and synchronized to secondary servers as well. Therefore, if the primary server were to restart or experience an extended failure, the lease lifetime would not be lost.</t>
</list></t>

<t>Note that it is possible to use both the Dynamic DNS Update leases to communicate the lease lifetime and for the authoritative unicast DNS server to create TIMEOUT resource records on demand to achieve the same result if the Update proxy does not include TIMEOUT resource records natively.</t>

</section>
</section>
<section anchor="unicast" title="Transitioning to Unicast">

<t>The design of the Update proxy is intended to work within the existing mDNS model and allow it to scale to multiple subnets using existing unicast DNS infrastructure. It is careful not to increase the amount of multicast traffic used for service discovery but it is also capable of providing a transition path to actually reduce multicast usage incrementally. Hosts have generally not been able to directly register their own services through DNS UPDATE because of the security scaling problem of shared passwords needed by TSIG.</t>

<t>By creating trusted infrastructure in the form of an Update proxy, services can now be registered through the Update proxy directly via unicast. This alleviates the need to advertise over mDNS at all.</t>

<t>Therefore, if we allow service providers to discover the Update proxy using either unicast or multicast queries, we can then perform all subsequent communication over unicast. This greatly reduces the multicast usage and the need for every host on the network to wake up and listen to multicast responses and periodic announcements.</t>

<t>In order to accomodate this transition, the Update proxy MAY announce and respond to PTR queries for the update proxy service using service name <spanx style="verb">_dns-updateproxy-tls._tcp.local.</spanx> pointing to a local instance name. As host implementations are updated to locate an Update proxy, they can switch entirely to unicast for all of the services they provide. The SRV record for the instance name can provide a target name and port for which the service provider can connect directly using TLS and send unicast registrations for all of its services. The TXT record for the instance name can contain vendor specific information associated with the Update proxy if desired. There are no required keys in the TXT record and while the record MUST exist (see Section 6 of <xref target="RFC6763"/>), it can consist of a single zero length byte. Multiple announcements can be sent across a single TLS connection. There are no responses expected from the Update proxy after sending the announcements. However, Update proxies MUST only announce this service if they intend to provide a unicast interface for service providers on the local subnet.</t>

<t>Discovery of the Update proxy can also be entirely using unicast for service providers that prefer or are not multicast capable. The service provider would use address-derived domain enumeration as described in <xref target="subdomain"/> to determine the subdomain name of the local link and then perform a normal unicast PTR query through the local resolver for <spanx style="verb">_dns-updateproxy-tls._tcp.&lt;subdomain&gt;.</spanx> to find the Update proxy instance. In the case of redundant proxies, multiple PTR records with different instance names may exist. The SRV records priority and weight fields can be used to determine the preferred Update proxy.</t>

<t>Once these services are initially registered with the Update proxy, the proxy may occasionally sent unicast queries to confirm these services are still active. A 60 second interval with appropriate jitter is recommended for confirmation. If, in the meantime, the service is discontinued, the service provider SHOULD reconnect to the Update proxy and send “goodbye” announcements with TTL 0 as normally would be done with mDNS to expire the services as described in Section 8.4 of <xref target="RFC6762"/>. The Update proxy will not send any response to these “goodbye” announcements, therefore, the connection MUST be closed gracefully to ensure proper delivery.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>When a secure DNS UPDATE is sent to an authoritative server, it should not be construed that this information is any more reliable than the original mDNS announcement was for which it was based. Care should always be taken when receiving mDNS announcements to ensure they are source IP address is one that belongs to an IP subnet on the received interface of the Update proxy. In addition, the TTL of the received link local announcement MUST be 1 to ensure it was not forwarded from a remote network.</t>

<t>Each Update proxy requires configuration of a shared secret for creation of the TSIG signature resource record contained as the last record in the UPDATE message.</t>

<t><vspace blankLines='999' /></t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2136" target='https://www.rfc-editor.org/info/rfc2136'>
<front>
<title>Dynamic Updates in the Domain Name System (DNS UPDATE)</title>
<author initials='P.' surname='Vixie' fullname='P. Vixie' role='editor'><organization /></author>
<author initials='S.' surname='Thomson' fullname='S. Thomson'><organization /></author>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter'><organization /></author>
<author initials='J.' surname='Bound' fullname='J. Bound'><organization /></author>
<date year='1997' month='April' />
<abstract><t>Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone.  Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2136'/>
<seriesInfo name='DOI' value='10.17487/RFC2136'/>
</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="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="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="RFC6762" target='https://www.rfc-editor.org/info/rfc6762'>
<front>
<title>Multicast DNS</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>As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important.  In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.</t><t>Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server.  In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.</t><t>The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.</t></abstract>
</front>
<seriesInfo name='RFC' value='6762'/>
<seriesInfo name='DOI' value='10.17487/RFC6762'/>
</reference>



<reference  anchor="RFC3927" target='https://www.rfc-editor.org/info/rfc3927'>
<front>
<title>Dynamic Configuration of IPv4 Link-Local Addresses</title>
<author initials='S.' surname='Cheshire' fullname='S. Cheshire'><organization /></author>
<author initials='B.' surname='Aboba' fullname='B. Aboba'><organization /></author>
<author initials='E.' surname='Guttman' fullname='E. Guttman'><organization /></author>
<date year='2005' month='May' />
<abstract><t>To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server.  Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available.  This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.</t><t>IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks).  This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3927'/>
<seriesInfo name='DOI' value='10.17487/RFC3927'/>
</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="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="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="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="RFC4635" target='https://www.rfc-editor.org/info/rfc4635'>
<front>
<title>HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers</title>
<author initials='D.' surname='Eastlake 3rd' fullname='D. Eastlake 3rd'><organization /></author>
<date year='2006' month='August' />
<abstract><t>Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code. Currently, identifiers have been specified only for HMAC MD5 (Hashed Message Authentication Code, Message Digest 5) and GSS (Generic Security Service) TSIG algorithms.  This document standardizes identifiers and implementation requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4635'/>
<seriesInfo name='DOI' value='10.17487/RFC4635'/>
</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="RFC3007" target='https://www.rfc-editor.org/info/rfc3007'>
<front>
<title>Secure Domain Name System (DNS) Dynamic Update</title>
<author initials='B.' surname='Wellington' fullname='B. Wellington'><organization /></author>
<date year='2000' month='November' />
<abstract><t>This document proposes a method for performing secure Domain Name System (DNS) dynamic updates.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3007'/>
<seriesInfo name='DOI' value='10.17487/RFC3007'/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor="RFC7719" target='https://www.rfc-editor.org/info/rfc7719'>
<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='2015' month='December' />
<abstract><t>The 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></abstract>
</front>
<seriesInfo name='RFC' value='7719'/>
<seriesInfo name='DOI' value='10.17487/RFC7719'/>
</reference>



<reference anchor="I-D.ietf-dnssd-push">
<front>
<title>DNS Push Notifications</title>

<author initials='T' surname='Pusateri' fullname='Tom Pusateri'>
    <organization />
</author>

<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
    <organization />
</author>

<date month='November' day='4' year='2018' />

<abstract><t>The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static.  When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high.  But there exists no mechanism for a client to be asynchronously notified when these changes occur.  This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-dnssd-push-16' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-dnssd-push-16.txt' />
</reference>



<reference anchor="I-D.sekar-dns-ul">
<front>
<title>Dynamic DNS Update Leases</title>

<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
    <organization />
</author>

<author initials='T' surname='Lemon' fullname='Ted Lemon'>
    <organization />
</author>

<date month='August' day='2' year='2018' />

<abstract><t>This document proposes a method of extending Dynamic DNS Update to contain an update lease lifetime, allowing a server to garbage collect stale resource records.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-sekar-dns-ul-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-sekar-dns-ul-02.txt' />
</reference>



<reference anchor="I-D.pusateri-dnsop-update-timeout">
<front>
<title>DNS TIMEOUT Resource Record</title>

<author initials='T' surname='Pusateri' fullname='Tom Pusateri'>
    <organization />
</author>

<author initials='T' surname='Wattenberg' fullname='Tim Wattenberg'>
    <organization />
</author>

<date month='March' day='4' year='2019' />

<abstract><t>This specification defines a new DNS TIMEOUT resource record (RR) that associates a lifetime with one or more zone resource records with the same owner name, type, and class.  It is intended to be used to transfer resource record lifetime state between a zone's primary and secondary servers and to store lifetime state during server software restarts.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-pusateri-dnsop-update-timeout-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-pusateri-dnsop-update-timeout-02.txt' />
</reference>



<reference anchor="I-D.ietf-dnssd-hybrid">
<front>
<title>Discovery Proxy for Multicast DNS-Based Service Discovery</title>

<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
    <organization />
</author>

<date month='March' day='21' year='2018' />

<abstract><t>This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-dnssd-hybrid-08' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-dnssd-hybrid-08.txt' />
</reference>



<reference anchor="I-D.ietf-dnssd-mdns-relay">
<front>
<title>Multicast DNS Discovery Relay</title>

<author initials='T' surname='Lemon' fullname='Ted Lemon'>
    <organization />
</author>

<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
    <organization />
</author>

<date month='July' day='2' year='2018' />

<abstract><t>This document complements the specification of the Discovery Proxy for Multicast DNS-Based Service Discovery.  It describes a lightweight relay mechanism, a Discovery Relay, which, when present on a link, allows remote clients, not attached to that link, to perform mDNS discovery operations on that link.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-dnssd-mdns-relay-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-dnssd-mdns-relay-01.txt' />
</reference>




    </references>


<section anchor="comparison-to-discovery-proxy" title="Comparison to Discovery Proxy">

<t>The Update Proxy defined in this document is an alternative to the Discovery Proxy <xref target="I-D.ietf-dnssd-hybrid"/> and the Discovery Relay <xref target="I-D.ietf-dnssd-mdns-relay"/>. This solution makes different trade-offs than the ones made by the Discovery Proxy which offer some advantages at a cost of increased state.</t>

<t>The main difference is that the Discovery Proxy builds the list of matching services on demand by querying over mDNS and collecting the announcements in response to client queries. Whereas the Update proxy tries to build a complete list of services by listening for all announcements, discovering and refreshing them, and then inserting them into subdomains using DNS UPDATE.</t>

<t>The main advantages of the Update proxy include limiting further propagation of IP multicast across the campus, providing a pathway to eliminate multicast entirely, faster response time to client queries, and the ability to provide DNSSEC signed security responses for client queries.</t>

<t>While the Discovery Proxy increases multicast queries and responses based on received unicast queries <spanx style="verb">O(n^2)</spanx>, the Update proxy can reduce or eliminate mDNS traffic on the local links <spanx style="verb">O(1)</spanx>.</t>

<t>Another key difference is that the Update proxy never becomes an authoritative unicast DNS server for the attached subdomain. It simply updates the existing authoritative server for the domain. Therefore, the administrator is free to use existing authoritative DNS server infrastructure.</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIADAjhFwAA6Vd63LbSHb+z6dA7B9rVyhaku+u3LSyZ0dVviiWnM1ObWXU
BJokxiDARQOSua55lzxLnizn2hcAtGeSVGXHkojG6dPn8p1b8+joaNaVXWVf
Za/fX2WfdoXpbHbZNl/22appsyvb3pa5zV6XLm9ubbufFU1emy18vmjNqjva
9Q6eaMujonauOOppgaMdLnB0fDLDn15lp8cnL2flrn2VdW3vutPj45fHpzPT
WvMqu6jh8dp2s7s10XD1Ovtz034u63X2p7bpd7PPd+FDR6/xpbPcdK8y1xUz
15m6+NlUTW1pbTub5U0Bz77K+m519GK2K1/Nsuwo65qc/uv229auHP+7aTv6
YWb6btO09En4/ywra/cqu15kl7I5+iXv+rrZpr9uWnjZp9qsVmVVwq8L+q2D
lS0Qee8e/ZiX3f5V9tFUtlxv+DdNAau9P89Onz87fiG/6uuuhc99ujqjX+w2
tK9/PMkevDx5+TB78ez50cnjx8f0R7s1ZfUqU/7/29LU618WebOdzY6OjjKz
BBJM3s1m15vSZXBq/dbWXVZYl7fl0rrMZFsL2y6AN1mxh92VuamqfbY1u2zb
Vx386DqSClPXQFpucQEHzIEHuo3N+jp8BJnjdgYkBaWmdzZb7jMnwlOo8GR5
VeIai+wCKGmAiLpBklZlbeEt+6y2dxnIDpxWU7ls2Xe4lMvsl9J1KBH4qvD3
sqYH7sweVqRtuqa6jT8Pn11Wduuyu7LbTNBj8rZxjre7q2x2cZm5fgmCRoub
zJVb+PU829sus3DCOZI/BxbVtW0XzOltWRQVCN59lNK2Kfq8K5t6NnuX8BCI
g60gswvDqlWV9eejqgGmjwlbZH/elEBPh5vaGKAfVAKeBo1xTW2WcEx3tqqy
pqaT4FVwwXmW923LB72rmj2deWtvrQF+dXeN58gi+6FsHe4Fqbszrv4DCUe5
rolK0CYDlMBBxjw6Yu5kudmC4AH3OyQMFruyeVMXc2RgkB08YVwWP6PLgIgR
oVm336EQ1gUsVmdLq5QZeBj39eL4dHFykv25XJXRe643FlS2aeFMDJ52j7xG
5iLpLVMOlHQGjq+ya5PvB7I8IQNAAmy2diWtBQuYRLTHT2xBd6tF9kfSlR3K
GR6CMp4Yqh8GiuR5UZzWrvvKtBmbnLKD7d7a0fuA8XNVlmzVgs1B7fDSSSzb
ms/hwb/1YAPgHd0GbOZ6A3rVbkEk4nVbS9rRugXaBCAtAwOMorwnDcKNo+p7
cqMt9A43mTJyZAa8CRBdnDQ58CayN/yoso/XNxm5DfiL6YCMunDsky5fn12/
AWPlnFnDIl+//sPHH85PTx4/+/VXILK1eVfRosCT73FV9arsUGZ2IJAlyByp
ozX5Jts08HGg4rYsmCI9fFgeKYIH/+Cy5q6OKJtnny1KQg3U0X5RX3eoc+C0
CrA8sH/40RSxSjaraAXnlQMYA2a9JtnamFumoSq3Ja5U99ulbfFR5BOeNogs
mTkQW/AU4IpANNvYis2HO+0a2Z6F/YDEWiKDvTa8v0OvQDsx+GkHZgWO84e+
w0+SGiOf+w6o7JIVdCMNWk2Q7zUQSk/j22trC1sshq7orgRbYL/sKlTWTXMX
RA9WoeNYsGFjpvDnlyw1wI7v+CFUa1xU/6raRKuobOPzzvoXk18CEsHqAzYw
QCO8AlyUZZmswbZswM0ip2Dfrf1bTzYHaLPgX3g5fdGcXWcikF614aRilYQV
Vi0Q2YLvAI4CGcDGoiCDNM/uxBVYhWesJiXKC/q/qlmj60a7l9tdR2cutKGD
HThV2BHwkH1uEdvfZV9Wnahi4nCrctkatC5wgmf1mAiwv4WNvBhauR4lMgNb
BNiErPwj2LIDL5xvrDc1ifMT++ilR2z+kDXoZz/y5hiOvIUD6UFgyaiRKsJj
YDruvft0dX1vzv/N3n+gf3988++fLj6+eY3/vvrx7O1b/4+ZfOLqxw+f3r4O
/wpPnn949+7N+9f8MPw2S341u/fu7C/wF2TovQ+X1xcf3p+9vYei0SVCj4LD
R1AipgXDgKpt3EytJInTH88v/+e/T554W3fyEmwd//Di5PkT+OFuY2t+W1Mj
GqAfQUb2M9QO0xJ+AUnPzQ6krwKZA6vkNmi60PYvkFvOCq+2YJXhM8B9/2xK
dVnPquYOTgVUyeJKrLRv6nVVug2vMkfMiR8GKsqWPRBJ/daaGmQJxQcODyXq
ql+KTr9DVzqbvZnQ9k0JvxPZZljqxMoHPwg0kjMmFpK53pmWTJN/Q1mPjMSm
tCDQ+QZgFr0YLKrYAX0K4Q58GLWibe4cGcMHoE67piaIcXn90btcdB43y8XP
EAAduWLxc1/sFv/kV/qXxc1DhEcWIRIBDAA18EI+zGfPnz2Gw1yp5S4sIBdQ
UrMEzeF3A+fIHpBpAWRjv3RCcKKJ8/EWSNT2O+Gf29m8REiQfohejUwRX4yn
dP9+dELvITAAQ/D1vn/oV1Y1ok78hP90ZZa2Io/T2h04TMGS8HH5ABpoEls9
qgIjBXD9wMymYE59/fqvwJvnz0nqPW/AELBIkbdLNgrL0Yu9AcewIjLiaLwJ
JxN1cKqbHrwcoumC6IdXgLfF/65BVP9O70DLBGAY4CfYRwQ1b2oEQmjOyIXg
K1SLIc5CHlGQwceg5FwTyilrNcisTc6TtMc1QDZBmOhxkVZhlsclXuIX0cnw
O9R8N0sEvcxOXELsMzAKkEgLu9EwCeFOBdpMkI4iQDIMfVXgMqbr7HbXsRkC
tUanBkrnHHp6kD8HjsHWAKvNtoEFwP31dYFMFkzyajY7WaDzAm1xR/A4WIBC
92MBwgAtjLMFqbLSqyecUWx7HeiHFxNwVI3j2Ak3CEi6xBiXBaIVecxUKJYG
wy0JkGL+qYlQ/UU1AelD4YIHcPWLy9snJFTwj2e6hEPBpcgFVDK3fHj4bFGu
VpaQf8Bd8Br9UOovFcMw8UAA8NA7QJKfGFiCI/cnswb+EQPwEaQy2X+sCivQ
96XJCasNmFKuEBBMP8nnuyrXcNII1vAgzsi92y+Gw2DX7wBJWo/UIWzEZ2qw
bKzoxDmxzTenx48XxxDDwf8+On1yQ1bMSxRYOttuMe4vyZghvmQT7uWbTAWf
Nob2tCqZOTrbxKDAgiwcdyrHKnmw5o0QsUCCyvoIhXNh2p1Z3ESSxk+SvE2K
W1AawpiJegCWKlhIPPH6mJeJV8RQ+p8beH/iLr5B4F//yo/8/ieK5e9+5Pc/
Uf3mR4JmrzDxkLE3dWz2KHarHSKMYIpShtI5g1JVfaER91hOIn6zKvQt4fJh
eEwSBdCF8RiacolRsotVyAYxRQr2AX7WbBa9OdA9zCk8pxCMPbM+KbaZMj+Y
zQqGWbZJ4K0nlUJPX412PNrXIjAysSyyIPtR8fmgyFGgM1wao70dmW2M5uDj
TzNQSEDs7NRuMWU09kAUmGBcio/uWkx5Zi3wutlmv0A4Cq+SYDbKpSGydBx7
UlicuX2dw1Gor4U9nS5kH+wP1BKJdYcdtBBk8NYvyIiJuMA56tHMI/YioiWX
PrWcJIgkwp/mt4QfJBCumXsbJJ8NUopnC/Q/BqdXrTHU22zLfISI1rYWxxfv
YYo4xk4EpEdnP9yhrGo5Y4UYgt9mGKowytBVAkkIuHaIzpgDebPdekdAXFhk
H2p8AM7db4pQC0A5zDpFDMLltyj2hMuD9UetRgyLrgJizS9ZZes1KPoDTrEA
MsPNYoTydwvi8pAj0aaGk+7Q71EouAHPUwBsxVQWOCyCwpRDIDe6xuDCZC8w
KEcIBtIgXODP4ho9hytmeCCL7Adhizg3hNy3Vs6Zueh9yU2+PD5+fnJ8fAMH
rVDcYGL6jhyXWhVJAkxKcJuIRxAHZF0qgm4+lkqg6XONsVsC7tCi5JicJyQq
mMt7PqUqcmbzMSCRKFfxCFuvSLWHSC6GcK3NKXz0b6o1WSeY/+9oErcGFyZF
Sg00qe62wVURvsFi7FcRTSMYr6eDHCGcwnpBq5RyoKUEfgtlHMu89oFMXMfi
GGYCSKDIeLMXzoHi443xCZSQHaWcF9jdaGuwbukI8GxR3ElY5iOfpWDQ+5MV
iUkVm05gi2FVFrhJQT0bMPZG3nOYAsy3ALtb61OJP0LgDoSKaEtw5HNXqHYK
56IFMOgye/KKlPvcYcLZ+8X0RRCrQghA/pWXRd0LqDgWbeTVFF7OHhhGUJrc
D9HdQ5+uFtKNJH0FnyGWVCcXJQBiPqvnHWgUgwlK0XLcNs4aeJAiAh1gIZkL
/NjXryEw/tVLefggeyfG0SCq+wg0wAfrEWHDcI6y/2xS+JRSw4J8Y1Q/2B3F
+6vSCltF+uzKwClmA5BKNnnk0kB1zimXOVEFnoH57PqacEOoVEgYFQU1UdVE
RC7OosYYmpyJP4lY6yH01nSkvshUGLvvOSBpO0qyH2E9GYSx/qXpW0kfKRMc
pYJ9lOAspn+SoGmQEgkZYUxIuIOpG2CT1y+/G1xAKY3FcxwhpNBqPvgEmbhl
kmlhdZWojq2cP0V5ijJXaqbZXggqDXv0cirPqCUvKN3N6d8JZ0EE5cBmyojb
raqJmkggjj5ia0oXDCwoCGXYSfCkK6ouzL9fEeM0ZVH4U19JGv2yd5vsfdNR
rgYPCotE/3px9HpR2m4lnQk7+BDlTVEu2LUbjOjik0IyuXSIuY2KHB7Qj4nZ
Ha9LdSAVjXN50qdP7zAZishlQCRZ3hWwrW+TEgzaBK0qwwrY48C7x89AvImA
B3OmSVvGHy1Whpp2NuMcwyjDT0kJzu/PB3lc9EYA9ENFjhHQjgP4paw8lV/0
9ZRyWJNPSgtw4qXFnC/6isghTlS4yf/qGymRS7TBCfQl+5W+k8quJMZhfZEs
gAo74NSyrMpuL9ARUVwHuMqJ26esplqus7iFgX3/VPRUUXaLRCEu/aYNEA/U
ggNqFQxLAdPKUBWDC264qmRqFtk79ZzRO9Eoia1PAQ8hgSjc6sJvuxKxOadI
xQadfiNFmhRsJa8rOzrHg0L0D6z7aFewo81sdhZ7DdACzVi/WDxO7B68c36A
Nyh7FLt4sIA0O0lYca4w3yegxLv2gDaw0lr0uwrV2Y4KwOKLv1/rjZoFRuIs
B54DH+yhvWhxheiZKkVj1SVUN89iWU3Y92TMPsNOF00HLX9v3TTFcm/vDYig
Nhqu8uIerq/f4v6PpSRQOsKWcwEr5A7Uayi2JgDBIQvuFdUbmQ62CrE5tZUY
VOddhAejzQZYwMWd38Z8frtSzZQtJvSOUTzaTib3EdORNf5s4KWcpq2LCON7
j+V3912K7hRt0bpHqwq9xpLVFViMCoN2dCADB8705HhxOjxUFIHDHQTkJLhy
7rMzpHf+XMWZxgTI9kqOTOi/n631LSe69q2pyiJkvNFlAdjyaph0iFBxOLfA
JBepIUNIMnoeY0mJ2zovfYCtYTXqX9FXK/iQ8F48B24HiOpFMqf0C9vd4JBx
T5gnqNE5IlvSNDHuFuxj3hOWie0bRKymZR5HCCfqIJjInExFvqR9oeNnnPhV
4glYx/0mHjnLtganIqkKQZypFlGjhWTN6FSXtruzIJ9PSc5PjhFyNtgBsyQD
ljIV+FCQaXRjgdGmipJq5YdM0gDIkkU6ZCIphcJFVwDWeUg0NMOAXn7hnaH4
Qmqu2mqrCsVpFOwZ+usBr+cS3gtgarW+RxZjhwWE0NfCWdSoqw5WU1JLFYfb
Z76ETRhv8J6yc7Za0RtuTVlxcbCW3NYzv5zS3iLCpQ+RnoIcO4R1XdKSx0g3
RAYjPicRrOOOLC/ICR3DTGxo7IlrRUkKWMQbxTq1BSzgNz97OJvk8Yn8xY1/
qVbPrqNSug+O0YiKNpGAd8pvfk9SKWlQgoYreJ+ehn0gvUh3+BSbJDJeAG1H
zgThFMXUtGmFOhc1dgnDP95Eqau4gP9AsLuEnpPbg009jLJCouHS0YSFKwyb
VPip7B2DaQaThNYlOajNSHRgv2DEZtznpA1X3dVeAAZZwxoAeGTuVC1IF01q
qRA9B19B6Y5gPPsdSR3b1An3KS5T1kcrVENAwUESOuHOtzlJlhgcMaX5oowJ
4T6CEwLTRUexx/vNOfssLQWDOt1ZqcRgjaBsegc88G1rdDgpnMXjx8NRyqiM
y/QWCpq1h4rSsa4TLlXleoMiioGss9xF3EmPKuxeIwpYDNSC2qHYRO+9xXex
yQ/xYOxNR1pOQZPKls9ETBk5573MnKFa4pIpBbZaScS29wlPxhK+qI0ImoN5
KoOgfvUtHXUJh2SKsiHTiyItzzyKtNF3J9DDgAzIpgMSgH9E0RUEpEtgwWzG
XZUB8I6wEeG17ZaaOlGAdyBCdYf9KFoqW9qQkMMshrR6L32hfh7nQkOOl0jE
LuM1Jps1FY1JMggfOm4s6LmRjnYkRlKS5owipH0oQX6Yl/cnG0USpp5AsNgO
1mIJDQs4kZ5RUmTv80fS9clHr1EE8/Nt8Ftn7GWIsRcDxyV4atIRD9r03dAb
Dh0YQQVkMfWTL+NOBvj7AEB5mQi+Es9MEgCsdU2cbWbfn9sWEyqxLtNCEWHG
b9c3yZO6cxeGo0Z3wVKaAXZas0IjR4kI6dfHWtIRnj2EDbdl29SMiTZsW2RJ
fp+4E+Ok5f22hLDnx/NLDJBc50G65KVF7bF82ZL6ppyNV31wc/Ls5eL06ZNH
J89uHmKgrOH645enzylMuEjQanb18T+yDrseO+2DIUNLsaeZYFWUOY4OgxJ3
YNsUD1FJCMktKSwQbCKyQo0slPckdUD9+b0RntjDxGWTwHJxq5pAlOjJXJTG
mZKpgKmmSGapUkmnaEcQstN65rAINenZRkVR1kJWEu78eYKLX6ErRd3E1ld9
qQdnGNMhm2OMhk/OaSFq8102GBUNWogo/Up/ofeceVvGcnJy/PgpmEzfgXQG
/zf4yOOnL7H9nZxev8QmTOldgu1H4iT9o89foAlGWDAXvxgXehQ2SlIyPg/C
pESoz/LxGbtma0NZCzFQIzKkeh5Xaqkdr4Ygjqyh/QIvhrikwqkDcJXeu0kx
TzqKKN8aCEibskLS0ZWIC0xtGTJQ0nBFvRj6GSmpg2mjah0HIORY50oFHmSD
USaLgc/XvZXWajCDV1ypkrmewbDQqEcMXsmojhNzohIce4A8f7vDDKcUbD05
lUTGLkgvPuG3OVxGHJ709GL7rxbHonTlBPCWVAtXayZ7aglgCmod7KVoFBWX
Wg5UyZSD1mmFKvA2xI/YTO7DR5rl2W7J9nTaKDSES9I/SoE4VWIn6os+PeA5
TDbYHLK8wZg30TGMCHbJup7uNOchOd4E2+iKUdFJDi8uvbOpeuAeynk3Secu
SyqXBD76zOpsdulzT6E3c5B2TsQnHSpaYtXGleh4OJNP7AVX2vXeEEfJQZW9
RfY+6n4aNYUGw4/W8g6tFp31Xp9gmDt+TmPv0Pt0FqokvBGdXWLQNZmmjQoi
QADWfKhuCzYBBBStKPcmKUAhpC6EXdJn+tKVXSgD6ogjCeQhLqe0IpbXMvu7
s79k+aZpuKy8KZf0IcsRHzg4TQY4NVNaIEiVNE7tRLsST004I0r4/1BW0m6K
qnqNKZlK+pEEY0q8gzs/3J36G2as4iYNFCkpCmerhIIuUKCyH0e/E/NznM6a
akeVQT9Qm7rTfr1oAUIZEgxpVY7ywDKwd1a2l/ior9A5zXSETVBxjrNw/3mt
mXbAjk1OM78heyBEaBWwo04p5KsByP/Z7p1CWo449nGMqibD99U0UqL0FE5V
lUOz15ATyjEWohHbfOnFBKolsbW0m5LyRoA7P1P/dtMKjHYdmDGkIQ4vTY5b
nCpKyMp/cGRgKWzR7aEeLK3IxbBx3TWkCjoj7GiUa5cVPUuQlsCbne+jqhXQ
iaEYxGmcbiZq276CALKTMEjGj/HhSCgpUS6i663zqiK9ww4xcKm1zmmA3eFq
WiSq9yNLpPFxZJtKEQKRR+nkSTQrmQXFjjg/yuGHuwiF+Qa8HqOCTkrgSfpa
5DHH8TDOcRFnZDyBOpQ4nqK1gLbrq4s/KXh88QTA6Jx/ePKMkCkX0cuoyR7c
8sawtuatNN8acvN31InpNplvgaApljp4z8PVIR0gLiCS5zZHGVmnGcjyFmW9
aad2HnCDzvROsVdLXFIvDLErKgqGjiIKktyUqOVbXJdgFLePna6Yl+nZzrOk
Wk4JpOGptkomS6n5rkLu4CzZwKfI8l7RDg7XtaM+OYwkuX3jewyZ6oKTbGE0
QUKj8Dz1MVQ5eTn3e3MimqOTOP+MWWe5NaKD6OLnLh+MT2GsFNrDCVVqBph0
luEbZezQssuUrCY3fEiDIHZryT9IQnXlbZrWnGUOdmz8Hc7Ds3m6Pr+kl316
fZndGkBqXpKpjhhlYOO90b5u6MH0130Bv5Z84fXbK10yWD6SqIU0DMefwJYS
7Lwb+lvX4db1xA09E0IqNWV4DMQvrdhx5iPa1SQXIkGSNTWCkHNofOMcypCc
yYMXTx8/9O06ZAiQKoIwK+1j1Ozh40VUnHr+4ukLgjKni+l8P03B00UNJZYl
B6U7PAafW0h6lcpV0mUrfQ95EDO0O9pZ/uqQnAYhjbz6ISnhLnE+SO8y8BzU
IcZzBocLljiEhT18U23Gu6Yq8z3LM03WmHpCr7GLdYnVxmTe58niG13pYtc4
jhutOEEsnk1IcV99CAmMcT8648G9T+HoOLpI1rv3Z+/eSBuxbiFQPpHKyc7W
8J+5zDKDpD3C4wB9sTWggBZiAuqZ9Gkb2PxT2nwykq+5dvKaAZ6EqKy10qgf
/oj7nCA3StiNmISjdVtJhU2+3yeXphnHLUvS7r4dX9cyrISHtva+3sl1JbdW
OqXDwYo2OuxpGMdU2oFMJqjVwIiwbdJBFN/VQK+4n/2EoEBWR2Bk61FKHSEp
D5k0USOJD0S65hFfiRE4wQJI7eYapHGvolwF4nuk6SMPfvpw/uHT++vsn7OT
hz7D+xOdm3bPpIzmRDfLZbHIfrr+y2X4KB46LvLT+duzq6t0BerorYxzahhU
C3hF2KYtHkmnDjAoFgA8zolEgS4fRhZpxlNyNJNdSiWlIOP9YLe6/F1TIdj7
kvZqEoXc7akZnDBAMpTlQe8q4H2gCNENH0rSW+wlmVj+/2Jn/EK6UIECM35S
g5l1I9rBQxJ4gFfsLqq9NKaJiJlBPvh+Gv+rh/p6X1IHwDo/bhyivENFfkkB
UdS3i9aVPjIW+UeeGJ1h+HZZ8c5IPEiRzdLSBJZtWxpprgtsIaXogUxNUQxe
HKfiLZU9wgjbVNq8dGEGGIOsP5W3Vuq32wM9jphanchaBnv0IGm/fji+soSu
gxH/ruqjmfei4OkRvAOAZ1AfHegI06pF6KeJ+Si3uiQpI0mIoLzE1ScWJGJD
QXGryVamA4/JXMfd8PQZjlhpwCr38UTh6mqc7pL2Ck4RxweVzBGiJGEEXq60
+MuzSCAdcgmSyK7sz9vaCD+pkfRmPGoqCFM9Jh5Y9IKmbFezlcygRE4YrMr1
xbs3Hz5dj0N/ZC/bF4gfei60FdFlAVNHJ+lstQc+oWqcv1Rp9J4ycbqya+2g
rcqVpS4FiGg5gTbVSCvMPAtpmtdw2pNcDYN5XtXDUwU+ZVwYNJW2FB0iG350
S10KyUZby3EWOU0yzMMRxuVePSeac28QOZWUqa88Q42hotIau8kG+Rgl8HqD
lXQaaxgOMZEGT6oXBT6PotYr64bG3/hjEQ/hDe4pCU2Y8TWYZsH8nhwUBQyl
y3vn0pxndJJM4IdLTdKRDwvznpE08No6g+X4mhMpj6VHoXJD+B3Pm9Ijebvf
dc26NbsNDnyW65qzh+MsuYKmdLS5kiajWGK/TwGDtDQTwNF/NBgwkknapTYo
HLSN2KDDTxGWffPx4uytxtNqvMmdmxV5GUwNyAPkGLgDvwhYcjyYQXm575aW
URI1U+vXqX/bgEcYvgktr1EDmqYESM1RZqTGTz+HYQzfC5PcxIftimlR2uVg
0qfvY2E3hiAcCAZ5JS2X3NRgVEFaos7jqQbAxtT0BH+bSxr5S5eOvJe2KiSf
9B6fFxnKfYMLFT2tXkRBC6RyRqepbTVAsHayxfeFDZvOBraVBQLTcXCkyaV4
+AxPrYZHktv1BvCd9nBgl+gAFcz7vcSLR8kEahwkOOubKNOCAAXmpJpB4X5T
USPish/e+Iw51aifTrDxlIJNpThJM4cxoAbA2o+BPA7XgyARFi+BpLoDmy8J
TYKDORCKPT4+fq6loejC14/Mw7dqRwHiBpsqUdoIevIVfWmGQU3db7uOj5QE
ld37y6HFJ9jMzc40fURNu0RJktEQy0rd4pJ+GgAOrqBFMhtAXSgYe+iIrdac
5O5sVblwd2JERBO/LlaJsuURg0X2NtmMR60+ax7eDFzCC17Q2PNouq/W3EmE
HHczu9C2xHPy6J+1gYlFlVqZdPIhzoUa7mbkJmHJgdJGN/bQC/BP+Irk4ki9
VohNBZosLS0jiyaSRLR7usuQ3Z8eMSFhOSXCgLgRU6tnCWHqCTvfoCCxu1jG
t9dEtxRqPZHig+Sw2IkZbVEDQ/PFFglzHmhv6+kT2FTfuodBaBD0l5UzK6QQ
51lLR+OQ1OFBJW0+0cRosjNfN1RfXlV8620R5XrJC/NQ83jWhRHS2VBFxA5F
nRKehQEGDXKtr7nUGpsAklXvV539bNojynlWONZM2/btwMaPbURiNOEi+Dz1
BrbkPHlwmcLJrm2qKk6w1YX1M4ihUqV8l1sBkZo1SWvCQrypl0Lh6N5NUzQ7
HpamO6u+Cz9cs+qwSUEStmB/YNs9In/4zMGYRjgXX4jd7HzKmPkF+ERn/uJw
Z8Ca2OhRal2YzcMfyGu57ZOuTPa3gk4avuSqgPG7AmM7LQWuKgjX0fdjKxUl
/T1zudZLRev/I0fpYhFT3EIwiTvV4sMhniY3pZHV6ZrWHvDa8q6q/MxEalMJ
yz8mGfytMzpniDM2pt37CeOo3dQ3/Jbaa19uw0e5XZ3UFMI4LKO0NEcLeLPO
ebD3iwwCoJ3odQZxoLt3cS9yxSb2vb9vdHx3K12s3UirwYQSV6zEg8apiRfT
5UgC6b97ergcD30fPCh0ZnZr+HZEHQL2oSJ8HCsWU/krL1sKAQ6+QhtpKAi6
9hc2S25Pq6Ff72sDDIMtvtJ6cqKZZiI6f0mhv4BAhMsPOPP1iHjNJJe1qSWD
r6jhK24HmVrqDBvcoxpzdXTZK3dKG6wVV5pi8uMJdEJbvBqeJkn8DETX4pXz
eUiojm9coF7IMC+Vmx03qa6SAcXo7muIPnh+HSjTC6T63EZv7clAEXFUH6eB
vR+pN5qMgzQ6wqMs1IhdRHb96Fx81wxgJcTwIbcv/fsRetDwxI/45X2LMxrI
++iOd2rY5x6EHYAXvthUsDB4FgzZQXIgPPGJE/ouAjIm8XmEEre/1yiN6zyt
aMkxNoqu84uu3RlLuu4fnbPIg5hfYJi9Lf1An85B+/ZtLplycQdtcqVIzFuo
OytyOR4mGd5AMZhKITHli4tUSDELNpwbneMr/ICV9nQZamHx06Zp1wW9Md3o
Gnnv5UqczkC4tB5DXKAWBBJmbfDkP3V6GfUd3YK+i0phXh0HI2bUISCjcWmN
LJ7Q4z6ZBtSdLafOL5Z+hGQw/gHYUxeTxtmDt8RG7lcjKD4sPoWDzQP8bRq+
6qyzebsGzJeYPyNV21KH3fgarzPHfBs2tKAr1ZAx9ISMRJ3cLvUU0M3NOItd
UhYJXZEIywD6RZps9yqFDNxDqdtzIyGXuwVDmMINBf7CWH+bRohXhsKuaQLq
S/D65svAcu8sNnr4Gb9wE6aLt4ITZcn4T9z3d5h6TVHcwkvQJGtXQTwTNNU1
mPqlkMjPQrxF93ZKOzX1EYqdivsRYWfhsvD4OgAuwDxw0TXEz4ZX2Tz0dSIp
8ci4nBRObdvokPdyj4j8XbgmMa43C77lMWe91l4WSVtRRrtTTfUXkvh4PO18
XXFlvfYXQabaHApmg1IUsYKnalRjk64dxid7QQXJRS1eYkJ3euxzo0HM+Bs5
fDOivzhpEoj47pqlDSrGUhtr2YRpR5TIow0UDkjLQLB+4vJZgkfachfmu79/
X+/wJoTk3qv0Rte0dk7KoTM8fipazXzkS4ZfWhFG8WOfmt4XPGoiG9jKtJMs
vqo1VTnR5HDTtgxqjGp08wD1eDaZwSlpckjnJJYhqoEODaGTvKmMnN5ZKvpQ
ytMNi34pf8NAy2AA64Oke6OvNSDBKOsS5y0j/HXIAA1vmWxy4AYVI3ievBt/
60jDyZd2O/VmaUjjPpPsLHumtxv4e0altzyafZCrRLnbjwdHBQ3Ii7g2l12s
5moI8Zp5jG3S8YtSvsgEPWWvbVUjTfC3IA6a2kZjMd+8q4V2ganDY8rDkjRX
8Z3E1A+rWX0qvvNtJ4njPHTlyMQ1MhM9cX7eSvotw31zsif4xwH65TKecGFO
1DWoVdccglQga92CBYRohaGAtBDg6VkqxZd0wxPGaVeK1s+lXq5lIG78yUZf
IcK3sXDae5RBjrLG6Rgveiz8+q9C0wWDefeSe+2pyAPWtTTSWFBHqToQw1H7
FBVEAuaQCgnlbxfZOQm3NNhWNIeCpT0ApDVnbblR1YeQqbAkrReS3OCAN830
8lSz6ajeWa/H34HgOy65KzbyUBO+ZvDVIprrDnk7XoMstMycxuxQMTiJyI/K
RsCpOx6nlgYtuStAL9OVL3pIBNY3sw8uTF2NespJ+yl4a3xAT5XYUHsdllND
9kv6haToGtfA0soFf6nXEX+1F96ijlJMhbm2dNxKHpw5TV8lRR2ex4oyrYPv
0aB6yeCmN8rlpGtOlDc3+2VbFjIWmj7yEYcYJx7Zolts8Y8+heu/Mgv7ZuPS
B4Dgwh41q5WL9KIm31X4otaQStaKBtfgrnif2ZPvEtJbFzSbUXCPkRTCCB4o
CWyrfdPJ8FX47TSFnKFg09HYRZSFAoL9ZflR8EwXxVXUUj8FHTO6CjGYy7SO
TI0XuI2xa+jUDRKZfKcy1Xg9sZ7G5T5q2dSIY2CHNV7XYSm53UFo3s4DeAKg
gSkC+QMXWKNmQQaRwbrGjI/OajI7Jvk4qtgQrXKXOpp5s/ZamHzjmwB+RlD4
FXHzJNWE+SX5BjCL69LYW3hase988jKR8YF4PsRXjChkl0KpVLF81ihEGeNG
gYUO6kwJoIqwm7hTK8T9+Hdf3vPmdIiXbj48qP/r9OHNgb5pybph6iNwiRCD
5PxGX/tHS548vKG5J8574zchHdCtwUw+t8Xx7cu/oWgb8sZdh2XOImn66vg7
E/ehiTtOpX5zFl/XuE5RSDqsjlMPrfXJ8AMrR9SOvj/qfwGMoMZL83QAAA==

-->

</rfc>