RFC3093_防火墙增进协议 (FEP)

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


Network Working Group                              G. Montenegro, Editor
Request for Comments: 2344                        Sun Microsystems, Inc.
Category: Standards Track                                       May 1998




  
RFC2344  移动IP反向隧道
(RFC2344 Reverse Tunneling for Mobile IP)


本备忘录状态
   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.
版权声明
   Copyright (C) The Internet Society (1999).  All Rights Reserved.

摘要

   移动IP在家乡代理和移动节点的转交地址之间使用隧道，但在相反方向却很少使用。通常，移动节点通过一台位于外地网络上的路由器发送数据包，并假定数据包的路由与源地址无关。如果该假设不成立（即路由与源地址有关）,就可以很方便地在转交地址和家乡代理之间建立起一个拓扑上正确（topologically correct）的反向隧道。
   本文档推荐移动IP的一种向后兼容的扩展以支持在拓扑上正确的反向隧道。由位于家乡代理和移动节点转交地址之间的防火墙所引发的各种问题，本文档不予解决。




目录
1. 简介	3
1.1. 术语	4
1.2. 假定	4
1.3. 合理性	5
2. 总述	5
3.新的数据包格式	5
3.1. 移动代理广告扩展	5
3.2. 注册请求	6
3.3. 封装发送方式扩展	7
3.4.新的注册应答码	7
4. 协议工作方式的变化	8
4.1. 移动节点方面的考虑	8
4.1.1.给外地代理发送注册请求	8
4.1.2.接收来自外地代理的注册应答	8
4.2. 外地代理方面的考虑	9
4.2.1. 接收来自移动节点的注册请求	9
4.2.2. 把注册请求中继到家乡代理	9
4.3. 家乡代理方面的考虑	10
4.3.1. 从外地代理接收注册请求	10
4.3.2. 向外地代理发送注册应答	10
5. 移动节点到外地代理的发送方式	10
5.1. 直接发送方式	11
5.1.1. 数据包的处理	11
5.1.2. 数据包头部格式及各域	11
5.2. 封装发送方式	12
5.2.1 数据包的处理	12
5.2.2. 数据包头部格式及各域	12
5.3. 广播和多播数据报的支持	13
5.4.可选的反向隧道	13
6. 安全方面的考虑	14
6.1. 反向隧道劫机及拒绝服务攻击	14
6.2. 入口处过滤	14
7. 致谢	14
参考文献	14
编辑和主席地址	15
完整版权通告	16






1. 简介
   移动IP（参考文献[1]）的1.3列出了下面的假设:
      我们假设IP单播数据报的路由基于数据报头的目的地址(也就是说，不是根据源地址进行路由)。
   出于安全方面的考虑(例如IP欺骗攻击),以及根据RFC 2267（参考文献[8]）和CERT(参考文献[3])的建议,不遵循这个假设的路由器正在变得越来越常见。
   在这种路由器中数据包中的源地址和目的地址必须在拓扑上正确。前向隧道符合这一点，因为其端点(家乡代理和转交地址)各自被指定了正确的地址。但是另一方面,移动节点发送的数据包的源IP地址与其发送地的网络前缀不一致。
   本文档讨论在拓扑上正确的反向隧道。

RFC 2344            Reverse Tunneling for Mobile IP             May 1998

  移动IP在多播数据报和移动路由器的情况下没有规定使用反向隧道。但是,源IP地址被设置为移动节点的家乡地址，因此这些隧道在拓扑上不正确。
   注意不管拓扑正确性如何，反向隧道有几个用处：

      - 移动路由器:反向隧道不需要递归隧道（参考文献[1]）。

- 多播:反向隧道使得远离家乡的移动节点能够
(1) 加入到其家乡网络的多播组
(2) 发送多播数据报以便能够从其家乡网络发出（参考文献[1]）

      - 移动节点发送的数据包的TTL可能太小以至于在到达目的地之前就到期（例如，在发送数据报到其家乡网络上的其他主机时）。反向隧道解决了这个问题，因为它表现出来的只是TTL减1（参考文献[5]）。
