<?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.9 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC1918 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC2136 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2136.xml">
<!ENTITY RFC4033 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4193 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY RFC6762 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml">
<!ENTITY RFC6763 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml">
<!ENTITY RFC7336 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7336.xml">
<!ENTITY RFC7556 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7556.xml">
<!ENTITY RFC7788 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7788.xml">
<!ENTITY RFC8375 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8375.xml">
<!ENTITY I-D.ietf-dnssd-hybrid SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnssd-hybrid.xml">
<!ENTITY I-D.sctl-service-registration SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.sctl-service-registration.xml">
<!ENTITY I-D.ietf-dnsop-session-signal SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnsop-session-signal.xml">
<!ENTITY I-D.ietf-dnssd-push SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnssd-push.xml">
<!ENTITY I-D.ietf-intarea-provisioning-domains SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-intarea-provisioning-domains.xml">
<!ENTITY I-D.ietf-mboned-ieee802-mcast-problems SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mboned-ieee802-mcast-problems.xml">
]>

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

<rfc ipr="trust200902" docName="draft-ietf-homenet-simple-naming-03" category="info" obsoletes="" updates="">

  <front>
    <title abbrev="Homenet Naming/SD Arch">Homenet Naming and Service Discovery Architecture</title>

    <author initials="T." surname="Lemon" fullname="Ted Lemon">
      <organization>Nibbhaya Consulting</organization>
      <address>
        <postal>
          <street>P.O. Box 958</street>
          <city>Brattleboro</city>
          <region>Vermont</region>
          <code>05301</code>
          <country>United States of America</country>
        </postal>
        <email>mellon@fugue.com</email>
      </address>
    </author>
    <author initials="D." surname="Migault" fullname="Daniel Migault">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>8400 boulevard Decarie</street>
          <city>Montreal, QC H4P 2N2</city>
          <country>Canada</country>
        </postal>
        <facsimile></facsimile>
        <email>daniel.migault@ericsson.com</email>
        <uri></uri>
      </address>
    </author>
    <author initials="S." surname="Cheshire" fullname="Stuart Cheshire">
      <organization>Apple Inc.</organization>
      <address>
        <postal>
          <street>1 Infinite Loop</street>
          <city>Cupertino</city>
          <region>California</region>
          <code>95014</code>
          <country>USA</country>
        </postal>
        <phone>+1 408 974 3207</phone>
        <email>cheshire@apple.com</email>
      </address>
    </author>

    <date year="2018" month="October" day="23"/>

    
    
    

    <abstract>


<t>This document describes how names are published and resolved on
homenets, and how hosts are configured to use these names to discover
services on homenets. It presents the complete architecture, and
describes a simple subset of that architecture that can be used in
low-cost homenet routers.</t>



    </abstract>


  </front>

  <middle>


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

<t>This document is a homenet architecture document. The term ‘homenet’ refers to a set of
technologies that allow home network users to have a local-area network (LAN) with more than one
physical link and, optionally, more than one internet service provider. Home network users are
assumed not to be knowledgeable in network operations, so homenets automatically configure
themselves, providing connectivity and service discovery within the home with no operator
intervention.  This document describes the aspect of homenet automatic configuration that has to
do with service discovery and name resolution.</t>

<t>This architecture provides a minimal set of features required to enable seamless service
discovery on a multi-link home network, but does not attempt to provide feature parity with a
managed LAN.</t>

<t>This document begins by presenting a motivational list of requirements and considerations, which
should give the reader a clear idea of the scope of the problem being solved. It then explains
how each requirement is addressed, and provides references for relevant standards documents
describing the details of the implementation. Not all requirements are addressed by this
architecture document, but the basic requirements are satisfied, and this document serves as a
foundation upon which solutions to the remaining problems can be built.</t>

</section>
<section anchor="requirements" title="Requirements">

<t>Name service on a local area network (LAN) requires the following:</t>

<t><list style="symbols">
  <t>Name: a forward domain under which information about local services will
be published</t>
  <t>Authority: a name server that is authoritative for at least one
forward domain and one or two reverse domains that are applicable to
that network and is capable of signing and publishing the zones
using DNSSEC</t>
  <t>Resolution: a full-service caching DNS resolver that fully supports EDNS(0)
and queries with the DO bit set</t>
  <t>Publication: a mechanism that  <list style="symbols">
      <t>allows services on the LAN to publish information about the services they
provide</t>
      <t>allows services to publish information on how to reach them</t>
      <t>manages the lifetime of such information, so that it persists long
enough to prevent spoofing, but protects end users from seeing
stale information</t>
    </list></t>
  <t>Host configuration: one or more automatic mechanisms (e.g. DHCP or RA) that
provide:  <list style="symbols">
      <t>caching resolver information to hosts on the LAN</t>
      <t>information about how services on the LAN can publish information</t>
    </list></t>
  <t>Trust: some basis for trusting the information that is provided by
the service discovery system</t>
</list></t>

<section anchor="managed-lan-versus-homenet" title="Managed LAN versus Homenet">

<t>A managed network is one that has a (human) manager, or operator.  The operator has authority
over the network, and the authority to publish names in a forward DNS tree, and reverse names in
the reverse tree.  The operator has the authority to sign the respective trees with DNSSEC, and
acquire TLS certificates for hosts/servers within the network.</t>

<t>On a managed LAN, many of these services can be provided by operators. When a new printer is
added to the network, it can be added to the service discovery system (the authoritative server)
manually. When a printer is taken out of service, it can be removed. In this scenario, the role
of “publisher” is filled by the network operator.</t>

<t>In many managed LANs, establishment of trust for service discovery is simply on the basis of a
belief that the local resolver will give a correct answer. Once the service has been discovered
and chosen, there may be some security (e.g., TLS) that protects the connection to the service,
but the trust model is often just “you’re connected to a network you trust, so you can trust the
printer that you discovered on this network.”</t>

<t>A homenet does not have an operator, so functions that would normally be performed by the
operator have to happen automatically. This has implications for trust establishment—since there
is no operator controlling what services are published locally, some other mechanism is required
for basic trust establishment.</t>

<section anchor="multiple-provisioning-domains" title="Multiple Provisioning Domains">

<t>Additionally, whereas in a managed LAN with multiple links to the Internet, the network operator
can configure the network so that multihoming is handled seamlessly, in a homenet, multihoming
must be handled using multiple provisioning domains <xref target="RFC7556"/>.</t>

<t>When a host on a homenet connects to a host outside the homenet, and the homenet is multihomed,
the source address that the host uses for connecting determines which upstream ISP connection is
used.  In principle, this is not a problem, because the Internet is a fully connected network,
so any host that is on the Internet can be reached by any host on the Internet, regardless of
how that host connects to the Internet.</t>

<t>Unfortunately in practice this is not always the case.  Some ISPs provide special services to
their end users that are only accessible when connected through the ISP.  When such a service is
discovered using that ISP’s name server, a response will be provided that will only work if the
host connects using a prefix provided by that ISP.  If another ISP’s prefix is used, the
connection will fail.</t>

<t>In the case of content delivery networks (CDNs), using the name service of one ISP and then
connecting through a second ISP may seem to work, but may provide very poor service.</t>

<t>In order to address this problem, the homenet naming architecture takes two approaches.  First,
for hosts that do not support provisioning domain separation, we make sure that all ISP name
servers are consulted in such a way that Happy Eyeballs will tend to work.  Second, for hosts
that do support provisioning domain separation, we provide information to the hosts to identify
provisioning domains, and we provide a mechanism that hosts can use to indicate which
provisioning domain to use for a particular DNS query.</t>

</section>
</section>
<section anchor="homenet-specific-considerations" title="Homenet-specific considerations">

<t>A naming architecture for homenets therefore adds the following considerations:</t>

<t><list style="symbols">
  <t>All of the operations mentioned here must reliably function automatically,
without any user intervention or debugging.</t>
  <t>Because user intervention cannot be required, naming conflicts must
be resolved automatically, and, to the extent possible,
transparently.</t>
  <t>Devices that provide services must be able to publish those services
on the homenet, and those services must be available from any part
of the homenet, not just the link to which the device is attached.</t>
  <t>Homenets must address the problem of multiple provisioning domains,
in the sense that the DNS may give a different answer depending on
whether caching resolvers at one ISP or another are queried.</t>
</list></t>

<t>An additional requirement from the Homenet Architecture <xref target="RFC7556"/> is
that hosts are not required to implement any homenet-specific
capabilities in order to discover and access services on the
homenet. This architecture may define optional homenet-specific
features, but hosts that do not implement these features must work on
homenets.</t>

</section>
</section>
<section anchor="terminology" title="Terminology">

<t>This document uses the following terms and abbreviations:</t>

<t><list style="hanging">
  <t hangText='HNR'>
  Homenet Router</t>
  <t hangText='SHNR'>
  Homenet Router implementing simple homenet naming architecture</t>
  <t hangText='AHNR'>
  Homenet Router implementing advanced homenet naming architecture</t>
  <t hangText='ISP'>
  Internet Service Provider</t>
  <t hangText='Forward Mapping'>
  A mapping between a host name or service name and some information
about that host or service.</t>
  <t hangText='Reverse Mapping'>
  A mapping between an IP address and the host that has that IP address.</t>
  <t hangText='Homenet Domain'>
  A domain name that is used for publishing the names of devices and services
that are present on the homenet.   By default, ‘home.arpa.’</t>
</list></t>

</section>
<section anchor="name" title="Name">

<t>In order for names to be published on a homenet, it is necessary that there be a set of domain
names under which such names are published. These domain names, together, are referred to as the
“local domains.” By default, homenets publish names for forward lookups under the reserved
domain ‘home.arpa.’ <xref target="RFC8375"/> publishing names.</t>

<t>So a host called ‘example’ that published its name on the homenet would publish its records on
the domain name ‘example.home.arpa.’. Because ‘home.arpa.’ is used by all homenets, it has no
global meaning, and names published under the domain ‘home.arpa’ cannot be used outside of the
homenet on which they are published.</t>

<t>How to publish names outside of the homenet is out of scope for this document.  However, in
order to address the problem of validating names published on the homenet using DNSSEC, it is
necessary that the homenet have a globally valid delegation from the root.  This allows hosts on
the homenet to validate names published on the homenet using the DNS root trust anchor
(<xref target="RFC4033"/> section 3.1).</t>

