摘要：傳統(tǒng)的隧道技術(shù)不能滿足隱藏在網(wǎng)絡地址轉(zhuǎn)換（NAT）域內(nèi)的IPv6節(jié)點的通信要求。針對此問題，提出了一種新的面向NAT用戶的IPv6過渡技術(shù)Silkroad，它可以使位于一個或多個IPv4 NAT內(nèi)的節(jié)點獲得IPv6的連通性。Silkroad支持所有類型的NAT用戶和IPv6網(wǎng)絡進行互聯(lián)，且不需要升級現(xiàn)有的NAT設備；此外，Silkroad不需要任何特殊的IPv6地址前綴，能夠為NAT用戶分配固定的IPv6地址，并具有更高的安全性。

關(guān)鍵詞： IPv6協(xié)議；過渡技術(shù)；網(wǎng)絡地址轉(zhuǎn)換技術(shù)；隧道技術(shù)

Abstract： Traditional tunneling methods are not suitable for IPv6 nodes， which are hidden in the network address translator （NAT）. In this paper， we propose a new IPv6 transition mechanism， called Silkroad， for new NAT users. Silkroad allows nodes in one or several IPv4 NATs to use IPv6 connectivity. It also allows all types of NAT users to connect with IPv6 networks without updating NAT devices. In addition， Silkroad does not need a special IPv6 addressing prefix and can assign stable IPv6 addresses to users. It is also highly secure.

Key words： IPv6 protocol； transition technology； NAT technology； tunnel technology

由于整個網(wǎng)絡從IPv4升級到IPv6需要一個漫長的過程，所以IPv6網(wǎng)絡在其發(fā)展的初始階段使用的主要是現(xiàn)有IPv4網(wǎng)絡的傳輸設施。鑒于此，IPv6過渡的關(guān)鍵點在于如何兼容現(xiàn)有IPv4網(wǎng)絡下眾多的主機和路由器設備。在兼容IPv4網(wǎng)絡的同時部署IPv6網(wǎng)絡，將會使整個網(wǎng)絡的過渡平滑而自然。在這種愿景的驅(qū)動下，出現(xiàn)了很多IPv4承載IPv6（IPv6 over IPv4）的隧道技術(shù)，它們都是將IPv6數(shù)據(jù)置于IPv4包的載荷部分進行數(shù)據(jù)的收發(fā)，負載的類型為41。然而，這些方法都不適用于位于網(wǎng)絡地址轉(zhuǎn)換（NAT）域內(nèi)的IPv6設備，其主要原因是NAT一般都會對入口的包進行過濾，拒絕包括負載類型41在內(nèi)的很多種數(shù)據(jù)包。即便允許它們通過，由于NAT內(nèi)所使用的都是私有IPv4地址，也無法使用IPv6到IPv4（6to4）及很多其他的隧道機制。

NAT是解決IPv4地址不足的一種臨時性技術(shù)[1]。由于IP地址資源短缺現(xiàn)象很嚴重，所以NAT技術(shù)使用得非常普遍。在NAT內(nèi)，用戶使用私有地址進行通信，在NAT外，則被轉(zhuǎn)換為一個或若干個公有地址。由于私有地址并不是全局唯一的，所以外部互聯(lián)網(wǎng)的節(jié)點不能夠主動訪問NAT內(nèi)的節(jié)點，這嚴重破壞了端到端的連通性，因此它們更迫切需要過渡到IPv6。目前有4種NAT類型[2]，分別是完全錐型NAT、受限錐型NAT、端口受限型NAT和對稱型NAT。一般NAT不允許任意負載類型的數(shù)據(jù)包通過，這致使很多IPv6的隧道技術(shù)無法直接應用于NAT內(nèi)的IPv6設備。因此，提供面向NAT用戶的IPv6過渡技術(shù)已經(jīng)成為了一個非常急迫的任務。

