<?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.8 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc subcompact="yes"?>

<rfc ipr="trust200902" docName="draft-ietf-6lo-minimal-fragment-00" category="info">

  <front>
    <title abbrev="watteyne-6lo-minimal-fragment">LLN Minimal Fragment Forwarding</title>

    <author initials="T." surname="Watteyne" fullname="Thomas Watteyne" role="editor">
      <organization>Analog Devices</organization>
      <address>
        <postal>
          <street>32990 Alvarado-Niles Road, Suite 910</street>
          <city>Union City</city>
          <region>CA</region>
          <code>94587</code>
          <country>USA</country>
        </postal>
        <email>thomas.watteyne@analog.com</email>
      </address>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization>Universitaet Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <author initials="P." surname="Thubert" fullname="Pascal Thubert">
      <organization abbrev="Cisco">Cisco Systems, Inc</organization>
      <address>
        <postal>
          <street>Building D</street> <street>45 Allee des Ormes - BP1200</street>
          <city>MOUGINS - Sophia Antipolis</city>
          <code>06254</code>
          <country>France</country>
        </postal>
        <email>pthubert@cisco.com</email>
      </address>
    </author>

    <date />

    <area>Internet Area</area>
    <workgroup>6lo</workgroup>
    <keyword>Draft</keyword>

    <abstract>


<t>This document gives an overview of LLN Minimal Fragment Forwarding.
When employing adaptation layer fragmentation in 6LoWPAN, it may be beneficial for a forwarder not to have to reassemble each packet in its entirety before forwarding it.
This has been always possible with the original fragmentation design of RFC4944.
This document is a companion document to <xref target="I-D.ietf-lwig-6lowpan-virtual-reassembly"/>, which details the virtual Reassembly Buffer (VRB) implementation technique which reduces the latency and increases end-to-end reliability in route-over forwarding.</t>



    </abstract>


  </front>

  <middle>


<section anchor="overview-of-6lowpan-fragmentation" title="Overview of 6LoWPAN Fragmentation">

<t>6LoWPAN fragmentation is defined in <xref target="RFC4944"/>.
Although <xref target="RFC6282"/> updates <xref target="RFC4944"/>, it does not redefine 6LoWPAN fragmentation.</t>

<t>We use <xref target="fig:perhop"/> to illustrate 6LoWPAN fragmentation.
We assume node A forwards a packet to node B, possibly as part of a multi-hop route between IPv6 source and destination nodes which are neither A nor B.</t>

<figure title="Fragmentation at node A, reassembly at node B." anchor="fig:perhop"><artwork><![CDATA[
               +---+                     +---+
        ... ---| A |-------------------->| B |--- ...
               +---+                     +---+
                              # (frag. 5)

             123456789                 123456789
            +---------+               +---------+
            |   #  ###|               |###  #   |
            +---------+               +---------+
               outgoing                incoming
          fragmentation                reassembly
                 buffer                buffer
]]></artwork></figure>

<t>Node A starts by compacting the IPv6 packet using header compression defined in <xref target="RFC6282"/>.
If the resulting 6LoWPAN packet does not fit into a single link-layer frame, node A’s 6LoWPAN sublayer cuts it into multiple 6LoWPAN fragments, which it transmits as separate link-layer frames to node B.
Node B’s 6LoWPAN sublayer reassembles these fragments, inflates the compressed header fields back to the original IPv6 header, and hands over the full IPv6 packet to its IPv6 layer.</t>

<t>In <xref target="fig:perhop"/>, a packet forwarded by node A to node B is cut into nine fragments, numbered 1 to 9.
Each fragment is represented by the ‘#’ symbol.
Node A has sent fragments 1, 2, 3, 5, 6 to node B.
Node B has received fragments 1, 2, 3, 6 from node A.
Fragment 5 is still being transmitted at the link layer from node A to node B.</t>

<t>A reassembly buffer for 6LoWPAN contains:</t>

