移動IPv6實施的關(guān)鍵問題及在CDMA網(wǎng)絡中的應用

摘要　IPv4的NAT缺陷、缺乏固定地址限制了CDMA網(wǎng)絡中移動IP業(yè)務的發(fā)展，CDMA移動網(wǎng)絡向IPv6承載過渡是必然趨勢。本文探討了移動IPv6在CDMA網(wǎng)絡中的應用，著重分析了CDMA網(wǎng)絡中應用移動IPv6所面臨的服務質(zhì)量、安全、認證、DNS自動發(fā)現(xiàn)、演進等問題，并對現(xiàn)有CDMA網(wǎng)絡實體的改動加以闡述。

關(guān)鍵詞　碼分多址　移動IPv6　服務質(zhì)量　多媒體域

1、前言

　　CDMA網(wǎng)絡的部署不僅為用戶提供了高速的無線連接，也為用戶接入到互聯(lián)網(wǎng)提供了更加豐富的接入手段。為在 cdma2000網(wǎng)絡中向用戶提供高速的分組數(shù)據(jù)業(yè)務，3GPP2的無線網(wǎng)絡參考模型中引入了分組域功能實體，并定義了基于IP技術(shù)的網(wǎng)絡接口。從業(yè)務實現(xiàn)上來講，分組數(shù)據(jù)業(yè)務又可以分為簡單IP和移動IP(MIP)兩大類型。其中，簡單IP業(yè)務是cdma2000網(wǎng)絡中最基本的分組數(shù)據(jù)業(yè)務模式，類似于我們所熟悉的撥號業(yè)務。移動IP業(yè)務則為移動數(shù)據(jù)用戶提供了更加完善的移動性支持，移動數(shù)據(jù)用戶可以在無線網(wǎng)絡內(nèi)獲得無縫服務，與之對應的分組域技術(shù)也有所不同。

　　由于IPv4地址空間不足，限制了網(wǎng)絡和用戶數(shù)目的發(fā)展。采用NAT技術(shù)雖然解決了地址不足問題，但破壞了網(wǎng)絡端到端的特性，缺少固定地址、永遠在線機制，限制了移動IP、IP電話、Push業(yè)務的發(fā)展。IPv6的采用，不僅滿足了未來移動設(shè)備對IP地址空間的需求，也讓移動終端更易于配置管理(自動配置)；而用戶對基于IP的應用業(yè)務的使用也更為安全方便。CDMA移動網(wǎng)絡向IPv6承載過渡是必然趨勢，基于此，本文探討移動IPv6在CDMA網(wǎng)絡中的應用事宜。

2、移動IPv6實施的關(guān)鍵問題及目前的解決思路

2.1　移動IPv6服務質(zhì)量問題

　　當移動節(jié)點改變網(wǎng)絡連接點時，數(shù)據(jù)包經(jīng)過的中間網(wǎng)絡域可能發(fā)生變化。因此，在這些網(wǎng)絡域中需要提供適當?shù)姆召|(zhì)量支持，這樣運行在移動節(jié)點上的對服務質(zhì)量敏感的應用程序才能保持可用的服務等級。

2.1.1　基于RSVP的移動IPv6服務質(zhì)量體系

　　基于RSVP(資源預留協(xié)議)的移動IPv6服務質(zhì)量體系提出了一套移動網(wǎng)絡中的信令協(xié)議，當移動主機從一個子網(wǎng)移動到另一個子網(wǎng)時，允許移動主機在當前位置的路徑上建立和維持預留資源。

