<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.30 (Ruby 3.4.7) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ideafarm-ipv6-sparse-random-addressing-00" category="info" submissionType="independent" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.31.0 -->
  <front>
    <title abbrev="Sparse Addressing">IPv6 Sparse Random Addressing</title>
    <seriesInfo name="Internet-Draft" value="draft-ideafarm-ipv6-sparse-random-addressing-00"/>
    <author fullname="Wo Of Ideafarm">
      <organization>IDEAFARM.COM</organization>
      <address>
        <email>wo.ideafarm.publication.delayed.4.yrs@ideafarm.com</email>
      </address>
    </author>
    <date year="2026" month="January" day="16"/>
    <area>Internet</area>
    <workgroup>IP Version 6 Working Group</workgroup>
    <keyword>ipv6</keyword>
    <keyword>address exhaustion</keyword>
    <keyword>route flapping</keyword>
    <keyword>bgp update</keyword>
    <abstract>
      <?line 39?>

<t>The IPv6 address space is huge.  This document discusses how "sparse random addressing" can be used
to defeat DDOS attacks, and also to create paid-access websites.  The essential idea is to use the
host ID portion of an IPv6 address as a time-based password that only paid subscribers know.  (They
know it by running a program on the device that they use to access the website.  That program uses
the current time and a secret shared with the web server to calculate the current host ID.)  Each
subscriber has a unique secret so, at any point in time, uses a unique IPv6 address to access the
website.  Sparseness prevents attack packets from reaching the web server.  Uniqueness creates
accountability.  To protect routers from flood attacks, the globally routable /48 prefix is also
randomized, in a way that exploits BGP route propagation delay to partially or completely quash
the flooding at the source, thereby protecting all upstream routers.</t>
      <t>This early draft only contains a conceptual overview.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://ideafarm.github.io/RFC-IPv6-Sparse-Random-Addressing/draft-ideafarm-ipv6-sparse-random-addressing.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ideafarm-ipv6-sparse-random-addressing/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        IP Version 6 Working Group Working Group mailing list (<eref target="mailto:ipv6@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ipv6"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ipv6/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/ideafarm/RFC-IPv6-Sparse-Random-Addressing"/>.</t>
    </note>
  </front>
  <middle>
    <?line 55?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>The IPv6 address space is huge.  For example, it contains 68 billion prefixes that are 36 bits long,
so every human being alive today could be given a /36 prefix for his or her exclusive use for life,
and this policy could continue indefinitely without ever consuming more than a small fraction of
the available address space.  Yet all of the Tier-1 networking providers and all of the Regional Internet
Registries still operate as if addresses are scarce and that each device should only have a single, unchanging,
published, address.  For example, ARIN's IPv6 block assignment policy requires that an
applicant must have multiple physical locations to obtain a prefix shorter than the minimum prefix length
(48 bits) that is globally routable, and that the length of the prefix granted will depend upon the
number of physical locations such that each location is only given a single routable prefix.  The
policy neither contemplates nor provides for using the huge IPv6 address space in any manner other
than the way that IPv4 addresses have been used for a half century, one unchanging public address
per device.</t>
      <t>This document proposes that portions of an IPv6 address be used as time-based passwords, describes
a particular experimental implementation and preliminary findings from studying it, and discusses
the costs and benefits, both to individual organizations and to the Internet community, of using
the huge IPv6 address space in this new way.</t>
      <t>Time-based passwords have become widely used to provide "two factor authentication" when a user logs into a
website.  In that application, brute force password attacks are prevented by requiring that the
user also enter a time-based password that is calculated using the current time and a secret that
only he and the web server knows.  Current practice allocates 64 bits for the host ID portion of
an IPv6 address, which is huge relative to the number of distinct values needed to identify each
host on a physical link of any conceivable size.  By using some (or all) of those bits as a time-based
password, attack packets can be prevented, by sparseness, from reaching that server.</t>
      <t>For such a scheme to work, a would-be attacker must not be able to discover the secret.  A simple
way to prevent this is to give a unique secret to each paid subscriber, which requires that the
server accepts packets from many IPv6 addresses, one for each subscriber.  An attacker can purchase
a subscription and use a tool like Wireshark to see the current IPv6 address that gives him access
to the server, but if he uses that information to attack the server, the IPv6 addresses that the
attack uses will reveal his identity.</t>
      <t>A similar approach can be used to secure upstream routers from a flooding attack.  A well funded and
