rfc2003.txt

很多RFC的中文文档

      数据报太大Datagram Too Big (Code 4)
         封装方必须把数据报太大ICMP中继给未封装数据报的发送方。
      源路由失败Source Route Failed (Code 5)
         该代号应该由封装方自己处理。不允许把它中继给位封装数据报的发送方。
4.2.源淹没 Source Quench (Type 4)
   封装方不应该把源淹没信息中继给未封装数据报的发送方,但应该激活所使用的拥塞控
制机制以帮助减轻隧道内部所检测到的拥塞。
4.3.重定向 Redirect (Type 5)
   封装方可能自己处理重定向ICMP信息。不允许把重定向中继到为封装数据报的发送方。4。
4.4.超时 (Type 11)
   超时ICMP信息在隧道自身内部报告(推测)路由环回。封装方收到超时信息必须把该超时
信息作为主机不可达（Type 3, Code 1）信息向未封装数据报的发送方报告。主机不可达与
网络不可达更优越；因为数据报由封装方处理,封装方通常被视为未封装数据报的目的地址且
位于相同的网络上,数据报被视为到达正确的网络，但错误的目标节点。
4.5. 参数问题Parameter Problem(Type 12)
   如果参数问题指向从未封装数据报中拷贝而来的某个域,封装方可能把该ICMP信息中继
给未封装数据报的发送方；否则，如果问题是由封装方插入的IP选项引起，封装方不允许把
该ICMP信息中继给发送方。注意遵循实际情况的封装方永不会把IP选项插入到封装的数据
报中，除非出于安全原因。  
4.6.其他ICMP信息
   其他ICMP信息与本协议规范中的封装无关,封装方应该遵循按参考文献[9]中所定义的 
规范。
5. 隧道管理
   不幸的是,ICMP仅要求IP路由器返回IP头部之外的8个字节(64bits)。这不足以包括一
个封装后(内层)IP头部的一个拷贝,所以封装方不总是能把隧道内部的ICMP信息中继给原发
送方。但是，通过仔细维护隧道的“软状态”（"soft state" ），封装方可在大多数情况下把
精确的ICMP信息返回给发送者，封装方应该至少维护每一个隧道的下述软状态信息：
    - 隧道的MTU (见5.1)
-隧道的TTL (路径长度path length)
    - 隧道端点的可达性
   封装方使用它收到的来自隧道内部的ICMP信息更新该隧道的软状态信息。可能从隧道中
的路由器返回的ICMP错误包括：
    - 数据报太大
    - 超时
    - 目标不可达
    - 源淹没
   当随后经过该隧道的数据报到达时，封装方（器）检查该隧道的软状态.如果该数据报与
隧道的当前状态冲突（新数据报的TTL小于隧道的"软状态"TTL） 封装方向原始数据报的发
送方送回一个ICMP错误信息 ，但还是封装该数据报并把它转交给隧道。
   使用这种技术,用封装方发送的ICMP错误信息不会总是与隧道内部发生的错误一一匹配，
但它们可以精确地反映网络的状态。
   隧道软状态最初开发用于IP地址封装（IP Address Encapsulation ，IPAE），见参考文
献[4]。
5.1.隧道MTU发现
   如果源发送方设置了Don't Fragment位并被拷贝到外层IP头部中,可以通过报告给封装
方的Datagram Too Big (Type 3, Code 4)ICMP信息得知隧道的MTU.为支持使用路径MTU发
现的发送节点，所有封装实现必须支持隧道内部“路径MTU发现”软状态（参考文献[5, 7]）。
在这种特殊应用中，有几个好处： 

     -分片（由于封装头部的大小）将作为路径MTU发现的受益者,在封装后只执行一次。这
将阻止对一个数据报进行多次分片,提高拆分方和隧道内部的处理效率。
     -如果未封装数据报的源正在做路径MTU发现,那么要求封装方知道隧道的MTU。任何来
自隧道内部的Datagram Too Big信息被返回到封装方,正如在5中所注的那样，封装
方不可能把所有ICMP信息中继给未封装数据报的发送方.通过维护隧道MTU的软状态，
封装方可以把正确的Datagram Too Big信息返回给未封装数据报的发送方以支持它
自己的路径MTU发现.在这种情况下,由封装方发送给原发送方的MTU应该是隧道的
MTU减去正封装的IP头部的大小。这将避免最初IP数据报被封装方分片。
-	如果未封装数据报的源不在做路径MTU发现，封装方仍然需要知道隧道的MTU。特别
地，在封装时对原始数据报进行分片比允许对封装后的数据报分片要好得多.对原始
数据报的分片可由封装方完成，且不需要特殊缓冲要求，也不需要在拆分方保存重
新装配的状态。相比之下,如果对封装后的数据报进行分片,那么拆分方必须在拆分
前重新组装分片（封装后）后的数据报，这就要求在拆分方重新组装状态和缓冲空
间。

