本備忘錄的狀態

本文檔為Internet社區提供信息。它并不定義任何Internet標準。本備忘錄的發布不受任
何限制。

版權聲明

Copyright(C)TheInternetSociety(2000).AllRightsReserved.

摘要

本備忘錄編制了幾個已知和路徑最大傳輸單元發現(PMTUD)相關的傳輸控制協議（TCP）實
現問題，包括長期存在的黑洞問題，由于最大段長（MSS）和段長的混淆造成的彈性確認
（ACKs）問題，以及基于PMTU的MSS通告問題。

目錄
1介紹 2
2已知的實現問題 2
2.1問題名字 2
2.2問題名字 4
2.3問題名字 7
3安全考慮 9
4致謝 9
5參考 9
6作者地址： 10
7完整的版權說明 10
1介紹
本備忘錄編制了幾個已知和路徑最大傳輸單元發現(PMTUD)相關的傳輸控制協議（TCP）實
現問題，包括長期存在的黑洞問題，由于最大段長（MSS）和段長的混淆造成的彈性確認
（ACKs）問題，以及基于PMTU的MSS通告問題。這么做的目的是通過改進當前TCP/ip實現
的質量來改善目前Internet的環境。
路徑MTU發現（PMTUD）可被任何上層協議使用，但通常TCP用得最多。本文檔不打算涉及
其它上層協議碰到的問題。Ipv6的路徑MTU發現[RFC1981]只處理與Ipv6相關的情況，不
是本文檔要討論的情況。
每個問題按如下定義：
問題名字
與問題相聯系的名字。在本備忘錄中，名字作為子小節的標題。
分類
該問題的更多分類是：“擁塞控制”，“性能”，“可靠性”，“非互操作――連接
失敗”。
描述
問題定義，簡潔但包括了必要的背景材料。
意義
對幾個環境的簡單總結表明問題的意義。
含義
為什么這個問題被當作一個問題。
相關RFC
和該問題相抵觸的定義TCP的RFC。這些RFC通常使用術語如必須，應該，可以及其它
大寫的詞語指示該如何動作。這些術語的確切解釋見RFC2119。
闡述問題的輸出文件
若合適的話，給出一個或多個ASCII輸出文件闡述問題
解釋什么是正確處理的輸出文件
若合適的話，給出一個或多個ASCII輸出文件解釋正確處理的輸出
參考
對問題進一步討論的參考材料
如何檢測
如何對實現測試來檢查是否有這個問題。
如何修改
對原因已明的問題，如何改正實現。
2已知的實現問題
2.1問題名字
黑洞檢測
分類
非交互操作――連接失敗
描述
主機執行路徑MTU發現方法是發送盡可能大的包，在IP頭置上不要分片位（DF）。若
包太大無法由路由器轉發到特定路徑，路由器必須給源地址發送一個目的不可達――需要
分片的ICMP消息。主機將基于這個ICMP消息調整包大小。

正如[RFC1435]中指出的，路由器并不總能正確處理這種事件――許多路由器未能發送
ICMP消息，或是由于核心的bug或是由于配置原因等。若實現遵守相關文檔的建議，
Ipsec[RFC2401]和IP-in-IP[RFC2003]隧道不應引起這種問題。

如[RFC1191]中指出的，當原始主機未能收到合適的ICMP消息時PMTUD失敗。沒有
ICMP消息通知就無法發現需要減小包大小，上層協議則繼續嘗試發送大包。它發的包在
PMTUD黑洞中消失。
意義
當由于沒有ICMP消息導致PMTUD失敗時，TCP在某些條件下也會完全失效。
含義
因為到目的主機的ping和某些交互式TCP連接是正常的，這種故障尤其難查。大流量
傳輸在第一個大包即失敗而連接最終超時。
這種情況幾乎總是由于網絡的應該被更正的配置錯誤造成。然而似乎在路徑上某些TCP
實現互操作失敗而未影響到其它TCP實現（也就是那些沒有PMTUD的），這是不合適的。這
使得市場不愿將TCP實現配置為PMTUD使能。
相關RFC
RFC1191描述路徑MTU發現。RFC1435提供了早期這類問題的描述。
闡述問題的輸出文件
用tcpdump[Jacobson89]在一個中間主機上記錄的結果：

