One document matched: draft-kompella-mpls-larp-03.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-kompella-mpls-larp-03" ipr="trust200902">
<front>
<title>Label Distribution Using ARP</title>
<author initials="K." surname="Kompella" fullname="Kireeti Kompella">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Avenue</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>kireeti.kompella@gmail.com</email>
</address>
</author>
<author initials="R." surname="Balaji" fullname="Balaji Rajagopalan">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>Prestige Electra, Exora Business Park</street>
<street>Marathahalli - Sarjapur Outer Ring Road</street>
<city>Bangalore</city>
<code>560103</code>
<country>India</country>
</postal>
<email>balajir@juniper.net</email>
</address>
</author>
<author initials="G." surname="Swallow" fullname="George Swallow">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>1414 Massachusetts Ave</street>
<city>Boxborough</city>
<code>01719</code>
<region>MA</region>
<country>US</country>
</postal>
<email>swallow@cisco.com</email>
</address>
</author>
<date year="2015"/>
<area>Routing</area>
<workgroup>MPLS WG</workgroup>
<keyword>MPLS</keyword>
<keyword>L-ARP</keyword>
<abstract>
<t>
This document describes extensions to the Address Resolution
Protocol to distribute MPLS labels for IPv4 and IPv6 host
addresses. Distribution of labels via ARP enables simple
plug-and-play operation of MPLS, which is a key goal of the MPLS
Fabric architecture.
</t>
</abstract>
<note title="Requirements Language">
<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"/>.
</t>
<t>
The term "server" will be used in this document to refer to an
ARP/L-ARP server; the term "host" will be used to refer to a
compute server or other device acting as an ARP/L-ARP client.
</t>
</note>
</front>
<middle>
<section title="Introduction" anchor='intro'>
<t>
This document describes extensions to the Address Resolution
Protocol (ARP) <xref target='RFC0826'/> to advertise label
bindings for IP host addresses. While there are
well-established protocols, such as LDP, RSVP and BGP, that
provide robust mechanisms for label distribution, these
protocols tend to be relatively complex, and often require
detailed configuration for proper operation. There are
situations where a simpler protocol may be more suitable from an
operational standpoint. An example is the case where an MPLS
Fabric is the underlay technology in a Data Centre; here, MPLS
tunnels originate from host machines. The host thus needs a
mechanism to acquire label bindings to participate in the MPLS
Fabric, but in a simple, plug-and-play manner. Existing
signaling/routing protocols do not always meet this need.
Labeled ARP (L-ARP) is a proposal to fill that gap.
</t>
<t>
[TODO-MPLS-FABRIC] describes the motivation for using MPLS as the
fabric technology.
</t>
<section title='Approach'>
<t>
ARP is a nearly ubiquitous protocol; every device with an
Ethernet interface, from hand-helds to hosts, have an
implementation of ARP. ARP is plug-and-play; ARP clients do
not need configuration to use ARP. That suggests that ARP may
be a good fit for devices that want to source and sink MPLS
tunnels, but do so in a zero-config, plug-and-play manner,
with minimal impact to their code.
</t>
<t>
The approach taken here is to create a minor variant of the
ARP protocol, labeled ARP (L-ARP), which is distinguished by a
new hardware type, MPLS-over-Ethernet. Regular (Ethernet) ARP
(E-ARP) and L-ARP can coexist; a device, as an ARP client, can
choose to send out an E-ARP or an L-ARP request, depending on
whether it needs Ethernet or MPLS connectivity. Another
device may choose to function as an E-ARP server and/or an
L-ARP server, depending on its ability to provide an
IP-to-Ethernet and/or IP-to-MPLS mapping.
</t>
</section>
</section>
<section title="Overview of Ethernet ARP">
<t>
In the most straightforward mode of operation <xref
target="RFC0826"/>, ARP queries are sent to resolve "directly
connected" IP addresses. The ARP query is broadcast, with the
Target Protocol Address field (see <xref target='larp-format'/>
for a description of the fields in an ARP message) carrying the
IP address of another node in the same subnet. All the nodes in
the LAN receive this ARP query. All the nodes, except the node
that owns the IP address, ignore the ARP query. The IP address
owner learns the MAC address of the sender from the Source
Hardware Address field in the ARP request, and unicasts an ARP
reply to the sender. The ARP reply carries the replying node's
MAC address in the Source Hardware Address field, thus enabling
two-way communication between the two nodes.
</t>
<t>
A variation of this scheme, known as "proxy ARP" <xref
target="RFC2002"/>, allows a node to respond to an ARP request
with its own MAC address, even when the responding node does not
own the requested IP address. Generally, the proxy ARP response
is generated by routers to attract traffic for prefixes they can
forward packets to. This scheme requires the host to send ARP
queries for the IP address the host is trying to reach, rather
than the IP address of the router. When there is more than one
router connected to a network, proxy ARP enables a host to
automatically select an exit router without running any routing
protocol to determine IP reachability. Unlike regular ARP, a
proxy ARP request can elicit multiple responses, e.g., when more
than one router has connectivity to the address being resolved.
The sender must be prepared to select one of the responding
routers.
</t>
<t>
Yet another variation of the ARP protocol, called 'Gratuitous
ARP' <xref target="RFC2002"/>, allows a node to update the ARP
cache of other nodes in an unsolicited fashion. Gratuitous ARP
is sent as either an ARP request or an ARP reply. In either
case, the Source Protocol Address and Target Protocol Address
contain the sender's address, and the Source Hardware Address is
set to the sender's hardware address. In case of a gratuitous
ARP reply, the Target Hardware Address is also set to the
sender's address.
</t>
</section>
<section title='L-ARP Protocol Operation'>
<t>
The L-ARP protocol builds on the proxy ARP model, and also
leverages gratuitous ARP model for asynchronous updates.
</t>
<t>
In this memo, we will refer to L-ARP clients (that make L-ARP
requests) and L-ARP servers (that send L-ARP responses). In
<xref target='Fig1'/>, H1, H2 and H3 are L-ARP clients, and T1,
T2 and T3 are L-ARP servers. T is a member of the MPLS Fabric
that may not be an L-ARP server. Within the MPLS Fabric, the
usual MPLS protocols (IGP, LDP, RSVP-TE) are run. Say H1, H2
and H3 want to establish MPLS tunnels to each other (for
example, they are using BGP MPLS VPNs as the overlay virtual
network technology). H1 might also want to talk to a member of
the MPLS Fabric, say T.
</t>
<figure anchor='Fig1'>
<artwork align='center'>
. . . . . .
. .
H1 --- T1 T4
\ . MPLS .
\ . .
\ . Fabric .
H2 --- T2 T3 --- H3
. .
. . . . . .
</artwork>
</figure>
<section title='Basic Operation'>
<t>
A node (say H1) that needs an MPLS tunnel to a destination
(say H3) broadcasts over all its interfaces an L-ARP query
with the Target Protocol Address set to H3. A node that has
reachability to H3 (such as T1 or T2) sends an L-ARP reply
with the Source Hardware Address set to a locally-allocated
MPLS label plus its Ethernet MAC address. After receiving one
or more L-ARP replies, H1 can select either T1 or T2 to send
MPLS packets that are destined to H3. As described later, the
L-ARP response may contain certain parameters that enable the
client to make an informed choice of the routers.
</t>
<t>
As with standard ARP, the validity of the MPLS label obtained
using L-ARP is time-bound. The client should periodically
resend its L-ARP requests to obtain the latest information,
and time out entries in its ARP cache if such an update is not
forthcoming. Once an L-ARP server has advertised a label
binding, it MUST NOT change the binding until expiry of the
binding's validity time.
</t>
<t>
The mechanism defined here is simplistic; see <xref target='ffs'/>.
</t>
</section>
<section title='Asynchronous operation'>
<t>
The preceding sections described a request-response based
model. In some cases, the L-ARP server may want to
asynchronously update its clients. L-ARP uses the gratuitous
ARP model <xref target="RFC2002"/> to "push" such changes.
</t>
<t>
In a pure "push" model, a device may send out updates for all
prefixes it knows about. This naive approach will not scale
well. This memo specifies a mode of operation that is
somewhere between "push" and "pull" model. An L-ARP server
does not advertise any binding for a prefix until at least one
L-ARP client expresses interest in that prefix (by initiating
an L-ARP query). As long as the server has at least one
interested client for a prefix, the server sends unsolicited
(aka gratuitous, though the term is less appropriate in this
context) L-ARP replies when a prefix's reachability changes.
The server will deem the client's interest in a prefix to have
ceased when it does not hear any L-ARP queries for some
configured timeout period.
</t>
</section>
<section title='Client-Server Synchronization'>
<t>
In an L-ARP reply, the server communicates several pieces of
information to the client: its hardware address, the MPLS
label, Entropy Label capability and metric. Since ARP is a
stateless protocol, it is possible that one of these changes
without the client knowing, which leads to a loss of
synchronization between the client and the server. This loss
of synchronization can have several bad effects
</t>
<t>
If the server's hardware address changes or the MPLS label is
repurposed by the server for a different purpose, then packets
may be sent to the wrong destination. The consequences can
range from suboptimally routed packets to dropped packets to
packets being delivered to the wrong customer, which may be a
security breach. This last may be the most troublesome
consequence of loss of synchronization.
</t>
<t>
If a destination transitions from entropy label capable to
entropy label incapable (an unlikely event) without the client
knowing, then packets encapsulated with entropy labels will be
dropped. A transition in the other direction is relatively
benign.
</t>
<t>
If the metric changes without the client knowing, packets may
be suboptimally routed. This may be the most benign
consequence of loss of synchronization.
</t>
</section>
<section title='Applicability'>
<t>
L-ARP can be used between a host and its Top-of-Rack switch
in a Data Center. L-ARP can also be used between a DSLAM and
its aggregation switch going to the B-RAS. More generally,
L-ARP can be used between an "access node" and its first hop
MPLS-enabled device in the context of Seamless MPLS
[reference]. In all these cases, L-ARP can handle the
presence of multiple connections between the access device and
its first hop devices.
</t>
<t>
ARP is not a routing protocol. The use of L-ARP should be
limited to cases where the L-ARP client has a small number of
one-hop connections to L-ARP servers. The presence of a
complex topology between the L-ARP client and server suggests
the use of a different protocol.
</t>
</section>
<section title='Backward Compatibility'>
<t>
Since L-ARP uses a new hardware type, it is backward
compatible with "regular" ARP. ARP servers and clients MUST
be able to send out, receive and process ARP messages based on
hardware type. They MAY choose to ignore requests and replies
of some hardware types; they MAY choose to log errors if they
encounter hardware types they do not recognize; however, they
MUST handle all hardware types gracefully. For hardware types
that they do understand, ARP servers and clients MUST handle
operation codes gracefully, processing those they understand,
and ignoring (and possibly logging) others.
</t>
</section>
</section>
<section title='For Future Study' anchor='ffs'>
<t>
The L-ARP specification is quite simple, and the goal is to keep
it that way. However, inevitably, there will be questions and
features that will be requested. Some of these are:
<list style='numbers'>
<t>
Keeping L-ARP clients and servers in sync. In particular,
dealing with:
<list style='letters'>
<t>
client and/or server restart
</t>
<t>
lost packets
</t>
<t>
timeouts
</t>
</list>
</t>
<t>
Withdrawing a response.
</t>
<t>
Dealing with scale.
</t>
<t>
If there are many servers, which one to pick?
</t>
<t>
How can a client make best use of underlying ECMP paths?
</t>
<t>
and probably many more.
</t>
</list>
In all of these, it is important to realize that, whenever
possible, a solution that places most of the burden on the
server rather than on the client is preferable.
</t>
</section>
<!--
<section title='Handling Server Restart'>
<t>
In the L-ARP reply message, the server includes an "instance
identifier". The server maintains a global "Instance
Identifier", which is a monotonically incrementing number.
Every time the server restarts or re-connects to a network, it
assigns a value to "instance identifier" that is larger than
the value used last time. The server inserts the "instance
identifier" in all the L-ARP replies that it sends. When the
client receives an L-ARP reply, it checks to see if it has
earlier received any label binding from the server that is
smaller than the current value advertised by the server. If
there are any such bindings, the client re-initiates unicast
L-ARP queries for each stale binding in its cache.
</t>
<t>
When a potential server receives a unicast L-ARP query for an
address for which it has no reachability, it must respond with
an L-ARP reply indicating that it has no reachability. This is
to allow quick re-synchronization between the client and server,
after the server restarts.
</t>
</section>
</section>
-->
<section title='L-ARP Message Format' anchor='larp-format'>
<figure anchor="L-ARP-Packet" title="L-ARP Packet Format"
suppress-title="false" align="left">
<artwork xml:space="preserve" align="left">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$hrd | ar$pro |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ar$hln | ar$pln | ar$op |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ar$sha (ar$hln octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ar$spa (ar$pln octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ar$tha (ar$hln octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ar$tpa (ar$pln octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ar$lst (variable...) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ar$att (variable...) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style='hanging' hangIndent='4'>
<t hangText='ar$hrd'>
Hardware Type: MPLS-over-Ethernet. The value of the field
used here is [HTYPE-MPLS]. To start with, we will use the
experimental value HW_EXP2 (256)
</t>
<t hangText='ar$pro'>
Protocol Type: IPv4/IPv6. The value of the field used here
is 0x0800 to resolve an IPv4 address and 0x86DD to resolve
an IPv6 address.
</t>
<t hangText='ar$hln'>
Hardware Length: 6.
</t>
<t hangText='ar$pln'>
Protocol Address Length: for an IPv4 address, the value is 4;
for an IPv6 address, it is 16.
</t>
<t hangText='ar$op '>
Operation Code: set to 1 for request, 2 for reply, and 10
for ARP-NAK. Other op codes may be used as needed.
</t>
<t hangText='ar$sha'>
Source Hardware Address: In an L-ARP message, Source
Hardware Address is the 6 octet sender's MAC address.
</t>
<t hangText='ar$spa'>
Source Protocol Address: In an L-ARP message, this field
carries the sender's IP address.
</t>
<t hangText='ar$tha'>
Target Hardware Address: In an L-ARP query message, Target
Hardware Address is the all-ones Broadcast MAC address; in
an L-ARP reply message, it is the client's MAC address.
</t>
<t hangText='ar$tpa'>
Target Protocol Address: In an L-ARP message, this field
carries the IP address for which the client is seeking an
MPLS label.
</t>
<t hangText='ar$lst'>
Label Stack: In an L-ARP request, this field is empty. In
an L-ARP reply, this field carries the MPLS label stack as
an ARP TLV in the format below.
</t>
<t hangText='ar$att'>
Attributes: In an L-ARP request, this field is empty. In
an L-ARP reply, this field carries attributes for the MPLS
label stack as an ARP TLV in the format below.
</t>
</list>
</t>
<t>
This document introduces the notion of ARP TLVs. These take the
form as in <xref target='arp-tlv'/>. <xref target='LS'/>
describes the format of Label Stack TLV carried in L-ARP. <xref
target='ATT'/> describes the format of Attributes TLV carried in
L-ARP.
</t>
<figure anchor="arp-tlv" title="ARP TLVs">
<artwork xml:space="preserve" align="left">
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 | Value (Length octets) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<postamble>
Type is the type of the TLV; Length is the length of the value
field in octets; Value is the value field.
</postamble>
</figure>
<figure anchor="LS" title="MPLS Label Stack Format">
<artwork xml:space="preserve" align="left">
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 | MPLS Label (20 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |E|Z|Z|Z| MPLS Label (20 bits) |E|Z|Z|Z|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style='hanging'>
<t hangText='Label Stack:'>
Type = TLV-LST; Length = n*3 octets, where n is the number
of labels. The Value field contains the MPLS label stack
for the client to use to get to the target. Each label is 3
octets. This field is valid only in an L-ARP reply message.
</t>
<t hangText='E-bit:'>
Entropy Label Capable: this flag indicates whether the
corresponding label in the label stack can be followd by an
Entropy Label. If this flag is set, the client has the
option of inserting ELI and EL as specified in <xref
target="RFC6790"/>. The client can choose not to insert
ELI/EL pair. If this flag is clear, the client must not
insert ELI/EL after the corresponding label.
</t>
<t hangText='Z'>
These bits are not used, and SHOULD be set to zero on sending
and ignored on receipt.
</t>
<!--
<t>
If "Address Valid" bit is set, then MPLS label, entropy capability,
metric, and instance identifier fields are valid.
</t>
<t>
In an L-ARP reply message, the Label field may or may not be
set. If the label is not set in a reply, indicated by setting
V-bit to zero, it means that the server is withdrawing the binding
for the address, or simply declaring its inability to reach the
requested destination.
</t>
<t>
If V-bit bit is not set, entropy capability, metric, and
instance identifier field are invalid.
</t>
<t>
E-bit: Entropy Capability
</t>
<t>
This field indicates whether the label stack of MPLS data packets
sent with the label in this advertisement can contain Entropy
Label or not. If this flag is set, the client has the option of
inserting ELI and EL as specified in <xref target="RFC6790"/>. The
client can choose not to insert ELI/EL pair, if it does not
support Entropy Labels, or the local policy does not permit the
client to insert ELI/EL. If this flag is clear, the client must
not insert ELI/EL into the label stack when sending packets with
the advertised L-ARP label.
</t>
<t>
Metric
</t>
<t>
The field represents the cost to reach the resolving address.
</t>
<t>
1) The source protocol address is set to any valid IP address the
server can reach
</t>
<t>
2) Address Valid field is set to 1 (and therefore all the related
fields are also populated)
</t>
-->
</list>
</t>
<figure anchor="ATT" title="Attribute TLV">
<artwork xml:space="preserve" align="left">
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 (4 octets) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style='hanging'>
<t hangText='Attributes TLV:'>
Type = TLV-ATT; Length = 4 octets. The Value field contains
the metric (typically, IGP distance) from the responder to
the destination (device with the requested IP address).
This field is valid only in an L-ARP reply message.
</t>
</list>
If other parameters are deemed useful in the ATT TLV, they will
be added as needed.
</t>
</section>
<section title='Security Considerations' anchor='sec-con'>
<t>
There are many possible attacks on ARP: ARP spoofing, ARP cache
poisoning and ARP poison routing, to name a few. These attacks
use gratuitous ARP as the underlying mechanism, a mechanism used
by L-ARP. Thus, these types of attacks are applicable to L-ARP.
Furthermore, ARP does not have built-in security mechanisms;
defenses rely on means external to the protocol.
</t>
<t>
It is well outside the scope of this document to present a
general solution to the ARP security problem. One simple answer
is to add a TLV that contains a digital signature of the
contents of the ARP message. This TLV would be defined for use
only in L-ARP messages, although in principle, other ARP
messages could use it as well. Such an approach would, of
course, need a review and approval by the Security Directorate.
If approved, the type of this TLV and its procedures would be
defined in this document. If some other technique is suggested,
the authors would be happy to include the relevant text in this
document, and refer to some other document for the full solution.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
IANA is requested to allocate a new ARP hardware type (from the
registry hrd) for HTYPE-MPLS.
</t>
<t>
IANA is also requested to create a new registry ARP-TLV ("tlv").
This is a registry of one octet numbers. Allocation policies: 0
is not to be allocated; the range 1-127 is Standards Action; the
values 128-251 are FCFS; and the values 252-255 are
Experimental.
</t>
<t>
Finally, IANA is requested to allocate two values in the ARP-TLV
registry, one for TLV-LST and another for TLV-ATT.
</t>
</section>
<section title='Acknowledgments'>
<t>
Many thanks to Shane Amante for his detailed comments and
suggestions. Many thanks to the team in Juniper prototyping
this work for their suggestions on making this variant workable
in the context of existing ARP implementations. Thanks too to
Luyuan Fang, Alex Semenyaka and Dmitry Afanasiev for their
comments and encouragement.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include='reference.RFC.0826'?>
<?rfc include='reference.RFC.2002'?>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.5226'?>
<?rfc include='reference.RFC.6790'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 20:46:28 |