　　移動IPv6對QoS的支持主要表現(xiàn)在流標記(flow label)域，流標記是按位產(chǎn)生的偽隨機數(shù)，在一定的時間內(nèi)，源端不能重用流標記。流標記為0指示這個包不屬于任何流。普通的移動IPv6與RSVP結(jié)合，在標識流時有兩種方式：一種是基于移動節(jié)點的家鄉(xiāng)地址來標識流的源端或者目的端；另一種方式是用移動節(jié)點的轉(zhuǎn)交地址(COA)來標識流的源端或者目的端。但不論是哪種方式，都存在一些問題：如果使用移動節(jié)點的家鄉(xiāng)地址來標識流，則可能會出現(xiàn)包分類的不匹配問題，預留路徑上中間路由器的包分類將可能是基于移動節(jié)點的家鄉(xiāng)地址而不是基于移動節(jié)點的轉(zhuǎn)交地址，因此該種方法是不可行的。如果用移動節(jié)點的轉(zhuǎn)交地址來標識流，當移動節(jié)點移動到另一個子網(wǎng)時，攜帶了新的轉(zhuǎn)交地址的PATH消息與RESV消息將會觸發(fā)預留路徑上的路由器進行新的資源預留，而不是重用原來的資源預留，即使新路徑只是在舊路徑基礎(chǔ)上的簡單更改。因此，無論移動節(jié)點作為源端或目的端，都必須在切換后的新路徑上重新進行資源預留，不能實現(xiàn)流透明。

　　針對移動IPv6 QoS模型的不足，通過對移動IPv6和RSVP進行擴展，出現(xiàn)了一些改進的移動IPv6 QoS模型。其中包括新加坡國立大學Charles Qi Shen提出的“流透明的移動IPv6 QoS模型”，德國柏林工業(yè)大學的Xiaoming Fu提出的“移動IPv6基于條件的QoS切換模型”等。

　　Charles Qi Shen的方法為了實現(xiàn)流透明，把移動節(jié)點發(fā)出的包的“家鄉(xiāng)地址選項”的存放位置由目的地選項頭標改為中繼點選項頭標(hop-by-hop option header)，需要路徑上所有的中間路由器都對每個包的中繼點選項頭標進行檢查，當路徑經(jīng)過的路由器非常多時代價很大，因此這種移動IPv6 QoS模型沒有可擴展性。 {{分頁}}

　　Xiaoming Fu的方法采用了基于層次化管理的QoS條件切換機制，減少了域內(nèi)切換時的信令的數(shù)目，但只是提出了一種框架，并沒有具體的QoS處理機制，而且沒有考慮流透明。

2.1.2　基于區(qū)分服務的移動IPv6服務質(zhì)量體系

　　基于區(qū)分服務的移動IPv6服務質(zhì)量體系中，每個管理域中至少有一個全局服務器，稱為全局服務質(zhì)量代理(GQA)，在控制面上；有幾個歸屬節(jié)點作為歸屬服務質(zhì)量代理(LQA)，在傳輸面上。GQA和LQA之間的通信采用COPS(common open policy service)。由于在中心服務器上保留全局信息，并且將控制和數(shù)據(jù)傳輸分開，因此用于移動環(huán)境時非常靈活，易于添加新的服務，并且更加有效。該結(jié)構(gòu)還考慮了集成移動IPv6和區(qū)分服務的其它問題，如移動環(huán)境下的網(wǎng)絡資源提供、缺乏動態(tài)配置問題、服務等級約定的定義和選擇、移動數(shù)據(jù)流的標識和計費問題等。但區(qū)分服務用于移動IP中存在以下問題：

●區(qū)分服務比較適用于設(shè)計周全、帶寬合理分配的網(wǎng)絡，支持移動環(huán)境的網(wǎng)絡由于網(wǎng)絡中的節(jié)點隨時移動，因而業(yè)務量模型比較復雜。

●在區(qū)分服務中，不同QoS區(qū)域(如不同的ISP提供的網(wǎng)絡)的業(yè)務等級協(xié)商(SLA)常常是靜態(tài)的，移動IP的高動態(tài)環(huán)境與區(qū)分服務的靜態(tài)帶寬分配是相矛盾的，因此為了MN的動態(tài)帶寬分配需要，必須支持動態(tài)的業(yè)務等級協(xié)商。