20:12:11.951321A>B:S1748427200:1748427200(0)
win49152<mss1460>
20:12:11.951829B>A:S1001927984:1001927984(0)
ack1748427201win16384<mss65240>
20:12:11.955230A>B:.ack1win49152(DF)
20:12:11.959099A>B:.1:1461(1460)ack1win49152(DF)
20:12:13.139074A>B:.1:1461(1460)ack1win49152(DF)
20:12:16.188685A>B:.1:1461(1460)ack1win49152(DF)
20:12:22.290483A>B:.1:1461(1460)ack1win49152(DF)
20:12:34.491856A>B:.1:1461(1460)ack1win49152(DF)
20:12:58.896405A>B:.1:1461(1460)ack1win49152(DF)
20:13:47.703184A>B:.1:1461(1460)ack1win49152(DF)
20:14:52.780640A>B:.1:1461(1460)ack1win49152(DF)
20:15:57.856037A>B:.1:1461(1460)ack1win49152(DF)
20:17:02.932431A>B:.1:1461(1460)ack1win49152(DF)
20:18:08.009337A>B:.1:1461(1460)ack1win49152(DF)
20:19:13.090521A>B:.1:1461(1460)ack1win49152(DF)
20:20:18.168066A>B:.1:1461(1460)ack1win49152(DF)
20:21:23.242761A>B:R1461:1461(0)ack1win49152(DF)

短的SYN包因為包小通過網絡沒問題。同樣，用于診斷連通性問題的ICMP響應包也能
成功通過。
大數據包通過網絡時失敗。最終連接超時。若應用是從少量數據的寫開始，成功，再
開始大數據量寫，失敗，這種情形尤其令人迷惑。
解釋什么是正確處理的輸出文件
用tcpdump[Jacobson89]在一個中間主機上記錄的結果：

16:48:42.659115A>B:S271394446:271394446(0)
win8192<mss1460>(DF)
16:48:42.672279B>A:S2837734676:2837734676(0)
ack271394447win16384<mss65240>

16:48:42.676890A>B:.ack1win8760(DF)
16:48:42.870574A>B:.1:1461(1460)ack1win8760(DF)
16:48:42.871799A>B:.1461:2921(1460)ack1win8760(DF)
16:48:45.786814A>B:.1:1461(1460)ack1win8760(DF)
16:48:51.794676A>B:.1:1461(1460)ack1win8760(DF)
16:49:03.808912A>B:.1:537(536)ack1win8760
16:49:04.016476B>A:.ack537win16384
16:49:04.021245A>B:.537:1073(536)ack1win8760
16:49:04.021697A>B:.1073:1609(536)ack1win8760
16:49:04.120694B>A:.ack1609win16384
16:49:04.126142A>B:.1609:2145(536)ack1win8760

在這種情況下，發送者發現四個包發送失敗（使用兩個包的初始發送窗口），停掉了
PMTUD。所有接著發送的包的DF標志都關閉，包大小設為缺省值536[RFC1122]。
參考
這個問題在tcp實現的郵件列表中被廣泛討論；名字“黑洞”已使用多年。
如何檢測
這個問題表現為TCP連接掛起（無法繼續）直到超時（這經常表現為連接已建立并開
始傳輸，然后在15分鐘后最終終止而未發送任何字節）。而象FTP這樣的應用尤其令人討
厭，開始傳輸小包的控制信息時非常好，但開始大塊數據傳輸時就失敗。
一系列的ICMP響應包表明兩端主機仍能傳送包，一系列MTU大小的ICMP響應包會發現
有分片現象，而一系列MTU大小的帶DF標志的ICMP響應包則失敗。對要診斷問題的網絡工
程師來說這令人迷惑。
有幾個做PMTUD的traceroute的實現能解釋這個問題。
如何修改
TCP應該會注重到連接已超時。在幾次超時后，TCP應該試圖發送小一點的包，也可以
把每個包的DF標志關閉。若這樣成功，就應繼續把這個連接的PMTUD關閉一段時間，直到
它再次檢測試圖確定路徑是否已改變。
注重，在Ipv6中沒有DF位――它是永遠隱含設置的。在路由器中不答應分片，只在
源主機答應分片。幸運的是，Ipv6支持的最小MTU是1280字節，遠遠大于Ipv4中的最小
68字節。當Ipv4實現檢測到黑洞問題時可能要關掉DF，與之相比，Ipv6實現后退到1280
字節的包應是合理的。
ICMP黑洞理想的處理應是在發現時處理。
若主機開始執行黑洞檢測，有可能問題將仍然被人忽視并未得到修復。因為每次檢測
將花費幾秒時間且延遲將引起隱藏的性能相當下降，這十分糟糕。實施黑洞檢測的主機應
記錄檢測的黑洞以便能修復。