<t>It is not necessary that this delegation work for hosts off the homenet. HNRs implementing this
specification do not answer queries from outside the homenet; however, when a validating
resolver inside the homenet attempts to validate the chain of trust up to the root zone, the
chain of trust will validate correctly, because the answer given for internally-available
zones will be signed by a DS record that is present in the delegation externally.</t>

<t>If there is a valid delegation from the root, the homenet domain will be the name of the delegated
domain.   By default, there will be no delegation from the root; in this case, the homenet domainname
will be ‘home.arpa.’</t>

<t>In addition to the homenet domain, names are needed for reverse lookups. These names are dependent
on the IP addressing used on the homenet. If the homenet is addressed with IPv4, a reverse
domain corresponding to the IPv4 subnet <xref target="RFC1034"/> section 5.2.1 should be constructed. For
example, if the homenet is allocating local IP addresses out of net 10 <xref target="RFC1918"/>, a domain,
‘10.in-addr.arpa’ would be required. Like ‘home.arpa.’, ‘10.in-addr.arpa’ is a locally-served
zone, and has no validity outside of the homenet.</t>

<t>If the homenet is addressed with IPv6, it is expected to have a unique local address prefix.
The reverse mapping domain for hosts on any link in the subnet will be a subdomain of the
reverse zone for the subset of the ULA prefix that is being advertised on that link. Every
service on the homenet that supports IPv6 is expected to be reachable at an address that is
configured using the ULA prefix. Therefore there is no need for any IPv6 reverse zone to be
populated other than the ULA zone.  So for example if the homenet’s ULA prefix is
fc00:2001:db8::/48, then the reverse domain name for the homenet would end in
‘8.b.d.0.1.0.0.2.0.0.d.f.ip6.arpa’.</t>

</section>
<section anchor="authority" title="Authority">

<t>There are two types of authoritative name service on the homenet.  Every link on the homenet has
a zone that is a subdomain of the homenet’s primary domain.  Authority for these zones is local
to the HNR that is currently authoritative for that zone.  The contents of these zones are
served using DNSSD Discovery Proxy <xref target="I-D.ietf-dnssd-hybrid"/>.  Consequently, there is no need
for database replication in the case that a new HNR is elected; that HNR simply takes over the
Discovery Relay function.</t>

<t>Name service for the homenet domain itself may be stateless or stateful.  HNRs are not required
to implement stateful service.  If one or more HNRs on the homenet are capable of providing this
service, then one of those HNRs is elected to act as the primary nameserver for the homenet
domain; one or more HNRs may also act as secondary servers.</t>

<t>Name service for reverse mapping subdomains is only provided if one or more HNRs can provide
stateful service.  If no such server is present, the reverse mapping subdomains are not served.
If stateful servers are present, the primary and secondary servers for these subdomains will
be the same as for the homenet domain.</t>

<section anchor="reachability" title="Reachability">

<t>Whether the homenet domain is a global domain name or not, HNRs answering queries for domains on
the homenet do not respond to queries from off the homenet unless configured to do so.  Exposing
services on the homenet for browsing off the homenet creates many opportunities for security
issues; as such, even an HNR configured to answer queries from prefixes off the homenet do not
provide answers for names of devices on the homenet unless configured to do so.  How
reachability of names published on the homenet is managed is out of scope for this document: an
HNR implementing only this document checks the source address of every query to see if it is
within a prefix belonging to the homenet; if not, the HNR does not answer the query.</t>

</section>
<section anchor="link-names" title="Link Names">

<t>Each link must have a name.  These names are determined using HNCP.  Each router will have zero
or more wired links, each of which must be labeled.   In addition, each router will have zero or
more wireless links.  Each of these links will be named by the frequency band the link supports,
2.4ghz or 5ghz.</t>

<t>The HNR is named using its manufacturer name.   If, as is likely, two or more HNRs from the
same manufacturer are present on a homenet, then the HNR name is made up of the manufacturer
name plus as many hexadecimal digits as are required from the HNRs link layer addresses so as
to disambiguate them.</t>

<t>When shipping multiple HNRs as a kit, manufacturers are advised to arrange that each HNR has a
different number in the lowest four bits of the link-layer address.   Manufacturers are also
advised to print that link layer address, in full, somewhere on the outside of the HNR where
it can be seen by the user.  Since most HNRs will have more than one interface, the manufacturer
should be consistent in choosing which link-layer address is printed on the outside and used
to identify the router.</t>

<t>The name given to a link is the name of the HNR, plus a hyphen (‘-‘), plus name of the interface
of that HNR that is attached to the link.  In the event that this name must be displayed to the
user, this should give the user enough information to figure out which link is being referenced.
In the event that the HNR that is providing authoritative service for that link changes, the
link name changes.   This should only happen if the network topology changes.</t>

<t>If the appearance of a new HNR requires that the name of an existing HNR change, then the names
of all the links managed by that existing HNR change to reflect the new name.</t>

</section>
<section anchor="authoritative-name-service-for-the-homenet-domain" title="Authoritative name service for the homenet domain">

<t>All HNRs must be capable of providing authoritative name service for the homenet domain.  HNRs
that provide only stateless authoritative service publish the information that is required for
hosts to do DNS Service Discovery over DNS, using the local resolver as a DNSSD Discovery
Broker.</t>

<t>Some contents are required for the homenet domain, whether it is stateful or stateless.</t>

<t><list style="symbols">
  <t>Every link on the homenet has a name that is a subdomain of the homenet domain.  The zone
associated with the homenet domain contains a delegation for each of these subdomains.</t>
  <t>In order for DNSSD service discovery to work, a default browsing domain must be published.
The default browsing domain is simply the homenet domain.</t>
  <t>If DNSSD SRP is supported (that is, if stateful authoritative service is present), then an SRV
record must be published, along with a list of available registration zones containing exactly
one entry, for the homenet domain (<xref target="I-D.sctl-service-registration"/> section 2).</t>
  <t>Also if DNSSD SRP is supported, then one or more A and/or AAAA records must be published under
the name that the SRV record points to, which should be a single label subdomain of the
homenet domain.</t>
</list></t>

<t>Both stateful and stateless authoritative servers provided by HNRs must support DNS Stateful
Operations <xref target="I-D.ietf-dnsop-session-signal"/> and DNS Push <xref target="I-D.ietf-dnssd-push"/> for the
names for which they are authoritative.</t>

</section>
<section anchor="authoritative-name-service-for-per-link-subdomains-of-the-homenet-domain" title="Authoritative name service for per-link subdomains of the homenet domain">

<t>Per-link subdomains of the homenet domain are served by DNSSD Discovery Proxies.  Although these
proxies generally do caching, no long-lived state is kept by them.  DNSSD Discovery Proxies
running on HNRs must support DNS Stateful Operations and DNS Push.</t>

</section>
<section anchor="authoritative-name-service-for-the-ula-reverse-mapping-domain" title="Authoritative name service for the ULA reverse mapping domain">

<t>The ULA reverse mapping domain itself is only published if stateful name service is available.
It is represented as a single zone, which contains no delegations: every reverse mapping for an
address in the ULA prefix is simply published in the ULA zone.</t>

<t>In order to permit registration of reverse mappings in this domain, it must contain an SRV
record for the label _homenet-rrp._tcp at the top level, pointing to the primary server for the
domain.</t>

</section>
<section anchor="Z1918" title="Authoritative name service for the RFC1918 reverse mapping domains">

<t>If IPv4 service is being provided on the homenet, and if stateful name service is being provided
on the homenet, then either one or sixteen reverse mapping zones for the RFC1918 prefix in use
must be provided.  If more than one RFC1918 prefix is in use, reverse mapping zones for all such
prefixes must be provided.</t>

<t>Like the ULA reverse mapping zone, the RFC1918 reverse mapping zones must each contain an SRV
record on the label _homenet-rrp._tcp at the top level, pointing to the name of the primary
server for the zone.</t>

<t>The RFC1918 reverse mapping zone contains the entire address space of the RFC1918 prefix that is
in use on the homenet.  Section 3 of RFC1918 defines three prefixes that may be used.  The
homenet will use all of one of these three prefixes.  Of these, the 172.16.0.0 prefix is
subdivided on a 12-bit boundary, and therefore must be represented as 16 separate zones.
The 10.0.0.0/8 and 192.168.0.0/16 prefixes are each represented as a single zone.</t>

<t>The zone to be updated is therefore the 10.in-addr.arpa zone for all addresses in 10.0.0.0/8,
and the 168.192.in-addr.arpa zone for all addresses in 192.168.0.0/16.  For addresses in the
172.16.0.0/12 prefix, the zone to be updated is the subdomain of 172.in-addr.arpa that
corresponds to bits 8-11 of the prefix: a number between 16 and 31, inclusive.</t>

<t>Also like the ULA zone, the RFC1918 reverse mapping zones contain no delegations: if there is a
single zone, then every reverse mapping published for an address in the RFC1918 prefix in use on
the homenet is published directly under this zone.  If there are sixteen zones, each address is
published in its respective zone.  Because the zone 172.in-addr.arpa is not available to be
served locally, its locally served subdomains are simply served individually with no delegation.</t>

</section>
</section>
<section anchor="resolution" title="Resolution">

<t>Name resolution on the homenet must accomplish two tasks: resolving names that are published on
the homenet, and resolving names that are published elsewhere.  This is accomplished by
providing several functional layers.</t>

<t><list style="numbers">
  <t>The set of caching nameservers provided by the ISP or ISPs through which the homenet gains
access to the global internet, if any (homenets can operate standalone as well).</t>
  <t>The set of stateful name servers on the homenet that are authoritative for the homenet domain
as a whole, and for any reverse mapping zones that are provided by the homenet.  This layer
is optional, and may or may not be present.  If present, it is provided by one or more HNRs
on the homenet that support stateful service.</t>
  <t>The set of stateless name servers on the homenet that are authoritative for the homenet
domain as a whole.  These are not used if one or more stateful servers are present.</t>
  <t>The set of stateless DNSSD Discovery Proxies that are authoritative for each of the links
in the homenet.</t>
  <t>A DNS routing proxy.   Hereafter we refer to this as the DNS proxy.</t>
</list></t>

<t>The reason that these are described as layers is that it’s quite possible that all of the DNS
services on the homenet might be provided by a single service listening on port 53; how the
request is routed then depends on the question being asked.  So the services described as
running on HNRs are treated as functional blocks which may be connected internally, if the
question being asked can be answered directly by the HNR that received it, or they may be
separate name servers running on different HNRs, if the question can be answered within the
homenet, or it may be that the HNR receiving the query forwards it to an ISP caching name
server.</t>

