组织:中国互动出版网(http://www.china-pub.com/)
RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail:ouyang@china-pub.com
译者:钱海波(bood  boodweb@wx88.net)
译文发布时间:2002-04-26
版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。

译注:本文中的某些词句可能翻译的不准确,我已将没有把握的英文原文附于其后(如果有的话)。如果您发现本文的翻译有任何问题,欢迎来信指正。


Network Working Group                                           G. Malkin
Request for Comments: 1393                                    Xylogics, Inc.
                                                            January 1993

使用IP选项实现Traceroute程序
(Traceroute Using an IP Option)

本备忘录状态
  本备忘录为Internet团体定义了一个试验性质的协议。本文所述内容尚需要通过讨论和建议来改进。要了解本协议的标准化进程,请参考查阅最新的“IAB官方协议”文档。本备忘录的散发不受限制。

概述:
  Traceroute是一个很有用的网络调试工具。当前实现此工具所采用的方法有一个优点,即实现所要求的功能天生就被路由器所支持。然而当前的实现也有两个问题:过多的数据包和过长的运行时间。
本文详细说明了一种新的IP选项和ICMP消息类型,通过它们,我们可以用更少的数据包在更短的时间实现原来Traceroute的功能。

目录

1.  现今的Traceroute  . . . . . . . . . . . . . . . . . . . . . 2
2.  将来的Traceroute  . . . . . . . . . . . . . . . . . . . . . 2
2.1 基本算法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 IP Traceroute选项格式 . . . . . . . . . . . . . . . . . . 2
2.3 ICMP Traceroute消息格式  . . . . . . . . . . . . . . 3
3.  协议  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 跳跃(Hop)计数  . . . . . . . . . . . . . . . . . . . . . 5
3.2 目的主机操作  . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 路由器操作  . . . . . . . . . . . . . . . . . . . . . . . . 5
4.  参考文献  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.  安全性考虑 . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.  作者地址  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1. 现今的Traceroute
  现在的traceroute的实现是这样的:主机先发出一个TTL(Time To Live,生存时间)为1的数据包。接着数据包经过第一跳之后到达一个路由器,此时路由器将发回一个ICMP错误消息[1],以说明这个数据包不能继续向前传送,因为其TTL已经过期了。然后traceroute程序又发出一个TTL为2的数据包,这个数据包经过两次跳跃后其TTL过期。这个过程不断重复,直到数据包到达目的主机。此过程的目的就是要记录下所有发出ICMP超时消息的消息源,据此就可以确定出数据包到达目的主机的路径了。
  这个算法的优点是所有的路由器都能够发出TTL超时消息,因而不需要特殊的代码以支持此算法。而其缺点在于:发出的数据包的数目(2n个,其中n是数据包跳跃次数)(译注:可能包含了路由器发送的超时消息),花费在用连续的数据包记录较近路由的时间,以及路径在这个检测过程中可能会发生改变这个事实。同时,这个算法并不能跟踪检测数据包返回时的路径,而这个路径很可能与外出路径不同。
2. 将来的Traceroute
  这个被提议的traceroute实现将使用一种不同的算法来达到相同的目的,即得到到达目的主机的路径。由于新的traceroute实现采用了一种专用的ICMP消息,所以用户还可以得到一些以前(使用老的traceroute)得不到的额外信息。
2.1 基本算法
  这里,我们将定义一种新的IP选项——Traceroute选项。若此选项存在在一个ICMP应答(或任何其他)数据包中,在下文中称之为“外出数据包”(Outbound Packet),则会使路由器给这个外出数据包的源端发出一个新定义的ICMP Traceroute消息。这样,通过n+1个数据包(而不是2n个),这个外出数据包所经过的路径就可以被其发送端记录下来。路径的改变并不影响这个算法的有效性,同时,该算法还允许对外出数据的应答,下文称之为“返回数据包”(Return Packet),进行跟踪,只要外出数据包的目的主机在发送应答数据时保留原来的IP Traceroute选项就可以了。
  这个方法的不足之处在于必须把traceroute功能加到路由器中去。而好处是这种机制能够很容易的加入到新版本的IP协议中去。
2.2 IP Traceroute选项格式
(译注:为方便对比,我将英文和中文的格式都列了出来,下同)

F(复制到分片标志,copy to fragments):
  0(不复制到分片)
C(类别,class):
  2(调试 & 测量)
数字(Number):
  18(F+C+Number = 82)
ID标识号(ID Number):
  这是由外出数据包发送者指定的任意一个数值,其目的在于可以让程序识别与自身发出数据包对应的ICMP Traceroute消息。这个数值与IP头部的标识号没有关系。
源IP地址(Originator IP Address):
  发送外出数据包的主机地址。这是必须的,因为路由器要根据这个地址发送返回数据包。含有源站选路(Source Route)选项的外出数据包同样需要这个字段。
外出跳跃计数(Outbound Hop Count,简称OHC):
  外出数据包已经通过的路由器数目。外出数据包的目的主机不增加这个字段的值。
返回跳跃计数(Return Hop Count,简称RHC):
  返回数据包已经通过的路由器数目。返回数据包的目的主机不增加这个字段的值。
2.3 ICMP Traceroute消息格式

类型(Type):
  30
代码(Code):
  0 - 外出数据包转发成功
  1 - 前面已没有路由器,数据包被抛弃
校验和(Checksum):
  对首部中每个16位字进行二进制反码求和的结果。在计算校验和之前,应当先把此字段填零,然后填入计算结果。
ID标识号(ID Number):
  与引起此消息的数据包中的IP Traceroute选项部分的相应字段相同。这同样不与IP首部的ID标识号有任何关系。
外出跳跃计数(Outbound Hop Count):
  与引起此消息的数据包中的IP Traceroute选项部分的相应字段相同。
返回跳跃计数(Return Hop Count):
  与引起此消息的数据包中的IP Traceroute选项部分的相应字段相同。
输出连接速度(Output Link Speed):
  发送“外出/返回数据包”所在连接的速度,以“字节(8位)/秒”计。选择“字节/秒”而不是“位/秒”是考虑到如下事实:网络速度不久即将突破4.3GB/s,同时有些机器处理大于32位字段的效率很低。如果这个值不能确定,那么该字段应该置为零。
输出连接MTU(Output Link MTU):
  发送“外出/返回数据包”所在连接的MTU,以“字节”计。MTU所针对的只是数据包中的数据部分,包括IP首部,但不包括链路层所加的首部及尾部封装。如果这个值不能确定,那么该字段应该置为零。
3. 协议
  带有IP Traceroute选项的外出数据包通常不应该使用特殊的服务类型(Type Of Service,简称TOS)或优先级(Precedence),除非想要跟踪具有特殊服务类型或优先级的数据包路径。
  外出数据包的TTL值应该设置成“数字分配”[2]一文中所指定的默认值。
3.1 跳跃(Hop)计数
  跳跃计数提供了有关外出/返回数据包到目的主机所经路径长度的信息。这些计数也提供了判断ICMP Traceroute消息丢失与否的一种方法。举个例子来说,如果一个OHC为6的消息紧跟在一个OHC为4的消息后面,那么我们可以得出结论,那个OHC为5的消息丢失了。这也说明了仅计算Traceroute消息的数目不能有效判断路径长度的原因。
  外出数据包的源端应当把数据包中的OHC设成0,而把RHC设成0xFFFF。0xFFFF这个特殊数值用来表示这是一个外出数据包而不是返回数据包,返回数据包的RHC为0。
  另外要注意的很重要的一点是,这个跳跃计数与与IP的TTL没有任何关联。跳跃计数的步增应该仅在一个ICMP Traceroute消息发出时进行。
3.2 目的主机操作
  若一主机接收到一个带有IP Traceroute选项的外出数据包,那么在被要求应答的时候(如ICMP Echo服务的请求/应答),返回数据包也应当带有此选项。在返回数据包中必须填入如下内容:ID标识号、OHC和源IP地址。而RHC字段应当被设为0。
  外出数据包的目的主机不应该再增加跳跃计数或者发送任何的ICMP Traceroute消息。
3.3 路由器操作
  当路由器转发一个含有IP Traceroute选项的数据包时,它应当给源IP地址字段所指出的主机发送一份ICMP  Traceroute消息。如果接收到的数据包中的RHC字段为0xFFFF,那么这个数据包就是外出数据包,因此路由器应当将OHC字段的值加一;否则路由器应将RHC字段加一。而发回的Traceroute消息应该反映出增加后的跳跃计数。输出连接速度应当设置成发送“外出/返回数据包”所在连接的速度,以“字节(8位)/秒”计(如一个以太网速度为1,250,000),该字段也可以设成零以表示速度不能确定。输出连接MTU应当设置成发送“外出/返回数据包”所在连接的MTU,该字段同样可以为零以表示MTU不能确定。
  当Traceroute选项存在时,外出/返回数据包的转发过程应该像它不存在一样。也就是说,到达目的主机的路径与是否存在Traceroute选项无关。
  ICMP Traceroute消息应该与外出/返回数据包具有相同的TOS和优先级。TTL值应该设置成“数字分配”[2]一文中所指定的默认值。
  ICMP Traceroute消息不应该再具有IP Traceroute选项。
  如果外出数据包不能被转发,那么返回的ICMP Traceroute消息的代码字段应当设为1。但是如果返回数据包由于没有可用的路由器而不能被转发,那么就不需要发回一个Traceroute消息,因为这个消息就算发了也将不能被转发。
4. 参考文献
   [1] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
       USC/Information Sciences Institute, September 1981.
   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July 1992.
5. 安全性考虑
  安全性方面的相关内容不在本文中讨论。
6. 作者的地址
   Gary Scott Malkin
   Xylogics, Inc.
   53 Third Avenue
   Burlington, MA 01803
   Phone:  (617) 272-8140
   EMail:  gmalkin@Xylogics.COM
RFC 1393 -- Traceroute Using an IP Option                      使用IP选项实现Traceroute程序




1
RFC文档中文翻译计划