1.1. 术语
   下面的讨论使用了移动IP规范中定义的术语。另外，还使用了下面的术语:

前向隧道
         把数据包发向移动节点的隧道。它始于家乡代理，终止于移动节点的转交地址。
反向隧道
         始于移动节点的转交地址，终止于家乡代理的隧道。
   本文当出现的关键词“必须(MUST )”，“不允许(MUST NOT)”，“要求（REQUIRED）”，“应该（SHALL）”,“不应该（SHALL NOT）”，“应该（SHOULD）”，“不应该（SHOULD NOT）”，“建议（RECOMMENDED）”，“可以(MAY)”，“可选（OPTIONAL）”等按RFC 2119（参考文献[9]）解释。（本文档的中译版将以粗体字加上红色显示）。


1.2. 假定
   移动性限制为一个通用的IP地址空间(举个例子，也就是说，移动节点与家乡代理之间的路由结构并不分为“专用”和“公用”网络)。

   本文档不解决穿越防火墙的问题。而是假设下述条件之一成立：

      - 数据包传送所经过的隧道沿途没有防火墙。
      - 任何位于其间的防火墙共享必要的安全联合来处理可能已经添加到数据包头部中的认证部分（参考文献[6]）或者加密部分（参考文献[7]）。

   这里讨论的反向隧道是对称的，就是说，它使用与前向隧道相同的配置（使用相同的封装方法，相同的IP地址作为隧道的端点）。除非指明别的封装方法，总是假设使用IP-in-IP封装（参考文献[2]）。

   路由最优化（参考文献[4]）引进了通信主机发起的前向隧道。因为移动节点可能不知道对方主机是否能对数据包进行拆封,在这种情况下的反向隧道在这里不予讨论。
1.3. 合理性
   为什么不让移动节点自己发起到家乡代理的隧道呢？实际上，这正是移动节点在以一个在拓扑上正确的配置转交地址操作时应该做的。

   但是，移动IP规范的一个基本设计目标就是不要求这种模式的操作。

   本文档大致描述的机制主要用于前向隧道依赖于外地代理的移动节点。我们所希望的就是继续支持这些移动节点，即使在出现过滤路由器的场合。
2. 总述
   移动节点到达一个外地网络，侦听代理广告并选中一个支持反向隧道的外地代理。当它通过该选中的外地代理注册时它请求使用反向隧道。此时，移动节点还根据它向外地代理发送数据包的方式在注册请求中表明是使用直接发送方式还是封装发送方式（见5节）。

   在直接发送方式中，移动节点把外地代理指明为其缺省路由器并直接把数据包发送到外地代理，也就是说没有经过封装。外地代理截获这些数据包，并通过隧道把他们传送到家乡代理。

   在封装发送方式中，移动节点把所有待发送的数据包进行封装。外地代理对这些数据包进行拆封并通过第二个隧道把他们传送到家乡代理，在第二个隧道，隧道的入口点是外地代理转交地址。

3.新的数据包格式
3.1. 移动代理广告扩展
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
       Type
    Length
          Sequence Number
            Lifetime 
R
B
H
F
M
G
V
T
     reserved
Zero or more Care-of  Addresses
     . . . . . .


   移动代理广告扩展（参考文献[1]）的唯一的变化是多出了一个“T”位：

      T   代理提供反向隧道服务。

   设置了“T”位的外地代理必须支持当前支持的两种发送方式：直接发送方式和封装发送方式（见第5节）。

   通过这些信息，移动节点能够选择一个支持反向隧道的外地代理。注意如果移动节点不理解这一位,它简单的把它忽略（参考文献[1]）。
