數據報太大Datagram Too Big (Code 4)
         封裝方必須把數據報太大ICMP中繼給未封裝數據報的發送方。
      源路由失敗Source Route Failed (Code 5)
         該代號應該由封裝方自己處理。不允許把它中繼給位封裝數據報的發送方。
4.2.源淹沒 Source Quench (Type 4)
   封裝方不應該把源淹沒信息中繼給未封裝數據報的發送方,但應該激活所使用的擁塞控
制機制以幫助減輕隧道內部所檢測到的擁塞。
4.3.重定向 Redirect (Type 5)
   封裝方可能自己處理重定向ICMP信息。不允許把重定向中繼到為封裝數據報的發送方。4。
4.4.超時 (Type 11)
   超時ICMP信息在隧道自身內部報告(推測)路由環回。封裝方收到超時信息必須把該超時
信息作為主機不可達（Type 3, Code 1）信息向未封裝數據報的發送方報告。主機不可達與
網絡不可達更優越；因為數據報由封裝方處理,封裝方通常被視為未封裝數據報的目的地址且
位于相同的網絡上,數據報被視為到達正確的網絡，但錯誤的目標節點。
4.5. 參數問題Parameter Problem(Type 12)
   如果參數問題指向從未封裝數據報中拷貝而來的某個域,封裝方可能把該ICMP信息中繼
給未封裝數據報的發送方；否則，如果問題是由封裝方插入的IP選項引起，封裝方不允許把
該ICMP信息中繼給發送方。注意遵循實際情況的封裝方永不會把IP選項插入到封裝的數據
報中，除非出于安全原因。  
4.6.其他ICMP信息
   其他ICMP信息與本協議規范中的封裝無關,封裝方應該遵循按參考文獻[9]中所定義的 
規范。
5. 隧道管理
   不幸的是,ICMP僅要求IP路由器返回IP頭部之外的8個字節(64bits)。這不足以包括一
個封裝后(內層)IP頭部的一個拷貝,所以封裝方不總是能把隧道內部的ICMP信息中繼給原發
送方。但是，通過仔細維護隧道的“軟狀態”（"soft state" ），封裝方可在大多數情況下把
精確的ICMP信息返回給發送者，封裝方應該至少維護每一個隧道的下述軟狀態信息：
    - 隧道的MTU (見5.1)
-隧道的TTL (路徑長度path length)
    - 隧道端點的可達性
   封裝方使用它收到的來自隧道內部的ICMP信息更新該隧道的軟狀態信息。可能從隧道中
的路由器返回的ICMP錯誤包括：
    - 數據報太大
    - 超時
    - 目標不可達
    - 源淹沒
   當隨后經過該隧道的數據報到達時，封裝方（器）檢查該隧道的軟狀態.如果該數據報與
隧道的當前狀態沖突（新數據報的TTL小于隧道的"軟狀態"TTL） 封裝方向原始數據報的發
送方送回一個ICMP錯誤信息 ，但還是封裝該數據報并把它轉交給隧道。
   使用這種技術,用封裝方發送的ICMP錯誤信息不會總是與隧道內部發生的錯誤一一匹配，
但它們可以精確地反映網絡的狀態。
   隧道軟狀態最初開發用于IP地址封裝（IP Address Encapsulation ，IPAE），見參考文
獻[4]。
5.1.隧道MTU發現
   如果源發送方設置了Don't Fragment位并被拷貝到外層IP頭部中,可以通過報告給封裝
方的Datagram Too Big (Type 3, Code 4)ICMP信息得知隧道的MTU.為支持使用路徑MTU發
現的發送節點，所有封裝實現必須支持隧道內部“路徑MTU發現”軟狀態（參考文獻[5, 7]）。
在這種特殊應用中，有幾個好處： 

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

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







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

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

參考文獻
   [1] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
   [2] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
       August 1995.
   [3] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC
       1812, June 1995.
   [4] Gilligan, R., Nordmark, E., and B. Hinden, "IPAE: The SIPP
       Interoperability and Transition Mechanism", Work in Progress.
   [5] Knowles, S., "IESG Advice from Experience with Path MTU
       Discovery", RFC 1435, March 1993.
   [6] Mankin, A., and K. Ramakrishnan, "Gateway Congestion Control
       Survey", RFC 1254, August 1991.
   [7] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
       November 1990.
   [8] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
       October 1996.
   [9] Postel, J., Editor, "Internet Control Message Protocol", STD 5,
       RFC 792, September 1981.
   [10] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
        September 1981.
   [11] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
作者地址
   關于本文檔的問題可通過下述方式直接聯系:
   Charles Perkins
   Room H3-D34
   T. J. Watson Research Center
   IBM Corporation
   30 Saw Mill River Rd.
   Hawthorne, NY  10532
   Work:   +1-914-784-7350
   Fax:    +1-914-784-6205
   EMail: perk@watson.ibm.com
   
本工作組可以通過現任主席聯系:
   Jim Solomon
   Motorola, Inc.
   1301 E. Algonquin Rd.
   Schaumburg, IL  60196

   Work:   +1-847-576-2753
   EMail: solomon@comm.mot.com
RFC2003   IP Encapsulation within I P                              在IP內封裝IP


1
RFC文檔中文翻譯計劃