One document matched: draft-howard-homenet-routing-comparison-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<rfc category="info" docName="draft-howard-homenet-routing-comparison-00"
ipr="trust200902" submissionType="IETF" xml:lang="en">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="Homenet Routing Comparison">Evaluation of Proposed Homenet
Routing Solutions</title>
<author fullname="Lee Howard" initials="L" surname="Howard">
<organization>Time Warner Cable</organization>
<address>
<postal>
<street>13820 Sunrise Valley Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>US</country>
</postal>
<phone>+1 703 345 3513</phone>
<email>lee.howard@twcable.com</email>
</address>
</author>
<date month="December" year="2011" />
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>homenet</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>Homenet Routing Proposals</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document evaluates the various proposals for routing in an
unmanaged home network.</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>This document evaluates the suitability of each of the proposed
routing solutions for the Homenet problem space. The list of
requirements is provided in <xref
target="draft-howard-homenet-routing-requirements"></xref> (soon to be
included in <xref target="draft-ietf-homenet-arch"></xref>). This
document is intended to assist the working group in developing consensus
around a single solution, so that work may progress.</t>
</section>
<section title="Requirements" toc="default">
<t>This section includes the requirements from <xref
target="draft-howard-homenet-routing-requirements"></xref>. After each
requirement is a short mnemonic, to be used in the table comparing each
solution.<list counter="REQ" style="numbers">
<t>Reachability between all nodes in the home network. Links may be
Ethernet, WiFi, MoCA, or any other; test all solutions against
mutliple L2 types. [1. Reachability]</t>
<t>Border detection. Any solution will have to determine the routing
boundary. It is assumed that no home networking device can handle a
full routing table for the Internet, and that a home router should
not be required to do so. [2. Border detection]<list style="letters">
<t>Border may be upstream ISP, or may be a device that is a
gateway to SmartGrid devices, e.g. a controller that speaks RPL
to 802.15.4 and foo to home net. Or there may be no border, if
no external connection has been established. [2a. Any
border]</t>
<t>Must be able to find “up” (a path to the
Internet), but must not be dependent on “up”
(Internet connectivity) existing for intra-home reachability.
[2b. Find "up"]</t>
<t>May be discovered by routing protocol, or other means. [2c.
Border method]</t>
</list></t>
<t>Robust to routers being moved/added/removed/renumbered.
Convergence time a few minutes or less. [3. Handles change]</t>
<t>No configuration required. It may be acceptable to require a
single password or passphrase to be entered on each device, both for
security, and to establish the administrative boundary. [4. No
config]</t>
<t>Best-path is a non-requirement. [5. Null requirement]</t>
<t>Support for multiple upstream networks is a requirement. [6.
Multiple upstreams]<list style="letters">
<t>Including wireless offload, video-only, and split-tunnel VPN
scenarios. [6a. Split up views]</t>
<t>It may be assumed that each upstream will be connected via a
separate router, not multihomed off the same router. [6b. Null
requirement]</t>
<t>Must support a prefix delegated from each provider. How hosts
handle multiple prefixes is not a routing problem. [6c. Multiple
PD]</t>
<t>Load-balancing among providers is a non-requirement. [6d.
Null requirement]</t>
<t>If multiple upstream networks can provide a path to the same
destination (such as an Internet host), the solution must allow
for backup in case the router or link to one upstream fails.
Failover time should be within a few minutes. [6e. Failover]</t>
<t>Must support a "walled-garden" network. This might routing
based on either source address (from the walled garden network)
or destination address (to the walled garden network); support
for both is not required. [6f. Walled garden]</t>
<t>Source address selection is out of scope for the routing
solution. Choosing which address to use to look up the
destination address is out of scope for the routing solution.
[6g. Null requirement]</t>
</list></t>
<t>Cannot assume hierarchical prefix delegation in the home, unless
the Homenet working group finds consensus on a hierarchical
addressing mechanism. [7. Non-hierarchical]</t>
<t>A host with mutliple upstream paths to the same destination
(in-home or external) should be able to use another in case on
fails. [8. Failover]</t>
<t>Prevent looping. [9. Prevent loops]</t>
<t>Should be a lightweight solution. [10. Lightweight]</t>
<t>Must handle multi-dwelling units or other potential dense
wireless or wired networks. [11. Robust to MDUs]</t>
<t>Must be resilient to running on wireless networks. Must be able
to handle both wired and wireless links. [12. Wireless]</t>
<t>Robustness in the face of unintentional joining of networks. [12.
Unintended joins]</t>
</list></t>
</section>
<section title="Consideration">
<t></t>
<section title="OSPFv3">
<t>As documented in <xref target="OSPFv3-autoconfig"></xref>.</t>
<t><list style="numbers">
<t>Reachability. YES, OSPF can detect reachability.</t>
<t>Border detection. NO. Any node which the router uses as a next
hop, but which is not in its OSPF Area 0, may be assumed to be an
external border. However, the router will have to be manually
configured, or use another routing protocol, to establish a path
to that next hop; therefore auto-configured OSPFv3 by itself does
not detect borders. <list style="letters">
<t>Any border. NO.</t>
<t>Find "up". NO. Manual configuration of the router
neighboring the ISP is required to set a default route. </t>
<t>Border method. MANUAL. </t>
</list></t>
<t>Handles change. YES. OSPFv3 normally handles router additions
and removals well, with link-state changes. It may not be able to
handle being moved from one existing segment to another.</t>
<t>No config. YES, but requires manual configuration for
security.</t>
<t>(null)</t>
<t>Multiple upstreams. YES, OSPFv3 can support multiple default
routes, and multiple specific routes.<list style="letters">
<t>Split up views. SOMEWHAT. OSPFv3 can certainly carry many
paths, including specific routes for a wireles home agent,
video cluster, or VPN concentrator. It cannot, by itself,
establish routing policies determining which hosts may use
those paths, so the upstream ISP may not have a return path
(or may have an asymmetric path). </t>
<t>(null)</t>
<t>Multiple PD. YES, OSPFv3 can route for multiple prefixes on
a link.</t>
<t>(null)</t>
<t>Failover. YES, autoconfigured OSPFv3 detects link state
change and reconverges in a reasonable amount of time.</t>
<t>Walled garden. SOMEWHAT. OSPFv3 can carry destination
routes, but cannot by itself support source-based routing.</t>
<t>(null)</t>
</list></t>
<t>Non-hierarchical addressing. YES.</t>
<t>Failover. YES. </t>
<t>Prevent loops. YES.</t>
<t>Lightweight. NO. One estimate of a common implementation is
50,000 lines of code.</t>
<t>Robust to MDUs. YES. Full LSAs are sent periodically, but they
are not onerus.</t>
<t>Wireless. YES.</t>
<t>Unintended joins. NO. Autoconfig OSPFv3 is not resilient
against unintended joins unless the recommendation to use
authentication hashes <xref target="OSPFV3-AUTH-TRAILER"></xref>
is followed, which requires manual configuration.</t>
</list> </t>
</section>
<section title="RIPng">
<t>Specified in <xref target="RFC2080"></xref>, but no document
specifying how it would be used in a Homenet environment has been
written.<list style="numbers">
<t>Reachability. YES, RIPng can detect reachability.</t>
<t>Border detection. NO. Any node which the router uses as a next
hop, but which is not speaking RIPng, may be assumed to be an
external border. However, the router will have to be manually
configured, or use another routing protocol, to establish a path
to that next hop; therefore auto-configured RIPng by itself does
not detect borders. <list style="letters">
<t>Any border. NO. Some ISPs use RIP (though rarely RIPng) to
communicate with customers.</t>
<t>Find "up". NO. Manual configuration of the router
neighboring the ISP is required to set a default route.</t>
<t>Border method. MANUAL.</t>
</list></t>
<t>Handles change. YES. RIPng normally handles router additions
and removals. It may not be able to handle being moved from one
existing segment to another.</t>
<t>No config. YES.</t>
<t>(null)</t>
<t>Multiple upstreams. NO, RIPng does not forward to multiple
paths for the same prefix.<list style="letters">
<t>Split up views. YES, RIPng can carry multiple paths,
including specific routes for a wireles home agent, video
cluster, or VPN concentrator. It cannot, by itself, establish
routing policies determining which hosts may use those paths,
so the upstream ISP may not have a return path (or may have an
asymmetric path). </t>
<t>(null)</t>
<t>Multiple PD. Yes, RIPng can support multiple prefixes on a
link.</t>
<t>(null)</t>
<t>Failover. Yes, RIPng can calculate a new path when one is
lost or withdrawn.</t>
<t>Walled garden. SOMEWHAT. RIPng can carry destination
routes, but cannot by itself support source-based routing.</t>
<t>(null)</t>
</list></t>
<t>Non-hierarchical addressing. YES.</t>
<t>Failover. YES.</t>
<t>Prevent loops. SOMEWHAT. RIPng uses the original RIP
count-to-infinity algorithm to prevent infinite loops; it works,
but is inefficient, especially in larger networks.</t>
<t>Lightweight. YES. </t>
<t>Robust to MDUs. YES. </t>
<t>Wireless. YES.</t>
<t>Unintended joins. NO. There is no authorization method; <xref
target="RFC2080"></xref> says to use the Authentication Header
built into IPv6, which would allow any RIPng host.</t>
</list></t>
</section>
<section title="UP-PIO">
<t>As documented in <xref target="UP-PIO"></xref>, this proposal would
overload Router Advertisements to apporximate a distance-vector
routing protocol.</t>
<t><list style="numbers">
<t>Reachability. YES, UP-PIO will find a path, but it may not be
the shortest path.</t>
<t>Border detection. YES. UP-PIO infers from DHCP-PD where the ISP
network is.<list style="letters">
<t>Any border. YES. A dedicated gateway, intended to run
between an 802.15.4 network and a Wi-Fi or Ethernet (etc.)
segment on a Homenet network, could be preconfigured to
establish itself as UP for that prefix.</t>
<t>Find "up". YES.</t>
<t>Border method. Assume that DHCP-PD indicates upstream ISP,
increment distance with RAs.</t>
</list></t>
<t>Handles change. YES, UP handles moves/adds/changes/deletions
exactly as well as Router Advertisements do.</t>
<t>No config. YES.</t>
<t>(null)</t>
<t>Multiple upstreams. YES, whatever information is included in
RAs is propagated.<list style="letters">
<t>Split up views. YES.</t>
<t>(null)</t>
<t>Multiple PD. YES. </t>
<t>(null)</t>
<t>Failover.</t>
<t>Walled garden. YES. </t>
<t>(null)</t>
</list></t>
<t>Non-hierarchical addressing. NO. UP depends on hierarchical
addressing.</t>
<t>Failover. YES, when RAs are no longer detected, an alternate
path is computed.</t>
<t>Prevent loops. Undefined; the protocol is still being defined.
It is expected to prevent loops as well as RIPng.</t>
<t>Lightweight. YES.</t>
<t>Robust to MDUs. YES.</t>
<t>Wireless. YES. </t>
<t>Unintended joins. NO. Even SEND would only authenticate, not
authorize.</t>
</list></t>
</section>
<section title="IS-IS">
<t>As defined in <xref target="RFC1195"></xref>, but no document
specifying how it would be used in a Homenet environment has been
written.</t>
<t><list style="numbers">
<t>Reachability. YES.</t>
<t>Border detection. NO. Any node which the router uses as a next
hop, but which is not speaking IS-IS, may be assumed to be an
external border. However, the router will have to be manually
configured, or use another routing protocol, to establish a path
to that next hop; therefore auto-configured IS-IS by itself does
not detect borders. <list style="letters">
<t>Any border. NO. </t>
<t>Find "up". NO. Manual configuration of the router
neighboring the ISP is required to set a default route.</t>
<t>Border method. MANUAL.</t>
</list></t>
<t>Handles change. YES.</t>
<t>No config. NO, IS-IS must be configured.</t>
<t>(null)</t>
<t>Multiple upstreams. YES.<list style="letters">
<t>Split up views. YES.</t>
<t>(null)</t>
<t>Multiple PD. YES.</t>
<t>(null)</t>
<t>Failover. YES. </t>
<t>Walled garden. YES.</t>
<t>(null)</t>
</list></t>
<t>Non-hierarchical addressing. YES.</t>
<t>Failover. YES. </t>
<t>Prevent loops. YES.</t>
<t>Lightweight. NO. </t>
<t>Robust to MDUs. YES.</t>
<t>Wireless. YES.</t>
<t>Unintended joins. SOMEWHAT, if <xref target="RFC5310"></xref>
is implemented, but that requires further manual
configuration.</t>
</list> </t>
</section>
<section title="MANEMO">
<t>No document exists describing this mechanism, though several people
have suggested it to the working group. Evaluation will have to be
undertaken by someone familiar with the mechanism.</t>
<t><list style="numbers">
<t>Reachability</t>
<t>Border detection<list style="letters">
<t>Any border.</t>
<t>Find "up".</t>
<t>Border method.</t>
</list></t>
<t>Handles change.</t>
<t>No config</t>
<t>(null)</t>
<t>Multiple upstreams.<list style="letters">
<t>Split up views.</t>
<t>(null)</t>
<t>Multiple PD.</t>
<t>(null)</t>
<t>Failover.</t>
<t>Walled garden.</t>
<t>(null)</t>
</list></t>
<t>Non-hierarchical addressing.</t>
<t>Failover.</t>
<t>Prevent loops.</t>
<t>Lightweight.</t>
<t>Robust to MDUs.</t>
<t>Wireless.</t>
<t>Unintended joins.</t>
</list></t>
</section>
<section title="RPL">
<t>As documented in <xref target="RPL"></xref>, but no document
specifying how it would be used in a Homenet environment has been
written.</t>
<t><list style="numbers">
<t>Reachability. YES.</t>
<t>Border detection. NO.<list style="letters">
<t>Any border. NO.</t>
<t>Find "up". NO.</t>
<t>Border method. NO.</t>
</list></t>
<t>Handles change. YES.</t>
<t>No config. YES?</t>
<t>(null)</t>
<t>Multiple upstreams. <list style="letters">
<t>Split up views.</t>
<t>(null)</t>
<t>Multiple PD.</t>
<t>(null)</t>
<t>Failover.</t>
<t>Walled garden.</t>
<t>(null)</t>
</list></t>
<t>Non-hierarchical addressing.</t>
<t>Failover.</t>
<t>Prevent loops.</t>
<t>Lightweight. YES.</t>
<t>Robust to MDUs.</t>
<t>Wireless.</t>
<t>Unintended joins.</t>
</list></t>
</section>
<section title="new section">
<t></t>
<texttable>
<ttcol>Requirement</ttcol>
<ttcol>OSPFv3</ttcol>
<ttcol>RIPng</ttcol>
<ttcol>UP PIO</ttcol>
<ttcol>IS-IS</ttcol>
<ttcol>MANEMO</ttcol>
<ttcol>RPL</ttcol>
<c>1.</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c></c>
<c></c>
<c>2.</c>
<c>NO</c>
<c>NO</c>
<c>YES</c>
<c>NO</c>
<c></c>
<c></c>
<c>2A.</c>
<c>NO</c>
<c>NO</c>
<c>YES</c>
<c>NO</c>
<c></c>
<c></c>
<c>2B.</c>
<c>NO</c>
<c>NO</c>
<c>YES</c>
<c>NO</c>
<c></c>
<c></c>
<c>2C.</c>
<c>MANUAL</c>
<c>MANUAL</c>
<c>PD</c>
<c>MANUAL</c>
<c></c>
<c></c>
<c>3.</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c></c>
<c></c>
<c>4.</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c>NO</c>
<c></c>
<c></c>
<c>5.</c>
<c>NA</c>
<c>NA</c>
<c>NA</c>
<c>NA</c>
<c></c>
<c></c>
<c>6.</c>
<c>YES</c>
<c>NO</c>
<c>YES</c>
<c>YES</c>
<c></c>
<c></c>
<c>6A.</c>
<c>SOME</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c></c>
<c></c>
<c>6B.</c>
<c>NA</c>
<c>NA</c>
<c>NA</c>
<c>NA</c>
<c></c>
<c></c>
<c>6C.</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c></c>
<c></c>
<c>6D.</c>
<c>NA</c>
<c>NA</c>
<c>NA</c>
<c>NA</c>
<c></c>
<c></c>
<c>6E.</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c></c>
<c></c>
<c>6F.</c>
<c>SOME</c>
<c>SOME</c>
<c>YES</c>
<c>YES</c>
<c></c>
<c></c>
<c>6G.</c>
<c>NA</c>
<c>NA</c>
<c>NA</c>
<c>NA</c>
<c></c>
<c></c>
<c>7.</c>
<c>YES</c>
<c>YES</c>
<c>NO</c>
<c>YES</c>
<c></c>
<c></c>
<c>8.</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c></c>
<c></c>
<c>9.</c>
<c>YES</c>
<c>SOME</c>
<c>TBD</c>
<c>YES</c>
<c></c>
<c></c>
<c>10.</c>
<c>NO</c>
<c>YES</c>
<c>YES</c>
<c>NO</c>
<c></c>
<c></c>
<c>11.</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c></c>
<c></c>
<c>12.</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c>YES</c>
<c></c>
<c></c>
<c>13.</c>
<c>NO</c>
<c>NO</c>
<c>NO</c>
<c>SOME</c>
<c></c>
<c></c>
</texttable>
</section>
</section>
<section title="Security Considerations">
<t>As an evaluation document, no security considerations are created.
The solution should be safe from route injection to perpetrate
man-in-the-middle attacks, especially in multi-dwelling or other
dense/mesh networks, but this may be a link requirement more than a
routing requirement.</t>
</section>
<section title="IANA Considerations">
<t>There are no IANA considerations or implications that arise from this
document.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Informative References">
<reference anchor="draft-howard-homenet-routing-requirements">
<front>
<title>Homenet Routing Requirements</title>
<author fullname="Lee Howard">
<organization></organization>
</author>
<date month="December" year="2011" />
</front>
</reference>
<reference anchor="draft-ietf-homenet-arch">
<front>
<title>Home Networking Architecture for IPv6</title>
<author fullname="Jari Arkko">
<organization></organization>
</author>
<author fullname="Tim Chown">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Jason Weil">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="Ole Troan">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date />
</front>
</reference>
<reference anchor="OSPFv3-autoconfig">
<front>
<title>draft-acee-ospf-ospfv3-autoconfig</title>
<author fullname="Acee Lindem">
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="RFC2080">
<front>
<title>RIPng for IPv6</title>
<author fullname="G. Malkin">
<organization></organization>
</author>
<author fullname="R. Minnear">
<organization>R. Minnear</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date />
</front>
</reference>
<reference anchor="UP-PIO">
<front>
<title>draft-howard-up-pio-00</title>
<author fullname="Lee Howard">
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="RFC1195">
<front>
<title>Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments</title>
<author fullname="R. Callon">
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="RPL">
<front>
<title>draft-ietf-roll-rpl-19</title>
<author>
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="OSPFV3-AUTH-TRAILER">
<front>
<title></title>
<author>
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="RFC5310">
<front>
<title>IS-IS Generic Cryptographic Authentication</title>
<author fullname="M. Bhatia">
<organization></organization>
</author>
<author fullname="V. Manral">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="T. Li">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="R. Atkinson">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="R. White">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author fullname="M. Fanto">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:44:24 |