2.2問題名字
由于PMTUD引起的ACK延遲(stretchACK)
分類
擁塞控制/性能
描述
當一個實現上未作復雜處理的TCP協議棧和一個有PMTUD功能的TCP協議棧通信時，對
每隔兩個的全尺寸包將試圖產生一個ACK。若是基于通告的MSS來決定全尺寸大小，則在面
臨PMUTD時會嚴重降低性能。
PMTU可以減小為只是通告的MSS的一小段；在這種情況下，ACK只是會很少產生。
意義
延遲的ACK有一系列不好的影響，更完整的列在[RFC2525]。由于ACK很少到達，多數
會產生更突發性的連接。它們能阻止擁塞窗口的增長。
含義
延遲的ACK的完整含義列在[RFC2525]。
相關RFC
RFC1122列出了對ACK頻繁產生的需求。[RFC2581]對此進行了擴展并且聲明延遲ACK
是應該而不是必須。
闡述問題的輸出文件
在中間主機上使用tcpdump記錄。為簡明起見，除了頭兩個包以外，其它包的時間戳
選項都被刪除。

18:16:52.976657A>B:S3183102292:3183102292(0)win16384
<mss4312,nop,wscale0,nop,nop,timestamp121280>(DF)
18:16:52.979580B>A:S2022212745:2022212745(0)ack3183102293win
49152<mss4312,nop,wscale1,nop,nop,timestamp159295712128>(DF)
18:16:52.979738A>B:.ack1win17248(DF)
18:16:52.982473A>B:.1:4301(4300)ack1win17248(DF)
18:16:52.982557C>A:icmp:Bunreachable-
needtofrag(mtu1500)!(DF)
18:16:52.985839B>A:.ack1win32768(DF)
18:16:54.129928A>B:.1:1449(1448)ack1win17248(DF)
.
.
.
18:16:58.507078A>B:.1463941:1465389(1448)ack1win17248(DF)
18:16:58.507200A>B:.1465389:1466837(1448)ack1win17248(DF)
18:16:58.507326A>B:.1466837:1468285(1448)ack1win17248(DF)
18:16:58.507439A>B:.1468285:1469733(1448)ack1win17248(DF)
18:16:58.524763B>A:.ack1452357win32768(DF)
18:16:58.524986B>A:.ack1461045win32768(DF)
18:16:58.525138A>B:.1469733:1471181(1448)ack1win17248(DF)
18:16:58.525268A>B:.1471181:1472629(1448)ack1win17248(DF)
18:16:58.525393A>B:.1472629:1474077(1448)ack1win17248(DF)
18:16:58.525516A>B:.1474077:1475525(1448)ack1win17248(DF)
18:16:58.525642A>B:.1475525:1476973(1448)ack1win17248(DF)
18:16:58.525766A>B:.1476973:1478421(1448)ack1win17248(DF)
18:16:58.526063A>B:.1478421:1479869(1448)ack1win17248(DF)
18:16:58.526187A>B:.1479869:1481317(1448)ack1win17248(DF)
18:16:58.526310A>B:.1481317:1482765(1448)ack1win17248(DF)
18:16:58.526432A>B:.1482765:1484213(1448)ack1win17248(DF)
18:16:58.526561A>B:.1484213:1485661(1448)ack1win17248(DF)
18:16:58.526671A>B:.1485661:1487109(1448)ack1win17248(DF)
18:16:58.537944B>A:.ack1478421win32768(DF)
18:16:58.538328A>B:.1487109:1488557(1448)ack1win17248(DF)
注重ACK之間的間隔比兩倍段大小還要大；它消耗了幾乎兩倍于建議的MSS的時間。傳輸時
間長得可以驗證延遲的ACK不是丟失ACK包的結果。

