傳統(tǒng)的NAT已經(jīng)使用了15年左右，我們主要通過它為大量專屬設(shè)備提供少量公共IPv4地址的共享。就家庭用戶和小型辦公場所而言，其NAT界面外通常只有一個單獨的公共IPv4地址。這一公共地址當(dāng)然是由寬帶服務(wù)供應(yīng)商提供。
由于IPv4地址即將耗盡，寬帶服務(wù)供應(yīng)商現(xiàn)在正在想辦法解決如何繼續(xù)為其新客戶提供IP地址的問題。問題的答案似乎很明顯：如果NAT在服務(wù)供應(yīng)商面對的客戶端有效，那么它對于客戶端所面對的服務(wù)商也應(yīng)該同樣有效。這也是大規(guī)模NAT(LSN)的基礎(chǔ)。
LSN添加了新的轉(zhuǎn)換層，因此，就如同IPv4地址用于CPE NAT內(nèi)部一樣，它們也可以被用來向CPE NAT外部指定地址。
圖一展示了一個概念圖。服務(wù)供應(yīng)商在其公共IPv4外指定的地址數(shù)達到了LSN設(shè)備聯(lián)網(wǎng)接口的數(shù)量。在LSN與客戶相連的一端，一個專屬IPv4地址塊外有一地址——172.16.0.0/12——它被指定到與CPE NAT相連的每一個界面。然后，每個客戶可以使用另一個IPv4地址塊——通常是10.0.0.0/8——來為其網(wǎng)絡(luò)中的所有設(shè)備確立地址。
圖一：
客戶端網(wǎng)絡(luò)中的設(shè)備有可能向帶有10.1.1.1源地址的互聯(lián)網(wǎng) 終端發(fā)送數(shù)據(jù)包;而后，CPE NAT會通過附帶的端口映射將源地址轉(zhuǎn)換成類似172.16.1.1的地址。在LSN中，源地址會被轉(zhuǎn)換成公共IPv4地址——201.15.83.1，且其數(shù)據(jù)包會被發(fā)送到終端。與201.15.83.1響應(yīng)的數(shù)據(jù)包會被發(fā)送到服務(wù)供應(yīng)商的IPv4地址集，然后再發(fā)送到合適的LSN，而后NAT會將該終端地址轉(zhuǎn)換成172.16.1.1，再把數(shù)據(jù)包轉(zhuǎn)發(fā)給對應(yīng)的CPE NAT，后者會將終端地址轉(zhuǎn)換成10.1.1.1。
要實現(xiàn)互聯(lián)網(wǎng) 到正確客戶網(wǎng)絡(luò)，再到準(zhǔn)確設(shè)備的傳輸，取決于兩個條件：
1. 對話由客戶端網(wǎng)絡(luò)發(fā)起，因此CPE NAT和LSN才能獲取準(zhǔn)確的地址和端口映射;
2. 外部路由圖總是指向容易被識別的終端。因此，來自公共互聯(lián)網(wǎng) 的數(shù)據(jù)包可以被傳送到服務(wù)供應(yīng)商醒目的IPv4地址集;一旦數(shù)據(jù)包到達服務(wù)供應(yīng)商的網(wǎng)絡(luò)，便會有一個更為明確的路由將數(shù)據(jù)包發(fā)送到特定的LSN。LSN擁有從外之內(nèi)的地址/端口映射，該映射指向一個特定的CPE NAT，而CPE NAT又擁有另一個從一個從外之內(nèi)的地址/端口映射，可以將數(shù)據(jù)包發(fā)送到與之直接相連的終端，或是為數(shù)據(jù)包提供一條在客戶網(wǎng)絡(luò)邊界里的特殊路由。
這一架構(gòu)是一個NAT444架構(gòu)：它將IPv4地址轉(zhuǎn)換成另一個IPv4地址，再轉(zhuǎn)換成第三個IPv4地址。這個方法之所以吸引人是因為可以在不更改現(xiàn)有CPE NAT的情況下，對其進行利用。而NAT不在乎其外部IPv4地址是公共的還是私有的，因此，對于CPE NAT而言，一切沒什么不同。服務(wù)供應(yīng)商部署該架構(gòu)的時候，不需要對客戶的設(shè)備提出特殊要求，也不需要更改其設(shè)備，任何傳統(tǒng)NAT都可以使用。
盡管NAT444很簡單，但也不是一勞永逸。任何架構(gòu)，當(dāng)然也包括LSN在內(nèi)，可擴展性是我們經(jīng)常顧慮的問題。對于寬帶服務(wù)供應(yīng)商而言，每個客戶網(wǎng)絡(luò)都代表著其CPE NAT背后的若干設(shè)備。而每個設(shè)備又能生成多個應(yīng)用數(shù)據(jù)流。現(xiàn)在，我們還不知道一個單獨的LSN究竟能處理多少客戶網(wǎng)絡(luò)，也不知道公共IPv4地址的性能如何。
NAT444有可能出現(xiàn)地址重疊問題，這種重疊發(fā)生在客戶網(wǎng)絡(luò)和服務(wù)供應(yīng)商使用的私有地址之間。例如，如果服務(wù)供應(yīng)商在LSN和CPE NAT之間，使用172.16.0.0/12地址塊以外的地址，而客戶也使用相同的地址，那么兩者之間的唯一性就被破壞，這可能導(dǎo)致數(shù)據(jù)包誤傳。要確�？蛻羰褂玫牡刂贩秶c服務(wù)供應(yīng)商所使用的不沖突。
如果用戶想將數(shù)據(jù)包傳送到同一NAT之后的其他客戶，如圖二所示。防火墻，路由ACL甚至是服務(wù)器中的過濾政策通常會阻止外部數(shù)據(jù)包進入擁有專屬源地址的網(wǎng)絡(luò)。為了回避這種過濾，數(shù)據(jù)包必須通過LSN，以便它們的源地址可以被轉(zhuǎn)換成一個公共地址，然后再將數(shù)據(jù)包一起傳送到終端。即便數(shù)據(jù)包不通過LSN到達終端，其NAT資源也會被消耗掉。
圖二：
對于這兩些問題，我們建議先留出剩下的公共IPv4空間作為ISP共享地址空間。因為地址塊可能會被保留供NAT444架構(gòu)使用，相同的地址可以和RFC1918地址一樣，在不同LSN之后使用。但是由于它們不是RFC1918地址，它們不會與任何客戶網(wǎng)絡(luò)的專有地址相沖突。而且，正由于它們不是RFC1918地址，它們也不好被過濾政策阻止;同一LSN后客戶間的數(shù)據(jù)流就不需要 穿越LSN。
還有一種方法可以解決這些問題。使用LSN和CPE NAT之間的公共IPv6地址，如圖三所示。源于客戶網(wǎng)絡(luò)的IPv4數(shù)
[1] [2] 下一頁