motivated attacker might use a botnet to flood the /48 prefix with randomly addressed packets, not
to reach the web server, but to get the upstream ISP to nullroute the entire prefix.  Randomizing a
portion of the /48 prefix can mitigate and, in some scenarios, entirely quash such an attack.</t>
      <t>Using the huge IPv6 address space in this way consumes orders of magnitude more addresses, so such
applications revive address exhaustion concerns.  Fortunately, these concerns are mitigated by two
facts.  First, the space is so huge that, even with current routing practice, every person on the
planet can be given a /36 prefix for his exclusive use, and each such block contains 4096 routable
blocks (blocks that use a 48 bit prefix), since 12 bits are available for randomizing
the prefix.  Second, the RIR's can reserve a portion of the address space for sparse random
addressing in a way that permits routers to enforce a requirement that routes in that space are
sparse.  This would enable routers to treat much longer prefixes as globally routable in that
space.  (In that space, the number of routes in the global routing table would be constrained by
enforced sparseness rather than prefix length.)  It might take several years for such prefixes
to become reliably routable, but after that transition, sparse random addressing would no longer
require prefixes shorter than /48.  So sparse random addressing would not, long term, create an
address exhaustion concern.</t>
      <t>Explosive growth of the global routing table, not address exhaustion, will likely be what constrains
use of the huge IPv6 address space.  Even if prefixes longer than 48 bits are dropped, that leaves up
to 281 trillion prefixes requiring global routability.  Sparse random addressing "theoretically" does
not increase the number of routes advertised, but in practice it will, because multiple routes must
be advertised at the same time. As discussed below, the objective in randomizing the prefix is to
exploit asymmetries that put a DDOS attacker and his botnet at a disadvantage.  In the experimental
implementation, this is done by withdrawing the eldest prefix and advertising a new prefix approximately
once each minute, with each prefix being advertised for about 15 minutes.  Deploying sparse random
addressing in this way, with each server cluster emitting a BGP UPDATE (add+withdraw) message once
each minute, would place a new processing burden on the global BGP system.</t>
      <t>This document is a working draft that presents the current status of an experimental implementation
of sparse random addressing using a single router and a single web server at a single datacenter
to serve a simple paid-access website.  The initial objective is to get it all to work, and then to
assess robustness.  (Can it effectively withstand a DDOS attack?)  This document will specify the
experimental system in enough detail to enable others to replicate the experiment, using the same
proprietary open source software.  In this initial phase, the focus will be to find out whether
it is possible for a well funded and motivated DDOS attacker to bring down the experimental website.</t>
      <t>The next research objective will be to quantify the resource impact that the deployment of such
systems will have on the global BGP and routing system.  If the benefits of defeating DDOS attacks
and of facilitating paid-access websites are significant, the Internet community can then discuss
what level of incremental processing cost it is willing to bear, in the form of more expensive
routers and higher energy consumption, to obtain those benefits.</t>
      <t>At this early stage, this approach appears to promise to give the Internet community the "upper hand"
in its battle against bad actors who use botnets to attack servers, and sparse random addressing,
which can only be done with IPv6, just might be the "killer app" that could finally drive universal
migration to IPv6.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</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="security-considerations">
      <name>Security Considerations</name>
      <t>[TODO Security]</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document proposes that a /16 block be reserved for sparse random addressing:</t>
      <t>Block: 2003::/16
Name: Sparse Random Addressing
RFC: [This document]
Allocation Date: [TBD]
Termination Date: N/A
Source: TRUE
Destination: TRUE
Forwardable: TRUE
Globally Reachable: TRUE
Reserved-by-Protocol: TRUE</t>
      <t>Required IP compliant processing:  External BGP peers <bcp14>SHALL NOT</bcp14> drop routes for prefixes within this
block based upon prefix lengths from /0 through /128.  To limit the number of global routing table
entries for destinations in this block, routers <bcp14>SHALL</bcp14> enforce sparseness, using any of the algorithms
specified in this document.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <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="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>
    <?line 197?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The author thanks the ARIN Regional Internet Registry for temporarily providing an IPv6 /36 block
