基于Traceroute路徑的IPv6過渡元素識別策略

馬東雯，劉 述，高 強(qiáng)

（1.北京航空航天大學(xué) 電子信息工程學(xué)院，北京100191；2.工業(yè)和信息化部電信傳輸研究所，北京100191）

0 引 言

截至2012年6月底，中國擁有IPv6地址數(shù)量為12499塊／32地址，相比上年底增速達(dá)到33.0%，在全球的排名由2011年6月底的第15位迅速提升至第3位[1]。這預(yù)示著我國已進(jìn)入IPv6網(wǎng)絡(luò)部署的爆發(fā)期，IPv6骨干網(wǎng)的規(guī)模會在今后幾年內(nèi)迅速增長，但我們?nèi)詫㈤L期處于IPv4與IPv6網(wǎng)絡(luò)設(shè)備的共存期。

在IPv6骨干網(wǎng)中，存在相當(dāng)多的IPv4／IPv6過渡元素，如雙棧路由器，隧道端點(diǎn)路由器等。它們是IPv6與IPv4主機(jī)互通的重要轉(zhuǎn)接點(diǎn)，而一些過渡元素需要對每個(gè)數(shù)據(jù)包進(jìn)行判斷、數(shù)據(jù)包封裝等操作，因此過渡元素被普遍認(rèn)為是整個(gè)網(wǎng)絡(luò)性能的瓶頸[2]。本文旨在在IPv6骨干網(wǎng)拓?fù)浒l(fā)現(xiàn)的基礎(chǔ)上，識別出網(wǎng)絡(luò)中的過渡元素。在識別出過渡元素后，對它們的運(yùn)行狀況進(jìn)行監(jiān)測，按照需求進(jìn)行性能的優(yōu)化，是過渡期保持網(wǎng)絡(luò)健康運(yùn)行的可行方法之一。

在國內(nèi)外已有的研究中，對局域網(wǎng)內(nèi)的過渡元素識別已經(jīng)有相當(dāng)多的研究，如基于SNMP（simple network management protocol）協(xié)議的過渡元素發(fā)現(xiàn)[3]。而對骨干網(wǎng)層面的過渡元素發(fā)現(xiàn)則研究很少，已存在的方法也存在著識別設(shè)備類型有限、識別率不高的問題[4]。本文在研究已有科研成果的基礎(chǔ)上，針對由Traceroute骨干網(wǎng)拓?fù)浒l(fā)現(xiàn)得到的接口路徑 （由IPv6路由器的接口IP地址組成），提出了一種基于Traceroute路徑的IPv6骨干網(wǎng)過渡元素識別策略，用以判斷每條Traceroute接口路徑上存在的過渡元素，從而最終得出整個(gè)IPv6骨干網(wǎng)網(wǎng)絡(luò)中的過渡元素。

該識別策略結(jié)合了路徑最大傳輸單元 （path maximum transmission unit，PMTU）試探、雙棧節(jié)點(diǎn)識別、相鄰雙棧提取、ping注入、跳限檢驗(yàn)等方法，合理設(shè)計(jì)了識別流程，刪減了不符合網(wǎng)絡(luò)實(shí)際情況的判斷流程。同時(shí)采取PMTU和雙棧節(jié)點(diǎn)判斷進(jìn)行粗判，提高了識別效率，采取跳限檢驗(yàn)對初判為過渡元素的節(jié)點(diǎn)進(jìn)行檢驗(yàn)，提高判斷的準(zhǔn)確性。對識別策略進(jìn)行實(shí)驗(yàn)測試，結(jié)果表明該識別策略具有識別多種主要過渡元素的能力，且具有冗余識別少，識別速度快，識別率較高的特點(diǎn)。

1 過渡元素分類及識別方法

IPv6骨干網(wǎng)過渡技術(shù)主要分為雙棧技術(shù)、隧道技術(shù)和協(xié)議轉(zhuǎn)換技術(shù)[5]。本小節(jié)將對前兩種技術(shù)對應(yīng)的過渡元素及識別方法進(jìn)行介紹，而協(xié)議轉(zhuǎn)換技術(shù)由于破壞了IP協(xié)議端到端的特性而沒有被大規(guī)模使用，在此不進(jìn)行深入討論

