计算机,外文翻译

《计算机,外文翻译》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

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

1译文标题IPEncapsulationwithinIP原文标题在IP数据包内封装IP作者InternetEngineeringTaskForce译名Internet工程任务组国籍美国原文出处RequestForComments2003译文：在IP数据包内封装IP摘要本文档描述了一种方法，通过该IP数据报可能被一个IP数据报中封装（作为净负载）。封装建议，以改变正常的IP路由数据报，由他们来提供，否则将不会被IP目的地址字段（的网络部分）的原始IP报头中选择了一个中间目的地的一种手段。封装可以用于各种目的，例如把数据报传送到使用移动IP的移动节点。1.简介本文档描述了一种方法，通过该IP数据报可能被一个IP数据报中封装（作为净负载）。封装被建议作为改变正常的IP路由数据包，通过将其提供给，否则将根据原始IP头中的IP目的地址字段（网络的一部分）不能被选择的中间目的地的装置。一旦被封装的数据报到达该中间目的节点时，它被解封，得到原始的IP数据报，然后将其输送到由原始目标地址字段所指示的目的地。这种使用封装数据报的封装和解封装的是经常被称为“隧道”的数据报，而封装和拆封，然后认为是隧道的“端点二在最常见的隧道中我们有：source--->encapsulator>decapsulator--->destination其中source,encapsulator,decapsulator和destination是独立的节点。encapsulator节点称为隧道的“入口”，而decapsulator节点称为隧道的“出口点”。在封装与拆分的过程中同-一个隧道通常可能有多个source-destination对。2.动机移动IP工作组已经规定把封装作为--种从移动节点的“家庭网络”传送数据包，可以通过常规手段本地传送数据包在其当前位置远离家乡的移动节点的代理。封装的使用也可能需要在IP数据报的源极（或中间路由器）必须影响一个数据报将被传递到其最终目的地的路由。封装的其他可能的应用包括多播，计费，选择与选定的安全属性路线，和一般的策略路由。这通常是真实的封装和IP松散源路由选项可以以类似的方式影响一个数据报的路由可以使用，但有儿个技术上的原因更喜欢封装：

2-有与使用有关的未解决的安全问题的IP源路由选项。-当前互联网路由器展品的性能问题转发含有IP选项，包括IP源路由选项的数据报的时候。-目前，很多网络节点处理IP源路由选项不正确。-防火墙可以排除的IP源路由数据包。一个IP源路由选项插入可以由数据包的源和/或目的地复杂的认证信息的处理，根据不同的身份验证是如何指定要执行的。-这被认为是不礼貌的中间路由器进行修改的数据报，他们没有起源。这些技术优势必须权衡通过使用封装所带来的弊端：-封装的数据包通常比源路由数据包较大。-封装不能使用，除非它是事先知道的，在隧道的出口点节点能解封装的数据报。由于多数互联网节点的今天表现不好时，IP松散源路由选项时，封装的第二次技术缺点并不像表面看起来的那样严重。3.在IP中封装IP为了使IP-in-IP来封装IP数据报，在现存IP头部前面插入外层的IP头如下所示：OuterIPHeaderI-IIPHeader||IPHeaderIPPayload||IPPayload外层IP头的源地址和目的地址确定隧道的“端点”。内层IP报头的源地址和目的地址标识原始发件人和数据报的接收方，分别为。内部IP头没有被封装改变，除非到的TTL递减如下所述，其输送到隧道的出口点期间保持不变。通过隧道传递的数据报封装过程中不改变IP选项中的内部头发生。如果需要的话，其他的协议头，如IP认证头可以在外部IP包头和内部IP头之间插入。需要注意的是内部IP头的安全选项可能会影响对封装（外）IP报头的安全选项的选择。3.1IP头部各域及管理

3外层IP头部由封装方按下面设置：Version3IHL因特网头部长度为外部IP头部的长度，用32位的字表示。TOS服务类型(TOS)从内层IP头部拷贝。TotalLengthTotalLength为整个封装后IP数据报的长度，包括外层IP头部，内层IP头部，及其净载数据。Identification,Flags,FragmentOffset这三个域按参考文献［10］进行设置.但是如果在内部IP头部设置了"Don、Fragment"位，必须在外部IP头部中设置该位;如果内部IP头部没有设置"Don、Fragment"位，在外层IP头部中可以设置该位，见5.1。TimetoLive外层IP头部的生存期(TTL)域设置为封装后数据报传输到隧道出口点所经历的大致时间。Protocol4HeaderChecksum为外层IP头部的“Internet头部检验和工SourceAddress封装方的IP地址，即隧道的入口点。DestinationAddress解封装方的IP地址，即隧道的出口点。Options

