计算机,外文翻译.docx

《计算机,外文翻译.docx》由会员分享，可在线阅读，更多相关《计算机,外文翻译.docx（21页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、密级分类号编号成绩以孑秋天工嗦卑悦本科生毕业设计（论文）外文翻译原文标题IP Encapsulation within IP译文标题在IP数据包内封装IP作者所在系别计算机科学与工程系作者所在专业网络工程作者所在班级B10521作者姓名崇延军作者学号20104052128指导教师姓名安志远指导教师职称教授完成时间2013年12月北华航天工业学院教务处制译文标题IP Encapsulation within IP原文标题在IP数据包内封装IP作者Internet Engineering Task Force译名Internet工程任务组国籍美国原文出处Request For Comments 2

2、003译文：在IP数据包内封装IP摘要本文档描述了一种方法，通过该IP数据报可能被一个IP数据报中封装（作为净负载）。封装建议，以改变正常的IP路由数据报，由他们来提供，否则将不会被IP目的地址字段（的网络部分）的原始IP报头中选择了一个中间目的地的一种手段。封装可以用于各种目的，例如把数据报传送到使用移动IP的移动节点。1 .简介本文档描述了一种方法，通过该IP数据报可能被一个IP数据报中封装（作为净负载）。封装被建议作为改变正常的IP路由数据包，通过将其提供给，否则将根据原始IP头中的IP目的地址字段（网络的一部分）不能被选择的中间目的地的装置。一旦被封装的数据报到达该中间目的节点时，它被

3、解封，得到原始的IP数据报，然后将其输送到由原始目标地址字段所指示的目的地。这种使用封装数据报的封装和解封装的是经常被称为“隧道”的数据报，而封装和拆封，然后认为是隧道的“端点二在最常见的隧道中我们有：source - encapsulator decapsulator - destination其中 source, encapsulator, decapsulator 和 destination 是独立的节点。encapsulator 节点称为隧道的“入口”，而decapsulator节点称为隧道的“出口点”。在封装与拆分的过程中同-一个隧道通常可能有多个source-destination

4、对。2 .动机移动IP工作组已经规定把封装作为-种从移动节点的“家庭网络”传送数据包，可以通过常规手段本地传送数据包在其当前位置远离家乡的移动节点的代理。封装的使用也可能需要在IP数据报的源极（或中间路由器）必须影响一个数据报将被传递到其最终目的地的路由。封装的其他可能的应用包括多播，计费，选择与选定的安全属性路线，和一般的策略路由。这通常是真实的封装和IP松散源路由选项可以以类似的方式影响一个数据报的路由可以使用，但有儿个技术上的原因更喜欢封装：-有与使用有关的未解决的安全问题的IP源路由选项。- 当前互联网路由器展品的性能问题转发含有IP选项，包括IP源路由选项的数据报的时候。- 目前，很

5、多网络节点处理IP源路由选项不正确。- 防火墙可以排除的IP源路由数据包。一个IP源路由选项插入可以由数据包的源和/或目的地复杂的认证信息的处理，根据不同的身份验证是如何指定要执行的。- 这被认为是不礼貌的中间路由器进行修改的数据报，他们没有起源。这些技术优势必须权衡通过使用封装所带来的弊端：- 封装的数据包通常比源路由数据包较大。-封装不能使用，除非它是事先知道的，在隧道的出口点节点能解封装的数据报。由于多数互联网节点的今天表现不好时，IP松散源路由选项时，封装的第二次技术缺点并不像表面看起来的那样严重。3 .在IP中封装IP为了使IP-in-IP来封装IP数据报，在现存IP头部前面插入外层

6、的IP头如下所示：Outer IP HeaderI -IIP Header|IP HeaderIP Payload|IP Payload外层IP头的源地址和目的地址确定隧道的“端点”。内层IP报头的源地址和目的地址标识原始发件人和数据报的接收方，分别为。内部IP头没有被封装改变，除非到的TTL递减如下所述，其输送到隧道的出口点期间保持不变。通过隧道传递的数据报封装过程中不改变IP选项中的内部头发生。如果需要的话，其他的协议头，如IP认证头可以在外部IP包头和内部IP头之间插入。需要注意的是内部IP头的安全选项可能会影响对封装（外）IP报头的安全选项的选择。3.1 IP头部各域及管理外层IP头部

