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