4内部IP头部中出现的选项通常不出现在外层IP头部中。但是以增加隧道自定义的选项.特别地，•些内层IP头部支持的安全选项可能影响到外层的头部安全选项的选择。并不期望在这些选项到隧道的选项或安全头部之间建立一对一的映射.在封装数据报时，如果隧道作为转发数据报的一部分，内层IP头部的TTL将减1；否则，在封装的过程中内层TTL保持不变.如果得到的内层1P头部的TTL为0,数据报被丢弃并应该向发送者产生一个TimeExceeded的ICMP信息。封装方是不会对TTL=0的数据报进行封装的。内层IP头部中的TTL在拆分的过程中保持不变。拆分后，如果内层数据报TTL=0,拆分方必须丢弃该数据报。拆分后，如果拆分方转发该数据报到它的一个网络接口，它像正常转发IP数据报那样递减1TL。见4.4。封装方可以使用现存适合的IP机制来把封装后的净载数据传送到隧道的出口点。特别地,允许使用IP选项，还可以允许分片，除非内层IP头部中设置了"Don'tFragment"位。使用该分片限制是为了使使用路径MTU发现的节点能够得到他们所要寻找的信息。3.2路由失败在隧道内部的路由环回（Routingloops）特别危险，它们使数据报再次回到封装方。假设一个数据报到达路由器等待转发，而该路由器认为该数据报在传送之前必须封装，那么：-如果该数据报的SourceAddress与路由器自己的任■个网络接口的IP地址匹配，该路由器不允许为该数据报建立隧道；相反，该数据报应该被丢弃.-如果该数据报的SourceAddress与隧道的目的IP地址匹配（隧道出口点一般由路由器根据数据报的IP头部的DestinationAddress选择），路由器不允许为该数据报建立隧道，相反，该数据报应该被丢弃，参见4.4。4.隧道内部的ICMP信息封装后的数据报被发送后，封装方可能从该隧道内的任一中间路由器而不是隧道出口接收到一条ICMP信息。封装方采取的动作取决于所收到的ICMP信息的类型.当收到的信息包含足够信息时，封装方可能使用收到的信息产生一个相似ICMP信息，发送给产生未封装IP数据报的构建者（原始发送方）。该过程称为中继来自隧道的ICMP信息。ICMP信息表明处理数据报的过程中产生一个错误，它包含引起错误的数据报的（-一部分）的一个拷贝。中继一个ICMP信息要求封装方从该返回的数据报中剥去外层IP头部。对收到不包含足够信息的ICMP信息的情况，见5。

54.1.目标不可达DestinationUnreachable(Type3)ICMP目标不可达信息由封装方根据它们的Code域进行处理。这里给出的模型允许隧道扩展到一个包括非本地节点(如移动节点)的网络。这样,如果未封装数据报中的目标地址与封装者处在同■个网络，可以修改DestinationUnreachableCode的值使之与给定模型一致。网络不可达NetworkUnreachable(Code0)一条目标不可达ICMP信息应该返回给原始发送方。如果未封装数据报的目的地址与封装者处在同个网络上，封装后新产生的目标不可达信息应该为Code=l(HostUnreachable),因为推测数据报到达了正确的网络而且封装方把最初的目的地址视为该网络的本地地址，即使事实并非如此。否则(目的地址与封装者处在不同的网络上)，如果封装者返回目标不可达信息，Code域必须设置为0(NetworkUnreachable)o主机不可达HostUnreachable(Code1)封装者应该尽可能把该主机不可达信息中继到未封装数据报的发送者。协议不可达ProtocolUnreachable(Code2)当收到协议不可达ICMP,封装方应该向为封装数据报的发送方发送一个Code域为0或1的目标不可达信息。(见Code为0部分)。因为原始发送方没有使用协议号为4来发送该数据报，将向该发送方返回Code2o端口不可达PortUnreachable(Code3)该代号应该从不被封装方接收，因位外层IP头部不指定任何端口号。不允许把该代号发送给未封装数据报的发送方。数据报太大DatagramTooBig(Code4)封装方必须把数据报太大的ICMP数据报中继给未封装数据报的发送方。源路由失败SourceRouteFailed(Code5)该代号应该由封装方自己处理。不允许把它中继给未封装数据报的原始发送方。4.2.源淹没SourceQuench(Type4)封装方不应该把源淹没信息中继给未封装数据报的发送方,但应该激活所使用的拥塞控制机制以帮助减轻隧道内部所检测到的拥塞。4.3.重定向Redirect(Type5)封装方可能自己处理重定向ICMP信息。不允许把重定向中继到为封装数据报的发送方。4.4.超时（Type11）超时ICMP

