密級(jí)

分類號(hào)

編號(hào)

成績

M罩瓶天工嚏再悅

本科生畢業(yè)設(shè)計(jì)（論文）

外文翻譯

原文標(biāo)題IPEncapsulationwithinIP

譯文標(biāo)題在IP數(shù)據(jù)包內(nèi)封裝IP

作者所在系別計(jì)算機(jī)科學(xué)與工程系

作者所在專業(yè)網(wǎng)絡(luò)工程_________________

作者所在班級(jí)B10521___________________

作者姓名崇延軍___________________

作者學(xué)號(hào)201學(xué)052128______________

指導(dǎo)教師姓名安志遠(yuǎn)___________________

指導(dǎo)教師職稱教授____________________

完成時(shí)間成13年12月

北華航天工業(yè)學(xué)院教務(wù)處制

譯文標(biāo)題IPEncapsulationwithinIP

原文標(biāo)題在IP數(shù)據(jù)包內(nèi)封裝IP

InternetEngineeringInternet工程任務(wù)

作者譯名國籍美國

TaskForce組

原文出處RequestForComments2003

譯文：在IP數(shù)據(jù)包內(nèi)封裝IP

摘要

本文檔描述了一種方法，通過該IP數(shù)據(jù)報(bào)可能被一個(gè)IP數(shù)據(jù)報(bào)中封裝（作為凈

負(fù)載）。封裝建議，以改變正常的IP路由數(shù)據(jù)報(bào)，由他們來提供，否則將不會(huì)被IP目

的地址字段（的網(wǎng)絡(luò)部分）的原始IP報(bào)頭中選擇了一個(gè)中間目的地的?種手段。封裝

可以用于各種目的，例如把數(shù)據(jù)報(bào)傳送到使用移動(dòng)IP的移動(dòng)節(jié)點(diǎn)。

1.簡介

本文檔描述了一種方法，通過該IP數(shù)據(jù)報(bào)可能被一個(gè)IP數(shù)據(jù)報(bào)中封裝（作為凈

負(fù)載）。封裝被建議作為改變正常的IP路由數(shù)據(jù)包，通過將其提供給，否則將根據(jù)原

始IP頭中的IP目的地址字段（網(wǎng)絡(luò)的一部分）不能被選擇的中間目的地的裝置。一

旦被封裝的數(shù)據(jù)報(bào)到達(dá)該中間目的節(jié)點(diǎn)時(shí)，它被解封，得到原始的IP數(shù)據(jù)報(bào)，然后將

其輸送到由原始目標(biāo)地址字段所指示的目的地。這種使用封裝數(shù)據(jù)報(bào)的封裝和解封裝

的是經(jīng)常被稱為“隧道”的數(shù)據(jù)報(bào)，而封裝和拆封，然后認(rèn)為是隧道的“端點(diǎn)”。

在最常見的隧道中我們有：

source--->encapsulator------->decapsulator--->destination

其中source,encapsulator,decapsulator和destination是獨(dú)立的節(jié)點(diǎn)。encapsulator節(jié)點(diǎn)

稱為隧道的‘'入口"，而decapsulator節(jié)點(diǎn)稱為隧道的“出口點(diǎn)”。在封裝與拆分的過程

中同一個(gè)隧道通常可能有多個(gè)source-destination對(duì)。

2.動(dòng)機(jī)

移動(dòng)IP工作組已經(jīng)規(guī)定把封裝作為一種從移動(dòng)節(jié)點(diǎn)的“家庭網(wǎng)絡(luò)”傳送數(shù)據(jù)包，

可以通過常規(guī)手段本地傳送數(shù)據(jù)包在其當(dāng)前位置遠(yuǎn)離家鄉(xiāng)的移動(dòng)節(jié)點(diǎn)的代理。封裝的

使用也可能需要在IP數(shù)據(jù)報(bào)的源極（或中間路由器）必須影響一個(gè)數(shù)據(jù)報(bào)將被傳遞到

其最終目的地的路由。封裝的其他可能的應(yīng)用包括多播，計(jì)費(fèi)，選擇與選定的安全屬

性路線，和一般的策略路由。這通常是真實(shí)的封裝和IP松散源路由選項(xiàng)可以以類似的

方式影響一個(gè)數(shù)據(jù)報(bào)的路由可以使用，但有兒個(gè)技術(shù)上的原因更喜歡封裝：

-有與使用有關(guān)的未解決的安全問題的IP源路由選項(xiàng)。

-當(dāng)前互聯(lián)網(wǎng)路由器展品的性能問題轉(zhuǎn)發(fā)含有IP選項(xiàng)，包括IP源路由選項(xiàng)的數(shù)據(jù)

報(bào)的時(shí)候。

-目前，很多網(wǎng)絡(luò)節(jié)點(diǎn)處理IP源路由選項(xiàng)不正確。

-防火墻可以排除的IP源路由數(shù)據(jù)包。

一個(gè)IP源路由選項(xiàng)插入可以由數(shù)據(jù)包的源和/或目的地復(fù)雜的認(rèn)證信息的處理，

根據(jù)不同的身份驗(yàn)證是如何指定要執(zhí)行的。

-這被認(rèn)為是不禮貌的中間路由器進(jìn)行修改的數(shù)據(jù)報(bào)，他們沒有起源。

這些技術(shù)優(yōu)勢必須權(quán)衡通過使用封裝所帶來的弊端：

-封裝的數(shù)據(jù)包通常比源路由數(shù)據(jù)包較大。

-封裝不能使用，除非它是事先知道的，在隧道的出口點(diǎn)節(jié)點(diǎn)能解封裝的數(shù)據(jù)報(bào)。