一種解決上述問題的方案是由微軟提出的Teredo隧道技術(shù)[3]，也是目前除了本文所提的Silkroad隧道技術(shù)之外的唯一解決方案。它采用IPv6在UDP中（IPv6-in-UDP）的封裝方式，將IPv6的數(shù)據(jù)包置于私有IPv4數(shù)據(jù)包的數(shù)據(jù)報協(xié)議（UDP）載荷中，而不需要升級現(xiàn)有的NAT設備。然而，Teredo隧道技術(shù)卻存在著很多不足。首先，Teredo隧道技術(shù)不能為用戶分配固定不變的IPv6地址，其地址內(nèi)嵌了相關(guān)的隧道參數(shù)，即用戶的私有地址和UDP源端口經(jīng)過NAT轉(zhuǎn)換后的外部地址和外部端口。由于外部地址和外部端口在每次初始化時的隨機性，用戶在使用Teredo隧道技術(shù)進行通信時往往會被NAT轉(zhuǎn)換成不同的外部地址或外部端口，從而獲得和上次不同的IPv6地址。這種IPv6地址經(jīng)常變化的情況破壞了NAT用戶端到端的連通性，喪失了IPv6本來的優(yōu)勢。其次，Teredo隧道技術(shù)不支持對稱型NAT用戶。由于對稱型NAT根據(jù)數(shù)據(jù)包目的地址來轉(zhuǎn)換它的私有地址和UDP源端口，如果目的地址不同，那么轉(zhuǎn)換后的外部地址和外部端口也就不同。Teredo協(xié)議本身采用的是客戶端-客戶端隧道模式，通信對端就是隧道端點，這樣隨著通信目的地的變化隧道參數(shù)也在不斷變化，這違背了Teredo中IPv6地址配置后隧道參數(shù)不變的假定。最后，Teredo的機制本身存在著嚴重的安全漏洞，不能有效地阻止非法用戶利用Teredo中繼器和IPv6網(wǎng)絡互聯(lián)。由于Teredo中繼器的無狀態(tài)特性，任何沒有經(jīng)過身份驗證的非法用戶只需要構(gòu)造出符合Teredo格式的源IPv6地址就可以輕松享用中繼器提供的數(shù)據(jù)轉(zhuǎn)發(fā)服務。非法用戶通過這種方式獲得IPv6連接后，便可以對IPv6網(wǎng)絡上的節(jié)點實施攻擊。

1 Silkroad協(xié)議設計

同Teredo相比，本文提出的Silkroad協(xié)議可以為NAT用戶提供不變的IPv6地址，并可適用于對稱型NAT中，使系統(tǒng)在安全方面得到了很好的保障。

1.1 Silkroad體系結(jié)構(gòu)

Silkroad典型的體系結(jié)構(gòu)如圖1所示，其實現(xiàn)機制主要包括3個實體部分：Silkroad客戶端（SC），Silkroad接入路由器（SAR），Silkroad導航器（SN）。其中SC為位于NAT之后想要使用IPv6網(wǎng)絡的終端用戶，它是一個雙棧節(jié)點，向應用程序提供透明的IPv6連接。SAR為SC提供身份認證及中繼數(shù)據(jù)的服務，它同時與IPv4與IPv6網(wǎng)絡相連，也是一個雙棧節(jié)點。SN位于IPv4網(wǎng)絡中，擁有SC的注冊信息和SAR的部署情況，它的主要功能是為SC選擇一個就近的SAR進行接入，并對各個SAR的運行狀況進行監(jiān)視。

1.2 Silkroad操作規(guī)程

1.2.1 SAR的確定

在Silkroad協(xié)議操作的開始階段，SC選擇適當?shù)腟AR來為自己提供Silkroad隧道服務。換句話說，SC必須知道它的SAR的IPv4地址。SC獲取SAR網(wǎng)絡信息的方式有多種，例如SC可以從系統(tǒng)管理員處獲得SAR的信息，也可以用域名服務器（DNS）去查找SAR，還可以用預先配置或設定的IPv4任播地址查找SAR。當然，因特網(wǎng)業(yè)務提供商（ISP）也可通過其他方式把SAR的地址或域名通告給SC。無論如何，SAR的信息一旦確定，將自動保存到SC的配置文件中。如果SC沒有明確地改變它的配置，此SAR將成為SC的默認SAR。

1.2.2 IPv6地址的獲取

為了獲得IPv6地址，SC通過UDP隧道向SAR發(fā)送一個常規(guī)的路由請求，而SAR則通過UDP隧道向SC回復一個常規(guī)的路由通告，其中包含所請求的IPv6地址。SAR返回的響應報文還包含一個控制選項，可用于存放SAR收到路由請求時所看到的SC地址信息（經(jīng)NAT映射后的IPv4地址和端口）。事實上，當一個地址請求報文到達SAR時，可能經(jīng)過了多級NAT設備，此時SAR看到的地址請求報文的源地址和端口應該是最靠近SAR的那個NAT所映射的地址和端口。SAR將會把該地址和端口寫入響應報文的控制選項字段，和IPv6的地址響應信息一起返回給SC。