6信息在隧道自身内部报告（推测）路由环回。封装方收到超时信息必须把该超时信息作为主机不可达（Type3,Code1）信息向未封装数据报的发送方报告。主机不可达比网络不可达更优越；因为数据报由封装方处理，封装方通常被视为未封装数据报的目的地址且位于相同的网络上，数据报被视为到达正确的网络，但错误的目标节点。4.1.参数问题ParameterProblem（Type12）如果参数问题指向从未封装数据报中拷贝而来的某个域，封装方可能把该ICMP信息中继给未封装数据报的发送方；否则，如果问题是由封装方插入的IP选项引起，封装方不允许把该ICMP信息中继给发送方。注意遵循实际情况的封装方永不会把IP选项插入到封装的数据报中，除非出于安全原因。4.2.其他ICMP信息其他ICMP信息与本协议规范中的封装无关，封装方应该遵循相应的规范。5.隧道管理不幸的是,ICMP仅要求IP路由器返回IP头部之外的8个字节（64bits）。这不足以包括一个封装后（内层）IP头部的一个拷贝,所以封装方不总是能把隧道内部的ICMP信息中继给原发送方。但是，通过仔细维护隧道的“软状态”，封装方可在大多数情况下把精确的ICMP信息返回给发送者，封装方应该至少维护每一个隧道的下述软状态信息：-隧道的MTU（见5.1章）-隧道的TTL（路径长度pathlength）-隧道端点的可达性封装方使用它收到的来自隧道内部的ICMP信息更新该隧道的软状态信息。可能从隧道中的路由器返回的ICMP错误包括：-数据报太大-超时-目标不可达-源淹没当随后经过该隧道的数据报到达时，封装方（器）检查该隧道的软状态.如果该数据报与隧道的当前状态冲突（新数据报的TTL小于隧道的“软状态"TTL）封装方向原始数据报的发送方送回一个ICMP错误信息，但还是封装该数据报并把它转交给隧道。使用这种技术，用封装方发送的ICMP错误信息不会总是与隧道内部发生的错误一一匹配，但它们可以精确地反映网络的状态。

75.1.隧道MTU发现如果源发送方设置了Don'tFragment位并被拷贝到外层IP头部中，可以通过报告给封装方的DatagramTooBig（Type3,Code4）ICMP信息得知隧道的MTU.为支持使用路径MTU发现的发送节点，所有封装实现必须支持隧道内部“路径MTU发现”软状态。在这种特殊应用中，有几个好处：-分片（由于封装头部的大小）将作为路径MTU发现的受益者，在封装后只执行一次。这将阻止对一个数据报进行多次分片，提高拆分方和隧道内部的处理效率。-如果未封装数据报的源正在做路径MTU发现,那么要求封装方知道隧道的MTUo任何来自隧道内部的DatagramTooBig信息被返回到封装方，正如在5中所注的那样,封装方不可能把所有ICMP信息中继给未封装数据报的发送方。通过维护隧道MTU的软状态，封装方可以把正确的DatagramTooBig信息返回给未封装数据报的发送方以支持它自己的路径MTU发现.在这种情况下，由封装方发送给原发送方的MTU应该是隧道的MTU减去正封装的IP头部的大小。这将避免最初IP数据报被封装方分片。-如果未封装数据报的源不在做路径MTU发现,封装方仍然需要知道隧道的MTU。特别地，在封装时对原始数据报进行分片比允许对封装后的数据报分片要好得多。对原始数据报的分片可由封装方完成，且不需要特殊缓冲要求，也不需要在拆分方保存重新装配的状态。相比之下，如果对封装后的数据报进行分片，那么拆分方必须在拆分前重新组装分片（封装后）后的数据报，这就要求在拆分方重新组装状态和缓冲空间。这样，封装方正常情况下应该做路径MTU发现，要求封装方在所有送往隧道的数据报均在IP头部设置"DoniFragment"位。但是该方法带来几个问题。当原始发送方设置"Don'tFragment"位时，发送方能通过重传原始数据报来对返回的DatagramTooBigICMP错误信息迅速做出反应。另一方面，假定封装方收到来自隧道内部的DatagramTooBigICMP错误信息，如果未封装数据报的发送者没有设置"DoniFragment"位,封装方将无法让原始发送方知道该错误。封装方可能在试图递增隧道的MTU时保存已发送数据报的•份拷贝，以允许它在收到DatagramTooBig响应时分片并重传该数据报。另一种选择是在未封装数据报没有设置"DoniFragment"位时，封装方可以设置某些类型的数据报不设置"DoniFragment"位。5.2.拥塞封装方可能收到来自隧道内部的拥塞的暗示，例如，收到隧道内部的源淹没