由于多數(shù)互聯(lián)網(wǎng)節(jié)點(diǎn)的今天表現(xiàn)不好時(shí)，IP松散源路由選項(xiàng)時(shí)，封裝的第二次技

術(shù)缺點(diǎn)并不像表面看起來的那樣嚴(yán)重。

3.在IP中封裝IP

為了使IP-in-IP來封裝IP數(shù)據(jù)報(bào)，在現(xiàn)存IP頭部前面插入外層的IP頭

如下所示：

H---------------------------------------------------+

OuterIPHeader|

II

T----------------------------------------------------+T-------------------------------------------------+

|IPHeader||IPHeader|

IIII

T-------------------------------------------------+====>T------------------------------------------------+

IIII

IIII

IIPPayload||IPPayload|

IIII

T----------------------------------------------------+T-------------------------------------------------+

外層IP頭的源地址和目的地址確定隧道的“端點(diǎn)內(nèi)層IP報(bào)頭的源地址和目的

地址標(biāo)識(shí)原始發(fā)件人和數(shù)據(jù)報(bào)的接收方，分別為。內(nèi)部IP頭沒有被封裝改變，除非到

的TTL遞減如下所述，其輸送到隧道的出口點(diǎn)期間保持不變。通過隧道傳遞的數(shù)據(jù)報(bào)

封裝過程中不改變IP選項(xiàng)中的內(nèi)部頭發(fā)生。如果需要的話，其他的協(xié)議頭，如IP認(rèn)

證頭可以在外部IP包頭和內(nèi)部IP頭之間插入。需要注意的是內(nèi)部IP頭的安全選項(xiàng)可

能會(huì)影響對(duì)封裝（外）IP報(bào)頭的安全選項(xiàng)的選擇。

3.1IP頭部各域及管理

外層IP頭部由封裝方按下面設(shè)置：

Version

4

IHL

因特網(wǎng)頭部長度為外部IP頭部的長度，用32位的字表示。

TOS

服務(wù)類型(TOS)從內(nèi)層IP頭部拷貝。

TotalLength

TotalLength為整個(gè)封裝后IP數(shù)據(jù)報(bào)的長度，包括外層IP頭部，內(nèi)層IP頭部，及

其凈載數(shù)據(jù)。

Identification,Flags,FragmentOffset

這三個(gè)域按參考文獻(xiàn)［10］進(jìn)行設(shè)置.但是如果在內(nèi)部IP頭部設(shè)置了”Don'tFragment"

位，必須在外部IP頭部中設(shè)置該位;如果內(nèi)部IP頭部沒有設(shè)置"Don,tFragment"位，在外

層IP頭部中可以設(shè)置該位，見5.1。

TimetoLive

外層IP頭部的生存期(TTL)域設(shè)置為封裝后數(shù)據(jù)報(bào)傳輸?shù)剿淼莱隹邳c(diǎn)所經(jīng)歷的大致

時(shí)間。

Protocol

4

HeaderChecksum

為外層IP頭部的“Internet頭部檢驗(yàn)和”。

SourceAddress

封裝方的IP地址，即隧道的入口點(diǎn)。

DestinationAddress

解封裝方的IP地址，即隧道的出口點(diǎn)。

Options

內(nèi)部IP頭部中出現(xiàn)的選項(xiàng)通常不出現(xiàn)在外層IP頭部中。但是以增加隧道自定義

的選項(xiàng).特別地,一些內(nèi)層IP頭部支持的安全選項(xiàng)可能影響到外層的頭部安全選項(xiàng)的選

擇。并不期望在這些選項(xiàng)到隧道的選項(xiàng)或安全頭部之間建立?對(duì)一的映射.

在封裝數(shù)據(jù)報(bào)時(shí)，如果隧道作為轉(zhuǎn)發(fā)數(shù)據(jù)報(bào)的一部分，內(nèi)層IP頭部的TTL將減1；

否則，在封裝的過程中內(nèi)層TTL保持不變.如果得到的內(nèi)層IP頭部的TTL為0,數(shù)據(jù)

報(bào)被丟棄并應(yīng)該向發(fā)送者產(chǎn)生一個(gè)TimeExceeded的ICMP信息。封裝方是不會(huì)對(duì)

TTL=0的數(shù)據(jù)報(bào)進(jìn)行封裝的。

內(nèi)層IP頭部中的TTL在拆分的過程中保持不變。拆分后，如果內(nèi)層數(shù)據(jù)報(bào)TTL=0,

拆分方必須丟棄該數(shù)據(jù)報(bào)。拆分后，如果拆分方轉(zhuǎn)發(fā)該數(shù)據(jù)報(bào)到它的一個(gè)網(wǎng)絡(luò)接口，

它像正常轉(zhuǎn)發(fā)IP數(shù)據(jù)報(bào)那樣遞減TTL。見4.4。

封裝方可以使用現(xiàn)存適合的IP機(jī)制來把封裝后的凈載數(shù)據(jù)傳送到隧道的出口點(diǎn)。

特別地，允許使用IP選項(xiàng)，還可以允許分片，除非內(nèi)層IP頭部中設(shè)置了"Don'tFragment"

位。使用該分片限制是為了使使用路徑MTU發(fā)現(xiàn)的節(jié)點(diǎn)能夠得到他們所要尋找的信

息。

3.2路由失敗

在隧道內(nèi)部的路由環(huán)回（Routingloops）特別危險(xiǎn)，它們使數(shù)據(jù)報(bào)再次回到封裝方。

假設(shè)一個(gè)數(shù)據(jù)報(bào)到達(dá)路由器等待轉(zhuǎn)發(fā)，而該路由器認(rèn)為該數(shù)據(jù)報(bào)在傳送之前必須封

裝，那么：

