通信網(wǎng)banner.jpg)
在IPv4地址池逐漸耗盡的時(shí)候，要想創(chuàng)建雙協(xié)議堆棧網(wǎng)絡(luò)，重點(diǎn)應(yīng)放在寬帶服務(wù)供應(yīng)商身上，因?yàn)楸M管IPv4地址池即將耗盡，他們?nèi)匀灰^續(xù)為大量新客戶提供地址。下列兩種原因?qū)е翴PV6技術(shù)的推廣心有余而力不足。
幾乎公共互聯(lián)網(wǎng)上所有可用服務(wù)都僅限IPv4。
雖然新技術(shù)的替換很快，但是許多寬帶用戶運(yùn)行的操作系統(tǒng)要么不支持IPV6，要么在對IPV6的支持方面還存在缺陷。
LSN(大規(guī)模NAT)是對運(yùn)營級NAT(CGN)更新更準(zhǔn)確的稱呼。它是位于服務(wù)供應(yīng)商網(wǎng)絡(luò)NAT，一般屬于路由提供的一種服務(wù)，而不是一個(gè)單獨(dú)的設(shè)備;LSN是否能達(dá)到運(yùn)營級的性能標(biāo)準(zhǔn)和規(guī)模，還要拭目以待。
NAT444是在運(yùn)營商和客戶之間提供IPv4地址的最簡單的架構(gòu)。
客戶端網(wǎng)絡(luò)中已有的NAT也可以被利用，而相同的NAT44基本功能也會在運(yùn)營商LSN中得到利用。但是，如我們在前面的文章中所提到的，在客戶端連接上使用RFC1918地址需要考慮到一些問題，即客戶端RFC1918地址和運(yùn)營商指定的RFC1918地址之間的覆蓋問題，以及相同LSN后客戶之間的尋址問題。此前我們建議保留一些IPv4地址作為共享地址，以此預(yù)防RFC1918地址的覆蓋問題，而且也可以避免客戶之間的地址過濾問題。盡管如此，這也只是我們給出的建議，僅作參考，而目前尚未有人預(yù)留IPv4地址塊作為共享地址。
而使用IPV6地址也是一種可行的方法。IPV6地址不僅可以解決共享地址能夠解決的問題，而且還能為那些需要分配和管理IPv4地址與IPV6地址的運(yùn)營商減輕負(fù)擔(dān)。這一方法還能讓運(yùn)營商更接近自己的理想：一個(gè)純粹的IPV6架構(gòu)。而NAT464架構(gòu)的不利面在于，CPE NAT 和LSN都必須進(jìn)行IPv4與IPV6的轉(zhuǎn)換，這種轉(zhuǎn)換比較復(fù)雜，而且涉及很多性能，規(guī)模方面的問題。
Dual-Stack Lite是一種前景比較好的方法，因?yàn)樗芎玫乩昧薔AT464的優(yōu)勢又巧妙地避免了其不足：它在運(yùn)營商和客戶之間只使用IPV6鏈接，但是卻不使用NAT64轉(zhuǎn)換。當(dāng)客戶端網(wǎng)絡(luò)的設(shè)備將IPv4數(shù)據(jù)包發(fā)送到外部終端時(shí)，IPv4數(shù)據(jù)包會被裝載到一個(gè)IPV6數(shù)據(jù)包中，然后再將IPV6數(shù)據(jù)包發(fā)送到運(yùn)營商網(wǎng)絡(luò)。在LSN中，該數(shù)據(jù)包又被解開，以NAT44的方式執(zhí)行。此隧道技術(shù)遠(yuǎn)比轉(zhuǎn)換技術(shù)簡單，因此性能和復(fù)雜性的顧慮全部被打消。
這樣還不夠，還要在LSN的NAT44中添加一項(xiàng)額外要素。
如果在對外數(shù)據(jù)包上執(zhí)行內(nèi)部IPv4源地址到外部IPv4源地址的簡單映射，LSN可能無法區(qū)分不同客戶網(wǎng)絡(luò)中覆蓋的RFC1918 IPv4地址。因此，還要為地址映射添加一項(xiàng)額外要素：要把用于封裝的IPV6數(shù)據(jù)包的源地址添加到內(nèi)部IPv4源地址。因?yàn)镮PV6地址對于每個(gè)客戶而言都是獨(dú)一無二的，所以IPV6源地址+IPv4源地址+端口以后，就能使映射清楚明確。當(dāng)作為響應(yīng)的外部IPv4數(shù)據(jù)包被接收后，其IPv4終端地址和端口就可以與映射表中基于IPV6地址的NAT后的指定客戶準(zhǔn)確匹配;該數(shù)據(jù)包的IPv4終端地址和端口可以被映射到內(nèi)部IPv4終端地址和端口，再將映射的IPV6地址作為IPV6終端地址將其包裝成IPV6數(shù)據(jù)包，轉(zhuǎn)發(fā)給客戶。
來源：ZDNET網(wǎng)絡(luò)頻道
