<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.33 (Ruby 2.6.10) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-horley-v6ops-lab-03" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="Expanding the IPv6 Lab Use Space">Expanding the IPv6 Lab Use Space</title>

    <author initials="N." surname="Buraglio" fullname="Nick Buraglio">
      <organization>Energy Sciences Network</organization>
      <address>
        <email>buraglio@forwardingplane.net</email>
      </address>
    </author>
    <author initials="C." surname="Cummings" fullname="Chris Cummings">
      <organization>Energy Sciences Network</organization>
      <address>
        <email>chriscummings@es.net</email>
      </address>
    </author>
    <author initials="K." surname="Myers" fullname="Kevin Myers">
      <organization>IP ArchiTechs</organization>
      <address>
        <email>kevin.myers@iparchitechs.com</email>
      </address>
    </author>
    <author initials="R." surname="White" fullname="Russ White">
      <organization>Akamai Technologies</organization>
      <address>
        <email>russ@riw.us</email>
      </address>
    </author>
    <author initials="E." surname="Horley" fullname="Ed Horley">
      <organization>Hexabuild</organization>
      <address>
        <email>ed@hexabuild.io</email>
      </address>
    </author>

    <date year="2023" month="July" day="24"/>

    <area>Int</area>
    <workgroup>V6OPS</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<?line 57?>

<t>To reduce the likelihood of addressing conflicts and confusion between lab deployments and non-lab (i.e., production) deployments, an IPv6 unicast address prefix is reserved for use in lab, proof-of-concept, and validation networks as well as for any similar use case. This document describes the use of the IPv6 address prefix 0200::/7 as a prefix reserved for this purpose (repurposing the deprecated OSI NSAP-mapped prefix).</t>



    </abstract>



  </front>

  <middle>


<?line 61?>

<section anchor="introduction"><name>Introduction</name>

<t>The address architecture for IPv6 <xref target="RFC4291"/> does not explicitly define any prefixes allocated exclusively for lab use, nor is such address space allocated in <xref target="RFC6890"/> or in <xref target="RFC8200"/>. While lab deployments could potentially use IPv6 address prefixes typically assigned and configured in non-lab network, the use of such addressing in lab environments may create addressing conflicts and unnecessary operational confusion. For instance, designing labs utilizing ULA fc00::/7 <xref target="RFC4193"/> is problematic due to the random global ID requirement preventing hierarchical network prefix design possibilities. Further, default address selection behavior <xref target="RFC6724"/> by end nodes may result in a de-preference of such addresses and prevent lab deployments from accurately modeling their desired non-lab equivalents, especially in the testing of devices that are incapable of adjusting the global source selection table.
To resolve these problems involved in building large-scale lab networks, and pre-staging, or automating large-scale networks for deployment, this document allocates the IPv6 address prefix 0200::/7 for these purposes.
The goal is to allow organization to share working lab configuration files (with little or no need of modification) to be deployed in a third party lab environment, public and private externally managed services, virtualization or hosting environments as well as in other networks such as Service Providers, Enterprise, Government, IoT, and Energy, all with the knowledge that the lab GUA address space will perform the same as any GUA but with the added knowledge that filtering will be used to protect accidental leaks to the Internet. 
The following criteria is for selecting the lab prefix:</t>

<t><list style="symbols">
  <t>Address space should reside outside of IANA allocated GUA block of 2000::/3</t>
  <t>The precedence for the lab prefix should not be lower than the GUA prefix as defined in <xref target="RFC6724"/> (unlike ULA).</t>
  <t>Reduce the operational impacts to IANA and the RIR's in selecting lab prefix space.</t>
</list></t>

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

<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" 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.</t>

<?line -18?>

</section>
<section anchor="assignment-of-address-space-for-use-in-large-scale-lab-and-prototyping-environments"><name>Assignment of address space for use in large-scale lab and prototyping environments</name>