-如果該數(shù)據(jù)報(bào)的SourceAddress與路由器自己的任一個(gè)網(wǎng)絡(luò)接口的IP地址匹配，

該路由器不允許為該數(shù)據(jù)報(bào)建立隧道；相反，該數(shù)據(jù)報(bào)應(yīng)該被丟棄.

-如果該數(shù)據(jù)報(bào)的SourceAddress與隧道的目的IP地址匹配（隧道出口點(diǎn)一般由

路由器根據(jù)數(shù)據(jù)報(bào)的IP頭部的DestinationAddress選擇），路由器不允許為該數(shù)據(jù)報(bào)

建立隧道，相反，該數(shù)據(jù)報(bào)應(yīng)該被丟棄，參見4.4。

4.隧道內(nèi)部的ICMP信息

封裝后的數(shù)據(jù)報(bào)被發(fā)送后，封裝方可能從該隧道內(nèi)的任一中間路由器而不是隧道

出口接收到一條ICMP信息。封裝方采取的動(dòng)作取決于所收到的ICMP信息的類型.當(dāng)

收到的信息包含足夠信息時(shí)，封裝方可能使用收到的信息產(chǎn)生一個(gè)相似ICMP信息，發(fā)

送給產(chǎn)生未封裝IP數(shù)據(jù)報(bào)的構(gòu)建者（原始發(fā)送方）。該過程稱為中繼來自隧道的ICMP

信息。

ICMP信息表明處理數(shù)據(jù)報(bào)的過程中產(chǎn)生一個(gè)錯(cuò)誤，它包含引起錯(cuò)誤的數(shù)據(jù)報(bào)的

（一部分）的一個(gè)拷貝。中繼一個(gè)ICMP信息要求封裝方從該返回的數(shù)據(jù)報(bào)中剝?nèi)ネ?/p>

層IP頭部。對(duì)收到不包含足夠信息的ICMP信息的情況，見5o

4.1目標(biāo)不可達(dá)DestinationUnreachable(Type3)

ICMP目標(biāo)不可達(dá)信息由封裝方根據(jù)它們的Code域進(jìn)行處理。這里給出的模型允

許隧道擴(kuò)展到一個(gè)包括非本地節(jié)點(diǎn)(如移動(dòng)節(jié)點(diǎn))的網(wǎng)絡(luò)。這樣,如果未封裝數(shù)據(jù)報(bào)中

的目標(biāo)地址與封裝者處在同一個(gè)網(wǎng)絡(luò)，可以修改DestinationUnreachableCode的值使

之與給定模型一致。

網(wǎng)絡(luò)不可達(dá)NetworkUnreachable(Code0)

一條目標(biāo)不可達(dá)ICMP信息應(yīng)該返回給原始發(fā)送方。如果未封裝數(shù)據(jù)報(bào)的目的地

址與封裝者處在同一個(gè)網(wǎng)絡(luò)上，封裝后新產(chǎn)生的目標(biāo)不可達(dá)信息應(yīng)該為Code=l(Host

Unreachable),因?yàn)橥茰y數(shù)據(jù)報(bào)到達(dá)了正確的網(wǎng)絡(luò)而且封裝方把最初的目的地址視為該

網(wǎng)絡(luò)的本地地址，即使事實(shí)并非如此。否則(目的地址與封裝者處在不同的網(wǎng)絡(luò)上)，

如果封裝者返回目標(biāo)不可達(dá)信息，Code域必須設(shè)置為0(NetworkUnreachable)0

主機(jī)不可達(dá)HostUnreachable(Code1)

封裝者應(yīng)該盡可能把該主機(jī)不可達(dá)信息中繼到未封裝數(shù)據(jù)報(bào)的發(fā)送者。

協(xié)議不可達(dá)ProtocolUnreachable(Code2)

當(dāng)收到協(xié)議不可達(dá)ICMP,封裝方應(yīng)該向?yàn)榉庋b數(shù)據(jù)報(bào)的發(fā)送方發(fā)送一個(gè)Code域?yàn)?/p>

0或1的目標(biāo)不可達(dá)信息。(見Code為0部分)。因?yàn)樵及l(fā)送方?jīng)]有使用協(xié)議號(hào)為4

來發(fā)送該數(shù)據(jù)報(bào)，將向該發(fā)送方返回Code2。

端口不可達(dá)PortUnreachable(Code3)

該代號(hào)應(yīng)該從不被封裝方接收，因位外層IP頭部不指定任何端口號(hào)。不允許把該

代號(hào)發(fā)送給未封裝數(shù)據(jù)報(bào)的發(fā)送方。

數(shù)據(jù)報(bào)太大DatagramTooBig(Code4)

封裝方必須把數(shù)據(jù)報(bào)太大的ICMP數(shù)據(jù)報(bào)中繼給未封裝數(shù)據(jù)報(bào)的發(fā)送方。

源路由失敗SourceRouteFailed(Code5)

該代號(hào)應(yīng)該由封裝方自己處理。不允許把它中繼給未封裝數(shù)據(jù)報(bào)的原始發(fā)送方。

4.2.源淹沒SourceQuench(Type4)

封裝方不應(yīng)該把源淹沒信息中繼給未封裝數(shù)據(jù)報(bào)的發(fā)送方,但應(yīng)該激活所使用的

擁塞控制機(jī)制以幫助減輕隧道內(nèi)部所檢測到的擁塞。

4.3.重定向Redirect(Type5)

封裝方可能自己處理重定向ICMP信.息。不允許把重定向中繼到為封裝數(shù)據(jù)報(bào)的

發(fā)送方。

4.4.超時(shí)(Type11)

超時(shí)ICMP信息在隧道自身內(nèi)部報(bào)告(推測)路由環(huán)回。封裝方收到超時(shí)信息必須把