1.1 雙棧技術(shù)及雙棧主機(jī)的識別

雙棧技術(shù)要求網(wǎng)絡(luò)節(jié)點(diǎn)同時(shí)支持IPv4和IPv6協(xié)議棧，使得路由器能同時(shí)與IPv4、IPv6主機(jī)通信。在一個(gè)路由器中，分別維護(hù)IPv6和IPv4兩套路由協(xié)議棧和路由表，不同協(xié)議的數(shù)據(jù)包根據(jù)不同的路由表轉(zhuǎn)發(fā)。由于現(xiàn)在各大硬件商的網(wǎng)絡(luò)設(shè)備在逐步升級至支持雙棧協(xié)議，因此雙棧技術(shù)是過渡時(shí)期最主要的技術(shù)之一，運(yùn)用的非常廣泛[5]。

對于雙棧主機(jī)的識別，現(xiàn)在通用的做法有兩種:地址列表獲取法和DNS報(bào)文分析法。

地址列表獲取法:首先調(diào)用gethostbyaddr（）函數(shù)，以已知的IPv6地址為參數(shù)，能得到該IPv6地址所在主機(jī)的主機(jī)名。根據(jù)RFC2553中的定義，以主機(jī)名為getaddrinfo（）函數(shù)的參數(shù)，可以獲得該主機(jī)硬件設(shè)備上包括IPv6和IPv4地址在內(nèi)的所有IP地址。利用這一特性，若調(diào)用此函數(shù)返回的結(jié)果中包含IPv4地址，說明該路由器同時(shí)擁有IPv4和IPv6地址，則該路由為雙棧路由器[6]。

DNS報(bào)文分析法:文獻(xiàn)[4]中給出了基于DNS請求響應(yīng)報(bào)文的分析來發(fā)現(xiàn)雙棧設(shè)備的方法，其基本原理與上述地址列表獲取法相同。該方法屬于被動監(jiān)聽法，識別的效率較低。

1.2 隧道技術(shù)及隧道端點(diǎn)的識別

隧道技術(shù)是一項(xiàng)應(yīng)用成熟的互聯(lián)網(wǎng)技術(shù)，它通過將有效負(fù)載在隧道入口進(jìn)行協(xié)議封裝，在隧道出口對其解封，使得相互兼容的網(wǎng)絡(luò)節(jié)點(diǎn)能夠跨接在與之不兼容的網(wǎng)絡(luò)上，實(shí)現(xiàn)兼容網(wǎng)絡(luò)節(jié)點(diǎn)間的雙向通信。隧道入口與隧道出口之間的邏輯關(guān)系被定義為隧道[5]。

在實(shí)際運(yùn)行的IPv6網(wǎng)絡(luò)中，主要采用的是IPv6－over－IPv4隧道[7]，對于隧道端點(diǎn)的識別，常用的方法有以下3種。

基于PMTU發(fā)現(xiàn)的隧道識別方法:當(dāng)源主機(jī)向網(wǎng)絡(luò)注入較大的IPv6數(shù)據(jù)包 （數(shù)據(jù)包長度大于1500字節(jié)）時(shí)，由于每兩個(gè)節(jié)點(diǎn)之間的鏈接都存在一個(gè)最大傳輸單元（MTU），因此過大的數(shù)據(jù)包會觸發(fā)中間路由器返回ICMPv6數(shù)據(jù)包過大報(bào)文，報(bào)文中會告知源主機(jī)下一跳的MTU值。源主機(jī)根據(jù)此MTU值調(diào)整數(shù)據(jù)包大小，再次發(fā)送數(shù)據(jù)包。當(dāng)數(shù)據(jù)包最終成功到達(dá)目的端時(shí)，數(shù)據(jù)包的大小即為該路徑上的最大傳輸單元 （PMTU）[8]。通過獲取到的PMTU值，與特征值進(jìn)行比較，即可判斷是否存在隧道。由于PMTU是一條路徑中最小的MTU值，該方法僅可判斷出隧道存在的可能性，無法給出確定的結(jié)論[4]。

