One document matched: draft-baker-fun-routing-class-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the administrative value of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
administrative values. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="info" docName="draft-baker-fun-routing-class-00"
ipr="trust200902">
<front>
<title abbrev="">Routing a Traffic Class</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date year="2011" />
<area>Routing</area>
<workgroup></workgroup>
<abstract>
<t>This note addresses the concept of routing a traffic class. This has
many possible implementations, IGP and BGP, and link state as well as
distance vector. The fundamental impetus is the question raised in RFC
3704 and shim6 of exit routing, the question raised by Mike O'Dell of
source/destination routing, and the "fish" problem, raised in many
networks, in which distinct traffic classes that could conceivably use
the same route predictably use different routes. Instead of handling
these as "destination routing with a twist", the paper looks at the
matter systemically.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<note title="Requirements">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</note>
<!--
<?rfc needLines="10" ?> <texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "administrative values",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<?rfc needLines="5"?>
<section title="Introduction">
<t>This note addresses the concept of routing a traffic class. This has
many possible implementations, IGP and BGP, and link state as well as
distance vector. The fundamental impetus is the question raised in <xref
target="RFC3704"></xref> and shim6 of exit routing, the question raised
by Mike O'Dell of source/destination routing, and the "fish" problem,
raised in many networks, in which distinct traffic classes that could
conceivably use the same route predictably use different routes. Instead
of handling these as "destination routing with a twist", the paper looks
at the matter systemically.</t>
<section title="Scope">
<t>The question of implementation of IPv4 or IPv6 routes is moot; the
algorithms discussed here can be used for either. Examples, however,
will be drawn from <xref target="RFC2460">IPv6</xref> and will presume
its <xref target="RFC4291">addressing architecture</xref>.</t>
</section>
<section title="Structure of the paper">
<t>The paper looks first at the fundamental concept in <xref
target="fundamental"></xref>. It then goes on to imagine an <xref
target="RFC5308">IS-IS-like</xref> <xref target="RFC6119"></xref>
implementation. Unfortunately, this really can't be implemented in
IS-IS by adding a TLV, which is our usual approach, due to the changed
concept of a metric. However, given the changed concepts of a metric
and a TLV, it shows how the same exchange and calculation algorithms
can be used to build such a routing protocol. It also looks at a <xref
target="RFC2080">RIP-like</xref> algorithm that includes a sequence
number (derived from <xref target="RFC3561">AODV</xref>) to simplify
count-to-infinity-related problems. It stops short of a BGP
implementation, although one modeled on the distance vector model
would make sense.</t>
</section>
</section>
<?rfc needLines="5"?>
<section anchor="fundamental"
title="The fundamental concept of routing a class">
<t>This section introduces the fundamental concepts involved in routing
a traffic class. These include the definitions of <list style="symbols">
<t>a "traffic class", which is a set-theoretic definition - all
traffic matching a constraint,</t>
<t>a "metric", which is an administrative number applied to a class
of traffic crossing an interface, and</t>
<t>a "route announcement", which is the accumulation of information
regarding the routing of a traffic class as modified by various
metrics en route.</t>
</list></t>
<t>In addition, it describes the fundamental algorithm applied in
modifying a route announced by a predecessor node using a metric for
announcement on the interface implied.</t>
<?rfc needLines="5"?>
<section anchor="class" title="Define: "traffic class"">
<t>A "class" of traffic, in any routing protocol, is the selector that
is used to identify a traffic stream for the purpose of routing. For
traditional internet routing protocols like RIP, OSPF, IS-IS, EIGRP,
or BGP, a "traffic class" is "the traffic destined to a stated
prefix". In the context of this design, a traffic class is the traffic
that goes <list style="symbols">
<t>to a destination prefix, which may be a default route (::/0), a
host route (any /128 prefix), or anything in between,</t>
<t>from a source prefix, which may be a default route (::/0), a
host route (any /128 prefix), or anything in between, and</t>
<t>using one of a set of <xref target="RFC2474">DSCP</xref>
values.</t>
</list></t>
<t>The set of DSCP values includes and "any DSCP". "Any DSCP" has the
obvious meaning: we are not really looking at the DSCP in traffic
classification.</t>
<t>A protocol could also identify a route as a "null route"; this is
like any other route, but specifically directs that traffic matching
the traffic class is to be dropped.</t>
<t>A traffic class is represented in this document as <list
style="empty">
<t>{destination, source, {list of DSCPs}|any|none}</t>
</list></t>
<t>Examples of common traffic classes include: <list style="hanging">
<t hangText="Standard Default Route:">{::/0, ::/0, any}</t>
<t hangText="Default Route using a source prefix">{::/0, source,
any}</t>
<t
hangText="Default route used only for a QoS Traffic Class:">{::/0,
::/0, {list of DSCPs}}</t>
</list></t>
<t>Examples of QoS traffic classes are found in the <xref
target="RFC4594">Configuration Guidelines for DiffServ Service
Classes</xref> and related documents <xref target="RFC5127"></xref>
and <xref target="RFC5865"></xref>.</t>
</section>
<section anchor="metric" title="Define: "metric"">
<t>A "metric" is an attribute of an interface, and associates a
traffic class with a administrative value used in comparison of
routes. In this document, it is represented as <list style="empty">
<t>{{destination, source, {DSCP}|any|none}, administrative
value}</t>
</list> and should be understood as "the metric for traffic from
source to destination using DSCP".</t>
<t>For example, if an interface is available to all VoIP traffic, one
of the metrics on an interface might be <list style="empty">
<t>{{::/0, ::/0, {EF}}, administrative value}</t>
</list></t>
</section>
<section anchor="route" title="Define: "route announcement"">
<t>A route announcement is identical to a metric in structure, but is
semantically different. Where a metric is an attribute of an
interface, a route is an entry in the route table calculated by the
routing protocol, and is used in making forwarding decisions.</t>
<t>The calculation of a route follows the following logic: <list
style="numbers">
<t>Inputs to the route calculation are a route announcement (which
may be derived from an interface metric in the case of local
routes, or received from a neighboring route for remote routes),
and a metric associated with an interface.</t>
<t>The source, destination, and set of DSCPs of the route
announcement and the metric are intersected to generate the
traffic class for the resulting route.</t>
<t>The resulting route's administrative value is the sum of the
original route's administrative value and the interface's
administrative value.</t>
</list></t>
<t>For example, in <xref target="example1"></xref>, if the prefix
allocated by ISP-1 to a network is 2001:db8:1::/48 and the prefix
allocated by ISP-2 to the network is 2001:db8:2::/48, the exit routers
for the network might advertise into the network the default routes
<list style="symbols">
<t>{{2000::/3, 2001:db8:1::/48, any}, 1} ("unicast traffic using
source addresses in 2001:db8:1::/48 for any application"), and</t>
<t>{{::/0, 2001:db8:2::/48, any}, 2} ("all traffic using source
addresses in 2001:db8:2::/48 for any application").</t>
</list></t>
<figure anchor="example1" title="Simple multihomed network">
<artwork align="center"><![CDATA[
\ / \ /
`. ISP-1 ,' `. ISP-2 ,'
'--. _.-' '--. _.-'
`---+--'' `--+---''
| |
+--+---+ +--+---+
| Exit | | Exit |
|Router| |Router|
+---+--+ +---+--+
------+------------+- -+-------------+-----
+-+----+-+
|Interior|
| Router |
+---+----+
-------+--------]]></artwork>
</figure>
<t>One edge case is the case in which a route intersected with the
available metrics yields the null set. In such a case, the resulting
route cannot be used as no traffic matches it.</t>
<t>If an interior distance vector router in the network receives <list
style="empty">
<t>{{2000::/3, 2001:db8:1::/48, any}, 1} and</t>
<t>{{::/0, 2001:db8:2::/48, any}, 2}</t>
</list></t>
<t>from its upstream router, and on a given interface has a metric
<list style="empty">
<t>{{::/0, ::/0, {EF}}, 5} ("any VoIP traffic"),</t>
</list></t>
<t>it would validly infer the routes <list style="empty">
<t>{{2000::/3, 2001:db8:1::/48, {EF}}, 6} ("unicast VoIP traffic
using source addresses in 2001:db8:1::/48") and</t>
<t>{{::/0, 2001:db8:2::/48, {EF}}, 7} ("all VoIP traffic using
source addresses in 2001:db8:2::/48").</t>
</list></t>
<t>It would install the routes it received into its own route table,
and advertise the calculated routes to neighboring routers.</t>
<t>Note that there is no question of a unicast RPF or other forms of
<xref target="RFC2827"> Ingress Filtering</xref> required in such a
network. If a host spoofs a source address in another routing domain
and sends a datagram upstream, there is no route in the network "from"
that routing domain, and the router has no idea what to do with it. In
such cases the router would silently drop the traffic (it might be
nice to respond with an ICMP, but to whom?); it should of course
maintain appropriate counters and/or logs. Similarly, since traffic is
routed according to both its source and destination addresses, traffic
using a source address in 2001:db8:2::/48 would have no chance of
existing to ISP-1. It is still possible for traffic from outside to
come in, however, as such routes would have a source prefix of ::/0 or
2000::/3.</t>
</section>
<section anchor="precedence" title="Route Precedence">
<t>Precedence in selection of routes is based on intersection, and
follows the rule "most specific first". This is a generalization of
the "longest match first" rule used in destination routing. That may
require, in generating the Forwarding Information Base (FIB) from the
Routing Information Base (RIB), that we calculate the least
intersection of two route announcements.</t>
<t>In calculating routes, either one route's traffic class is a subset
of another's, or they mutually incompatible. If one is a subset of the
other, we consider the superset to be "less specific" and the subset
to be "more specific"; the most specific matching traffic class rules.
If the most specific option is in fact multiple traffic classes none
of which are subsets of the others, we calculate the intersections of
those routes for the purpose of comparison, and apply the rule to the
resulting route announcements.</t>
<t>For example, consider the two routes <list style="empty">
<t>{{2000::/3, ::/0, any}, 1} and</t>
<t>{{::/0, 2000::/3, any}, 5}.</t>
</list></t>
<t>They are not comparable because neither is a subset of the other.
We therefore calculate the intersection, which is a choice between
<list style="empty">
<t>{{2000::/3, 2000::/3, any}, 1} and</t>
<t>{{2000::/3, 2000::/3, any}, 5}.</t>
</list></t>
<t>Given that choice, the metric clearly selects {{2000::/3, 2000::/3,
any}, 1}. So we install in the RIB the three routes <list
style="empty">
<t>{{2000::/3, 2000::/3, any}, 1},</t>
<t>{{2000::/3, ::/0, any}, 1}, and</t>
<t>{{::/0, 2000::/3, any}, 5}.</t>
</list></t>
<t>The first is used by unicast traffic, as it is the most specific
that matches traffic from and to addresses in 2000::/3. The second is
used, for example, with traffic that is from addresses whose most
significant three bits are not 001 and to an address in 2000::/3. The
third is used for traffic that is to addresses whose most significant
three bits are not 001 but are from addresses in 2000::/3.</t>
</section>
</section>
<section anchor="dv" title="Sketch of a distance vector implementation">
<t>A distance vector implementation would operate much as described in
<xref target="fundamental"></xref>. In addition, however, we might take
advantage of an algorithm used in <xref target="RFC3561">AODV</xref>) to
simplify count-to-infinity-related problems.</t>
<t>To this end, we use the mechanisms and algorithms of <xref
target="RFC2080"></xref> with certain modifications.</t>
<t>A Route Table Entry (RTE), in this model, might be structured as in
<xref target="rte"></xref>.</t>
<figure anchor="rte" title="Route Table Entry">
<artwork align="center"><![CDATA[ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| route tag (2) |A|N| flags | metric (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Announcement sequence number (4) |
+---------------------------------------------------------------+
| |
~ IPv6 originator address (16) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dest prefix len|source prf len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IPv6 destination prefix (up to 16) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IPv6 source prefix (up to 16) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Traffic Class DSCP (64 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The fields are: <list style="hanging">
<t hangText="Route Tag:">The Route Tag is as defined in <xref
target="RFC2080"></xref>.</t>
<t hangText="A:">If 1, any DSCP applies, and the IPv6 Traffic Class
DSCP mask is absent. If 0, the IPv6 Traffic Class DSCP is
present.</t>
<t hangText="N:">if 1, a null route; traffic in this traffic class
and not in more explicit match SHOULD be dropped.</t>
<t hangText="flags:">unspecified in this version of the
specification. Set to 0 on transmission and ignored on receipt.
Future versions may specify additional flags.</t>
<t hangText="Metric:">The Metric is as defined in <xref
target="RFC2080"></xref>.</t>
<t hangText="Announcement sequence number:">0..FFFFFFFF, follows the
rules for a sequence number specified in <xref
target="RFC3561"></xref>.</t>
<t hangText="IPv6 originator address:">One of the global addresses
of the router originating this RTE, presumably the one used on the
relevant interface, which is in control of the sequence number. See
<xref target="RFC3561"></xref> for considerations and
algorithms.</t>
<t hangText="Destination Prefix Length:">0..128</t>
<t hangText="Source Prefix Length:">0..128</t>
<t hangText="IPv6 destination prefix:">The significant bits of the
prefix in question. Occupies ceiling(destination prefix length/8)
bytes.</t>
<t hangText="IPv6 source prefix:">The significant bits of the prefix
in question. Occupies ceiling(source prefix length/8) bytes.</t>
<t hangText="IPv6 Traffic Class DSCP:">if A=0, not present; if A=0,
the most significant bit is numbered 0, and indicates that the
traffic class includes traffic with a DSCP of 000000; if A=1, not
present.</t>
</list></t>
<t>Distribution and calculation of routes follows <xref
target="RFC2080"></xref>, including split horizon (an announcement
received from a router on the interface should not be reannounced to the
same router). and poison reverse (which should be used on triggered
updates but not regular announcements).</t>
<t>Elimination of stale routing information of routes follows the
algorithm with the sequence number specified in <xref
target="RFC3561"></xref>.</t>
<t>Intersection of route announcements with interface metric data is as
described in <xref target="fundamental"></xref>.</t>
</section>
<section anchor="spf" title="Sketch of a link state implementation">
<t>A link state (SPF) implementation would also operate much as
described in <xref target="fundamental"></xref>, although the algorithm
operates in memory as opposed to being distributed.</t>
<t>To this end, we use the mechanisms and algorithms of <xref
target="RFC5308"></xref> with certain modifications.</t>
<t>IS-IS structures its network as a lattice of routers that lead one to
sets of hosts identified by "TLVs". A TLV, in this model, might be
structured as in <xref target="TLV"></xref>.</t>
<figure anchor="TLV" title="Link State Advertisement TLV">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = ??? | Length | Metric .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. Metric |U|X|S| Reserve | TLV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-TLV Len(*) | Sub-TLVs(*) ...
* - if present
TLV or sub-TLV format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dest prefix len|source prf len |A|N|flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IPv6 destination prefix (up to 16) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ IPv6 source prefix (up to 16) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Traffic Class DSCP (64 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The fields are: <list style="hanging">
<t hangText="U:">up/down bit</t>
<t hangText="X:">external original bit</t>
<t hangText="S:">subtlv present bit</t>
<t hangText="A:">If 1, any DSCP applies, and the IPv6 Traffic Class
DSCP mask is absent. If 0, the IPv6 Traffic Class DSCP is
present.</t>
<t hangText="N:">if 1, a null route; traffic in this traffic class
and not in more explicit match SHOULD be dropped.</t>
<t hangText="flags:">unspecified in this version of the
specification. Set to 0 on transmission and ignored on receipt.
Future versions may specify additional flags.</t>
<t hangText="Destination Prefix Length:">0..128</t>
<t hangText="Source Prefix Length:">0..128</t>
<t hangText="IPv6 destination prefix:">The significant bits of the
prefix in question. Occupies ceiling(destination prefix length/8)
bytes.</t>
<t hangText="IPv6 source prefix:">The significant bits of the prefix
in question. Occupies ceiling(source prefix length/8) bytes.</t>
<t hangText="IPv6 Traffic Class DSCP:">if A=0, not present; if A=0,
the most significant bit is numbered 0, and indicates that the
traffic class includes traffic with a DSCP of 000000; if A=1, not
present.</t>
</list></t>
<t>Distribution and calculation of routes follows <xref
target="RFC5308"></xref>.</t>
<t>Intersection of route announcements with interface metric data is as
described in <xref target="fundamental"></xref>.</t>
</section>
<?rfc needLines="5"?>
<section anchor="IANA" title="IANA Considerations">
<t>At this point, this memo asks the IANA for no new parameters and
gives the IANA no instructions. As development progresses, that might
change.</t>
</section>
<?rfc needLines="5"?>
<section anchor="Security" title="Security Considerations">
<t>Security issues in routing protocols such as these are the same as in
other distance vector and link state routing protocols, and need to be
mitigated in the same ways. Since this paper looks primarily at the
algorithms for route calculation, those issues are largely ignored. If a
protocol such as described in <xref target="dv"></xref> or <xref
target="spf"></xref> is implemented, however, care must be taken to
ensure the integrity of communications between routers and their mutual
authentication.</t>
</section>
<?rfc needLines="5"?>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Dana Blair reviewed the initial version of the draft.</t>
</section>
<?rfc needLines="5"?>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">Sat Mar 26 12:25:46 CET 2011</t>
</list></t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<?rfc needLines="5"?>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.4291" ?>
</references>
<?rfc needLines="5"?>
<references title="Informative References">
<?rfc include="reference.RFC.2080" ?>
<?rfc include="reference.RFC.2474" ?>
<?rfc include="reference.RFC.2827" ?>
<?rfc include="reference.RFC.3561" ?>
<?rfc include="reference.RFC.3704" ?>
<?rfc include="reference.RFC.4594" ?>
<?rfc include="reference.RFC.5127" ?>
<?rfc include="reference.RFC.5308" ?>
<?rfc include="reference.RFC.5865" ?>
<?rfc include="reference.RFC.6119" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:25:27 |