rfc2983.txt

RFC规范的翻译稿

如果IP隧道对包重组敏感，则必须或应该限制使用它的DS的行为集合。如果包属于允
许重组的行为集合，则区分服务体系结构也应允许对包进行重组；例如被不同分类选择器标
记的行为集合。IPSec[RFC 2401]和L2TP[RFC 2661]提供了一个对包重组敏感的隧道的例子。
如果IPSec配置了反回放支持，那么对超过一定水平的包重组都将产生一个审计事件，指示
出潜在的安全问题。可以配置L2TP来在出口节点恢复入口的顺序，不仅消除了任何建立在
隧道重排基础上的区别，也会消极地影响通信（例如：通过增加延迟）。通用模型不能完全
的应用于这种隧道，简单地将不同的行为集合混合在一起会导致一些不可预知的交互。
最简单地能够避免使用重组敏感隧道协议进行重组而导致非预期交互的方法就是不使
用这样的协议或特征，但是这往往是不可能的。当使用这样的协议或特征时，可以通过确保
通过隧道的聚集流在 [2 - Outter] 处被标记来组成一个单序集合来避免交互（例如，PHB
共享一个能阻止包重组的排序约束）。隧道协议规范应该说明一个隧道是否和在什么环境下
应该限制为一个单序集合以及何时不受限制。
为了上面提到的IPSec和L2TP，当配置了有重族敏感的协议特征时，规范应该限制每个
隧道为一个单序集合，并且会采取措施限制所有隧道来避免在协议特征改变或隧道流量组合
时产生不希望的结果。区分服务的实现不应该企图期望这些隧道本身来为封装微流提供基于
重组的区分。如果这些隧道需要基于重组的区分，则相同端点间应该使用多并行隧道。这使
不同隧道的包重组和个别不支持包重组的隧道可以共存。对于IPSec和相关的安全协议，因
为任何使用多隧道的流量分析也能通过建立在外IP头的DSCP使用单隧道流量来实现，所以使
用单隧道来实现多排序集合比使用多隧道没有加密的优势。一般来说，支持多隧道还需要一
些附加资源（例如，加密环境），并且在决定是否使用它们时应该考虑多隧道对于网络管理
的影响。
4.2	隧道选择
在决定对什么流量使用隧道时，隧道的行为特性要重点考虑的。其中包括所有参与域的
服务提供策略，不仅仅是在隧道[2 - Outter]标记的PHB和DSCP。举个例子，如果EF是利用
隧道的唯一流量，且隧道提供的方式能充分保护EF PHB特性，那么即使以默认的PHB隧道传
送EF PHB通信不是个好主意，至少也是可以接受的。
服务提供策略要负责防止像通过一个不完备的默认隧道转发EF造成的的不匹配。当一个
有多行为特征的多并行隧道可用时，服务提供策略要负责决定哪个数据流使用哪个隧道。在
所有的可能性当中，有一个通用隧道模型的简单版本，它使用内部DSCP的值来选择一个隧道，
并用与通信的PHB相兼容的行为集合来转发通信。
5．出口功能
如上面第三节中所述，本分析是建立的基础是，区分服务功能和/或带外的通信线路与
隧道封装的过程是非并行的。这就允许3个可能的位置来进行关于隧道解封的流量调节。如
下图所示，描述了IP头在隧道解封过程中的流程：
   >>----[5 - Outer]-------------+
                                  \
                                   \
   >>----[4 - Inner] --------- Decapsulate ---- [6 - After] -->>
