組織：中國互動出版網(wǎng)（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：Hlp(hlp,huangliuqi@hotmail.com)
譯文發(fā)布時間：2001-5-23
版權(quán)：本中文翻譯文檔版權(quán)歸中國互動出版網(wǎng)所有。可以用于非商業(yè)用途自由轉(zhuǎn)載，但必須
保留本文檔的翻譯及版權(quán)信息。



Network Working Group                                         C. Perkins
Request for Comment: 2003                                            IBM
Category: Standards Track                                   October 1996


在IP內(nèi)封裝IP
（RFC2003   IP Encapsulation within IP）

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

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

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

   使用封裝時必須權(quán)衡封裝的優(yōu)缺點：
    - 封裝后的數(shù)據(jù)報一般比使用源路由算法的數(shù)據(jù)報大。
-	封裝必須在事先知道隧道的出口點能夠拆分數(shù)據(jù)報.
-	
   既然現(xiàn)在大多數(shù)的Internet節(jié)點在使用IP松散源路由選擇時性能不夠好,封裝的第二個
技術(shù)缺點不像起初想象的那么嚴重.
3.在IP中封裝IP
   為了使IP-in-IP來封裝IP數(shù)據(jù)報,在現(xiàn)存IP頭部前面插入外層的IP頭（參考文獻[10]），
如下所示：
                                         +---------------------------+
                                         |      Outer IP Header      |
                                         |                           |
     +---------------------------+       +---------------------------+
     |         IP Header         |       |         IP Header         |
     |                           |       |                           |
     +---------------------------+ ====> +---------------------------+
     |                           |       |                           |
     |                           |       |                           |
     |         IP Payload        |       |         IP Payload        |
     |                           |       |                           |
     +---------------------------+       +---------------------------+
   外層IP頭部中的Source Address和Destination Address標識了隧道的“端口”.內(nèi)層
IP頭部的中的Source Address和Destination Addresses標識了數(shù)據(jù)報的原（最初，
original）發(fā)送方和接收方.內(nèi)層IP頭部不能被封裝方修改（并在向隧道出口傳輸?shù)倪^程中
保持不變），除非按下面的方法遞減TTL.封裝后的數(shù)據(jù)報在隧道傳輸?shù)倪^程中IP選項不做任
何修改。如果要修改，則在內(nèi)外層IP頭部間插入其他協(xié)議頭部，如IP認證頭部
（Authentication header，參考文獻[1]）.注意內(nèi)層IP頭部的安全選項可能影響正在封裝
的（外層）IP頭部的安全選項。
3.1.IP頭部各域及管理
   外層IP頭部由封裝方按下面設(shè)置:
      Version
          4
      IHL
         因特網(wǎng)頭部長度為外部IP頭部的長度，用32位的字表示（參考文獻[10]）.
      TOS
         服務(wù)類型(TOS)從內(nèi)層IP頭部拷貝.
      Total Length
         Total Length為整個封裝后IP數(shù)據(jù)報的長度，包括外層IP頭部,內(nèi)層IP頭部，
及其凈載數(shù)據(jù).
     Identification, Flags, Fragment Offset
         這三個域按參考文獻[10]進行設(shè)置.但是如果在IP頭部設(shè)置了"Don't Fragment"
位,必須在外部IP頭部中設(shè)置該位;如果內(nèi)部IP頭部沒有設(shè)置"Don't Fragment"位，
在外層IP頭部中可能（以）設(shè)置該位，見5.1。
      Time to Live
         外層IP頭部的生存期(TTL)域設(shè)置為封裝后數(shù)據(jù)報傳輸?shù)剿淼莱隹邳c所經(jīng)歷的大
致時間.
      Protocol
         4
      Header Checksum
         為外層IP頭部的“Internet頭部檢驗和”（參考文獻[10]）。
      Source Address
         封裝方的IP地址,即隧道的入口點。
      Destination Address
         拆封方的IP地址,即隧道的出口點。
      Options
         內(nèi)部IP頭部中出現(xiàn)的選項通常不出現(xiàn)在外層IP頭部中。但是可能（以）增加隧
道自定義的選項.特別地，內(nèi)層IP頭部支持的安全選項可能影響到外層的頭部。不應(yīng)該（not         
expected）在這些選項到隧道的選項或安全頭部之間建立一對一的映射.
   在封裝數(shù)據(jù)報時,如果隧道作為轉(zhuǎn)發(fā)數(shù)據(jù)報的一部分，內(nèi)層IP頭部的TTL將減1；否則，
在封裝的過程中內(nèi)層TTL保持不變.如果得到的內(nèi)層IP頭部的TTL為0,數(shù)據(jù)報被丟棄并應(yīng)該
向發(fā)送者產(chǎn)生一個Time Exceeded的ICMP信息。不允許封裝方對TTL=0的數(shù)據(jù)報進行封裝。
內(nèi)層IP頭部中的TTL在拆分的過程中保持不變。拆分后，如果內(nèi)層數(shù)據(jù)報TTL=0，拆分方必
須丟棄該數(shù)據(jù)報。拆分后，如果拆分方轉(zhuǎn)發(fā)該數(shù)據(jù)報到它的一個網(wǎng)絡(luò)接口，它像正常轉(zhuǎn)發(fā)IP
數(shù)據(jù)報那樣遞減TTL。見4.4。
   封裝方可以使用現(xiàn)存適合的IP機制來把封裝后的凈載數(shù)據(jù)傳送到隧道的出口點。特別地，
