RFC2004 IP最小封装

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者：hlp（uangliuqi  hlq@mail.ndsc.com.cn）
译文发布时间：2001-6-8
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。


Network Working Group                                         C. Perkins
Request for Comments: 2004                                           IBM
Category: Standards Track                                   October 1996



IP最小封装
(RFC2004 capsulation within IP)

文档现状
   本文档为Internet社区定义一种Internet标准跟踪协议,尚需讨论以期提高.关于本协议
的标准化情况请参阅最新版本的"因特网正式协议标准" (STD 1)。本文档可以任何形式分发。.
摘要
   本文档定义了一种在IP数据报中封装另一个IP数据报（作为净负载）的方法,可以比“传
统的”IP封装（每一个数据报中封装另一个IP头部）的开销要小。封装通过把他们送往某
个中间目的地（不是由原IP头部的IP Destination Address域）把正常的IP路由变为数据
报。封装可用于多方面,例如使用移动IP把数据报传送到某个移动节点.
1.简介
   本文档定义了一种在IP数据报中封装另一个IP数据报（作为净负载）的方法,可以比“传
统的”IP封装（每一个数据报中封装另一个IP头部）的开销要小。封装通过把路由信息送
往某个中间目的地（不是由原IP头部的IP Destination Address域）把正常的IP路由变为
数据报。封装可用于多方面,例如使用移动IP把数据报传送到某个移动节点.封装与拆分数据
报的过程通常称为数据报“隧道”（"tunneling"），封装方和拆分方分别为隧道的端点
（“endpoints"）;封装方称为隧道的“入口点”（"entry point"）,拆分方称为隧道的出口
点（"exit point"）.

2. 动机
   移动IP工作组已经规定把封装作为从移动节点的“家乡网络”（"home network" ）向代
理（agent）传送数据包的方法，该代理能够以传统方式在移动节点在当前异于家乡的位置“本
地”地传送数据包（参考文献[5]）。封装的使用也可表明在IP数据报的源地址（或者中间路
由器）必须影响数据报送达最终目的地所经过的路由。封装的其他的应用包括多播，预付费,
安全属性选择路由，通用（general）路由选择策略。
   封装比IP松散路由选择的优点见参考文献[4]。使用IP头部封装数据报要求内部IP头部
的几个多余的域;可以通过指定一种封装机制来节省多余的空间。图中显示的方案来自移动
IP工作组（在早期的草案中）,与参考文献[2]中定义的相似.
3.最小封装
   最小转发头部在数据报中定义，在封装前没有分片.这种封装方法是可选的.最小封装不允
许原始（original）的数据报已经分片,因为在转发头部中没有空间存储分片信息.为使用最
小封装来封装IP数据报，最小转发头部被插入到数据报中如下所示：
     +---------------------------+       +---------------------------+
     |                           |       |                           |
     |         IP Header         |       |     Modified IP Header    |
     |                           |       |                           |
     +---------------------------+ ====> +---------------------------+
     |                           |       | Minimal Forwarding Header |
     |                           |       +---------------------------+
     |         IP Payload        |       |                           |
     |                           |       |                           |
     |                           |       |         IP Payload        |
     +---------------------------+       |                           |
                                         |                           |
                                         +---------------------------+


   原始IP的头部已经被修改,在IP头部的后面插入了最小转发头部（minimal forwarding 
header），紧跟着的是原始数据报的IP净负载（如传输层头部，传输层数据）。数据报中没有
再其他的其他的IP头部。
   在封装数据报的过程中,原始IP头部（参考文献[6]）按如下修改:
    -  IP头部的Protocol域被一个协议号55所取代，以说明使用最小封装协议.
    -  IP头部的Destination Address域被隧道的出口的IP地址所取代.
-  如果封装器不在数据报的源地址,IP头部中Source Address域被封装器的IP地址取
代。
- IP头部中的Total Length域增加插入数据报的最小转发头部的大小.增加的可能是12
字节或8字节,取决于转发头部中是否设置了“原始源地址出现”（Original Source 
Address Present (S位)）标志。
    - IP头部的Header Checksum域被重新计算（参考文献[6]）或者更新因为封装的IP头