<t><list style="symbols">
  <t>datagram_size,</t>
  <t>datagram_tag and link-layer sender and receiver addresses (to which the datagram_tag is local),</t>
  <t>actual packet data from the fragments received so far, in a form that makes it possible to detect when the whole packet has been received and can be processed or forwarded,</t>
  <t>a timer that allows discarding the partial packet after a timeout.</t>
</list></t>

<t>A fragmentation header is added to each fragment; it indicates what portion of the packet that fragment corresponds to.
Section 5.3 of <xref target="RFC4944"/> defines the format of the header for the first and subsequent fragments.
All fragments are tagged with a 16-bit “datagram_tag”, used to identify which packet each fragment belongs to.
Each fragment can be uniquely identified by
    the source and destination link-layer addresses of the frame that carries it, and
    the datagram_tag.
The value of the datagram_tag only needs to be locally unique to nodes A and B.</t>

<t>Node B’s typical behavior, per <xref target="RFC4944"/>, is as follows.
Upon receiving a fragment from node A with a datagram_tag previously unseen from node A, node B allocates a buffer large enough to hold the entire packet.
The length of the packet is indicated in each fragment (the datagram_size field), so node B can allocate the buffer even if the first fragment it receives is not fragment 1.
As fragments come in, node B fills the buffer.
When all fragments have been received, node B inflates the compressed header fields into an IPv6 header, and hands the resulting IPv6 packet to the IPv6 layer.</t>

<t>This behavior typically results in per-hop fragmentation and reassembly.
That is, the packet is fully reassembled, then (re)fragmented, at every hop.</t>

</section>
<section anchor="sec:limits" title="Limits of Per-Hop Fragmentation and Reassembly">

<t>There are at least 2 limits to doing per-hop fragmentation and reassembly:</t>

<section anchor="latency" title="Latency">

<t>When reassembling, a node needs to wait for all the fragments to be received before being able to generate the IPv6 packet, and possibly forward it to
the next hop.
This repeats at every hop.</t>

<t>This may result in increased end-to-end latency compared to the case where each fragment would be forwarded without per-hop reassembly.</t>

</section>
<section anchor="memory-management-and-reliability" title="Memory Management and Reliability">

<t>Constrained nodes have limited memory.
Assuming 1 kB reassembly buffers, typical nodes only have enough memory for 1-3 reassembly buffers.</t>

<t>Assuming the topology from <xref target="fig:topology"/>, where nodes A, B, C and D all send packets through node E.
We further assume that node E’s memory can only hold 3 reassembly buffers.</t>

<figure title="Illustrating the Memory Management Issue." anchor="fig:topology"><artwork><![CDATA[
               +---+       +---+
       ... --->| A |------>| B |
               +---+       +---+\
                                 \
                                 +---+    +---+
                                 | E |--->| F | ...
                                 +---+    +---+
                                 /
                                /
               +---+       +---+
       ... --->| C |------>| D |
               +---+       +---+
]]></artwork></figure>

<t>When nodes A, B and C concurrently send fragmented packets, all 3 reassembly buffers in node E are occupied.
If, at that moment, node D also sends a fragmented packet, node E has no option but to drop one of the packets, lowering end-to-end reliability.</t>

</section>
</section>
<section anchor="virtual-reassembly-buffer-vrb-implementation" title="Virtual Reassembly Buffer (VRB) Implementation">

<t>Virtual Reassembly Buffer (VRB) is the implementation technique described in <xref target="I-D.ietf-lwig-6lowpan-virtual-reassembly"/> in which a forwarder does not reassemble each packet in its entirety before forwarding it.</t>

<t>VRB overcomes the limits listed in <xref target="sec:limits"/>.
Nodes don’t wait for the last fragment before forwarding, reducing end-to-end latency.
Similarly, the memory footprint of VRB is just the VRB table, reducing the packet drop probability significantly.</t>

<t>There are, however, limits:</t>

<t><list style="hanging" hangIndent="4">
  <t hangText='Non-zero Packet Drop Probability:'>
  Each VRB table entry can be 12 B (assuming 16-bit link-layer addresses).
