從IPv4到IPv6組播過渡技術(shù)

因此，必須有一套機(jī)制來保證IPv4與IPv6節(jié)點(diǎn)能直接通信以實(shí)現(xiàn)平滑過渡。目前，已有相當(dāng)多的過渡技術(shù)被提出，但它們只適用于單播通信，還不能適用于組播通信。雖然組播通信的過渡技術(shù)尚未成為人們研究工作的重心，但作為一個很有實(shí)際應(yīng)用意義的研究方向，已經(jīng)開始被越來越多的組織和團(tuán)體關(guān)注[1-4]。

1.組播過渡技術(shù)

1.1雙棧技術(shù)

雙棧的組播過渡解決方案實(shí)際上是純IPv4組播網(wǎng)和純IPv6組播網(wǎng)兩者的疊加。單播中，可以將服務(wù)器配置成雙棧，以便純IPv4和純IPv6的主機(jī)能夠輕松地訪問它。同樣，組播源也可以配置成雙棧，同時向IPv4組和IPv6組發(fā)送數(shù)據(jù)流，使

在雙棧網(wǎng)絡(luò)上IPv4和IPv6組播可以同時部署。IPv4和IPv6組播能同時運(yùn)行在路由器和主機(jī)上，并且能同時存在于同一網(wǎng)絡(luò)鏈路；路由器也能同時成為IPv4組和IPv6組的匯聚點(diǎn)(RP)。

對于簡單的單源情況，如果數(shù)據(jù)流只存在于一個封閉環(huán)境中，所有潛在接收者都支持同一IP協(xié)議，則源只需要使用這一IP協(xié)議。在更多的開放環(huán)境中，潛在接收者及其支持的IP協(xié)議是未知的，為了確保所有接收者都能夠接收，需要有一個IPv4源和一個IPv6源，此時必須保證兩個源都使用同一源數(shù)據(jù)。

只有少量源時，可以利用雙棧技術(shù)，將所有源配置成雙棧，同時向IPv4組和IPv6組發(fā)送報文。但在一個視頻會議中，幾乎每個人都要同時接收和發(fā)送數(shù)據(jù)，并且一部分參與者使用純IPv4，另一部分使用純IPv6，在這種情況下雙棧技術(shù)將無能為力。另外，使用雙棧技術(shù)時，帶寬的耗費(fèi)將是原來的兩倍。

雙棧技術(shù)不需要額外的設(shè)備，也不需要對組播數(shù)據(jù)做額外的轉(zhuǎn)換。因此，是最容易實(shí)施的一種方案。適用于應(yīng)用環(huán)境中不需要IPv4主機(jī)與IPv6主機(jī)之間進(jìn)行通信的情況，如內(nèi)容分發(fā)。

1.2協(xié)議轉(zhuǎn)換技術(shù)

協(xié)議轉(zhuǎn)換技術(shù)可以在無需改動基礎(chǔ)設(shè)施的情況下，使IPv6主機(jī)能像與IPv6組播組通信一樣，使用普通的IPv6組播協(xié)議與任何IPv4組播組通信。其核心思想是：在使用一種IP協(xié)議的源和使用另一種IP協(xié)議的宿之間的路徑上放置一個或多個轉(zhuǎn)換設(shè)備。在極少數(shù)的情況下，轉(zhuǎn)換也在發(fā)送或接收的主機(jī)上完成，這主要針對運(yùn)行在雙棧主機(jī)上但僅支持一種IP協(xié)議的應(yīng)用程序。常用的轉(zhuǎn)換方法有以下幾種：

(1)轉(zhuǎn)發(fā)器

IPv4中，轉(zhuǎn)發(fā)器(Reflector)方案在無法全局組播時經(jīng)常被采用。虛擬房間視頻會議系統(tǒng)(VRVS)是一個典型的例子，它在核心網(wǎng)上采用純組播，在無法直接通過組播的區(qū)域設(shè)置轉(zhuǎn)發(fā)器作為此區(qū)域的組播代理。核心網(wǎng)與轉(zhuǎn)發(fā)器之間采用單播方式連接，轉(zhuǎn)發(fā)器與端系統(tǒng)之間可以采用純組播也可以使用單播。

IPv4-IPv6組播轉(zhuǎn)發(fā)器在IPv4和IPv6組播之間進(jìn)行轉(zhuǎn)換(Reflect)，而不是在單播與組播之間進(jìn)行轉(zhuǎn)換。給定IPv4組地址和端口及IPv6組地址和端口，轉(zhuǎn)發(fā)器將同時加入兩個組并監(jiān)聽相應(yīng)的端口，從一個組接收到的所有數(shù)據(jù)將重新發(fā)送(Resend)至另一組。