解釋什么是正確處理的輸出文件
在中間主機上使用tcpdump記錄。為簡明起見，除了頭兩個包以外，其它包的時間戳選項
都被刪除。

18:13:32.287965A>B:S2972697496:2972697496(0)
win16384<mss4312,nop,wscale0,nop,nop,timestamp113260>(DF)
18:13:32.290785B>A:S245639054:245639054(0)
ack2972697497win34496<mss4312>(DF)
18:13:32.290941A>B:.ack1win17248(DF)
18:13:32.293774A>B:.1:4313(4312)ack1win17248(DF)
18:13:32.293856C>A:icmp:Bunreachable-
needtofrag(mtu1500)!(DF)
18:13:33.637338A>B:.1:1461(1460)ack1win17248(DF)
.
.
.
18:13:35.561691A>B:.1514021:1515481(1460)ack1win17248(DF)
18:13:35.561814A>B:.1515481:1516941(1460)ack1win17248(DF)
18:13:35.561938A>B:.1516941:1518401(1460)ack1win17248(DF)
18:13:35.562059A>B:.1518401:1519861(1460)ack1win17248(DF)
18:13:35.562174A>B:.1519861:1521321(1460)ack1win17248(DF)
18:13:35.564008B>A:.ack1481901win64680(DF)
18:13:35.564383A>B:.1521321:1522781(1460)ack1win17248(DF)
18:13:35.564499A>B:.1522781:1524241(1460)ack1win17248(DF)
18:13:35.615576B>A:.ack1484821win64680(DF)
18:13:35.615646B>A:.ack1487741win64680(DF)
18:13:35.615716B>A:.ack1490661win64680(DF)
18:13:35.615784B>A:.ack1493581win64680(DF)
18:13:35.615856B>A:.ack1496501win64680(DF)
18:13:35.615952A>B:.1524241:1525701(1460)ack1win17248(DF)
18:13:35.615966B>A:.ack1499421win64680(DF)
18:13:35.616088A>B:.1525701:1527161(1460)ack1win17248(DF)
18:13:35.616105B>A:.ack1502341win64680(DF)
18:13:35.616211A>B:.1527161:1528621(1460)ack1win17248(DF)
18:13:35.616228B>A:.ack1505261win64680(DF)
18:13:35.616327A>B:.1528621:1530081(1460)ack1win17248(DF)
18:13:35.616349B>A:.ack1508181win64680(DF)
18:13:35.616448A>B:.1530081:1531541(1460)ack1win17248(DF)
18:13:35.616565A>B:.1531541:1533001(1460)ack1win17248(DF)
18:13:35.616891A>B:.1533001:1534461(1460)ack1win17248(DF)

在本例中，每兩段到達的數據產生一個ACK。(即使源主機是同一個，由于沒有時間戳
選項，在本例中段長較大)。

如何檢測
這樣的情況可在當通告的MSS比連接的實際PMTU要大得多的跟蹤包中可看到。
如何修改該問題有幾個建議：
一個簡單的辦法是回答每個包，而不管其大小。這有一個缺點是在處理大量小包時產
生大量的ACK；在X窗口系統中就有這樣的應用。
一個稍微復雜的處理辦法是監測進來的段大小并試圖決定發送者使用的段大小。這對
接收者的狀態要求多一點，但計算得更精確，能避免糊涂窗口綜合癥。

