As per Relevance of the word encapsulation, we have this rfc below:
Network Working Group D.
Request for Comments: 2667
Category: Standards Track August 1999
IP Tunnel
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
1.
This memo defines a Management Information Base (MIB) for use
network management protocols in the Internet community.
particular, it describes managed objects used for managing tunnels
any type over IPv4 networks. Extension MIBs may be designed
managing protocol-specific objects. Likewise, extension MIBs may
designed for managing security-specific objects. This MIB does
support tunnels over non-IPv4 networks (including IPv6 networks).
Management of such tunnels may be supported by other MIBs
Table of
1 Abstract ...................................................... 1
2 Introduction .................................................. 2
3 The SNMP Network Management Framework ......................... 2
4 Overview ...................................................... 3
4.1 Relationship to the Interfaces MIB .......................... 3
4.1.1 Layering Model ............................................ 3
4.1.2 ifRcvAddressTable ......................................... 4
4.1.3 ifEntry ................................................... 4
5 Definitions ................................................... 4
6 Security Considerations ...................................... 12
7 Acknowledgements ............................................. 12
8 Author's Address ............................................. 12
9 References ................................................... 13
10 Intellectual Property Notice ................................. 15
11 Full Copyright Statement ..................................... 16
Thaler Standards Track [Page 1]
RFC 2667 IP Tunnel MIB August 1999
2.
Over the past several years, there have been a number of "tunneling
protocols specified by the IETF (see [28] for an early discussion
the model and examples). This document describes a
Information Base (MIB) used for managing tunnels of any type
IPv4 networks, including GRE [16,17], IP-in-IP [18],
Encapsulation [19], L2TP [20], PPTP [21], L2F [25], UDP (e.g., [26]),
ATMP [22], and IPv6-in-IPv4 [27] tunnels
Extension MIBs may be designed for managing protocol-
objects. Likewise, extension MIBs may be designed for
security-specific objects (e.g., IPSEC [24]), and traffic
[29] objects. Finally, this MIB does not support tunnels over non
IPv4 networks (including IPv6 networks). Management of such
may be supported by other MIBs
3. The SNMP Network Management
The SNMP Management Framework presently consists of five
components
o An overall architecture, described in RFC 2571 [1].
o Mechanisms for describing and naming objects and events for
purpose of management. The first version of this Structure
Management Information (SMI) is called SMIv1 and described
STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].
second version, called SMIv2, is described in STD 58, RFC 2578
[5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7].
o Message protocols for transferring management information.
first version of the SNMP message protocol is called SNMPv1
described in STD 15, RFC 1157 [8]. A second version of the
message protocol, which is not an Internet standards
protocol, is called SNMPv2c and described in RFC 1901 [9]
RFC 1906 [10]. The third version of the message protocol
called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11]
RFC 2574 [12].
o Protocol operations for accessing management information.
first set of protocol operations and associated PDU formats
described in STD 15, RFC 1157 [8]. A second set of
operations and associated PDU formats is described in RFC 1905
[13].
Thaler Standards Track [Page 2]
RFC 2667 IP Tunnel MIB August 1999
o A set of fundamental applications described in RFC 2573 [14]
the view-based access control mechanism described in RFC 2575
[15].
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the mechanisms defined in the SMI
This memo specifies a MIB module that is compliant to the SMIv2.
MIB conforming to the SMIv1 can be produced through the
translations. The resulting translated MIB must be
equivalent, except where objects or events are omitted because
translation is possible (use of Counter64). Some machine
information in SMIv2 will be converted into textual descriptions
SMIv1 during the translation process. However, this loss of
readable information is not considered to change the semantics of
MIB
4.
This MIB module contains two tables
o the Tunnel Interface Table, containing information on
tunnels known to a router;
o the Tunnel Config Table, which can be used for dynamic
of tunnels, and also provides a mapping from endpoint
to the current interface index value
4.1. Relationship to the Interfaces
This section clarifies the relationship of this MIB to the
MIB [23]. Several areas of correlation are addressed in
following subsections. The implementor is referred to the
MIB document in order to understand the general intent of
areas
4.1.1. Layering
Each logical interface (physical or virtual) has an ifEntry in
Interfaces MIB [23]. Tunnels are handled by creating a
interface (ifEntry) for each tunnel. These are then correlated,
the ifStack table of the Interfaces MIB, to those interfaces on
the local IPv4 addresses of the tunnels are configured. The
model, therefore, looks something like this (for example):
Thaler Standards Track [Page 3]
RFC 2667 IP Tunnel MIB August 1999
| | | | | |
+--+ +---+ +--+ +---+ | |
|IP-in-IP| | GRE | | |
| tunnel | | tunnel | | |
+--+ +---+ +--+ +---+ | |
| | | | | | <== attachment to
+--+ +---------+ +----------+ +--+ interfaces, to be
| Physical interface | by ifStack
+--------------------------------+
4.1.2.
The ifRcvAddressTable usage is defined in the MIBs defining
encapsulation below the network layer. For example, if IP-in-
encapsulation is being used, the ifRcvAddressTable is defined by IP
in-IP
4.1.3.
IfEntries are defined in the MIBs defining the encapsulation
the network layer. For example, if IP-in-IP encapsulation [20]
being used, the ifEntry is defined by IP-in-IP
The ifType of a tunnel should be set to "tunnel" (131). An entry
the IP Tunnel MIB will exist for every ifEntry with this ifType.
implementation of the IP Tunnel MIB may allow ifEntries to be
via the tunnelConfigTable. Creating a tunnel will also add an
in the ifTable and in the tunnelIfTable, and deleting a tunnel
likewise delete the entry in the ifTable and the tunnelIfTable
The use of two different tables in this MIB was an important
decision. Traditionally, ifIndex values are chosen by agents,
are permitted to change across restarts. Allowing row
directly in the Tunnel Interface Table, indexed by ifIndex,
complicate row creation and/or cause interoperability problems (
each agent had special restrictions on ifIndex). Instead, a
table is used which is indexed only by objects over which the
has control. Namely, these are the addresses of the tunnel
and the encapsulation protocol. Finally, an additional manager
chosen ID is used in the index to support protocols such as L2F
allow multiple tunnels between the same endpoints
Thaler Standards Track [Page 4]
RFC 2667 IP Tunnel MIB August 1999
5.
TUNNEL-MIB DEFINITIONS ::=
MODULE-IDENTITY, OBJECT-TYPE, transmission
Integer32, IpAddress FROM SNMPv2-
RowStatus FROM SNMPv2-
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-
ifIndex, InterfaceIndexOrZero FROM IF-MIB
tunnelMIB MODULE-
LAST-UPDATED "9908241200Z" -- August 24, 1999
ORGANIZATION "IETF Interfaces MIB Working Group
CONTACT-
" Dave
Microsoft
One Microsoft
Redmond, WA 98052-6399
EMail: dthaler@dthaler.microsoft.com
"The MIB module for management of IP Tunnels, independent
the specific encapsulation scheme in use."
REVISION "9908241200Z" -- August 24, 1999
"Initial version, published as RFC 2667."
::= { transmission 131 }
tunnelMIBObjects OBJECT IDENTIFIER ::= { tunnelMIB 1 }
tunnel OBJECT IDENTIFIER ::= { tunnelMIBObjects 1 }
-- the IP Tunnel MIB-
--
-- a collection of objects providing information
-- IP
tunnelIfTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"The (conceptual) table containing information on
tunnels."
::= { tunnel 1 }
tunnelIfEntry OBJECT-
SYNTAX
Thaler Standards Track [Page 5]
RFC 2667 IP Tunnel MIB August 1999
MAX-ACCESS not-
STATUS
"An entry (conceptual row) containing the information on
particular configured tunnel."
INDEX { ifIndex }
::= { tunnelIfTable 1 }
TunnelIfEntry ::= SEQUENCE {
tunnelIfLocalAddress IpAddress
tunnelIfRemoteAddress IpAddress
tunnelIfEncapsMethod INTEGER
tunnelIfHopLimit Integer32,
tunnelIfSecurity INTEGER
tunnelIfTOS Integer32
tunnelIfLocalAddress OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The address of the local endpoint of the tunnel (i.e.,
source address used in the outer IP header), or 0.0.0.0
unknown."
::= { tunnelIfEntry 1 }
tunnelIfRemoteAddress OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The address of the remote endpoint of the tunnel (i.e.,
destination address used in the outer IP header), or 0.0.0.0
if unknown."
::= { tunnelIfEntry 2 }
tunnelIfEncapsMethod OBJECT-
SYNTAX INTEGER {
other(1), -- none of the
direct(2), -- no intermediate
gre(3), -- GRE
minimal(4), -- Minimal
l2tp(5), -- L2TP
pptp(6), -- PPTP
l2f(7), -- L2F
udp(8), -- UDP
atmp(9) -- ATMP
Thaler Standards Track [Page 6]
RFC 2667 IP Tunnel MIB August 1999
}
MAX-ACCESS read-
STATUS
"The encapsulation method used by the tunnel. The
direct indicates that the packet is encapsulated
within a normal IPv4 header, with no intermediate header
and unicast to the remote tunnel endpoint (e.g., an RFC 2003
IP-in-IP tunnel, or an RFC 1933 IPv6-in-IPv4 tunnel).
value minimal indicates that a Minimal Forwarding
(RFC 2004) is inserted between the outer header and
payload packet. The value UDP indicates that the
packet is encapsulated within a normal UDP packet (e.g.,
1234). The remaining protocol-specific values indicate
a header of the protocol of that name is inserted
the outer header and the payload header."
::= { tunnelIfEntry 3 }
tunnelIfHopLimit OBJECT-
SYNTAX Integer32 (0..255)
MAX-ACCESS read-
STATUS
"The TTL to use in the outer IP header. A value of 0
indicates that the value is copied from the payload'
header."
::= { tunnelIfEntry 4 }
tunnelIfSecurity OBJECT-
SYNTAX INTEGER {
none(1), -- no
ipsec(2), -- IPSEC
other(3)
}
MAX-ACCESS read-
STATUS
"The method used by the tunnel to secure the outer
header. The value ipsec indicates that IPsec is
between the tunnel endpoints for authentication
encryption or both. More specific security-
information may be available in a MIB for the
protocol in use."
::= { tunnelIfEntry 5 }
tunnelIfTOS OBJECT-
SYNTAX Integer32 (-2..63)
MAX-ACCESS read-
Thaler Standards Track [Page 7]
RFC 2667 IP Tunnel MIB August 1999
STATUS
"The method used to set the high 6 bits of the TOS in
outer IP header. A value of -1 indicates that the bits
copied from the payload's header. A value of -2
that a traffic conditioner is invoked and more
may be available in a traffic conditioner MIB. A
between 0 and 63 inclusive indicates that the bit field
set to the indicated value."
::= { tunnelIfEntry 6 }
tunnelConfigTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
"The (conceptual) table containing information on
tunnels. This table can be used to map a set of
endpoints to the associated ifIndex value. It can also
used for row creation. Note that every row in
tunnelIfTable with a fixed destination address should have
corresponding row in the tunnelConfigTable, regardless
whether it was created via SNMP."
::= { tunnel 2 }
tunnelConfigEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"An entry (conceptual row) containing the information on
particular configured tunnel."
INDEX { tunnelConfigLocalAddress
tunnelConfigRemoteAddress
tunnelConfigEncapsMethod
tunnelConfigID }
::= { tunnelConfigTable 1 }
TunnelConfigEntry ::= SEQUENCE {
tunnelConfigLocalAddress IpAddress
tunnelConfigRemoteAddress IpAddress
tunnelConfigEncapsMethod INTEGER
tunnelConfigID Integer32,
tunnelConfigIfIndex InterfaceIndexOrZero
tunnelConfigStatus
tunnelConfigLocalAddress OBJECT-
Thaler Standards Track [Page 8]
RFC 2667 IP Tunnel MIB August 1999
SYNTAX
MAX-ACCESS not-
STATUS
"The address of the local endpoint of the tunnel, or 0.0.0.0
if the device is free to choose any of its addresses
tunnel establishment time."
::= { tunnelConfigEntry 1 }
tunnelConfigRemoteAddress OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
"The address of the remote endpoint of the tunnel."
::= { tunnelConfigEntry 2 }
tunnelConfigEncapsMethod OBJECT-
SYNTAX INTEGER {
other(1), -- none of the
direct(2), -- no intermediate
gre(3), -- GRE
minimal(4), -- Minimal
l2tp(5), -- L2TP
pptp(6), -- PPTP
l2f(7), -- L2F
udp(8), -- UDP
atmp(9)
}
MAX-ACCESS not-
STATUS
"The encapsulation method used by the tunnel."
::= { tunnelConfigEntry 3 }
tunnelConfigID OBJECT-
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-
STATUS
"An identifier used to distinguish between multiple
of the same encapsulation method, with the same endpoints
If the encapsulation protocol only allows one tunnel per
of endpoint addresses (such as for GRE or IP-in-IP),
value of this object is 1. For encapsulation methods (
as L2F) which allow multiple parallel tunnels, the
is responsible for choosing any ID which does not
with an existing row, such as choosing a random number."
Thaler Standards Track [Page 9]
RFC 2667 IP Tunnel MIB August 1999
::= { tunnelConfigEntry 4 }
tunnelConfigIfIndex OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"If the value of tunnelConfigStatus for this row is active
then this object contains the value of ifIndex
to the tunnel interface. A value of 0 is not legal in
active state, and means that the interface index has not
been assigned."
::= { tunnelConfigEntry 5 }
tunnelConfigStatus OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"The status of this row, by which new entries may
created, or old entries deleted from this table. The
need not support setting this object to createAndWait
notInService since there are no other writable objects
this table, and writable objects in rows of
tables such as the tunnelIfTable may be modified while
row is active
To create a row in this table for an encapsulation
which does not support multiple parallel tunnels with
same endpoints, the management station should simply use
tunnelConfigID of 1, and set tunnelConfigStatus
createAndGo. For encapsulation methods such as L2F
allow multiple parallel tunnels, the management station
select a pseudo-random number to use as the
and set tunnelConfigStatus to createAndGo. In the
that this ID is already in use and an inconsistentValue
returned in response to the set operation, the
station should simply select a new pseudo-random number
retry the operation
Creating a row in this table will cause an interface
to be assigned by the agent in an implementation-
manner, and corresponding rows will be instantiated in
ifTable and the tunnelIfTable. The status of this row
become active as soon as the agent assigns the
index, regardless of whether the interface is
up
Thaler Standards Track [Page 10]
RFC 2667 IP Tunnel MIB August 1999
Deleting a row in this table will likewise delete
corresponding row in the ifTable and in the tunnelIfTable."
::= { tunnelConfigEntry 6 }
-- conformance
OBJECT IDENTIFIER ::= { tunnelMIB 2 }
OBJECT IDENTIFIER ::= { tunnelMIBConformance 1 }
tunnelMIBGroups OBJECT IDENTIFIER ::= { tunnelMIBConformance 2 }
-- compliance
tunnelMIBCompliance MODULE-
STATUS
"The compliance statement for the IP Tunnel MIB."
MODULE -- this
MANDATORY-GROUPS { tunnelMIBBasicGroup }
OBJECT
MIN-ACCESS read-
"Write access is not required."
OBJECT
MIN-ACCESS read-
"Write access is not required."
OBJECT
MIN-ACCESS read-
"Write access is not required."
::= { tunnelMIBCompliances 1 }
-- units of
tunnelMIBBasicGroup OBJECT-
OBJECTS { tunnelIfLocalAddress, tunnelIfRemoteAddress
tunnelIfEncapsMethod, tunnelIfHopLimit, tunnelIfTOS
tunnelIfSecurity, tunnelConfigIfIndex, tunnelConfigStatus }
STATUS
"A collection of objects to support basic management of
Tunnels."
::= { tunnelMIBGroups 1 }
Thaler Standards Track [Page 11]
RFC 2667 IP Tunnel MIB August 1999
6. Security
This MIB contains readable objects whose values provide
related to IP tunnel interfaces. There are also a number of
that have a MAX-ACCESS clause of read-write and/or read-create,
as those which allow an administrator to dynamically
tunnels
While unauthorized access to the readable objects is
innocuous, unauthorized access to the write-able objects could
a denial of service, or could cause unauthorized creation and/
manipulation of tunnels. Hence, the support for SET operations in
non-secure environment without proper protection can have a
effect on network operations
SNMPv1 by itself is such an insecure environment. Even if
network itself is secure (for example by using IPSec [24]),
then, there is no control as to who on the secure network is
to access and SET (change/create/delete) the objects in this MIB
It is recommended that the implementers consider the
features as provided by the SNMPv3 framework. Specifically, the
of the User-based Security Model RFC 2574 [12] and the View-
Access Control Model RFC 2575 [15] is recommended
It is then a customer/user responsibility to ensure that the
entity giving access to this MIB, is properly configured to
access to those objects only to those principals (users) that
legitimate rights to access them
7.
This MIB module was updated based on feedback from the IETF'
Interfaces MIB (IF-MIB) and Point-to-Point Protocol
(PPPEXT) Working Groups
8. Author's
Dave
Microsoft
One Microsoft
Redmond, WA 98052-6399
Phone: +1 425 703 8835
EMail: dthaler@microsoft.
Thaler Standards Track [Page 12]
RFC 2667 IP Tunnel MIB August 1999
9.
[1] Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture
Describing SNMP Management Frameworks", RFC 2571, April 1999.
[2] Rose, M. and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based Internets", STD 16,
1155, May 1990.
[3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[4] Rose, M., "A Convention for Defining Traps for use with
SNMP", RFC 1215, March 1991.
[5] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure
Management Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "
Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "
Statements for SMIv2", STD 58, RFC 2580, April 1999.
[8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "
Network Management Protocol", STD 15, RFC 1157, May 1990.
[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser
"Introduction to Community-based SNMPv2", RFC 1901,
1996.
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "
Mappings for Version 2 of the Simple Network Management
(SNMPv2)", RFC 1906, January 1996.
[11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "
Processing and Dispatching for the Simple Network
Protocol (SNMP)", RFC 2572, April 1999.
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM
for version 3 of the Simple Network Management
(SNMPv3)", RFC 2574, April 1999.
[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "
Operations for Version 2 of the Simple Network
Protocol (SNMPv2)", RFC 1905, January 1996.
Thaler Standards Track [Page 13]
RFC 2667 IP Tunnel MIB August 1999
[14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications",
2573, April 1999.
[15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Control Model (VACM) for the Simple Network Management
(SNMP)", RFC 2575, April 1999.
[16] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
Encapsulation (GRE)", RFC 1701, October 1994.
[17] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
Encapsulation over IPv4 networks", RFC 1702, October 1994.
[18] Perkins, C., "IP Encapsulation within IP", RFC 2003,
1996.
[19] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[20] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
August 1999.
[21] Hamzeh, K., Pall, G., Verthein, W. Taarud, J., Little, W. and G
Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999.
[22] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP",
2107, February 1997.
[23] McCloghrie, K. and F. Kastenholz. "The Interfaces Group
using SMIv2", RFC 2233, November 1997.
[24] R. Atkinson, "Security architecture for the internet protocol",
RFC 2401, November 1998.
[25] Valencia, A., Littlewood, M. and T. Kolar. "Cisco Layer
Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[26] D. Provan, "Tunneling IPX Traffic through IP Networks",
1234, June 1991.
[27] Gilligan, R. and E. Nordmark. "Transition Mechanisms for IPv
Hosts and Routers", RFC 1933, April 1996.
[28] Woodburn, R. and D. Mills, "A Scheme for an
Encapsulation Protocol: Version 1", RFC 1241, July 1991.
Thaler Standards Track [Page 14]
RFC 2667 IP Tunnel MIB August 1999
[29] Nichols, K., Blake, S., Baker, F. and D. Black. "Definition
the Differentiated Services Field (DS Field) in the IPv4
IPv6 Headers", RFC 2474, December 1998.
10. Intellectual Property
The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed
pertain to the implementation or use of the technology described
this document or the extent to which any license under such
might or might not be available; neither does it represent that
has made any effort to identify any such rights. Information on
IETF's procedures with respect to rights in standards-track
standards-related documentation can be found in BCP-11. Copies
claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made
obtain a general license or permission for the use of
proprietary rights by implementers or users of this specification
be obtained from the IETF Secretariat."
The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other
rights which may cover technology that may be required to
this standard. Please address the information to the IETF
Director
Thaler Standards Track [Page 15]
RFC 2667 IP Tunnel MIB August 1999
11. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Thaler Standards Track [Page 16]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
