顏永明

（中國(guó)電信股份有限公司上海分公司 上海200030）

1 引言

中國(guó)電信股份有限公司上海分公司（以下簡(jiǎn)稱(chēng)上海電信）IP城域網(wǎng)在全國(guó)同類(lèi)網(wǎng)絡(luò)中規(guī)模最大，網(wǎng)絡(luò)結(jié)構(gòu)最為復(fù)雜。網(wǎng)絡(luò)分為A平面“城域網(wǎng)通道”和B平面“城域網(wǎng)優(yōu)化通道”兩大部分。A平面主要承載互聯(lián)網(wǎng)上網(wǎng)業(yè)務(wù)，B平面主要承載IPTV、軟交換、VPN、IPRAN等業(yè)務(wù)。上海電信在中國(guó)電信集團(tuán)公司下一代互聯(lián)網(wǎng)示范商用首批試點(diǎn)項(xiàng)目中，主要采用IPv6/IPv4公網(wǎng)雙棧過(guò)渡技術(shù)，于2013年實(shí)施了城域網(wǎng)A平面的IPv6改造，首批實(shí)現(xiàn)了數(shù)十萬(wàn)IPv6公客PPPoE撥號(hào)用戶(hù)的雙棧接入。在實(shí)踐中發(fā)現(xiàn)，因不同網(wǎng)絡(luò)和設(shè)備的MTU（max transfer unit，最大傳輸單元）配置存在差異，IPv6和IPv4在分段和MTU處理機(jī)制上有著各自特點(diǎn)，可能會(huì)造成用戶(hù)在有些情況下上網(wǎng)業(yè)務(wù)的使用出現(xiàn)問(wèn)題。本文就雙棧環(huán)境下分段和MTU技術(shù)原理、部署中需注意的問(wèn)題和解決方案進(jìn)行討論。

2 數(shù)據(jù)分組分段相關(guān)技術(shù)

2.1 MTU相關(guān)定義和解析

MTU指某一通信協(xié)議層面上所能通過(guò)的最大數(shù)據(jù)分組字節(jié)數(shù)大小，在IP城域網(wǎng)環(huán)境下通常將IP網(wǎng)絡(luò)層的MTU簡(jiǎn)稱(chēng)為MTU。當(dāng)網(wǎng)絡(luò)設(shè)備轉(zhuǎn)發(fā)數(shù)據(jù)分組時(shí)，會(huì)檢查其數(shù)據(jù)域大小是否小于等于出接口的MTU設(shè)置值。以EthernetⅡ幀為例，如圖1所示，數(shù)據(jù)域的大小=幀長(zhǎng)－DMAC（目的MAC）-SMAC（源MAC）-type（類(lèi)型字段）－CRC（檢驗(yàn)字段），計(jì)算所得通常稱(chēng)為數(shù)據(jù)分組大小。

圖1 EthernetⅡ幀結(jié)構(gòu)

一個(gè)IP數(shù)據(jù)分組從源主機(jī)到達(dá)目的主機(jī)所經(jīng)路徑上的各段鏈路MTU值不盡相同，要完成端到端的傳送，IP網(wǎng)絡(luò)層數(shù)據(jù)分組尺寸必須小于由各段鏈路構(gòu)成的整條路徑上的最小MTU。路徑上每一段鏈路所能傳送的最大IP分組尺寸，稱(chēng)為link MTU（鏈路MTU），源主機(jī)到目的主機(jī)整條路徑上的最小MTU則稱(chēng)為path MTU（路徑MTU），其大小等于數(shù)據(jù)分組途經(jīng)所有鏈路MTU的最小值。MTU值可在網(wǎng)絡(luò)設(shè)備的接口上配置，用來(lái)確保從該接口發(fā)出的數(shù)據(jù)分組尺寸小于或等于該值。如果源主機(jī)發(fā)送的IP網(wǎng)絡(luò)層數(shù)據(jù)分組尺寸大于路徑MTU，該數(shù)據(jù)分組會(huì)被分段或丟棄。

2.2 MRU定義及解析

