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


Network Working Group                                           J. Mogul
Request for Comments: 1191                                        DECWRL
Obsoletes: RFC 1063                                             S. Deering
                                                        Stanford University
November 1990


RFC1191 路徑MTU發(fā)現(xiàn)
（RFC1191 Path MTU Discovery）


本備忘錄狀態(tài)
   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.
摘要
   此備忘錄描述了一種動態(tài)發(fā)現(xiàn)因特網(wǎng)上任意一條路徑的最大傳輸單元(MTU)的技術(shù)。它對這條路徑上的路由器產(chǎn)生的一種ICMP消息作了很小的修改。在路徑上的路由器如果沒有作出這樣的改變，這種技術(shù)將不能發(fā)現(xiàn)正確的路徑MTU，但是這種技術(shù)選擇出來的路徑MTU將和當(dāng)前使用的其它方法選擇出來的MTU同樣準(zhǔn)確，而且在許多情況下更加精確。
致謝
這個建議是IETF MTU發(fā)現(xiàn)工作組的產(chǎn)品。

    這種被建議的機制首先由Geof Cooper [2]提出，他在兩個簡短的段落中陳述了所有基本的思想，IETF MTU發(fā)現(xiàn)工作組用了幾個月的時間重新修訂。







                            目錄
 
1. 簡介	2
2. 協(xié)議概覽	2
3, 主機規(guī)范	3
3.1 TCP MSS選項	4
4. 路由器規(guī)范	5
5. 主機對老式報文的處理	5
6. 主機實現(xiàn)	6
6.1 分層	7
6.2 存儲PMTU信息	7
6.3 清除過時的PMTU信息	8
6.4 TCP層的行為	9
6.5 其它傳輸協(xié)議的問題	10
6.6 管理接口	11
7. 路徑MTU的可能值	11
7.1 一種較好的檢測PMTU增長的方法	12
8. 安全性的考慮	13
參考書目：	13
作者地址：	14

1. 簡介 
   當(dāng)一臺IP主機有大量的數(shù)據(jù)要發(fā)送給另一臺主機的時候，數(shù)據(jù)是作為一系列的IP數(shù)據(jù)報傳輸。數(shù)據(jù)報最好具有在從源點到目的點的路徑上不需要分片的最大尺寸。（避免分片的情況，見[5]。）這種數(shù)據(jù)報的尺寸稱作為路徑MTU（PMTU）,它等于路徑上每一跳的MTU之中的最小值。當(dāng)前因特網(wǎng)協(xié)議族的缺點就是對一臺主機來說缺乏發(fā)現(xiàn)任意一條路徑的PMTU的標(biāo)準(zhǔn)機制。

  注意：路徑MTU在[1]中被稱作為“用于發(fā)送的有效MTU" (EMTU_S).
PMTU與一條路徑相關(guān)，路徑是IP的源地址、目的地址，也許還有
服務(wù)類型（TOS）的特定組合。

   當(dāng)前實際[1]采用的是576和第一跳MTU中的較小者作為任何不與源地址網(wǎng)絡(luò)或者子網(wǎng)直接相連的目的地址的PMTU。在許多情況下，這導(dǎo)致了使用比必須要求小的數(shù)據(jù)報，因為許多路徑的PMTU比576大。一臺主機發(fā)送比路徑MTU小的多的數(shù)據(jù)報是浪費因特網(wǎng)的資源，達(dá)不到最優(yōu)的吞吐量。而且，當(dāng)前的實現(xiàn)在所有的情況下不防止分片，因為一些路徑的MTU比576小。

   期望未來的路由協(xié)議將能夠在一個路徑區(qū)域中提供準(zhǔn)確的PMTU信息，盡管也許不能越過多級路由層次。還要多久這種未來的路由協(xié)議才能廣泛應(yīng)用現(xiàn)在還不清楚。所以在以后的幾年中，因特網(wǎng)在所有主機和路由器被修改前為了不浪費資源需要一種簡單的發(fā)現(xiàn)PMTU的機制。
