馬東雯，劉 述，高 強

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

0 引 言

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

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

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

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

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

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

1.1 雙棧技術及雙棧主機的識別

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

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

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

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

1.2 隧道技術及隧道端點的識別

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

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

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

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

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

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

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

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

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

圖1 一條Traceroute結果的說明

下面將針對一條Traceroute結果進行闡述，如何識別其中的過渡元素。

2.1 PMTU試探

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

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

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

2.2 判斷雙棧節(jié)點

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

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

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

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

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

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

2.4 ping注入初判

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

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

圖2 ping注入的說明

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

2.5 跳限法確認AB間為隧道

本步驟仍以IP欺騙為基礎，通過跳限法驗證隧道端點B的IPv6地址來進一步確認AB間是否存在隧道。

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

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

圖3 跳限法的說明

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

2.6 隧道類型判斷

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

表1 隧道典型PMTU值

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

2.7 判斷過程總流程圖

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

3 實驗結果

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

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

表2 實驗結果

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

4 結束語

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

[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)絡信息中心.CNNIC第30次互聯(lián)網(wǎng)報告[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)絡的拓撲與故障管理研究[D].上海:華東師范大學，2010.]

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

[5]WU Xiaojin.Technology and application of IPv6[M].Beijing:Tsinghua University Press，2010 （in Chinese）.[伍孝金.IPv6技術與應用[M].北京:清華大學出版社，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ā)現(xiàn)技術研究[D].河南:解放軍信息工程大學，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)及利用技術研究與實現(xiàn)[D].鄭州:解放軍信息工程大學，2007.]