對于IPv4，IP地址的匱乏，網絡安全的漏洞，帶寬問題等等。那么現在IPv6的來臨卻正好解決了這些問題，但是對于普及來說，它卻又有著相當大的問題。針對這個情況，我們就要做好IPv4與IPv6之間的通信問題了。

(1)Dual Stack Model ( RFC2893 )

在這種模型下，任意節點都是完全雙棧的。這時不存在IPv4與IPv6之間的相互通信問題，但是這種機制要給每一個IPv6的站點分配一個IPv4地址。這種方法不能解決IPv4地址資源不足的問題，而且隨著IPv6站點的增加會很難得到滿足，因此這種方法只能用在早期的變遷過程。

(2)Limited Dual Stack Model ( RFC2893 )

在這種模型下，服務器和路由器仍然是雙棧的，而非服務器的主機只需要支持IPv6。這種機制可以節省大量的IPv4地址，但是在純IPv6和純IPv4節點之間的通信將會出現問題，為了解決這種問題，必須與其它技術結合使用。

(3)SIIT ( Stateless IP/ ICMP Translation, RFC2765 )

SIIT定義了在IPv4與IPv6的分組報頭之間進行翻譯的方法，這種翻譯是無狀態的，因此對于每一個分組都要進行翻譯。這種機制可以和其它的機制(如NAT-PT)結合，用于純IPv6站點同純 IPv4站點之間的通信，但是在采用網絡層加密和數據完整性保護的環境下這種技術不可用。純IPv6節點和純IPv4節點通過一個SIIT轉換器通信，IPv6節點看到的對方一個IPv4?mapped地址的主機，同時它自己則使用一個IPv4 translated的地址。如果IPv6主機發出的IP分組中的目的地址是一個IPv4?mapped地址，那么SIIT轉換器就知道這個IP分組需要進行協議轉換。

(4)NAT-PT (Network Address Translation - Protocol Translation, RFC2766 )

NAT-PT就是在做IPv4與IPv6地址轉換(NAT)的同時在IPv4分組和IPv6分組之間進行報頭和語義的翻譯(PT)。適用于純IPv4站點和純IPv6站點之間的通信。對于一些內嵌地址信息的高層協議（如FTP），NAT-PT需要和應用層的網關協作來完成翻譯。在NAT-PT的基礎上利用端口信息，就可以實現NAPT-PT，這點同目前IPv4下的NAPT沒有本質區別。

NAT-PT的原理和SIIT類似，其改進的地方是將傳統的IPv4下的NAT應用于SIIT中的IPv4地址的選取當中。SIIT的一個***的缺點是需要比較大的IPv4地址池，以供IPv6應用動態分配。這個IPv4地址池很大程度上制約了SIIT 的應用。而NAT-PT采用傳統的IPv4下的NAT技術來分配IPv4地址，這樣就可以以很少的IPv4地址構成自己的IPv4地址分配池，可以給大量的需要進行地址轉換的應用使用協議轉換服務。

在實現方面，如果沒有DNS-ALG的支持，只能實現由IPv6發起的與IPv4之間的通信，反之，包就會被丟棄。如果有DNS-ALG的支持，就可以實現雙向的通信。有一些應用需要一定程度的地址穩定性，NAT-PT可以被配置成提供V6到特定V4地址的靜態映射。

該機制適用于過渡的初始階段，使得基于雙協議棧的主機，能夠運行IPv4應用程序與IPv6應用互相通信。這種技術允許不支持IPv6的應用程序透明地訪問純IPv6站點。該機制要求主機必須是雙棧的，同時要在協議棧中插入三個特殊的擴展模塊：域名解析器、地址映射器和翻譯器，相當于在主機的協議棧中使用了NAT-PT。

(6)BIA ( Bump-In-the-API, Internet Draft )

這種技術同BIS類似，只是在API層而不是在協議棧的層次上進行分組的翻譯，所以它的實現比BIS要簡單一些，因為不需要對IP包頭進行翻譯。BIS與BIA的主要區別是：BIS用在沒有IPv6協議棧的系統上，BIA用在有IPv6協議棧的系統上。#p#

當雙棧主機上的IPv4應用與其它IPv6主機通信時，API翻譯器檢測到從IPv4應用發出的基于socket API的函數，就調用IPv6 socket API函數與IPv6主機通信。

(7)SOCKS64 ( Socks gateway, rfc3089 )

SOCKS64是原有SOCKS協議 ( RFC1928 )的擴展，相當于IP層的代理。這種機制不需要修改DNS或者做地址映射，可用于多種環境，但是需要采用SOCKS代理服務器，并在客戶端安裝支持SOCKS代理的軟件，對于用戶來講不是透明的。該機制增加了兩個新的功能部件，它們構成了網關機制。

除了上述7種通信方式，IPv4與IPv6還可以通過TRT、DSTM、ALG等方式進行通信。

如何選擇IPv4與IPv6的過渡機制

從已有的過渡機制可以看出，目前所有的方案都是針對某一種問題而提出的。這些過渡機制都不是普遍適用的，每一種機制都適用于某種或幾種特定的網絡情況，而且常常需要和其它的技術組合使用。在實際應用時需要綜合考慮各種實際情況來制定合適的過渡策略。對于某一類互連問題，設計者們可以找出新的方式，并隨著網絡技術和發展不斷的改進和更新這種方式。

為選擇一個合適的機制，首先需求要明確，明確應用的類型、范圍和系統的類型，然后選擇合適的轉換機制進行設計和實施。IPv4向IPv6過渡時期，通常采用的組網原則：

◆在能直接建立IPv6鏈路的情況下，使用純IPv6路由；

◆在不能使用IPv6鏈路的情況下，IPv6節點之間使用隧道技術；

◆雙棧的IPv6/IPv4主機和純IPv6或者純IPv4 的主機通信不需要采用協議轉換，而直接“自動”選擇相應的通信協議（IPv4或者 IPv6）。

◆對于純IPv6和純IPv4主機之間的通信，則應該使用協議轉換或者應用層網關（ALG）技術，設計的協議轉換器或者ALG應該盡量保證在不修改原有應用的情況下就可以使用