基于IP欺騙和ping注入的隧道識別方法:IPv6－over－IPv4配置隧道采用的安全機(jī)制非常薄弱。若已知IPv6－over－IPv4配置隧道兩個(gè)端點(diǎn)的IPv4地址，IPv4網(wǎng)絡(luò)中的任意節(jié)點(diǎn)可以利用IPv4地址欺騙的方式，向隧道端口發(fā)送偽造的IPv6－over－IPv4隧道數(shù)據(jù)包，從而進(jìn)入隧道端口后的IPv6網(wǎng)絡(luò)，這個(gè)過程被稱為IP欺騙。以IP欺騙為基礎(chǔ)，文獻(xiàn)[9]中提到利用構(gòu)造ping數(shù)據(jù)報(bào)文的方法判斷IPv6－over－IPv4配置隧道是否存在。

被動探測法:劫持目標(biāo)網(wǎng)絡(luò)內(nèi)兩個(gè)IPv6／IPv4雙棧節(jié)點(diǎn) （路由器或主機(jī)）之間的通信，通過對截獲的數(shù)據(jù)報(bào)進(jìn)行分析，很容易發(fā)現(xiàn)隱匿在其中的IPv6－over－IPv4隧道。這種方法具有一定的局限性，成功率也相對較低[10]。

2 基于Traceroute路徑的過渡元素識別策略

針對由Traceroute方式進(jìn)行骨干網(wǎng)拓?fù)浒l(fā)現(xiàn)得到的接口路徑 （由IPv6路由器的接口IP地址組成），本文提出了一種過渡元素識別策略，用以判斷每條接口路徑上存在的過渡元素，從而最終得出整個(gè)IPv6骨干網(wǎng)網(wǎng)絡(luò)中的過渡元素。

Traceroute的原理是探測點(diǎn)向目標(biāo)點(diǎn)發(fā)送跳限 （hop limit）逐跳增加的ICMP或UDP報(bào)文，由每一跳路由器返回的ICMP超時(shí)報(bào)文中的信息，獲知從探測點(diǎn)到目標(biāo)點(diǎn)所經(jīng)過的路徑的全部路由器的接口IP地址。在對網(wǎng)絡(luò)邊緣的某一目標(biāo)點(diǎn)進(jìn)行一次Traceroute后，得到了探測點(diǎn)至目標(biāo)點(diǎn)經(jīng)過的IPv6路由器的接口路徑 （可稱為 “一條Traceroute結(jié)果”）。對該路徑上的所有路由器進(jìn)行判斷，發(fā)現(xiàn)哪些節(jié)點(diǎn)屬于過渡元素。將這樣的方法運(yùn)用至每一條Traceroute的結(jié)果，就能在獲得IPv6骨干網(wǎng)拓?fù)涞幕A(chǔ)上，識別出其中的IPv6過渡元素。

根據(jù)我們對中國IPv6骨干網(wǎng)進(jìn)行實(shí)際的Traceroute實(shí)驗(yàn)，對于IPv6骨干網(wǎng)路由器的界定為:從探測點(diǎn)開始經(jīng)過的第三跳路由器起，至目標(biāo)點(diǎn)前倒數(shù)第三跳路由器止 （如圖1）。由于在網(wǎng)絡(luò)中個(gè)別路由器由于網(wǎng)絡(luò)擁塞或出于安全的考慮，不回應(yīng)ICMP請求，會出現(xiàn)Traceroute結(jié)果中對應(yīng)的IP地址為空，也就是網(wǎng)絡(luò)拓?fù)浒l(fā)現(xiàn)領(lǐng)域中常說的 “匿名路由器”問題。因此在一條Traceroute結(jié)果中，可能存在一個(gè)或更多的匿名路由器，我們只知道它的存在，而無法獲知該跳的IPv6地址 （見圖1）。為了降低由匿名路由器造成的誤差，我們進(jìn)行如下處理:若一條Traceroute結(jié)果中存在匿名路由器，將再次對目標(biāo)點(diǎn)進(jìn)行Traceroute。若再次Traceroute的結(jié)果仍然存在匿名路由器，則表明Tracer－oute結(jié)果不可能完整，則選取匿名路由器最少的一條Traceroute結(jié)果，來進(jìn)行我們上述的過渡元素識別過程。