該超時(shí)信息作為主機(jī)不可達(dá)(Type3,Code1)信息向未封裝數(shù)據(jù)報(bào)的發(fā)送方報(bào)告。

主機(jī)不可達(dá)比網(wǎng)絡(luò)不可達(dá)更優(yōu)越；因?yàn)閿?shù)據(jù)報(bào)由封裝方處理，封裝方通常被視為未封裝

數(shù)據(jù)報(bào)的目的地址且位于相同的網(wǎng)絡(luò)上，數(shù)據(jù)報(bào)被視為到達(dá)正確的網(wǎng)絡(luò)，但錯(cuò)誤的目標(biāo)

節(jié)點(diǎn)。

4.5.參數(shù)問題ParameterProblem(Type12)

如果參數(shù)問題指向從未封裝數(shù)據(jù)報(bào)中拷貝而來的某個(gè)域，封裝方可能把該ICMP信

息中繼給未封裝數(shù)據(jù)報(bào)的發(fā)送方；否則，如果問題是由封裝方插入的IP選項(xiàng)引起，封

裝方不允許把該ICMP信息中繼給發(fā)送方。注意遵循實(shí)際情況的封裝方永不會(huì)把IP選

項(xiàng)插入到封裝的數(shù)據(jù)報(bào)中，除非出于安全原因。

4.6.其他ICMP信息

其他ICMP信息與本協(xié)議規(guī)范中的封裝無關(guān)，封裝方應(yīng)該遵循相應(yīng)的規(guī)范。

5.隧道管理

不幸的是,ICMP僅要求IP路由器返回IP頭部之外的8個(gè)字節(jié)(64bits)。這不足以

包括一個(gè)封裝后(內(nèi)層)IP頭部的一個(gè)拷貝,所以封裝方不總是能把隧道內(nèi)部的ICMP信

息中繼給原發(fā)送方。但是，通過仔細(xì)維護(hù)隧道的“軟狀態(tài)”，封裝方可在大多數(shù)情況下

把精確的ICMP信息返回給發(fā)送者，封裝方應(yīng)該至少維護(hù)每一個(gè)隧道的下述軟狀態(tài)信

息：

-隧道的MTU(見5.1章)

-隧道的TTL(路徑長度pathlength)

-隧道端點(diǎn)的可達(dá)性

封裝方使用它收到的來自隧道內(nèi)部的ICMP信息更新該隧道的軟狀態(tài)信息?？赡?/p>

從隧道中的路由器返回的ICMP錯(cuò)誤包括：

-數(shù)據(jù)報(bào)太大

-超時(shí)

-目標(biāo)不可達(dá)

-源淹沒

當(dāng)隨后經(jīng)過該隧道的數(shù)據(jù)報(bào)到達(dá)時(shí)，封裝方（器）檢查該隧道的軟狀態(tài).如果該數(shù)

據(jù)報(bào)與隧道的當(dāng)前狀態(tài)沖突（新數(shù)據(jù)報(bào)的TTL小于隧道的“軟狀態(tài)"TTL）封裝方向

原始數(shù)據(jù)報(bào)的發(fā)送方送回一個(gè)ICMP錯(cuò)誤信息，但還是封裝該數(shù)據(jù)報(bào)并把它轉(zhuǎn)交給隧

道。使用這種技術(shù)，用封裝方發(fā)送的ICMP錯(cuò)誤信息不會(huì)總是與隧道內(nèi)部發(fā)生的錯(cuò)誤一

一匹配，但它們可以精確地反映網(wǎng)絡(luò)的狀態(tài)。

5.1.隧道MTU發(fā)現(xiàn)

如果源發(fā)送方設(shè)置了Don'tFragment位并被拷貝到外層IP頭部中，可以通過報(bào)告給

封裝方的DatagramTooBig（Type3,Code4）ICMP信息得知隧道的MTU.為支持使用路

徑MTU發(fā)現(xiàn)的發(fā)送節(jié)點(diǎn)，所有封裝實(shí)現(xiàn)必須支持隧道內(nèi)部“路徑MTU發(fā)現(xiàn)”軟狀態(tài)。

在這種特殊應(yīng)用中，有幾個(gè)好處：

-分片（由于封裝頭部的大?。⒆鳛槁窂組TU發(fā)現(xiàn)的受益者，在封裝后只執(zhí)行一

次。這將阻止對(duì)一個(gè)數(shù)據(jù)報(bào)進(jìn)行多次分片，提高拆分方和隧道內(nèi)部的處理效率。

-如果未封裝數(shù)據(jù)報(bào)的源正在做路徑MTU發(fā)現(xiàn),那么要求封裝方知道隧道的MTUo

任何來自隧道內(nèi)部的DatagramTooBig信息被返回到封裝方,正如在5中所注的那樣,

封裝方不可能把所有ICMP信息中繼給未封裝數(shù)據(jù)報(bào)的發(fā)送方。通過維護(hù)隧道MTU的

軟狀態(tài)，封裝方可以把正確的DatagramTooBig信息返回給未封裝數(shù)據(jù)報(bào)的發(fā)送方以

支持它自己的路徑MTU發(fā)現(xiàn).在這種情況下，由封裝方發(fā)送給原發(fā)送方的MTU應(yīng)該

是隧道的MTU減去正封裝的IP頭部的大小。這將避免最初IP數(shù)據(jù)報(bào)被封裝方分片。

-如果未封裝數(shù)據(jù)報(bào)的源不在做路徑MTU發(fā)現(xiàn),封裝方仍然需要知道隧道的MTU。

特別地，在封裝時(shí)對(duì)原始數(shù)據(jù)報(bào)進(jìn)行分片比允許對(duì)封裝后的數(shù)據(jù)報(bào)分片要好得多。對(duì)

