注意：執行可以避免使用異步通知機制來通知PMTU的降低，通過延遲通知直到下一次嘗試發送大于PMTU估計的分組時。使用這種方法，當嘗試發送大于PMTU估計的分組時，發送失敗并返回合適的錯誤指示。這種方法可能更適用于無連接分組層（如使用UDP），因為它們（在一些執行中）可能很難被ICMP層通知到。這樣的話，普通的超時重發機制可以用來恢復丟棄的分組。
通知分組層實例使用的路徑PMTU的改變和通知特殊的實例分組被丟棄是截然不同的，這一點很重要。后者一旦應用就實現（也就是說，對于分組層實例來說它是異步的），而前者可能要推遲到分組層實例想要創造分組時。只有當那些已知分組被丟棄時（由分組長度超限信息指示）重發才能實現。
5.3 清除陳舊PMTU信息
網間布局是動態的，路線會隨時間的過去而改變。然而一個路徑的本地代表是保持不變的，實際應用的路徑卻可能會改變。這樣節點存儲的PMTU信息可能會變得陳舊。
如果陳舊的PMTU值太大，一旦一個足夠大的分組發送到該路徑上就會被發現。沒有相關的機制能夠發現陳舊的PMTU值太小，所以應當采用一個執行來計算存儲值的“年齡”。當PMTU值經過一段時間（規定是10分鐘）后沒有被降低，PMTU估計應當被設置為第一距離段的MTU，并且應當通知分組層這個改變。這樣就使整個路徑MTU發現過程重新進行。
注意：執行應當提供一種方法改變超時時間，包括設置為“無限”。例如，FDDI連接上的節點另一端連接在較小的MTU連接上，它永遠無法發現新的非本地PMTU，所以它不應當10分鐘丟棄分組。
上層不能因PMTU估計的增長而重發數據，因為這種增長永遠無法產生丟棄分組的指示。
一種計算PMTU年齡的方法是讓PMTU值有一個時標域。這個域初始化為“預留”值，指示PMTU與第一距離段的MTU相等。無論何時一旦PMTU因收到分組長度超限信息而減小時，時標被設為當前時間。
一旦計時器程序在所有PMTU開始運行，對每一個PMTU只要它的時標不是預留并且超過了超時間隔：
－PMTU估計設置為第一距離段的MTU。
－時標設置為預留狀態。
－使用該路徑通知分組層此增長。
5.4 TCP層動作
TCP層必須通過一種連接記錄路徑上的PMTU；它不能發送可能導致分組大于PMTU的分段。一個簡單的執行過程應當在每次建立新的分段時詢問IP層相應的值，但是它的效率很低。此外，TCP執行過程會遵循它典型的“慢啟動”擁塞回避算法，計算并儲存幾個其他的PMTU數值。當PMTU改變時它可以更簡單的接收異步通知，所以這些變量應當被更新。
TCP執行過程也必須等同的找到并存儲MSS值，并且不能發送超過MSS的分段，不管PMTU是如何。在4.xBSD-derived執行中，還需要增加附加的區域記錄TCP狀態。
發送到TCP MSS選項中的值與PMTU是相互獨立的。這個MSS選項值被連接的另一端使用，它可能使用無關的PMTU值。見[IPv6-SPEC]部分"Packet Size Issues" 和 "Maximum Upper-Layer Payload Size"，有選擇TCP MSS選項值的信息。
當收到分組長度超限信息時，它意味著一個分組被節點丟棄并發送了ICMP信息。這就足夠把這件事當作其他丟棄的分段，并等待重發計時器過期引起重發分段。如果路徑MTU發現過程需要幾個步驟去發現整個路徑的PMTU，這樣來回反復會延遲連接時間。
或者可以在收到路徑MTU變化通知時立即重發，但是只能對指定了分組長度超限信息的特殊連接可行。重發中的分組長度不能超過新的PMTU。
注意：分組層不能對每個分組長度超限信息作出重發響應，因為幾個分段超限的爆發會引起幾個同樣的信息從而重發相同的信息。如果新的PMTU仍是錯的，那么過程重復，并且多余分段的發送會呈指數增長。這意味著TCP層必須能夠在分組長度超限信息到達時認出真正的PMTU的降低，并忽視其他的通知。
許多TCP執行過程包含擁塞避免和滿啟動算法來提高性能[CONG]。與TCP重發超時引起的重發不同，由分組長度超限信息引起的重發不能改變擁塞窗口。然而，它可以引發滿啟動算法（也就是說，直到確認信息到達前只有一個分段可以被重發）。
當發送者的窗口大小不是使用的分段大小的整數倍時（這不是擁塞窗口大小），TCP性能會下降。在很多系統中（如4.2BSD中），分段大小經常被設為1024八位組，最大的窗口大小（“發送空間”）通常是1024八位組，所以保持者正確的關系。然而如果路徑MTU發現被使用，分段大小就可能不會是發送空間的約數，它可能在連接時改變；這意味著在分組長度超限探索改變了PMTU的值時TCP層可能需要改變重發窗口大小。最大窗口大小應當設為分段大小的最大倍數，小于或等于發送者的緩存空間。
5.5 其他傳輸協議的運行問題
一些傳輸協議（如ISO TP4在[ISOTP]）不允許在重發的時候重新分組。更確切的說，一旦一個傳輸嘗試開始進行，分段具有一特定的大小，那么不允許在重發中將分段內容分成更小的分段。在這種情況下，原始分段可以在IP層的重發過程中被分為更小的段。后來的段在第一次傳輸中，不能大于路徑MTU的允許。
Sun網絡文件系統（NFS）使用遠距離程序調用（RPC）協議[RPC]，當在UDP上使用時，在很多情況下都會產生有效載荷即使實在第一距離段連接時，都要進行分段。這樣可能提高性能，但會引發可靠性和執行問題，特別是當客戶端和服務器被路由器分開時。
不管是否包含路由器，我們都建議NFS執行使用路徑MTU發現。大多數的NFS執行允許RPC數據報長度在執行期間可變（通過改變有效的文件系統字區大小，間接的改變），但是可能為了支持后面的改變需要一些修改。
同樣的，由于單一的NFS操作不能被分為幾個UDP數據報，特別的操作（主要是那些對于文件名和目錄的操作）需要最小的有效載荷長度，使當被送到單一的分組時會大于PMTU。NFS執行不能把有效載荷長度減小到低于這個門限，即使路徑MTU發現建議一個更小的值。在這種情況下，有效載荷會被IP層分段。
5.6 管理界面
我們建議執行過程提供一種方法使系統能有效進行：
－確定路徑MTU探索沒有在該路徑上被進行。
－在一指定路徑上改變PMTU值。
前者可以通過給路徑附加一標記完成；當分組被送到該路徑上發現作有標記，那么IP層就不再發送比IPv6最小鏈接MTU大的分組。
這些特征可以被應用于一些反常的情形下，或應用于路由協議執行，可以獲得路徑MTU值。
執行過程還應當提供能夠改變用于計算陳舊PMTU信息的超時時間的方法。
6 安全考慮
本路徑MTU發現機制可能引起兩個負面的攻擊，都是基于惡毒團體發送給節點的錯誤的分組長度超限信息。
第一個攻擊，錯誤的信息指示的PMTU遠小于實際。這樣不能完全停止數據流，因為受害的節點永遠無法將它的PMTU估計小于IPv6最小鏈接MTU。這樣就導致了不理想的性能。
第二個攻擊，錯誤的信息指示了PMTU大于實際。如果相信它，就會引起暫時的阻塞，受害者發送的分組會被一些路由丟棄。在一個來回時間內，該節點會發現這個錯誤（從路由器收到分組長度超限信息），但是經常的收到這種攻擊就會使大量分組丟失。一個節點決不應在收到分組長度超限信息后增加它的估計，所以不是很容易被這種攻擊影響。
惡毒團體還可以通過停止受害者接收合法的分組長度超限信息來引發問題，但是這樣的話還有更簡單的攻擊方式存在。
致謝
我們感謝[RFC-1191]的作者和捐助者，這里的大部分文章都是源自那里。我們還感謝IPng工作組的成員，感謝他們細心的評論和有建設性的評語。
附錄A － 與RFC1191的對比
本文檔很大程度上基于RFC1191（描述了IPv4的路徑MTU探索）。在RFC1191里的一些部分這里是不需要的：
路由器說明		－分組長度超限信息和相應的路由動作在[ICMPv6]中定義
不分段比特位	－在IPv6分組里沒有DF位
TCP MSS討論		－選擇值發送到TCP MSS選項在[IPv6-SPEC]里討論
舊式信息		－所有分組長度超限信息報告了壓縮連接的MTU
MTU曲線表格		－因為沒有舊式信息，所以沒有必要了
參考文獻
[CONG]      Van Jacobson.  Congestion Avoidance and Control.  Proc.
            SIGCOMM '88 Symposium on Communications Architectures and
            Protocols, pages 314-329.  Stanford, CA, August, 1988.