●在不同QoS區(qū)域的入口處，網(wǎng)絡的邊緣路由器要對分組流進行識別，傳統(tǒng)分組流可以通過分組頭標上的五元組來識別。而移動IPv6中的分組的源IP地址(MN發(fā)送的分組)或目的IP地址(MN接收的分組)是MN的轉(zhuǎn)交地址，該地址是隨著節(jié)點的移動動態(tài)地變化。

　　為了在移動IP網(wǎng)絡上實現(xiàn)區(qū)分服務，應精細設(shè)計提供移動服務的網(wǎng)絡，動態(tài)預測移動節(jié)點對帶寬的需求和接入的MN數(shù)，或采用資源預留等信令機制，更準確地預測滿足移動節(jié)點QoS所需的帶寬。

2.1.3　移動IPv6的頭標壓縮

　　由于無線鏈路傳輸速率較低、誤碼率較高，在無線網(wǎng)絡上傳輸IP分組的主要問題就是頭標的開銷過大。例如，一幀音頻數(shù)據(jù)凈荷通常只有15-32byte，而在移動IPv6環(huán)境中傳輸該數(shù)據(jù)需要40byte的IPv6頭標，20byte的信宿選項頭標或24byte的尋路頭標，8byte的傳輸層UDP(用戶數(shù)據(jù)報協(xié)議)頭標和12byte的RTP(實時傳輸協(xié)議)頭標?？偣驳念^標開銷是80或84byte，如果通信對端也是MN，那么分組的IP/UDP/RTP加在一起的頭標開銷有104byte。這不僅浪費帶寬，同時還使分組因出錯而被丟棄的概率增大。

　　事實上，在傳輸過程中，同一個數(shù)據(jù)流的分組的IPv6頭標有很多域是相同的，例如，版本、流標記、下一個頭標以及源地址、目的地址在一個小區(qū)內(nèi)都是不變的。動態(tài)變化的部分只有業(yè)務量等級、中繼點限制。此外，信宿選項頭標和尋路頭標中每個域都是靜態(tài)不變的。因此，頭標壓縮的基本思路是：在無線鏈路上僅僅在數(shù)據(jù)流開始時發(fā)送完整的IP分組及相應的選項頭標，后續(xù)的IP分組的頭標域可以只傳輸變化的部分和相對于同一個流的關(guān)聯(lián)識別符，以實現(xiàn)有效地利用帶寬。但由于用戶在不斷的移動中，因此，有效的頭標壓縮算法和數(shù)據(jù)流壓縮同步規(guī)程是關(guān)鍵所在。

　　IS-835C中指定了兩種頭標壓縮機制：

●選項S061，使用LLA-ROHC來壓縮RTP/UDP/IP頭標，接近0byte。

●選項S060，刪除頭標，再使用物理信道來再生。

　　S061的好處是，LLA-ROHC可以被用于VoIP以及其它多媒體應用，可根據(jù)RTP時間戳來同步語音和視頻流，缺點是實現(xiàn)復雜。S060實現(xiàn)簡單，但不能被用于非VoIP應用。 {{分頁}}

2.1.4　影響服務質(zhì)量的其它問題

　　MN在越區(qū)切換時引入的分組傳輸延時和分組丟失也是移動IP急需解決的問題，這個問題不解決，移動IP的QoS保證就無從談起。

　　目前，關(guān)于移動IP快速切換的提案很多，基本思路主要有：分組緩存、組播和基于移動觸發(fā)的預先切換等。另外，移動IP的資源預留、MN注冊過程中的認證以及移動IPv6頭標壓縮的同步規(guī)程都將在MN的切換過程中引入延時，因此移動IP的越區(qū)切換需要更加有效的方法。

2.2　移動IPv6安全、認證及DoS防御

2.2.1　移動IPv6面臨的安全威脅

　　當網(wǎng)絡體系結(jié)構(gòu)上添加新的功能時，通常會引入一些新的安全隱患：