原始數(shù)據(jù)報(bào)的分片可由封裝方完成，且不需要特殊緩沖要求，也不需要在拆分方保存

重新裝配的狀態(tài)。相比之下，如果對(duì)封裝后的數(shù)據(jù)報(bào)進(jìn)行分片，那么拆分方必須在拆分

前重新組裝分片（封裝后）后的數(shù)據(jù)報(bào)，這就要求在拆分方重新組裝狀態(tài)和緩沖空間。

這樣，封裝方正常情況下應(yīng)該做路徑MTU發(fā)現(xiàn)，要求封裝方在所有送往隧道的數(shù)

據(jù)報(bào)均在IP頭部設(shè)置"Don,tFragment"位。但是該方法帶來兒個(gè)問題。當(dāng)原始發(fā)送

方設(shè)置"Don'tFragment"位時(shí),發(fā)送方能通過重傳原始數(shù)據(jù)報(bào)來對(duì)返回的DatagramToo

BigICMP錯(cuò)誤信息迅速做出反應(yīng)。另一方面，假定封裝方收到來自隧道內(nèi)部的

DatagramTooBigICMP錯(cuò)誤信息，如果未封裝數(shù)據(jù)報(bào)的發(fā)送者沒有設(shè)置"Don't

Fragment"位,封裝方將無法讓原始發(fā)送方知道該錯(cuò)誤。封裝方可能在試圖遞增隧道的

MTU時(shí)保存已發(fā)送數(shù)據(jù)報(bào)的一份拷貝，以允許它在收到DatagramTooBig響應(yīng)時(shí)分片

并重傳該數(shù)據(jù)報(bào)。另一種選擇是在未封裝數(shù)據(jù)報(bào)沒有設(shè)置"DoniFragment"位時(shí)，封裝

方可以設(shè)置某些類型的數(shù)據(jù)報(bào)不設(shè)置"DoniFragment"位。

5.2.擁塞

封裝方可能收到來自隧道內(nèi)部的擁塞的暗示，例如，收到隧道內(nèi)部的源淹沒

（SourceQuench）ICMP信息。另外，與Internet無關(guān)的鏈路層以及各種協(xié)議可能以

CongestionExperienced標(biāo)志位的形式提供該暗示。封裝方應(yīng)該在隧道的軟狀態(tài)中反映

擁塞狀態(tài)，在隨后向隧道轉(zhuǎn)發(fā)數(shù)據(jù)報(bào)時(shí)，封裝方應(yīng)該使用適當(dāng)手段來對(duì)擁塞進(jìn)行控制；

但是，封裝方不應(yīng)該向位封裝數(shù)據(jù)報(bào)的發(fā)送方發(fā)送源淹沒（SourceQuench）ICMP信

息。

6.安全方面的考慮

IP封裝潛在地降低了Internet的安全性，所以在使用IP封裝時(shí)應(yīng)該注意。例如IP

封裝使邊沿路由器很難根據(jù)其頭部對(duì)數(shù)據(jù)報(bào)進(jìn)行過濾。特別是,IP頭部的原始的Source

Address,DestinationAddress和Protocol各域,以及數(shù)據(jù)報(bào)中傳輸層頭部使用的端口號(hào)，

在封裝后并不處在它們正常的位置。因?yàn)槿魏蜪P數(shù)據(jù)報(bào)能被封裝并通過隧道傳輸，這

樣的過濾邊沿路由器需要認(rèn)真檢查每一個(gè)數(shù)據(jù)報(bào)。

6.1.路由器方面的考慮

路由器需要知道的IP封裝協(xié)議，以便正確地過濾傳入的數(shù)據(jù)報(bào)。期望的是，這樣

的濾波可以與IP驗(yàn)證集成。其中IP驗(yàn)證時(shí)，封裝的數(shù)據(jù)包可能會(huì)被允許進(jìn)入一個(gè)組

織時(shí)的封裝（外部）數(shù)據(jù)包或封裝（內(nèi)部）數(shù)據(jù)包是通過一個(gè)認(rèn)證，TrustedSource的

發(fā)送。不包含這樣的認(rèn)證Enc即uslated包代表?個(gè)潛在的大的安全隱患。

這是封裝和加密IP數(shù)據(jù)報(bào)也可能造成問題的過濾路由器。在這種情況下，路由器

可以過濾該數(shù)據(jù)報(bào)僅當(dāng)它共享用于加密的安全關(guān)聯(lián)。要允許這樣的加密環(huán)境中的所有

數(shù)據(jù)包需要在其中進(jìn)行過濾（或至少占了），一個(gè)機(jī)制必須到位，為接收節(jié)點(diǎn)進(jìn)行安全

通信的安全關(guān)聯(lián)的邊界路由器。這可能會(huì)較為罕見，也適用于用于輸出數(shù)據(jù)報(bào)的安全

關(guān)聯(lián)。

6.2.主機(jī)方面的考慮

能夠接收封裝后的IP數(shù)據(jù)報(bào)的主機(jī)應(yīng)該只接受符合下面兒種類型的--種或多種數(shù)

據(jù)報(bào)：

-協(xié)議無害:不需要進(jìn)行基于源地址的身份認(rèn)證。

■■正封裝的(外層)數(shù)據(jù)報(bào)來自認(rèn)證識(shí)別的可信的源，源的真實(shí)性建立于物理安全

和邊沿路由器的配置，但更可能來自IP身份認(rèn)證頭部.

-封裝后的(內(nèi)層)數(shù)據(jù)報(bào)包括一個(gè)IP身份認(rèn)證頭部

-封裝后的(內(nèi)層)數(shù)據(jù)報(bào)送到屬于拆分方的網(wǎng)絡(luò)接口，或者拆分方已與之建立特

