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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/