3.2. 注册请求
   在注册请求中直接加入一个“rsvd”位来请求反向隧道的支持。如果不支持反向隧道的外地代理或家乡代理收到设置“T”位的注册请求，则该注册请求将失败。这将导致一个拒绝注册（拒绝码在第3.4节定义）。

   大多数的家乡代理不拒绝提供反向隧道支持，因为他们“应该能对移动节点发给它的数据包进行拆封并进行进一步传送”（参考文献[1]）。在拓扑正确的反向隧道中，移动节点发送数据包时并不是以其家乡地址来区分，相反，这些数据包的外层（封装层）源IP地址为移动节点的转交地址。尽管如此，家乡代理也许已经支持所要求的拆封及进一步转发功能。

   在移动节点发送的注册请求中，IP头部的生存期（Time to Live）域必须设置为255。这样就限制了恶意主机发送虚假注册请求而导致的拒绝服务攻击（见第6章）。

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
       Type
S
B
D
M
G
V
Y
-
            Lifetime
                                   Home Address
                                   Home Agent
                                  Care-of Address
                                   Identification
Extentions   . . . . . .


   注册请求数据包中唯一的变化就是多出来的“T”位：
         T     如果设置了“T”位，则移动节点请求其家乡代理接受始于转交地址的隧道。
移动节点使用外地代理转交地址请求外地代理使用反向隧道传送其数据包。
3.3. 封装发送方式扩展
   移动节点可以在注册请求中包含封装发送方式扩展以进一步指定反向隧道的工作方式。我们认为只有外地代理用到该扩展。因此，外地代理必须处理掉该扩展（也就是说，外地代理不能把该扩展中继到家乡代理，也不能在发送给移动节点的应答中包含该扩展）。

   如（参考文献[1]）中3.6.1.3中所述，如果出现封装发送方式扩展，移动节点必须在注册请求中把该扩展置于Mobile-Home认证扩展之后，Mobile-Foreign认证扩展之前。

   如果注册请求中没有设置“T”位，则该请求不允许包含封装发送方式扩展。

   如果没有出现该扩展，就假设发送方式为直接发送方式。封装根据前向隧道的协商结果来进行(也就是说，除非指定其他方式，总是假设为IP-in-IP)。发送方式的细节请参考第5节。

0
1
0
1
2
3
4
5
6
7
8
9
0
1
2
3
4
5
      Type
   Length

      Type
        130
      Length
        0
3.4.新的注册应答码
   如果反向隧道请求失败，外地代理和家乡代理必须发送注册应答。新的应答码定义如下：
      服务被外地代理拒绝：
      74 请求的反向隧道不可用
      75 强制使用反向隧道但没有设置“T”位
      76 移动节点太“远”

   以及

      服务被家乡代理拒绝:

      137 请求的反向隧道不可用
      138 强制使用反向隧道但没有设置“T”位
      139 请求的封装不可用

   对应于设置“T”位的注册请求,移动节点可能分别收到（而且必须接受）来自外地代理的code 70(poorly formed request)和来自家乡代理的code 134（poorly formed request）。但是支持反向隧道的外地代理和家乡代理必须分别使用code 74和code 137.

   没有设置“T”位的注册请求可能分别从外地代理和家乡代理收到code 75和code 138。

   前向隧道和反向隧道时对称的，也就是说，两者都能使用注册时协商的隧道选项。这就暗示着家乡代理如果收到包含不支持形式的隧道的注册请求时必须拒绝该注册（code 139）。注意移动IP（参考文献[1]）已经定义了外地代理类似的拒绝码（失败码）。
4. 协议工作方式的变化
   除非另外指出，总是假设使用移动IP（参考文献[1]）中规定的工作状况。特别地，如果两个实体共享移动安全联合，他们必须在传送注册数据报文时使用正确的认证扩展（Mobile-Foreign, Foreign-Home或者Mobile-Home认证扩展）。Mobile-Home认证扩展总是必须出现。

   反向隧道要求移动实体进行多出移动IP规范的协议处理。与移动IP（参考文献[1]）协议工作状况的不同之处在随后的章节中描述。