按照IPv6的過渡進(jìn)程，轉(zhuǎn)發(fā)器可以有以下兩種部署方案：當(dāng)內(nèi)容提供者所使用的協(xié)議沒有被廣泛支持，并且主機(jī)或應(yīng)用程序不支持雙協(xié)議時，轉(zhuǎn)發(fā)器位于源附近；當(dāng)接收者使用不同于源的另一種協(xié)議時，那么在接收者附近放置轉(zhuǎn)發(fā)器也是非常有效的。

轉(zhuǎn)發(fā)器方案主要缺陷是性能較低，不能支持大規(guī)模的組播應(yīng)用。另外它必須為每個會話都啟用一個實(shí)例，即使沒有接收者，它仍執(zhí)行接收重發(fā)的過程。

因?yàn)樯鲜龅木窒?，轉(zhuǎn)發(fā)器可以被用來為多個組播組工作，但同時工作的會話數(shù)量有限。如果利用轉(zhuǎn)發(fā)器在網(wǎng)絡(luò)上提供服務(wù)，用戶必須聯(lián)系管理員，申請?jiān)谟邢薜臅r間內(nèi)分配一個會話；或者可以像隧道代理(Tunnel Broker)一樣，使用Web認(rèn)證等輔助措施來使會話分配過程自動化。

(2)網(wǎng)關(guān)

組播過渡技術(shù)的發(fā)展晚于單播過渡技術(shù)，因此大部分組播過渡技術(shù)都不同程度地借鑒了單播過渡技術(shù)的思想。雙棧技術(shù)自然毋須多言，因?yàn)樗诮M播過渡技術(shù)與單播過渡技術(shù)中完全是一致的。轉(zhuǎn)發(fā)器技術(shù)工作于傳輸層，從而避免了報頭轉(zhuǎn)換，這與單播過渡的TCP-UDP中繼技術(shù)的思想是一致的。IPv4-IPv6組播網(wǎng)關(guān)則是一種類網(wǎng)絡(luò)地址轉(zhuǎn)換/協(xié)議轉(zhuǎn)換(NAT-PT)的方案。

NAT-PT[5]主要是針對單播提出的，并不能完全適用于組播。網(wǎng)關(guān)根據(jù)NAT-PT的思想，結(jié)合組播自身的特性優(yōu)化改進(jìn)，從而形成適合組播的IPv4-IPv6過渡技術(shù)。

網(wǎng)關(guān)的思想是將IPv4組播地址通過加上指定“/96”的前綴嵌入到IPv6地址中，從而每一個IPv4組播地址都有一個相應(yīng)的IPv6組播地址；同樣，每個IPv6地址也都和一個IPv4地址對應(yīng)。參與組播過渡的IPv4與IPv6地址之間是一一映射的關(guān)系，這是IPv4-IPv6組播網(wǎng)關(guān)一個至關(guān)重要的特性。正是因?yàn)檫@個特性，協(xié)議轉(zhuǎn)換的工作才能夠順利地進(jìn)行。

網(wǎng)關(guān)可以部署在IPv4和IPv6網(wǎng)絡(luò)的邊界，也可以放置在雙棧網(wǎng)絡(luò)中。它可用于單個站點(diǎn)或組織，也可以作為服務(wù)在大型網(wǎng)絡(luò)上提供。需要的話，甚至可以為同一網(wǎng)絡(luò)部署多個網(wǎng)關(guān)。

網(wǎng)關(guān)的主要不足有兩點(diǎn)：對IPv4組播的組成員及源的有效期不敏感、IPv4只能訪問給定前綴的IPv6組。

網(wǎng)關(guān)最大的優(yōu)勢在于提供IPv4和IPv6組播的相互通信機(jī)制，使用網(wǎng)關(guān)可以建立同時存在IPv4和IPv6的多方視頻會議，并可進(jìn)行全雙向連接。NAT-PT已逐漸成為主要的單播過渡方案，與之相近的網(wǎng)

(3)其他過渡技術(shù)

6over4過渡技術(shù)將IPv4網(wǎng)絡(luò)當(dāng)作具有組播功能的一條鏈路，通過IPv6組播地址和IPv4組播地址的映射關(guān)系實(shí)現(xiàn)IPv6協(xié)議的鄰居發(fā)現(xiàn)功能，使孤立IPv6主機(jī)之間形成IPv6互聯(lián)。這種單播過渡機(jī)制本身就是采用IPv4組播作為其底層載體，用于IPv6組播時，只將其目的地址映射到專私用組播地址域——239.0.0.0/8。因?yàn)?over4過渡技術(shù)本身并未大規(guī)模地應(yīng)用，基于它的組播技術(shù)很少被提及。