7、由封装方按下面设置：Version4IHL因特网头部长度为外部IP头部的长度，用32位的字表示。TOS服务类型(TOS)从内层IP头部拷贝。Total LengthTotal Length为整个封装后IP数据报的长度，包括外层IP头部，内层IP头部，及其净载数据。Identification, Flags, Fragment Offset这三个域按参考文献10进行设置.但是如果在内部IP头部设置了Don、Fragment位，必须在外部IP头部中设置该位;如果内部IP头部没有设置Don、Fragment位，在外层IP头部中可以设置该位，见5.1。Time to Live外层IP头部的生存期(TT

8、L)域设置为封装后数据报传输到隧道出口点所经历的大致时间。Protocol4Header Checksum为外层IP头部的“Internet头部检验和工Source Address封装方的IP地址，即隧道的入口点。Destination Address解封装方的IP地址，即隧道的出口点。Options内部IP头部中出现的选项通常不出现在外层IP头部中。但是以增加隧道自定义的选项.特别地，些内层IP头部支持的安全选项可能影响到外层的头部安全选项的选择。并不期望在这些选项到隧道的选项或安全头部之间建立一对一的映射.在封装数据报时，如果隧道作为转发数据报的一部分，内层IP头部的TTL将减1；否则，在

9、封装的过程中内层TTL保持不变.如果得到的内层1P头部的TTL为0,数据报被丢弃并应该向发送者产生一个Time Exceeded的ICMP信息。封装方是不会对 TTL=0的数据报进行封装的。内层IP头部中的TTL在拆分的过程中保持不变。拆分后，如果内层数据报TTL=0,拆分方必须丢弃该数据报。拆分后，如果拆分方转发该数据报到它的一个网络接口，它像正常转发IP数据报那样递减1TL。见4.4。封装方可以使用现存适合的IP机制来把封装后的净载数据传送到隧道的出口点。特别地,允许使用IP选项，还可以允许分片，除非内层IP头部中设置了Dont Fragment位。使用该分片限制是为了使使用路径MTU发现

10、的节点能够得到他们所要寻找的信息。3.2路由失败在隧道内部的路由环回（Routing loops）特别危险，它们使数据报再次回到封装方。假设一个数据报到达路由器等待转发，而该路由器认为该数据报在传送之前必须封装，那么：-如果该数据报的Source Address与路由器自己的任个网络接口的IP地址匹配，该路由器不允许为该数据报建立隧道；相反，该数据报应该被丢弃.-如果该数据报的Source Address与隧道的目的IP地址匹配（隧道出口点一般由路由器根据数据报的IP头部的Destination Address选择），路由器不允许为该数据报建立隧道，相反，该数据报应该被丢弃，参见4.4。4 .

11、隧道内部的ICMP信息封装后的数据报被发送后，封装方可能从该隧道内的任一中间路由器而不是隧道出口接收到一条ICMP信息。封装方采取的动作取决于所收到的ICMP信息的类型.当收到的信息包含足够信息时，封装方可能使用收到的信息产生一个相似ICMP信息，发送给产生未封装IP数据报的构建者（原始发送方）。该过程称为中继来自隧道的ICMP 信息。ICMP信息表明处理数据报的过程中产生一个错误，它包含引起错误的数据报的（-一部分）的一个拷贝。中继一个ICMP信息要求封装方从该返回的数据报中剥去外层IP头部。对收到不包含足够信息的ICMP信息的情况，见5。4.1. 目标不可达 Destination Unr

12、eachable (Type 3)ICMP目标不可达信息由封装方根据它们的Code域进行处理。这里给出的模型允许隧道扩展到一个包括非本地节点(如移动节点)的网络。这样,如果未封装数据报中的目标地址与封装者处在同个网络，可以修改Destination Unreachable Code的值使之与给定模型一致。网络不可达 Network Unreachable (Code 0)一条目标不可达ICMP信息应该返回给原始发送方。如果未封装数据报的目的地址与封装者处在同个网络上，封装后新产生的目标不可达信息应该为Code=l (Host Unreachable),因为推测数据报到达了正确的网络而且封装方把

13、最初的目的地址视为该网络的本地地址，即使事实并非如此。否则(目的地址与封装者处在不同的网络上)，如果封装者返回目标不可达信息，Code域必须设置为0(Network Unreachable)o 主机不可达 Host Unreachable (Code 1)封装者应该尽可能把该主机不可达信息中继到未封装数据报的发送者。协议不可达 Protocol Unreachable (Code 2)当收到协议不可达ICMP,封装方应该向为封装数据报的发送方发送一个Code域为0或1的目标不可达信息。(见Code为0部分)。因为原始发送方没有使用协议号为4来发送该数据报，将向该发送方返回Code 2o端口不可