由SAR分配給SC的IPv6地址永久分配給SC，這樣即使SC的IPv4地址是動態(tài)分配的，也可保持一個固定的IPv6地址。而SC也可以要求分配臨時的IPv6地址，這樣的地址會有一個生存期，超過生存期后地址將被收回，除非SC提交延長地址生存期的請求。一旦一個SAR給SC分配了IPv6地址，這個SAR就會在自己的映射表里面維護一個地址映射，將SC的IPv6地址同SC的IPv4映射地址及映射端口綁定在一起，該綁定可以隨著SC的IPv4地址的改變而相應動態(tài)更新。

1.2.3 NAT類型的確定

當SC收到地址響應后，將把控制選項字段中的IP地址和端口與自己發(fā)送路由請求時綁定的本地IP地址和端口進行比較。如果不匹配，則SC位于NAT域內(nèi)；否則SC不需要使用Silkroad服務。為了獲得更高的傳輸效率，SC可以選擇在SAR的幫助下確定它所使用的NAT類型。為此，SC發(fā)送“測試請求”，而SAR返回“測試應答”，基本過程可參照文獻[2]中的描述。一旦確定，NAT類型將被SC保存。

1.2.4 從SC到普通IPv6節(jié)點的報文

傳輸

圖2顯示了一個SC和一個普通的IPv6節(jié)點之間的報文傳輸，其中A是NAT域中的SC，R1是A所選擇的SAR，B是一個普通IPv6節(jié)點，R2是靠近B的SAR。A若要向B發(fā)送IPv6包，A首先要把這個IPv6包封裝在IPv4的UDP數(shù)據(jù)包中，并把它發(fā)送給R1。此報文稱作Silkroad包，這種包的格式如圖3所示。

NAT會接收此數(shù)據(jù)包，用映射地址和映射端口替換UDP的源地址和源端口，然后把包轉(zhuǎn)發(fā)出去。此包通過IPv4的UDP隧道1后被R1接收，R1查看IPv6目的地址并在當前的通信對等節(jié)點列表中檢查這個IPv6地址對應的表項是否存在以及該表項是否有效。如果這個IPv6地址對應的表項不存在或無效，R1將登錄它的SN去查找是否B是由另一SAR提供服務的SC。此查找過程與DNS的處理過程類似。SN將在自己的管理域中查找SAR的信息，如果沒找到對應表項，它將查詢上層SN。SN中的默認路由是直接接入IPv6網(wǎng)絡的SAR，這就意味著當R1找不到可以轉(zhuǎn)發(fā)數(shù)據(jù)包到目的IPv6地址的SAR時，會直接將該數(shù)據(jù)包轉(zhuǎn)發(fā)到IPv6網(wǎng)絡上，之后數(shù)據(jù)包便開始遵循IPv6的路由規(guī)則進行常規(guī)的數(shù)據(jù)轉(zhuǎn)發(fā)。

圖2中，確定了R2的地址后，R1就會將IPv6包和控制選項字段一起通過隧道發(fā)送給R2。R1和R2之間的傳輸可以遵循不同的方式，它們可以用另一條UDP隧道傳輸IPv6包，如圖2中的UDP隧道2。這種方法的優(yōu)點是轉(zhuǎn)發(fā)之前R1的處理比較簡單，只需要替換掉UDP的源地址和源端口以及目的地址和目的端口即可。然而，UDP封裝將帶來一定的開銷。Silkroad還可以像傳統(tǒng)的隧道機制那樣，使用IPv6在IPv4中（IPv6-in-IPv4）的封裝方式，把IPv6包作為IPv4包的載荷在SAR之間發(fā)送。但是這種方法不支持控制選項字段，而且R1在轉(zhuǎn)發(fā)之前必須拆包并重新封裝。ISP可以指定SAR之間的傳輸方式，默認的處理是當包中有控制選項字段時，SAR通過UDP隧道轉(zhuǎn)發(fā)包；否則，使用傳統(tǒng)隧道轉(zhuǎn)發(fā)包。事實上，控制選項字段一般只出現(xiàn)于一次會話的前幾個報文中。在Silkroad隧道機制中，SAR需要監(jiān)聽UDP和IP兩種封裝，但是無論在SAR之間采用哪種傳輸方法，SC只需要支持UDP封裝。為簡單起見，在下面的描述中，我們假設SAR之間都使用UDP隧道轉(zhuǎn)發(fā)報文。當R2接收到數(shù)據(jù)包后，如果發(fā)現(xiàn)B是它所負責的SC，那么R2就會把該數(shù)據(jù)包通過隧道轉(zhuǎn)發(fā)給B，否則，R2將會從UDP載荷中解封裝出IPv6數(shù)據(jù)包再發(fā)往IPv6網(wǎng)絡上給B。注意R1和R2可能是同一個SAR，此時，UDP隧道2將不存在。