PPP（point-to-point protocol，點(diǎn)對(duì)點(diǎn)協(xié)議）定義了LCP（link control protocol，鏈路控制協(xié)議）配置選項(xiàng)，該選項(xiàng)用于協(xié)商修改PPP點(diǎn)對(duì)點(diǎn)鏈路的默認(rèn)特性，其中包含稱(chēng)為MRU（maximum receive unit,最大接收單元）的字段，發(fā)送給PPP對(duì)端設(shè)備以告知本地設(shè)備能接收更大的數(shù)據(jù)分組，或者通知對(duì)端發(fā)送更小的數(shù)據(jù)分組。上海電信公客撥號(hào)用戶(hù)采用PPPoE撥號(hào)認(rèn)證方式，PPPoE基于PPP，同樣定義了MRU字段，協(xié)商建立PPPoE撥號(hào)會(huì)話(huà)時(shí)，撥號(hào)客戶(hù)端設(shè)備會(huì)將撥號(hào)接口所配MTU值作為PPPoE MRU字段發(fā)給撥號(hào)服務(wù)器（城域網(wǎng)中為BRAS），撥號(hào)服務(wù)器將收到的MRU值與自身接口配置的MTU值相比較，選取兩者中的較小值作為其后續(xù)發(fā)送數(shù)據(jù)分組的最大尺寸。

2.3 MSS定義及解析

MSS（maximum segment size，最大分段尺寸）用于TCP報(bào)文，規(guī)定了每個(gè)TCP報(bào)文中數(shù)據(jù)域的最大長(zhǎng)度。MSS定義的數(shù)據(jù)域不包含TCP頭部。MSS與MTU的關(guān)系為：MSS=MTU-IP頭部-TCP頭部。當(dāng)建立TCP連接3次握手時(shí)，協(xié)商的雙方會(huì)互相通告MSS大小。通過(guò)設(shè)定合適的MSS值可確保數(shù)據(jù)域被TCP、IP頭部封裝后，尺寸小于或等于path MTU，避免TCP報(bào)文在傳送過(guò)程中被分段。MSS只定義于TCP，在UDP及其他傳輸層協(xié)議中無(wú)定義。

2.4 數(shù)據(jù)分組分段原理解析

IPv4數(shù)據(jù)分組頭部包含DF(don’t fragment，不分段)位，路由器據(jù)此判斷能否對(duì)數(shù)據(jù)分組分段。若IPv4數(shù)據(jù)分組大小超過(guò)出接口MTU且設(shè)置了DF位，則被丟棄。若未設(shè)置DF位則由路由器分段后轉(zhuǎn)發(fā)。

IPv6頭部與IPv4協(xié)議不同，包含如下基本字段：版本、業(yè)務(wù)流類(lèi)別、流標(biāo)簽、凈荷長(zhǎng)度、下一分組頭、跳數(shù)限制、源地址、目的地址，共40 byte。除基本分組頭外，還定義了多種可選IPv6擴(kuò)展分組頭，fragment（分段）分組頭就屬于其中的一種，用于源節(jié)點(diǎn)對(duì)長(zhǎng)度超過(guò)其和目的節(jié)點(diǎn)間路徑MTU的分組實(shí)施分段。根據(jù)RFC規(guī)定，除了hop-by-hop（逐跳）擴(kuò)展分組頭外，其他擴(kuò)展分組頭都不會(huì)被傳送路徑上的節(jié)點(diǎn)檢查或處理，只有當(dāng)數(shù)據(jù)分組到達(dá)了目的地址標(biāo)識(shí)的節(jié)點(diǎn)時(shí)這些擴(kuò)展分組頭才被處理，且必須嚴(yán)格按照它們?cè)跀?shù)據(jù)分組內(nèi)出現(xiàn)的順序依次進(jìn)行。因此，對(duì)IPv6數(shù)據(jù)分組而言，分段動(dòng)作只能在源節(jié)點(diǎn)實(shí)施，不能被分組轉(zhuǎn)發(fā)路徑上的路由器執(zhí)行。當(dāng)IPv6數(shù)據(jù)分組大小超過(guò)路徑MTU時(shí)，會(huì)出現(xiàn)分組丟失現(xiàn)象。

3 雙棧環(huán)境下IP城域網(wǎng)MTU研究

