面向NAT用戶的IPV6過渡機(jī)制研究

1、面向 NT 用戶的 IPV6 過渡機(jī)制研究XX:TP393XX:XX:1009-3044(20XX)27-7653-02IPv6 取代 IPv4 已成為必定,XX 絡(luò)界的研究熱點是怎樣由IPv4 向 IPv6 的成功平滑過渡。 在現(xiàn)階段 , 解決過渡問題的基本技術(shù)主要有三種 :IPv4/IPv6 協(xié)議轉(zhuǎn)換和雙協(xié)議棧及隧道技術(shù)。 其中 遂道技術(shù)是一種重要的過渡技術(shù),絕大多數(shù)隧道基于 IPv6-In-IPv4 封裝方式,就是將IPv6 分組封裝在 IPv4 分組中,利用已有的 IPv4 路由體系進(jìn)行傳輸,解決被IPv4XX 絡(luò)分離的兩個IPv6XX 絡(luò)或節(jié)點之間通信的問題。 但 IPv6-In-I

2、Pv4 報文無法通過 IPv4XX 絡(luò)中大量存在的 NT 設(shè)備 , 因此這類隧道不能在有NT的環(huán)境中使用。但我國的現(xiàn)狀是8000 多萬個上 XX 用戶只有3000 多萬個 IPv4 地址。除了采納動態(tài)分配緩解地址緊張外,更多的則是采納 NT 技術(shù)來解決這個問題。在 IPv4 向 IPv6 的過 渡時期 ,如何為這些 NT 用戶提供 IPv6 接入服務(wù),使得它們能和其他 IPv6 節(jié)點實現(xiàn)互通互訪,是一個切實需要解決的問題。幾種面向 NT 用戶的遂道技術(shù)分析國際上現(xiàn)有的隧道機(jī)制中微軟公司提出的 Teredo 協(xié)議和中科院計算所提出的 Silkrod 協(xié)議是專為 NT 用戶設(shè)計的過渡技術(shù)。它們都采

3、納 IPv6-in-UDP 隧道 ,也就是將 IPv6 報文封裝在IPv4UDP 載荷中的方式實現(xiàn)NT 用戶和 IPv6XX 絡(luò)的互連。Teredo 的地址獵取過程Teredo 的客戶端產(chǎn)生一個IPv6 的路由請求報文,并將其封裝在 IPv4 的 UDP 數(shù)據(jù)包的凈荷里通過現(xiàn)有的 IPv4XX 絡(luò)發(fā)給Teredo 服務(wù)器 ,服務(wù)器收到這個路由請求后 ,向客戶端返回一個包含有一個IPv6 的地址前綴以及Teredo 客戶端經(jīng)過NT 設(shè)備映射后的公有IPv4 地址和端口號的路由信息 ,根據(jù)這個返回的路由宣告消息客戶端生成一個結(jié)構(gòu)如圖 1 的 IPv6 地址。然后 ,Teredo 客戶端會定期地發(fā)送

4、單一的氣泡數(shù)據(jù)包 （ 由 IPv6 報頭組成 ,并且不包含IPv6 有效載荷,為維持或建立一個NT 映射而發(fā)送 ） 到 Teredo 服務(wù)器。 Teredo 服務(wù)器會在不回復(fù)的情況下丟棄該數(shù)據(jù)包。這個周期性的數(shù)據(jù)包會重新刷新NT 的轉(zhuǎn)換表。來維持這種映射關(guān)系。Teredo 的局限性在 Teredo 機(jī)制中同一鏈路上客戶端之間的通信是不受限的其它類型的通信則依賴于客戶端的所屬的 NT 類型。 而對于對稱NT 類型 ,則根據(jù)數(shù)據(jù)包中的目的地址來轉(zhuǎn)換它的私有地址及端口 ,如果目的地址不同,那么經(jīng)過轉(zhuǎn)換后的外部地址和外部端口也會不同。這樣隧道另一端IPv4 地址的變化就會引起NT 用戶本身隧道參數(shù)的變