This is a footprint 2 orders of magnitude smaller compared to needing a 1280-byte reassembly buffer for each packet.
Yet, the size of the VRB table necessarily remains finite.
In the extreme case where a node is required to concurrently forward more packets that it has entries in its VRB table, packets are dropped.</t>
  <t hangText='No Fragment Recovery:'>
  There is no mechanism in VRB for the node that reassembles a packet to request a single missing fragment.
Dropping a fragment requires the whole packet to be resent.
This causes unnecessary traffic, as fragments are forwarded even when the destination node can never construct the original IPv6 packet.</t>
  <t hangText='No Per-Fragment Routing:'>
  All subsequent fragments follow the same sequence of hops from the source to the destination node as fragment 1.</t>
</list></t>

<t>The severity and occurrence of these limits depends on the link-layer used.
Whether these limits are acceptable depends entirely on the requirements the application places on the network.</t>

<t>If the limits are both present and not accepted by the application, future specifications may define new protocols to overcome these limits.
One example is <xref target="I-D.thubert-6lo-fragment-recovery"/> which defines a protocol which allows fragment recovery.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>An attacker can perform a DoS attack on a node implementing VRB by generating a large number of bogus “fragment 1” fragments without sending subsequent
fragments.
This causes the VRB table to fill up.</t>

<t>Secure joining and the link-layer security that it sets up protects against those attacks from network outsiders.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>No requests to IANA are made by this document.</t>

</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>The authors would like to thank Yasuyuki Tanaka for his in-depth review of this document.</t>

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference  anchor="RFC6282" target='https://www.rfc-editor.org/info/rfc6282'>
<front>
<title>Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks</title>
<author initials='J.' surname='Hui' fullname='J. Hui' role='editor'><organization /></author>
<author initials='P.' surname='Thubert' fullname='P. Thubert'><organization /></author>
<date year='2011' month='September' />
<abstract><t>This document updates RFC 4944, &quot;Transmission of IPv6 Packets over IEEE 802.15.4 Networks&quot;.  This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs).  The compression format relies on shared context to allow compression of arbitrary prefixes.  How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers.  UDP header compression is specified within this framework.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6282'/>
<seriesInfo name='DOI' value='10.17487/RFC6282'/>
</reference>



<reference  anchor="RFC4944" target='https://www.rfc-editor.org/info/rfc4944'>
<front>
<title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</title>
<author initials='G.' surname='Montenegro' fullname='G. Montenegro'><organization /></author>
<author initials='N.' surname='Kushalnagar' fullname='N. Kushalnagar'><organization /></author>
<author initials='J.' surname='Hui' fullname='J. Hui'><organization /></author>
<author initials='D.' surname='Culler' fullname='D. Culler'><organization /></author>
<date year='2007' month='September' />
<abstract><t>This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4944'/>
<seriesInfo name='DOI' value='10.17487/RFC4944'/>
</reference>



<reference anchor="I-D.ietf-lwig-6lowpan-virtual-reassembly">
<front>
<title>Virtual reassembly buffers in 6LoWPAN</title>

<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
    <organization />
</author>

<author initials='T' surname='Watteyne' fullname='Thomas Watteyne'>
    <organization />
</author>

<date month='July' day='2' year='2018' />

<abstract><t>When employing adaptation layer fragmentation in 6LoWPAN, it may be beneficial for a forwarder not to have to reassemble each packet in its entirety before forwarding it.  This has been always possible with the original fragmentation design of RFC 4944.  Apart from a brief mention of the way to do this in Section 2.5.2 of the 6LoWPAN book, this has not been extensively described in the literature.  The present document attempts to fill that gap.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-lwig-6lowpan-virtual-reassembly-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-lwig-6lowpan-virtual-reassembly-00.txt' />
</reference>



<reference anchor="I-D.thubert-6lo-fragment-recovery">
<front>
<title>6LoWPAN Selective Fragment Recovery</title>

<author initials='P' surname='Thubert' fullname='Pascal Thubert'>
    <organization />
</author>

<date month='June' day='27' year='2018' />

<abstract><t>This draft updates RFC 4944 with a simple protocol to recover individual fragments across a route-over mesh network, with a minimal flow control to protect the network against bloat.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-thubert-6lo-fragment-recovery-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-thubert-6lo-fragment-recovery-01.txt' />
</reference>