上海電信公客撥號(hào)用戶(hù)上網(wǎng)路徑可劃分為3個(gè)段落，如圖2所示：第一段落為城域網(wǎng)接入側(cè)，包含用戶(hù)終端、家庭網(wǎng)關(guān)、EPON、匯聚交換機(jī)和BRAS下聯(lián)接口；第二段落為城域網(wǎng)絡(luò)側(cè)，包含BRAS上聯(lián)接口和上海電信城域網(wǎng)路由器；第三段落為Internet側(cè)，包括骨干網(wǎng)、異地/異網(wǎng)運(yùn)營(yíng)商、ICP內(nèi)網(wǎng)及應(yīng)用服務(wù)器。公客撥號(hào)用戶(hù)終端通過(guò)家庭網(wǎng)關(guān)上聯(lián)EPON，接入IP城域網(wǎng)BRAS、路由器等設(shè)備，最終實(shí)現(xiàn)Internet訪(fǎng)問(wèn)。

因城域網(wǎng)、互聯(lián)網(wǎng)、異地/異網(wǎng)運(yùn)營(yíng)商、ISP、ICP網(wǎng)絡(luò)情況紛繁復(fù)雜，MTU的配置存在差異，開(kāi)放的網(wǎng)絡(luò)環(huán)境中數(shù)據(jù)分組經(jīng)過(guò)的路徑又存在不確定性，這些都可能導(dǎo)致數(shù)據(jù)分組因MTU問(wèn)題無(wú)法順利到達(dá)目的端。尤其對(duì)于IPv6數(shù)據(jù)分組，因其分組頭比IPv4長(zhǎng)20 byte，若有設(shè)備和網(wǎng)絡(luò)沿用了IPv4的MTU配置參數(shù)值，很可能會(huì)引發(fā)分組丟失和性能下降等問(wèn)題。如何避免和解決MTU問(wèn)題，業(yè)界提出了很多方案，結(jié)合城域網(wǎng)雙棧環(huán)境，具體分析如下。

Wenjie Guo, PhD, Associate Professor from School of Life Science, Nanjing University.

3.1 中間設(shè)備分段方案

以上海電信城域網(wǎng)為例，BRAS負(fù)責(zé)終結(jié)PPPoE撥號(hào)請(qǐng)求，家庭網(wǎng)關(guān)可配置成橋接模式或路由模式。橋接模式下PPPoE由用戶(hù)終端發(fā)起，路由模式下則由家庭網(wǎng)關(guān)發(fā)起?？紤]到PPPoE封裝需額外增加6 byte PPPoE和2 byte PPP頭部開(kāi)銷(xiāo)，上海電信BRAS PPPoE撥號(hào)接口配置的MTU值為1 492 byte（在標(biāo)準(zhǔn)的1 500 byte基礎(chǔ)上減去6 byte PPPoE頭部和2 byte PPP頭部計(jì)算所得），因此BRAS用于PPPoE協(xié)商的MRU值也為1 492 byte。而絕大多數(shù)用戶(hù)終端的IPv4和IPv6協(xié)議棧MTU值默認(rèn)設(shè)為1 500 byte。若家庭網(wǎng)關(guān)采用橋接模式，PPPoE撥號(hào)在用戶(hù)終端和BRAS之間完成，經(jīng)協(xié)商后，用戶(hù)終端和BRAS均會(huì)選用彼此MRU/MTU中較小值1 492 byte來(lái)發(fā)送數(shù)據(jù)分組，IPv4和IPv6數(shù)據(jù)分組都不會(huì)引起中間設(shè)備對(duì)其分段。但如果家庭網(wǎng)關(guān)采用路由模式，PPPoE撥號(hào)在家庭網(wǎng)關(guān)WAN口和BRAS之間完成，經(jīng)協(xié)商后，它們之間也會(huì)選用MRU/MTU中較小的值1 492 byte來(lái)發(fā)送數(shù)據(jù)分組，而此時(shí)的用戶(hù)終端并不知道PPPoE協(xié)議的存在，最大仍會(huì)使用1 500 byte發(fā)送數(shù)據(jù)分組，在純IPv4環(huán)境下，這些大于1 492 byte的數(shù)據(jù)分組從用戶(hù)終端發(fā)送到家庭網(wǎng)關(guān)WAN接口時(shí)，由于IPv4支持中間設(shè)備對(duì)分組進(jìn)行分段，所以沒(méi)有設(shè)置DF位的IPv4數(shù)據(jù)分組會(huì)被家庭網(wǎng)關(guān)分段成兩個(gè)數(shù)據(jù)分組后發(fā)送，數(shù)據(jù)分組的重組則由目的端負(fù)責(zé)，這就是中間設(shè)備分段方案，最終可實(shí)現(xiàn)IPv4分組的成功收發(fā)。

圖2 上海電信公客撥號(hào)用戶(hù)上網(wǎng)路徑示意