在 [5 - Outter] 和 [6 - After] 的流量调节在逻辑上同隧道分离，因为它并不受隧道解封
的影响。隧道设计和规范应该允许在这些位置的区分服务流量调节。这些调节可被看作是独
立于隧道的，[ 5 – Outer ]是发生在隧道出口前的流量调节，[ 6 - After ]是发生在出口解封后
的流量调节。一个重要的例外是，隧道配置（例如，在入口处没有流量调节）和区分服务域
可能要求所有离开隧道的流量通过区分服务的流量调节来完成隧道出口节点的区分服务边
节点流量调节责任。为了确保流量离开节点时与出口节点的区分服务域兼容，鼓励隧道设计
者提供功能使所有的流量都通过区分服务的流量调节来离开隧道。
比较起来，在[ 4 - Inner ]的位置很难进行流量调节，因为它需要到包内部对内IP头进行
操作。不像封装过程中的 [3 - Inner] ，没有必要在[ 4 - Inner ]执行功能，因为区分服务流量
调节可以附加到隧道解封的过程中，如在[6 – After]处执行。
5.1	出口DSCP选择
并行功能的消除和解封装数据路径造成了潜在的信息丢失的可能，如上图所示，解封装
把两个DSCP值减少为一个，丢失了信息，即使允许任意功能。除此之外，允许任意功能也
会造成结构性问题，即外部IP头的DSCP值必须作为带外输入提交给[ 6 - After ]的流量
调节块，这使流量调节模型趋于复杂。
为了避免这样的复杂化，一个简单的办法就是在解封时静态地选择内部或外部DSCP值，
把全部的流量调节留给[ 5 - Outter ] 和/或 [ 6 - After ]来实现。隧道应该支持在隧道
出口静态选择一个或其它DSCP值。这种方法的基本原理就是两个DSCP值中只有一个包含了
有用信息。该隧道的概念模型强烈的暗示了哪个DSCP包含了有用信息；在通用模型中，外
部DSCP值经常包含隧道的有用信息，而在管道模型中，内部DSCP值经常包含了隧道的有用
信息。IPSec隧道经常基于管道模型，并且由于安全原因，一般需要选择内部DSCP值；它
们不应该在没有对结果风险和意义进行足够安全分析的情况下配置为选择外部DSCP值。
5.2	出口DSCP选择情况研究
如上面所讲的在出口处对DSCP选择方法的完整检查，本小节考虑的情况需要更复杂的
手段。当DSCP字段都携带了与流量调节相关的信息时，就不可能静态地选择一个单DSCP
值。
例如，考虑这样一种情况，隧道端点的两个域使用不同的AF 组 [RFC 2597]，并且有
隧道的一个中间域使用RFC 791 IP优先权，它要将设置DSCP为0来传输。如下面的IP头
流程图所示。在图中，I 是隧道入口节点，E是隧道出口节点，垂直线是域边界。为了与中
间域的兼容性，竖线左边的节点将外部头中的DSCP设置为0。
                        |                   |
                  +-----|-------------------|------+
                 /      |                   |       \
   >>-----------I-------|-------------------|--------E---------->>
                        |                   |
      入口  DS  域             RFC 791         出口  DS  域
IP   优先域                               
在这种情况下，出口域的DS边缘节点可以选择适当的AF组（例如：通过一个MF分类
器），但不能重建在RFC 791域传送时从外部头删除的丢弃优先信息。（尽管他可以通过测算
或标记来重建新的信息）。原始的丢弃优先信息被保存在内IP头的DSCP字段，并且可以在
隧道出口处与通过外部IP头的DSCP传输的AF 类型选择进行组合。能够重用原始丢弃优先
信息相对于建立新的丢弃优先信息的附带好处在于，使两个DSCP值对于[6 - After]的流量
调节可用而不用调整引入到隧道出口流量调节中的附加复杂性。
6．区分服务和协议转换器
一个相关的问题是协议转换器，包括那些采用无状态IP/ICMP转换算法。这些转换器
不是隧道，因为它们没有在包上增/删二级IP头。（例如：IPv6 over IPv4隧道 [RFC1933]）
因此没有引起在内外IP头间的信息传播。转换器与区分服务最主要的交互是转换边界类似
于区分服务域边界（例如：IPv4和IPv6可能有不同的通信调节策略和DSCP用法），并且因
此这种转换器应该允许将区分服务边缘节点处理（包括通信调节）插入到转换处理的前后。
7．安全考虑
当隧道存在时，可应用[RFC 2474][RFC 2475]中讨论的区分服务体系结构安全考虑。一
个要求是区分服务域内的一个隧道出口节点是通信退出隧道的DS入口节点，并且要负责进
行适当的流量调节。 主要的安全意义在于流量调节要对流量离开隧道造成区分服务域偷窃
和拒绝服务负责。IPSec结构 [RFC 2401] 隧道出口处理上有更多的限制；除非流量调节的
属性是已知的并且为了安全而经过了充分分析，外部头才能丢弃。其中包括可能存在于隧道
出口节点的 [ 5 - Outter] 和 [ 6 – After ]的流量调节块和上游DS节点（且是封装隧
道流量的DS域入口节点）的流量调节。
8．参考
   [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.
9．鸣谢
本文的某些部分是建立于Brian Carpenter的讨论基础之上，特别是他1999夏天在Oslo
的IETF会议上有关这方面的区分服务WG讲演。同时要感谢那些为撰写隧道规范而工作的
人们，他们发现了区分服务体系结构结构在隧道应用方面的局限。感谢他们为本文付出的耐
心。最后，本文得益于区分服务WG通过会议和邮件列表进行的内部讨论。对所有参与讨
论的人致以崇高的谢意。
10．作者地址
   David L. Black
   EMC Corporation
   42 South St.
   Hopkinton, MA   01748
   Phone: [phone] x75140
   EMail: [e-mail]
11．版权信息
   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.
12．致谢
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC2983——Differentiated Services and Tunnels	区分服务和隧道


1
RFC文档中文翻译计划