殊關(guān)系以傳輸這些封裝后數(shù)據(jù)報(bào)的節(jié)點(diǎn)。

這些檢查的某些或全部在邊沿路由器而不是接受節(jié)點(diǎn)進(jìn)行，但如果邊沿路由器檢查

作為備份而不是僅僅作為檢察會(huì)更好。

原文：

IPEncapsulationwithinIP

Abstract

ThisdocumentspecifiesamethodbywhichanIPdatagrammaybeencapsulated

(carriedaspayload)withinanIPdatagram.Encapsulationissuggestedasameanstoalter

thenormalIProutingfordatagrams,bydeliveringthemtoanintermediatedestinationthat

wouldotherwisenotbeselectedbythe(networkpartofthe)IPDestinationAddressfieldin

theoriginalIPheader.Encapsulationmayserveavarietyofpurposes,suchasdeliveryofa

datagramtoamobilenodeusingMobileIP.

1.Introduction

ThisdocumentspecifiesamethodbywhichanIPdatagrammaybeencapsulated

(carriedaspayload)withinanIPdatagram.Encapsulationissuggestedasameanstoalter

thenormalIProutingfordatagrams,bydeliveringthemtoanintermediatedestinationthat

wouldotherwisenotbeselectedbasedonthe(networkpartofthe)IPDestinationAddress

fieldintheoriginalIPheader.Oncetheencapsulateddatagramarrivesatthisintermediate

destinationnode,itisdecapsulated,yieldingtheoriginalIPdatagram,whichisthen

deliveredtothedestinationindicatedbytheoriginalDestinationAddressfield.Thisuseof

encapsulationanddecapsulationofadatagramisfrequentlyreferredtoas"tunneling”the

datagram,andtheencapsulatoranddecapsulatorarethenconsideredtobethe"endpoints11

ofthetunnel.

Inthemostgeneraltunnelingcasewehave:

source—>encapsulator------->decapsulator???>destination

withthesource,encapsulator,decapsulator,anddestinationbeingseparatenodes.The

encapsulatornodeisconsideredthe“entrypoint"ofthetunnel,andthedecapsulatornodeis

consideredthe"exitpoint'*ofthetunnel.Thereingeneralmaybemultiple

source-destinationpairsusingthesametunnelbetweentheencapsulatoranddecapsulator.

2.Motivation

TheMobileIPworkinggrouphasspecifiedtheuseofencapsulationasawayto

deliverdatagramsfromamobilenode's"homenetwork“toanagentthatcandeliver

datagramslocallybyconventionalmeanstothemobilenodeatitscurrentlocationaway

fromhome.Theuseofencapsulationmayalsobedesirablewheneverthesource(oran

intermediaterouter)ofanIPdatagrammustinfluencetheroutebywhichadatagramistobe

deliveredtoitsultimatedestination.Otherpossibleapplicationsofencapsulationinclude

multicasting,preferentialbilling,choiceofrouteswithselectedsecurityattributes,and

generalpolicyrouting.

ItisgenerallytruethatencapsulationandtheIPloosesourceroutingoption[10]canbe

usedinsimilarwaystoaffecttheroutingofadatagram,butthereareseveraltechnical

reasonstopreferencapsulation:

-ThereareunsolvedsecurityproblemsassociatedwiththeuseoftheIPsource

routingoptions.

-CurrentInternetroutersexhibitperformanceproblemswhenforwardingdatagrams

thatcontainIPoptions,includingtheIPsourceroutingoptions.

-ManycurrentInternetnodesprocessIPsourceroutingoptionsincorrectly.

-FirewallsmayexcludeIPsource-routeddatagrams.

-InsertionofanIPsourcerouteoptionmaycomplicatetheprocessingofauthentication

informationbythesourceand/ordestinationofadatagram,dependingonhowthe

authenticationisspecifiedtobeperformed.

-Itisconsideredimpoliteforintermediaterouterstomakemodificationstodatagrams

whichtheydidnotoriginate.

Thesetechnicaladvantagesmustbeweighedagainstthedisadvantagesposedbytheuse

ofencapsulation:

-Encapsulateddatagramstypicallyarelargerthansourcerouteddatagrams.

-Encapsulationcannotbeusedunlessitisknowninadvancethatthenodeatthetunnel

exitpointcandecapsulatethedatagram.

SincethemajorityofInternetnodestodaydonotperformwellwhenIPloosesource

routeoptionsareused,thesecondtechnicaldisadvantageofencapsulationisnotasserious

asitmightseematfirst.

3.IPinIPEncapsulation

ToencapsulateanIPdatagramusingIPinIPencapsulation,anouterIPheaderis

insertedbeforethedatagram'sexistingIPheader,

asfollows:

OuterIPHeader

IPHeaderIPHeader

IPPayloadIPPayload

TheouterIPheaderSourceAddressandDestinationAddressidentifythe"endpoints11ofthe

tunnel.TheinnerIPheaderSourceAddressandDestinationAddressesidentifytheoriginal

senderandrecipientofthedatagram,respectively.TheinnerIPheaderisnotchangedbythe

encapsulator,excepttodecrementtheTTLasnotedbelow,andremainsunchangedduring

itsdeliverytothetunnelexitpoint.NochangetoIPoptionsintheinnerheaderoccurs

duringdeliveryoftheencapsulateddatagramthroughthetunnel.Ifneedbe,otherprotocol

headerssuchastheIPAuthenticationheadermaybeinsertedbetweentheouterIPheader

andtheinnerIPheader.NotethatthesecurityoptionsoftheinnerIPheadermayaffectthe

choiceofsecurityoptionsfortheencapsulating(outer)IPheader.