然而，此方案存在兩點(diǎn)不足。

·家庭網(wǎng)關(guān)對(duì)大量IPv4數(shù)據(jù)分組的分段操作會(huì)影響性能，而目的端對(duì)分組重組同樣會(huì)消耗自身存儲(chǔ)、計(jì)算資源，進(jìn)而可能造成時(shí)延和分組丟失等問(wèn)題。

·從第2.4節(jié)分析可知，IPv6并不支持中間設(shè)備對(duì)分組進(jìn)行分段操作，因而該方案無(wú)法解決IPv6數(shù)據(jù)分組遇到的MTU問(wèn)題。由此可知，在城域網(wǎng)環(huán)境中并不適合采用本方案。

3.2 path MTU discover（路徑MTU發(fā)現(xiàn)）方案

path MTU discover是指當(dāng)數(shù)據(jù)分組大小超過(guò)某中間設(shè)備出接口設(shè)置的MTU時(shí)，該設(shè)備將丟棄超長(zhǎng)數(shù)據(jù)分組并發(fā)送ICMP packet too big消息給發(fā)起此超長(zhǎng)分組的主機(jī)，ICMP消息中包括了分組丟失設(shè)備的MTU值。源主機(jī)收到此ICMP消息后，將重發(fā)分組的尺寸設(shè)為ICMP消息中要求的MTU值，如此反復(fù)，直到分組的尺寸不大于端到端路徑上所有設(shè)備出接口的MTU值，并順利達(dá)到通信對(duì)端主機(jī)或服務(wù)器為止。path MTU由數(shù)據(jù)分組發(fā)送方向上途徑的各設(shè)備出接口MTU配置決定，所以該機(jī)制是單向的，在來(lái)去兩個(gè)方向上的路徑MTU發(fā)現(xiàn)結(jié)果可能會(huì)不一致（例如來(lái)去方向上途經(jīng)的路徑不對(duì)稱(chēng)或者同一設(shè)備不同接口上的MTU配置值不同）。IPv4和IPv6都支持此方案，但在具體實(shí)現(xiàn)上有差異。對(duì)IPv4數(shù)據(jù)分組而說(shuō)，該機(jī)制只對(duì)設(shè)置了DF位的數(shù)據(jù)分組有效。而IPv6協(xié)議沒(méi)有定義DF字段，但天然地支持了path MTU discover機(jī)制。

本方案有如下限制和安全問(wèn)題。

·路徑MTU發(fā)現(xiàn)機(jī)制依賴(lài)于ICMP packet too big消息的傳遞，若有中間設(shè)備被禁止產(chǎn)生該消息或傳送路徑上有中間設(shè)備拒絕該ICMP消息通過(guò)，會(huì)使源主機(jī)無(wú)法偵測(cè)路徑上的最小MTU值，最終導(dǎo)致發(fā)現(xiàn)機(jī)制失效并產(chǎn)生大量分組丟失。一旦出現(xiàn)此問(wèn)題，因互聯(lián)網(wǎng)的復(fù)雜性，各種因素互相交織，排障將變得非常困難。

·中間設(shè)備產(chǎn)生并回復(fù)ICMP packet too big消息一般需由其CPU處理，若大量用戶(hù)觸發(fā)該類(lèi)消息或存在惡意攻擊行為，設(shè)備性能遭受重大影響。

·若有攻擊者利用大量“肉雞”假冒源主機(jī)地址發(fā)送大分組至網(wǎng)絡(luò)，將有大量ICMP packet too big數(shù)據(jù)分組返回攻垮無(wú)辜的源主機(jī)。雖然很多廠商設(shè)備能對(duì)ICMP分組的產(chǎn)生進(jìn)行限速，但不區(qū)分對(duì)錯(cuò)的限速會(huì)影響到正常使用的MTU發(fā)現(xiàn)機(jī)制，因此多數(shù)主流設(shè)備廠商并不建議在城域網(wǎng)實(shí)際部署中開(kāi)啟該功能。鑒于以上安全問(wèn)題對(duì)于城域網(wǎng)而言可能帶來(lái)毀滅性的后果，因此本方案在城域網(wǎng)中的可實(shí)施性并不強(qiáng)。

3.3 router advertisement messages（路由器通告消息）方案