<t>The routing works as follows.  When a request is received (opcode=0, Q/R=0), the DNS proxy looks
at the owner name in the question part of the message.</t>

<t><list style="symbols">
  <t>If the name is a subdomain of the homenet domain, the query is local.</t>
  <t>If the name is a subdomain of a locally-valid ULA reverse mapping domain, the query is local.</t>
  <t>If the name is a subdomain of a locally valid RFC1918 reverse mapping zone, the query is local.</t>
  <t>If the name is a subdomain of any locally-served zone, as defined in Locally Served DNS
Zones <xref target="localzones"/>, but is not otherwise identified as local, the response is NXDOMAIN.</t>
  <t>Otherwise, the query is not local.</t>
</list></t>

<t>Local queries are further divided.  If the query is for a link subdomain, the DNS proxy consults
the table that maps per-link subdomains to the HNRs that serve them.  Either the HNR that serves
this link subdomain is the HNR that received the question, or not.  If it is, then the DNS proxy
passes the query directly to the local DNSSD Discovery Proxy.   Otherwise, it forwards the query
to the DNSSD Discovery Proxy on the HNR that is providing Discovery Proxy service for that link.</t>

<t>If the query is for the homenet subdomain, and stateful authoritative service for the homenet
subdomain is present on the homenet, then either the HNR receiving the query provides stateful
authoritative service, or not.  If it does, then the query is passed directly to the local
authoritative server.  If not, then the HNR looks in the table of authoritative servers
generated by HNCP and forwards the request to one of these servers.  Queries for the reverse
mapping zones are handled the same way.</t>

<t>Otherwise, the query is examined to see if it contains an EDNS(0) Provisioning Domain option.  If
not, it round-robined across the resolvers provided by each ISP in such a way that each ISP is
tried in succession, and the same ISP is not asked the same question repeatedly.  If the query
does contain the EDNS(0) Provisioning Domain option, then that option is used to select which
ISP’s resolvers are used for the round robin.</t>

<section anchor="round-robining" title="Round Robining">

<t>There are several cases above where there may be a choice of servers to which to forward
queries.  It’s assumed that when the query can be satisfied by the HNR that received it, round
robining is not required.  If there is a specific HNR that is responsible for a particular link,
then round robining is likewise not required.  However, if the query is for a stateful
authoritative server, and the HNR that received it does not provide this service, and there is
more than one HNR on the homenet that does provide the service, the HNR that received the query
round robins it across the available set of HNRs that could answer it.</t>

<t>Similarly, if the query is to be sent to an ISP’s resolver, and the ISP has provided more than
one resolver, round robining is done across the set of resolvers provided by that ISP.  If the
query is to be attempted at every ISP, then that is accomplished by round-robining in such a way
that each ISP is tried in succession, rather than all the resolvers at one ISP, and then all the
resolvers at the next ISP, and so on.</t>

</section>
<section anchor="retransmission" title="Retransmission">

<t>For queries that can’t be resolved locally by the HNR that received them, retransmission as
described in <xref target="RFC1035"/> is performed.</t>

</section>
<section anchor="dns-stateful-operations-and-dns-push" title="DNS Stateful Operations and DNS Push">

<t>DNS proxies on HNRs are required to support DNS Stateful Operations and DNS Push.  When a DNS
Push operation is requested on a name that can be satisfied by the HNR that received it, it is
handled locally.  When such an operation is requested on a name that is local to the homenet,
but can’t be satisfied by the HNR that received it, a DNS Stateful operation is started with the
HNR that is responsible for it.</t>

</section>
<section anchor="multicast-dns" title="Multicast DNS">

<t>In addition to consulting the local resolver, hosts on the homenet may attempt to discover
services directly using Multicast DNS.  HNRs may filter out incoming Multicast DNS queries,
forcing the client to do service discovery using the DNS protocol.  If such filtering is not
done, the client will be able to discover services on the link to which it is attached, but will
not be able to discover services elsewhere.</t>

<t>It is believed that all currently-available hosts support DNSSD using the DNS protocol.  Support
for mDNS on the local link is therefore not required.  However, if an mDNS query returns the
same answer as the DNS protocol query, this is not expected to be a problem.</t>

</section>
<section anchor="host-behavior" title="Host behavior">

<t>Hosts that support the RA Provisioning Domain option direct queries to the name server(s) of the
provisioning domain they will use for communication using the EDNS(0) provisioning domain
option.  In practice this means that a host that supports PvDs will keep a set of provisioning
information for each prefix that it received from the router, and will either choose a prefix to
use based on its own criteria, or will attempt to connect using every PvD at once or in
sequence.  Answers to queries sent for a particular provisioning domain will only be used with
source addresses for prefixes that are in that provisioning domain.</t>

</section>
</section>
<section anchor="publication" title="Publication">

<t>Names are published either using Multicast DNS Service Discovery <xref target="RFC6762"/> or DNSSD Service
Registration Protocol (<xref target="I-D.sctl-service-registration"/>).  Reverse mappings are published
using Homenet Reverse Mapping Update Protocol <xref target="HRUMPH"/>.</t>

<section anchor="dnssd-service-registration-protocol" title="DNSSD Service Registration Protocol">

<t>HNRs that provide stateful authoritative service also publish information acquired
using DNSSD Service Registration Protocol <xref target="I-D.sctl-service-registration"/>.  DNSSD SRP does not
explicitly support population of the reverse zone; hosts that wish to provide reverse mapping
information must first establish their hostname using DNSSD SRP; once established, the key used
to authenticate the DNSSD SRP update is also used to update the reverse name.</t>

<t>Support for SRP provides several advantages over DNSSD Discovery Proxy.  First, DNSSD SRP
provides a secure way of claiming service names.  Second, a claimed name is valid for the entire
network covered by the SRP service, not just an individual link, as is the case with mDNS.
Third, SRP does not use multicast, and is therefore more reliable on links with constrained
multicast support <xref target="I-D.ietf-mboned-ieee802-mcast-problems"/>.</t>

<t>Support for the DNSSD SRP service is not sufficient to achieve full deployment of DNSSD SRP: it
is also necessary that services advertise using DNSSD SRP.  Requiring such support is out of
scope for this document; our goal is simply to specify a way in which DNSSD SRP can be supported
on homenets, so that that as adoption of SRP increases on devices providing service, it can
actually be used.</t>

</section>
<section anchor="HRUMPH" title="Homenet Reverse Mapping Update Protocol">

<t>This is an extension to the DNSSD Service Registration protocol.  The purpose is to allow for
updates of reverse mappings.  Hosts wishing to publish reverse mappings first publish their
hostname using DNSSD SRP.  When this process has successfully completed, the host can add reverse
mappings to the ULA reverse mapping domain and to the RFC1918 reverse mapping domain, if present.</t>

<section anchor="AULA" title="Adding ULA reverse mappings">

<t>The host first determines the ULA prefix.  If there is more than one ULA prefix active, the ULA
prefix with the longest preferred lifetime is used.   A ULA prefix can be identified because it
matches the prefix fc00::/7 (<xref target="RFC4193"/> section 3.1).   The actual prefix is then the first
48 bits of the advertised prefix or the IP address in that prefix.</t>

<t>Because the ULA reverse mapping zone contains no delegations, all updates go to that one zone.
To determine where to send the updates, the host first queries the SRV record under the label
_homenet-rrp._tcp at the top of the ULA reverse mapping zone.  It then uses the name contained
in the SRV record to look up A and/or AAAA records to which to send the update.</t>

<t>The update is then signed using SIG(0) with the key that was used for the DNSSD SRP
registration.  The update is then sent using DNS Update <xref target="RFC2136"/> to one of the IP addresses
received during the A/AAAA resolution step.  The update is sent using TCP; if a TCP connection
to one of the addresses fails, each subsequent address is tried in succession; if none of the
addresses is reachable, the update fails, and may be retried after a reasonable period (on the
order of an hour) has elapsed.</t>

</section>
<section anchor="adding-rfc1918-reverse-mappings" title="Adding RFC1918 reverse mappings">

<t>RFC1918 reverse mapping updates use the same mechanism as ULA reverse mapping updates.  The host
must first determine which zone to update, as described earlier in <xref target="Z1918"/>.   Once the zone
has been determined, the reverse mapping is updated as described in <xref target="AULA"/>.</t>

</section>
</section>
</section>
<section anchor="host-configuration" title="Host Configuration">

<t>Each HNR provides a Homenet DNS Proxy.  When an HNR provides the DNS resolver IP address to
hosts on the link using RA, DHCPv4 or DHCPv6, it provides its own address.  The IPv4 address
that it provides is a valid IPv4 address on the link to which the host is attached.  The IPv6
address it provides is an address in the homenet’s ULA prefix that is valid on the link to which
the host is attached.</t>

<t>When sending router advertisements, the homenet includes the PvD ID RA option
<xref target="I-D.ietf-intarea-provisioning-domains"/> in each RA.  Because the PvD ID RA option can only be
sent once per RA message, if the homenet is connected to more than one ISP, the prefixes for
each ISP must be advertised in different RA options.  In this case, the prefix for the ULA
should also be sent in a separate RA.</t>

<t>If the configuration received from the ISP includes a Domain Name (DHCPv4) or Domain Search List
(DHCPv4 or DHCPv6) option, the domain name provided is used to identify the PvD.  In the case of
Domain Search List options, if there is more than one, the first one is used.  For the ULA
prefix, the homenet domain is used to identify the PvD.</t>

<t>In order to facilitate DNSSD bootstrapping, any DHCPv4, DHCPv6 or RA Domain Search List options
contain only a single domain name, the homenet domain.  This allows hosts to quickly bootstrap
DNS Service Discovery using the local domain name, as descried in <xref target="RFC6763"/> section 11.</t>

</section>
<section anchor="globally-unique-names" title="Globally Unique Names">

<t>Homenets are not required to have globally unique names.  Homenets operating according to this
specification do not publish names in such a way that they can be resolved by hosts that aren’t
on the homenet.  However, such names are useful for DNSSEC validation.</t>

<t>There are three ways that homenets can get global names:</t>

<t><list style="numbers">
  <t>They can be manually configured by the user.  How this is done is out of scope for this
document.</t>
  <t>They can publish a delegation with the ISP, using a Homenet Delegation Registration Protocol