5、化。但Teredo 協(xié)議一個隱含的假定是用戶配置了 IPv6 地址后,內(nèi)嵌其中的隧道參數(shù)是不會發(fā)生變化的。顯然如果存在對稱類型NT 的情況 ,從用戶 IPv6 地址中獲得的隧道參數(shù)則是不正確的,這就導(dǎo)致了Teredo 服務(wù)對對稱NT 用戶的不適用。Teredo 的實現(xiàn)相對比較復(fù)雜,與現(xiàn)有的XX 絡(luò)結(jié)構(gòu)很難兼容。因為不僅需要增設(shè)Teredo 服務(wù)器來協(xié)助 Teredo 客戶端建立連接 ,而且還要求Teredo 客戶端所要訪問的一般IPv6 站點附近的路由器有Teredo 中繼功能 , 即該路由器不但要能識別Teredo 格式的特別 IPv6 地址,還要向所在XX 絡(luò)廣播 Teredo格式的地址的

6、可達(dá)性,并能和Teredo 服務(wù)器共同完成穿透NT的功能。這必定需要對所有的 IPv6 XX 絡(luò)入口處的路由器進(jìn)行升級。Silkrod 遂道技術(shù) 4Silkrod 協(xié)議是由中科院計算所提出的,能支持所有類型的NT 用戶與 IPv6 XX 絡(luò)進(jìn)行互連,能為用戶分配固定不變的IPv6地址 ,而 具 有 更高 的 安 全 性 。 雖 然 Silkrod 隧 道也 采納 IPv6-In-UDP 隧道的方式實現(xiàn)NT 用戶與IPv6XX 絡(luò)互聯(lián)的。 但不同的是它為NT 用戶分配的 IPv6 地址沒有采納固定格式的前綴 ,而且地址中也沒有嵌入 NT 映射地址或映射端口等信息。Silkrod 協(xié)議的體系結(jié)構(gòu)如

7、圖 2 。Silkrod 體系簡介初始化過程中,客戶端向?qū)Ш狡靼l(fā)送一個接入請求報文, 由導(dǎo)航器為其選擇一個路由距離最近的隧道服務(wù)器, 將服務(wù)器的IPv4 地址返回給客戶端?？蛻舳巳缓笙蛑付ǖ乃淼婪?wù)器發(fā)送一個地址請求報文 ,報文內(nèi)容為身份認(rèn)證信息以及創(chuàng)建IPv6 地址所需要的接口標(biāo)識符,當(dāng)服務(wù)器收到請求報文后對客戶端的身份進(jìn)行認(rèn)證,通過認(rèn)證后便為其構(gòu)造一個IPv6 地址 ,接著在映射表中添加該地址和隧道參數(shù)之間的映射關(guān)系,然后將地址和更新過的身份認(rèn)證信息作為響應(yīng)報文的內(nèi)容再返回給客戶端。 客戶端再對服務(wù)器的身份進(jìn)行認(rèn)證,當(dāng)通過認(rèn)證后配置IPv6 地址,并建立另一端為服務(wù)器的 IPv6-In-U

8、DP 隧道。 在此之后,客戶端就可以通過該隧道和 IPv6 XX 絡(luò)上的其他節(jié)點進(jìn)行端到端的通信 ,服務(wù)器在數(shù)據(jù)轉(zhuǎn)發(fā)過程中要檢查數(shù)據(jù)包的合法性:一個是以目的 IPv6 地址為入口查找映射表,如果沒有這個入口,表明數(shù)據(jù)包是一個非法數(shù)據(jù)包,作丟棄處理;另一個是檢查從IPv4 接口收到的數(shù)據(jù)包,以源IPv6 地址為入口查找映射表,如果沒有這個入口或者這個入口對應(yīng)的隧道參數(shù)和數(shù)據(jù)包的源IPv4 地址、 源 UDP端口不一致,則表明數(shù)據(jù)包為非法數(shù)據(jù)包,也作丟棄處理。 在只有源或目的是合法用戶的情況下,數(shù)據(jù)包才能通過上述檢查,從而大大增強(qiáng)了 XX 絡(luò)的安全性。服務(wù)器在運(yùn)行過程中 ,會周期性地向?qū)Ш狡鲌蟾尕?fù)