4.1. 移动节点方面的考虑
   本节描述移动节点如何在注册中请求反向隧道。
4.1.1.给外地代理发送注册请求
   除了参考文献[1]中的考虑，移动节点在注册请求中设置“T”位来请求反向隧道。

   移动节点必须把IP头部的TTL域设置为255。这样做是为了限制反向隧道中的“劫机攻击”(见第6章)。

   移动节点在注册请求中还可以（可选地）包含一个封装传送方式扩展。
4.1.2.接收来自外地代理的注册应答
   可能的有效应答为:

      - 由家乡代理或者外地代理发送的拒绝注册:
a. 移动节点遵循参考文献[1]中的检错原则，根据应答重的错误码（失败码）可以试图修改该注册请求（例如，从注册请求中去除可选形式的封装）并发送一个新的注册。
b. 根据应答错误码（失败码）,移动节点可以试图把“T”位清零，去掉封装发送方式扩展（如果出现的话），并发送一个新的注册。注意这样做之后注册可能成功，但由于没有反向隧道，数据传输可能无法进行。

      - 家乡代理返回注册应答，表明将提供（所请求的）服务（即反向隧道）。

   在最后一种情形中，移动节点已经在其转交地址和家乡代理之间成功建立起一条反向隧道。如果移动节点以配置转交地址操作，它可以对待发送数据包进行封装以使得外层头部的目的地址为家乡代理的地址。这种把数据包通过反向隧道发送的能力我们在第5.4节还要深入讨论。
   如果转交地址属于一个单独的外地代理，则移动节点必须使用所请求的无论哪一种发送方式（直接发送或者封装发送）并继续第5章中描述的过程。

   成功的注册应答保证了外地代理和家乡代理都支持所请求的不管那种可选形式的封装（除了IP-in-IP之外）。因而，移动节点可以自己判断使用（哪一种封装方式）。
4.2. 外地代理方面的考虑
   本节描述了外地代理如何处理反向隧道的注册请求。
4.2.1. 接收来自移动节点的注册请求
   外地代理在收到设置了“T”位的注册请求时按移动IP规范（参考文献[1]）中描述的那样对数据包进行处理（即合法性检查，向家乡代理转发等），并判断它是否能容纳该前向隧道请求。如果不能，则返回一个合适的错误码（失败码）。特别地，如果外地代理不能支持所请求形式的封装，它必须返回错误码72。

   外地代理可以使用错误码75（强制使用反向隧道但注册请求没有设置“T”位）来拒绝不设置“T”位的注册请求。

   外地代理必须核实以确保IP头部的TTL域设置为255。否则，它必须使用错误码76（移动节点太“远”）来拒绝该注册。外地代理必须把其发送注册应答的速率限制为最大一秒钟一次。

   作为最后的检查，外地代理核实以确保它能支持相同配置的反向隧道。如果不能，它必须发送错误码74（请求的反向隧道不可用）的注册应答。
4.2.2. 把注册请求中继到家乡代理
   否则，外地代理必须把该注册请求中继到家乡代理。

   一旦接收到满足合法性检查的注册应答，外地代理必须更新其访问者列表，包括暗示移动节点其请求的反向隧道和发送方式已经获准（第5章）。

   在该访问者（移动节点）表项有效期间，外地代理必须根据其发送方式处理来自该访问者（移动节点）的数据流量，对数据包进行封装并把它们送入由转交地址到家乡代理的隧道。
4.3. 家乡代理方面的考虑
   本节描述家乡代理如何处理请求反向隧道的注册请求。