14、达 Port Unreachable (Code 3)该代号应该从不被封装方接收，因位外层IP头部不指定任何端口号。不允许把该代号发送给未封装数据报的发送方。数据报太大 Datagram Too Big (Code 4)封装方必须把数据报太大的ICMP数据报中继给未封装数据报的发送方。源路由失败 Source Route Failed (Code 5)该代号应该由封装方自己处理。不允许把它中继给未封装数据报的原始发送方。4.2. 源淹没 Source Quench (Type 4)封装方不应该把源淹没信息中继给未封装数据报的发送方,但应该激活所使用的拥塞控制机制以帮助减轻隧道内部所检测到的拥塞

15、。4.3. 重定向 Redirect (Type 5)封装方可能自己处理重定向ICMP信息。不允许把重定向中继到为封装数据报的发送方。4.4. 超时（Type 11）超时ICMP信息在隧道自身内部报告（推测）路由环回。封装方收到超时信息必须把该超时信息作为主机不可达（Type 3, Code 1）信息向未封装数据报的发送方报告。主机不可达比网络不可达更优越；因为数据报由封装方处理，封装方通常被视为未封装数据报的目的地址且位于相同的网络上，数据报被视为到达正确的网络，但错误的目标节点。4.5. 参数问题 Parameter Problem（Type 12）如果参数问题指向从未封装数据报中拷贝而来

16、的某个域，封装方可能把该ICMP信息中继给未封装数据报的发送方；否则，如果问题是由封装方插入的IP选项引起，封装方不允许把该ICMP信息中继给发送方。注意遵循实际情况的封装方永不会把IP选项插入到封装的数据报中，除非出于安全原因。4.6. 其他ICMP信息其他ICMP信息与本协议规范中的封装无关，封装方应该遵循相应的规范。5 .隧道管理不幸的是,ICMP仅要求IP路由器返回IP头部之外的8个字节（64bits）。这不足以包括一个封装后（内层）IP头部的一个拷贝,所以封装方不总是能把隧道内部的ICMP信息中继给原发送方。但是，通过仔细维护隧道的“软状态”，封装方可在大多数情况下把精确的ICMP信

17、息返回给发送者，封装方应该至少维护每一个隧道的下述软状态信息：- 隧道的MTU （见5.1章）- 隧道的TTL （路径长度path length）- 隧道端点的可达性封装方使用它收到的来自隧道内部的ICMP信息更新该隧道的软状态信息。可能从隧道中的路由器返回的ICMP错误包括：- 数据报太大- 超时- 目标不可达- 源淹没当随后经过该隧道的数据报到达时，封装方（器）检查该隧道的软状态.如果该数据报与隧道的当前状态冲突（新数据报的TTL小于隧道的“软状态 TTL）封装方向原始数据报的发送方送回一个ICMP错误信息，但还是封装该数据报并把它转交给隧道。使用这种技术，用封装方发送的ICMP错误信息不

18、会总是与隧道内部发生的错误一一匹配，但它们可以精确地反映网络的状态。5.1. 隧道MTU发现如果源发送方设置了 Dont Fragment位并被拷贝到外层IP头部中，可以通过报告给封装方的Datagram Too Big （Type 3, Code 4）ICMP信息得知隧道的MTU.为支持使用路径MTU发现的发送节点，所有封装实现必须支持隧道内部“路径MTU发现”软状态。在这种特殊应用中，有几个好处：-分片（由于封装头部的大小）将作为路径MTU发现的受益者，在封装后只执行一次。这将阻止对一个数据报进行多次分片，提高拆分方和隧道内部的处理效率。-如果未封装数据报的源正在做路径MTU发现,那么要求

19、封装方知道隧道的MTUo 任何来自隧道内部的Datagram Too Big信息被返回到封装方，正如在5中所注的那样,封装方不可能把所有ICMP信息中继给未封装数据报的发送方。通过维护隧道MTU的软状态，封装方可以把正确的Datagram Too Big信息返回给未封装数据报的发送方以支持它自己的路径MTU发现.在这种情况下，由封装方发送给原发送方的MTU应该是隧道的MTU减去正封装的IP头部的大小。这将避免最初IP数据报被封装方分片。-如果未封装数据报的源不在做路径MTU发现,封装方仍然需要知道隧道的MTU。特别地，在封装时对原始数据报进行分片比允许对封装后的数据报分片要好得多。对原始数据报

20、的分片可由封装方完成，且不需要特殊缓冲要求，也不需要在拆分方保存重新装配的状态。相比之下，如果对封装后的数据报进行分片，那么拆分方必须在拆分前重新组装分片（封装后）后的数据报，这就要求在拆分方重新组装状态和缓冲空间。这样，封装方正常情况下应该做路径MTU发现，要求封装方在所有送往隧道的数据报均在IP头部设置Doni Fragment位。但是该方法带来几个问题。当原始发送方设置Dont Fragment位时，发送方能通过重传原始数据报来对返回的Datagram Too Big ICMP错误信息迅速做出反应。另一方面，假定封装方收到来自隧道内部的 Datagram Too BigICMP错误信息，