<xref target="DeRP"/>.</t>
  <t>They can publish a delegation with some other provider, using Homenet Delegation Registration
Protocol <xref target="DeRP"/>.  How this is configured is out of scope for this document.</t>
</list></t>

<t>Homenets are also not required to support global delegations for reverse mapping of global IPv4
and IPv6 addresses.   How this would be done is out of scope for this document.</t>

</section>
<section anchor="dnssec-validation" title="DNSSEC Validation">

<t>DNSSEC validation for ‘home.arpa’ requires installing a per-homenet trust anchor on the host,
and is therefore not practical.  Validation for locally-served reverse zones for the ULA and
RFC1918 addresses would likewise require a trust anchor to be installed on the host, and
likewise are not practical.</t>

<t>If DNSSEC validation is to be done for the homenet, the homenet must acquire a global name, and
must be provided with a secure delegation.  Secure delegations must also be provided from the
homenet domain to each of the per-link subdomains.</t>

<t>Each HNR on a homenet generates its own private/public key pair that can serve as a trust
anchor.  These keys are shared using HNCP <xref target="RFC7788"/>. HNRs MUST NOT use pre-installed keys:
each HNR MUST generate its own key.  The HNR responsible for authoritative Discovery Proxy
service on a particular link signs the zone for that link; delegations from the homenet domain
zone to each per-link subdomain zone include a DS record signed by the ZSK of the homenet zone.</t>

<section anchor="how-trust-is-established" title="How trust is established">

<t>Every HNR has its own public/private key pair.  A DS record for each such public key is
published in the delegation for the homenet domain.  If stateless authoritative service for the
homenet zone is being provided, then each HNR signs its own homenet zone.  The signed zone
should be very stable, although the delegations may change when the network topology changes.
The HNR can therefore sign the zone using its private key whenever it changes.  Each HNR will
have a copy of the zone signed with a different key, but since all of the ZSKs are present in
the DS RRset at the delegation point, validation will succeed.</t>

<t>If stateful authoritative service is being provided, the HNR that is acting as primary signs the
zone, and all the secondaries serve copies acquired using zone transfers.  If the HNR that is
primary goes away, then a secondary becomes primary and signs the zone before beginning to
provide service.  Again, since all of the HNR’s public keys exist in the DS RRset at the
delegation, the zone can be validated.</t>

</section>
</section>
<section anchor="DeRP" title="Homenet Delegation Registration Protocol">

<t>Homenet Delegation Registration Protocol (HDeRP) operates similarly to DNSSD Service
Registration Protocol.  When a homenet is not connected to an ISP that supports HDeRP, and then
an ISP connection becomes available, the HNR that is connected to the ISP determines whether
HDeRP is available.  This is done by first determining the ISP domain.</t>

<t>If the connection to the ISP is IPv4-only, this will be either the DHCPv4 Domain Name option or,
if not present, the only domain name in the DHCPv4 Domain Name Search List option.  If the
Domain Name Search List option contains more than one name, HDeRP is not supported by the ISP.</t>

<t>If the connection to the ISP is dual-stack or IPv6-only, then the DHCPv6 Domain Search List
option obtained through DHCPv6 Prefix Delegation is used.  If it is not present, or if it
contains more than one domain name, HDeRP is not supported by the ISP.</t>

<t>Once the ISP domain has been discovered, the HNR looks for an SRV record owned by the name
_homenet-derp._tcp under the ISP domain.  If this is not present, HDeRP is not supported.  If
the SRV record is present, then the HNR looks for A and AAAA records on the hostname provided in
the HNR.   If present, these are used when attempting the update.</t>

<t>The HNR then constructs a DNS update.  The DNS update creates a delegation for the zone
home.arpa, with a DS record for each HNR on the homenet, containing that HNR’s public key.  The
HNR doing the update lists its key as the first key in the DS RRset.  The update is signed using
SIG(0) with the private key of the HNR that is constructing it.  As with DNSSD SRP, the update
includes an Update Lease EDNS(0) option, specifying a key lifetime of a week.</t>

<t>The HNR then attempts to connect to the hostname provided in the SRV record, in a round-robin
fashion across the set of IP addresses discovered during the A/AAAA lookup phase.  When it has
successfully connected, it sends the DNS update.</t>

<t>The HDeRP server validates the update by checking the SIG(0) signature of the update against the
first key in the DS RRset.  If the update is successfully validated, then the server generates a
domain name and sends a reply back to the HNR on the same TCP connection, including the NOERROR
(0) RCODE, and including in the query section the actual domain name that was generated.</t>

<t>This domain name then becomes the homenet name.  Subsequent updates use the homenet name rather
than ‘home.arpa’.  It is not necessary that the same HNR do the update; if a different HNR does
the update, it lists its public key first in the DS RRset, and signs the update using its
private key.</t>

<t>The HDeRP is responsible for removing the delegation if it is not refreshed for the length of
its lifetime.  HNRs should attempt to refresh the delegation when half the lifetime has
experienced, then again at 5/8ths, and again at 7/8ths of the lifetime.  If the ISP becomes
unavailable, and a different ISP becomes available that supports HDeRP, the homenet should
migrate to the new ISP.</t>

</section>
<section anchor="using-the-local-namespace-while-away-from-home" title="Using the Local Namespace While Away From Home">

<t>This document does not specify a way for service discovery to be performed on the homenet by
devices that are not directly connected to a link that is part of the homenet.</t>

</section>
<section anchor="expected-host-behavior" title="Expected Host Behavior">

<t>It is expected that hosts will fall into one of two categories: hosts that are able to discover
DNS-SD browsing domains, and hosts that are not.   Hosts that can discover DNS-SD browsing
domains can be expected to successfully use service discovery across the entire homenet.
Hosts that do not will only be able to discover services on the particular local subnet of the
homenet to which they happen to be attached at any given time.</t>

<t>This is not considered to be a problem, since it is understood by the authors that the vast
majority of hosts that are capable of doing mDNS discovery are also capable of doing DNS-SD
discovery as described in <xref target="RFC6763"/>.</t>

</section>
<section anchor="mgt" title="Management Considerations">

<t>This architecture is intended to be self-healing, and should not require management.  That said,
a great deal of debugging and management can be done simply using the DNS Service Discovery
protocol.</t>

</section>
<section anchor="privacy-considerations" title="Privacy Considerations">

<t>Privacy is somewhat protected in the sense that names published on the homenet are only visible
to devices connected to the homenet.  This may be insufficient privacy in some cases.</t>

<t>The privacy of host information on the homenet is left to hosts.  Various mechanisms are
available to hosts to ensure that tracking does not occur if it is not desired.  However,
devices that need to have special permission to manage the homenet will inevitably reveal
something about themselves when doing so.</t>

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

<t>There are some clear issues with the security model described in this document, which will be
documented in a future version of this section.  A full analysis of the avenues of attack for
the security model presented here have not yet been done, and must be done before the document
is published.</t>

</section>
<section anchor="IANA" title="IANA considerations">

<section anchor="homenet-reverse-registration-protocol" title="Homenet Reverse Registration Protocol">

<t>IANA is requested to add a new entry to the Service Names and Port Numbers registry for
homenet-rrp with a transport type of tcp.  No port number is to be assigned.  The reference should
be to this document, and the Assignee and Contact information should reference the authors of
this document.  The Description should be as follows:</t>

<t>Availability of Homenet Reverse Registration Protocol service for a given domain is advertised
using an SRV record with an owner name of “_homenet-rrp._tcp.&lt;domain&gt;.” in that domain, which
gives the target host and port where Homenet Reverse Registration service is provided for the
named domain.</t>

</section>
<section anchor="homenet-delegation-registration-protocol" title="Homenet Delegation Registration Protocol">

<t>IANA is requested to add a new entry to the Service Names and Port Numbers registry for
homenet-derp with a transport type of tcp.  No port number is to be assigned.  The reference
should be to this document, and the Assignee and Contact information should reference the
authors of this document.  The Description should be as follows:</t>

<t>Availability of Homenet Delegation Registration Protocol service for a given domain is advertised
using an SRV record with an owner name of “_homenet-derp._tcp.&lt;domain&gt;.” in that domain, which
gives the target host and port where Homenet Delegation Registration service is provided for the
named domain.</t>

</section>
<section anchor="unique-local-address-reserved-documentation-prefix" title="Unique Local Address Reserved Documentation Prefix">

<t>IANA is requested to add an entry to the IPv6 Special-Purpose Address Registry for the prefix
fc00:2001:db8::/48.  The Name shall be “Unique Local Address Documentation Prefix.”  The
reference RFC will be this document, once published.  The date will be the date the entry was
added.   All other fields will be the same as for the Documentation prefix, 2001:db8::/32.</t>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC1034;
&RFC1035;
&RFC1918;
&RFC2136;
&RFC4033;
&RFC4193;
&RFC6762;
&RFC6763;
&RFC7336;
&RFC7556;
&RFC7788;
&RFC8375;
&I-D.ietf-dnssd-hybrid;
&I-D.sctl-service-registration;
&I-D.ietf-dnsop-session-signal;
&I-D.ietf-dnssd-push;
&I-D.ietf-intarea-provisioning-domains;
<reference anchor="localzones" target="https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml">
  <front>
    <title>Locally-Served DNS Zones</title>
    <author >
      <organization>Internet Assigned Numbers Authority</organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>


    </references>

    <references title='Informative References'>

&I-D.ietf-mboned-ieee802-mcast-problems;


    </references>



  </back>