to accommodate his study of, and experimentation with, sparse random addressing.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA5Va23Ibx7V976/oAz9EOgFIUWYUhZUThxIph1WWqJDUcblc
fmhgGsCEM9Pj6RlCiMv/cr4lX5a19u4ZDHiRc1wuEZjp276tvfZuzGYz0+Zt
4U/s5OLj3St7XbsmenvlqiyU9jTLGh9jXq0mxs3njb/DuDRk/G7hWr8KzfbE
5tUyGJOFReVKLJo1btnO8sy7pWvKWV7fvZpFmT9rZIuZG5aZvXhhYjcvc3wL
VbutPZfLfO3xT9Va+5V1RQw86fnNu4mdjF5Opnbis7wNTe4Kfrk4fYM/ocGn
Kww2VVfOfXNiMpz0xHxlF6GKvopdPLFt03kDwb42rvGOy1etbyrfTswmNLer
JnS1qMf+r294NPvKfo8XOLL9li8n5tZvMTQ7MXZmKSP/JsGs/7x2XWwxj08x
vvV2Wbi6xnw+ma9q29U8l7nzVYfTWfuf7Gmtqmjy4Hnp8gLPeZC/5r5dHoRm
xeeuWazxfN22dTw5POQwPsrv/EE/7JAPDudN2ER/yAU4b5W3627OFZMdD6/e
vZ3RXWbqCzN1l9nYJawtIFJsRxv20w90wYM8/PZCh/8fDzpYt2UxMcZ17To0
tAaOYe2yKwp1x++DvVzai7SYvITQrsr/6WigE3txdn767vTq/cHby/fy2qsy
N+FgOH3dzYt8IRMOMl+4rc8Ojg+2TfzrMGQRSmOq0JQYdQeLGobF7tvBwYEx
sxl8ZB7bxi1aY27W3koA9m4DGRfe5tGuu5U/sPZmjc+Iq65kLGR5XHQxerwO
GztRhVhViN0pZGIXrrJzb7voM9MGm/mld609O7u8tq5t3eI2Ti1mSWRZDFgg
BOCgtcuzmVsseJKNn8ccppRDeItHOAHCzFJcnhDTsL5t196sQ2yhRFuHhvqx
YYnV9wVz+N+2eelnc4dTYasYGTyYj5OFqtjK7hZQEBdNjqiN9rYKG2z/DPtv
Db/YvLXzrW26qqLrO1s3YdW4EvN5Dsh5ly+8LonvWz1gsEkkDkliiVQY1S+A
gdHw/aJrGqqaR1UV2eihntbGNYAisxt4cb8SXjV3vhENumLR0ffteJWkmIPn
1p67xdrspLNr0UhX5T93ftgiwCwttoUyQo75eSUHmcr5dsP3NLsnn9nJp7FV
8UUNCMdxYjI+NL249fi6bOA3MD3QAOrcFworfJLdZAV1kGiwU+iq1s3zIm+3
1GKgDlu/aBXkmrTqsggh2zkb114VYe4KGJoD3bzw9vD4Nc+2zD/ToeiMRp05
/6fPppTe2Y3bqkH957oIOU795tuPCVCxc+1WEpNWYpLKgNj0U+yDPICQrAvf
enz7uXNxLTaWs4kDiZtA7V2z8HLIxsO/kkAyoigA0whXDydJAh4wbnFe7xos
K0ilDozs0rq8oqHwceHrtkO8BCjzLvcbTJPoL/MsK7xBNkLGaULWLSRL/DYW
vIM8/rOjQFNGwrDdq9cW9iioBdWmj6oyOKz9+hVeQmtFqFZTg3CHKzRbrFkK
RqiQACioLnOUoSsyYscKz6j/QyyQbAQwsxScfzzPsii6yKkMM74s8qWfGkZN
y3F1AGL2S/K0ORKdJPdlXuViFEYTtCqHkuzclTxRGRoJYx4gljTCkoCp2CI2
dHfMY3SiPXVBTT8gkDgDIMSBN7lvZkcWiX2TMibMewcQg6cqBA5Dr/wKO8Bk
PRUwfALj51AocjlH1r5hkCN482W/NUMT540LpFEFDXVYxFUPSXEtShA3WTuo
DHLhLLRkVy0g6CqneSTJxDWdP6193+6nVxcffhfVUeZFQDADSPNVJfkhKbzx
P3d5MzhBZUA7mLswogQn0QOUXdHmWNLW623EywIeoulNICXM6VsCsWJ7CNC0
hDoahcqCnfKyK/v3ha9W7do8O34t7vZc94YTPIj66U5DXEcn9iZIqwGTYQKC
LXSudA9hqCifSB1nPHL02C3WI/X3L3gSUX7v1qr9HRTpxprsTNJj5XNCgriu
h/qJgBb5vfegKE7fxR48GaePhnAlkI6Aq3hurmkGPQ74honHI48SI809Dsss
Ljs5PCyWdgFTd80WPLfyI++xylD6JQw8NXlfD1gDjyBuhtg7SMra8bG0nUgE
/f2R5A1ghxYkoSE1KPIyC9JfsX3OzcgY6LryWUxB80PdRQ4XcoAigAHROCWO
2HbZluLkrXrKQHo0PyOjauDOkZmWcLWpnQem5EBkyWEXAd0Rv9PheM/5fWgz
M5RIpy31uFQjmt8wooBa5Te0GXX6iEJ6s2F1mBY+UmxVgW3ovcZOgER2CTij
ScFZyavUSyd2sxbvxBSgaYBOwAKQ30dp/aJKYa0xzWnQQCP1RSD+DMwqJV/B
psQAcJB5jw/qtRqFRjYUNshRzZe4GnQwkJ1s5P1PMydOMwp9PTzu0SdSOwLd
27RCLVhPKC0kfuGor441izEMxEoPGKe557pT6DIHAqT8CaELIeK9I+xQBA6G
zAQCc+eKjhHufaYWy1lk5sutYImy3CCYOOBOXt1q2Gw15ed3giYRBAYCvdkm
/US6wzPauyieK9Yh/lSke8zY9Nqe3mdridQPppzSlnFgedMHdA7GSlzOGCYR
wUZYZbFGNFI+ZsQpORaT0wxr645Qi+SJKrTcUCRiFYFADEJ31z1jhYynEJbx
bTaJfunxNFi0TCDmPuC6eC4IfY/192bbz2F00eQs5Lo1tLHHYUsaYGx9HxUe
6S+yzW4HnrnaSUqt1uB/4OMeGJbG1QNSkdvAPiHQ2rfefs9ToRS4pQTR7/P9
fWLOk1N2eGBeJpJukvupNDAhyA+YxNorxdcI68tGJrzQu8F4VnuPK471lIbL
cpI/aRD4qthDHLoleond2AogkjSBOhpVjSocxPIP6K9q3I1ZNDcUV9h4UrWu
YvxAeaYMCDnBiZ1n5at1m7QK4K7UFbRcoFijmkBKLS0IgB29qFlv+ikdlPoU
l78HKqpZOp9XnjGIcXH9kc+rrii0iuBbqqUZsYCrVIaIfGZU1947IlVW5m2+
ElJYadEi0R6Rpl2TBxxTF+9LkBSGvQvCFJ/+EwYh8bQRhk6W7EnDhcTiUKVb
IZN1yC1CnEcxAEDndmaULSIdQiLyQatKMaypEutsu8qRpYu/RT+8lYzSSy0Z
BRnNMKPJxLyJrbroUMHgGCIanXRKsl+pcfu4oSGUmivyT1OVAhIRqXclfmBg
krnVTb9QoOxVJsoiEgjgH2XNQ/F0/OJPrwYaaORltM/SXwkq9VUltmmn51MS
SMh29DKBeDMuSXiOZudBZsdsWZeDHNBRpOK4uPqdAjssQb9lctl3tn1H4Mp7
bR+za/vcq5ehu5JH68OWgFspRXA9vJaK1C4V71EdjXlDdoNURnfrW1GSKbCO
iDlamaHF6kIod7Xyza4SdY/UAP0+pi/anl2MN57ey9Djw/V9hMFndMFNX7cy
PNoGphXPNEnkbJQooTmh9ULB98oX9mku2gRRrbsl4MIPsdkWxb6yD/GhXjii
TyJ7JLQ4ybjOIQK5ZaqasCAsBhInhO2p1l2SowpJjSYZaqfOvUIMSESPCr+9
HsKOK1pMLad9v4+l4ZMgAGA6Z8tF4mjVhM2uSnvMAoLGj2DKVJMQcyeUAwNt
qIvBSpHUs1/3CfiDiOeMdeTJQQ3Jy0QLqeaUIMxQ2tRewgvbFN4x/XY1DfXy
9RFscL9RsiPDI6l2/a3rpxQ7wYEBtqTu8OwJiiu4A1UAXIB2tTP60IddBodq
8yj0rZMO30B3AS/U1ZQu5aiWoUZPk8nKDBnZsMjQwnJkdCCRB/Y0DiUTA6II
Gw2nMP8Hm1p3EnwjdBrX3cLXTOq0IXK3Zem1/aGQQocet5HJxwCuRIaUy1mZ
cH8cESW8Ww0li9+rCc1+TTgd6GJG1jbXxlDWuE1/QF+g0uzhV8uLpATtBLMs
61+Sz3zOS8ldhs6s6I9yE1qcauZR7qkTUhdsp1QptufsSx39IU1jZjvz0IvU
pl+C4D5RjzdK3JVZibHrAczaXpRm5qePZ6c35/YZ1vl9L/dzixQfoT9LAcy+
ABLTyIYC5Sp5WKQTzDvQgj5l9j7NXeIWe5cPegFsvNq+NabNTLU1MxJ7xmN+
G2Gurm8UfKHGNxjxJCR1yWSjFkzyo+HZqDgUh0qPMwenkwLVCD9tUiOtlD7W
w8uLdHfBZiNvLkYREHtqmGuzcFcMaXlK4m0cORQT6Bxmq7QZ9+wtJMckv1zq
WqmJCc2IAKPg+Ob5/fsbQcJY+wVrSjKaPRWqgehCvgrdir1DUJRCE7ckOWkd
ydEbr3zO34us6aggJyYYtnoQwC0bLaH2VWp248+y3QAw+/Bk9CU11SyFFDOW
OHmqIuZSA7JXYxkYm7WXPlYuHlQHmLZnPu5+GWB3ZcA+djB7CvRmYfMQIwYr
am+88p9boUm8rBzZcnQ68Gut17kUhqqocA8A7K7jmEkYi0HopqTHqvokqbRw
HsYPBekzXool6E4TV9+LknaCXLZx1Pi+TbrieAuWzNSiAx67b9NWcg5Cv5SW
7fSJtpWwRvHUhPZmoxkPLsmNJA0lRY7ggf0zq0ajsOIr5DCumfb8isWnVBWs
JWiQihTA9GxPAX8lNwCVb1Z9RVInIB96x6nHkVTDkjN1BfTiJDI7JOAfSlB8
EKal7bIy1/s7aSA8oQY+nnR1LVdqVTYxOeMT+QiK5+3AiiSjxVe4IltukHut
N5easeKoxFbISXejT+HX1GiHgvqXphZ8T7KWwD3Zy9T+g+0TpZFzPfnkFtr2
UmxP1BX1WgQBJcw4a6RcqXIeAPkRk5uhA8BFeX0k/31l34aKLZahtXmm9yn8
rqFy67dW25GT95+ub/jLCP61Hy7l89X53z9dXJ2f8fP1306/+274YNKI679d
fvrubPdpN/Pt5fv35x/OdDKe2r1HZvL+9IeJ6m9y+fHm4vLD6XeTISsOQEgf
F7djf9M3yDXSI4imbydnnPPm7cd//d/Rsf3ll/+6evf25dHRn379NX15ffTH
Y3xhu1R3E0voV978GnUkKYkQ0gtXI+YKWlYYNNCGd33Q6X//SM38dGL/PF/U
R8d/SQ8o8N7DXmd7D0VnD588mKxKfOTRI9sM2tx7fk/T++c9/WHve6/30cM/
f4NI93Z29Pqbv6gPXbO5w/iBM0XehrnkPz/eXJ5dDq9/ksEXpx9OHwz80pUC
qvKj/n5q7vviNntYvo7i6sSYN5xwYl++ePH1yQlWMB/k9xtP/TrJwBFO7I97
B/nJnBbDpc8Zf/aDAW/OfjI3LIer8fMPh6fmWlLEib25+nRuzjwbwek3IfLk
XWiQJDMm3/Tk276UvSIlG724SjLO5tvZxya0YRGK9ArvpIjLEMh6I507VVlC
5RMUOJ+JbCnV1J5AO/iSFDV9DbAMo9qakJOCyyRtS8de7sr2StvUtjt8gcGN
sIvDo5ev9QKfNzHtvXLlsRIPxbQWAzxDtlNWHAJczjAdGgMqQd91GLeqEwes
tkObo1gFONy6jEYJUq4YsIcbgoG8Q58DremYpwveHRQ+W/F1NL+cqAQ++5/J
EvHuJ78qIupvg6RcvFVKy4vUhze+Nt34bvWmwZd1aBxqxm26vdFTa43KxpMI
bPQnGEhJgT/oknJIrrEgXOo+7WiNOCDt9nQT4MD8G5KttnqhJwAA

-->

</rfc>