3.1.IPHeaderFieldsandHandling

ThefieldsintheouterIPheaderaresetbytheencapsulatoras

follows:

Version

4

IHL

TheInternetHeaderLength(IHL)isthelengthoftheouterIPheadermeasuredin

32-bitwords.

TOS

TheTypeofService(TOS)iscopiedfromtheinnerIPheader.

TotalLength

TheTotalLengthmeasuresthelengthoftheentireencapsulatedIPdatagram,including

theouterIPheader,theinnerIPheader,anditspayload.

Identification,Flags,FragmentOffset

Thesethreefieldsaresetasspecifiedin[10].However,ifthe"Don*tFragment"bitis

setintheinnerIPheader,itmustbesetintheouterIPheader;ifthe"Don'tFragment"bitis

notsetintheinnerIPheader,itmaybesetintheouterIPheader,asdescribedinSection

5.1.

TimetoLive

TheTimeToLive(TTL)fieldintheouterIPheaderissettoavalueappropriatefor

deliveryoftheencapsulateddatagramtothetunnelexitpoint.

Protocol

4

HeaderChecksum

TheInternetHeaderchecksum[10]oftheouterIPheader.

SourceAddress

TheIPaddressoftheencapsulator,thatis,thetunnelentrypoint.

DestinationAddress

TheIPaddressofthedecapsulator,thatis,thetunnelexitpoint.

Options

AnyoptionspresentintheinnerIPheaderareingeneralnotcopiedtotheouterIP

header.However,newoptionsspecifictothetunnelpathmaybeadded.Inparticular,any

supportedtypesofsecurityoptionsoftheinnerIPheadermayaffectthechoiceofsecurity

optionsfortheouterheader.Itisnotexpectedthattherebeaone-to-onemappingofsuch

optionstotheoptionsorsecurityheadersselectedforthetunnel.

Whenencapsulatingadatagram,theTTLintheinnerIPheaderisdecrementedbyone

ifthetunnelingisbeingdoneaspartofforwardingthedatagram;otherwise,theinnerheader

TTLisnotchangedduringencapsulation.IftheresultingTTLintheinnerIPheaderis0,

thedatagramisdiscardedandanICMPTimeExceededmessageshouldbereturnedtothe

sender.AnencapsulatormustnotencapsulateadatagramwithTTL=0.

TheTTLintheinnerIPheaderisnotchangedwhendecapsulating.If,after

decapsulation,theinnerdatagramhasTTL=0,thedecapsulatormustdiscardthedatagram.

If,afterdecapsulation,thedecapsulatorforwardsthedatagramtooneofitsnetwork

interfaces,itwilldecrementtheTTLasaresultofdoingnormalIPforwarding.Seealso

Section4.4.

TheencapsulatormayuseanyexistingIPmechanismsappropriatefordeliveryofthe

encapsulatedpayloadtothetunnelexitpoint.Inparticular,useofIPoptionsisallowed,and

useoffragmentationisallowedunlessthe"Don'tFragment"bitissetintheinnerIPheader.

ThisrestrictiononfragmentationisrequiredsothatnodesemployingPathMTUDiscovery

canobtaintheinformationtheyseek.

3.2.RoutingFailures

Routingloopswithinatunnelareparticularlydangerouswhentheycausedatagramsto

arriveagainattheencapsulator.Supposeadatagramarrivesatarouterforforwarding,and

therouterdeterminesthatthedatagramhastobeencapsulatedbeforefurtherdelivery.

Then:

-IftheIPSourceAddressofthedatagrammatchestherouter'sownIPaddressonanyof

itsnetworkinterfaces,theroutermustnottunnelthedatagram;instead,thedatagram

shouldbediscarded.

-IftheIPSourceAddressofthedatagrammatchestheIPaddressofthetunnel