8（SourceQuench）ICMP信息。另外，与Internet无关的链路层以及各种协议可能以CongestionExperienced标志位的形式提供该暗示。封装方应该在隧道的软状态中反映拥塞状态，在随后向隧道转发数据报时，封装方应该使用适当手段来对拥塞进行控制；但是，封装方不应该向位封装数据报的发送方发送源淹没（SourceQuench）ICMP信息。6.安全方面的考虑IP封装潜在地降低了Internet的安全性，所以在使用IP封装时应该注意。例如IP封装使边沿路由器很难根据其头部对数据报进行过滤。特别是,IP头部的原始的SourceAddress,DestinationAddress和Protocol各域,以及数据报中传输层头部使用的端口号，在封装后并不处在它们正常的位置。因为任何IP数据报能被封装并通过隧道传输，这样的过滤边沿路由器需要认真检查每一个数据报。6.1.路由器方面的考虑路由器需要知道的IP封装协议，以便正确地过滤传入的数据报。期望的是，这样的滤波可以与IP验证集成。其中IP验证时，封装的数据包可能会被允许进入一个组织时的封装（外部）数据包或封装（内部）数据包是通过一个认证，TrustedSource的发送。不包含这样的认证Enc叩uslated包代表一个潜在的大的安全隐患。这是封装和加密IP数据报也可能造成问题的过滤路由器。在这种情况下，路由器可以过滤该数据报仅当它共享用于加密的安全关联。要允许这样的加密环境中的所有数据包需要在其中进行过滤（或至少占了），一个机制必须到位，为接收节点进行安全通信的安全关联的边界路由器。这可能会较为罕见，也适用于用于输出数据报的安全关联。6.2.主机方面的考虑能够接收封装后的IP数据报的主机应该只接受符合下面儿种类型的一种或多种数据报：-协议无害:不需要进行基于源地址的身份认证。-正封装的(外层)数据报来自认证识别的可信的源，源的真实性建立于物理安全和边沿路由器的配置，但更可能来自IP身份认证头部.-封装后的(内层)数据报包括一个IP身份认证头部-封装后的(内层)数据报送到属于拆分方的网络接口，或者拆分方已与之建立特殊关系以传输这些封装后数据报的节点。这些检查的某些或全部在边沿路由器而不是接受节点进行，但如果边沿路由器检查作为备份而不是仅仅作为检察会更好。

9原文：IPEncapsulationwithinIPAbstractThisdocumentspecifiesamethodbywhichanIPdatagrammaybeencapsulated(carriedaspayload)withinanIPdatagram.EncapsulationissuggestedasameanstoalterthenormalIProutingfordatagrams,bydeliveringthemtoanintermediatedestinationthatwouldotherwisenotbeselectedbythe(networkpartofthe)IPDestinationAddressfieldintheoriginalIPheader.Encapsulationmayserveavarietyofpurposes,suchasdeliveryofadatagramtoamobilenodeusingMobileIP.1.IntroductionThisdocumentspecifiesamethodbywhichanIPdatagrammaybeencapsulated(carriedaspayload)withinanIPdatagram.EncapsulationissuggestedasameanstoalterthenormalIProutingfordatagrams,bydeliveringthemtoanintermediatedestinationthatwouldotherwisenotbeselectedbasedonthe(networkpartofthe)IPDestinationAddressfieldintheoriginalIPheader.Oncetheencapsulateddatagramarrivesatthisintermediatedestinationnode,itisdecapsulated,yieldingtheoriginalIPdatagram,whichisthendeliveredtothedestinationindicatedbytheoriginalDestinationAddressfield.Thisuseofencapsulationanddecapsulationofadatagramisfrequentlyreferredtoas"tunneling"thedatagram,andtheencapsulatoranddecapsulatorarethenconsideredtobethe"endpoints”ofthetunnel.Inthemostgeneraltunnelingcasewehave:source■■->encapsulator>decapsulator--->destinationwiththesource,encapsulator,decapsulator,anddestinationbeingseparatenodes.Theencapsulatornodeisconsideredthe“entrypoint"ofthetunnel,andthedecapsulatornodeisconsideredthe"exitpoint*'ofthetunnel.Thereingeneralmaybemultiplesource-destinationpairsusingthesametunnelbetweentheencapsulatoranddecapsulator.2.MotivationTheMobileIPworkinggrouphasspecifiedtheuseofencapsulationasawaytodeliverdatagramsfromamobilenode's"homenetwork**toanagentthatcandeliverdatagramslocallybyconventionalmeanstothemobilenodeatitscurrentlocationawayfromhome.Theuseofencapsulationmayalsobedesirablewheneverthesource(oranintermediaterouter)ofanIPdatagrammustinfluencetheroutebywhichadatagramistobedeliveredtoitsultimate

10destination.Otherpossibleapplicationsofencapsulationincludemulticasting,preferentialbilling,choiceofrouteswithselectedsecurityattributes,andgeneralpolicyrouting.ItisgenerallytruethatencapsulationandtheIPloosesourceroutingoption[10]canbeusedinsimilarwaystoaffecttheroutingofadatagram,butthereareseveraltechnicalreasonstopreferencapsulation:-ThereareunsolvedsecurityproblemsassociatedwiththeuseoftheIPsourceroutingoptions.-CurrentInternetroutersexhibitperformanceproblemswhenforwardingdatagramsthatcontainIPoptions,includingtheIPsourceroutingoptions.-ManycurrentInternetnodesprocessIPsourceroutingoptionsincorrectly.-FirewallsmayexcludeIPsource-routeddatagrams.-InsertionofanIPsourcerouteoptionmaycomplicatetheprocessingofauthenticationinformationbythesourceand/ordestinationofadatagram,dependingonhowtheauthenticationisspecifiedtobeperformed.-Itisconsideredimpoliteforintermediaterouterstomakemodificationstodatagramswhichtheydidnotoriginate.Thesetechnicaladvantagesmustbeweighedagainstthedisadvantagesposedbytheuseofencapsulation:-Encapsulateddatagramstypicallyarelargerthansourcerouteddatagrams.-Encapsulationcannotbeusedunlessitisknowninadvancethatthenodeatthetunnelexitpointcandecapsulatethedatagram.SincethemajorityofInternetnodestodaydonotperformwellwhenIPloosesourcerouteoptionsareused,thesecondtechnicaldisadvantageofencapsulationisnotasseriousasitmightseematfirst.3.IPinIPEncapsulationToencapsulateanIPdatagramusingIPinIPencapsulation,anouterIPheaderisinsertedbeforethedatagram'sexistingIPheader,asfollows:h+OuterIPHeaderIIH+4-+