[FRAG]      C. Kent and J. Mogul.  Fragmentation Considered Harmful.
            In Proc. SIGCOMM '87 Workshop on Frontiers in Computer
            Communications Technology.  August, 1987.
[ICMPv6]    Conta, A., and S. Deering, "Internet Control Message
            Protocol (ICMPv6) for the Internet Protocol Version 6
            (IPv6) Specification", RFC 1885, December 1995.
[IPv6-SPEC] Deering, S., and R. Hinden, "Internet Protocol, Version
            6 (IPv6) Specification", RFC 1883, December 1995.
[ISOTP]     ISO.  ISO Transport Protocol Specification: ISO DP 8073.
            RFC 905, SRI Network Information Center, April, 1984.
[ND]        Narten, T., Nordmark, E., and W. Simpson, "Neighbor
            Discovery for IP Version 6 (IPv6)", Work in Progress.
[RFC-1191]  Mogul, J., and S. Deering, "Path MTU Discovery",
            RFC 1191, November 1990.
[RPC]       Sun Microsystems, Inc., "RPC: Remote Procedure Call
            Protocol", RFC 1057, SRI Network Information Center,
            June, 1988.
作者地址
Jack McCann
Digital Equipment Corporation
110 Spitbrook Road, ZKO3-3/U14
Nashua, NH 03062
Phone: +1 603 881 2608
Fax:   +1 603 881 0120
Email: mccann@zk3.dec.com

Stephen E. Deering
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304
Phone: +1 415 812 4839
Fax:   +1 415 812 4471
EMail: deering@parc.xerox.com

Jeffrey Mogul
Digital Equipment Corporation Western Research Laboratory
250 University Avenue
Palo Alto, CA 94301
Phone: +1 415 617 3304
EMail: mogul@pa.dec.com
RFC1981――Path MTU Discovery for IP version 6                         IP 版本 6的路徑MTU探索