IPv6在RFC2461中定義了neighbor discovery（鄰居發(fā)現(xiàn)）協(xié)議，該協(xié)議包含5種ICMP分組類(lèi)型，分別是重定向消息、成對(duì)使用的路由器請(qǐng)求和路由器通告消息、成對(duì)使用的鄰居請(qǐng)求和鄰居通告消息。其中，路由器通告消息中含有MTU選項(xiàng)，可以實(shí)現(xiàn)在同一鏈路段上的所有節(jié)點(diǎn)使用相同的MTU值?；谠搮f(xié)議，通過(guò)對(duì)家庭網(wǎng)關(guān)（受電信管控）進(jìn)行開(kāi)發(fā)，可實(shí)現(xiàn)向連接在家庭網(wǎng)關(guān)LAN口上的用戶(hù)終端通告運(yùn)營(yíng)商所希望的MTU值大小，用戶(hù)終端接受網(wǎng)關(guān)通告并修改MTU后，可避免其使用默認(rèn)卻又不合適的MTU配置發(fā)出數(shù)據(jù)分組，進(jìn)而在城域網(wǎng)和互聯(lián)網(wǎng)上遭遇path MTU問(wèn)題。

此方案的限制在于：

·因MTU選項(xiàng)是IPv6 neighbor discover協(xié)議中新定義的，IPv4中無(wú)此選項(xiàng)，因而該方案只適用于IPv6，無(wú)法用于IPv4協(xié)議棧；

·因位于Internet上的應(yīng)用服務(wù)器端網(wǎng)關(guān)一般由用戶(hù)自行部署，其MTU設(shè)置并不受運(yùn)營(yíng)商控制，本方案只能影響公客撥號(hào)用戶(hù)去往服務(wù)器數(shù)據(jù)分組的MTU大小，無(wú)法解決返回?cái)?shù)據(jù)分組的MTU問(wèn)題。

若采用此方案，并結(jié)合用戶(hù)服務(wù)器端發(fā)出的MTU大小符合城域網(wǎng)要求，就有可能解決IPv6的MTU問(wèn)題。因此，建議在有條件的情況下實(shí)施該方案。

3.4 TCP MSS調(diào)整方案

根據(jù)第2.3節(jié)描述，若能確保以MSS大小發(fā)送的TCP類(lèi)型數(shù)據(jù)分組的數(shù)據(jù)域在封裝TCP、IP分組頭后的尺寸小于path MTU，則可避免數(shù)據(jù)分組在傳送過(guò)程中被分段。MSS大小可由建立TCP連接的兩端設(shè)備直接進(jìn)行協(xié)商（例如PC和Web服務(wù)器直接協(xié)商），也可以由中間路由設(shè)備參與協(xié)商，中間設(shè)備參與協(xié)商的一個(gè)復(fù)雜場(chǎng)景流程如圖3所示。由圖可知中間的路由設(shè)備可在兩個(gè)方向上分別控制MSS的大小。因TCP兩端的會(huì)話(huà)協(xié)商過(guò)程不受控，很難依靠用戶(hù)自身協(xié)商來(lái)確保TCP數(shù)據(jù)分組的MSS大小符合path MTU的要求，此時(shí)配置中間設(shè)備參與MSS的協(xié)商成為運(yùn)營(yíng)商的一種可選方案。

基于以上思路，上海電信在使用路由模式的家庭網(wǎng)關(guān)上開(kāi)啟了類(lèi)似ip tcp adjust-mss、ipv6 tcp adjust-mss的命令，可實(shí)現(xiàn)對(duì)TCP應(yīng)用客戶(hù)端和服務(wù)器端的IPv4和IPv6 MSS大小控制?？紤]到上海電信城域網(wǎng)上最小MTU為1 492 byte（PPPoE封裝段），IPv4MSS=pathMTU（1 492 byte）-TCP報(bào)頭（20 byte）-IPv4報(bào)頭（20 byte）=1 452 byte，所以應(yīng)將IPv4 tcp adjust-mss值設(shè)置小于或等于1 452 byte；IPv6 MSS=path MTU（1 492 byte）-TCP報(bào)頭（20 byte）-IPv6報(bào)頭（40 byte）=1 432 byte，應(yīng)當(dāng)將IPv6的tcp adjust-mss值設(shè)置小于或等于1 432 byte。若考慮到用戶(hù)有自建額外隧道的配置需求，需將adjust-mss值設(shè)置得更小，為額外封裝分組頭保留余量。