11IIPHeader||IPHeader|IIIIH+====>—+IIIIIIII|IPPayload||IPPayload|IIIIT+H+TheouterIPheaderSourceAddressandDestinationAddressidentifythe"endpoints**ofthetunnel.TheinnerIPheaderSourceAddressandDestinationAddressesidentifytheoriginalsenderandrecipientofthedatagram,respectively.TheinnerIPheaderisnotchangedbytheencapsulator,excepttodecrementtheTTLasnotedbelow,andremainsunchangedduringitsdeliverytothetunnelexitpoint.NochangetoIPoptionsintheinnerheaderoccursduringdeliveryoftheencapsulateddatagramthroughthetunnel.Ifneedbe,otherprotocolheaderssuchastheIPAuthenticationheadermaybeinsertedbetweentheouterIPheaderandtheinnerIPheader.NotethatthesecurityoptionsoftheinnerIPheadermayaffectthechoiceofsecurityoptionsfortheencapsulating(outer)IPheader.3.1.IPHeaderFieldsandHandlingThefieldsintheouterIPheaderaresetbytheencapsulatorasfollows:Version4IHLTheInternetHeaderLength(IHL)isthelengthoftheouterIPheadermeasuredin32-bitwords.TOSTheTypeofService(TOS)iscopiedfromtheinnerIPheader.TotalLengthTheTotalLengthmeasuresthelengthoftheentireencapsulatedIPdatagram,includingtheouterIPheader,theinnerIPheader,anditspayload.Identification,Flags,FragmentOffsetThesethreefieldsaresetasspecifiedin[10].However,ifthe"Don'tFragment"bitissetintheinnerIPheader,itmustbesetintheouterIPheader;ifthe"Don'tFragment"bitisnotsetintheinnerIPheader,itmaybesetintheouterIPheader,asdescribedinSection5.1.

12TimetoLiveTheTimeToLive(TTL)fieldintheouterIPheaderissettoavalueappropriatefordeliveryoftheencapsulateddatagramtothetunnelexitpoint.Protocol4HeaderChecksumTheInternetHeaderchecksum[10]oftheouterIPheader.SourceAddressTheIPaddressoftheencapsulator,thatis,thetunnelentrypoint.DestinationAddressTheIPaddressofthedecapsulator,thatis,thetunnelexitpoint.OptionsAnyoptionspresentintheinnerIPheaderareingeneralnotcopiedtotheouterIPheader.However,newoptionsspecifictothetunnelpathmaybeadded.Inparticular,anysupportedtypesofsecurityoptionsoftheinnerIPheadermayaffectthechoiceofsecurityoptionsfortheouterheader.Itisnotexpectedthattherebeaone-to-onemappingofsuchoptionstotheoptionsorsecurityheadersselectedforthetunnel.Whenencapsulatingadatagram,theTTLintheinnerIPheaderisdecrementedbyoneifthetunnelingisbeingdoneaspartofforwardingthedatagram;otherwise,theinnerheaderTTLisnotchangedduringencapsulation.IftheresultingTTLintheinnerIPheaderis0,thedatagramisdiscardedandanICMPTimeExceededmessageshouldbereturnedtothesender.AnencapsulatormustnotencapsulateadatagramwithTTL=0.TheTTLintheinnerIPheaderisnotchangedwhendecapsulating.If,afterdecapsulation,theinnerdatagramhasTTL=0,thedecapsulatormustdiscardthedatagram.If,afterdecapsulation,thedecapsulatorforwardsthedatagramtooneofitsnetworkinterfaces,itwilldecrementtheTTLasaresultofdoingnormalIPforwarding.SeealsoSection4.4.TheencapsulatormayuseanyexistingIPmechanismsappropriatefordeliveryoftheencapsulatedpayloadtothetunnelexitpoint.Inparticular,useofIPoptionsisallowed,anduseoffragmentationisallowedunlessthe"Don'tFragment"bitissetintheinnerIPheader.ThisrestrictiononfragmentationisrequiredsothatnodesemployingPathMTUDiscoverycan

