前面提到DS-lite對于雙棧用戶的DNS request是啟用DNS-proxy，即將用戶的IPv4 DNS終結在家庭網關B4上，再有B4發起DNS request，之所以采用這種方式是因為DS-lite默認B4和AFTR之間的網絡是IPv6單棧的，因此將DNS request采用IPv6方式承載。

在NAT64中，雙棧用戶的IPv4網絡和IPv6網絡有可能都能訪問服務器，用戶采用哪種報文格式進行DNS請求和業務轉發呢?

典型的雙棧系統DNS訪問行為如下圖所示。首先，雙棧主機會同時發起AAAA和A的請求，在部署了DNS44和DNS64的情況下，可以獲得AAAA的響應，也可以獲得A的響應;然后，主機優先選擇IPv6網絡進行業務訪問，在IPv6網絡失敗的情況下，再選擇IPv4網絡進行訪問，網絡層設備根據主機發起的數據包類型采用相應的協議進行承載。

上述流程，用戶是先發起IPv6訪問，再IPv6網絡不可用時，再選擇采用IPv4網絡訪問，增加了用戶業務等待時間，降低了業務體驗。為了解決這個問題，將典型的雙棧系統進行了優化，即雙棧終端同時發起TCP SYN IPv6和TCP SYN IPv4過程。

當IPv6網絡不可用時，優化后的流程如下圖所示：當用戶在規定時間內僅收到IPv4網絡相應，則發起IPv4承載。

當IPv4和IPv6網絡不可用時，優化后的流程如下圖所示：用戶在獲得IPv4和IPv6同時相應是，將發起IPv6承載，并通知IPv4中斷TCP服務。

以上流程來源于RFC6555(Happy Eyeballs : Success with Dual-Stack Hosts)的描述。從上述描述也可以看出，標準規定在IPv6網絡可用狀態時，優先選擇IPv6網絡承載，僅當IPv6網絡不通時，才會選擇IPv4網絡承載。因此對于雙棧用戶訪問IPv4資源的情況，且同時獲得AAAA和A響應時，優先選擇采用IPv6網絡嘗試業務訪問，所以不會直接采用IPv4承載訪問業務。

這樣設計的初衷是為了促進IPv6網絡的發展，另外，對于雙棧用戶，假如要采用IPv4承載，還需要分配IPv4地址，仍然會加大對IPv4的地址壓力，若采用的IPv4地址為私網IPv4，還將會引入NAT444部署來解決地址轉換，業務體驗跟直接采用IPv6承載再經過NAT64訪問IPv4服務器是一致的。因此推薦用戶優先采用IPv6承載方式進行服務而不是優先選擇IPv4承載方式。

原文鏈接：http://blog.csdn.net/hanlijin/article/details/17076067