IPv4向IPv6過渡場景分析
孫瓊 江志峰 陳運清
來源： 電信網技術
摘要： 在今后一段時間內，IPv4和IPv6將長期共存，這種共存的趨勢將會隨著IPv4地址的進一步消耗逐漸過渡為以IPv6為主導的情形。目前，隨著IPv4地址緊缺所導致的IPv4和IPv6的過渡共存場景主要包括以下幾個方面：
Abstract：
Key words :
在今后一段時間內，IPv4和IPv6將長期共存，這種共存的趨勢將會隨著IPv4地址的進一步消耗逐漸過渡為以IPv6為主導的情形。目前，隨著IPv4地址緊缺所導致的IPv4和IPv6的過渡共存場景主要包括以下幾個方面：
（1）IPv4 NAT（Network Address Translator）及NAT444 IPv4的NAT解決方案是暫時緩解IPv4地址消耗的有效途徑，已被廣泛使用。NAT可以使用端口復用，這樣一個用戶（或一個單位、部門）獲得的惟一一個公網IP地址可以由多個用戶使用。
在IPv4 NAT的基礎上，隨著IPv4地址的進一步緊缺，用戶的公網地址也無法得到的情況下，運營商網絡也開始使用私用地址，這樣NAT的位置就由用戶終端設備（Customer Premises Equipment，CPE）側移到了接入匯聚處，因此就出現了雙層NAT（見圖1）。在該方案增加了系統的復雜性，限制了較多應用的部署與開展，具有可擴展性、安全性、端對端可靠性的問題。
圖1 雙NAT過渡場景
（2）純IPv6接入初期
隨著IPv4地址消耗殆盡，此時用戶已無法得到IPv4地址，這時便出現了純IPv6接入的應用場景，即用戶接入的網絡是純IPv6，而不支持IPv4。由于在此階段仍然存在著大量的IPv4應用與服務，因此IPv4與IPv6的共存階段具有以下兩個長尾特征：
●操作系統的長尾特征。雖然目前的主流操作系統（Windows XP，Vista，Linux等）都已經能夠支持IPv6，但對純IPv6的支持還不夠。例如，XP尚不能在純IPv6環境中處理DNS請求。此外，一些IPv4的應用無法很快升級到IPv6，一些電子設備目前也只能支持IPv4。因此，這就要求在純IPv6的接入環境中仍然能夠使用IPv4的應用以及IPv4的操作系統。
●服務與內容的長尾特征。目前IPv6的服務還比較少，這就要求在純IPv6的介入環境中仍然能夠保持IPv4服務的連通性。
在本階段，IPv4與IPv6的共存機制包括已廣泛使用的IPv4 NAT（CGN，雙層NAT），IPv4應用與服務以及IPv6應用與服務（見圖2）。IPv6過渡初期的一個重要目標就是保持IPv4的后項兼容性，使用戶仍然能夠將IPv4的應用接入純IPv6網絡中，這樣才能夠實現IPv6的順利過渡。
（2）純IPv6接入初期
隨著IPv4地址消耗殆盡，此時用戶已無法得到IPv4地址，這時便出現了純IPv6接入的應用場景，即用戶接入的網絡是純IPv6，而不支持IPv4。由于在此階段仍然存在著大量的IPv4應用與服務，因此IPv4與IPv6的共存階段具有以下兩個長尾特征：
●操作系統的長尾特征。雖然目前的主流操作系統（Windows XP，Vista，Linux等）都已經能夠支持IPv6，但對純IPv6的支持還不夠。例如，XP尚不能在純IPv6環境中處理DNS請求。此外，一些IPv4的應用無法很快升級到IPv6，一些電子設備目前也只能支持IPv4。因此，這就要求在純IPv6的接入環境中仍然能夠使用IPv4的應用以及IPv4的操作系統。
●服務與內容的長尾特征。目前IPv6的服務還比較少，這就要求在純IPv6的介入環境中仍然能夠保持IPv4服務的連通性。
在本階段，IPv4與IPv6的共存機制包括已廣泛使用的IPv4 NAT（CGN，雙層NAT），IPv4應用與服務以及IPv6應用與服務（見圖2）。IPv6過渡初期的一個重要目標就是保持IPv4的后項兼容性，使用戶仍然能夠將IPv4的應用接入純IPv6網絡中，這樣才能夠實現IPv6的順利過渡。
圖2 純IPv6接入過渡初期場景
（3）純IPv6接入中期
在純IPv6的接入中期，隨著IPv6的進一步發展，操作系統以及應用程序對IPv6的支持都有了較好的提升，因此用戶開始較多地轉向使用純IPv6的應用，用戶端出現了較多的純IPv6的主機，而非雙棧或純IPv4的主機（見圖3）。在該階段，IPv6的服務還較為有限，大量IPv4的服務依然存在，因此用戶需要通過IPv6的應用來訪問IPv4的服務。
（3）純IPv6接入中期
在純IPv6的接入中期，隨著IPv6的進一步發展，操作系統以及應用程序對IPv6的支持都有了較好的提升，因此用戶開始較多地轉向使用純IPv6的應用，用戶端出現了較多的純IPv6的主機，而非雙棧或純IPv4的主機（見圖3）。在該階段，IPv6的服務還較為有限，大量IPv4的服務依然存在，因此用戶需要通過IPv6的應用來訪問IPv4的服務。
圖3 純IPv6接入過渡中期景
（4）IPv6普及發展階段
在IPv6已較為普及，用戶及網絡側都已經基本升級到純IPv6的環境時，此時還存在少量位于NAT后的IPv4服務。這個階段需要解決的問題是，在純IPv6的環境中訪問少量位于NAT后的IPv4服務（見圖4）。
（4）IPv6普及發展階段
在IPv6已較為普及，用戶及網絡側都已經基本升級到純IPv6的環境時，此時還存在少量位于NAT后的IPv4服務。這個階段需要解決的問題是，在純IPv6的環境中訪問少量位于NAT后的IPv4服務（見圖4）。
圖4 IPv6普及發展階段
綜上所述，純IPv6接入場景是向IPv6過渡非常重要的應用場景。尤其在IPv6的過渡初期，需要解決的主要問題在于保持IPv4的后向兼容性，使用戶能夠在IPv6的接入環境中無縫使用IPv4的應用與服務。
3 已有過渡技術
迄今為止，已有的IPv4/v6過渡技術可以分為協議翻譯類和隧道類。其中，IETF的Behave工作組主要研究協議翻譯類的技術，而Softwire工作組則主要研究隧道類的技術。
3.1 協議翻譯類
（1）技術原理
IPv6過渡中的協議翻譯類技術是由IPv4的NAT技術發展而來的。在IPv4的NAT技術中，為了減少IPv4公網地址的消耗，NAT協議翻譯網關為私網IPv4地址和公網IPv4地址建立起映射關系，通過端口的復用技術，從而達到一個公網地址可以由多個私網地址共享的效果。
與此相對應，IPv6過渡中的協議翻譯類技術就是將IPv6數據包中的每個字段與IPv4數據包中的每個字段建立起一一映射的關系，從而在兩個網絡的邊緣實現數據報文的轉換。其應用場景參見圖5。
綜上所述，純IPv6接入場景是向IPv6過渡非常重要的應用場景。尤其在IPv6的過渡初期，需要解決的主要問題在于保持IPv4的后向兼容性，使用戶能夠在IPv6的接入環境中無縫使用IPv4的應用與服務。
3 已有過渡技術
迄今為止，已有的IPv4/v6過渡技術可以分為協議翻譯類和隧道類。其中，IETF的Behave工作組主要研究協議翻譯類的技術，而Softwire工作組則主要研究隧道類的技術。
3.1 協議翻譯類
（1）技術原理
IPv6過渡中的協議翻譯類技術是由IPv4的NAT技術發展而來的。在IPv4的NAT技術中，為了減少IPv4公網地址的消耗，NAT協議翻譯網關為私網IPv4地址和公網IPv4地址建立起映射關系，通過端口的復用技術，從而達到一個公網地址可以由多個私網地址共享的效果。
與此相對應，IPv6過渡中的協議翻譯類技術就是將IPv6數據包中的每個字段與IPv4數據包中的每個字段建立起一一映射的關系，從而在兩個網絡的邊緣實現數據報文的轉換。其應用場景參見圖5。
圖5 協議翻譯機制的應用場景
在這里，通信雙方的主機需要明確本機在另一個網絡中的對應地址。在上例中需明確以下兩組地址：
●PCA：主機IPv6地址與轉換的IPv4地址。
●PCB：主機IPv4地址與映射的IPv6地址。
由于IPv4地址空間遠遠小于IPv6的地址空間，因此位于IPv4網絡中的主機可以通過加上IPv6前綴即可實現IPv4地址與IPv6地址的一一映射，但為了確定IPv6網絡中主機的IPv4地址則較為困難。由于IPv6的地址空間遠大于IPv4的地址空間，因此只能通過縮小IPv6地址空間的方法與IPv4地址建立映射關系，或者通過建立映射表的方法與IPv4地址建立映射關系。
（2）技術分類
根據IPv6地址空間與IPv4地址空間映射的不同方法，可以將協議翻譯類技術分為有狀態協議翻譯和無狀態協議翻譯。其中，有狀態協議翻譯是通過建立映射表的方案，將任意IPv6地址與任意IPv4地址之間建立映射關系，而無狀態協議翻譯則是通過將IPv4地址內嵌到IPv6地址中，實現無狀態地址翻譯。因此，無狀態協議翻譯僅能訪問具有特定格式IPv6地址的主機，而有狀態協議翻譯則能夠訪問任意地址格式的IPv6主機。
現有協議翻譯技術已有很多不同的種類。其中，根據IPv6地址空間與IPv4地址空間映射的不同方法，可分為有狀態協議翻譯和無狀態協議翻譯。其中，有狀態協議翻譯（如NAT64，PNAT等）是通過建立映射表的方案，將任意IPv6地址與任意IPv4地址之間建立映射關系，而無狀態協議翻譯則是通過將IPv4地址內嵌到IPv6地址中，實現無狀態地址翻譯。因此，無狀態協議翻譯（如IVI，DIVI等）僅能訪問具有特定格式IPv6地址的主機，而有狀態協議翻譯則能夠訪問任意地址格式的IPv6主機。
此外，根據協議翻譯的位置，可以分為主機側協議翻譯、網絡側協議翻譯以及主機側和網絡側的協議翻譯。主機側協議翻譯（如BIS，BIA等）在主機中完成翻譯即可，完成端系統中應用程序協議類型與網絡傳輸協議類型的不匹配，其應用場景為4-6-6或6-4-4；網絡側協議翻譯（如NAT64，IVI，Socks64等）僅在網絡中部署協議翻譯網關即可，完成網絡兩側協議類型的不匹配，其應用場景為6-6-4或4-4-6；而主機側和網絡中的兩次協議翻譯（如PNAT）可應用于4-6-4和6-4-6的應用場景。
最后，根據協議翻譯技術的協議層次，可以包括網絡層協議翻譯（如NAT64，PNAT，IVI，BIS）、傳輸層協議翻譯（如TRT）以及應用層協議翻譯（如BIA，Socks64等）。
（3）典型的協議翻譯技術
●NAT64
NAT64是有狀態的協議翻譯技術，在網關中記錄了“IPv4地址＋端口”與IPv6地址的映射表會話狀態，是網絡層的協議翻譯技術，其應用場景為6-6-4。NAT64的提出實際是用于替代NAT-PT的，NAT64僅允許IPv6主動發起的連接，并通過將DNS-ALG的功能與NAT64網關的功能相分離，從而可以避免NAT-PT中一些與DNS-ALG相關的缺陷。
在這里，通信雙方的主機需要明確本機在另一個網絡中的對應地址。在上例中需明確以下兩組地址：
●PCA：主機IPv6地址與轉換的IPv4地址。
●PCB：主機IPv4地址與映射的IPv6地址。
由于IPv4地址空間遠遠小于IPv6的地址空間，因此位于IPv4網絡中的主機可以通過加上IPv6前綴即可實現IPv4地址與IPv6地址的一一映射，但為了確定IPv6網絡中主機的IPv4地址則較為困難。由于IPv6的地址空間遠大于IPv4的地址空間，因此只能通過縮小IPv6地址空間的方法與IPv4地址建立映射關系，或者通過建立映射表的方法與IPv4地址建立映射關系。
（2）技術分類
根據IPv6地址空間與IPv4地址空間映射的不同方法，可以將協議翻譯類技術分為有狀態協議翻譯和無狀態協議翻譯。其中，有狀態協議翻譯是通過建立映射表的方案，將任意IPv6地址與任意IPv4地址之間建立映射關系，而無狀態協議翻譯則是通過將IPv4地址內嵌到IPv6地址中，實現無狀態地址翻譯。因此，無狀態協議翻譯僅能訪問具有特定格式IPv6地址的主機，而有狀態協議翻譯則能夠訪問任意地址格式的IPv6主機。
現有協議翻譯技術已有很多不同的種類。其中，根據IPv6地址空間與IPv4地址空間映射的不同方法，可分為有狀態協議翻譯和無狀態協議翻譯。其中，有狀態協議翻譯（如NAT64，PNAT等）是通過建立映射表的方案，將任意IPv6地址與任意IPv4地址之間建立映射關系，而無狀態協議翻譯則是通過將IPv4地址內嵌到IPv6地址中，實現無狀態地址翻譯。因此，無狀態協議翻譯（如IVI，DIVI等）僅能訪問具有特定格式IPv6地址的主機，而有狀態協議翻譯則能夠訪問任意地址格式的IPv6主機。
此外，根據協議翻譯的位置，可以分為主機側協議翻譯、網絡側協議翻譯以及主機側和網絡側的協議翻譯。主機側協議翻譯（如BIS，BIA等）在主機中完成翻譯即可，完成端系統中應用程序協議類型與網絡傳輸協議類型的不匹配，其應用場景為4-6-6或6-4-4；網絡側協議翻譯（如NAT64，IVI，Socks64等）僅在網絡中部署協議翻譯網關即可，完成網絡兩側協議類型的不匹配，其應用場景為6-6-4或4-4-6；而主機側和網絡中的兩次協議翻譯（如PNAT）可應用于4-6-4和6-4-6的應用場景。
最后，根據協議翻譯技術的協議層次，可以包括網絡層協議翻譯（如NAT64，PNAT，IVI，BIS）、傳輸層協議翻譯（如TRT）以及應用層協議翻譯（如BIA，Socks64等）。
（3）典型的協議翻譯技術
●NAT64
NAT64是有狀態的協議翻譯技術，在網關中記錄了“IPv4地址＋端口”與IPv6地址的映射表會話狀態，是網絡層的協議翻譯技術，其應用場景為6-6-4。NAT64的提出實際是用于替代NAT-PT的，NAT64僅允許IPv6主動發起的連接，并通過將DNS-ALG的功能與NAT64網關的功能相分離，從而可以避免NAT-PT中一些與DNS-ALG相關的缺陷。
NAT64能夠支持純IPv6主機與純IPv4主機的直接通信，接入網絡可以為純IPv6網絡，無需更改主機側設備，并且其IPv6地址格式不受限。由于NAT64是一個有狀態的協議翻譯機制，因此具有一定的可擴展性問題和狀態同步問題，且需要處理ALG的相關問題。
●IVI
IVI是無狀態協議翻譯技術。其中，1:1的IVI方式僅將IPv4地址內嵌到IPv6地址中，因此會消耗過多的IPv4公網地址，此時協議翻譯網關僅需在網絡側部署即可；而1:N的IVI則通過將IPv4的地址和端口范圍同時內嵌到IPv6地址中，從而實現1:N的地址復用，此時的協議翻譯網絡需要在用戶側和網絡側同時部署，用戶側僅實現端口的有狀態映射，而網絡側則可以實現無狀態地址映射。
IVI能夠實現網絡核心無狀態處理，報文轉發高效，實現簡單。由于IVI中需要將IPv4地址內嵌到IPv6中，因此IPv6地址格式比較受限，在1:1的IVI中會消耗過多的IPv4地址，而在1:N的IVI中則又需要在用戶側有一定的更改，并且也需要處理ALG的相關問題。
3.2 隧道類
（1）技術原理
隧道類技術是指將另外一個協議數據包的報頭直接封裝在原數據包報頭前，從而可以實現在不同協議的網絡上直接進行傳輸。其應用場景參見圖6。
●IVI
IVI是無狀態協議翻譯技術。其中，1:1的IVI方式僅將IPv4地址內嵌到IPv6地址中，因此會消耗過多的IPv4公網地址，此時協議翻譯網關僅需在網絡側部署即可；而1:N的IVI則通過將IPv4的地址和端口范圍同時內嵌到IPv6地址中，從而實現1:N的地址復用，此時的協議翻譯網絡需要在用戶側和網絡側同時部署，用戶側僅實現端口的有狀態映射，而網絡側則可以實現無狀態地址映射。
IVI能夠實現網絡核心無狀態處理，報文轉發高效，實現簡單。由于IVI中需要將IPv4地址內嵌到IPv6中，因此IPv6地址格式比較受限，在1:1的IVI中會消耗過多的IPv4地址，而在1:N的IVI中則又需要在用戶側有一定的更改，并且也需要處理ALG的相關問題。
3.2 隧道類
（1）技術原理
隧道類技術是指將另外一個協議數據包的報頭直接封裝在原數據包報頭前，從而可以實現在不同協議的網絡上直接進行傳輸。其應用場景參見圖6。
圖6 隧道轉換實現原理
在隧道類技術中，通過不同協議類型數據包的封裝和解封裝可以方便的實現數據包在不同協議類型網絡中的傳輸穿越。因此，隧道方式能夠較為方便地實現原有流量的承載。
（2）技術分類
●在隧道類技術中，根據其穿越的不同網絡類型，又可以分為IPv6 over IPv4類隧道（圖6左側）和IPv4 over IPv6類隧道（圖6右側）。其中，支持IPv6 over IPv4的隧道類型較多，包括已經成為標準的6 to 4，6
over 4，ISATAP，TSP，Teredo，6PE等，而支持IPv4 over IPv6的隧道類型目前基本還都處于草案階段，如DS-Lite，A+P，TSP等。
●根據隧道封裝的協議層次，又可以分為應用層隧道、傳輸層隧道（TSP）以及網絡層隧道（DS-Lite，A+P等）。其中，應用層隧道的隧道報頭通常包括以太頭，IP頭，TCP/UDP頭和應用層的標識頭；傳輸層隧道的隧道報頭通常包括以太頭，IP頭，TCP/UDP頭；而網絡層隧道的隧道報頭則通常包括以太頭和IP頭。
●針對隧道方式所應用的不同網絡結構，又可以將隧道分為星型隧道和網狀型隧道。其中，星型隧道通常有一個集中控制器與多個客戶端建立一對一隧道，通常這類隧道可以應用到接入網中，需具備NAT穿越的功能，并且能夠AAA認證、用戶管理等；而網狀型隧道則不需要核心集中控制器來建立隧道，此時隧道的斷點具有自動發現、自動建立的功能，這類隧道通常可應用于骨干網中。兩種隧道的拓撲參見圖7。
在隧道類技術中，通過不同協議類型數據包的封裝和解封裝可以方便的實現數據包在不同協議類型網絡中的傳輸穿越。因此，隧道方式能夠較為方便地實現原有流量的承載。
（2）技術分類
●在隧道類技術中，根據其穿越的不同網絡類型，又可以分為IPv6 over IPv4類隧道（圖6左側）和IPv4 over IPv6類隧道（圖6右側）。其中，支持IPv6 over IPv4的隧道類型較多，包括已經成為標準的6 to 4，6
over 4，ISATAP，TSP，Teredo，6PE等，而支持IPv4 over IPv6的隧道類型目前基本還都處于草案階段，如DS-Lite，A+P，TSP等。
●根據隧道封裝的協議層次，又可以分為應用層隧道、傳輸層隧道（TSP）以及網絡層隧道（DS-Lite，A+P等）。其中，應用層隧道的隧道報頭通常包括以太頭，IP頭，TCP/UDP頭和應用層的標識頭；傳輸層隧道的隧道報頭通常包括以太頭，IP頭，TCP/UDP頭；而網絡層隧道的隧道報頭則通常包括以太頭和IP頭。
●針對隧道方式所應用的不同網絡結構，又可以將隧道分為星型隧道和網狀型隧道。其中，星型隧道通常有一個集中控制器與多個客戶端建立一對一隧道，通常這類隧道可以應用到接入網中，需具備NAT穿越的功能，并且能夠AAA認證、用戶管理等；而網狀型隧道則不需要核心集中控制器來建立隧道，此時隧道的斷點具有自動發現、自動建立的功能，這類隧道通常可應用于骨干網中。兩種隧道的拓撲參見圖7。
圖7 隧道轉換實現原理
由于在本文中主要考慮接入網的IPv6過渡方案，因此主要考慮星型網絡下的隧道技術。
（3）典型的隧道技術
●DS-Lite
DS-Lite是一個網絡層的IPv4 over IPv6的隧道，通過將IPv4流量封裝在IPv6隧道中進行傳輸，接入網絡為IPv6單棧，可以使用IPv6地址對數據報文進行惟一標識，并且避免了CPE側的NAT轉換。DS-Lite僅在AFTR側做一次NAT轉換，對IPv6地址無格式限制。
DS-Lite隧道方式取消了用戶CPE側的NAT轉換，從而實現了網絡中僅保留一次NAT轉換，簡化了IPv4地址的分配與管理，終端用戶可使用任意IPv4私網地址。該隧道建立的過程無需進行協商，且接入網絡可以僅為純IPv6單棧。但DS-Lite也存在一定的局限性，例如DS-Lite必須對用戶側的CPE做一定的更改，在AFTR網關上需維護大量的NAT表項，具有一定的可擴展性問題和狀態的同步問題，并且無法支持由通信對端發起的連接。
由于在本文中主要考慮接入網的IPv6過渡方案，因此主要考慮星型網絡下的隧道技術。
（3）典型的隧道技術
●DS-Lite
DS-Lite是一個網絡層的IPv4 over IPv6的隧道，通過將IPv4流量封裝在IPv6隧道中進行傳輸，接入網絡為IPv6單棧，可以使用IPv6地址對數據報文進行惟一標識，并且避免了CPE側的NAT轉換。DS-Lite僅在AFTR側做一次NAT轉換，對IPv6地址無格式限制。
DS-Lite隧道方式取消了用戶CPE側的NAT轉換，從而實現了網絡中僅保留一次NAT轉換，簡化了IPv4地址的分配與管理，終端用戶可使用任意IPv4私網地址。該隧道建立的過程無需進行協商，且接入網絡可以僅為純IPv6單棧。但DS-Lite也存在一定的局限性，例如DS-Lite必須對用戶側的CPE做一定的更改，在AFTR網關上需維護大量的NAT表項，具有一定的可擴展性問題和狀態的同步問題，并且無法支持由通信對端發起的連接。
●A+P
A+P也是一個網絡層IPv4 over IPv6的隧道，采用端口靜態劃分的方式復用IPv4地址，將網絡核心側的NAT轉移到CPE側，從而實現網絡核心側無狀態的數據轉發。在A+P中，將IPv4地址和端口范圍內嵌到IPv6地址中，IPv6地址格式受限，且有特定前綴。
A+P的方案可實現網絡核心無狀態轉換，并且可以復用IPv4地址。隧道可自動建立，無協商過程。但是其缺點在于一方面CPE需進行一定的升級，并且IPv6地址格式有一定的限制。
●TSP
TSP是基于隧道代理（Tunnel Broker）的一種信令協議，通過在兩個端點間進行參數協商建立隧道，包括IPv4 over IPv6和IPv6 over IPv4兩種類型，隧道的層次也可以通過協商確定，包括網絡層和傳輸層UDP隧道。此時的IPv6地址為任意格式的地址，IPv4地址為公網地址。因此，若需要使用IPv4私有地址，則還需要額外增加NAT設備。
3.3 地址復用技術
地址共享機制可以分為兩種類型，一種是采用IPv4私網地址進行地址共享（如CGN，DS-Lite等解決方案），此時需要引入運營級NAT，在不同網絡邊界處實現私網地址與公網地址的轉換與映射；另一類則是采用公網IPv4地址進行地址共享，這類方案避免了運營級NAT轉換，通過劃分端口空間使得用戶能夠通過不同的端口空間來區分共享同一個公網IPv4地址，可以實現網絡核心側無狀態地址復用。
4 結束語
協議翻譯技術和隧道技術為兩種可應用于不同場景的過渡技術，兩個技術比較參見表1。
A+P也是一個網絡層IPv4 over IPv6的隧道，采用端口靜態劃分的方式復用IPv4地址，將網絡核心側的NAT轉移到CPE側，從而實現網絡核心側無狀態的數據轉發。在A+P中，將IPv4地址和端口范圍內嵌到IPv6地址中，IPv6地址格式受限，且有特定前綴。
A+P的方案可實現網絡核心無狀態轉換，并且可以復用IPv4地址。隧道可自動建立，無協商過程。但是其缺點在于一方面CPE需進行一定的升級，并且IPv6地址格式有一定的限制。
●TSP
TSP是基于隧道代理（Tunnel Broker）的一種信令協議，通過在兩個端點間進行參數協商建立隧道，包括IPv4 over IPv6和IPv6 over IPv4兩種類型，隧道的層次也可以通過協商確定，包括網絡層和傳輸層UDP隧道。此時的IPv6地址為任意格式的地址，IPv4地址為公網地址。因此，若需要使用IPv4私有地址，則還需要額外增加NAT設備。
3.3 地址復用技術
地址共享機制可以分為兩種類型，一種是采用IPv4私網地址進行地址共享（如CGN，DS-Lite等解決方案），此時需要引入運營級NAT，在不同網絡邊界處實現私網地址與公網地址的轉換與映射；另一類則是采用公網IPv4地址進行地址共享，這類方案避免了運營級NAT轉換，通過劃分端口空間使得用戶能夠通過不同的端口空間來區分共享同一個公網IPv4地址，可以實現網絡核心側無狀態地址復用。
4 結束語
協議翻譯技術和隧道技術為兩種可應用于不同場景的過渡技術，兩個技術比較參見表1。
表1 協議翻譯和隧道技術總結
由表1可見，目前協議翻譯技術比較適用于IPv6?àIPv4和IPv4?àIPv6的場景，而隧道技術則比較適用于IPv4?àIPv4和IPv6?àIPv6的場景。協議翻譯技術的優點在于部署簡單和應用場景多樣，缺點在于實現的復雜度較高。與此相對應，隧道技術實現較為簡單，但是其缺點在于應用場景較為單一，且需要在用戶側和網絡側均部署相應的設備。因此，可以考慮將協議翻譯和隧道技術相結合，從而可以發揮兩者的優勢，實現多場景的自適應選擇和適配。
此內容為AET網站原創，未經授權禁止轉載。