2.3問題名字
從PMTU確定MSS
分類
性能
描述
在連接開始階段的MSS通告應基于系統接口的MTU。（因為效率和其它原因這可能不是
最大的MSS）。某些系統使用決定的PMTUD值來決定要通告的MSS值。
這導致了通告的MSS要小于系統能接收的最大的MTU。
意義
通告的MSS向遠程系統指示了可接收的最大TCP段[RFC879]。若該值太小，遠程系統
在發送時被迫使用小的段長，完全是由于本地系統在較早時發現一個非凡的PMTU。
由于Internet上路由器的不對稱屬性[Paxson97]，返回的PMTU和發送的PMTU完全可
能不同。使用這種辦法限制段長可能造成性能降低及使PMTUD算法失敗。
即使路由器是對稱的，人為將段長限制降低會使得不可能以后查詢來決定PMTU是否改
變。
含義
整個PMTUD的要點是盡可能發送大的段。若一個持續了很長時間的連接不能檢測到更
大的PMTUD，那么就無法獲得潛在的性能。這破壞了PMTUD的要點。
相關RFCRFC1191。
[RFC879]有MSS計算和適當值的討論。注重本實踐并不和這些RFC的定義相沖突。
闡述問題的輸出文件
輸出文件是在中間主機上用tcpdump記錄。主機A初始化兩條到主機B的單獨的連接
A1和A2。路由器是在MTU瓶頸位置。TCP選項照常從所有非SYN包中移走。

22:33:32.305912A1>B:S1523306220:1523306220(0)
win8760<mss1460>(DF)
22:33:32.306518B>A1:S729966260:729966260(0)
ack1523306221win16384<mss65240>
22:33:32.310307A1>B:.ack1win8760(DF)
22:33:32.323496A1>B:P1:1461(1460)ack1win8760(DF)
22:33:32.323569C>A1:icmp:129.99.238.5unreachable-
needtofrag(mtu1024)(DF)(ttl255,id20666)
22:33:32.783694A1>B:.1:985(984)ack1win8856(DF)
22:33:32.840817B>A1:.ack985win16384
22:33:32.845651A1>B:.1461:2445(984)ack1win8856(DF)
22:33:32.846094B>A1:.ack985win16384
22:33:33.724392A1>B:.985:1969(984)ack1win8856(DF)
22:33:33.724893B>A1:.ack2445win14924
22:33:33.728591A1>B:.2445:2921(476)ack1win8856(DF)
22:33:33.729161A1>B:.ack1win8856(DF)
22:33:33.840758B>A1:.ack2921win16384

[...]

22:33:34.238659A1>B:F7301:8193(892)ack1win8856(DF)
22:33:34.239036B>A1:.ack8194win15492
22:33:34.239303B>A1:F1:1(0)ack8194win16384

22:33:34.242971A1>B:.ack2win8856(DF)
22:33:34.454218A2>B:S1523591299:1523591299(0)
win8856<mss984>(DF)
22:33:34.454617B>A2:S732408874:732408874(0)
ack1523591300win16384<mss65240>
22:33:34.457516A2>B:.ack1win8856(DF)
22:33:34.470683A2>B:P1:985(984)ack1win8856(DF)
22:33:34.471144B>A2:.ack985win16384
22:33:34.476554A2>B:.985:1969(984)ack1win8856(DF)
22:33:34.477580A2>B:P1969:2953(984)ack1win8856(DF)

[...]
注重會話A2的SYN包定義了MSS為984。

解釋什么是正確處理的輸出文件
和前面一樣，輸出文件是在中間主機上用tcpdump記錄。主機A初始化兩條到主機B的單獨
的連接A1和A2。路由器是在MTU瓶頸位置。TCP選項照常從所有非SYN包中移走。

22:36:58.828602A1>B:S3402991286:3402991286(0)win32768
<mss4312,wscale0,nop,timestamp11233703090,
echo1123370309>(DF)
22:36:58.844040B>A1:S946999880:946999880(0)
ack3402991287win16384
<mss65240,nop,wscale0,nop,nop,timestamp4295521123370309>
22:36:58.848058A1>B:.ack1win32768(DF)
22:36:58.851514A1>B:P1:1025(1024)ack1win32768(DF)
22:36:58.851584C>A1:icmp:129.99.238.5unreachable-
needtofrag(mtu1024)(DF)
22:36:58.855885A1>B:.1:969(968)ack1win32768(DF)
22:36:58.856378A1>B:.969:985(16)ack1win32768(DF)
22:36:59.036309B>A1:.ack985win16384
22:36:59.039255A1>B:FP985:1025(40)ack1win32768(DF)
22:36:59.039623B>A1:.ack1026win16344
22:36:59.039828B>A1:F1:1(0)ack1026win16384
22:36:59.043037A1>B:.ack2win32768(DF)
22:37:01.436032A2>B:S3404812097:3404812097(0)win32768
<mss4312,wscale0,nop,timestamp11233729160,
echo1123372916>(DF)
22:37:01.436424B>A2:S949814769:949814769(0)
ack3404812098win16384
<mss65240,nop,wscale0,nop,nop,timestamp4295621123372916>
22:37:01.440147A2>B:.ack1win32768(DF)
22:37:01.442736A2>B:.1:969(968)ack1win32768(DF)