<t>The prefix reserved for large scale lab and testing purposes is 0200::/7.</t>

<section anchor="operational-implications"><name>Operational Implications</name>

<t>This space <bcp14>SHOULD NOT</bcp14> be employed for addressing use cases which are already defined in other RFCs, such as addresses set apart for documentation, testing, etc.
Enterprise and large-scale networks have some specific criteria around building and validating prior to deployment. The issues with ULA for infrastructure modeling, lab creation, configuration and behavior testing at the host level are notably impactful in large enterprises as well as continental and global scale networks. This is primarily, but not exclusively, due to the increased focus on large-scale hosts, servers, and application testing. Additionally, it is likely that both GUA and ULA may co-exist or are planned to co-exist, and reconfiguring lab hosts, network elements, operational technology systems, and IoT hardware isn't practical or desirable due to inconsistent results for host preference due to <xref target="RFC6724"/> behavior.
Most large-scale enterprises strive to build lab, dev, and QA environments that reflect production as accurately as possible. This is a fairly straightforward way to avoid disparity between production and non-production. Enterprise environments are an area that need increased IPv6 adoption. In an effort to enable a more approachable mechanism to model a global scale network,  and to avoid the pitfalls of ULA de-preferenced host behavior or mis-use (i.e. address space squatting) on other IPv6 space, a specific IPv6 lab prefix is being assigned.</t>

<section anchor="resource-utilization"><name>Resource utilization</name>

<t>The prefix in question, (0200::/7) has previously been used for the OSI NSAP-mapped prefix set in <xref target="RFC4048"/> and <xref target="RFC4548"/>, and deprecated, this address prefix is already limited in its usability and has not been officially re-purposed. The address prefix was returned to IANA and is available to be marked for other purposes.
This assignment implies that IPv6 network operators <bcp14>SHOULD</bcp14> add this address prefix to the list of non-routable IPv6 address space, and if packet filters are deployed, then this address prefix <bcp14>SHOULD</bcp14> be added to packet filters. This is not a local-use address prefix so these filters may be used in both local and public contexts.</t>

<t>As noted <eref target="https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml">here</eref> by the IANA Internet Protocol Version 6 Address Space allocation reference, 0200::/7 was deprecated as of December 2004 by <xref target="RFC4048"/>. This space is outside of the 2000::/3 address block, making it significantly easier to filter and providing straightforward visual and programmatic identification. Because the resource has been previously allocated, no new resources are required. Additionally, as noted by the IANA allocation list, approximately 85% of the IPv6 address space is reserved for future
definition and use, and is not assigned by IANA at this time, leaving ample room for growth over the coming decades.</t>

</section>
</section>
</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>

<t>The authors would like to acknowledge the valuable input and contributions of the v6ops WG. The authors further acknowledge the work of Bob Hinden and Stephen Deering, in authoring the protocol standard and the addressing architecture for IPv6. The authors would also like to recognize the valuable input, suggestions, and insight by Tom Coffeen, Scott Hogg, and Jay Stewart.</t>

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

<t>The addresses assigned for lab and staging use <bcp14>SHOULD</bcp14> be filtered as noted above.
Setting aside address space for lab and staging use, and adding this address space to common filters to prevent destinations in this space from being routed in production networks (including the global Internet) improves security by preventing the leakage of prefixes used for testing into production environments. As such, setting aside this space improves the overall security posture of the Internet.</t>

</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<t>IANA to allocate and record the reservation of the IPv6 global unicast address prefix 0200::/7 as a lab-only prefix in the IPv6 address registry. No end party is to be assigned this address.</t>

</section>
<section anchor="appendix-a"><name>Appendix A.</name>

</section>


  </middle>

  <back>


    <references title='Normative References'>