●對移動IPv6來說，由于MN的移動需要經(jīng)常向家鄉(xiāng)代理和CN發(fā)送綁定更新報文，這一特征引入了諸多安全問題。其中最大的威脅是綁定更新報文具有對分組的重定向功能，攻擊者通過冒充MN向CN發(fā)送綁定更新報文，就可以將發(fā)往MN的分組重定向到攻擊者指定的地點。

●DoS(denial of service)攻擊，攻擊者能夠阻塞未受保護鏈路上的所有業(yè)務量，也能夠阻止MN與其它節(jié)點的通信。

●在移動IPv4協(xié)議中，移動節(jié)點獲得轉(zhuǎn)交地址前，外地代理會對移動節(jié)點進行認證等處理，但是，在移動IPv6中沒有外地代理，這意味著移動訪問的安全策略工作需要由被訪問網(wǎng)絡的路由器來完成。

●家鄉(xiāng)地址選項的運用雖然解決了網(wǎng)絡入口過濾路由器的問題，但卻暴露了MN當前的位置信息，這給某些希望隱藏MN位置信息的通信帶來了安全威脅。

2.2.2　移動IPv6的安全保護

　　移動IPv6規(guī)定了IPSec作為MN的綁定更新報文的安全保護，但在利用IPSec通信之前收發(fā)雙方需要事先建立安全關(guān)聯(lián)，即決定采用哪種認證、加密算法。一般認為，MN與其本地代理很容易建立安全關(guān)聯(lián)，但大多數(shù)情況下，MN與CN不存在安全關(guān)聯(lián)或其它安全關(guān)系。

　　采用IPSec的另外一個問題是，它依賴于PKI，而PKI的建設(shè)是一個復雜的工程。IPSec的密鑰管理要求終端具有很強的處理能力，未來使用移動IP的設(shè)備諸如手機、PDA計算能力都很弱，而且能耗也需要考慮，因此要求進行大量計算的安全機制不太適合這些設(shè)備。為此目前也在討論一種輕量級的安全保護協(xié)議，如定制密鑰(PBK，purpose built key)。

　　PBK協(xié)議中，在每一個移動IP會話之前，通信雙方產(chǎn)生一對新的公鑰/私鑰，這對密鑰匙是臨時的，只有通信雙方能夠使用，無需向第三方注冊。當會話結(jié)束時，密鑰失效。PBK協(xié)議簡單，但安全性沒有IPSec好，如沒有解決中間人攻擊等問題，并且PBK實現(xiàn)的不是用戶認證，而是設(shè)備認證。

2.2.3　移動IPv6中DoS的防御

　　在移動IPv6中DoS表現(xiàn)形式為：

●黑客向本地代理發(fā)出偽造的注冊請求，把自己的IP地址當作移動節(jié)點的轉(zhuǎn)交地址，在注冊成功后，本地代理將根據(jù)黑客注冊的轉(zhuǎn)交地址，把目的地址是移動節(jié)點的數(shù)據(jù)分組通過隧道送給黑客，黑客得到應送給移動節(jié)點的數(shù)據(jù)，而真正的移動節(jié)點卻被拒絕服務。

●黑客以數(shù)據(jù)分組不斷轟炸服務器，服務器不得不處理這些請求，并為每一個請求分配資源，而無法響應其它有用信息。 {{分頁}}

　　防御偽造注冊請求的DoS攻擊的有效辦法是對移動節(jié)點和本地代理之間交換的所有注冊信息進行有效的驗證。本地代理向MN回送的注冊應答消息采用消息摘要方法。

