As per Relevance of the word different, we have this rfc below:
Network Working Group D.
Request for Comments: 2983 EMC
Category: Informational October 2000
Differentiated Services and
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document considers the interaction of Differentiated
(diffserv) (RFC 2474, RFC 2475) with IP tunnels of various forms
The discussion of tunnels in the diffserv architecture (RFC 2475)
provides insufficient guidance to tunnel designers and implementers
This document describes two conceptual models for the interaction
diffserv with Internet Protocol (IP) tunnels and employs them
explore the resulting configurations and combinations
functionality. An important consideration is how and where it
appropriate to perform diffserv traffic conditioning in the
of tunnel encapsulation and decapsulation. A few simple
are also proposed that limit the complexity that tunnels
otherwise add to the diffserv traffic conditioning model.
considerations for IPSec tunnels limit the possible functionality
some circumstances
1. Conventions used in this
An IP tunnel encapsulates IP traffic in another IP header as
passes through the tunnel; the presence of these two IP headers is
defining characteristic of IP tunnels, although there may
additional headers inserted between the two IP headers. The inner
header is that of the original traffic; an outer IP header
attached and detached at tunnel endpoints. In general,
network nodes between tunnel endpoints operate solely on the outer
header, and hence diffserv-capable intermediate nodes access
modify only the DSCP field in the outer IP header. The
"tunnel" and "IP tunnel" are used interchangeably in this document
For simplicity, this document does not consider tunnels other than
tunnels (i.e., for which there is no encapsulating IP header),
Black Informational [Page 1]
RFC 2983 Diffserv and Tunnels October 2000
as MPLS paths and "tunnels" formed by encapsulation in layer 2 (link
headers, although the conceptual models and approach described
may be useful in understanding the interaction of diffserv with
tunnels
This analysis considers tunnels to be unidirectional; bi-
tunnels are considered to be composed of two unidirectional
carrying traffic in opposite directions between the same
endpoints. A tunnel consists of an ingress where traffic enters
tunnel and is encapsulated by the addition of the outer IP header,
egress where traffic exits the tunnel and is decapsulated by
removal of the outer IP header, and intermediate nodes through
tunneled traffic passes between the ingress and egress.
document does not make any assumptions about routing and
of tunnel traffic, and in particular assumes neither the presence
the absence of route pinning in any form
2. Diffserv and Tunnels
Tunnels range in complexity from simple IP-in-IP tunnels [RFC 2003]
to more complex multi-protocol tunnels, such as IP in PPP in L2TP
IPSec transport mode [RFC 1661, RFC 2401, RFC 2661]. The
general tunnel configuration is one in which the tunnel is not end
to-end, i.e., the ingress and egress nodes are not the source
destination nodes for traffic carried by the tunnel; such a
may carry traffic with multiple sources and destinations. If
ingress node is the end-to-end source of all traffic in the tunnel
the result is a simplified configuration to which much of
analysis and guidance in this document are applicable, and
if the egress node is the end-to-end destination
A primary concern for differentiated services is the use of
Differentiated Services Code Point (DSCP) in the IP header [RFC 2474,
RFC 2475]. The diffserv architecture permits intermediate nodes
examine and change the value of the DSCP, which may result in
DSCP value in the outer IP header being modified between
ingress and egress. When a tunnel is not end-to-end, there
circumstances in which it may be desirable to propagate the
and/or some of the information that it contains to the outer
header on ingress and/or back to inner IP header on egress.
current situation facing tunnel implementers is that [RFC 2475]
offers incomplete guidance. Guideline G.7 in Section 3 is
example, as some PHB specifications have followed it by
specifying the PHBs that may be used in the outer IP header
tunneled traffic. This is overly restrictive; for example, if
specification requires that the same PHB be used in both the
and outer IP headers, traffic conforming to that specification
be tunneled across domains or networks that do not support that PHB
Black Informational [Page 2]
RFC 2983 Diffserv and Tunnels October 2000
A more flexible approach that should be used instead is to
the behavioral properties of a PHB that are important to
when traffic is tunneled and allow the outer IP header to be
in any fashion that is sufficient to preserve those properties
This document proposes an approach in which traffic conditioning
performed in series with tunnel ingress or egress processing,
than in parallel. This approach does not create any additional
that transmit information across a tunnel endpoint, as all
information is contained in the DSCPs in the IP headers. The
architecture [RFC 2401] requires that this be the case to
security properties at the egress of IPSec tunnels, but this
also avoids complicating diffserv traffic conditioning blocks
introducing out-of-band inputs. A consequence of this approach
that the last sentence of Guideline G.7 in Section 3 of [RFC 2475]
becomes moot because there are no tunnel egress diffserv
that have access to both the inner and outer DSCPs
An additional advantage of this traffic conditioning approach is
it places no additional restrictions on the positioning of
domain boundaries with respect to traffic conditioning and
encapsulation/decapsulation components. An interesting class
configurations involves a diffserv domain boundary that
through (i.e., divides) a network node; such a boundary can be
to create a DMZ-like region between the domains that contains
tunnel encapsulation or decapsulation processing. Diffserv
conditioning is not appropriate for such a DMZ-like region,
traffic conditioning is part of the operation and management
diffserv domains
3. Conceptual Models for Diffserv
This analysis introduces two conceptual traffic conditioning
for IP tunnels based on an initial discussion that assumes a
diffserv-capable network. Configurations in which this is not
case are taken up in Section 3.2.
3.1 Conceptual Models for Fully DS-capable
The first conceptual model is a uniform model that views IP
as artifacts of the end to end path from a traffic
standpoint; tunnels may be necessary mechanisms to get traffic to
destination(s), but have no significant impact on
conditioning. In this model, any packet has exactly one DS
that is used for traffic conditioning at any point, namely the
Field in the outermost IP header; any others are ignored
Implementations of this model copy the DSCP value to the outer
header at encapsulation and copy the outer header's DSCP value to
Black Informational [Page 3]
RFC 2983 Diffserv and Tunnels October 2000
inner IP header at decapsulation. Use of this model allows
tunnels to be configured without regard to diffserv domain
because diffserv traffic conditioning functionality is not
by the presence of IP tunnels
The second conceptual model is a pipe model that views an IP
as hiding the nodes between its ingress and egress so that they
not participate fully in traffic conditioning. In this model,
tunnel egress node uses traffic conditioning information
from the tunnel ingress by the DSCP value in the inner header,
ignores (i.e., discards) the DSCP value in the outer header.
pipe model cannot completely hide traffic conditioning within
tunnel, as the effects of dropping and shaping at intermediate
nodes may be visible at the tunnel egress and beyond
The pipe model has traffic conditioning consequences when the
and egress nodes are in different diffserv domains. In such
situation, the egress node must perform traffic conditioning
ensure that the traffic exiting the tunnel has DSCP values
to the egress diffserv domain (see Section 6 of the
architecture [RFC 2475]). An inter-domain TCA (Traffic
Agreement) between the diffserv domains containing the tunnel
and egress nodes may be used to reduce or eliminate egress
conditioning. Complete elimination of egress traffic
requires that the diffserv domains at ingress and egress
compatible service provisioning policies for the tunneled traffic
support all of the PHB groups and DSCP values used for that
in a consistent fashion. Examples of this situation are provided
some virtual private network tunnels; it may be useful to view
tunnels as linking the diffserv domains at their endpoints into
diffserv region by making the tunnel endpoints virtually
even though they may be physically separated by intermediate
nodes
The pipe model is also appropriate for situations in which the
itself carries information through the tunnel. For example,
transit between two domains is obtained via a path that uses the
PHB [RFC 2598], the drop precedence information in the AF PHB
values [RFC 2597] will be lost unless something is done to
it; an IP tunnel is one possible preservation mechanism. A path
crosses one or more non-diffserv domains between its DS-
endpoints may experience a similar information loss phenomenon if
tunnel is not used due to the limited set of DSCP codepoints that
compatible with such domains
Black Informational [Page 4]
RFC 2983 Diffserv and Tunnels October 2000
3.2 Considerations for Partially DS-capable
If only the tunnel egress node is DS-capable, [RFC 2475] requires
egress node to perform any edge traffic conditioning needed by
diffserv domain for tunneled traffic entering from outside
domain. If the egress node would not otherwise be a DS edge node
one way to meet this requirement is to perform edge
conditioning at an appropriate upstream DS edge node within
tunnel, and copy the DSCP value from the outer IP header to the
IP header as part of tunnel decapsulation processing; this
the uniform model to the portion of the tunnel within the
node's diffserv domain. A second alternative is to discard the
DSCP value as part of decapsulation processing, reducing
resulting traffic conditioning problem and requirements to those
an ordinary DS ingress node. This applies the pipe model to
portion of the tunnel within the egress node's diffserv domain
hence the adjacent upstream node for DSCP marking purposes is
tunnel ingress node, rather than the immediately
intermediate tunnel node
If only the tunnel ingress node is DS-capable, [RFC 2475]
that traffic emerging from the tunnel be compatible with the
at the tunnel egress. If tunnel decapsulation processing
the outer header's DSCP value without changing the inner header'
DSCP value, the DS-capable tunnel ingress node is obligated to
the inner header's DSCP to a value compatible with the network at
tunnel egress. The value 0 (DSCP of 000000) is used for this
by a number of existing tunnel implementations. If the
network implements IP precedence as specified in [RFC 791], then
or all of the eight class selector DSCP codepoints defined in [
2474] may be usable. DSCP codepoints other than the class
are not generally suitable for this purpose, as correct
would usually require diffserv functionality at the DS-
tunnel egress node
4. Ingress
As described in Section 3 above, this analysis is based on
approach in which diffserv functionality and/or out-of-
communication paths are not placed in parallel with
encapsulation processing. This allows three possible locations
traffic conditioning with respect to tunnel encapsulation processing
as shown in the following diagram that depicts the flow of IP
through tunnel encapsulation
Black Informational [Page 5]
RFC 2983 Diffserv and Tunnels October 2000
+--------- [2 - Outer] -->>
/
/
>>---- [1 - Before] -------- Encapsulate ------ [3 - Inner] -->>
Traffic conditioning at [1 - Before] is logically separate from
tunnel, as it is not impacted by the presence of
encapsulation, and hence should be allowed by tunnel designs
specifications. Traffic conditioning at [2 - Outer] may
with tunnel protocols that are sensitive to packet reordering;
tunnels may need to limit the functionality at [2 - Outer]
discussed further in Section 5.1. In the absence of
sensitivity, no additional restrictions should be necessary,
traffic conditioning at [2 - Outer] may be responsible for
traffic to be compatible with the next diffserv domain that
tunneled traffic enters
In contrast, the [3 - Inner] location is difficult to utilize
traffic conditioning because it requires functionality that
inside the packet to operate on the inner IP header. This
impossible for IPSec tunnels and any other tunnels that are
or employ cryptographic integrity checks. Hence traffic
at [3 - Inner] can often only be performed as part of
encapsulation processing, complicating both the encapsulation
traffic conditioning implementations. In many cases, the
functionality can be achieved via a combination of
conditioners in the other two locations, both of which can
specified and implemented independently of tunnel encapsulation
An exception for which traffic conditioning functionality
necessary at [3 - Inner] occurs when the DS-incapable tunnel
discards the outer IP header as part of decapsulation processing,
hence the DSCP in the inner IP header must be compatible with
egress network. Setting the inner DSCP to 0 as part of
addresses most of these cases, and the class selector DCSP
values are also useful for this purpose, as they are valid
networks that support IP precedence [RFC 791].
The following table summarizes the achievable relationships among
before (B), outer (O), and inner (I) DSCP values and
corresponding locations of traffic conditioning logic
Black Informational [Page 6]
RFC 2983 Diffserv and Tunnels October 2000
Relationship Traffic Conditioning Location(s
------------ --------------------------------
B = I = O No traffic conditioning
B != I = O [1 - Before
B = I != O [2 - Outer
B = O != I Limited support as part of encapsulation
I can be set to 000000 or possibly one
the class selector code points
B != I != O Some combination of the above three scenarios
A combination of [1 - Before] and [2 - Outer] is applicable to
cases covered by the last two lines of the table, and may
preferable to deploying functionality at [3 - Inner].
conditioning may still be required for purposes such as rate
burst control even if DSCP values are not changed
4.1 Ingress DSCP Selection and
It may be necessary or desirable to limit the DS behavior
that utilize an IP tunnel that is sensitive to packet
within the tunnel. The diffserv architecture allows packets to
reordered when they belong to behavior aggregates among
reordering is permitted; for example, reordering is allowed
behavior aggregates marked with different Class Selector DSCPs [
2474]. IPSec [RFC 2401] and L2TP [RFC 2661] provide examples
tunnels that are sensitive to packet reordering. If IPSec's anti
replay support is configured, audit events are generated in
to packet reordering that exceeds certain levels, with the
events indicating potential security issues. L2TP can be
to restore the ingress ordering of packets at tunnel egress, not
undoing any differentiation based on reordering within the tunnel
but also negatively impacting the traffic (e.g., by
latency). The uniform model cannot be completely applied to
tunnels, as arbitrary mixing of traffic from different
aggregates can cause these undesirable interactions
The simplest method of avoiding undesirable interactions
reordering with reordering-sensitive tunnel protocols and features
not to employ the reordering-sensitive protocols or features,
this is often not desirable or even possible. When such protocols
features are used, interactions can be avoided by ensuring that
aggregated flows through the tunnel are marked at [2 - Outer]
constitute a single ordered aggregate (i.e., the PHBs used share
ordering constraint that prevents packets from being reordered).
Tunnel protocol specifications should indicate both whether and
what circumstances a tunnel should be restricted to a single
aggregate as well as the consequences of deviating from
restriction. For the IPSec and L2TP examples discussed above,
Black Informational [Page 7]
RFC 2983 Diffserv and Tunnels October 2000
specifications should restrict each tunnel to a single
aggregate when protocol features sensitive to reordering
configured, and may adopt the approach of restricting all tunnels
order to avoid unexpected consequences of changes in
features or composition of tunneled traffic.
implementations should not attempt to look within such tunnels
provide reordering-based differentiation to the
microflows. If reordering-based differentiation is desired
such tunnels, multiple parallel tunnels between the same
should be used. This enables reordering among packets in
tunnels to coexist with an absence of packet reordering within
individual tunnel. For IPSec and related security protocols,
is no cryptographic advantage to using a single tunnel for
ordered aggregates rather than multiple tunnels because any
analysis made possible by the use of multiple tunnels can also
performed based on the DSCPs in the outer headers of traffic in
single tunnel. In general, the additional resources required
support multiple tunnels (e.g., cryptographic contexts), and
impact of multiple tunnels on network management should be
in determining whether and where to deploy them
4.2 Tunnel
The behavioral characteristics of a tunnel are an
consideration in determining what traffic should utilize the tunnel
This involves the service provisioning policies of all
participating domains, not just the PHBs and DSCPs marked on
traffic at [2 - Outer]. For example, while it is in general a
idea to tunnel EF PHB traffic via a Default PHB tunnel, this can
acceptable if the EF traffic is the only traffic that utilizes
tunnel, and the tunnel is provisioned in a fashion adequate
preserve the behavioral characteristics required by the EF PHB
Service provisioning policies are responsible for
mismatches such as forwarding EF traffic via an
provisioned Default tunnel. When multiple parallel tunnels
different behavioral characteristics are available,
provisioning policies are responsible for determining which
should use which tunnels. Among the possibilities is a
version of the uniform tunnel model in which the inner DSCP value
used to select a tunnel that will forward the traffic using
behavioral aggregate that is compatible with the traffic's PHB
5. Egress
As described in Section 3 above, this analysis is based on
approach in which diffserv functionality and/or out-of-
communication paths are not placed in parallel with
Black Informational [Page 8]
RFC 2983 Diffserv and Tunnels October 2000
encapsulation processing. This allows three possible locations
traffic conditioners with respect to tunnel decapsulation processing
as shown in the following diagram that depicts the flow of IP
through tunnel decapsulation
>>----[5 - Outer]-------------+
\
\
>>----[4 - Inner] --------- Decapsulate ---- [6 - After] -->>
Traffic conditioning at [5 - Outer] and [6 - After] is
separate from the tunnel, as it is not impacted by the presence
tunnel decapsulation. Tunnel designs and specifications should
diffserv traffic conditioning at these locations. Such
can be viewed as independent of the tunnel, i.e., [5 - Outer]
traffic conditioning that takes place prior to tunnel egress,
[6 - After] is traffic conditioning that takes place after
decapsulation. An important exception is that the configuration of
tunnel (e.g., the absence of traffic conditioning at tunnel ingress
and/or the diffserv domains involved may require that all
exiting a tunnel pass through diffserv traffic conditioning
fulfill the diffserv edge node traffic conditioning
of the tunnel egress node. Tunnel designers are strongly
to include the ability to require that all traffic exiting a
pass through diffserv traffic conditioning in order to ensure
traffic exiting the node is compatible with the egress node'
diffserv domain
In contrast, the [4 - Inner] location is difficult to employ
traffic conditioning because it requires reaching inside the
to operate on the inner IP header. Unlike the [3 - Inner] case
encapsulation, there is no need for functionality to be performed
[4- Inner], as diffserv traffic conditioning can be appended to
tunnel decapsulation (i.e., performed at [6 - After]).
5.1 Egress DSCP
The elimination of parallel functionality and data paths
decapsulation causes a potential loss of information. As shown
the above diagram, decapsulation combines and reduces two DSCP
to one DSCP value, losing information in the most general case,
if arbitrary functionality is allowed. Beyond this,
arbitrary functionality poses a structural problem, namely that
DSCP value from the outer IP header would have to be presented as
out-of-band input to the traffic conditioning block at [6 - After],
complicating the traffic conditioning model
Black Informational [Page 9]
RFC 2983 Diffserv and Tunnels October 2000
To avoid such complications, the simpler approach of
selecting either the inner or outer DSCP value at decapsulation
recommended, leaving the full generality of traffic
functionality to be implemented at [5 - Outer] and/or [6 - After].
Tunnels should support static selection of one or the other
value at tunnel egress. The rationale for this approach is
only one of the two DSCP values contains useful information.
conceptual model for the tunnel provides a strong indication of
one contains useful information; the outer DSCP value
contains the useful information for tunnels based on the
model, and the inner DSCP value usually contains the
information for tunnels based on the pipe model. IPSec tunnels
usually based on the pipe model, and for security reasons
currently required to select the inner DSCP value; they should not
configured to select the outer DSCP value in the absence of
adequate security analysis of the resulting risks and implications
5.2 Egress DSCP Selection Case
As a sanity check on the egress DSCP selection approach
above, this subsection considers a situation in which a more
approach might be required. Statically choosing a single DSCP
may not work well when both DSCPs are carrying information that
relevant to traffic conditioning
As an example, consider a situation in which different AF groups [
2597] are used by the two domains at the tunnel endpoints, and
is an intermediate domain along the tunnel using RFC 791
precedences that is transited by setting the DSCP to zero.
situation is shown in the following IP header flow diagram where I
the tunnel ingress node, E is the tunnel egress node and the
lines are domain boundaries. The node at the left-hand vertical
sets the DSCP in the outer header to 0 in order to
compatibility with the middle domain
| |
+-----|-------------------|------+
/ | | \
>>-----------I-------|-------------------|--------E---------->>
| |
Ingress DS Domain RFC 791 Egress DS
IP
In this situation, the DS edge node for the egress domain (i.e.,
node at the right-hand vertical line) can select the appropriate
group (e.g., via an MF classifier), but cannot reconstruct the
precedence information that was removed from the outer header when
Black Informational [Page 10]
RFC 2983 Diffserv and Tunnels October 2000
transited the RFC 791 domain (although it can construct
information via metering and marking). The original drop
information is preserved in the inner IP header's DSCP, and could
combined at the tunnel egress with the AF class
communicated via the outer IP header's DSCP. The marginal benefit
being able to reuse the original drop precedence information
opposed to constructing new drop precedence markings does not
the additional complexity introduced into tunnel egress
conditioners by making both DSCP values available to
conditioning at [6 - After].
6. Diffserv and Protocol
A related issue involves protocol translators, including
employing the Stateless IP/ICMP Translation Algorithm [RFC 2765].
These translators are not tunnels because they do not add or remove
second IP header to/from packets (e.g., in contrast to IPv6 over IPv
tunnels [RFC 1933]) and hence do not raise concerns of
propagation between inner and outer IP headers. The
interaction between translators and diffserv is that the
boundary is likely to also be a diffserv domain boundary (e.g.,
IPv4 and IPv6 domains may have different policies for
conditioning and DSCP usage), and hence such translators should
the insertion of diffserv edge node processing (including
conditioning) both before and after the translation processing
7. Security
The security considerations for the diffserv architecture
in [RFC 2474, RFC 2475] apply when tunnels are present. One of
requirements is that a tunnel egress node in the interior of
diffserv domain is the DS ingress node for traffic exiting
tunnel, and is responsible for performing appropriate
conditioning. The primary security implication is that the
conditioning is responsible for dealing with theft- and denial-of
service threats posed to the diffserv domain by traffic exiting
the tunnel. The IPSec architecture [RFC 2401] places a
restriction on tunnel egress processing; the outer header is to
discarded unless the properties of the traffic conditioning to
applied are known and have been adequately analyzed for
vulnerabilities. This includes both the [5 - Outer] and [6 - After
traffic conditioning blocks on the tunnel egress node, if present
and may involve traffic conditioning performed by an upstream DS-
node that is the DS domain ingress node for the encapsulated
traffic
Black Informational [Page 11]
RFC 2983 Diffserv and Tunnels October 2000
8.
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791,
1981.
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC 1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms
IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC 2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for
Internet Protocol", RFC 2401, November 1998.
[RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black
"Definition of the Differentiated Services Field (
Field) in the IPv4 and IPv6 Headers", RFC 2474,
1998.
[RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z
and W. Weiss, "An Architecture for
Services", RFC 2475, December 1998.
[RFC 2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski
"Assured Forwarding PHB Group", RFC 2597. June 1999.
[RFC 2598] Jacobson, V., Nichols, K. and K. Poduri, "An
Forwarding PHB", RFC 2598, June 1999.
[RFC 2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G
and B. Palter. "Layer Two Tunneling Protocol "L2TP"",
2661, August 1999.
[RFC 2765] Nordmark, E., "Stateless IP/ICMP Translation
(SIIT)", RFC 2765, February 2000.
Black Informational [Page 12]
RFC 2983 Diffserv and Tunnels October 2000
9.
Some of this material is based on discussions with Brian Carpenter
and in particular his presentation on this topic to the diffserv
during the summer 1999 IETF meeting in Oslo. Credit is also due to
number of people working on tunnel specifications who have
limitations of the diffserv architecture [RFC 2475] in the area
tunnels. Their patience with the time it has taken to address
set of issues is greatly appreciated. Finally, this material
benefited from discussions within the diffserv WG, both in
and on the mailing list -- the contributions of participants in
discussions are gratefully acknowledged
10. Author's
David L.
EMC
42 South St
Hopkinton, MA 01748
Phone: +1 (508) 435-1000 x75140
EMail: black_david@emc.
Black Informational [Page 13]
RFC 2983 Diffserv and Tunnels October 2000
11. Full Copyright
Copyright (C) The Internet Society (2000). 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
Black Informational [Page 14]
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