圖1 一條Traceroute結(jié)果的說明

下面將針對一條Traceroute結(jié)果進(jìn)行闡述，如何識別其中的過渡元素。

2.1 PMTU試探

首先，使用路徑MTU發(fā)現(xiàn)來試探隧道存在的可能性。

由于隧道的原理是將IPv6數(shù)據(jù)包封裝在IPv4數(shù)據(jù)包中，使其可以在IPv4網(wǎng)絡(luò)中傳輸。因此，若在一條Traceroute路徑中存在IPv6－over－IPv4隧道，其路徑MTU將在下層IPv4網(wǎng)絡(luò)PMTU基礎(chǔ)上減少封裝報(bào)頭的長度。在現(xiàn)實(shí)網(wǎng)絡(luò)中，純IPv4網(wǎng)絡(luò)的典型MTU值為1500字節(jié)，而IPv6－in－IPv4隧道封裝報(bào)頭長度為20字節(jié)，GRE隧道封裝報(bào)頭長度為24或28字節(jié)。一些基于BSD系統(tǒng)的隧道接口使用1280字節(jié)的系統(tǒng)默認(rèn)MTU。因此我們可以推斷，當(dāng)一條路徑的路徑 MTU值為1480 （1500－20）、1476 （1500－24）、1472（1500－28）、1280之一時(shí)，極有可能存在至少一條隧道。

通過路徑MTU的發(fā)現(xiàn)，可以初步判斷該路徑上是否存在隧道這種過渡元素。

2.2 判斷雙棧節(jié)點(diǎn)

對于一條Traceroute結(jié)果中，每一個(gè)擁有全局單播IPv6地址的接口，使用雙棧主機(jī)識別中的地址列表獲取法，向每一個(gè)接口發(fā)送getaddrinfo（）請求，獲取其所在設(shè)備上全部socket信息。在返回的socket信息中，若包含IPv4地址，則判斷其為雙棧路由器，說明它是一個(gè)過渡元素。由于隧道端點(diǎn)的必要條件是支持雙棧，因此要等待進(jìn)行下一步判斷，判斷其是否為單純的雙棧路由器還是隧道端點(diǎn)。

若在本步驟中未發(fā)現(xiàn)雙棧路由器，而又通過2.1所述的PMTU試探出這條Traceroute路徑中可能存在隧道，則說明存在一種可能，剛好匿名路由器是過渡元素。因此我們只能判斷這條路徑上有很大可能存在某種類型的隧道，而無法確切獲知哪幾跳路由器為隧道端點(diǎn)，對于該條Traceroute的結(jié)果判斷到此結(jié)束。

若在本步驟中未發(fā)現(xiàn)雙棧路由器，在2.1步驟中也未發(fā)現(xiàn)隧道的典型PMTU值，則認(rèn)為該條Traceroute路徑中不存在任何過渡元素，該條Traceroute路徑中的每一個(gè)路由器節(jié)點(diǎn)均為純IPv6節(jié)點(diǎn)，對于該條Traceroute的結(jié)果判斷到此結(jié)束。

2.3 提取相鄰兩跳雙棧節(jié)點(diǎn)