4.3.1. 从外地代理接收注册请求
   家乡代理在收到设置了“T”位的注册请求时，对数据包的处理遵循移动IP规范（参考文献[1]），并判断是否能容纳该前向隧道请求。如果不能，家乡代理将返回合适的错误码（失败码）。特别地，如果家乡代理不能支持所请求形式的封装，它必须返回错误码139(请求的封装不可用)。
   家乡代理可以使用错误码138（强制使用反向隧道但注册请求没有设置“T”位）来拒绝没有设置“T”位的注册请求。
   作为最后的检查，家乡代理判断它是否能够支持使用与前向隧道相同配置的反向隧道。如果不能，它将回送一个错误码137（请求的反向隧道不可用）来拒绝该注册。
   一旦收到满足合法性检查的注册请求（原文为注册应答――译注），家乡代理必须更新其移动绑定列表，暗示移动节点其请求的反向隧道和发送方式已经获准。
4.3.2. 向外地代理发送注册应答
   与一个有效的注册请求相对应，家乡代理必须给移动节点发送一个注册应答。

   在成功注册后，家乡代理可能收到发给它自身的经过封装的数据包。对这些数据包进行拆封并盲目地把它们注入网络是一个潜在的安全缺陷（见第6.1节）。因而，家乡代理必须（并且缺省为应该）对发给它的经过封装的数据包进行下面的检查：

家乡代理搜寻这样的移动绑定记录：该记录的转交地址等于数据包外层头部源地址且移动节点地址为内层头部源地址。
   如果没有找到这样的绑定记录，或者数据包使用的不是注册时协商好的封装方法，家乡代理必须丢掉该数据包并应该把该事件记录为一个安全意外。

   终止于与移动IP无关（例如多播隧道）的隧道的家乡代理可以不进行上面的检查，但基于前述原因不提倡这么做。


   在该注册有效期间，家乡代理必须处理每一个有效的（由类似上面的检查来确定）来自反向隧道的数据包，即对数据包进行拆封，恢复出原始数据包然后代表其发送者（移动节点）把它转发到其目的地址（通信对方主机）。
5. 移动节点到外地代理的发送方式
   本节讨论移动节点如何通过外地代理发送其数据。在所有情况下，移动节点通过代理广告的链路层头部来获取外地代理的链路层地址。
5.1. 直接发送方式
   这种发送方式易于在移动节点实现，在移动节点和外地代理之间的链路（可能是很慢的链路）上使用小的（未经封装的）数据包。但是，它仅仅支持单播数据包的反向隧道，不允许其它的反向隧道（见第5.4节）。
5.1.1. 数据包的处理
   移动节点必须把外地代理指定为其缺省路由器。不这样做将不能保证对移动节点发出的所有数据包进行封装，并且反向隧道将失效。外地代理必须：
      - 检测（detect）移动节点发送的数据包,并且
- 在转发这些数据包之前对这些数据包进行封装。
5.1.2. 数据包头部格式及各域
   本节给出了直接发送方式下数据包头部的格式。这种格式假设使用的是IP-in-IP封装（参考文献[2]）。

   外地代理收到的数据包格式(直接发送方式):

       IP各域：
          源地址=移动节点的家乡地址
目的地址=通信对方主机的地址
       高层协议数据

   外地代理转发的数据包的格式(直接发送方式):

       IP 各域(封装头部):
         源地址=外地代理的转交地址
         目的地址=家乡代理的地址
         Protocol域: 4 (IP-in-IP)
       IP各域(原始头部):
         源地址=移动节点的家乡地址
         目的地址=通信对方主机的地址
       高层协议数据

   封装头部的各个域必须按下面选取:
      IP 源地址
         从注册请求的转交地址（Care-of Address）域拷贝而得。
IP 目的地址
         从注册请求的家乡代理（Home Agent）域拷贝。
      IP 协议域
         缺省为4 (IP-in-IP，参考文献[2]),但也可以使用注册时协商好的其它形式的封装方法。
5.2. 封装发送方式
   这种机制要求移动节点自己实现封装，并且通过把外地代理的地址指定为新的最外层头部的目的地址直接把数据包传送到外地代理。希望发送广播或者多播数据报的移动节点必须使用封装发送方式。