这样，封装方正常情况下应该做路径MTU发现，要求封装方在所有送往隧道的数
据报均在IP头部设置"Don't  Fragment" 位。但是该方法带来几个问题。当原始发送
方设置"Don't Fragment"位时,发送方能通过重传原始数据报来对返回的Datagram Too 
BigICMP错误信息迅速做出反应。另一方面，假定封装方收到来自隧道内部的Datagram 
Too BigICMP错误信息，如果未封装数据报的发送者没有设置"Don't Fragment"位,封装
方将无法让原始发送方知道该错误。封装方可能在试图递增隧道的MTU时保存已发送数
据报的一份拷贝，以允许它在收到Datagram Too Big响应时分片并重传该数据报。
         另一种选择是在未封装数据报没有设置"Don't Fragment"位时，封装方可能（以）
设置某些类型的数据报不设置"Don't Fragment"位。
5.2.拥塞
   封装方可能收到来自隧道内部的拥塞的暗示，例如，收到隧道内部的源淹没（Source 
Quench）ICMP信息。另外，与Internet无关的链路层以及各种协议可能以Congestion   
Experienced标志位（参考文献[6]）的形式提供该暗示。封装方应该在隧道的软状态中反映
拥塞状态,在随后向隧道转发数据报时，封装方应该使用适当手段来对拥塞进行控制（参考
文献[3]）；但是，封装方不应该向位封装数据报的发送方发送源淹没（Source Quench ）ICMP
信息。
6. 安全方面的考虑
   IP封装潜在地降低了Internet的安全性,所以在使用IP封装时应该注意。例如IP封装
使边沿路由器很难根据其头部对数据报进行过滤。特别是,IP头部的原始的Source Address, 
Destination Address,和Protocol各域,以及数据报中传输层头部使用的端口号,在封装后并
不处在它们正常的位置。因为任何IP数据报能被封装并通过隧道传输,这样的过滤边沿路由
器需要认真检查每一个数据报
6.1.路由器方面的考虑
   路由器需要知道IP封装的协议以便能够对传进来的数据报进行过滤。这样的过滤应该与
IP身份认证（参考文献1）集成在一起。在使用IP身份认证的地方，如果正在封装的（外层）
数据包或者已经封装的（内层）数据包由一个经过认证的可信的源发送，则封装后的数据报
可被允许进入某组织。不包含这些认证的封装后的数据包是一个极大的安全隐患。







   封装和加密后的IP数据报（参考文献[2]）也可能给过滤路由器带来问题。在这种情况下，
路由器只能过滤那些共享了用于加密的安全联合的数据报。在所有数据包都需要过滤（或者
至少说明）的环境中，为允许这种加密，接收节点必须采用一种机制来安全地把安全联合送
到边沿路由器。对于传出的数据包也适用这种安全联合，但较少使用。
6.2.主机方面的考虑
  能够接收封装后的IP数据报的主机应该只接受符合下面几种类型的一种或多种的数据报：
    -  协议无害:不需要进行基于源地址的身份认证。
    - 正封装的（外层）数据报来自认证识别的可信的源，源的真实性建立于物理安全和边
沿路由器的配置,但更可能来自IP身份认证头部（参考文献[1]）.
-封装后的（内层）数据报包括一个IP身份认证头部 
-封装后的（内层）数据报送到属于拆分方的网络接口，或者拆分方已与之建立特殊关系以传
输这些封装后数据报的节点。 

   这些检查的某些或全部在边沿路由器而不是接受节点进行，但如果边沿路由器检查作为备
份而不是仅仅作为检察会更好。
7.致谢
   3和5节部分节选自移动IP因特网草案（Bill Simpson）的早期版本（参考文献[8]）.6
节（安全考虑）的源文来自Bob Smart.从RFC 1853（参考文献[11]，作者也是Bill Simpson）
中的到很多好主意,也感谢Anders Klemets发现草案中的错误并提出改进建议。最后感谢
David Johnson对草案的非常细致的审阅，勘误，润色以及其他方面的。

参考文献
   [1] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
   [2] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
       August 1995.
   [3] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC
       1812, June 1995.
   [4] Gilligan, R., Nordmark, E., and B. Hinden, "IPAE: The SIPP
       Interoperability and Transition Mechanism", Work in Progress.
   [5] Knowles, S., "IESG Advice from Experience with Path MTU
       Discovery", RFC 1435, March 1993.
   [6] Mankin, A., and K. Ramakrishnan, "Gateway Congestion Control
       Survey", RFC 1254, August 1991.
   [7] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
       November 1990.
   [8] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
       October 1996.
   [9] Postel, J., Editor, "Internet Control Message Protocol", STD 5,
       RFC 792, September 1981.
   [10] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
        September 1981.
   [11] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
作者地址
   关于本文档的问题可通过下述方式直接联系:
   Charles Perkins
   Room H3-D34
   T. J. Watson Research Center
   IBM Corporation
   30 Saw Mill River Rd.
   Hawthorne, NY  10532
   Work:   [phone]
   Fax:    [phone]
   EMail: [e-mail]
   
本工作组可以通过现任主席联系:
   Jim Solomon
   Motorola, Inc.
   1301 E. Algonquin Rd.
   Schaumburg, IL  60196

   Work:   [phone]
   EMail: [e-mail]
RFC2003   IP Encapsulation within I P                              在IP内封装IP


1
RFC文档中文翻译计划