若該條Traceroute結(jié)果在經(jīng)過2.1、2.2兩步判斷后，仍未滿足判斷結(jié)束條件，則說明該路徑上必然有過渡元素存在。由于隧道的端點(diǎn)必為雙棧路由器，且隧道端點(diǎn)在Traceroute結(jié)果中均表現(xiàn)為相鄰的兩跳路由器，其底層復(fù)雜的隧道結(jié)構(gòu)不反映在Traceroute結(jié)果中。因此要提取出該條Traceroute結(jié)果中相鄰的兩跳雙棧路由器，它們之間有可能存在隧道，待下一步進(jìn)行判斷。為下文敘述方便，記此步驟提取出相鄰的雙棧路由器分別為A和B，它們的IPv4和IPv6地址已在2.2步驟中獲知。

若該條Traceroute結(jié)果中未能找到相鄰的兩跳雙棧路由器，則認(rèn)為這條路徑中存在的雙棧路由器均為單純的雙棧路由器，路徑中不存在隧道。雖然匿名路由器的存在可能使其相鄰的雙棧路由器被誤判為純雙棧路由器，但由于無法得知匿名路由器的IPv6地址，也就無法驗(yàn)證其是否為隧道端點(diǎn)，對于該條Traceroute的結(jié)果判斷到此結(jié)束。這是可能產(chǎn)生判斷誤差的一個(gè)原因。

2.4 ping注入初判

文獻(xiàn)[9]提到，IPv6－over－IPv4配置隧道采用的安全機(jī)制非常薄弱。當(dāng)隧道端點(diǎn)接收到IPv4數(shù)據(jù)包時(shí)，會驗(yàn)證該數(shù)據(jù)包的源地址。若源地址為該隧道起點(diǎn)的IPv4地址，則認(rèn)為這個(gè)數(shù)據(jù)包是經(jīng)由隧道起點(diǎn)傳輸過來的，將IPv4封裝頭解封后，繼續(xù)在IPv6網(wǎng)絡(luò)中傳輸至目標(biāo)點(diǎn)。若已知IPv6－over－IPv4配置隧道兩個(gè)端點(diǎn)的IPv4地址，IPv4網(wǎng)絡(luò)中的任意節(jié)點(diǎn)可構(gòu)造一以隧道起點(diǎn)IPv4地址為源地址、隧道端點(diǎn)IPv4地址為目的地址、封裝了IPv6數(shù)據(jù)包的IPv4數(shù)據(jù)包。這樣，就得以利用IPv4地址欺騙的方式向隧道端口發(fā)送偽造的IPv6－over－IPv4隧道數(shù)據(jù)包，從而進(jìn)入隧道端口后的IPv6網(wǎng)絡(luò)，這個(gè)過程被稱為IP欺騙。

若AB之間為隧道連接，則到達(dá)B點(diǎn)的IPv4數(shù)據(jù)包首先會經(jīng)過源地址的檢驗(yàn)，若源地址為A的IPv4地址，則認(rèn)為是由隧道起點(diǎn)A封裝并發(fā)送過來的數(shù)據(jù)包，解封后繼續(xù)傳輸。因此我們設(shè)想，通過任意節(jié)點(diǎn) （為了方便，我們選定為探測點(diǎn)S）構(gòu)造一IPv4封裝的IPv6數(shù)據(jù)包，其中IPv4封裝部分的源地址應(yīng)偽裝為A的IPv4地址，目的地址為B的IPv4地址。若該數(shù)據(jù)包到達(dá)B點(diǎn)后成功解封繼續(xù)向后傳輸，則說明AB間確實(shí)存在隧道。為得知數(shù)據(jù)包到達(dá)B點(diǎn)后是否成功解封向后傳輸，被封裝的IPv6數(shù)據(jù)包應(yīng)向AB所在路徑上B之后某一已知IPv6地址的主機(jī)T發(fā)送ICMP Echo－request請求。若AB間確為隧道，則探測點(diǎn)S會收到主機(jī)T發(fā)回的ICMP Echo－reply數(shù)據(jù)包。該過程稱作ping注入，如圖2所示。

圖2 ping注入的說明

若AB間非隧道連接，當(dāng)B點(diǎn)收到如上所述的IPv4數(shù)據(jù)包后，會直接丟棄，目標(biāo)點(diǎn)T無法收到ICMP Echo－request請求，則探測點(diǎn)S收不到任何回應(yīng)報(bào)文。

