rfc2983.txt

RFC 的详细文档！

5.2 Egress DSCP Selection Case Study

   As a sanity check on the egress DSCP selection approach proposed
   above, this subsection considers a situation in which a more complex
   approach might be required.  Statically choosing a single DSCP value
   may not work well when both DSCPs are carrying information that is
   relevant to traffic conditioning.

   As an example, consider a situation in which different AF groups [RFC
   2597] are used by the two domains at the tunnel endpoints, and there
   is an intermediate domain along the tunnel using RFC 791 IP
   precedences that is transited by setting the DSCP to zero.  This
   situation is shown in the following IP header flow diagram where I is
   the tunnel ingress node, E is the tunnel egress node and the vertical
   lines are domain boundaries.  The node at the left-hand vertical line
   sets the DSCP in the outer header to 0 in order to obtain
   compatibility with the middle domain:

                        |                   |
                  +-----|-------------------|------+
                 /      |                   |       \
   >>-----------I-------|-------------------|--------E---------->>
                        |                   |
      Ingress DS Domain        RFC 791         Egress DS domain
                            IP Precedence
                                Domain

   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
   group (e.g., via an MF classifier), but cannot reconstruct the drop
   precedence information that was removed from the outer header when it



Black                        Informational                     [Page 10]

RFC 2983                  Diffserv and Tunnels              October 2000


   transited the RFC 791 domain (although it can construct new
   information via metering and marking).  The original drop precedence
   information is preserved in the inner IP header's DSCP, and could be
   combined at the tunnel egress with the AF class selection
   communicated via the outer IP header's DSCP.  The marginal benefit of
   being able to reuse the original drop precedence information as
   opposed to constructing new drop precedence markings does not justify
   the additional complexity introduced into tunnel egress traffic
   conditioners by making both DSCP values available to traffic
   conditioning at [6 - After].

6.  Diffserv and Protocol Translators

   A related issue involves protocol translators, including those
   employing the Stateless IP/ICMP Translation Algorithm [RFC 2765].
   These translators are not tunnels because they do not add or remove a
   second IP header to/from packets (e.g., in contrast to IPv6 over IPv4
   tunnels [RFC 1933]) and hence do not raise concerns of information
   propagation between inner and outer IP headers.  The primary
   interaction between translators and diffserv is that the translation
   boundary is likely to also be a diffserv domain boundary (e.g., the
   IPv4 and IPv6 domains may have different policies for traffic
   conditioning and DSCP usage), and hence such translators should allow
   the insertion of diffserv edge node processing (including traffic
   conditioning) both before and after the translation processing.

7. Security Considerations

   The security considerations for the diffserv architecture discussed
   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
   diffserv domain is the DS ingress node for traffic exiting the
   tunnel, and is responsible for performing appropriate traffic
   conditioning.  The primary security implication is that the traffic
   conditioning is responsible for dealing with theft- and denial-of-
   service threats posed to the diffserv domain by traffic exiting from
   the tunnel.  The IPSec architecture [RFC 2401] places a further
   restriction on tunnel egress processing; the outer header is to be
   discarded unless the properties of the traffic conditioning to be
   applied are known and have been adequately analyzed for security
   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-edge
   node that is the DS domain ingress node for the encapsulated tunneled
   traffic.






Black                        Informational                     [Page 11]

RFC 2983                  Diffserv and Tunnels              October 2000


8. References

   [RFC 791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              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 for
              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 the
              Internet Protocol", RFC 2401, November 1998.

   [RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474, December
              1998.

   [RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
              and W. Weiss, "An Architecture for Differentiated
              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 Expedited
              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"", RFC
              2661, August 1999.

   [RFC 2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
              (SIIT)", RFC 2765, February 2000.













Black                        Informational                     [Page 12]

RFC 2983                  Diffserv and Tunnels              October 2000


9. Acknowledgments

   Some of this material is based on discussions with Brian Carpenter,
   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 a
   number of people working on tunnel specifications who have discovered
   limitations of the diffserv architecture [RFC 2475] in the area of
   tunnels.  Their patience with the time it has taken to address this
   set of issues is greatly appreciated.  Finally, this material has
   benefited from discussions within the diffserv WG, both in meetings
   and on the mailing list -- the contributions of participants in those
   discussions are gratefully acknowledged.

10. Author's Address

   David L. Black
   EMC Corporation
   42 South St.
   Hopkinton, MA   01748

   Phone: [phone] x75140
   EMail: [e-mail]





























Black                        Informational                     [Page 13]

RFC 2983                  Diffserv and Tunnels              October 2000


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.



















Black                        Informational                     [Page 14]