传统NAT，如在讨论前面的文章，已经使用了十五年左右通过私下寻址的设备数量较多，使少量公用IPv4地址的共享。在家庭和小型企业的情况下，通常有外部NAT接口上只是一个单一的公共IPv4地址。公共地址是由宽带服务提供商分配。
当我们接近的公用IPv4地址的枯竭，宽带提供商正在研究如何能继续为他们的客户面向公众的IP地址时，还剩下来伸手，没有IPv4地址。答案似乎相当明显：如果NAT得到了有效的面向供应商，客户优势，这也应该是面向客户的运营商边缘有效。这是大规模NAT（LSN）的基础。
LSN增加了翻译的另一层，使刚刚为私有IPv4地址的NAT CPE的内部使用，他们也可以被用来分配地址的CPE NAT的外部。
图1示出的概念性的一例。服务提供商分配地址了其公共IPv4骨料其LSN设备的“面向Internet”的一面。在每个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（再次端口映射），并且该数据包路由到目的地。Responding packets to 201.15.83.1 are routed to the service provider’s aggregate IPv4 address, then to the appropriate LSN, which translates the destination address back to 172.16.1.1 and forwards the packet to the corresponding CPE NAT which translates the destination address to 10.1.1.1.
从互联网上准确的路由到正确的设备正确的客户网络中的取决于两个因素：
1）会议从客户网络内发起的，从而使CPE NAT和LSN有正确的地址和端口映射;和
2）来自外部的路线视图总是朝向可以被唯一标识的目的地。因此，从公共互联网的数据包可以被路由到服务提供商的唯一的IPv4地址总量;一旦服务提供商网络内，一个更具体的路由被用于将数据包发送到特定的LSN（这通常是在一些边缘或聚集路由器软件处理）。该LSN具有外到内的地址/端口映射，它指向一个特定的CPE NAT，和CPE NAT具有另一个外到内的地址/端口映射，要么需要分组到直接连接的目的地或路由匹配that is unique within the boundaries of that customer’s network.
这种架构NAT444：它从IPv4地址转换成另一个IPv4地址到第三IPv4地址。这种方法是有吸引力的，因为现有CPE NAT的可以在不修改使用。NAT的不在乎自己以外的IPv4地址是公共的还是私有的，所以从CPE NAT的角度来看，没有什么不同。服务供应商部署该架构没有强加给他们的客户提供特殊的设备要求，或要求客户改变现有设备。任何旧的NAT会做。
虽然简单，NAT444也不是没有问题。一个共同的关注不仅是这个架构，但任何LSN解决方案的可扩展性。对于宽带服务供应商，每个客户网络可以代表一个家庭背后的CPE NAT多台设备或者是在小型办公室后面的CPE NAT十几设备。和每一个这种设备可以产生多个应用流。目前还没有足够的生产经验知道的一个LSN能有多少客户网络处理上的界限，无论是在性能方面还是在以一个单一的公共IPv4地址映射蒸的条款。
特别是NAT444的问题是客户的网络和服务供应商使用的私有地址之间的地址重叠的可能性。例如，如果出了LSN和CPE NAT和客户地址他的网络相同的块出来的172.16.0.0/12块的供应商使用的地址，这两个区域之间的独特性丢失的数据包可能被误传。投保客户使用不冲突的地址范围可以为供应商的管理的头痛。
如果客户需要将数据包发送到同一LSN背后的另一个客户，如图2过滤策略中所示的防火墙，路由器ACL，甚至服务器通常阻止网络有私有源地址的数据包外发生与NAT444的另一个问题。为了解决这个问题的数据包必须通过LSN，以便它们的源地址可以被转换成公共地址，然后“发夹”通过LSN到目的地了。LSN资源消耗，即使数据包不会超出LSN的目的地。
提议的解决方案，以这两个问题是预留剩余的公共IPv4空间的块作为“ISP共享地址”的空间。因为地址块将在NAT444架构被保留用于使用时，相同地址可以不同的LSN同样的方式RFC1918地址被用于后面使用。但是，因为它们不是RFC1918地址，它们不会与任何客户网络的私有地址冲突。而且因为它们不是RFC1918地址，它们不会被过滤政策阻止;同样的LSN背后的客户之间的数据包流不必经过LSN。
对这些问题的另一种解决方案是使用LSN和CPE之间的NAT公共IPv6地址，如示于图3的IPv4数据包始发在用户网络中被翻译成IPv6数据包的NAT CPE和LSN之间的跳，然后由LSN转换回IPv4的（与公网地址）。这种架构是NAT464。
有没有对CPE NAT和内侧的IPv4私有地址的外部IPv6地址的地址冲突的机会。并假设CPE NAT转换传入数据包到IPv4地址的内部到本地网络，应该有实现同一LSN后的两个客户之间的沟通没有过滤问题。
NAT464有一个好处，供应商和客户之间的联系是仅支持IPv6，而不是双堆叠，所以最让客户找到足够的IPv4地址的问题就会消失。而且，由于它支持IPv4 over IPv6的，而不是并行支持IPv4和IPv6，它会让我们更接近我们最终想要为：纯IPv6网络。
虽然NAT464简化了LSN和CPE的NAT之间的中间地带的事情，它是为LSN和CPE NAT的自己更成问题。最明显的问题是，无论这些设备现在必须NAT64 - 也就是说，他们必须在两种版本的协议之间的转换。极少数目前CPE的NAT支持NAT64，所以采用这种解决方案提供商都面临着要求他们的客户改变他们的设备：管理和客户关系头痛大多数供应商宁愿避免。
更重要的是，家庭地址之间的转换比单一地址家族中简单的翻译，这反映一个事实，即实现NAT64（以前称为NAT-PT）既不执行，以及规模也不及NAT44更加复杂。NAT64的实现得到了改善，将继续改善，但它是不可能的，他们将永远被视为有效的NAT44。
一个充满希望的妥协是一种称为双栈精简版的解决方案，它通过使用隧道而不是地址族转换消除一些NAT464的复杂性。我会在接下来的文章中涉及DS-精简版。