2.5 跳限法確認(rèn)AB間為隧道

本步驟仍以IP欺騙為基礎(chǔ)，通過跳限法驗(yàn)證隧道端點(diǎn)B的IPv6地址來進(jìn)一步確認(rèn)AB間是否存在隧道。

由于IPv6－over－IPv4隧道在網(wǎng)絡(luò)的IPv6層中被視為一跳，我們發(fā)送一被封裝的跳數(shù)限制 （hop limit）為1的IPv6數(shù)據(jù)包，該數(shù)據(jù)包一旦到達(dá)隧道端點(diǎn)被解封為純IPv6數(shù)據(jù)包，即觸發(fā)一ICMP超時(shí)報(bào)文。若探測點(diǎn)收到一個(gè)源地址為B的IPv6地址的ICMP超時(shí)報(bào)文，則確認(rèn)AB之間確實(shí)存在隧道。這種驗(yàn)證的方法我們稱其為跳限法。

具體方法如下:從探測點(diǎn)S發(fā)送一IPv4封裝IPv6數(shù)據(jù)包，IPv4封裝報(bào)頭的源地址偽裝為A的IPv4地址，目的地址為B的IPv4地址，被封裝的IPv6數(shù)據(jù)包為目標(biāo)點(diǎn)S到探測點(diǎn)T的HL（hop limit）＝1的任意數(shù)據(jù)包。若AB間存在隧道，則該數(shù)據(jù)包到達(dá)B點(diǎn)時(shí)成功解封，進(jìn)入IPv6網(wǎng)絡(luò)傳輸。但由于該IPv6數(shù)據(jù)包跳數(shù)限制為1，B點(diǎn)的IPv6協(xié)議棧在轉(zhuǎn)發(fā)前將HL值減為0，觸發(fā)B點(diǎn)發(fā)送ICMP超時(shí)報(bào)文。該過程如圖3所示。

圖3 跳限法的說明

若AB間確實(shí)為隧道連接，探測點(diǎn)S將收到一ICMP超時(shí)報(bào)文，該報(bào)文的源地址為隧道端點(diǎn)B的IPv6地址，該地址是Traceroute結(jié)果中已知的。至此，可以確認(rèn)AB間存在隧道，對AB這一對雙棧路由器的判斷結(jié)束。若在該條Traceroute結(jié)果中存在其它相鄰的雙棧路由器，則對它們應(yīng)用2.4、2.5所述的方法，判斷其是否為隧道端點(diǎn)。

2.6 隧道類型判斷

根據(jù)文獻(xiàn)[7]，我們可以根據(jù)該條路徑的PMTU粗略判斷路徑中可能存在哪種類型的隧道 （見表1）。但由于路徑MTU的值取決于路徑中所有路由器最小的MTU值，因此當(dāng)存在一個(gè)以上的隧道時(shí)，只能判斷其中MTU最小的隧道的類型，而MTU較大的隧道類型無法獲知。

表1 隧道典型PMTU值

圖4 基于Traceroute路徑的IPv6過渡元素識別總流程

2.7 判斷過程總流程圖

基于Traceroute路徑的IPv6過濾元素識別總流量，如圖4所示。

3 實(shí)驗(yàn)結(jié)果

本文以Cernet2主干網(wǎng)作為IPv6骨干網(wǎng)實(shí)驗(yàn)環(huán)境，按照上述過渡元素識別算法使用JAVA語言編寫過渡元素識別程序，使用雙棧主機(jī)接入IPv4和IPv6網(wǎng)絡(luò)進(jìn)行測試。

事先采集了287個(gè)屬于中國IPv6地址范圍內(nèi)的、處于網(wǎng)絡(luò)邊緣的IPv6目標(biāo)點(diǎn)。實(shí)驗(yàn)進(jìn)行了3次獨(dú)立的Traceroute路徑發(fā)現(xiàn)，并對其運(yùn)用了本文提出的過渡元素識別策略，實(shí)驗(yàn)結(jié)果見表2。

