中所讨论的传统NAT前一篇文章，已经使用了15年左右，使得大量的私有寻址设备能够共享少量的公共IPv4地址。在家庭和小型企业的情况下，通常在外部NAT接口上只有一个公共IPv4地址。该公共地址是由宽带服务提供商分配的。
当我们接近的公用IPv4地址的枯竭，宽带提供商正在研究如何能继续为他们的客户面向公众的IP地址时，还剩下来伸手，没有IPv4地址。答案似乎相当明显：如果NAT得到了有效的面向供应商，客户优势，这也应该是面向客户的运营商边缘有效。这是大规模NAT（LSN）的基础。
LSN添加了另一层转换，因此就像私有IPv4地址在CPE NAT内部使用一样，它们也可以被用来分配地址给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 NATs可以使用不需要修改。NATs并不关心他们外部的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架构中，相同的地址可以在不同的LSNs后面使用，就像使用RFC1918地址一样。但是因为它们不是RFC1918地址，所以它们不会与任何客户网络中的私有地址发生冲突。因为它们不是RFC1918地址，所以不会被过滤策略阻止;同一LSN背后的客户之间的包流不必经过LSN。
对这些问题的另一种解决方案是使用LSN和CPE之间的NAT公共IPv6地址，如示于图3的IPv4数据包始发在用户网络中被翻译成IPv6数据包的NAT CPE和LSN之间的跳，然后由LSN转换回IPv4的（与公网地址）。这种架构是NAT464。
CPE NAT外部的IPv6地址和内部的IPv4私有地址之间没有地址冲突的机会。并且假设CPE NAT将传入的数据包转换为本地网络内部的IPv4地址，那么在同一个LSN背后的两个客户之间应该不会存在影响通信的过滤问题。
NAT464还有一个额外的优势，即供应商和客户之间的链接仅为IPv6，而不是双层叠的，因此为客户找到足够的IPv4地址的问题就不存在了。而且，因为它支持IPv6上的IPv4，而不是并行支持IPv4和IPv6，它使我们更接近最终的目标:一个纯粹的IPv6网络。
虽然NAT464简化了LSN和CPE的NAT之间的中间地带的事情，它是为LSN和CPE NAT的自己更成问题。最明显的问题是，无论这些设备现在必须NAT64 - 也就是说，他们必须在两种版本的协议之间的转换。极少数目前CPE的NAT支持NAT64，所以采用这种解决方案提供商都面临着要求他们的客户改变他们的设备：管理和客户关系头痛大多数供应商宁愿避免。
更重要的是，地址家族之间的转换比单一地址家族内部的简单转换要复杂得多，这反映在NAT64实现(以前称为NAT-PT)的性能和规模都不如NAT44。NAT64实现已经改进，并将继续改进，但它们不太可能像NAT44那样高效。
一个充满希望的妥协是一种称为双栈精简版的解决方案，它通过使用隧道而不是地址族转换消除一些NAT464的复杂性。我会在接下来的文章中涉及DS-精简版。