應(yīng)用層組播(ALM)在應(yīng)用層實(shí)現(xiàn)組播功能，而不是在網(wǎng)絡(luò)層實(shí)現(xiàn)組播功能。其實(shí)際是一種疊加于單播網(wǎng)絡(luò)的邏輯網(wǎng)。因此，ALM的過渡由應(yīng)用層來保證。它的過渡問題最終歸結(jié)為單播IPv6過渡。

NAT-PT+ALG是在現(xiàn)有NAT-PT的基礎(chǔ)上加入組播應(yīng)用層網(wǎng)關(guān)(ALG)以滿足組播的需求。韓國的ETRI項(xiàng)目和以及歐洲的GTPv6項(xiàng)目曾經(jīng)提出過這種方案。

隧道技術(shù)將一種協(xié)議的組播報文封裝在另一協(xié)議報文中，從而可以實(shí)現(xiàn)組播的跨網(wǎng)傳輸。雖然目前不是所有的隧道過渡技術(shù)都支持組播，但在加入需要額外的功能代碼后，很多都可以支持。所有的隧道技術(shù)均是基于雙棧的，因此不能實(shí)現(xiàn)純IPv6主機(jī)和純IPv4主機(jī)之間的通信。

2.多播轉(zhuǎn)換網(wǎng)關(guān)模型

多播轉(zhuǎn)換網(wǎng)關(guān)(MTG)模型是基于Linux2.4內(nèi)核的網(wǎng)關(guān)協(xié)議轉(zhuǎn)換方案原型。

MTG模型在網(wǎng)絡(luò)中的部署如圖1所示，MTG部署在IPv4和IPv6網(wǎng)絡(luò)的邊界。MTG模型將IPv4網(wǎng)絡(luò)和IPv6網(wǎng)絡(luò)視為地位對等的兩個異構(gòu)網(wǎng)絡(luò)。從網(wǎng)關(guān)向兩邊看，一邊是純IPv4網(wǎng)絡(luò)，另一邊是純IPv6網(wǎng)絡(luò)。網(wǎng)關(guān)的工作對IPv4和IPv6而言也是對等的：IPv6主機(jī)可以加入組播源位于IPv4網(wǎng)絡(luò)的組播組，IPv4主機(jī)也可以加入組播源位于IPv6網(wǎng)絡(luò)的組播組。

在IPv4中，MTG作為IPv6的代理，參與IPv4的組播；同樣，MTG在IPv6中則作為IPv4的代理。圖中MTG既可理解為單個雙棧設(shè)備，也可理解為一個雙棧網(wǎng)絡(luò)。在MTG系統(tǒng)內(nèi)部，兩個代理之間進(jìn)行協(xié)議轉(zhuǎn)換。

2.1模型結(jié)構(gòu)

圖2虛線框部分給出了MTG的模型結(jié)構(gòu)。主要由IPv4組播代理(MP4)、IPv6組播代理(MP6)、組播協(xié)議轉(zhuǎn)換器(MT)、地址映射器(AM)、簡單網(wǎng)絡(luò)管理協(xié)議(SNMP)接口、MTG管理信息庫(MIB)組成。

(1)IPv4組播代理

IPv4組播代理作為IPv6接收節(jié)點(diǎn)的代理加入IPv4組播組，接收從IPv4流出的組播報文，再將報文轉(zhuǎn)交給組播協(xié)議轉(zhuǎn)換器。IPv4組播代理的主要工作包括：向IPv4網(wǎng)絡(luò)發(fā)送Internet組管理協(xié)議(IGMP)消息，向IPv4網(wǎng)絡(luò)發(fā)送組播數(shù)據(jù)，從IPv4網(wǎng)絡(luò)接收組播報文。向IPv4網(wǎng)絡(luò)發(fā)送IGMP消息包括響應(yīng)IGMP查詢、主動向路由器發(fā)送未經(jīng)同意的成員關(guān)系報告以及主動發(fā)起離開組信息。接收組播報文時，必須進(jìn)行有效性檢查，如IPv6中所有主機(jī)都已離開該組播組，則報文不再向組播協(xié)議轉(zhuǎn)換器轉(zhuǎn)交，并立即向IPv4發(fā)起離開組信息。