13obtaintheinformationtheyseek.3.1.RoutingFailuresRoutingloopswithinatunnelareparticularlydangerouswhentheycausedatagramstoarriveagainattheencapsulator.Supposeadatagramarrivesatarouterforforwarding,andtherouterdeterminesthatthedatagramhastobeencapsulatedbeforefurtherdelivery.Then:-IftheIPSourceAddressofthedatagrammatchestherouter'sownIPaddressonanyofitsnetworkinterfaces,theroutermustnottunnelthedatagram;instead,thedatagramshouldbediscarded.-IftheIPSourceAddressofthedatagrammatchestheIPaddressofthetunneldestination(thetunnelexitpointistypicallychosenbytherouterbasedontheDestinationAddressinthedatagram'sIPheader),theroutermustnottunnelthedatagram;instead,thedatagramshouldbediscarded.SeealsoSection4.4.4.ICMPMessagesfromwithintheTunnelAfteranencapsulateddatagramhasbeensent,theencapsulatormayreceiveanICMPmessagefromanyintermediaterouterwithinthetunnelotherthanthetunnelexitpoint.TheactiontakenbytheencapsulatordependsonthetypeofICMPmessagereceived.Whenthereceivedmessagecontainsenoughinformation,theencapsulatormayusetheincomingmessagetocreateasimilarICMPmessage,tobesenttotheoriginatoroftheoriginalunencapsulatedIPdatagram(theoriginalsender).Thisprocesswillbereferredtoas"relaying"theICMPmessagefromthetunnel.ICMPmessagesindicatinganerrorinprocessingadatagramincludeacopyof(aportionof)thedatagramcausingtheerror.RelayinganICMPmessagerequiresthattheencapsulatorstripofftheouterIPheaderfromthisreturnedcopyoftheoriginaldatagram.ForcasesinwhichthereceivedICMPmessagedoesnotcontainenoughdatatorelaythemessage,seeSection5.4.1.DestinationUnreachable(Type3)ICMPDestinationUnreachablemessagesarehandledbytheencapsulatordependingupontheirCodefield.Themodelsuggestedhereallowsthetunnelto"extend"anetworktoincludenon-local(e.g.,mobile)nodes.Thus,iftheoriginaldestinationintheunencapsulateddatagramisonthesamenetworkastheencapsulator,certainDestinationUnreachableCodevaluesmay

14bemodifiedtoconformtothesuggestedmodel.NetworkUnreachable(Code0)AnICMPDestinationUnreachablemessageshouldbereturnedtotheoriginalsender.Iftheoriginaldestinationintheunencapsulateddatagramisonthesamenetworkastheencapsulator,thenewlygeneratedDestinationUnreachablemessagesentbytheencapsulatormayhaveCode1(HostUnreachable),sincepresumablythedatagramarrivedatthecorrectnetworkandtheencapsulatoristryingtocreatetheappearancethattheoriginaldestinationislocaltothatnetworkevenifitisnot.Otherwise,iftheencapsulatorreturnsaDestinationUnreachablemessage,theCodefieldmustbesetto0(NetworkUnreachable).HostUnreachable(Code1)TheencapsulatorshouldrelayHostUnreachablemessagestothesenderoftheoriginalunencapsulateddatagram,ifpossible.ProtocolUnreachable(Code2)WhentheencapsulatorreceivesanICMPProtocolUnreachablemessage,itshouldsendaDestinationUnreachablemessagewithCode0or1(seethediscussionforCode0)tothesenderoftheoriginalunencapsulateddatagram.Sincetheoriginalsenderdidnotuseprotocol4insendingthedatagram,itwouldbemeaninglesstoreturnCode2tothatsender.PortUnreachable(Code3)ThisCodeshouldneverbereceivedbytheencapsulator,sincetheouterIPheaderdoesnotrefertoanyportnumber.Itmustnotberelayedtothesenderoftheoriginalunencapsulateddatagram.DatagramTooBig(Code4)TheencapsulatormustrelayICMPDatagramTooBigmessagestothesenderoftheoriginalunencapsulateddatagram.SourceRouteFailed(Code5)ThisCodeshouldbehandledbytheencapsulatoritself.Itmustnotberelayedtothesenderoftheoriginalunencapsulateddatagram.3.1.SourceQuench(Type4)TheencapsulatorshouldnotrelayICMPSourceQuenchmessagestothesenderoftheoriginalunencapsulateddatagram,butinsteadshouldactivatewhatevercongestioncontrol