1.2.5 從普通IPv6節(jié)點到SC的報文

傳輸

圖2中，B是一個普通的IPv6節(jié)點，A是一個SC，R1是A所對應的SAR。當B想要向A發(fā)送IPv6包時，B只需要遵循IPv6規(guī)則，由于A的地址空間屬于R1的管轄區(qū)域，此數(shù)據(jù)包可以正常轉(zhuǎn)發(fā)到R1上。當R1接收到該數(shù)據(jù)包后，發(fā)現(xiàn)A是它所負責的SC，然后就通過UDP隧道1轉(zhuǎn)發(fā)該數(shù)據(jù)包給A。

2 路由優(yōu)化

為了達到更高的傳輸效率，Silkroad機制在某些情況下可以進行路由優(yōu)化。

2.1 兩個SC間的路由優(yōu)化

兩個SC間的路由優(yōu)化如圖4所示。假設A和B是兩個SC，分別位于NAT為N1、N2的后面。R1、R2分別是A和B所選擇的SAR，它們也可能是同一個SAR。事實上，A和B都能識別Silkroad報文。因此，A和B可以直接互通，條件是N1和N2不能同為對稱型NAT。當然，在直接通信前，A和B需要借助R1、R2交換必要的參數(shù)信息。

在A與B通信時，如果A想進行路由優(yōu)化，A首先應在R1的協(xié)助下確定N1的NAT類型。然后，A將自己的映射地址和映射端口以及NAT類型封裝到Silkroad報文的控制選項字段內(nèi)發(fā)給B。如果N1和N2都是完全錐型NAT，則B在響應報文的控制選項字段內(nèi)嵌入自己的映射地址和映射端口，通過UDP封裝直接返回給A，而后A、B即可通過UDP隧道直接通信。如果N1和N2都是對稱NAT，則A、B無法在無SAR協(xié)助的情況下進行直接通信。在其他的情況下（受限錐型NAT/端口受限錐型NAT/對稱型NAT），則A、B需要發(fā)送更多的測試報文，在非完全錐型NAT設備上建立對應的映射關(guān)系，而后才能直接通信。在這種情況下，建議用戶只在需要傳輸大量數(shù)據(jù)時進行路由優(yōu)化，如果交互信息量比較少，則不需要發(fā)送更多的測試報文來進行路由優(yōu)化。

2.2 同一鏈路上兩個SC間的路由優(yōu)化

同一鏈路上兩個SC間的路由優(yōu)化如圖5所示。假設A和B為同一鏈路上的兩個SC，均通過名為N1的NAT接入Internet，默認SAR為R1。這里我們不考慮N1的類型，只介紹A、B間如何進行路由優(yōu)化，以避免所有的報文都經(jīng)過R1、N1轉(zhuǎn)發(fā)。

我們假設A和B已經(jīng)分別從R1獲得了它們的IPv6地址。當然，如果A和B都用相同的IPv4映射地址，那么它們可能位于同一個NAT域中。然而，即使IPv4映射地址不同，它們也可能位于同一個NAT域中。另一方面，即使位于同一個NAT域內(nèi)，相互之間也不一定能直接通信。所以，必須采取一些措施來確定它們之間是否是直接可達的。有許多方法可以達到這一目的，這里只是給出一種可行方案。如果A想要判斷它和B是否在同一鏈路上，A可以把自己的私有地址放在數(shù)據(jù)包的控制選項字段中，通過N1和R1發(fā)送給B。當B接收到此包時，同時向R1以及A的私有地址返回報文，內(nèi)含自己的私有地址。如果A能夠收到這兩個報文，則A可以確認它和B在同一鏈路上，可以直接互通。后繼報文將利用A、B的私有地址封裝，只在本地鏈路上傳播，而不必再經(jīng)過R1和N1轉(zhuǎn)發(fā)。

3 安全考慮

通常，Silkroad服務被局限在一個ISP的范圍里，ISP應該在它的邊界上實行IPv4入口過濾，阻止SAR的地址在ISP外部被用作源地址。ISP也應該對它的用戶實行IPv4入口過濾，尤其是SC，使得它們不能偽造包的IPv4源地址。