<reference anchor="BOOK" >
  <front>
    <title>6LoWPAN</title>
    <author initials="Z." surname="Shelby" fullname="Zach Shelby">
      <organization></organization>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization></organization>
    </author>
    <date year="2009" month="November"/>
  </front>
  <seriesInfo name="John Wiley &amp; Sons, Ltd" value="monograph"/>
  <seriesInfo name="DOI" value="10.1002/9780470686218"/>
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIAHmaTFsAA6Vaa28bNxb9Pr+CiD84QSWt37G1aFE/mq6xiWPEaYMuFiio
GUpiPSLVIcdaNfH+9j33kpyH7NTGVghsi0Pyvs59TobDYea8NMWvsrRGjYWv
apXpZcV/Ob+3s3Oys5cVNjdygcdFJad+uJLeq7VRw6PSDhfa6IUsh9NKzhbK
+CH259KPhTZTmy31OBPC23wsttfKbeNLbhe0z7Ur2pSaiKfvrp5g01LmPq15
7UtsePv2SrwL9MSbSE+8sdVKVoU2s0xOJpW6G4s/ZTCTlZJjcWm8qozy4hRf
s9VsLLA5u12NxQUJmcnaz201zoaiskRbFdrbirkF6x9H4lMkgqWgnI9zu5Cu
u24rXHtqoNuZuFB3OleOxPOVUhBtf+/kZEeclneykoUdXulSOfHBymIgbmrt
lTjZ3SF9ab8ei5+Mtkac428sVWqGb2Nxfsr6LEh3JweHx6+DfmvjKzpyQ4/V
QuoS5mTmRkkz30vmagQ9Q0IW6Xwkzmy1kMY0Ep3LynllOussEXi5U5XTXkJ9
Z5WCVsXHf112RLu2zk9lPhf7+zsHB60UYXPD9MVw73j/8KTL9I+KSK1bxnM5
sd/7P/QIpBOr1yMou56oyjesXkuXAxXtMnN6rl1uxc0aUizcADbP8SShhB+2
TOOvoTirdUlQEhf89eAQ9imVEgVM875a4Cf2XO/CLxqZ3r3/6cfLqxs8uLHL
uZYwuNdLW2rXGmfnaO/woGccwNfkqhVz6QPn3+fEFdslIw+CNjy0Tdx9eHN+
tHe8F/88ODk4oD8vhxcjrfx0WK70jAC/WkozvNOVrwF6YNs5tZiU67Q30mHX
aHy2UrmFSXnT2fv3/4Rp3l+Odnfwb2fv15PXxzsHr3eOjo/2do+zbDgcQofQ
Ghw0yz7OtRMIEDU74wy8OiGNoOvutFoJO33KbUfZpzkQpBbL0q5J97KQSw+x
AfhSrlUlEp9hTRtx9NZ+uj69GgjtxUKuxUThn1FTnWvQgNaEpJ9EAMeN9QhB
Yi7vFP1udKKEIowi0NwCyLhWeydARlfK0524QaVriC/tR0HcOdx8osCzLFdy
7cTSOqfpvpX2c7iaAvr0TBvipcc6YKRnhnQSLTja0B/+loKDH/t7sw62P39+
rqnv7wdiNdcQrVAe6HLMUtwnPjT7gPbpFPp5+fOHs1dCQ/+qZdWrfG7077WK
V1WqqBG/+KpSIirka9i5gNpyoqxIc8XQ2yF+YXOp5USXcBDSa2Vrr4YEiY46
R1mA0kIXRanwZUu874AmmrgBDHOVZWl5AxJQIaxvFPEDTUXt3t+PstMSoa+e
zcMqOdD9vaiXBURw3Z2MpcJikeACafk+8Sg9sP5JidopXDDVs/FSVXO7xL0w
ky7LmnzDf/UsjsICsCsoFUqcJp2Q6SMWcQ8/OxskbEHZwJmsPOlGikVdej0E
0aBboNGvCJCX13dHwtm6yhVbB4DzwCEriW500ZrIgcIooBUmOcWTSpxBqP/i
gwjQ+3wDG30jHvvwk2b7aDQSWPiC674MH/l890Wc8RPa+f8SefyzJV6Sikfi
8FXW37q7t39wePT6+OTBmeZJ78A3Dbub3HSe9E58Yfpia2vry8aJL1jjZ+LL
X6SBD4w8sxSDNj7wPrug0qdd6nvGxqcNEg91OgnR4NHVAI3PY7HV4l1wVfbt
ds9DhfQR1oMOsWb1bLR9n2VXAfeoPCtE3MlaxHKPBKT4wiiOrlA7Wp0rSZGc
9lUKDsGxtO/wwbVH2eWU78A28hGcTW4YL2x8fKop6MPVpCAaCN8oQ2+HTcpZ
qEEUZds1l6A2DRvyGqynG9gdET4fuLxLkRg7ERSMW1COgSs7BWemILFJ07XO
PwqKOnuMfJvEOCQjFHVIonAoOb6RIpLOoKqoxalWJaLNBPogYr18xaoP+wYc
Qeb44Tid88ZpXZY9+1DIg0i8xKwhjlyajcA4aENbSssF2T0GwEZiCuRQbFCq
ofjbkcrUC1QuOLhLB05G2Q+UvdMGOlopkhRfwu3E7/bWtnDrxcSWowS7Oasf
J5q7xe5A7A3E/kAcDsTRQwPwEdRICtVN8dixIyzaRRRnlDVFziFxhQgMnU0U
oztigDiET3AyBQCaOqe5pMtEdtp1peimVOQkVOQW3keVMTKqQGaTMyDpV6f/
UIPuAn6xSTuQgx4IEZJzNsuHL0XBeHHiJZgI8CVGe/dArtKi4n5FFOC6VFkk
B8O+IAoDptFWo0BnxVRWBNNQptFGSYXcrWKXasopkEcFo3IPLpDc6LrVHN1Y
otTUYc3VJEiO8hMF4bKyeYC9rVrUMbuIXAvGM6jKEnUUygeU3bHMIzKUaXUr
EhpCUgyfQyhmk/TjbHQtqt8KAjdYV114/j3EikLn7JgrIr20FZ+100gzOBQ9
alCd2wrGWFpyQm9H2Q20QWcOR/t0rlPAxIAYnD40Dunm5Pc2+rBGW8eqQjhx
CjVe1xmoZCo7ZqNSARafQSgub6XYPRpOIM2LLiBeDKgeYrl1QTX0dB2hE8Xq
aQP2Ka2ZBZH6bhytV3PtCbjH2zS7NCctEuErJU4H2S2KoxI4ugbtwtKVZqxx
jGtu7QpElTmKZlmiAo439BzAGjBnlGK7EMfsDlgLnCf/dXBl4pLcuInmfr3U
1K1OFHoSbeEKCJQbxShnialldI6yn4CAiHLukFp9dWNGtE+PT0REkKgdc+bI
WTonBinukhcEZMoUYEpZzdAhGS6eqX2yZcFqCB1StGtQU6nMDKT7QIYICfCc
pfsIeNnTKMWqkJdeDSg+RLYIDIk1vjrypu4gh5520NymAZ+igSMOONGnZ7vA
tutAG6lRgbNGC1MEatehEztT2fMHbiN7Uac5/7y8G2oO87VU2y9eNlJtUx2l
VMvtY8JRAhZsHW4gYoQt7hT6ASuE/JRVyIySTDbYsCDl+3Wn2ih4gxEvK/Uq
XUiLOKxoggCYLEfczL3VXOsAE9dg4B9g4M0DBjq96Octp/JxyYfuSS6keo49
uLnENi/2RHjKaYGL4edINiZmwE1oWbNg0eYxbqHahO3XOPNKah+GCDB8P4cF
V2/STZwRhNwuY8qaKaOqBNiO/YKRm34upiSuDG1Ge436jw/6Y6uimlGSAnBf
tfyMhh7BxDy3iD140e3BU5POtXUVQjPjEhspn1ZqwyNXti5JpE6JRgEF+a5R
dBcwrNZ3amHB2Ttp5IyHB9GsTfufZefWUD/MtXqIiOxBbEssLfgGcky0xKTG
XXF79rDeIWDGqBku4fjLN8UQFS5iu+0O9x+5gbJ2IkKK8HZpSztbh4AYCta0
FkYopKMYxAfUi5+zdBeMC6qcomHJZyvmgXH0A7f407ri7jq2+px3wmMkgMgr
hbcgB8XWr/D8ZFfea5FjG/5dpw8PnfeTN/z7iS4bn2dsaa59TuMuqH/+gfkE
k2/w5ZHZwF+n8bcntzzY8Qz9nnf0e/EM/fZb6AZ8sYm+TGOjhM6HnnUJJCnu
n0MQa5HJsDynNiCvUS4aDwAxPtsInaA6YPA+BjUKJAGgHHZtntdLVF3UUA9C
r0I1uqXrYsIjR0CuJkquU5I0xAbpPqrTjRV2yfF5UnMqKyoEFGtUv2oAg6h4
VEVqeHygGLLLz09MMy9708wse2q/Don3q0NQqDqv9CTNG54/iqX9cebWGUl3
Bo1/YRidgXVuzamQiaPZkCJL7XzitZNX70NHSwNns+3bRBeGut0y6gHBQZgA
b9glJhn0JSCAirFchwKiCcbWL2FL7kSIWaj5N+Cc99B3T0mzc3Wn+GB8oImb
pEEyjc7RCCBoes4/TYkwQPxcUYocRPGR8+FnKKdml4bah2+3D+A2V9YM/1CV
FdeBwAURuG4JjLOx4F6kYYz0H8M00uLuHjztpWzyVOiCHms5XlEQ4zzN8/xW
C3voRQvyNahjISGOr+EgbgGfjNOtlKmpGAmV/u7e8c5wsvbqK0OADmyI7C/k
d9wiUUkdfauVyChqimWluapb0NQAdSkYUXT4MjTZqEPoRV23VIg1Epclv9c6
ctmLOKmgWdimO3AhaujQqpM2ue0K4O7YP+2mwEN2X1LcgcHa10UfmjdU9KKV
OOLiHkDLYWftFnQr3ZjgzOwy9e6orDthJ0EUNcJp/LfQjoeNyQlIIwSS5UbL
FTXgHg4kUnno4mnGQC5rakNrk3S/pjHQFEgecI/X67Tb2ot7nGbusTnIZ1Aa
Aj0ZAZmjzv0jk7yEC9IlleGtPlHWQSxSJ7X7jw0CYvcZwES9c9iRM6pQDbp2
yBPb8VhhPuC1IyX1YNwyOuKd3JpyFyUbglGeEOuaSFagCuYJpGmmZdHdaN7A
HRrXWb1D3DfkuVoG0Kc7QjgFVONl0ZCxtMeCXC5LaliJ82Upc9XQNcqvbHVL
w81pN9ASpYlF7xsnjywOBfZAvh1Edq4eoDj0NQ66pco5otFqKOrjayejVhT7
vM1tyV1HivI9OUfZe0PeKilrkUOExPSnr3iRkdK7wTAukg2hlKfCRKwD93Ay
JN4bBVOR3aiu1wV1OsQ8amua/XvCW8XgRM/Asz0pLuxNfETaTJEkZVpyLnJc
6Cl2TsHdwvwhDH0JFRM7q5140QLpRQeqqVGhWoSOt3jOOoOtrjv2wyI0TM2/
qKnDYhGV+A09JrNiik3ouaSEFN4cRa+a8xXNK6HVGYVWcknrVJQ+OkyEEr3T
YQW6oNjL06vTB0q9asIUo4D3EOQWEipkZHXeHod7TvNbY1fo1IPUwdvC/2Zx
sccr9W10VmluxS/S1ev6VouPqDVvuUoRnLvMEI7j6dVvein7gBy9z6P3CNn/
AFRdSO1KJAAA

-->

</rfc>