5.2.1 数据包的处理
   外地代理不修改其前向（转发）功能。相反地，它接收数据包，在核实数据包是移动节点发出的以后，它：
- 对数据包进行拆封，恢复出内层数据包
- 对数据包进行重新封装，并把它发送到家乡代理。
   如果外地代理接收到来自移动节点的未经封装的数据包，并且移动节点已经显式请求封装发送方式，那么外地代理不允许使用反向隧道发送该数据包，相反，它必须使用标准的IP路由机制来转发该数据包。
5.2.2. 数据包头部格式及各域
   本节给出了使用封装发送方式的数据包头部的格式。该格式假设使用IP-in-IP封装（参考文献[2]）。
   外地代理接收到的数据包格式(封装发送方式):
       IP各域(封装头部):
         源地址=移动节点的家乡地址
         目的地址=外地代理的地址
         Protoco域: 4 (IP in IP)
       IP各域(原始头部):
         源地址=移动节点的家乡地址
         目的地址=通信对方主机的地址
       高层协议数据

   封装头部的各域必须按如下选用：
      IP 源地址
         移动节点的家乡地址。
      IP 目的地址
         由代理最近的注册应答中得知的IP源地址。
      IP Protocol域
         缺省为4(IP-in-IP，参考文献[2]),但也可以使用注册时协商好的其它封装方法。

   由外地代理转发的数据包的格式(封装发送方式):
       IP 各域(封装头部):
         源地址=外地代理的转交地址
         目的地址=家乡代理的地址
         Protocol域: 4 (IP-in-IP)
       IP 各域(原始头部):
         源地址 =移动节点的家乡地址
         目的地址=通信对方主机的地址
       高层协议数据

   封装IP头部各域必须按照如下选取:
      IP 源地址
         从注册请求重的转交地址（Care-of Address）域拷贝。
      IP 目的地址
         从注册请求的家乡代理（Home Agent）域拷贝。
      IP Protocol域
         缺省为 4 (IP-in-IP，参考文献[2]),但也可以使用注册时协商好的其它封装方法。
5.3. 广播和多播数据报的支持
   如果移动节点以配置转交地址操作，广播和多播数据报按照移动IP规范（参考文献[1]）中的第4.3和4.4 节处理。使用外地代理转交地址的移动节点可以由外地代理通过反向隧道传送广播和多播数据报。但是，这样的移动节点必须使用封装发送方式。
   这样只是把数据报传送到外地代理，外地代理对数据报进行拆封，然后像对待来自移动节点的其它数据报一样处理该数据报，也就是说，通过反向隧道把它传送到家乡代理。
5.4.可选的反向隧道
   传送到本地资源（例如，附近的打印机）的数据包可能受到入口处过滤的影响。使用配置转交地址的移动节点可以对这些数据包的传送进行优化，方法就是不使用反向隧道传送。另一方面，使用外地代理转交地址的移动节点可以通过请求封装发送方式使用可选的反向隧道功能，遵循下面的原则：
      不想被通过反向隧道传送的数据包:
          使用直接发送方式。外地代理必须把这些数据包作为常规的流量来处理：它们可以被转发到家乡代理但是不允许通过反向隧道传送到家乡代理。

      想被通过反向隧道发送的数据包:
         使用封装发送方式发送。外地代理必须按第5.2节处理这些数据包：它们必须通过反向隧道传送到家乡代理。
6. 安全方面的考虑
   本文当描述的扩展是以移动IP规范（参考文献[1]）所描述的安全方面的考虑为基础的。本来，前向隧道和反向隧道的创建都涉及到认证过程，认证过程减少了受攻击的危险。