　　另外，可利用SCTP(流控制傳輸協(xié)議)四路防御DoS攻擊。SCTP是面向連接的可靠傳送協(xié)議，在SCTP中，TCP 中的連接被引申為關(guān)聯(lián)，每個關(guān)聯(lián)都由兩個SCTP端口號和兩個IP地址列表來標識。SYN flooding利用了TCP/IP中的TCP三次握手，惡意的攻擊者大量向服務器發(fā)送SYN報文，使得正常的連接無法建立，并在服務器端形成一個非常大的半連接列表而無法接受正常服務。而在SCTP四路握手中，INIT消息的接收端不必保存任何狀態(tài)信息或分配任何資源，它在發(fā)送INIT ACK消息時，采用了“狀態(tài)cookie”機制。采用這種方式，即使接收更多的INIT消息，接收端也沒有任何資源的消耗，它既不分配任何系統(tǒng)資源，也不保存此次新關(guān)聯(lián)的狀態(tài)，只是把相應重建狀態(tài)所用的cookie作為參數(shù)，包含在每一個回送的INIT ACK消息中，最后該cookie會被cookie-echo消息發(fā)送回來，從而防范SYN flooding等方式的DoS攻擊。

2.3　IPv6 DNS自動發(fā)現(xiàn)

　　IPv6網(wǎng)絡終端可以利用有狀態(tài)和無狀態(tài)自動地址獲得機制得到地址，DNS服務器同樣也需要有自動獲得機制。目前有三種機制，路由宣告選項機制(RA option)、DHCPv6選項(DHCPv6 option)和事先配置的任播地址機制。

(1)路由宣告選項機制

　　RA選項機制定義了一個新的鄰居發(fā)現(xiàn)(ND)選項RDNSS，包含了DNS服務器地址，可使用現(xiàn)有的ND宣告和請求機制。該方法具有以下優(yōu)點：

●只是擴展了ND自動配置機制，不需要對ND協(xié)議進行大的改動。

●和ND一樣，可在多種類型的鏈路上運作，包括點到點鏈路、點到多點鏈路、多播等。

●適用于多種網(wǎng)絡環(huán)境。

但也存在以下缺點：

●ND大多在操作系統(tǒng)內(nèi)實現(xiàn)，而DHCPv6在應用層實現(xiàn)。

●由于ND緩沖之間的同步在內(nèi)核空間中，而DNS配置文件在用戶空間中，所以目前的ND框架需要修改。

●路由器需要配置RDNSS地址。

●無線網(wǎng)絡環(huán)境中，由于多播不穩(wěn)定，此方法性能不佳。

(2)DHCPv6選項機制

　　DHCPv6中包含DNS Recursive Name Server選項來指定可以提供名字服務的服務器地址信息，提供名字搜索順序選項。主要有以下優(yōu)點：

●方便配置其它信息，如SIP服務器和NTP服務器地址。

●互操作性好。

●已為RFC，標準性好。 {{分頁}}

　　存在以下缺點：

●由于RA消息中不包含DNS信息，主機必須從路由器處接收兩個消息。

●增加了延遲，除了必須等待RA消息外，客戶還必須和DHCPv6服務器交換報文。

(3)任播地址機制

　　使用特殊的任播地址，具有以下優(yōu)點：延遲小，可與其它方法混合使用，在DNS可工作的任意環(huán)境下都可以使用。缺點主要有：此方法需要DNS服務器扮演部分路由器角色，向路由系統(tǒng)宣告任播地址。

3、CDMA網(wǎng)絡實施移動IPv6有關(guān)的問題

3.1　CDMA網(wǎng)絡中移動IPv6的演進

　　CDMA網(wǎng)絡中移動IPv6的演進有多種解決方案，如雙協(xié)議棧技術(shù)、隧道技術(shù)、協(xié)議轉(zhuǎn)換等，下面將就目前主要的幾種演進機制進行詳細說明。

(1)雙協(xié)議棧

　　IPv6和IPv4是功能相近的網(wǎng)絡層協(xié)議，兩者都基于相同的物理平臺，而且加載于其上的傳輸層協(xié)議TCP和UDP又沒有任何區(qū)別。雙協(xié)議棧，即主機和路由器在同一網(wǎng)絡接口上運行IPv4棧和IPv6棧。這樣，雙棧節(jié)點既可以接收和發(fā)送IPv4包，也可以接收和發(fā)送 IPv6包，因而兩個協(xié)議可以在同一網(wǎng)絡中共存。雙協(xié)議棧易于實施，但效率較低。