雖然此方案的不足之處在于只對(duì)IPv4和IPv6的TCP數(shù)據(jù)分組有效，而對(duì)互聯(lián)網(wǎng)應(yīng)用廣泛使用的UDP等其他傳輸層協(xié)議不起作用，但在實(shí)際應(yīng)用中，設(shè)計(jì)基于UDP的應(yīng)用時(shí)，編程者通常會(huì)有意識(shí)地將UDP數(shù)據(jù)分組的大小設(shè)定為較小值，以適應(yīng)復(fù)雜的網(wǎng)絡(luò)環(huán)境，而在真實(shí)環(huán)境中能否成功調(diào)控TCP數(shù)據(jù)分組大小更具有現(xiàn)實(shí)意義，因此，在城域網(wǎng)中應(yīng)優(yōu)先應(yīng)用本方案。

4 結(jié)束語(yǔ)

圖3 中間路由設(shè)備參與MSS協(xié)商流程

IPv6技術(shù)雖已發(fā)展多年，但在大型城域網(wǎng)內(nèi)規(guī)模部署的案例仍然不多。雙棧環(huán)境下遇到的MTU和分段問(wèn)題較為復(fù)雜，需通盤(pán)考慮IPv4和IPv6的協(xié)議特點(diǎn)，運(yùn)營(yíng)商、互聯(lián)網(wǎng)內(nèi)容提供商專(zhuān)業(yè)人員若囿于IPv4配置經(jīng)驗(yàn)，往往會(huì)引起IPv6的MTU問(wèn)題。根據(jù)本文分析，因存在一定技術(shù)和應(yīng)用限制，單純依靠現(xiàn)有的某個(gè)方案并不能徹底解決問(wèn)題。就城域網(wǎng)運(yùn)營(yíng)商而言，現(xiàn)階段可在綜合考慮網(wǎng)絡(luò)設(shè)備功能、性能、安全因素的前提下，結(jié)合多種方案，多管齊下，盡可能避免因MTU問(wèn)題導(dǎo)致分組丟失和網(wǎng)絡(luò)轉(zhuǎn)發(fā)性能下降問(wèn)題。在一個(gè)城域網(wǎng)內(nèi)可考慮適當(dāng)放大相關(guān)設(shè)備的MTU設(shè)置值，優(yōu)先確保本地網(wǎng)絡(luò)不會(huì)成為MTU瓶頸。從長(zhǎng)遠(yuǎn)來(lái)看，標(biāo)準(zhǔn)化組織、研發(fā)機(jī)構(gòu)和相關(guān)廠商應(yīng)考慮對(duì)相關(guān)MTU處理機(jī)制作進(jìn)一步開(kāi)發(fā)完善，理想中的MTU處理機(jī)制應(yīng)該同時(shí)滿(mǎn)足以下要求：

·應(yīng)能同時(shí)解決IPv4、IPv6的MTU問(wèn)題；

·應(yīng)能同時(shí)作用于TCP和UDP等各類(lèi)協(xié)議數(shù)據(jù)分組；

·不應(yīng)采用分段方式增加路由器的處理負(fù)擔(dān)；

·解決MTU問(wèn)題不能引發(fā)新的不可控的安全問(wèn)題。

就第3.2節(jié)的方案來(lái)看，當(dāng)特定ICMP數(shù)據(jù)分組能順利穿越整個(gè)網(wǎng)絡(luò)的情況下，若能徹底解決引發(fā)的各類(lèi)安全問(wèn)題，也許改良后的路徑MTU發(fā)現(xiàn)方案就能成為一種較為理想的方案。另一方面，ICP、操作系統(tǒng)、終端、應(yīng)用軟件廠商應(yīng)充分考量雙棧環(huán)境下MTU問(wèn)題的復(fù)雜性，在彼此負(fù)責(zé)的段落內(nèi)為IPv4和IPv6設(shè)置更為合理的MTU值，既減少問(wèn)題出現(xiàn)的幾率又確保數(shù)據(jù)分組的轉(zhuǎn)發(fā)效率。

1 RFC2460.Internet Protocol,Version 6(IPv6)Specification，19982RFC4459.MTU and Fragmentation Issues with in-the-Network Tunnel，2006

2 RFC4459. MTU and Fragmentation Issues with in-the-NetworkTunnel，2006

3 RFC4638.Accommodating a Maximum Transit Unit/Maximum Receive，2006

4 RFC2461.Neighbor Discovery for IP Version 6(IPv6)，1998