21、如果未封装数据报的发送者没有设置Doni Fragment位,封装方将无法让原始发送方知道该错误。封装方可能在试图递增隧道的MTU时保存已发送数据报的份拷贝，以允许它在收到Datagram Too Big响应时分片并重传该数据报。另一种选择是在未封装数据报没有设置Doni Fragment位时，封装方可以设置某些类型的数据报不设置Doni Fragment位。5.2. 拥塞封装方可能收到来自隧道内部的拥塞的暗示，例如，收到隧道内部的源淹没（Source Quench） ICMP信息。另外，与Internet无关的链路层以及各种协议可能以 Congestion Experienced标志位的形式

22、提供该暗示。封装方应该在隧道的软状态中反映拥塞状态，在随后向隧道转发数据报时，封装方应该使用适当手段来对拥塞进行控制；但是，封装方不应该向位封装数据报的发送方发送源淹没（Source Quench ） ICMP信息。6.安全方面的考虑IP封装潜在地降低了 Internet的安全性，所以在使用IP封装时应该注意。例如IP 封装使边沿路由器很难根据其头部对数据报进行过滤。特别是,IP头部的原始的Source Address,Destination Address和Protocol各域,以及数据报中传输层头部使用的端口号，在封装后并不处在它们正常的位置。因为任何IP数据报能被封装并通过隧道传输，这样

23、的过滤边沿路由器需要认真检查每一个数据报。6.1. 路由器方面的考虑路由器需要知道的IP封装协议，以便正确地过滤传入的数据报。期望的是，这样的滤波可以与IP验证集成。其中IP验证时，封装的数据包可能会被允许进入一个组织时的封装（外部）数据包或封装（内部）数据包是通过一个认证，TrustedSource的发送。不包含这样的认证Enc叩uslated包代表一个潜在的大的安全隐患。这是封装和加密IP数据报也可能造成问题的过滤路由器。在这种情况下，路由器可以过滤该数据报仅当它共享用于加密的安全关联。要允许这样的加密环境中的所有数据包需要在其中进行过滤（或至少占了），一个机制必须到位，为接收节点进行安全

24、通信的安全关联的边界路由器。这可能会较为罕见，也适用于用于输出数据报的安全关联。6.2. 主机方面的考虑能够接收封装后的IP数据报的主机应该只接受符合下面儿种类型的一种或多种数据报：- 协议无害:不需要进行基于源地址的身份认证。- 正封装的(外层)数据报来自认证识别的可信的源，源的真实性建立于物理安全和边沿路由器的配置，但更可能来自IP身份认证头部.- 封装后的(内层)数据报包括一个IP身份认证头部- 封装后的(内层)数据报送到属于拆分方的网络接口，或者拆分方已与之建立特殊关系以传输这些封装后数据报的节点。这些检查的某些或全部在边沿路由器而不是接受节点进行，但如果边沿路由器检查作为备份而不是仅

25、仅作为检察会更好。原文：IP Encapsulation within IPAbstractThis document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. Encapsulation is suggested as a means to alter the normal IP routing for datagrams, by delivering them to an intermediate destination

26、 that would otherwise not be selected by the (network part of the) IP Destination Address field in the original IP header. Encapsulation may serve a variety of purposes, such as delivery of a datagram to a mobile node using Mobile IP.1. IntroductionThis document specifies a method by which an IP dat

27、agram may be encapsulated (carried as payload) within an IP datagram. Encapsulation is suggested as a means to alter the normal IP routing for datagrams, by delivering them to an intermediate destination that would otherwise not be selected based on the (network part of the) IP Destination Address f

28、ield in the original IP header. Once the encapsulated datagram arrives at this intermediate destination node,it is decapsulated, yielding the original IP datagram, which is then delivered to the destination indicated by the original Destination Address field. This use of encapsulation and decapsulat

29、ion of a datagram is frequently referred to as tunneling the datagram, and the encapsulator and decapsulator are then considered to be the endpoints” of the tunnel.In the most general tunneling case we have:source - encapsulator decapsulator - destinationwith the source, encapsulator, decapsulator,

30、and destination being separate nodes. The encapsulator node is considered the “entry point of the tunnel, and the decapsulator node is considered the exit point* of the tunnel. There in general may be multiple source-destination pairs using the same tunnel between the encapsulator and decapsulator.2