<reference anchor='RFC2119'>
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname='S. Bradner' initials='S.' surname='Bradner'/>
    <date month='March' year='1997'/>
    <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='RFC8200'>
  <front>
    <title>Internet Protocol, Version 6 (IPv6) Specification</title>
    <author fullname='S. Deering' initials='S.' surname='Deering'/>
    <author fullname='R. Hinden' initials='R.' surname='Hinden'/>
    <date month='July' year='2017'/>
    <abstract>
      <t>This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
    </abstract>
  </front>
  <seriesInfo name='STD' value='86'/>
  <seriesInfo name='RFC' value='8200'/>
  <seriesInfo name='DOI' value='10.17487/RFC8200'/>
</reference>

<reference anchor='RFC8174'>
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname='B. Leiba' initials='B.' surname='Leiba'/>
    <date month='May' year='2017'/>
    <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>




    </references>

    <references title='Informative References'>



<reference anchor='RFC6724'>
  <front>
    <title>Default Address Selection for Internet Protocol Version 6 (IPv6)</title>
    <author fullname='D. Thaler' initials='D.' role='editor' surname='Thaler'/>
    <author fullname='R. Draves' initials='R.' surname='Draves'/>
    <author fullname='A. Matsumoto' initials='A.' surname='Matsumoto'/>
    <author fullname='T. Chown' initials='T.' surname='Chown'/>
    <date month='September' year='2012'/>
    <abstract>
      <t>This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa.</t>
      <t>Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='6724'/>
  <seriesInfo name='DOI' value='10.17487/RFC6724'/>
</reference>

<reference anchor='RFC4048'>
  <front>
    <title>RFC 1888 Is Obsolete</title>
    <author fullname='B. Carpenter' initials='B.' surname='Carpenter'/>
    <date month='April' year='2005'/>
    <abstract>
      <t>This document recommends that RFC 1888, on Open Systems Interconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic, as most of it has no further value, apart from one section, which is faulty. This memo provides information for the Internet community.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='4048'/>
  <seriesInfo name='DOI' value='10.17487/RFC4048'/>
</reference>

<reference anchor='RFC4193'>
  <front>
    <title>Unique Local IPv6 Unicast Addresses</title>
    <author fullname='R. Hinden' initials='R.' surname='Hinden'/>
    <author fullname='B. Haberman' initials='B.' surname='Haberman'/>
    <date month='October' year='2005'/>
    <abstract>
      <t>This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='4193'/>
  <seriesInfo name='DOI' value='10.17487/RFC4193'/>
</reference>

<reference anchor='RFC4291'>
  <front>
    <title>IP Version 6 Addressing Architecture</title>
    <author fullname='R. Hinden' initials='R.' surname='Hinden'/>
    <author fullname='S. Deering' initials='S.' surname='Deering'/>
    <date month='February' year='2006'/>
    <abstract>
      <t>This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t>
      <t>This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='4291'/>
  <seriesInfo name='DOI' value='10.17487/RFC4291'/>
</reference>