<!-- ##markdown-source:
H4sIAP5Lz1sAA7V965LbyJHu/3oKhCZiW/IhqW5dRppWbIR7pPFKsTNSu1tj
n/CfDZAEm7BAgAbApmjFRJyHOE94nuTkl5e6gOiWvGs7dm01CFRlZWXlPbOm
06krt+151re7rn9yevrD6RO3bBZ1vinOs2Wbr/ppWfSr6brZFHXRT7tys62K
Kf1e1jfT06dukffnWVmvGtfMu6Yq+qI7z05O3G67zO3f2/LcZVnfLOivQ9Gd
0B+LZrPNF3140B02bbHq7EFf9hVB8Famzd7zfFleL7Pror0tF0X2puwWzW3R
HrKLdrEu+2LR79rC5fN5W9wOv3x8/YZfcwDqPHtyevZyenY6ffLU5bt+3bTn
bkqLoNk/zrKfi01TE0SCg4/F0j9p2pvz7H05n6/zQ569bupuV/U0OsDv26Kg
5VzOPsyyH5vP2Q/PX2KZZX84z35s856WM2/ahp61xU3Z1OfZn4qWhu0ZGbu6
b+nFX2taBy2xB+qyZpVdbIq2XOT8zpKgOTl9/vT0DPgqNnlZnWeboqqa+ver
3c2umBFSbR1vZtkv5U1O8PmVvMnrsqiix7ycn2j8ruPl2RpePjs9zebNripu
83aZvSkWeVsWfjW/ENBtkVeT7I+vs7fPLrMn75/Ei3id1/kSIK/yBZFLiX08
iUBeMhyzjcDx+0IBYOizbNeW/Lqu43qWvV4X3bpsC7+Q636Xt338nFdysSXK
zN7Vi1m0ljN6sCqB1uznptn6RbzebYuW9i7ekNd5Va6ati4jfP/w/PTs2Umy
R9cX9Od23dT0+4P/dZY9O32Z/fDiWfb0yemLB2GZCwXv9zng4tW5umk3eV/e
FjgPV394fXb69Nl55v/93P/7h7OX9u8nZ0+/t38/O336VD99dvaD/fP7F98/
sTfo30/t3y+e0pf6z+fP/SAvXrx8qY9fPn0hc76bvpnxOV/WXbecrg/ztlz6
X7pFX007OXdTYIuwS8sAzgbfNlt6r+voJ+IUN3VejY2+3XXr8/hxWfc5UdR0
2za3JT4Gb1k2hEciAXqxahZ59XdCOP9FnESYw894XB2m4Ah0at68v87+gpf4
HTvXGf+HCeRd3RcteMJFB+Dok/e7zbxou+yCXybCkOHz9ga0s+77bXf++PF+
v5+VRNQzGuVxzt8Sb+m7x5UC0DEAWN2Uobzzh9nndb+pHNhlRAgeD5s5vbQk
hlsUL0+fTDeLvOuBlHlVbGjpbjqdZvkcyF/0zrmP67LLiFnvAE22LLpFW86J
b6ybPZ+ULiOsZtvdvCq7Na0W3LMtiEkDW3Tilad3E/4FX62brpevFg0dmxti
qEvi29muK7Ke6LnQcenRUtmvU7ogdlVnNuIse9dnW5oLaMKXzO8hHGjwwKx5
YhcAzzMRL1m3m3e0T8QA+3XeJ9/Ik0VeZ/MCcC2JT7iq2U8XBLsBkLXNjva6
mwnONuVyWRXOfQcSaJvlbgHiHSKwBAA2QDKlvTLLPtJSaOBNdqIvnhBGVyAh
QgmBz0A7+m5dN1VzUwJXvALi0nsePKOP9k37CbDLZ+v8ltAiRD7FOfCvPPz5
4v2jbF/262zTyNJrQnPhtutDR2Khyqqy/gQkTrJmizWB6ibpy4QfJXvdqYyP
2bJoZywkBwDlkKFdR+tdZnXTA0BC9Ke62VfF8qbIiRZpRP9RQ2yUWQFRUdd4
AsDxa0DhfA4CNTmihU1XEAXS+wIH5Dr9XhOuy1s6gkyMBurSC3lggeYFLTEa
GSt1owA0reNl3tIuETCzLLvrcGCAvNvSbCAvv90GrgeVFyWbt86xT6QWyaTH
sAFiHAw5XTuGQKkroSNFPOiMlJJyQxuoZL4qcrzR0Qh/25V66oqasd0V+aYi
pmoTuzAxQUhDQQmZMiXEBDbJ5jtaeEODYh9JAyk2W95PBcMmzbY5WJ8sLncb
4nQ3UHou3s+GR2ROvL/usvnBDjcrZURvtHW50B+RZMdL0pUwp2QMEWY7kJ2R
y35dkkLWrUnRWGY3xAt5b4j+6R0adFEVeZvRB7nwAULEgjbb/lC2SCABBmFq
zHboxzorPm8rSA8Hrlbki3UMDp/05ZJWQOxDmJ/fGT7NRQ1+Rjya/oQSRJ90
Pb1G2lBARmeMC/MDomXRk+DvDEDmZHgxF4p83zAbGOCF0O9BAV6JyDs3ynxk
PzHyPKfDfzxORxN1q9KW1Cc7x5KI3qP/cytSZZZC37st/RdvRGaUyzxJdgIC
GKszEWRsd74rq34GfnoVAeHce5wBOx5Mm8zUshGmptDLeVw1YI80E8m430Fj
J+GeA/976J+iCGQEM9GFwOoFKCYhTbXXibws2pdVRZJ1Hok/DO3lPMavDVoa
ls952anWUPYsm5kC6DkRIki6hqY5AAqIBo+lF2l1tCoarCv0V+P92GPSAYkX
4jj3UDn5B8MIBimB3C2/QPQDFcPsHV2AUdnfVcPZdXhCOs/1T6+xtCvPehh3
u8prbDTwYq0vm/zXFeO1A0nb7bZpiYp+ojcenj6i0THx33akmjMuiS9g6jcf
snkJUuox4SXgWuQ244ZkHin23YZHdjTG70TqdVmsIWAcIgBmQ7Kwkc3kw24f
0R+ilukZHR/6jvFYJ9nj15a5AMSPDCBsTuiP1P6iLzeC+l1KXyzWhDxIpaHd
LaEikc11w0AVdbO7WQtXLW75pG2bhiyOGzmvBDQOckcvLlXCrtpmQ4AXpQ5B
rIVlqp8S2H0LbSaRRedGaCzdg8DyiO+yh8XsZpa9efv6Eu9dXTySvfCoO5el
Gz14WogxBoWEtcCwWfLV8TYBs2N7Cy4xshlY1ke4Gc4JpRthY8Jl2flgBJ4A
o8dS4QeH5MNTjAjh7tD12Nzvvst+CSIsw4HcdeYOcO4iMwFnx6/sGLNe1OfZ
w/WOXnqkb7YTYNP0DFYtCv+nfOHNh0aOViSEhRUX4Z2YVEWbBh/xjAWHFLbr
RNV1YSj2ohPGLA/x2hg4R9OBnShLZ82HZS19rGdbmIgo4/mC+XL28efrbAEL
eYUzrtKQCeOxsMwu1sh0tSQSPrBGEvA/wR8HlYlddKxVlEQ76xdB5sOfIcQh
M/b0Bmt2GeTicimaUYLh0psDye93UUj2MMaPMHpZ0iPoPjsorB6AMDlZhZ/o
EegeXEIGjycnKdiIDlKL7O0WpMC1ZTMR1DdkgdCXD0wgtQ8w6ooElUn+YqBV
E7E5R6MxBiOcku5UENPgYVi4A7s4QrxJx+sGLNBGDnZI5eTRV7mbF1VZqJnF
rJDlqOcMkKOim5FC1rQt1Oa87vYwHj6QlpRgGrQ3LwhJNjUJXVb8iG6KmtFA
lLXJD0AXs4CuWOyYSJlzTUB1wrMC3xTjUcwDYU/RlBNnOpGsf9Msi4oP9Kon
OP6KZw8Oze6k9YMIgQR1hH6Vj5nR4y/spwxHAzujAIYKP4fFCTppNiP/B2Av
ZlJ4zVvsu9pvKk+02tUL1bYw8J6VYHYPQSLjYBQt+KCnDRcdcRxf2I3bLYg0
trRmYvdgJ7DjKp8jLptSzv/7P/+X1AjZRjLOsJRgUQFjZC1XFTjzHlD6w5v6
FdTbMZE9bTBWpA6UwahxAEO01xFgoFCCecOcgRPgMvIGZW9EoyIEL5dlsHT3
gDtXFhodETWabSgYR16vNTfQZPTIOWy/t1eTV0wR4GFpmwEXI7te4gybnQa4
GB6lhEn8gdtg3fPCfyV6nIc0doF5NfLLF3Xh/fYbIUlZE5ixKNlGcUrh6ouQ
33c9bC5vNjM4JpLsO1qDQUjGA4uYrtm1C2+aBPbAg5IaIxRl5xKgFnCLlDVk
Cqvouy1csPkme3d9GR9gYuPw2pDcIs6Gw7XAuidykEq1Vc3iIB2qWOTqfQr+
O/bUiO4aTrXJA0fbBIbJoJoCoYzPj+B5NqlCcsT8J4NXJ3APk2BmC7xZsUEp
qoJqaB7l8Ve0Tb9Cj+l3NUlPgrPEYnNCAR+2aKnVPj8ol8s7iPNrHCJCmtd6
MsjsMrZuyISgD8o2Uiq9pdHUNFu+WMALC2tiD2qJeN+6FYV1zZPQfExOrPXm
npPTJkVsTkiUZ6BPTrrYciJqYq2CmEwh0iIW6sLb8JTBEnWLVQGXok+mwL4X
q/JzohXYvKAYkli18BcBRF8vO/YE8oF2Ea3xzCsyykWOGpIh+cDbxDFUlSwk
lXxIiX795n33aOJXXYTlslm7Ym0RVK3nqHbROTD8Apf0eMkvQuSRwr8BlQTX
DJ7aFjMIZDh48S0QNy1sXhxnfxBFG5bDER/iWiNkiauUVJaODVMSFW0DWifd
KvtD2ZK4c16jExQvGyZINQbHGBHBts1btYr2kOSf4Ko1nyycG1gt0OVMSVRf
MgJl7Ko1SiOql6/eEmiH7KdDMafvxXDPetC14gongjE5CSqoM4D/AWAN0wNb
x5gan2D6vSaN9+DGuLDwzWikoc2r44C1MMei8eola8/q6hqDUp3r7GmAI44Y
xK7KWzYDYIAfWCqa+TJlVrASN2XkTIPeMUYAgjF1ybKMXzXicRo4XgbjsR/m
AsdWfFnBy5ttxMNKmynaHMRZS4eI5PjBazWpUjIhmw3yGLoz2Cw4Vha7a2Ff
LYv57uaGQJlh7h+V7R+/SugFmTLzFq1iYkuH1CaVp+8YKnH/+HhHCpH4zHX/
i8/MCraNsEyA27ek5dJ20PPqwBC9KcwdkfeBMxtHNqmuHh5v4PVQff1riFTW
2Ygsjl8KY90S5+IB2WMAzIFAMMgqHQQI+asqrBISwOFhMSyOSWXqcAKzwJuJ
i0EJgycMHCb4VmmeexUTYEotQFLwuyLoCSBf8Dc1HZblit2qZjwQSKS6suuf
I88kpJirDz0TgNizWxwR5f7gKuKewlIuakCvWmHi6GXEAR7LBohTBWK1ChIv
OsMYH0iNvfHen6uqQnogHXvvyoqgEIves24TpLzVIpiHXhOLxKn2nhxhYHFJ
Ug6+Hw3xHE9u4QMRLMdMPcAuVrgPN/DWi/4b4oHs2f3I6hyCWIdhFID1v5R9
QPkTL7/kX5Sej7x9f+VCNsYVx+Wcux57HMBkl76EAu+Rb7TzXx8mX97mZOEs
7x+I6MtFAWLLMbnUSJlzf1D3zC8krqDGn2dwJPG/6az2+yLo5KwuRIY4/81B
LWh2sUMs8/5O0ycTBeBK/Tz3zlln7y794Q2avem+4g+CBuXfopENYWJV8cAq
jxhY05o5vAoZMvBBizeKuMNSmWIUstNzxBaixIgGPI8EevYj0zTSPyYSSZ3l
7TafnYDw4P6PlB9M74POsT8/sX3YEcOWOM5X3h48KyI4wEst0CbLdDJiHFJg
vWQkas4xX+/SlzcgOW6YY034ZQ4aKZsQ/5t7II4UZZSzB8mSvUhO/YBYqrkB
q6b5RCaUgqi+O84mcApJjDdhZcjmIFYWbRaPS/t97Q1CiD8C9KT4nOOUnKg8
80gte1Xv001TB4X36vYw6hcN4mGNOCVj+rHRZxGIMy/TE8CNymCBVZ6zdbyf
oN26cTdVQ7ohKR55zW51i7Z2EdgBTUfYOYlUBp7KbOJmFfPezAfCEHAY0ABO
zP7YcZuOFNvT5ibkiCU7X2IOSkeAxivYfCJiHNHyExl8m1cl4nW2oekZiGeO
g0J6JNzxkfCva+aBIJjUN54IJhFZvKxsefnZNk1vQXUNvViUwMUj0iIU2uLb
YDVlAROoU4jY9bpp3UOmaWQ8EU13atE9nZ09gmnUm/18tDqgOSyARVswdJrV
KmVFJD+6VF5wANYEqwyiQlRVFwuLMW5G/CuvEBeRvd2Lpybsn4tCLsPvLELf
JUhkm3UNivZO3t3WR2iBNAQE1fJN32NTyg+k3lvovrFPRRcFPa1mREm2CGcv
eQXUcdDRm/eaPIUjm725VkYQxWqE66tiGG0G9GwZGlu4Uu7Mzpz7KS+1dPWE
GzTeQtdTqIN4RjmUNzKrfV03d876SpbAkdmuGIOBLV0bKZVj74JOGszM+NtJ
JGzqoliqpLXYjvJ/kz7hXdGcCcHOHFVesIN8hcMNBO67I/4Ucg7YUfru8vaZ
eHJ4dhMxTDPw7bCmbi4uehcJWhiJjyiSGKMj+nz2ZHaWaVrHXKx/Ikh4n2YZ
qVFOhcNEPUEJWBXEJp9DkZ9hcYVnqnj37FTn/uHs5W+/AXTFqjs5O52V9RRf
KfvfGySmzc+yn8tP6YaRGnL0HRNmmsnn5LBxuhwLJyFcRDDGZYEn9PuR/73p
L8XnrY9RKHfe1SWxHMukUAkhjq+Z+xiFA0011M2LuF7NJgsbhmauyf4Z7eZ4
oN+pWLRRsWKVYGleXpH9+vOFeeDs8Es2DuncCB16UkQOBU0+y36Cn8t5V1oq
EPg9n4sArAwxYh5bNoqhZNaph5o4d5S3GARMAJTPk3pBPPuhbcQJFCcMIYqn
TtbPc7tts91V4Cwa4+AMOxsf77H3lodRGh+Q+EkX44ygXS1OT8+fnJ6enS/n
L8/PHz97yWzGgrVxMonwONuIVC2Du4z0iJOXs/lsOTudndH/n9IxxH8vZ6tZ
uf1eaJotu5Ds6hgZzFbgJOwPW1Hr0+BoPcjqSXV53lKhrcF+0glxueLP0muO
6CxCzbYtNxDknm17QG3Zuh3sPOfz4JQnkRj3cyx2rbhtRpJ5+B3dqY8SWOw5
f8rHp2V8JEHKiY9UqjdRyQEZhp8PxIJG86Z/+42GR3UA8RuGZHJEa+x8Jbmc
z+GPbgsfqrMDyn5qsaQ4Co4V4jRUfBheqe+UHmpkV1y9ln7gAqRXRZUHx9xs
kKQ1pCfdG9Lvi2rlQ7UoR5D4Ryt/rHYVdFgoT0NXiUtcJfa2t2rZiR8nsvAg
A8php3HIhgp5oqKcWeydTwqPtVIfmqhzHk2sUyNibSq1EBgLU8n7GqxfBd+r
YwiBirzq/Hji3cdo6ukew+yQM3vi7yQmVR1CpKMcQQsn0mjW0zgm60YMV11O
UL8mCQsZAcD2Tch8BjGVTGHO+2Q8w6DY+wMMRKc0mocz8VRN69gT0t1BdeLp
vhIGD0/agWOdymqPabTzpkvCIuEvgMoo1MnqLZbu1XYcPIVtYLyonq8qD4gn
1fVT44EEM5+JNFMeQYkGbPHztgHncANXn/+aQ+EtGVLsBB0MvSAxh6QbyZ1h
iUhqQG/wW9qEK7tuV3SvmCCJDCYZUtAgFsEZUsDGrBcRRMWRXaSYcD7Swd92
kS8m8v0Mzbr7sEJWr2ujDWZ17n4zsex8XP+rdvU5QeqYU8YWHZ+zNBt2sS4W
n4QpDCLdNHjBfJODL5w8VbAYF2Nac558oHJeIBMw0o69EViuhAxNPIVEbNkI
PI8CPD9DgIKBdM79hExFlqjsnlU9EHgSsTWwBzTwbqLq7fvXiJXyIFIGIWoe
D/P3om2c8Zg9u7Y5N2IiSdK0evGBWAyCzD/ipYjWZ5FFo2+Pjk7nz/nRmRR4
AoPIC1pJyfBmWB4yXYg2WXAuSPiYQ5OxYbrhxD2ZPbtZ/x1H/Tn9L6epFyYi
ZSjBBfxUyOla5eznbQ2JxDonODTQI8gUYAm9b1Lma7agY66VjDJwbkZeSK+8
ARhmR0y/dIbIaleNJx6KHZHZttpxajYf9zXpjstiwdUBy/IGS8g7dTNqNCKE
NQAo44aEPADzthIkVeck/JBv5nQU1ZuwsQySbl2KUPAhHuGYYKufyn6SwGmZ
6res1IOdtG1e36iKwtSAFXMypAvRnprrq0ynqZp9wUlquxaJxD5THguYJgvA
Fv1yPD3JXxfBwKlZwbxIccA5OMgRkbQkThQy3jKw1QD5XhKgfGZIB+e60iOC
kFDtOVNqAy8qYyrQ/Ui9DUGuLoNku1OzuOx69ZQs1g2LCz1+xxgR0Y6hl8NV
5JIEIpqXRrDViYHzqaeDCU3cPJweJNZgd+Q+oaVNlCCz9WELSnl4Mj15pA/j
V/1CnRVqxXq4xRqNM4oFmGkehuRKB58dj2tch2h2i9Xbt8gYajVFaFgvwhFi
zcIexPY1hQsyI6A1WKm+1APazwhUqVkRlNDj1NGgSRspIi/ghgMFBD0/4QXq
Y5D3x2gxLKE0nU8tRss565stx+D8p96hgNfzFrEtNtm8lRBVVugybM9yuOBK
ybRmBYGHjJgWSxVsJlzxtmdB/loyzsggkmG/gtqt4EsJogi3i7vtyXFV0Dkk
H4jirTQxag/cY6jeoWOK1eKSKD6jPxg54/sbIvrjKeqBOZMA9BklpPjAu31c
s86WGv0U5xkNcm+ZEw8MT/dj23ziM81pYt5+TcXD6NInPsouriav7ZtRV0ls
8Hf3m/RWOPN1kz6gHPzn71I/k3ddsyjZieLrSgaKPRYlJkrimoVXJdEggpHB
UCcRQ0HbcSq0T8DKzSEclHCd3gguiv7ICu76IKRXj9o0v4OdJvBcX13y26LH
EAoeKhbZF+o3ZJwAg233SI8snefrqz9xATt74I8gp2VCPdXKPl+ZFxJL4lpu
dX0o9rE+UkQQMOCsFeKNKH+f3OUxeCi+kDsrxSMH8ZNHM0kvIh2lvAs1sXWv
WtkFJN1j+uuC/uPDj0eLlliglokEUsVfhC3D1bYpuTS5mVj810tmVCHXN5Uq
v8ee0ex4j39sUBfq9w/W8T3sBPpMnOEY+JzlszHP0OHch5B8lTqcjortCcmY
G19f7ohXHfmnUHlPL+keuhB2HkQ+E5i/iYcTjFNV0r3pP8oOnLv81lelqlHc
cISmMR9cycL0okJymWS1dkjZ5x+yGxqr5cAmsWFNLUKyFFdvTZH3qfsEyvtU
bHtV+DY05B2TuXZX12JUfmXbsmjb4k35ZokIT/G4a18Uurt/N/ed9zGF6H7E
ZZJJwciNK8w0vNoWym+QPdeFYyExEKEYz6uTOFp3rkb0ED7xsDuv0wb3ecjk
VV4aAT1wsqeZsVtYv33Kybj6OJm587E8E4ZlL3unKzBmquzBNkFYwH9ZwlXb
bmf/1S+2mTIU0s6yimYiI4MZSuQIMFdZ6mh0savrG4hAQ1x3bDQxhO/+wiEw
1golMhd2VNRcz2nGUg/vI4j0czf8nPlzUbJGoWy6Kz/3sJuG0IpkGa7JtpzT
ZX1dhM0n/s3Ushp+2enHk3tmhCoL35jzzq6jmZzjeOBdh84H2O/cDZmNx2UV
ZZymFIH/fZKKbS8lLzfwY+sB+fgVYMO5ZauHZgl16Fm3zRd+ngHKLcwmeD+O
Bl1bnga+t28lfRFztUURnI5SSyMhBi0J+Rjl47B5jUlyyUP2jv6CIyPxUPTl
B/1FNursxZPZ2feIf0XBNoib0h+FPDt7MkU585yr4duDr4vR8KCRyYANnn1v
meUaLJIg7NkpR9tOH7/kYc5+AAAv+Ql94dcMiabtCO5mrrqBIfKYSTOtpdrr
IX6ZDYLWIVoLpAVvEG1XAHDizKsGCAHptw6RLAqFBE2bvgEOF3D/+OyJrnzi
iXN0QamOhQESiLiIOeQiSCYg/Ecvp2dn4UBgIq7rF6eTZUgS+rHep2fwCC0q
MrdYpWH1s4rP/beeczvdQ5FXxhktLhGWwitHRWKQcyIcs4FwHOWWw8hFGTvQ
l6Uk+vikOPpVY54+6YY1K+XWvCp16QZvk0sEsCT8+eJhHe7HKJGIN/do66zK
yVscEklXpc4XDpZ9Z3+YwjcIValWoD+isIJOMtfq+k4wYTO0NYU1RNDIXGjO
MjRrJQF+wT2K2MZHMDzvPtGmijUeUu9CcmsUsIj3wuq2v/pZUXXilbS8OpCN
h0Fq3YOnowPZ5JUP5KLRCvyDsH3PpC+RZmZYDn2IcqbWBmDVdHquMrOKpVAv
YGi54YpL9NKSrHUVQxpzK32BXLnitImHPq114atdC22cUoE6iM/ti6qC+fck
AflYBQHQY+khR8bJXQ4kQA22ul83lWbsWHrH+KmOspZTXAXhxrvEWMfw0K41
IV/GhyiDrUr/o+mmyuLl4PlAajlsaXAU+MXw9yTHHEfVnXt6jFC2Pv/nGAUw
Zo95jPpAlIWRpRNXGsO+L55MID+7A+Q7TK/7wI0cQ+Kz5A1KlRPnns+yC002
3fWq234+wBn7FlXEKw5maTa3EHvZWe4APpPXnSZd5Z15/3qPCWszxTJdzqeI
OG4fctJlf9uhE6FVGmW+bk5hp1nuDBhvypt1ordKAqbKGdPbK44pqIXKxPL8
6SvpgcJJXX/bIQQD6w7BAalf1JxCPyO/Azap2VzdJ1bOrpPS+y5Z7JFdzDlF
HMVmXERsa06M/pNVCav6F+pTQ/qp5Qe6MXB8xwcOpsZCT0+td93T44ItfYS0
hLIPOq3zilxySqKlhEgWFuUzFj1EQyhCSwznxUHDDlddaBJaENDM+ysBZ83/
7/ANR+2lfjri6aryGx0qKUvtKudWcHq2FfbmWbznhouHzRb9Lf/9dJL98fHV
v5+KRzEQOaefdk5hbfa1hk7tTHkEoCDNxzWRiH1TmMvTWyzf4iSeRCiw5K5v
GCjkZ0oC8d0+kf/pBJqhfJ9m+N+dAqmZSZapjpZ3ajmxBqbNLrPQ7JJ4HLe7
zL58CQ0ykQyLGjBVvDhRcV8SpBoZLJU34QPLEdLqbfrk/f9+8+GXi3fvGewP
9u1gYRjXFsdQ+aQSHPrVrmWXgJpaXukM30uta+oBHNKflgx3rFn1ueeVhO9u
1NcYEgGV3TIqzZv3k7gpEsYgHdEcM/l0NLNKjnlITPsTzTSSFZbixu8tlOaX
4rZ5Z/VyggLPqiwwyjgczTCEbIq2oewDf/DjWQ7keIpiU6dLSSKZw5dHY5kh
4pjsYHyGo230vu+7AxlD/SLB+3jNWOptuo9/+kZ+BoQbBeJo85CeE22fXyrv
3nJ8z0aG5kSBdyH1J2CfOarxz95CmaPBASeO696iA68vTX8NW29cneBJHCOW
jZhlf4wS3uQLye1P1V4cWWtFwtIdTGqfQ8256/wjt5m5UpIcFaJ2tfWRG+vg
ojozY8kxlkru1lovp20z52HzRdt0tkqrA46VHtb2IBZH2gmE3+hooz5YX1pI
oCQ0P+GFyotiorJa4X/xEq4l3Qhbgd46CStznNFlzgA8/vqyPU2grHmr/VBE
d2ZkcvxcmgVIg4uoELotQj1mL5IfhiaQppmT/OAKD5B4GCV3m/GIpOIONae3
hSS8qDdAlZMcaSja48KUoVBI3hgBOmX3wAd0WusWK80+0hNk2TTWmvJ+9YyX
5Fpdge1MKNsI/gsRo9YMIeZuKs5YvT7qqgB+xg1u6hh9OhecQSwqB5OGUr1R
QXYPo+H6UKW3sRWHpEBLRZAUF+NR3iEJak5d4RhuzJzjEcNoEcO7V6IROUcI
Ye0zOobBfaPGWhCzC46aak5jCSvrGi3f8zYo8AFh4vtj/u5124jIA7JwLpFr
4E+9X7zD4sMHx7u4ZE9DgF0hHuckaW8ZNTZiWLUmD1ypVwcevR4f42OvTczO
GKiYS7khl8pGuRRxf19hYsk4Y00RPMr8ay55jfXO4nMf3u0gMGibJNea+1xs
Sp6Vi9y9Lmdttk/6pI2GqcN3nmNoXIjHxCPDQAzWIi3V6saec+eF0OtMGNm3
hFGdMw2rFFPZW51xz4Z/KDDrLSbo1hw/921PLMGHZIJFD0JmwT/G4ySP2ESu
ojNtw1R/48RmZAxyj6Upnt+6b4QrT5GUQEAsro0zdtx9DLeURm7Sxw0d7Bmf
w4LIhb88I9KBw7lOWpB6DwhqMEIb6+MO9MHzzfk5CQRWr4JBVmUFXw8SA8t6
IY3ckpftFHCTpIUBuahKZV3IZz/KLUoLmtHAsFk0lbAW3liZNkg2t/RWow7t
6/HUVe57hwydQmmTlzJJuBQDkOsu1A9593DBCW1F1dwQ8tbEOZiKL6gKBcG6
P9HxItPjzvVfy2tc87TBb7aIxrewTwJb98hfOhsb3xoJXGbXShBTsrRVDqU+
OwZDvkjbzA1KC33XOWu5xPG/dX5bNi0aAPimKrZszHF1cY+6pwQZeGoUxxX9
4GH3yNKKRrtDwVnlA6HScm+z2dVWLBZQbrrnyCguqNzDJnToqWCO1ahpiC/C
vLx9o3nOn4piG7poxLO4OBvSO2OTeHHEaqIKayQna1MtzKDGHWdCF6HCom+Q
/YuukcIAOW98X2ckTHCYcrbkeICINag/UfEjcpvWIoJzwR5qwovU53Ep1YVW
uEQ1P6ymHGmQY7sUGtxZiwkwSpdWlqgllka/Ia9KVSRGRuY4VtRnWwJZw/ab
irgRnjeSd8qSFxfGkOT1eZL6mruKk2gu7eR8PbXvEWHwaphwkwDptDbFGvWk
nW2yXzkcHKb88uXt1a+/XL7lfpeiEQQws1EwudPQsD3X/Y4Irucb7UK+0FrG
uPjz3tmzr+LI55Qh09H0fod7CspF2Ycu7JlWGWseU2S5s8X+Ku7utOdgZbjQ
YeCVTE4mxzhX6PwXuq5i9FKqxJknJcu9unwlh8W/rlmZxAsOvuAAmIVjcWHN
KsIiJcYvZf1d461cfRwvTDPFVU7wOcEAwZej9iv3cuq5bbvlT4/6zKTBYQDF
+ZFyqZ1jFwcHS6u83Eh8NTRr6qKeg7m8Uiy9+1YcwWaFS+6Ms3R9a5mpqhZW
4Q0w36Utr6MAttikWozEqkDe6e0mkHTILilbAiQmG5YGGzvpE7tAIEhQNpe0
Kx9n6Vi1Vb/Wfgw5XC3Oj+GpL0oZvfc2Ij6Z8Yalex+lkUlTyRXZ6aY9IZhR
IHK3I765LLZVc7A21n6Ec2L0zkhn0OQltCG2PgNDymV+hDMsRa/c3klA9TWE
7o4aQiL6XZvdNHkVJ3Y36mw4qK+ptGZBYclmBlgGs4vuQwqXCAjbB+iqItCi
Ofe5Rs1nJxqelVbG4f+k37hDPZF1iubcqbhL5NfZ63fKXrWzW9lJbUhf1F3U
sOQevhdpd4hCbXfttpEQAvaXLztCHYReAjiWkMmKHTjZ3hqLBV58lLwpfCsq
wSilxmKMa5ktZa1SOXVhLRWy+Lf1DZb7qJbW16UTQ46k9dBT6vW2ezJu89rX
Od2fsslabIiBo+E1Olpjk45HR37nBT3/TWJ9DKSgImq3bJBZg4vESZY6jaJE
25wTeSb2tWZHhpoMpEjDv7z1vc38JRnqsURs4iIeUg9AFGiyRkN0lEkKofss
j63vc/OL88cvMu30dPbDUaenTMhLqD1K+/SedcaGe/YyqSeM2o/oJ8qfok55
QeuSRiouzmW6Kwv0rnTnCdtJRuw3jZCCemkko+9jE/bMfK8wItXhpd9GxCj7
HLwxSfVCaHfG2aTu3mzSqFvL2KLYjSsY9Y0dpVhNFkucTP3bEQB9wwENVLWO
l2XEfuPBKjVyHdQDnlubSslhvn73HzBmPDVC4xCNJ+9SL3iQ8bG6pWxpOIU0
r1RuYVyRiQ+XLBLxJdGUpPmQ8xbMctea0XXxWNfsE8u6vtgeTR7N+/H1JZeG
5/hX1BbdpTNHNgOulNLkPO6+wy1F4qrQEf+hVp/78VyUpNmFFjqTaFNsIktk
Yp+fDC2JMbmmvLBGsSWqbJBGILkOkowvFYZrEp+PmN8WVb410eS53B3csXPu
Lr5px8oOp5Rj+87LeTdK2fqV7gVOlIs04PgogkgtM1W+0tC7+SuLvK1KqWL+
8kXS7X/jwKzdf8GlbeHyC1+QP96DA+xTs1+TaXh45vZs9Ij/4XV8A5B2BoDz
LVJofS9P+DFVAf7zOrSB8K+aS8QXGEbskKzsxOXGThkh2auLCV8pdPuMDUb8
S9pV+YHNJA/F2x/X2idMHzl/gZL/JnR9i18c9295phh5ucIs34d6ksEER8m0
o32YzJEp0IwB4EYBsDp6bWSs3RC88OE70dKucZx/bFsBf8S7N3AgiSboItX7
vgtR4TKvhSFcXQyScIdjSiameCacxtUXfHzxjibsjDViSy5LSZUIi38EVwY0
PR/R8N2rgxAu40QqD1tnxeBl3GDPdINQBGU182wJWPiIe3D49C3Cg09SSO9v
PPY7SdxY9yE3fx0nCD8UMn/EdC7Prwv0Cc5+JsniHg5PwaM4qpv0oAldfUJ0
NynNp40KtfB6J4E7ntNQNUmSy5P9mAQ9SLoPeO3sDxEO4zT84z46d4KYllqt
8gW6tgDjInbnTdND5DJjm3Amk+BIOcb3cg3ZCDJtYc7i53JthWUzRrgcg3m0
Eym77srFJxC7weXGnWDDkutkOs+Uo1AVblWOdNOzM+bQ/2F9U3+VFn3avsX3
VR/rIs79InzDVe3tZ04H/6VGX5DtuIA+5YuA7upNenSh2DAvgj3J/tYTDebN
D7E3Cd3uT/pBnVfsfx+0SCaqgW/Nyq1/eu0bner1p763HBfr6D0nub+kV/LE
b5BoLhnlPPS55bN7cO1SrrinUNqZg5vzqiG71EMw2ilIcpm1Ca9loR+SC+uS
onOvgDLTs0tKvMQNL467JGm2L1/eFFeXLNKfftNs0R1Kdk+vzfyVeTFd5I/U
eVPsRCj8ajel2YCUxRUzoGfzq1gjrmAUjXZAo9n0TUh9LkTiboteQeVsbAPY
d+68d1NjgL8zUvyTJ0WOFKfUyZ/GHaJ9zwySr30uN17lnGfokyui1sQhLolr
VI6cb5LPwWGWHA6SP6XzDnI9Y+duF8s9vo7PlOKgwAtOfK6KQk7QJhBKREtX
E9d+qrvQ+QHyI4hZlB7jzOdELOOOoHGC3rCexiCLjrdMPqzAtAYF6puNCnnY
EZs+s/sqVB3wY/h+TQP5houUo/KAkeTRWaRYJxdqWR5eUHG3LS46Lh7z+V2w
XbrNS82WxMGWtFMulOANcbIhvl6CvtCCpnUempRyjp9cR/HiJZsXHMz45dfr
j9n7Dx/Z9iERPg0binHOnW+8xG8auB5aeknVZEmXHGRGJUGRgRc9btJ6lELF
xnrnbZ80X/RVygRM7xrU55jFJcHCoz2RcVVPS9pMh+bTGPUv1/85TCjXCkp2
h+71VCBrMUQxaLt5odaxym8ub+pj3WO/uQgPRgD4ECeLw4gQhjVzrBSmDUxG
VZl3q682n7Hq8XiNxyXaliVrRCG7ZKtL8CNUobhk+zX0v2DcMLZwXKPWCukh
zK0nUcj5u7tpkdHgQjrmKqf095LyekLLtngHMHhxK11rQvskf145zUE75JFU
sJtGZURdn3KXYIPQuJIkIZcfRgU4RE9JmZJduUrbf3XVcZP24b5ylfYk5pQc
D2ZvDFuJ776ltcvITqbdtOR6sTy0yfVnMGpKbali1ptT4tjgSIQbztDXyKYi
W04hMrVWkjT8bjWc2dl8Nwg+5aTFWfeZqAPonP7FXRzj/qApj5jLlvMN8rXo
s76/ZGhpenHDPvKjfSGATrrosHXShMqO2WB7XNieqPJY1UnriL9UL8u36XLZ
l+9YoYruTvnaFw/f4otHVgnJwSTJjATj+4bIe8hIiyxzyOr0KlMpEUoTN3jq
kBzorI4o3I1nW+Zzeo5pLpnGbOfkokfuJ+V4srSFSChpZW1hfhg43sz+4hEt
1yFY8IPbXjVTEirjFIaipvFYtlRUFqAmemzVW5ytnTjpyZm2tGXDM7bdjaSO
Rzq2X0Pe6P3vhcBB6ksRlcjjL7p/L6nV/QbcIJQ8JTaz+MSFvaRTe0wV0YK+
H3NsGIbm4u7PrCJYv7gUl0xE78HHYJUvKV6RXoMf3B3LTuztb1m9d7UGehm7
bTiQsFRbaEV9FLdAKVu4bRnVdD50QoaWxk5CdCUiT93pkD3mVzu+AKlwGIRN
yrQ/87A6BPCy3p/GUiLlfeBdEuFEA0hP02Rw1e0lH4nZiORH2dFLgjFy7OWm
ULmtQZvP2WuiMIQHvkXxUZO24BE3+2piEnhEiTrOY5/ELcisq2TC/LVRiHTV
TZfD9a+i80B50ERA4T2so6Xy4jhUE0Wh3DAKFaslzZGgDKgTNQbSLLpgnYNU
ccTFBS9kbbGon5EC4HP5zLuoqQdilGJyH4rlCsV9UXwabmN8l4wlw0W3XQ7J
KEvpVO8vjvLY3Srv1pIaNcysT67oiG6NPY6TyZ0m2XYtF92ybJNrntwgNq9y
h8MMHZcm9wn12XL55GkLHJPrXUwO84P0ejZIdEu5XRpfr6f7qK/n3PJAdIj7
iOZd8lU5yC3wGkZ0yBXIYFHmLhY60lAdC835NgC0Pl58iqoa7ZBw9CuNHWpf
k6Wt8f2Hn66uPlw5LPTq9Yc3P2mCkH8pFPFyfyoVJ2sfZz+6Cg5RV1+TNvPX
AcZvFUGjiI0c7bd8HSKXw3Be/KaWPTgWFJF/RkLU5R03PilShB1E+6KB1qSG
m1OoXHiHKSzwjMiak+0fbP1koNkqAXjLxUUsIqHRkTz5ttg0vngx4qFlLFJJ
9NJ31h2GPdZFfdPDm+G4aYpyAstut1hJSIXVEYazsERY55X1TFCGgrOItGiy
HNAY11T9G85x6bPnj1/2a40S+4cv+GFov+Ah0lMCIaq04XZ1pG/yKNH+RC/G
HWPGFNuYcmTNblPesPPDkqyLvSoP32W/en+/1Cuzo567XP15XdIUF3CT/wGe
Cij3w+sufdZdmgImjfhHGozOi1DQMixhmB/cMr5I1rxvvnIhVe01DGmFu1Gx
fehq8R3uGpBPOGT8o09Zfze4Uijcb6oXY1fcxSVkHuzRJrEvbhoYjueD2MBR
FQH8qlNEgdJ+qEoeg4+l1jaLsuhhjvmChMFQzsq61WaLM/UTVrsLF+dGmxAJ
Ke1t5tEVAaChkyR7+6uFF7EnjGlJb1IaXCYYh659a2dfUiZ9sXO5SVZ7cpeb
YhbS8dTK4yuZjwsUzEAWPsHqatc3jVdsxcsQdYC+zZH/kP9VbtMhWAe7EzVX
Fo2KiywihJr7/+hF2TgXvXqU0+DjZ0ysv3AzaT5Yr5M7p8nC3tz0lpKY3IEL
nKDR8dKjAv0tp+sir0q7EVI5XxSf0L7VeuHiR2YjebmcuDy7gfJKcOaV3GSh
V09r9osHUKlvKb4kzgRNi1yOQovOJ0Zy6j6kweIwWKhz9hyKA/eml5z13lqg
qMbgb1T+yhUZeatmLHIFcF0fCFi5zJENP2hnpLk+dNZCiu7WwKslGsVlwyrO
7DeloSRt/vjmjqpY8VlgcuNQSFs2uy6k78hVS0l7MB/NpfX7u+X7NhclzjPj
ZrHYtamwJLoblAylzJYv+bIYLDNzJBXCH9FZ2qtsfrIM5g9kF9+WPd9xjoBN
XjlgpufEVbvDt9gQVd6KX6TW49E1TAjXemHLESV8DDXajOmKzPJMbnUJdodd
90JWNEnw9HglATDryqqOEWfP5dU8W+34OCHg5MsLOD9toc6MC8nJJiRUh64M
CZXEoXZ6NVjPPgakfIyAFnoa8roY0diZA0Qf2+reVel7/UfOQdZRFGYkf8cX
sH6Xvbt4fzG4p554Bp7+Npr9fEeZCA+TlFXKzavaQp/bXNthsfOtZTcE9iWC
ne+5w2BnTWcP2vPdp2CavSu3yHOp2GErInaB9MD3jbRmsusxfLVxJ/anmqX+
ggJTceaFb0sVttxqpi/kY7ElXsOEXqTHUzlkGDUWFc3KDa+oZYOfaW0bfz8v
ojZD585dyOH19/l80zYkkY1cZWB0sZNPHtISnNSLI+it48ZENPGDoyzY2b9V
/SsZ9d9u+lezBz7tN7TER3oXphd1oc9bJCQwawMeeZskXffedSVN2i0gGXXZ
XiZ3XH1zAsG/nFjh9PpnU2sUSvonU6sL1Jr9k6n1q978fynBet/jv4Ri71rb
P0a0muQkFtSF5lVe6aXk2RvdCcMaXMb3kW+d0i4ngVyLSJ5eajVJmCRQrjri
ePjj2zOVDuQivnUu4YEHo5CPAUzoZs9iIDrSXaOLhhNKlkzKcE283BEBCzS+
mdjXusly97gTc7nU6gkYHhy6WJVFteySD4d35aXwWj5ftPqnT2ifptMpe47c
/wcmCxT12aMAAA==

-->

</rfc>