31、. MotivationThe Mobile IP working group has specified the use of encapsulation as a way to deliver datagrams from a mobile nodes home network* to an agent that can deliver datagrams locally by conventional means to the mobile node at its current location away from home . The use of encapsulation may

32、 also be desirable whenever the source (or an intermediate router) of an IP datagram must influence the route by which a datagram is to be delivered to its ultimate destination. Other possible applications of encapsulation include multicasting, preferential billing, choice of routes with selected se

33、curity attributes, and general policy routing.It is generally true that encapsulation and the IP loose source routing option 10 can be used in similar ways to affect the routing of a datagram, but there are several technical reasons to prefer encapsulation:- There are unsolved security problems asso

34、ciated with the use of the IP source routing options.- Current Internet routers exhibit performance problems when forwarding datagrams that contain IP options, including the IP source routing options.- Many current Internet nodes process IP source routing options incorrectly.- Firewalls may exclude

35、IP source-routed datagrams.- Insertion of an IP source route option may complicate the processing of authentication information by the source and/or destination of a datagram, depending on how the authentication is specified to be performed.- It is considered impolite for intermediate routers to mak

36、e modifications to datagrams which they did not originate.These technical advantages must be weighed against the disadvantages posed by the use of encapsulation:- Encapsulated datagrams typically are larger than source routed datagrams.- Encapsulation cannot be used unless it is known in advance tha

37、t the node at the tunnel exit point can decapsulate the datagram.Since the majority of Internet nodes today do not perform well when IP loose source route options are used, the second technical disadvantage of encapsulation is not as serious as it might seem at first.3. IP in IP EncapsulationTo enca

38、psulate an IP datagram using IP in IP encapsulation, an outer IP header is inserted before the datagrams existing IP header, as follows:h+Outer IP HeaderIIH+4-+IIP Header|IP Header|IIIIH+=+IIIIIIII|IP Payload|IP Payload|IIIIT+H+The outer IP header Source Address and Destination Address identify the

39、endpoints* of the tunnel. The inner IP header Source Address and Destination Addresses identify the original sender and recipient of the datagram, respectively. The inner IP header is not changed by the encapsulator, except to decrement the TTL as noted below, and remains unchanged during its delive

40、ry to the tunnel exit point. No change to IP options in the inner header occurs during delivery of the encapsulated datagram through the tunnel. If need be, other protocol headers such as the IP Authentication header may be inserted between the outer IP header and the inner IP header. Note that the

41、security options of the inner IP header may affect the choice of security options for the encapsulating (outer) IP header.3.1. IP Header Fields and HandlingThe fields in the outer IP header are set by the encapsulator as follows:Version4IHLThe Internet Header Length (IHL) is the length of the outer

42、IP header measured in 32-bit words.TOSThe Type of Service (TOS) is copied from the inner IP header.Total LengthThe Total Length measures the length of the entire encapsulated IP datagram, including the outer IP header, the inner IP header, and its payload.Identification, Flags, Fragment OffsetThese

43、three fields are set as specified in 10. However, if the Dont Fragment bit is set in the inner IP header, it must be set in the outer IP header; if the Dont Fragment bit is not set in the inner IP header, it may be set in the outer IP header, as described in Section 5.1.Time to LiveThe Time To Live

44、(TTL) field in the outer IP header is set to a value appropriate for delivery of the encapsulated datagram to the tunnel exit point.Protocol4Header ChecksumThe Internet Header checksum 10 of the outer IP header.Source AddressThe IP address of the encapsulator, that is, the tunnel entry point.Destina

45、tion AddressThe IP address of the decapsulator, that is, the tunnel exit point.OptionsAny options present in the inner IP header are in general not copied to the outer IP header. However, new options specific to the tunnel path may be added. In particular, any supported types of security options of

46、the inner IP header may affect the choice of security options for the outer header. It is not expected that there be a one-to-one mapping of such options to the options or security headers selected for the tunnel.When encapsulating a datagram, the TTL in the inner IP header is decremented by one if

47、the tunneling is being done as part of forwarding the datagram; otherwise, the inner header TTL is not changed during encapsulation. If the resulting TTL in the inner IP header is 0, the datagram is discarded and an ICMP Time Exceeded message should be returned to the sender. An encapsulator must no

48、t encapsulate a datagram with TTL =0.The TTL in the inner IP header is not changed when decapsulating. If, after decapsulation, the inner datagram has TTL =0, the decapsulator must discard the datagram. If, after decapsulation, the decapsulator forwards the datagram to one of its network interfaces, it will decrement the TTL as a result of doing no