表2 實(shí)驗(yàn)結(jié)果

隧道識別的結(jié)果表明，該算法可以成功識別出IPv6骨干網(wǎng)中的純雙棧節(jié)點(diǎn)和隧道端點(diǎn)，并粗判出其隧道類型，證明該過渡元素識別算法的有效性。判斷一個(gè)路由器是否屬于過渡元素平均用時(shí)2.11秒，識別速度快。

4 結(jié)束語

本文提出的基于Traceroute路徑的IPv6骨干網(wǎng)過渡元素識別策略屬于主動探測法。結(jié)合了路徑MTU值和相鄰雙棧路由器的粗判，使其與已有方法相比，具有識別速度快、減少冗余識別的優(yōu)勢。采用了精準(zhǔn)的ping注入方式進(jìn)行初判，以及跳限法進(jìn)行驗(yàn)證，使其識別率較高。但由于依賴PMTU判斷隧道類型只能判斷一條路徑上MTU最小的隧道的類型，因此在隧道分類上還有待進(jìn)行進(jìn)一步研究。

[1]China Internet Network Information Center.CNNIC 30th internet report[EB／OL].[2012－07－19].http:／／www.cnnic.cn／research／bgxz／tjbg／201207／t20120719＿32247.html（in Chinese）.[中國互聯(lián)網(wǎng)絡(luò)信息中心.CNNIC第30次互聯(lián)網(wǎng)報(bào)告[EB／OL].[2012－07－19].http:／／www.cnnic.cn／research／bgxz／tjbg／201207／t20120719＿32247.html.]

[2]Zhou Xiaoming，Martin Jacobsson，Henk Uijterwaal，et al.IPv6delay and loss performance evolution[J].International Journal of Communication Systems，2008，21 （6）:643－663.

[3]CUI Ze.Research on topology and fault management based on IPV6network[D].Shanghai:East China Normal University，2010（in Chinese）.[崔澤.基于IPv6網(wǎng)絡(luò)的拓?fù)渑c故障管理研究[D].上海:華東師范大學(xué)，2010.]

[4]XU Liang.Study and realization on topology discovery of IPv6 network[D].Chongqing:Chongqing University，2008 （in Chinese）.[許靚.IPv6網(wǎng)絡(luò)拓?fù)浒l(fā)現(xiàn)的研究與實(shí)現(xiàn)[D].重慶:重慶大學(xué)碩士學(xué)位論文，2008.]

[5]WU Xiaojin.Technology and application of IPv6[M].Beijing:Tsinghua University Press，2010 （in Chinese）.[伍孝金.IPv6技術(shù)與應(yīng)用[M].北京:清華大學(xué)出版社，2010.]

[6]ZHU Mingming.Research on router－lever topology discovery technology based on IPv6[D].Henan:The PLA Information Engineering University，2009 （in Chinese）.[朱 明 明.基 于IPv6的路由器級拓?fù)浒l(fā)現(xiàn)技術(shù)研究[D].河南:解放軍信息工程大學(xué)，2009.]

[7]IETF RFC4459，MTU and Fragmentation Issues with In－the－Network Tunneling[S／OL].http:／／tools.ietf.org／html／rfc4459，2013.

[8]IETF RFC1981，Path MTU discovery for IP version 6[S／OL].http:／／www.ietf.org／rfc／rfc1981.txt，2013.

[9]Guanlan Chen，Qin Zhao，Yan Ma，et al.A new topology discovery solution for IPv4 ＆IPv6coexisting networks[C]／／Beijing:International Conference on Advanced Intelligence and Awarenss Internet，2010:208－212.

[10]REN Jie.The research and realization on IPv6－over－IPv4tunnel discovery and using technology[D].Zhengzhou:The PLA Information Engineering University，2007 （in Chinese）.[任杰.IPv6－over－IPv4隧道發(fā)現(xiàn)及利用技術(shù)研究與實(shí)現(xiàn)[D].鄭州:解放軍信息工程大學(xué)，2007.]