destination(thetunnelexitpointistypicallychosenbytherouterbasedontheDestination

Addressinthedatagram'sIPheader),theroutermustnottunnelthedatagram;instead,the

datagramshouldbediscarded.SeealsoSection4.4.

4.ICMPMessagesfromwithintheTunnel

Afteranencapsulateddatagramhasbeensent,theencapsulatormayreceiveanICMP

messagefromanyintermediaterouterwithinthetunnelotherthanthetunnelexitpoint.The

actiontakenbytheencapsulatordependsonthetypeofICMPmessagereceived.Whenthe

receivedmessagecontainsenoughinformation,theencapsulatormayusetheincoming

messagetocreateasimilarICMPmessage,tobesenttotheoriginatoroftheoriginal

unencapsulatedIPdatagram(theoriginalsender).Thisprocesswillbereferredtoas

''relaying"theICMPmessagefromthetunnel.

ICMPmessagesindicatinganerrorinprocessingadatagramincludeacopyof(a

portionof)thedatagramcausingtheerror.RelayinganICMPmessagerequiresthatthe

encapsulatorstripofftheouterIPheaderfromthisreturnedcopyoftheoriginaldatagram.

ForcasesinwhichthereceivedICMPmessagedoesnotcontainenoughdatatorelaythe

message,seeSection5.

4.1.DestinationUnreachable(Type3)

ICMPDestinationUnreachablemessagesarehandledbytheencapsulatordepending

upontheirCodefield.Themodelsuggestedhereallowsthetunnelto"extend"anetworkto

includenon-local(eg,mobile)nodes.Thus,iftheoriginaldestinationintheunencapsulated

datagramisonthesamenetworkastheencapsulator,certainDestinationUnreachableCode

valuesmaybemodifiedtoconformtothesuggestedmodel.

NetworkUnreachable(Code0)

AnICMPDestinationUnreachablemessageshouldbereturnedtotheoriginalsender.If

theoriginaldestinationintheunencapsulateddatagramisonthesamenetworkasthe

encapsulator,thenewlygeneratedDestinationUnreachablemessagesentbythe

encapsulatormayhaveCode1(HostUnreachable),sincepresumablythedatagramarrived

atthecorrectnetworkandtheencapsulatoristryingtocreatetheappearancethatthe

originaldestinationislocaltothatnetworkevenifitisnot.Otherwise,iftheencapsulator

returnsaDestinationUnreachablemessage,theCodefieldmustbesetto0(Network

Unreachable).

HostUnreachable(Code1)

TheencapsulatorshouldrelayHostUnreachablemessagestothesenderoftheoriginal

unencapsulateddatagram,ifpossible.

ProtocolUnreachable(Code2)

WhentheencapsulatorreceivesanICMPProtocolUnreachablemessage,itshouldsend

aDestinationUnreachablemessagewithCode0or1(seethediscussionforCode0)tothe

senderoftheoriginalunencapsulateddatagram.Sincetheoriginalsenderdidnotuse

protocol4insendingthedatagram,itwouldbemeaninglesstoreturnCode2tothatsender.

PortUnreachable(Code3)

ThisCodeshouldneverbereceivedbytheencapsulator,sincetheouterIPheaderdoes

notrefertoanyportnumber.Itmustnotberelayedtothesenderoftheoriginal

unencapsulateddatagram.

DatagramTooBig(Code4)

TheencapsulatormustrelayICMPDatagramTooBigmessagestothesenderofthe

originalunencapsulateddatagram.

SourceRouteFailed(Code5)

ThisCodeshouldbehandledbytheencapsulatoritself.Itmustnotberelayedtothe

senderoftheoriginalunencapsulateddatagram.

4.2.SourceQuench(Type4)

TheencapsulatorshouldnotrelayICMPSourceQuenchmessagestothesenderofthe

originalunencapsulateddatagram,butinsteadshouldactivatewhatevercongestioncontrol

mechanismsitimplementstohelpalleviatethecongestiondetectedwithinthetunnel.

4.3.Redirect(Type5)

TheencapsulatormayhandletheICMPRedirectmessagesitself.Itmustnotrelaythe

Redirecttothesenderoftheoriginalunencapsulateddatagram.

4.4.TimeExceeded(Type11)

ICMPTimeExceededmessagesreport(presumed)routingloopswithinthetunnelitself.

ReceptionofTimeExceededmessagesbytheencapsulatormustbereportedtothesenderof

theoriginalunencapsulateddatagramasHostUnreachable(Type3,Code1).Host

UnreachableispreferabletoNetworkUnreachable;sincethedatagramwashandledbythe

encapsulator,andtheencapsulatorisoftenconsideredtobeonthesamenetworkasthe

destinationaddressintheoriginalunencapsulateddatagram,thenthedatagramisconsidered

tohavereachedthecorrectnetwork,butnotthecorrectdestinationnodewithinthat

network.

4.5.ParameterProblem(Type12)

IftheParameterProblemmessagepointstoafieldcopiedfromtheoriginal

unencapsulateddatagram,theencapsulatormayrelaytheICMPmessagetothesenderofthe

originalunencapsulateddatagram;otherwise,iftheproblemoccurswithanIPoption

insertedbytheencapsulator,thentheencapsulatormustnotrelaytheICMPmessagetothe

originalsender.Notethatanencapsulatorfollowingprevalentcurrentpracticewillnever

insertanyIPoptionsintotheencapsulateddatagram,exceptpossiblyforsecurityreasons.

4.6.OtherICMPMessages

OtherICMPmessagesarenotrelatedtotheencapsulationoperationsdescribedwithin

thisprotocolspecification,andshouldbeactedonbytheencapsulatorasspecified.

5.TunnelManagement

Unfortunately,ICMPonlyrequiresIProuterstoreturn8octets(64bits)ofthedatagram

beyondtheIPheader.Thisisnotenoughtoincludeacopyoftheencapsulated(inner)IP

header,soitisnotalwayspossiblefortheencapsulatortorelaytheICMPmessagefromthe

interiorofatunnelbacktotheoriginalsender.However,bycarefullymaintaining"soft

state**abouttunnelsintowhichitsends,theencapsulatorcanreturnaccurateICMP

messagestotheoriginalsenderinmostcases.Theencapsulatorshouldmaintainatleastthe

followingsoftstateinformationabouteachtunnel:

-MTUofthetunnel(Section5.1)

-TTL(pathlength)ofthetunnel

-Reachabilityoftheendofthetunnel

TheencapsulatorusestheICMPmessagesitreceivesfromtheinteriorofatunnelto

updatethesoftstateinformationforthattunnel.ICMPerrorsthatcouldbereceivedfrom

oneoftheroutersalongthetunnelinteriorinclude:

-DatagramTooBig

-TimeExceeded

-DestinationUnreachable

-SourceQuench

Whensubsequentdatagramsarrivethatwouldtransitthetunnel,theencapsulator

checksthesoftstateforthetunnel.Ifthedatagramwouldviolatethestateofthetunnel(for

example,theTTLofthenewdatagramislessthanthetunnel"softstate"TTL)the

encapsulatorsendsanICMPerrormessagebacktothesenderoftheoriginaldatagram,but

alsoencapsulatesthedatagramandforwardsitintothetunnel.

Usingthistechnique,theICMPerrormessagessentbytheencapsulatorwillnotalways

matchupone-to-onewitherrorsencounteredwithinthetunnel,buttheywillaccurately

reflectthestateofthenetwork.

5.1.TunnelMTUDiscovery

WhentheDon*tFragmentbitissetbytheoriginatorandcopiedintotheouterIPheader,

theproperMTUofthetunne