(2)隧道技術(shù)

　　隧道技術(shù)的核心思想是通過把IPv6數(shù)據(jù)報文封裝入IPv4數(shù)據(jù)報文中，讓現(xiàn)有IPv4網(wǎng)絡成為載體以建立IPv6的通信，隧道兩端的節(jié)點間數(shù)據(jù)報文的傳送通過IPv4機制進行，隧道被看成一個直接連接的通道。隧道技術(shù)只要求在隧道的入口和出口處進行修改，對其它部分沒有要求，因而技術(shù)實現(xiàn)非常容易。

　　一個隧道具有一個入口點和一個終點，為了讓數(shù)據(jù)通過，必須知道兩個端點的地址。確定入口點是直接的，因為它出現(xiàn)在 IPv4基礎(chǔ)結(jié)構(gòu)的邊界，確定隧道的終點要復雜一些。根據(jù)隧道終點地址的獲得方式可將隧道分為配置型隧道和自動型隧道，其中配置型隧道主要用于路由器到路由器，而自動型隧道有以下幾種方式：tunnel brokers(RFC 3053)(基于服務器的半自動隧道)、6to4(RFC 3056)(路由器到路由器)、ISATAP(intra-site automatic tunnel addressing protocol)(主機到路由器，路由器到主機，主機到主機)、6over4(RFC 2529)(主機到路由器，路由器到主機)、Teredo(通過IPv4 NAT建立隧道)、IPv64(IPv4/IPv6混合環(huán)境下使用)、DSTM(dual stack transition mechanism)(IPv4在IPv6隧道里)。

　　隧道技術(shù)的優(yōu)點在于隧道的透明性，IPv6主機之間的通信可以忽略隧道的存在，隧道只起到物理通道的作用，不需要大量的 IPv6專用路由器設(shè)備和專用鏈路，可以明顯地減少投資。其缺點是：過程繁瑣，IPv4主機和IP6主機無法互通。在IPv6網(wǎng)絡建設(shè)的初期，可以采用這種方式。

(3)翻譯機制

　　目前，翻譯機制有多種層次，如網(wǎng)絡層翻譯器，包括SIIT(stateless IP/ICMP translation algorithm，RFC2765)、NAT-PT(RFC2766)和BIS(bump in the stack，RFC2767)；傳輸層翻譯器有TRT(transport relay translator，RFC3142)、BIA(bump in the API，RFC3338)和SOCKS64(RFC3089)；應用層翻譯器有ALG(application level gateway)。

3.2　移動IPv6的自舉

　　自舉(bootstrapping)是指MN必須創(chuàng)建并維護以下三種信息：MN的家鄉(xiāng)地址，家鄉(xiāng)代理地址，MN與家鄉(xiāng)代理之間的IPSec安全關(guān)聯(lián)或者共享密鑰，以實現(xiàn)在家鄉(xiāng)代理完成注冊的過程。一般來講，MN每次啟動、地址前綴變化或當有更優(yōu)的家鄉(xiāng)代理出現(xiàn)時都會進行自舉。自舉可以看成是移動服務提供商驗證移動服務訂購者的身份后，為移動服務訂購者配置所需參數(shù)的過程，有以下兩種模式：

●移動服務提供商(MSP)模式的自舉，MIPv6認證獨立于網(wǎng)絡接入認證。

●綜合接入服務提供商(IASP)模式的自舉，MIPv6認證依賴于網(wǎng)絡接入認證。

　　從網(wǎng)絡運營模式方面，移動IPv6服務運營實體可以分為：接入服務提供商(ASP)、MSP和IASP，其中MSP必須通過ASP為其提供業(yè)務的基本接入，而IASP自身既是ASP又是MSP。

　　運營商在網(wǎng)絡部署初期，可以先只作為MSP，通過與第三方ASP簽訂協(xié)議，利用其作為用戶的網(wǎng)絡接入認證，而自己為用戶進行移動IPv6自舉。后期則可采用基于IASP模式的自舉，同時進行網(wǎng)絡接入認證與自舉過程，更易于實現(xiàn)可運營、可管理，但部署難度相對較大。