在SN和SAR的交互中，可采用安全的簡單網(wǎng)絡管理協(xié)議（SNMP）。此外，若想更簡單地在遠程終端上執(zhí)行Shell命令（RSH），則可以采用標準的IP安全協(xié)議（IPsec）。需要指出的是SC和SAR間通信過程的安全問題。由于兩者間的隧道不是面向連接的，因此如果SC單方面強行釋放了隧道，SAR會繼續(xù)轉(zhuǎn)發(fā)隧道數(shù)據(jù)，導致數(shù)據(jù)包被錯誤地發(fā)到原來的IPv4地址。Silkroad機制采用了保持活動（keep-alive）機制來解決這個問題。當檢測到隧道失效后，SAR立即停止向離線用戶轉(zhuǎn)發(fā)數(shù)據(jù)包。另一方面，SC必須確保它使用的Silkroad隧道是有效的，這可以通過檢查是否定期收到來自SAR的數(shù)據(jù)包來進行驗證。

NAT使SC失去了端到端的連接，但卻可以獲得更高的安全性，因為NAT可以被看作是一種防火墻。然而，在Silkroad的幫助下，SC在IPv6網(wǎng)絡中變成可達的節(jié)點，這就使其成為攻擊者的潛在目標。為了確保通信的安全性，SC可使用IP安全服務，如使用全局IPv6連接的認證頭（AH）或封裝安全載荷（ESP）。SC和SAR之間認證過程的實現(xiàn)將有效地阻止中間人攻擊，如果認證過程經(jīng)過對稱或非對稱加密系統(tǒng)加密，中間人攻擊就很難實現(xiàn)。

4 Silkroad原型系統(tǒng)

Silkroad機制已經(jīng)在重慶的IPv6城域網(wǎng)示范項目中得到了實現(xiàn)驗證，并已應用于中國聯(lián)通的中國下一代互聯(lián)網(wǎng)（CNGI）試驗網(wǎng)。我們基于Silkroad實現(xiàn)了手機與手機或手機與個人數(shù)字助理（PDA）及PC用戶間的IPv6通信。圖6展示了Silkroad的原型系統(tǒng)，演示的內(nèi)容是手機用戶通過Silkroad接入IPv6網(wǎng)絡，然后和IPv6網(wǎng)絡中的PDA及PC用戶進行基于IPv6協(xié)議的網(wǎng)絡五子棋游戲。

當兩個基于IP的手機進行端到端通信時，至少有一方需要具有公有IP地址，但目前移動運營商網(wǎng)絡不支持IPv6，同時由于缺少IPv4公有地址，它們只能向手機用戶分配私有IPv4地址。這樣，手機用戶本身就存在于NAT之中，即便支持IPv6也無法進行端到端的通信。通過本文的Silkroad系統(tǒng)，手機用戶不僅可以和手機用戶通信，還可以和PDA及PC用戶進行通信，任何一方只要輸入對方的IPv6地址就可以開始這個通信過程。可見，Silkroad在運營商網(wǎng)絡由IPv4向IPv6的過渡過程中能起到重要的推動作用。

5 結(jié)束語

本文提供了一種可以使IPv4中的NAT用戶獲得IPv6網(wǎng)絡通信的協(xié)議：Silkroad，它相比Teredo而言支持所有類型的NAT用戶，能為用戶分配固定不變的IPv6地址，并且具有更高的安全性。我們將Silkroad部署在示范性網(wǎng)絡平臺上，實現(xiàn)了手機與手機及手機與PDA或PC間的基于IPv6的端到端通信。Silkroad為NAT用戶提供了接入IPv6網(wǎng)絡的有效方法，在IPv4向IPv6的過渡過程中將會起到重要的推動作用。目前，Silkroad已經(jīng)成為了中國通信行業(yè)標準[4]。其作為中科院知識創(chuàng)新工程重要方向項目“IPv6網(wǎng)絡關(guān)鍵技術(shù)研究和城域示范系統(tǒng)”的重要成果，通過了由中科院組織的科技成果鑒定。鑒定專家委員會認為Silkroad技術(shù)具有明顯的技術(shù)創(chuàng)新和實用價值，具有國際領(lǐng)先水平。

參考文獻

[1] SRISURESH P， HOLDREGE M. IP network address translator （NAT） terminology and considerations [S]. RFC2663. 1999.

[2] ROSENBERG J， MAHY R， MATTHEWS P， et al. Session traversal utilities for NAT （STUN） [S]. RFC5389. 2008.

[3] HUITEMA C. Teredo： Tunneling IPv6 over UDP through （network address translations） NATs [S]. RFC4380. 2006.

[4] YD/T 1635-2007. IPv6網(wǎng)絡技術(shù)要求--面向網(wǎng)絡地址翻譯（NAT）用戶的IPv6隧道技術(shù) [S]. 2007.