部已经发生改变。 
    注意跟IP-in-IP封装（参考文献[4]）不同,IP头部中的Time to Live(TTL)域在封装的
过程中并不修改;如果封装器正在转发该数据报,该域将由于正常IP转发而递减。同样,因为
封装后的IP头部依然保留原来的TTL，转发到隧道内部的数据报可见，例如"traceroute"。


   最小转发头部的格式如下所示:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Protocol    |S|  reserved   |        Header Checksum        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Original Destination Address                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :            (if present) Original Source Address               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Protocol
         从原来IP头部的Protocol域拷贝。
      Original Source Address Present (S)
0	原始源地址Original Source Address）域为空.这种情况下最小隧道头部
的长度为8个字节.
1	原始源地址（Original Source Address）域不为空。 这种情况下最小隧
道头部为12字节。
      reserved
         按0发送;接收时忽略.
      Header Checksum
         最小转发头部中所有16比特字和的补码.为计算检验和checksum域的值设置为0.
在计算检验和时不包括IP头部和IP静负载(位于最小转发头部之后).
      Original Destination Address
         从原IP头部中的Destination Address域拷贝.
      Original Source Address
        从原IP头部中的Source Address域拷贝。该域仅在设置Original Source Address         
Present (S)标志时存在.

   在拆分数据报时，最小转发头部各域存放在IP头部中,转发头部从数据报中删除。另外，
IP头部中的Total Length域递减掉从数据报中删除的最小转发头部,IP头部的Checksum域 
被重新计算（参考文献[6]）或者更新，以说明在拆分时IP头部的变化.
   封装器（encapsulator）可以使用现存合适的的IP机制把封装以后的净负载传送到隧道
出口点.特别是,允许选择IP的使用,如果IP头部中不设置"Don't Fragment"位还允许使用分
片。要求对分片加以限定以便使用Path MTU Discovery （参考文献[3]）能得到他们寻找的
信息.
4.路由失败（ Routing Failures）
   用于路由的封装方法使路由环回的敏感度上升.为削减危险,路由器应该遵循参考文献[4]
中描述的规程.
5. 来自隧道内部的ICMP信息
   ICMP信息用参考文献[4]中的方法进行处理,包括维护隧道的“软状态”（"soft state"）.
6.安全方面的考虑
   安全考虑不在本文当中论述，但与参考文献[4]中描述的基本相似.
7.致谢

   很多第3部分的原文从移动IP草案（参考文献[1]）中获得.感谢David Johnson对草案
的连贯性及其它方面的改进。


参考文献
   [1] Perkins, C., Editor, "IPv4 Mobility Support", Work in Progress,
       May 1995.
   [2] David B. Johnson.  Scalable and Robust Internetwork Routing
       for Mobile Hosts.  In Proceedings of the 14th International
       Conference on Distributed Computing Systems, pages 2--11, June
       1994.
   [3] Mogul, J.,  and S. Deering, "Path MTU Discovery", RFC 1191,
       November 1990.
 [4] Perkins, C., "IP Encapsulation within IP", RFC 2003,
       October 1996.
   [5] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
       October 1996.
   [6] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
       September 1981.
作者地址
   关于本文档的问题可直接通过下面的方式与作者联系:
   Charles Perkins
   Room H3-D34
   T. J. Watson Research Center
   IBM Corporation
   30 Saw Mill River Rd.
   Hawthorne, NY  10532
   Work:   +1-914-784-7350
   Fax:    +1-914-784-6205
   EMail: perk@watson.ibm.com

   工作组可以通过现任主席联系:

   Jim Solomon
   Motorola, Inc.
   1301 E. Algonquin Rd.
   Schaumburg, IL  60196

   Work:   +1-847-576-2753
   EMail: solomon@comm.mot.com
 RFC2004 capsulation within IP                                        IP最小封装


1
RFC文档中文翻译计划