15mechanismsitimplementstohelpalleviatethecongestiondetectedwithinthetunnel.3.1.Redirect(Type5)TheencapsulatormayhandletheICMPRedirectmessagesitself.ItmustnotrelaytheRedirecttothesenderoftheoriginalunencapsulateddatagram.3.2.TimeExceeded(Type11)ICMPTimeExceededmessagesreport(presumed)routingloopswithinthetunnelitself.ReceptionofTimeExceededmessagesbytheencapsulatormustbereportedtothesenderoftheoriginalunencapsulateddatagramasHostUnreachable(Type3,Code1).HostUnreachableispreferabletoNetworkUnreachable;sincethedatagramwashandledbytheencapsulator,andtheencapsulatorisoftenconsideredtobeonthesamenetworkasthedestinationaddressintheoriginalunencapsulateddatagram,thenthedatagramisconsideredtohavereachedthecorrectnetwork,butnotthecorrectdestinationnodewithinthatnetwork.3.3.ParameterProblem(Type12)IftheParameterProblemmessagepointstoafieldcopiedfromtheoriginalunencapsulateddatagram,theencapsulatormayrelaytheICMPmessagetothesenderoftheoriginalunencapsulateddatagram;otherwise,iftheproblemoccurswithanIPoptioninsertedbytheencapsulator,thentheencapsulatormustnotrelaytheICMPmessagetotheoriginalsender;NotethatanencapsulatorfollowingprevalentcurrentpracticewillneverinsertanyIPoptionsintotheencapsulateddatagram,exceptpossiblyforsecurityreasons.3.4.OtherICMPMessagesOtherICMPmessagesarenotrelatedtotheencapsulationoperationsdescribedwithinthisprotocolspecification,andshouldbeactedonbytheencapsulatorasspecified.4.TunnelManagementUnfortunately,ICMPonlyrequiresIProuterstoreturn8octets(64bits)ofthedatagrambeyondtheIPheader.Thisisnotenoughtoincludeacopyoftheencapsulated(inner)IPheader,soitisnotalwayspossiblefortheencapsulatortorelaytheICMPmessagefromtheinteriorofatunnelbacktotheoriginalsender.However,bycarefullymaintaining''softstate"abouttunnelsintowhichitsends,theencapsulatorcanreturnaccurateICMPmessagestotheoriginalsenderinmostcases.Theencapsulatorshouldmaintainatleastthefollowingsoftstateinformationabouteachtunnel:

16-MTUofthetunnel(Section5.1)-TTL(pathlength)ofthetunnel-ReachabilityoftheendofthetunnelTheencapsulatorusestheICMPmessagesitreceivesfromtheinteriorofatunneltoupdatethesoftstateinformationforthattunnel.ICMPerrorsthatcouldbereceivedfromoneoftheroutersalongthetunnelinteriorinclude:-DatagramTooBig-TimeExceeded-DestinationUnreachable-SourceQuenchWhensubsequentdatagramsarrivethatwouldtransitthetunnel,theencapsulatorchecksthesoftstateforthetunnel.Ifthedatagramwouldviolatethestateofthetunnel(forexample,theTTLofthenewdatagramislessthanthetunnel"softstate"TTL)theencapsulatorsendsanICMPerrormessagebacktothesenderoftheoriginaldatagram,butalsoencapsulatesthedatagramandforwardsitintothetunnel.Usingthistechnique,theICMPerrormessagessentbytheencapsulatorwillnotalwaysmatchupone-to-onewitherrorsencounteredwithinthetunnel,buttheywillaccuratelyreflectthestateofthenetwork.5.1.TunnelMTUDiscoveryWhentheDon*tFragmentbitissetbytheoriginatorandcopiedintotheouterIPheader,theproperMTUofthetunnelwillbelearnedfromICMPDatagramTooBig(Type3,Code4)messagesreportedtotheencapsulator.TosupportsendingnodeswhichusePathMTUDiscovery,allencapsulatorimplementationsmustsupportPathMTUDiscoverysoftstatewithintheirtunnels.Inthisparticularapplication,thereareseveraladvantages:-AsabenefitofPathMTUDiscoverywithinthetunnel,anyfragmentationwhichoccursbecauseofthesizeoftheencapsulationheaderisperformedonlyonceafterencapsulation.Thispreventsmultiplefragmentationofasingledatagram,whichimprovesprocessingefficiencyofthedecapsulatorandtherouterswithinthetunnel.-IfthesourceoftheunencapsulateddatagramisdoingPathMTUDiscovery,thenitis

17desirablefortheencapsulatortoknowtheMTUofthetunnel.AnyICMPDatagramTooBigmessagesfromwithinthetunnelarereturnedtotheencapsulator,andasnotedinSection5,itisnotalwayspossiblefortheencapsulatortorelayICMPmessagestothesourceoftheoriginalunencapsulateddatagram.Bymaintaining"softstate"abouttheMTUofthetunnel,theencapsulatorcanreturncorrectICMPDatagramTooBigmessagestotheoriginalsenderoftheunencapsulateddatagramtosupportitsownPathMTUDiscovery.Inthiscase,theMTUthatisconveyedtotheoriginalsenderbytheencapsulatorshouldbetheMTUofthetunnelminusthesizeoftheencapsulatingIPheader.ThiswillavoidfragmentationoftheoriginalIPdatagrambytheencapsulator.-IfthesourceoftheoriginalunencapsulateddatagramisnotdoingPathMTUDiscovery,itisstilldesirablefortheencapsulatortoknowtheMTUofthetunnel.Inparticular,itismuchbettertofragmenttheoriginaldatagramwhenencapsulating,thantoallowtheencapsulateddatagramtobefragmented.Fragmentingtheoriginaldatagramcanbedonebytheencapsulatorwithoutspecialbufferrequirementsandwithouttheneedtokeepreassemblystateinthedecapsulator.Bycontrast,iftheencapsulateddatagramisfragmented,thenthedecapsulatormustreassemblethefragmented(encapsulated)datagrambeforedecapsulatingit,requiringreassemblystateandbufferspacewithinthedecapsulator.Thus,theencapsulatorshouldnormallydoPathMTUDiscovery,requiringittosendalldatagramsintothetunnelwiththe"Don'tFragment"bitsetintheouterIPheader.Howeverthereareproblemswiththisapproach.Whentheoriginalsendersetsthe"Don'tFragment**bit,thesendercanreactquicklytoanyreturnedICMPDatagramTooBigerrormessagebyretransmittingtheoriginaldatagram.Ontheotherhand,supposethattheencapsulatorreceivesanICMPDatagramTooBigmessagefromwithinthetunnel.Inthatcase,iftheoriginalsenderoftheunencapsulateddatagramhadnotsetthe"Don'tFragmentnbit,thereisnothingsensiblethattheencapsulatorcandotolettheoriginalsenderknowoftheerror.TheencapsulatorMAYkeepacopyofthesentdatagramwheneverittriesincreasingthetunnelMTU,inordertoallowittofragmentandresendthedatagramifitgetsaDatagramTooBigresponse.AlternativelytheencapsulatorMAYbeconfiguredforcertaintypesofdatagramsnottosetthe"Don'tFragment**bitwhentheoriginalsenderoftheunencapsulateddatagramhasnotsetthe"Don't

