一、概述
新的IPv6網(wǎng)絡(luò)的部署已經(jīng)在全球范圍內(nèi)展開(kāi)，在此過(guò)程中我們不可能立即放棄原有的已經(jīng)成熟的IPv4網(wǎng)絡(luò)。在將來(lái)很長(zhǎng)一段時(shí)間之內(nèi)，兩種網(wǎng)絡(luò)必然是共存的，我們現(xiàn)在需要考慮的就是我們?nèi)绾文軌蚱椒�(wěn)地從IPv4網(wǎng)絡(luò)過(guò)渡到IPv6網(wǎng)絡(luò)。
網(wǎng)絡(luò)地址和協(xié)議轉(zhuǎn)換(NAT-PT)就是我們的選擇之一，它能夠解決我們?cè)谶^(guò)渡過(guò)程中所能碰到的一些問(wèn)題。
二、NAT-PT介紹
NAT-PT是一種純IPv6節(jié)點(diǎn)和IPv4節(jié)點(diǎn)間的互通方式，所有包括地址、協(xié)議在內(nèi)的轉(zhuǎn)換工作都由網(wǎng)絡(luò)設(shè)備來(lái)完成。支持NAT-PT的網(wǎng)關(guān)路由器應(yīng)具有IPv4地址池，在從IPv6向IPv4域中轉(zhuǎn)發(fā)包時(shí)使用,地址池中的地址是用來(lái)轉(zhuǎn)換IPv6報(bào)文中的源地址的。此外網(wǎng)關(guān)路由器需要DNS-ALG和FTP-ALG這兩種常用的應(yīng)用層網(wǎng)關(guān)的支持，在IPv6節(jié)點(diǎn)訪問(wèn)IPv4節(jié)點(diǎn)時(shí)發(fā)揮作用。如果沒(méi)有DNS-ALG的支持，只能實(shí)現(xiàn)由IPv6節(jié)點(diǎn)發(fā)起的與IPv4節(jié)點(diǎn)之間的通信，反之則不行。如果沒(méi)有FTP-ALG的支持，IPv4網(wǎng)絡(luò)中的主機(jī)將不能用FTP軟件從IPv6網(wǎng)絡(luò)中的服務(wù)器上下載文件或者上傳文件，反之亦然。
采用NAT-PT方式進(jìn)行過(guò)渡的優(yōu)點(diǎn)是不需要進(jìn)行IPv4，IPv6節(jié)點(diǎn)的升級(jí)改造，缺點(diǎn)是IPv4節(jié)點(diǎn)訪問(wèn)IPv6節(jié)點(diǎn)的實(shí)現(xiàn)方法比較復(fù)雜，網(wǎng)絡(luò)設(shè)備進(jìn)行協(xié)議轉(zhuǎn)換、地址轉(zhuǎn)換的處理開(kāi)銷(xiāo)較大，一般在其他互通方式無(wú)法使用的情況下使用。
三、SIIT介紹
在NAT-PT的實(shí)現(xiàn)中最重要的一部分就是協(xié)議部分的轉(zhuǎn)換算法，也就是無(wú)狀態(tài)IP/ICMP轉(zhuǎn)換算法(SIIT)。轉(zhuǎn)換方法包括如下幾個(gè)大的方面：
IPv4－>IPv6：
¨ IPv4頭部到IPv6頭部的轉(zhuǎn)換
¨ IPv4 UDP頭部的轉(zhuǎn)換
¨ IPv4的ICMP頭部轉(zhuǎn)換為IPv6的ICMP頭部
¨ IPv4的ICMP錯(cuò)誤消息轉(zhuǎn)換為IPv6的ICMP錯(cuò)誤消息
IPv6－>IPv4：
¨ IPv6頭部到IPv4頭部的轉(zhuǎn)換
¨ IPv4的ICMP頭部轉(zhuǎn)換為IPv6的ICMP頭部
¨ IPv4的ICMP錯(cuò)誤消息轉(zhuǎn)換為IPv6的ICMP錯(cuò)誤消息
上述轉(zhuǎn)換中，IPv4頭部和IPv6頭部的相互轉(zhuǎn)換比較簡(jiǎn)單，請(qǐng)參看RFC2765。下面重點(diǎn)描述一下IPv4－>IPv6轉(zhuǎn)換過(guò)程中UDP頭部的轉(zhuǎn)換以及ICMP報(bào)文的轉(zhuǎn)換。
3.1、IPv4報(bào)文中UDP頭部的轉(zhuǎn)換
在IPv4報(bào)文中，UDP頭部校驗(yàn)和可以不填寫(xiě),即UDP頭部校驗(yàn)和可以是0。但是在IPv6協(xié)議中，IPv6頭部沒(méi)有校驗(yàn)和，為了保證UDP數(shù)據(jù)包的正確性，UDP頭部中校驗(yàn)和字段必須填寫(xiě)。
如果一個(gè)UDP包被分片，但是UDP頭部的校驗(yàn)和為0，作為一個(gè)無(wú)狀態(tài)的轉(zhuǎn)換設(shè)備來(lái)說(shuō)，它不可能計(jì)算出一個(gè)有效的校驗(yàn)和。不過(guò)，我們認(rèn)為這種情況是惡意的攻擊。當(dāng)轉(zhuǎn)換設(shè)備收到這種報(bào)文的時(shí)候，轉(zhuǎn)換設(shè)備應(yīng)該丟棄該報(bào)文并生成一個(gè)系統(tǒng)相關(guān)事件（事件至少需要記錄IP地址和端口號(hào)）。
如果轉(zhuǎn)換設(shè)備收到一個(gè)未分片的IPv4 UDP報(bào)文并且校驗(yàn)和為0，轉(zhuǎn)換設(shè)備必須計(jì)算UDP校驗(yàn)和，而且轉(zhuǎn)換設(shè)備應(yīng)該記錄有多少個(gè)這樣的UDP校驗(yàn)和被計(jì)算。
3.2、ICMP頭部的轉(zhuǎn)換
在IPv6中，ICMP的校驗(yàn)和計(jì)算包含一個(gè)偽頭部（源地址，目的地址，協(xié)議號(hào)，ICMP包長(zhǎng)度），而在IPv4中，ICMP的頭部校驗(yàn)和的計(jì)算不包含偽頭部。所以，所有經(jīng)過(guò)轉(zhuǎn)換設(shè)備的ICMP的校驗(yàn)和都需要重新計(jì)算。
說(shuō)到ICMP頭部的轉(zhuǎn)換，除了校驗(yàn)和之外，剩下的就是ICMP的Type值和Code值需要轉(zhuǎn)換，下面給出一個(gè)轉(zhuǎn)換表(表一)，請(qǐng)大家參考。
3.3、ICMP錯(cuò)誤消息的轉(zhuǎn)換
對(duì)于ICMP錯(cuò)誤消息，它頭部中的Type值和Code值的轉(zhuǎn)換也需要參照(表一)進(jìn)行轉(zhuǎn)換。
ICMP錯(cuò)誤消息中包含了IP頭部，錯(cuò)誤消息中的IP頭部也需要被轉(zhuǎn)換，就像普通的IP頭部被轉(zhuǎn)換一樣。轉(zhuǎn)換錯(cuò)誤消息中的IP頭部可能導(dǎo)致數(shù)據(jù)包的長(zhǎng)度變化，那么正常的IPv6頭部的有效載荷長(zhǎng)度也需要更新。如圖一所示：
ICMP錯(cuò)誤消息中的IP頭部的轉(zhuǎn)換能夠第歸調(diào)用轉(zhuǎn)換外部IP頭部的轉(zhuǎn)換函數(shù)。只不過(guò)轉(zhuǎn)換之前，內(nèi)部的IP頭部中，源地址、目的地址和上層協(xié)議(TCP,UDP)的源端口號(hào)、目的端口號(hào)需要互換。只有這樣才能保證ICMP ERROR報(bào)文的正確轉(zhuǎn)換。
四、應(yīng)用層網(wǎng)關(guān)(ALG)
4.1、DNS-ALG
在組網(wǎng)的時(shí)候，如果處于V6網(wǎng)絡(luò)的主機(jī)需要連接到V4網(wǎng)絡(luò)中的主機(jī)，V6主機(jī)可以認(rèn)為V4主機(jī)的所對(duì)應(yīng)的IPv6地址為NATPT前綴+IPv4主機(jī)地址。如：V4主機(jī)地址為10.18.34.1，NATPT設(shè)備設(shè)定的前綴為2222::/64，則V4主機(jī)對(duì)應(yīng)的IPv6地址就是2222::10.18.34.1或2222::0a12:2201。
但是當(dāng)V4網(wǎng)絡(luò)中的主機(jī)需要訪問(wèn)V6網(wǎng)絡(luò)中的主機(jī)的時(shí)候就不能按照這種方法來(lái)做，V4主機(jī)可以按照V6主機(jī)所對(duì)應(yīng)的域名來(lái)訪問(wèn)，這就需要用到DNS-ALG功能。如（圖二）所示：
V4端主機(jī)10.18.34.117需要訪問(wèn)V6端主機(jī)2000::1，V4主機(jī)所對(duì)應(yīng)的域名為www.ipv4.com.cn，V6主機(jī)所對(duì)應(yīng)的域名為www.ipv6.com.cn。
首先V4主機(jī)發(fā)送DNS請(qǐng)求1給它的DNS服務(wù)器，請(qǐng)求www.ipv6.com.cn這個(gè)域名所對(duì)應(yīng)的IPv4地址，V4的DNS服務(wù)器發(fā)現(xiàn)沒(méi)有這個(gè)資源記錄，于是它轉(zhuǎn)發(fā)這個(gè)DNS請(qǐng)求給V6的DNS服務(wù)器。需要注意到，NATPT設(shè)備上必須配置兩個(gè)DNS服務(wù)器的地址映射關(guān)系，如：10.18.34.252 => 2000::2，即V6的DNS服務(wù)器所對(duì)應(yīng)的IPv4地址為10.18.34.252。
NATPT發(fā)送經(jīng)過(guò)轉(zhuǎn)換的DNS請(qǐng)求2給V6的DNS服務(wù)器。
V6的DNS服務(wù)器收到經(jīng)過(guò)NATPT設(shè)備轉(zhuǎn)換之后的DNS請(qǐng)求之后，它作出響應(yīng)，發(fā)送DNS應(yīng)答3給V4的DNS服務(wù)器。NATPT在收到應(yīng)答3之后，對(duì)之進(jìn)行轉(zhuǎn)換。因?yàn)?A >www.ipv6.com.cn這個(gè)域名對(duì)應(yīng)的IPv6地址為2000::1，所以應(yīng)答報(bào)文中的資源記錄為AAAA，地址為2000::1，經(jīng)過(guò)轉(zhuǎn)換之后，資源記錄變?yōu)锳，2000::1這個(gè)IPv6地址所對(duì)應(yīng)的IPv4地址就從地址池中獲取。假如獲取的IPv4地址為10.18.34.11，則在地址映射表中增加了一條新的地址映射表項(xiàng)2000::1=>10.18.34.11，此記錄為一動(dòng)態(tài)記錄，超時(shí)之后將被自動(dòng)刪除。
NATPT設(shè)備發(fā)送經(jīng)過(guò)轉(zhuǎn)換之后的DNS應(yīng)答報(bào)文給V4的DNS服務(wù)器。
V4的DNS服務(wù)器收到應(yīng)答報(bào)文之后在它的DNS緩存中增加一條記錄，表明www.ipv6.com.cn這個(gè)域名所對(duì)應(yīng)的IPv4地址為10.18.34.11。在此之后，IPv4主機(jī)要和IPv6主機(jī)進(jìn)行通信，只需要訪問(wèn)IPv6主機(jī)的域名即可。
從V6端訪問(wèn)V4端主機(jī)的域名也按照同樣的步驟。
4.2、FTP-ALG
當(dāng)IPv4網(wǎng)絡(luò)中的用戶需要訪問(wèn)IPv6網(wǎng)絡(luò)中的FTP服務(wù)器的時(shí)候，對(duì)應(yīng)的FTP請(qǐng)求報(bào)文和相應(yīng)報(bào)文需要進(jìn)行轉(zhuǎn)換，F(xiàn)TP-ALG就是解決此問(wèn)題的。一般來(lái)說(shuō)，我們只需要對(duì)目的端口或源端口為21的TCP報(bào)文進(jìn)行轉(zhuǎn)換，因?yàn)檫@些報(bào)文屬于FTP的控制報(bào)文，只有FTP控制報(bào)文中包含了地址和端口的信息。我們只需要轉(zhuǎn)換這些地址和端口。
FTP的請(qǐng)求分很多類(lèi)型，如PORT 、PASV、EPRT、EPSV等等。對(duì)于大多數(shù)支持IPv4的FTP客戶端來(lái)說(shuō)，它們一般都只支持PORT和PASV請(qǐng)求模式，經(jīng)過(guò)升級(jí)之后可能支持EPRT和EPSV請(qǐng)求模式。但是現(xiàn)在支持IPv6的FTP客戶端一般是支持EPRT和EPSV這兩種請(qǐng)求模式。
從上面的描述中我們可以知道，對(duì)于IPv4網(wǎng)絡(luò)中的FTP客戶端來(lái)說(shuō)，它們即可以支持PORT和PASV請(qǐng)求模式也可以支持EPRT和EPSV請(qǐng)求模式。對(duì)于IPv6網(wǎng)絡(luò)中的FTP客戶端來(lái)說(shuō)，它們肯定都支持EPRT和EPSV請(qǐng)求模式。但是，這時(shí)將會(huì)出現(xiàn)一個(gè)問(wèn)題，如（圖三）所示：
IPv4的FTP請(qǐng)求轉(zhuǎn)換成IPv6的FTP請(qǐng)求是二對(duì)一的關(guān)系，反之是一對(duì)二的關(guān)系。也就是說(shuō)，我們現(xiàn)在需要考慮，在轉(zhuǎn)換IPv6側(cè)的FTP請(qǐng)求的時(shí)候我們應(yīng)該怎么轉(zhuǎn)換呢？?jī)煞N都可以！但是兩種都有不足的地方。
1、EPRT－>PORT EPSV－>PASV
這種轉(zhuǎn)換中，F(xiàn)TP-ALG不能轉(zhuǎn)換“ EPSVALL“這種指令。這樣將導(dǎo)致FTP Server返回一個(gè)錯(cuò)誤信息。
2、EPRT－>EPRT EPSV－>EPSV
這種轉(zhuǎn)換要求IPv4側(cè)的主機(jī)升級(jí)FTP軟件以支持EPRT和EPSV兩種請(qǐng)求模式。
鑒于這種情況，我們建議在缺省情況下采用第一種轉(zhuǎn)換方式，因?yàn)榈谝环N轉(zhuǎn)換方式不需要IPv4側(cè)的主機(jī)進(jìn)行升級(jí)，雖然有個(gè)指令不能轉(zhuǎn)換，但是我們認(rèn)為該指令出現(xiàn)的幾率不是很頻繁，就算出現(xiàn)該指令，大多數(shù)情況下我們的FTP連接還是能夠建立起來(lái)，不影響文件的傳輸。我們還建議在NATPT轉(zhuǎn)換設(shè)備上設(shè)置一條命令，把IPv6側(cè)的FTP請(qǐng)求的轉(zhuǎn)換方式當(dāng)作可配置的。
在經(jīng)過(guò)FTP-ALG模塊轉(zhuǎn)換之后FTP報(bào)文的數(shù)據(jù)部分長(zhǎng)度可能發(fā)生變化，此時(shí)TCP頭部的校驗(yàn)和需要重新計(jì)算，同時(shí)TCP包中的Seq Number和Ack Number需要調(diào)整。
六、NATPT設(shè)備應(yīng)用范圍的考慮
NATPT只是作為IPv4網(wǎng)絡(luò)向IPv6網(wǎng)絡(luò)過(guò)渡的時(shí)候采用的一種手段，NATPT自身有一定的局限性，由于轉(zhuǎn)換相當(dāng)耗費(fèi)系統(tǒng)資源和時(shí)間，所以NATPT設(shè)備注定不能作為核心的設(shè)備，只能用于邊緣協(xié)議和地址的轉(zhuǎn)換。而且NATPT對(duì)于系統(tǒng)安全不能夠很好的支持，而系統(tǒng)安全這一點(diǎn)對(duì)于下一代網(wǎng)絡(luò)來(lái)將非常重要。所以網(wǎng)絡(luò)中采用NATPT設(shè)備只能暫時(shí)作為一種解決問(wèn)題的方案。
七、總結(jié)
本文簡(jiǎn)單地描述了NAT-PT轉(zhuǎn)換中所需要注意的幾個(gè)方面，但要從真正實(shí)現(xiàn)NAT-PT協(xié)議的角度來(lái)講，這些遠(yuǎn)遠(yuǎn)不夠。武漢郵科院烽火網(wǎng)絡(luò)公司的Fengine系列路由器已經(jīng)實(shí)現(xiàn)了NATPT轉(zhuǎn)換，包括DNS-ALG、FTP-ALG、SIP-ALG等。能夠?yàn)橛脩籼峁⿵腎Pv4到IPv6網(wǎng)絡(luò)平滑進(jìn)行過(guò)渡的解決方案。眾所周知，在進(jìn)行NATPT轉(zhuǎn)換之后，系統(tǒng)的性能將大大降低，但是烽火網(wǎng)絡(luò)公司的R8000系列路由器能夠?qū)崿F(xiàn)硬件的轉(zhuǎn)換，大大提高了NATPT的轉(zhuǎn)換性能和可靠性。
參考資料：
[FTP-IPV6] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998.
[DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999.
[NAT-PT] George Tsirtsis., "Network Address Translation - Protocol Translation", RFC 2766, February 2000.
[SIIT] Nordmark, E., "Stateless IP/ICMP Translator (SIIT)", RFC 2765, February 2000.
[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