2. 協(xié)議概覽
   在此備忘錄中，我們描述了一種技術(shù)，在IP首部使用不分片(DF)比特位動態(tài)發(fā)現(xiàn)一條路徑的PMTU。基本思想就是源主機開始假定一條路徑的PMTU是它的（已知的）第一跳的MTU，在這條路徑上發(fā)送的數(shù)據(jù)報都設(shè)置DF比特位。如果有的數(shù)據(jù)報太大，不被路徑中的某些路由器分片就不能轉(zhuǎn)發(fā)，那么路由器將丟棄這些數(shù)據(jù)報，然后返回一個意思為“需要分片，設(shè)置了DF位 [7]”的ICMP目的不可達(dá)報文。在收到這樣一條報文后（以后稱它為“數(shù)據(jù)報太大”報文），源主機減小它假定的這條路徑的PMTU。
 
   當(dāng)主機對PMTU的估計值小到它的數(shù)據(jù)報不需要分片也能轉(zhuǎn)發(fā)的時候，PMTU發(fā)現(xiàn)過程結(jié)束。或者，主機可以選擇停止在數(shù)據(jù)報首部中設(shè)置DF比特位來結(jié)束發(fā)現(xiàn)過程；它可能會這樣做，例如主機想在某些情況下讓數(shù)據(jù)報分片。通常，主機繼續(xù)在所有的數(shù)據(jù)報中設(shè)置DF，這是為了如果路由改變并且新的PMTU減小的時候，將會被發(fā)現(xiàn)。

   不幸的是，當(dāng)前指定的數(shù)據(jù)報太大報文不報告拒絕太大數(shù)據(jù)報的那一跳的MTU。所以源主機不能準(zhǔn)確地判定把它假設(shè)的PMTU減小多少。為了彌補這個缺點，我們建議使用當(dāng)前在數(shù)據(jù)報太大報文中沒有使用的一個報頭字段來報告減小的那一跳的MTU。這是支持PMTU發(fā)現(xiàn)的路由器唯一被指定的改變。

   路徑的PMTU可能隨著時間而改變，因為路由的拓?fù)浣Y(jié)構(gòu)可能改變。PMTU的減小通過數(shù)據(jù)報太大報文被檢測到，除非主機停止設(shè)置沿此路徑的數(shù)據(jù)報的DF比特位。為了檢測路徑的PMTU值的增加，主機周期地增加它假定的PMTU（如果它已經(jīng)停止，再重新設(shè)置DF比特位）。這幾乎總是導(dǎo)致數(shù)據(jù)報被丟棄，數(shù)據(jù)報太大報文產(chǎn)生，因為在大多數(shù)情況下，路徑的PMTU不會改變，所以不應(yīng)該頻繁地做這種工作。

   因為這種機制本質(zhì)上保證了主機接收不到來自另一臺進(jìn)行PMTU發(fā)現(xiàn)的對等者的分片，它可能對與某個不能重新裝配分片的數(shù)據(jù)報的主機進(jìn)行互操作有幫助。
3, 主機規(guī)范
    當(dāng)主機收到一個數(shù)據(jù)報太大報文時，它必須基于此報文中的下一跳MTU字段中的值（見第四節(jié)），減少對相關(guān)路徑的PMTU估計值。因為不同的應(yīng)用程序有不同的需要，不同的實現(xiàn)體系傾向于不同的策略，所以我們不能在這種情況下指定確定的行為。
 
   我們要求在收到數(shù)據(jù)報太大報文后，主機必須盡量去避免在最近一段時間再引出這樣的報文。主機可以減小沿著這條路徑發(fā)送的數(shù)據(jù)報的尺寸，或者在這些數(shù)據(jù)報首部停止設(shè)置不分段比特位。顯然，前一種策略在一段時間內(nèi)可能繼續(xù)導(dǎo)致產(chǎn)生數(shù)據(jù)報太大報文，但是因為這些報文中任何一個（和它們所響應(yīng)的被丟棄的數(shù)據(jù)報）都消耗因特網(wǎng)的資源，主機必須強迫PMTU發(fā)現(xiàn)過程匯聚。

   使用PMTU發(fā)現(xiàn)的主機一定要盡可能快地檢測到路徑MTU的減少。主機可以檢測到路徑MTU的增加，但是，因為這樣做需要發(fā)送比當(dāng)前估計的PMTU大的數(shù)據(jù)報， 而且PMTU很可能不增加，所以這種工作一定不要頻繁地做。檢測一個增加的嘗試（通過發(fā)送一個比當(dāng)前估計值大的數(shù)據(jù)報）一定不要在數(shù)據(jù)報太大報文收到后5分鐘內(nèi)做，或者在前一個成功的增加嘗試之后1分鐘內(nèi)做。我們建議把計時器設(shè)置為它們最小值的兩倍（分別為10分鐘和2分鐘）。

   主機必須能夠處理不包括下一跳MTU的數(shù)據(jù)報太大報文，因為不可能在有限的時間內(nèi)升級因特網(wǎng)中的所有路由器。來自一個沒有修改的路由器的數(shù)據(jù)報太大報文中的下一跳MTU字段（新定義的）中的值為0（這對于ICMP規(guī)范[7]是必需的，ICMP規(guī)范要求“未使用”字段必須要是0）。在第五節(jié)中，我們討論響應(yīng)老式的數(shù)據(jù)報太大報文（由一個沒有修改的路由器發(fā)出）的主機可能遵守的策略。

    主機一定不要使對路徑MTU的估計值低于68字節(jié)。
 
    主機一定不能增加它對路徑MTU的估計值來響應(yīng)數(shù)據(jù)報太大報文的內(nèi)容。一個通告路徑MTU增加的報文可能是一個在因特網(wǎng)中飄移的過時的數(shù)據(jù)報，一個作為服務(wù)拒絕攻擊一部分的虛假的數(shù)據(jù)報，或者是由于到目的地址有多條路徑造成的結(jié)果。