18Fragment"bit.5.1.CongestionAnencapsulatormightreceiveindicationsofcongestionfromthetunnel,forexample,byreceivingICMPSourceQuenchmessagesfromnodeswithinthetunnel.Inaddition,certainlinklayersandvariousprotocolsnotrelatedtotheInternetsuiteofprotocolsmightprovidesuchindicationsintheformofaCongestionExperiencedflag.Theencapsulatorshouldreflectconditionsofcongestioninits“softstatenforthetunnel,andwhensubsequentlyforwardingdatagramsintothetunnel,theencapsulatorshoulduseappropriatemeansforcontrollingcongestion;However,theencapsulatorshouldnotsendICMPSourceQuenchmessagestotheoriginalsenderoftheunencapsulateddatagram.6.SecurityConsiderationsIPencapsulationpotentiallyreducesthesecurityoftheInternet,andcareneedstobetakenintheimplementationanddeploymentofIPencapsulation.Forexample,IPencapsulationmakesitdifficultforborderrouterstofilterdatagramsbasedonheaderfields.Inparticular,theoriginalvaluesoftheSourceAddress,DestinationAddress,andProtocolfieldsintheIPheader,andtheportnumbersusedinanytransportheaderwithinthedatagram,arenotlocatedintheirnormalpositionswithinthedatagramafterencapsulation.SinceanyIPdatagramcanbeencapsulatedandpassedthroughatunnel,suchfilteringborderroutersneedtocarefullyexaminealldatagrams.6.1.RouterConsiderationsRoutersneedtobeawareofIPencapsulationprotocolsinordertocorrectlyfilterincomingdatagrams.ItisdesirablethatsuchfilteringbeintegratedwithIPauthentication.WhereIPauthenticationisused,encapsulatedpacketsmightbeallowedtoenteranorganizationwhentheencapsulating(outer)packetortheencapsulated(inner)packetissentbyanauthenticated,trustedsource.Encapuslatedpacketscontainingnosuchauthenticationrepresentapotentiallylargesecurityrisk.IPdatagramswhichareencapsulatedandencryptedmightalsoposeaproblemforfilteringrouters.Inthiscase,theroutercanfilterthedatagramonlyifitsharesthesecurityassociationusedfortheencryption.Toallowthissortofencryptioninenvironmentsinwhichallpacketsneedtobefiltered(oratleastaccountedfor),amechanismmustbeinplaceforthereceiving

19nodetosecurelycommunicatethesecurityassociationtotheborderrouter.Thismight,morerarely,alsoapplytothesecurityassociationusedforoutgoingdatagrams.6.1.HostConsiderationsHostimplementationsthatarecapableofreceivingencapsulatedIPdatagramsshouldadmitonlythosedatagramsfittingintooneormoreofthefollowingcategories:-Theprotocolisharmless:sourceaddress-basedauthenticationisnotneeded.-Theencapsulating(outer)datagramcomesfromanauthenticallyidentified,trustedsource.Theauthenticityofthesourcecouldbeestablishedbyrelyingonphysicalsecurityinadditiontoborderrouterconfiguration,butismorelikelytocomefromuseoftheIPAuthenticationheader.-Theencapuslated(inner)datagramincludesanIPAuthenticationheader.-Theencapsulated(inner)datagramisaddressedtoanetworkinterfacebelongingtothedecapsulator,ortoanodewithwhichthedecapsulatorhasenteredintoaspecialrelationshipfordeliveringsuchencapsulateddatagrams.Someorallofthischeckingcouldbedoneinborderroutersratherthanthereceivingnode,butitisbetterifborderrouterchecksareusedasbackup,ratherthanbeingtheonlycheck.

20指导教师评语外文翻译成绩:指导教师签字: