摘要
本文檔描述了一種可在ip數(shù)據(jù)報中封裝另一個IP數(shù)據(jù)包（作為凈負載）的方法.封裝通
過把路由信息送往某個中間目的地（不是由原IP頭部的IPDestinationAddress域）把正
常的IP路由變?yōu)閿?shù)據(jù)報。封裝可用于多方面,例如使用移動IP把數(shù)據(jù)報傳送到某個移動節(jié)點.
1.簡介
本文檔描述了一種可在IP數(shù)據(jù)報中封裝另一個IP數(shù)據(jù)包（作為凈負載）的方法.封裝通
過把路由信息送往某個中間目的地（不是由原IP頭部的IPDestinationAddress域）把正
常的IP路由變?yōu)閿?shù)據(jù)報。一旦封裝后的數(shù)據(jù)報到達該中間目的地節(jié)點，就被拆分，得到原
IP數(shù)據(jù)報,然后原數(shù)據(jù)報被送到目的地址（由原DestinationAddress域決定）.封裝與拆
分數(shù)據(jù)報的過程通常稱為數(shù)據(jù)報“隧道”（"tunneling"），封裝方和拆分方分別為隧道的端點
（“endpoints"）;封裝方稱為隧道的“入口點”（"entrypoint"）,拆分方稱為隧道的出口
點（"exitpoint"）.
在最常見的隧道中我們有
source--->encapsulator-------->decapsulator--->destination

其中source,encapsulator,decapsulator和destination是獨立的節(jié)點。encapsulator
節(jié)點稱為隧道的“入口點”而decapsulator節(jié)點稱為隧道的“出口點”.在封裝與拆分的過
程中同一個隧道可能有多個source-destination對。
2.動機
移動IP工作組指定封裝作為移動IP工作組已經規(guī)定把封裝作為從移動節(jié)點的"家鄉(xiāng)網絡
“（"homenetwork"）向代理（agent）傳送數(shù)據(jù)包的方法，該代理能夠以傳統(tǒng)方式在移動節(jié)
點在當前異于家鄉(xiāng)的位置“本地”地傳送數(shù)據(jù)包（參見參考文獻[8]）。封裝的使用也可表明
在IP數(shù)據(jù)報的源地址（或者中間路由器）必須影響數(shù)據(jù)報送達最終目的地所經過的路由。封
裝的其他的應用包括多播，預付費,安全屬性選擇路由，總的（general）路由選擇策略。
封裝與松散的IP源路由選擇（IPloosesourceroutingoption，參考文獻[10]）可以
相似方式影響數(shù)據(jù)報的路由，但由幾個技術上的原因使得愿意選擇：
-松散的IP源路由還有尚未解決的安全問題
-當前Internet路由器在轉發(fā)包括IP選項的數(shù)據(jù)報（包括IP遠路由選擇）時暴露出性
能問題。
-很多Interner節(jié)點在處理IP源路由選擇時出錯。
-防火墻（firewalls）可能把IP遠路由數(shù)據(jù)報拒之門外。
-插入IP遠路由選擇可能使數(shù)據(jù)報的源地址和/或目的地址的認證信息的處理變得復雜
化,取決于認證如何進行.
-中間路由器不應（it'simpolite）改變不是由它產生的數(shù)據(jù)報.

使用封裝時必須權衡封裝的優(yōu)缺點：
-封裝后的數(shù)據(jù)報一般比使用源路由算法的數(shù)據(jù)報大。
- 封裝必須在事先知道隧道的出口點能夠拆分數(shù)據(jù)報.
-
既然現(xiàn)在大多數(shù)的Internet節(jié)點在使用IP松散源路由選擇時性能不夠好,封裝的第二個
技術缺點不像起初想象的那么嚴重.
3.在IP中封裝IP
為了使IP-in-IP來封裝IP數(shù)據(jù)報,在現(xiàn)存IP頭部前面插入外層的IP頭（參考文獻[10]），
如下所示：
+---------------------------+
OuterIPHeader

+---------------------------++---------------------------+
IPHeaderIPHeader

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


IPPayloadIPPayload

+---------------------------++---------------------------+
外層IP頭部中的SourceAddress和DestinationAddress標識了隧道的“端口”.內層
IP頭部的中的SourceAddress和DestinationAddresses標識了數(shù)據(jù)報的原（最初，
original）發(fā)送方和接收方.內層IP頭部不能被封裝方修改（并在向隧道出口傳輸?shù)倪^程中
保持不變），除非按下面的方法遞減TTL.封裝后的數(shù)據(jù)報在隧道傳輸?shù)倪^程中IP選項不做任
何修改。假如要修改，則在內外層IP頭部間插入其他協(xié)議頭部，如IP認證頭部
（Authenticationheader，參考文獻[1]）.注重內層IP頭部的安全選項可能影響正在封裝
的（外層）IP頭部的安全選項。
3.1.IP頭部各域及治理
外層IP頭部由封裝方按下面設置:
Version
4
IHL
因特網頭部長度為外部IP頭部的長度，用32位的字表示（參考文獻[10]）.
TOS
服務類型(TOS)從內層IP頭部拷貝.
TotalLength
TotalLength為整個封裝后IP數(shù)據(jù)報的長度，包括外層IP頭部,內層IP頭部，
及其凈載數(shù)據(jù).
Identification,Flags,FragmentOffset
這三個域按參考文獻[10]進行設置.但是假如在IP頭部設置了"Don'tFragment"
位,必須在外部IP頭部中設置該位;假如內部IP頭部沒有設置"Don'tFragment"位，
在外層IP頭部中可能（以）設置該位，見5.1。
TimetoLive
外層IP頭部的生存期(TTL)域設置為封裝后數(shù)據(jù)報傳輸?shù)剿淼莱隹邳c所經歷的大
致時間.
PRotocol
4
HeaderChecksum
為外層IP頭部的“Internet頭部檢驗和”（參考文獻[10]）。
SourceAddress
封裝方的IP地址,即隧道的入口點。
DestinationAddress
拆封方的IP地址,即隧道的出口點。
Options
內部IP頭部中出現(xiàn)的選項通常不出現(xiàn)在外層IP頭部中。但是可能（以）增加隧
道自定義的選項.非凡地，內層IP頭部支持的安全選項可能影響到外層的頭部。不應該（not
eXPected）在這些選項到隧道的選項或安全頭部之間建立一對一的映射.
在封裝數(shù)據(jù)報時,假如隧道作為轉發(fā)數(shù)據(jù)報的一部分，內層IP頭部的TTL將減1；否則，
在封裝的過程中內層TTL保持不變.假如得到的內層IP頭部的TTL為0,數(shù)據(jù)報被丟棄并應該
向發(fā)送者產生一個TimeExceeded的ICMP信息。不答應封裝方對TTL=0的數(shù)據(jù)報進行封裝。
內層IP頭部中的TTL在拆分的過程中保持不變。拆分后，假如內層數(shù)據(jù)報TTL=0，拆分方必
須丟棄該數(shù)據(jù)報。拆分后，假如拆分方轉發(fā)該數(shù)據(jù)報到它的一個網絡接口，它像正常轉發(fā)IP
數(shù)據(jù)報那樣遞減TTL。見4.4。
封裝方可以使用現(xiàn)存適合的IP機制來把封裝后的凈載數(shù)據(jù)傳送到隧道的出口點。非凡地，
答應使用IP選項,還可以答應分片，除非內層IP頭部中設置了"Don'tFragment"位。使用該
分片限制是為了使使用路徑MTU發(fā)現(xiàn)（參考文獻[7]）的節(jié)點能夠得到他們所要尋找的信息。
3.2.路由失敗
在隧道內部的路由環(huán)回（Routingloops）非凡危險，它們使數(shù)據(jù)報再次回到封裝方。假
設一個數(shù)據(jù)報到達路由器等待轉發(fā),而該路由器認為該數(shù)據(jù)報在傳送之前必須封裝，那么：
-假如該數(shù)據(jù)報的SourceAddress與路由器自己的任一個網絡接口的IP地址匹配，該
路由器不答應為該數(shù)據(jù)報建立隧道；相反，該數(shù)據(jù)報應該被丟棄.
-假如該數(shù)據(jù)報的SourceAddress與隧道的目的IP地址匹配（隧道出口點一般由路由
器根據(jù)數(shù)據(jù)報的IP頭部的DestinationAddress選擇），路由器不答應為該數(shù)據(jù)報建
立隧道，相反，該數(shù)據(jù)報應該被丟棄。
參見4.4。
4.隧道內部的ICMP信息
封裝后的數(shù)據(jù)報被發(fā)送后,封裝方可能從該隧道內的任一中間路由器而不是隧道出口接收
到一條ICMP信息（參考文獻[9]）。封裝方采取的動作取決于所收到的ICMP信息的類型.當收
到的信息包含足夠信息時,封裝方可能使用收到的信息產生一個相似的ICMP信息，發(fā)送給產
生未封裝IP數(shù)據(jù)報的構建者（原始發(fā)送方）。該過程稱為中繼（"relaying"）來自隧道的ICMP
信息。
ICMP信息表明處理數(shù)據(jù)報的過程中產生一個錯誤，它包含引起錯誤的數(shù)據(jù)報的（一部分）
的一個拷貝。中繼一個ICMP信息要求封裝方從該返回的數(shù)據(jù)報中剝去外層IP頭部。對收到
不包含足夠信息的ICMP信息的情況，見5。
4.1.目標不可達DestinationUnreachable(Type3)
ICMP目標不可達信息由封裝方根據(jù)它們的Code域進行處理。這里給出的模型答應隧道擴
展（"extend"）到一個包括非本地節(jié)點（如移動節(jié)點）的網絡。這樣,假如未封裝數(shù)據(jù)報中的
目標地址與封裝者處在同一個網絡，可以修改DestinationUnreachableCode的值使之與
給定模型一致。
網絡不可達NetworkUnreachable(Code0)
一條目標不可達ICMP信息應該返回給原始發(fā)送方。假如未封裝數(shù)據(jù)報的目的地址
與封裝者處在同一個網絡上,封裝著新產生的目標不可達信息應該為Code=1(Host
Unreachable),因為推測數(shù)據(jù)報到達了正確的網絡而且封裝方把最初的目的地址視為
該網絡的本地地址，即使事實并非如此。否則（目的地址與封裝者處在不同的網絡上），
假如封裝者返回目標不可達信息,Code域必須設置為0(NetworkUnreachable)。
主機不可達HostUnreachable(Code1)
封裝者應該盡可能把該主機不可達信息中繼到未封裝數(shù)據(jù)報的發(fā)送者。
協(xié)議不可達ProtocolUnreachable(Code2)
當收到協(xié)議不可達ICMP,封裝方應該向為封裝數(shù)據(jù)報的發(fā)送方發(fā)送一個Code域為0
或1的目標不可達信息。（見Code為0部分）。因為原始發(fā)送方沒有使用協(xié)議號為
4來發(fā)送該數(shù)據(jù)報,將向該發(fā)送方返回Code2。
端口不可達PortUnreachable(Code3)
該代號應該從不被封裝方接收，因位外層IP頭部不指定任何端口號。不答應把該代
號發(fā)送給未封裝數(shù)據(jù)報的發(fā)送方。
數(shù)據(jù)報太大DatagramTooBig(Code4)
封裝方必須把數(shù)據(jù)報太大ICMP中繼給未封裝數(shù)據(jù)報的發(fā)送方。
源路由失敗SourceRouteFailed(Code5)
該代號應該由封裝方自己處理。不答應把它中繼給位封裝數(shù)據(jù)報的發(fā)送方。
4.2.源沉沒SourceQuench(Type4)
封裝方不應該把源沉沒信息中繼給未封裝數(shù)據(jù)報的發(fā)送方,但應該激活所使用的擁塞控
制機制以幫助減輕隧道內部所檢測到的擁塞。
4.3.重定向Redirect(Type5)
封裝方可能自己處理重定向ICMP信息。不答應把重定向中繼到為封裝數(shù)據(jù)報的發(fā)送方。4。
4.4.超時(Type11)
超時ICMP信息在隧道自身內部報告(推測)路由環(huán)回。封裝方收到超時信息必須把該超時
信息作為主機不可達（Type3,Code1）信息向未封裝數(shù)據(jù)報的發(fā)送方報告。主機不可達與
網絡不可達更優(yōu)越；因為數(shù)據(jù)報由封裝方處理,封裝方通常被視為未封裝數(shù)據(jù)報的目的地址且
位于相同的網絡上,數(shù)據(jù)報被視為到達正確的網絡，但錯誤的目標節(jié)點。
4.5.參數(shù)問題ParameterProblem(Type12)
假如參數(shù)問題指向從未封裝數(shù)據(jù)報中拷貝而來的某個域,封裝方可能把該ICMP信息中繼
給未封裝數(shù)據(jù)報的發(fā)送方；否則，假如問題是由封裝方插入的IP選項引起，封裝方不答應把
該ICMP信息中繼給發(fā)送方。注重遵循實際情況的封裝方永不會把IP選項插入到封裝的數(shù)據(jù)
報中，除非出于安全原因。
4.6.其他ICMP信息
其他ICMP信息與本協(xié)議規(guī)范中的封裝無關,封裝方應該遵循按參考文獻[9]中所定義的
規(guī)范。
5.隧道治理
不幸的是,ICMP僅要求IP路由器返回IP頭部之外的8個字節(jié)(64bits)。這不足以包括一
個封裝后(內層)IP頭部的一個拷貝,所以封裝方不總是能把隧道內部的ICMP信息中繼給原發(fā)
送方。但是，通過仔細維護隧道的“軟狀態(tài)”（"softstate"），封裝方可在大多數(shù)情況下把
精確的ICMP信息返回給發(fā)送者，封裝方應該至少維護每一個隧道的下述軟狀態(tài)信息：
-隧道的MTU(見5.1)
-隧道的TTL(路徑長度pathlength)
-隧道端點的可達性
封裝方使用它收到的來自隧道內部的ICMP信息更新該隧道的軟狀態(tài)信息。可能從隧道中
的路由器返回的ICMP錯誤包括：
-數(shù)據(jù)報太大
-超時
-目標不可達
-源沉沒
當隨后經過該隧道的數(shù)據(jù)報到達時，封裝方（器）檢查該隧道的軟狀態(tài).假如該數(shù)據(jù)報與
隧道的當前狀態(tài)沖突（新數(shù)據(jù)報的TTL小于隧道的"軟狀態(tài)"TTL）封裝方向原始數(shù)據(jù)報的發(fā)
送方送回一個ICMP錯誤信息，但還是封裝該數(shù)據(jù)報并把它轉交給隧道。
使用這種技術,用封裝方發(fā)送的ICMP錯誤信息不會總是與隧道內部發(fā)生的錯誤一一匹配，
但它們可以精確地反映網絡的狀態(tài)。
隧道軟狀態(tài)最初開發(fā)用于IP地址封裝（IPAddressEncapsulation，IPAE），見參考文
獻[4]。
5.1.隧道MTU發(fā)現(xiàn)
假如源發(fā)送方設置了Don'tFragment位并被拷貝到外層IP頭部中,可以通過報告給封裝
方的DatagramTooBig(Type3,Code4)ICMP信息得知隧道的MTU.為支持使用路徑MTU發(fā)
現(xiàn)的發(fā)送節(jié)點，所有封裝實現(xiàn)必須支持隧道內部“路徑MTU發(fā)現(xiàn)”軟狀態(tài)（參考文獻[5,7]）。
在這種非凡應用中，有幾個好處：

-分片（由于封裝頭部的大小）將作為路徑MTU發(fā)現(xiàn)的受益者,在封裝后只執(zhí)行一次。這
將阻止對一個數(shù)據(jù)報進行多次分片,提高拆分方和隧道內部的處理效率。
-假如未封裝數(shù)據(jù)報的源正在做路徑MTU發(fā)現(xiàn),那么要求封裝方知道隧道的MTU。任何來
自隧道內部的DatagramTooBig信息被返回到封裝方,正如在5中所注的那樣，封裝
方不可能把所有ICMP信息中繼給未封裝數(shù)據(jù)報的發(fā)送方.通過維護隧道MTU的軟狀態(tài)，
封裝方可以把正確的DatagramTooBig信息返回給未封裝數(shù)據(jù)報的發(fā)送方以支持它
自己的路徑MTU發(fā)現(xiàn).在這種情況下,由封裝方發(fā)送給原發(fā)送方的MTU應該是隧道的
MTU減去正封裝的IP頭部的大小。這將避免最初IP數(shù)據(jù)報被封裝方分片。
- 假如未封裝數(shù)據(jù)報的源不在做路徑MTU發(fā)現(xiàn)，封裝方仍然需要知道隧道的MTU。非凡
地，在封裝時對原始數(shù)據(jù)報進行分片比答應對封裝后的數(shù)據(jù)報分片要好得多.對原始
數(shù)據(jù)報的分片可由封裝方完成，且不需要非凡緩沖要求，也不需要在拆分方保存重
新裝配的狀態(tài)。相比之下,假如對封裝后的數(shù)據(jù)報進行分片,那么拆分方必須在拆分
前重新組裝分片（封裝后）后的數(shù)據(jù)報，這就要求在拆分方重新組裝狀態(tài)和緩沖空
間。

這樣，封裝方正常情況下應該做路徑MTU發(fā)現(xiàn)，要求封裝方在所有送往隧道的數(shù)
據(jù)報均在IP頭部設置"Don'tFragment"位。但是該方法帶來幾個問題。當原始發(fā)送
方設置"Don'tFragment"位時,發(fā)送方能通過重傳原始數(shù)據(jù)報來對返回的DatagramToo
BigICMP錯誤信息迅速做出反應。另一方面，假定封裝方收到來自隧道內部的Datagram
TooBigICMP錯誤信息，假如未封裝數(shù)據(jù)報的發(fā)送者沒有設置"Don'tFragment"位,封裝
方將無法讓原始發(fā)送方知道該錯誤。封裝方可能在試圖遞增隧道的MTU時保存已發(fā)送數(shù)
據(jù)報的一份拷貝，以答應它在收到DatagramTooBig響應時分片并重傳該數(shù)據(jù)報。
另一種選擇是在未封裝數(shù)據(jù)報沒有設置"Don'tFragment"位時，封裝方可能（以）
設置某些類型的數(shù)據(jù)報不設置"Don'tFragment"位。
5.2.擁塞
封裝方可能收到來自隧道內部的擁塞的暗示，例如，收到隧道內部的源沉沒（Source
Quench）ICMP信息。另外，與Internet無關的鏈路層以及各種協(xié)議可能以Congestion
Experienced標志位（參考文獻[6]）的形式提供該暗示。封裝方應該在隧道的軟狀態(tài)中反映
擁塞狀態(tài),在隨后向隧道轉發(fā)數(shù)據(jù)報時，封裝方應該使用適當手段來對擁塞進行控制（參考
文獻[3]）；但是，封裝方不應該向位封裝數(shù)據(jù)報的發(fā)送方發(fā)送源沉沒（SourceQuench）ICMP
信息。
6.安全方面的考慮
IP封裝潛在地降低了Internet的安全性,所以在使用IP封裝時應該注重。例如IP封裝
使邊沿路由器很難根據(jù)其頭部對數(shù)據(jù)報進行過濾。非凡是,IP頭部的原始的SourceAddress,
DestinationAddress,和Protocol各域,以及數(shù)據(jù)報中傳輸層頭部使用的端口號,在封裝后并
不處在它們正常的位置。因為任何IP數(shù)據(jù)報能被封裝并通過隧道傳輸,這樣的過濾邊沿路由
器需要認真檢查每一個數(shù)據(jù)報
6.1.路由器方面的考慮
路由器需要知道IP封裝的協(xié)議以便能夠對傳進來的數(shù)據(jù)報進行過濾。這樣的過濾應該與
IP身份認證（參考文獻1）集成在一起。在使用IP身份認證的地方，假如正在封裝的（外層）
數(shù)據(jù)包或者已經封裝的（內層）數(shù)據(jù)包由一個經過認證的可信的源發(fā)送，則封裝后的數(shù)據(jù)報
可被答應進入某組織。不包含這些認證的封裝后的數(shù)據(jù)包是一個極大的安全隱患。


封裝和加密后的IP數(shù)據(jù)報（參考文獻[2]）也可能給過濾路由器帶來問題。在這種情況下，
路由器只能過濾那些共享了用于加密的安全聯(lián)合的數(shù)據(jù)報。在所有數(shù)據(jù)包都需要過濾（或者
至少說明）的環(huán)境中，為答應這種加密，接收節(jié)點必須采用一種機制來安全地把安全聯(lián)合送
到邊沿路由器。對于傳出的數(shù)據(jù)包也適用這種安全聯(lián)合，但較少使用。
6.2.主機方面的考慮
能夠接收封裝后的IP數(shù)據(jù)報的主機應該只接受符合下面幾種類型的一種或多種的數(shù)據(jù)報：
-協(xié)議無害:不需要進行基于源地址的身份認證。
-正封裝的（外層）數(shù)據(jù)報來自認證識別的可信的源，源的真實性建立于物理安全和邊
沿路由器的配置,但更可能來自IP身份認證頭部（參考文獻[1]）.
-封裝后的（內層）數(shù)據(jù)報包括一個IP身份認證頭部
-封裝后的（內層）數(shù)據(jù)報送到屬于拆分方的網絡接口，或者拆分方已與之建立非凡關系以傳
輸這些封裝后數(shù)據(jù)報的節(jié)點。