6.1. 反向隧道劫机及拒绝服务攻击
   一旦隧道建立起来后，恶意的节点将可能“劫持”该隧道并把数据包注入网络中。反向隧道可能使这个问题恶化，因为,当数据包到达隧道的出口点时，它的转发将在超出本地网络之外的地方进行。 这个问题在移动IP规范中也出现，因为它已经指定把反向隧道用于某些特定的应用。
   涉及到外地代理的未经
认证的数据交换将使得恶意的节点伪装成合法的移动节点，并把现存的隧道重定向到另一个家乡代理,或者是另一个恶意的节点。防止这种攻击的最好的方法就是使用移动IP规范（参考文献[1]）中的Mobile-Foreign以及Foreign-Home 认证扩展。
   如果所需的移动安全联合不可用，本文档介绍一种机制来减少这种攻击的范围和效力。移动节点必须把发给外地代理的注册请求中IP头部的TTL设置为255。这就防止了远于一跳（hop）之外的恶意节点伪装成合法节点。注册拒绝中其它的错误码（失败码）使得对这种确实发生的攻击的跟踪变得更容易。
   为了进一步减少这种攻击，移动IP工作组考虑了涉及到使用未认证状态的其它机制。但是，但是这些机制引入了拒绝服务攻击。大家一致认为在只提供很弱的（不加密的）保护来防止攻击的机制之间很难折衷。
6.2. 入口处过滤
   出现入口处过滤的反向隧道的长效性已经有一些问题。推想是网络管理员将把通过反向隧道的数据包（使用IP-in-IP封装的数据包）作为过滤的目标。入口处过滤的建议清楚地说明为什么不是如此（参考文献[8]）:
      当攻击的源变得更像“合法”时，对它的跟踪将变得更简单。
7. 致谢
   封装发送方式由Charlie Perkins提出。Jim Solomon的建议使得本文当形成现在的样子。 
参考文献
   [1] Perkins, C., “IP的移动性支持（移动IP规范）”, RFC 2002, October 1996.

   [2] Perkins, C., “在IP内封装IP（IP-in-IP封装）”, RFC 2003, October
       1996.

   [3] Computer Emergency Response Team (CERT), “IP欺诈攻击及劫持连接终端” , CA-95:01, January 1995。可通过匿名ftp从info.cert.org       in/pub/cert_advisories获得。

   [4] Johnson, D., and C. Perkins, “移动IP中的路由优化”,正在制订中。

   [5] Manuel Rodriguez, private communication, August 1995.

   [6] Atkinson, R., “IP认证头部”, RFC 1826, August 1995.

   [7] Atkinson, R., “封装安全净载的IP”, RFC 1827,  August 1995.

   [8] Ferguson, P., and D. Senie, “网络入口点过滤：挫败使用源IP地址的拒绝服务攻击”, RFC 2267, January 1998.

   [9] Bradner, S., “RFC中表明条件级别所使用的关键词”, BCP 14, RFC 2119, March 1997.

编辑和主席地址

   本文档的问题可以直接按以下方式联系：
   Gabriel E. Montenegro
   Sun Microsystems, Inc.
   901 San Antonio Road
   Mailstop UMPK 15-214
   Mountain View, California 94303

   Voice:  +1-415-786-6288
   Fax:    +1-415-786-6445
   EMail: gabriel.montenegro@eng.sun.com

   工作组可通过现任主席联系：
   Jim Solomon
   Motorola, Inc.
   1301 E. Algonquin Rd. - Rm 2240
   Schaumburg, IL  60196

   Voice:  +1-847-576-2753
   Fax:    +1-847-576-3240
   EMail: solomon@comm.mot.com


   Erik Nordmark
   Sun Microsystems, Inc.
   901 San Antonio Road
   Mailstop UMPK17-202
   Mountain View, California 94303

   Voice:  +1-415-786-5166
   EMail: erik.nordmark@eng.sun.com
完整版权通告
   Copyright (C) The Internet Society (1998).  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


RFC2344 Reverse Tunneling for Mobile IP                              RFC2344  移动IP反向隧道

1


1
中文文档翻译计划