允許使用IP選項,還可以允許分片，除非內(nèi)層IP頭部中設(shè)置了"Don't Fragment"位。使用該
分片限制是為了使使用路徑MTU發(fā)現(xiàn)（參考文獻[7]）的節(jié)點能夠得到他們所要尋找的信息。
3.2.路由失敗
   在隧道內(nèi)部的路由環(huán)回（Routing loops）特別危險，它們使數(shù)據(jù)報再次回到封裝方。假
設(shè)一個數(shù)據(jù)報到達路由器等待轉(zhuǎn)發(fā),而該路由器認為該數(shù)據(jù)報在傳送之前必須封裝 ，那么：
   -  如果該數(shù)據(jù)報的Source Address與路由器自己的任一個網(wǎng)絡(luò)接口的IP地址匹配，該
路由器不允許為該數(shù)據(jù)報建立隧道；相反，該數(shù)據(jù)報應(yīng)該被丟棄.
    - 如果該數(shù)據(jù)報的Source Address 與隧道的目的IP地址匹配（隧道出口點一般由路由
器根據(jù)數(shù)據(jù)報的IP頭部的Destination Address選擇），路由器不允許為該數(shù)據(jù)報建
立隧道 ，相反，該數(shù)據(jù)報應(yīng)該被丟棄。
   參見4.4。
4. 隧道內(nèi)部的ICMP信息
   封裝后的數(shù)據(jù)報被發(fā)送后,封裝方可能從該隧道內(nèi)的任一中間路由器而不是隧道出口接收
到一條ICMP信息（參考文獻[9]）。封裝方采取的動作取決于所收到的ICMP信息的類型.當收
到的信息包含足夠信息時,封裝方可能使用收到的信息產(chǎn)生一個相似的ICMP信息，發(fā)送給產(chǎn)
生未封裝IP數(shù)據(jù)報的構(gòu)建者（原始發(fā)送方）。該過程稱為中繼（"relaying"）來自隧道的ICMP
信息。
   ICMP信息表明處理數(shù)據(jù)報的過程中產(chǎn)生一個錯誤，它包含引起錯誤的數(shù)據(jù)報的（一部分）
的一個拷貝。中繼一個ICMP信息要求封裝方從該返回的數(shù)據(jù)報中剝?nèi)ネ鈱覫P頭部。對收到
不包含足夠信息的ICMP信息的情況，見5。
4.1.目標不可達 Destination Unreachable (Type 3)
   ICMP目標不可達信息由封裝方根據(jù)它們的Code域進行處理。這里給出的模型允許隧道擴
展（"extend"）到一個包括非本地節(jié)點（如移動節(jié)點）的網(wǎng)絡(luò)。這樣,如果未封裝數(shù)據(jù)報中的
目標地址與封裝者處在同一個網(wǎng)絡(luò)，可以修改 Destination Unreachable Code的值使之與
給定模型一致。
      網(wǎng)絡(luò)不可達Network Unreachable (Code 0)
         一條目標不可達ICMP信息應(yīng)該返回給原始發(fā)送方。如果未封裝數(shù)據(jù)報的目的地址  
與封裝者處在同一個網(wǎng)絡(luò)上,封裝著新產(chǎn)生的目標不可達信息應(yīng)該為Code=1 (Host         
Unreachable),因為推測數(shù)據(jù)報到達了正確的網(wǎng)絡(luò)而且封裝方把最初的目的地址視為
該網(wǎng)絡(luò)的本地地址，即使事實并非如此。否則（目的地址與封裝者處在不同的網(wǎng)絡(luò)上） ，
如果封裝者返回目標不可達信息,Code域必須設(shè)置為0(Network Unreachable)。
      主機不可達Host Unreachable (Code 1)
         封裝者應(yīng)該盡可能把該主機不可達信息中繼到未封裝數(shù)據(jù)報的發(fā)送者。
      協(xié)議不可達Protocol Unreachable (Code 2)
         當收到協(xié)議不可達ICMP,封裝方應(yīng)該向為封裝數(shù)據(jù)報的發(fā)送方發(fā)送一個Code域為0
或1的目標不可達 信息。（見Code為0部分）。因為原始發(fā)送方?jīng)]有使用協(xié)議號為
4來發(fā)送該數(shù)據(jù)報,將向該發(fā)送方返回Code 2。
      端口不可達Port Unreachable (Code 3)
        該代號應(yīng)該從不被封裝方接收，因位外層IP頭部不指定任何端口號。不允許把該代
號發(fā)送給未封裝數(shù)據(jù)報的發(fā)送方。