9、載信息如CPU 利用率、帶寬利用率、用戶數(shù)目等。對這些信息進(jìn)行統(tǒng)計和分析則有導(dǎo)航器負(fù)責(zé),以便系統(tǒng)治理員能動態(tài)掌握服務(wù)器的運(yùn)行狀況,在客戶端建立遂道之前給予指導(dǎo)。Silkrod 地址構(gòu)造客戶端的 IPv6 地址是由 64 位的地址前綴和 64 位的接口標(biāo)識符組合構(gòu)成,地址前綴由隧道服務(wù)器確定,因為隧道服務(wù)器在部署的時候都會分配一個全球唯一的 64 位地址前綴用于構(gòu)造客戶端 IPv6 地址 ,所以客戶端只要確定了選擇接入的隧道服務(wù)器 ,64 位的地址前綴也隨之確定而不再發(fā)生變化 ,IEEE 定義了 64 位的 Eui-64 編碼,用來表示XX 絡(luò)適配器的地址,如圖 3 所示。參考 Pppv6 生成

10、接口標(biāo)識符的方法,如果客戶端有EUI-64地址,哪么只要將它的“U ”位取反 ,就可以得到接口標(biāo)識符 ;如果有 Eui-48 地址哪么在其中間添加值為“ 0 xfffe ”的 16 位比特 , 成為一個EUI-64地址后 ,再將 “ U ” 位取反便可得到接口標(biāo)識符;如果沒有EUI-48或EUI-64地址 ,就將機(jī)器序列號等數(shù)值轉(zhuǎn)換成64 位編碼。采納這種方式生成的接口標(biāo)識符不僅具有固定性,而且具有唯一性,從而保證了 IPv6 地址的唯一性。 雖然客戶端可以獲得一個固定不變的 IPv6 地址 ,但必須在有一個IPv6 的域名的前提下,客戶端才可以被其它節(jié)點主動的去訪問。隧道維護(hù)和狀態(tài)信息治理當(dāng)

11、客戶端完成初始化過程后會以一定的時間間隔周期性的向隧道服務(wù)器發(fā)送IPv6-In-UDP 報文 ,一般發(fā)送默認(rèn)周期為 30s對于狀態(tài)信息的治理服務(wù)器通常采納客戶端顯式通知的方式 ,盡 可能多地刪除那些不再使用的信息 ,從而降低因維護(hù)信息對系統(tǒng) 資源的消耗。 例如如果客戶端在下線之前向服務(wù)器發(fā)送一個中斷 連接請求,哪么服務(wù)器收到請求后便會刪除對應(yīng)的映射關(guān)系。但這種方式不能較好地處理客戶端異常下線的情況。 對于異常下 線的情況Silkrod 則采納客戶端維護(hù)UDP 會話的過程來治理狀態(tài)信息。 服務(wù)器會為每個建立的映射關(guān)系設(shè)定一個計時器,一旦如果收到的收到來自客戶端的數(shù)據(jù)包就會刷新計時器重新計時。如果收到的是一個空數(shù)據(jù)包, 哪么服務(wù)器除了刷新計時器外將不作任何其他處理。如果計時器一旦超時 ,服務(wù)器就認(rèn)為客戶端已經(jīng)下線,便刪除對應(yīng)的映射關(guān)系。 采納這種方式可使隧道服務(wù)器上維護(hù)的都是處于活動狀態(tài)的映射關(guān)系 ,使治理更加高效。Silkrod 的不足Silkrod 在解決 Teredo 問題的同時也付出了一定的代價。它的不足之處在于兩個客戶端之間通信時,從源客戶端發(fā)出的數(shù)據(jù)包必須先到達(dá)隧道服務(wù)器,再由隧道服務(wù)器轉(zhuǎn)發(fā)給目標(biāo)客戶端而相應(yīng)的返回的數(shù)據(jù)包也必須由隧道服務(wù)器的中轉(zhuǎn),才能到達(dá)源客戶端。 所