3.1 TCP MSS選項
   作PMTU發(fā)現(xiàn)的主機一定要遵守不發(fā)送大于576字節(jié)的IP數(shù)據(jù)報的規(guī)則，除非它具有接收者的許可。對于TCP連接來說，這意味著主機一定不能發(fā)送大于40字節(jié)加上它的對等者發(fā)來的最大段尺寸（MSS）的數(shù)據(jù)報。

         注意：TCP MSS 被定義為相關(guān)的IP數(shù)據(jù)報尺寸減40[9]。最大IP數(shù)據(jù)報尺寸的默認(rèn)值576將導(dǎo)致TCP MSS的默認(rèn)值是536字節(jié)。

   "Requirements for Internet Hosts -- Communication Layers" [1]的 4.2.2.6節(jié)中陳述了：
 
         一些TCP實現(xiàn)只有當(dāng)目的主機在一個非直接連接網(wǎng)絡(luò)上才發(fā)送MSS選項。但是，通常TCP層不可能有適當(dāng)?shù)匦畔碜鞒鲞@種決定，所有它更愿意把決定因特網(wǎng)路徑合適的MTU的工作留給IP層來完成。

   實際上，很多TCP實現(xiàn)總是發(fā)送MSS選項， 但是，如果目的地不是本地的，把值設(shè)置為536。當(dāng)因特網(wǎng)中充滿了不遵守超過576字節(jié)的數(shù)據(jù)報不發(fā)給非本地的目的地址規(guī)則的主機的時候，這種行為是正確的。現(xiàn)在大多數(shù)主機遵守這個規(guī)則，所以對非本地的對等者來說也不必把TCP MSS選項的值限制為536。

而且，這樣做防止發(fā)現(xiàn)超過576的PMTU，所以，主機應(yīng)該不再減少它們在MSS選項中發(fā)送的值。MSS選項應(yīng)該比主機能夠重組的最大數(shù)據(jù)報（MSS_R,在[1]中定義）的尺寸小40字節(jié)； 在許多情況下，這將有65495 (65535 - 40)字節(jié)結(jié)構(gòu)上的限制。主機可能發(fā)送從它連接網(wǎng)絡(luò)上的MTU（對一個多宿主主機來說，是在它所有連接網(wǎng)絡(luò)中的最大MTU）得到的MSS值；這應(yīng)該不會對PMTU發(fā)現(xiàn)造成問題，可以阻止一個損壞的對等者發(fā)送巨大的數(shù)據(jù)報。

          注意：這時，我們沒有看到發(fā)送比連接的網(wǎng)絡(luò)最大的MTU還要大的MSS的原因。我們建議主機不使用65495。因為一些IP實現(xiàn)可能有負(fù)比特位的錯誤，這種錯誤在在沒有必要使用這么大的MSS的時候被觸發(fā)。
4. 路由器規(guī)范
     路由器不能轉(zhuǎn)發(fā)數(shù)據(jù)報，是因為數(shù)據(jù)報超過了下一跳網(wǎng)絡(luò)的MTU并且它的不分段比特位被設(shè)置， 路由器需要給數(shù)據(jù)報的源地址返回一個ICMP的目的不可達(dá)報文，此報文帶有表示“需要分段，設(shè)置了DF位”的代碼。為了支持在此備忘錄中說明的路徑MTU發(fā)現(xiàn)技術(shù)，路由器必須在ICMP首部字段中低序的16bit中包含下一跳網(wǎng)絡(luò)的MTU，這個字段在ICMP規(guī)范[7]中被標(biāo)記為“未使用”。高序的16bit保持未用，必須設(shè)置為0。因此，報文具有下面的格式：

       0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   類型 = 3    |   代碼 = 4    |           校驗和           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           未使用 = 0         |        下一跳    MTU      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Internet 首部 + 原始數(shù)據(jù)報中的前 64 bit             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
   在下一跳MTU字段中的值是：
 
沿著原始數(shù)據(jù)報的路徑，在此路由器上不需分段能夠轉(zhuǎn)發(fā)的最大數(shù)據(jù)報的用字節(jié)表示的尺寸，這個尺寸包含IP首部和IP數(shù)據(jù)，不包含任何低層的首部。

這個字段不會包含小于68字節(jié)的值，因為每一個路由器都“必須不分段轉(zhuǎn)發(fā)68字節(jié)的數(shù)據(jù)報”[8]。