22:37:01.442894A2>B:P969:985(16)ack1win32768(DF)
22:37:01.443283B>A2:.ack985win16384
22:37:01.446068A2>B:P985:1025(40)ack1win32768(DF)
22:37:01.446519B>A2:.ack1025win16384
22:37:01.448465A2>B:F1025:1025(0)ack1win32768(DF)
22:37:01.448837B>A2:.ack1026win16384
22:37:01.449007B>A2:F1:1(0)ack1026win16384
22:37:01.452201A2>B:.ack2win32768(DF)

注重會話A1和A2使用同樣的MSS。

如何檢測
可以通過追蹤兩個單獨連接的包來檢測；第一個應該激活PMTUD；在第一個之后第二個
應該在PMTU值未超時前盡快啟動。
如何修改
如[RFC1122]和[RFC1191]中指出的，MSS應該基于系統接口的MTU來設置。
3安全考慮
本備忘錄指出的第一個安全考慮是，ICMP黑洞經常由于過于熱心于安全的治理員阻塞所有
ICMP消息引起。那些設計和配置安全系統的人理解嚴格過濾上層協議的影響是至關重要
的。若大多數TCP實現無法從中傳輸數據的話，世界上最安全的web站點也就沒有任何價
值。修復所有黑洞要比修復所有TCP實現要好得多。
4致謝
感謝MarkAllman,VernPaxson,和JamshidMahdavi慷慨的幫助審閱了文檔，感謝
MattMathis對引起PMTUD黑洞問題的各種機制的提議及評論。描述TCP問題的結構和該結
構的早期描述是從[RFC2525]中得來。非凡感謝AmyBock幫助進行PMTUD測試以發現這些漏
洞。

5參考
[RFC2581]Allman,M.,Paxson,V.andW.Stevens,"TCPCongestion
Control",RFC2581,APRil1999.

[RFC1122]Braden,R.,"RequirementsforInternetHosts--
CommunicationLayers",STD3,RFC1122,October1989.

[RFC813]Clark,D.,"WindowandAcknowledgementStrategyinTCP",
RFC813,July1982.

[Jacobson89]V.Jacobson,C.Leres,andS.McCanne,tcpdump,June
1989,ftp.ee.lbl.gov

[RFC1435]Knowles,S.,"IESGAdvicefromEXPeriencewithPathMTU
Discovery",RFC1435,March1993.

[RFC1191]Mogul,J.andS.Deering,"PathMTUdiscovery",RFC
1191,November1990.

[RFC1981]McCann,J.,Deering,S.andJ.Mogul,"PathMTU
DiscoveryforIPversion6",RFC1981,August1996.

[Paxson96]V.Paxson,"End-to-EndRoutingBehaviorinthe
Internet",IEEE/ACMTransactionsonNetworking(5),
pp.~601-615,Oct.1997.

[RFC2525]Paxon,V.,Allman,M.,Dawson,S.,Fenner,W.,Griner,
J.,Heavens,I.,Lahey,K.,Semke,I.andB.Volz,
"KnownTCPImplementationProblems",RFC2525,March
1999.

[RFC879]Postel,J.,"TheTCPMaximumSegmentSizeandRelated
Topics",RFC879,November1983.

[RFC2001]Stevens,W.,"TCPSlowStart,CongestionAvoidance,Fast
Retransmit,andFastRecoveryAlgorithms",RFC2001,
January1997.


6作者地址：

KevinLahey
dotRocket,Inc.
1901S.BascomAve.,Suite300
Campbell,CA95008
USA

Phone:+1408-371-8977x115
email:kml@dotrocket.com


7完整的版權說明

Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsUChcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurpoSEOf
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.

致謝
FundingfortheRFCEditorfunctioniscurrentlyprovidedbythe
InternetSociety.