<reference anchor='RFC4548'>
  <front>
    <title>Internet Code Point (ICP) Assignments for NSAP Addresses</title>
    <author fullname='E. Gray' initials='E.' surname='Gray'/>
    <author fullname='J. Rutemiller' initials='J.' surname='Rutemiller'/>
    <author fullname='G. Swallow' initials='G.' surname='Swallow'/>
    <date month='May' year='2006'/>
    <abstract>
      <t>This document is intended to accomplish two highly inter-related tasks: to establish an "initial" Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service Access Point (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values. In the first task, this document is a partial replacement for RFC 1888 -- particularly for section 6 of RFC 1888. In the second task, this document incorporates wording and specifications from ITU-T Recommendation X.213 and further recommends that IANA use the "IETF consensus" assignment policy in making future ICP assignments. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='4548'/>
  <seriesInfo name='DOI' value='10.17487/RFC4548'/>
</reference>

<reference anchor='RFC6890'>
  <front>
    <title>Special-Purpose IP Address Registries</title>
    <author fullname='M. Cotton' initials='M.' surname='Cotton'/>
    <author fullname='L. Vegoda' initials='L.' surname='Vegoda'/>
    <author fullname='R. Bonica' initials='R.' role='editor' surname='Bonica'/>
    <author fullname='B. Haberman' initials='B.' surname='Haberman'/>
    <date month='April' year='2013'/>
    <abstract>
      <t>This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='153'/>
  <seriesInfo name='RFC' value='6890'/>
  <seriesInfo name='DOI' value='10.17487/RFC6890'/>
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIACe0vmQAA5VZ/27bRhL+n0+xl+LQpJCYOEnTxCjaKI7T+JrYqe20KIr+
sSJX0p4prrpLSlaLvMs9yz3ZfTOzS1KygrsLApiklrOz8+Obb4bj8ThrbFOZ
Y3V6u9J1aeu5ahZGnX1YP1Pv9FR9DEZdrXRhMj2derP+HxaWrqj1EiJLr2fN
eOF8Zbbj9TO3CuNKT8ePnmQQ8yQL7XRpQ7CubrYrLD87vX6TFbo5VqEpM7vy
x6rxbWgeP3r04tHjTHujsahuss38WP387OLDVXaz4SfG16YZv6btsizTbYM9
jzPF/8bxr1K2DsfqPFevWq/nlXXdD6LtuS1u7v7mPDY7rY2fb9VVYU1dmKDO
TbNx/qZbZJbaVsdqGl9+OXN+oz3ZaFXp2uTQ7rA2J7k6aZdLLAx72pwsvA13
f/x/1ClIRBElvDTh82r8mKv3W+P3dfjRrG299wsrcPZBTXyxsNemWIT9bW/o
rXxJb720K03rGlqXF265vz3vfpmrX2hNtrP5ZRvC7nPeenKjsY2inWtXubk1
nQJxf4RMeOntJm/D4dOe5uotx+TecU/L/ee841tzq6etrcr9g5ry5SL9lnch
k2W180vd2LWhELx8c/L46OhFvHyOWD7mRbae7S179s3jp/Hy6aOnz9Pl0Ysn
By4fvzhKl193a589f/EIlxnJH4/HSk9D43WBnLh2ypuyLQznbGVvTGUXzpXK
zZQuS2+QhkjowtWzyhZNUMhwvmspPdUUAWZMrZC9qjSrym2Xpo6raldTVqv7
Njf5SK28wz4N3nowXDrCWsGKtraFDk3aFi+Ymb1VCHbcGr82pYJlVAs4sbwj
y3SzMf5Do8KsmhFvvNaVLTXtpGpJACgU1MZUFf0lIbreqmCXttIiEBubXF0v
sBlAqiXNoGQovJ0ijcg0tAo26ZBtT8tH5L/jh9/QBjo93NG7IeGr1q8cJN33
Ri4TWsIi3gDisPji6kydX00+jJd6tcK9CHuQi+uWtiwrk2VfELx1JoUjISTp
lFKrab3hvVnjv/6K8fHpEw6JY9WuUeZ2Bb8C6LdQYWZrw6aRLbFEV5UTrcxt
UcHna4OVJJI8C5uMIMWTj0JbLDoFAsH94GX4i3enOMTu9EZ8QnH/6RPneWXu
hFHh2goGcA3uLMRt2Q0H7E9O2q4QP7RGI2bnNbZNsWrnMARrkWIyxsVo6Nrh
CcgtEmTK1GvrXS0KLfVWFSg3jfl8drR1bQC+QfutcivjORJ11WdNrt6wBUKj
EbUjCjToS4KwX1BtYyv7J91+fDdRsyIGlrgPmQ4DUiR5N60M4UShyhbp6/gs
Hhq4pZpXbootz14jBv9orTcc0bDVmiwJ0QsLxShMYLJkjRS2og/MjtNNoUsD
KIXOrccGntSd6bbq8zSYynAQAg0Wem1xNnE2YAu6TrcwIaEBxLL98BK9DvNq
yBrTpsZTvdp3ghF7Rq3vBMfM46C6KFBbG4rKJXaoYj5Zz6cgryeXkx2ADII5
JqxMIREFPchwjQlsGOhQok4VnPYap/QEN4VeaZhbUPGfrSyl16Khg2s9DtCb
oqHlucBrcNWa8RVxFt0WIHNNjzkquVCI//3cjAN8IrmQ4GuUDDFGzMyxckQ5
BDrjKAD2Xuwwj9K0N9hIEKiDt5Sd4b9jmsAXqy/4FXLGm7nD0SETsUfSNlQW
dW3/FOzF07Ag85E2Mbq7dJQlMyR9UPc3tlmg9jQNWdjDYziD4RIEn9oZYlTK
BiROTTySWE7ToTxMo32z3U9X1Id2iryMxoP3kbbmlkghe36paz2HHAJpcvhI
4dWmRfWIJ4AuCye+3kGBQTGBDo7Sore6RHBQVyJVffBubUtwnhHoGfaGIgSb
P7g19BA1z9y1eFj424isqdgo5Jqb2m0qU86NBCTXaRz0h4+TPbzdWLwGwCH+
wMsC2AsXJEA6LZ+2TS8W7+Lse8LhEKhIB2ZhUwbHkgyPwKWKQgmH09QNPF8Z
fRMS8CSynSsOjZmjgGBw9JZEagoUCqSYIzF/6CQSbsdZ9pWa7BwoLBj/8QRb
Ktc28nemzibnk0F54bPh5oZ+Q9BS1D6BNFKEyqopGV5iGA/2TDtQJcRZobGh
JVoggcTGdTCilMdBLRN4u9/WxJoIqx/g7F+py55ODdHfLnGkhs0l2sPdtOby
7PJLDqPeLkP9yA45Vftr40HXidhupdjfmC1lVhnUvfcfr67vjeSvOr/g68vT
nz6eXZ6+puurt5N377qLLK64envx8d3r/qp/8+Ti/fvT89fyMp6qnUfZvfeT
X+9JwN67+HB9dnE+eXdPcHQHYLyJGWsl7g35SocsESu25auTD//+19FT2PRv
kRHDqHLz/OgbsvBmYWrZzdXIWrmF6bYZ8SPNXIISBhhtEZYEloEcu6kVEpOs
99VvZJnfj9W302J19PS7+IAOvPMw2WznIdvs7pM7L4sRDzw6sE1nzZ3ne5be
1Xfy6859svvg4bffV8TfxkfPv/8uo5CZMA9iX/RsPqbWDpPeLTqClq5xxKj2
oU9i7xC/ZTFqV0wqqqlsEAakqkJR/YW6GKTI2ZK4KN8F2scmZXs7UjSZZcR/
JvI9C0s8HuAMWrPg+NMVyFq5HSavwDXCC4GSsLonHMEgcKmaSPWMscw6jdJx
QB+aIs96NOezHizB4EOwiQMMM+FAKevxUHvX4r2u+A9bF7KZJyaFBOpLeM6I
ZkNo6ZAE5MwQmUzOPHon3wrnT1RoJDWXCCsfYLf60oYdZUuuihWG6h4AHnSf
7QiABKHZRhSbtVUXOAiPZIadwoitIE8KBW2UiNKOfWLLxXTWLrW3FYofVSlp
TbqOYzSkuGBjOFDgACjaAFTYsT1pTq6lyPSROQEoUmSlg+ZUa6xEHm1gG1KD
G+Ct1MIpIkWqLCSQoZn8u7G5tbANxR4MQ2OcWipk+km2RNmJxk6QHhVLZBtw
HxvgYZlo0vgC/ek2NGCKIg4UAcHkyw3z0VB/SWwermD+7iLbZYoaLQUrIY2g
DqW/UG6pv+zZAemO63coewyKPHvPYTCw7tDbiDe7FoynGJaWHORZNP5psosc
bFNsS1VuMAzg9OtJPO6k76hMHxxazbT1+JWmFna+aOIYTW3gESKfa2dLVVqg
BZJr200lhrvEgUT/KB/QsT16R8BR0x8tWjMb7cMucmW3EjFnJF2ZGZRqSBtT
sx80spAErbClLhb8bAnvgiCHJa3jJMWyQ5kxUoKf6WwU96huM8RqIDCncNzp
nUrxa5fO+L+0YUyYyPOXPfgPf7S6oTR4QOkjkMjH4p/hwB6v+PGAksAfU8NI
EdvsnIoNoPzSxC5IGljdzyXSm7X6o6XsIyi6n+rAA8Q1txzQuw0VeQ+ua0M3
NjGfmYgwVic2RoMxRC4ZTe6/pnuJxH62EnuguxOmVCcqu7RxYGERCW3Q3ABv
WQ7pKUwRCroZjCMdJNqyWOBKQeg9+RtNIywAcwSKjv/RxmttK44NoUoAwZt4
cvHKsOOi9X1Nt1QuU5vKXkrQIoDifEiVEwodPHlE1IoBbcYJgqLEvetuR5jC
gpSeodsqbkxqFiRfUlPGzKw+uFnUZZpaD2oqdgT1CU9W1orofcUhvCcpuNiO
Jg0ImVOvQv00ITe/LWRGukCqSOj+YMlswltg8W/EEH+/v2iaVTh++HCz2eQW
XWGORvZhb+rw0K7Wz8ZRizEb48Cj/HbRLKsHNPHgjojcnNoiagMbV7hK/QyF
CZGedc3O1XBaRj91WT3qe/ANtyDdkFAzDLxGb7OcIkqw6intO8iFaE3Jd1wM
2ifSLrVJnW25gRrBlNyroxzyUIqa75qmg4A+a5iPiNETTURvS+v3kXltQ5vM
793c66WMqrh37Fr6XL3CecjDPLtKAEKJNhUA71Ch6/ZGMh/YdMslAOOcq9yv
6zq5euiVga0rqdiE0regIFyEnn/994Oz3s6WO8R31hLnyphi2q7Y8Gw0JjmH
cxpKQg/RoZEsaewSK9FLrxlUkdQ4jHNLlj33boNYplkBq1M4+maDQCh0SUM5
lSmh+kXXyA95unzwAinjLpf7VCopxbDrN0Q6W055W6/AveLUFMUdTIy4eLIF
f6hTv/wQQS7Knslc8I5UQaKZeuWm6q2t4XeWfNWYFSHEa8NzhhF3bywqjQRW
KVNoPlpSMKVeeUD2D464dxWTQ6MhdN3JiZQhqP88dG7qBuZzKU+RdFkQKMQ0
uewaDjkB5htqPq8K1zTqrZvPZd0/AD84FwKfxh9wx5UBoaGycUIcrIz0LuxM
6U3oYyIN1ElYnPBxO9NDpiSdJL7Es54iKvLsyjTC2zm57zZ5B8RGTlzGT7UD
pJbXmMsulzKfY3zl+Y9MYUumz3KerueP29FAVrgBVRHB4gEH67qi++BSVdt9
KU7D6giVD6iyAVi4G4t2nG6Hw2uuWUbf6DnDWfcJoCcNsZmxtUyukgZDmgeg
kGEd9QpDGw5O1CnC0xwkIc0ZOqVQlzn8ElSkCRh/nKEU3/c+P4zD0oK/IcRG
wZcJAAErcfY4wJ9ooM98INv99ETf0XlO0pOuOzjmzRyo57e5Onc8nJfxqUxy
qT6nuBwGBx9rAv5VlxA7yeOnxCnyPvsPnW6WJS4gAAA=

-->

</rfc>