　　目前自舉過程本身尚有不足之處，有待進一步研究解決，如MN和處理自舉過程的實體間的相互認證和信任關(guān)系；如何確保密鑰在生命周期內(nèi)不被盜用；特定HA和地址分配的SA綁定；如何支持SA的多種算法及如何避免拒絕服務攻擊等。

3.3　基于業(yè)務的承載控制

　　PDSN充當SBBC(service based bearer control)時候，需要標識會話中的流，但MN到CN的數(shù)據(jù)是通過MN-HA隧道傳送的，對PDSN透明。為了解決此問題，目前方法為移動IP歸屬地址只使用在SIP信令消息中，而使用IP轉(zhuǎn)交地址來承載。

3.4　移動IPv6與TFT的交互

　　移動IPv6和TFT(traffic flow template)交互時，有時不能正確映射TFT到IPv6的地址，目前有兩種解決方法。方法一是修改SDP(會話描述協(xié)議)，在draft-ietf -mmusic-sdp-srcfilter-05.txt中描述，此方法方便，但效率較低。方法二是在移動性選項中增加轉(zhuǎn)交地址移動性選項，此方法復雜，但效率較高。

3.5　互通問題

　　3GPP標準要求IMS使用IPv6，并確立了其惟一性。3GPP2出于兩種體系融合的考慮，也采用了IMS模式。現(xiàn)階段最突出的問題是IETF與3GPP/3GPP2 SIP網(wǎng)元之間的差異，以及IMS與外部使用IPv4的SIP設(shè)備之間的互通性。

3.6　認證問題

　　在蜂窩網(wǎng)絡中，基于SIM的認證過程中產(chǎn)生的會話密鑰也可以用來對移動IPv6中的綁定選項進行加密認證，還可以用來保證運行在IP網(wǎng)絡上的其它應用的安全。

　　理論上講，可用SIM6機制來為移動節(jié)點、家鄉(xiāng)代理和一些通信節(jié)點的認證提供綁定認證密鑰，從而完善在多接入環(huán)境中提供移動性所必須的安全機制。但如何在CDMA網(wǎng)絡中引入SIM6，并適應機卡分離這一要求，仍然處于探索階段。

4、實施中對CDMA網(wǎng)絡設(shè)備的具體要求

　　PDSN：PDSN需要支持雙協(xié)議棧，并且能夠支持IPv6CP over PPP，即：PDSN如果不是純IPv6的連接，則可以將IPv6數(shù)據(jù)通過隧道方式傳送到外部。PDSN仍需支持基于IPv4的到PCF的A10和A11 接口。如果PDSN具有純IPv6連接，而終端協(xié)議為IPv4，PDSN必須具有某種翻譯機制。

　　DNS：現(xiàn)有的DNS服務器必須支持雙協(xié)議棧，包含IPv6業(yè)務使用的AAAA記錄，能夠接受通過IPv4或IPv6的DNS查詢。如果運營商希望動態(tài)配置歸屬地址，HA或者AAAH(歸屬地AAA)必須在歸屬地址的DNS改變時，發(fā)送DNS更新到DNS服務器。

　　無線網(wǎng)絡：可保持不變，但PCF必須可以基于IPv4的A10和A11接口來與雙協(xié)議棧的PDSN進行通信。

　　終端：為雙協(xié)議棧，支持IS-835規(guī)范(cdma2000 wireless IP network)。

　　HA：如果運營商需要支持永遠在線，HA必須為雙協(xié)議棧，且支持移動IPv6協(xié)議。

　　AS：如果網(wǎng)絡為純IPv6，HTTP服務器、Java、下載等應用服務器必須支持雙協(xié)議棧。通信協(xié)議也需相應改動。

　　SIP服務器：必須支持雙協(xié)議棧，且SDP也應支持IPv6。