這些檢查的某些或全部在邊沿路由器而不是接受節(jié)點進行，但假如邊沿路由器檢查作為備
份而不是僅僅作為檢察會更好。
7.致謝
3和5節(jié)部分節(jié)選自移動IP因特網草案（BillSimpson）的早期版本（參考文獻[8]）.6
節(jié)（安全考慮）的源文來自BobSmart.從RFC1853（參考文獻[11]，作者也是BillSimpson）
中的到很多好主意,也感謝AndersKlemets發(fā)現(xiàn)草案中的錯誤并提出改進建議。最后感謝
DavidJohnson對草案的非常細致的審閱，勘誤，潤色以及其他方面的。

參考文獻
[1]Atkinson,R.,"IPAuthenticationHeader",RFC1826,August1995.
[2]Atkinson,R.,"IPEncapsulatingSecurityPayload",RFC1827,
August1995.
[3]Baker,F.,Editor,"RequirementsforIPVersion4Routers",RFC
1812,June1995.
[4]Gilligan,R.,Nordmark,E.,andB.Hinden,"IPAE:TheSIPP
InterOperabilityandTransitionMechanism",WorkinProgress.
[5]Knowles,S.,"IESGAdvicefromExperiencewithPathMTU
Discovery",RFC1435,March1993.
[6]Mankin,A.,andK.Ramakrishnan,"GatewayCongestionControl
Survey",RFC1254,August1991.
[7]Mogul,J.,andS.Deering,"PathMTUDiscovery",RFC1191,
November1990.
[8]Perkins,C.,Editor,"IPMobilitySupport",RFC2002,
October1996.
[9]Postel,J.,Editor,"InternetControlMessageProtocol",STD5,
RFC792,September1981.
[10]Postel,J.,Editor,"InternetProtocol",STD5,RFC791,
September1981.
[11]Simpson,W.,"IPinIPTunneling",RFC1853,October1995.
作者地址
關于本文檔的問題可通過下述方式直接聯(lián)系:
CharlesPerkins
RoomH3-D34
T.J.WatsonResearchCenter
IBMCorporation
30SawMillRiverRd.
Hawthorne,NY10532
Work:+1-914-784-7350
Fax:+1-914-784-6205
EMail:perk@watson.ibm.com

本工作組可以通過現(xiàn)任主席聯(lián)系:
JimSolomon
Motorola,Inc.
1301E.AlgonquinRd.
Schaumburg,IL60196

Work:+1-847-576-2753
EMail:solomon@comm.mot.com