如果用户想将数据包传送到同一NAT之后的其他客户，如图二所示。防火墙，路由ACL甚至是服务器中的过滤政策通常会阻止外部数据包进入拥有专属源地址的网络。为了回避这种过滤，数据包必须通过LSN，以便它们的源地址可以被转换成一个公共地址，然后再将数据包一起传送到终端。即便数据包不通过LSN到达终端，其NAT资源也会被消耗掉。
图二：
对于这两些问题，我们建议先留出剩下的公共IPv4空间作为ISP共享地址空间。因为地址块可能会被保留供NAT444架构使用，相同的地址可以和RFC1918地址一样，在不同LSN之后使用。但是由于它们不是RFC1918地址，它们不会与任何客户网络的专有地址相冲突。而且，正由于它们不是RFC1918地址，它们也不好被过滤政策阻止;同一LSN后客户间的数据流就不需要 穿越LSN。
还有一种方法可以解决这些问题。使用LSN和CPE NAT之间的公共IPv6地址，如图三所示。源于客户网络的IPv4数据包会被转换成IPv6数据包，以完成CPE NAT到LSN之间的交接，然后再被LSN转换回IPv4数据包。这一架构就是NAT464架构。
CPE NAT外部的IPv6地址和其内部的IPv4地址不会产生冲突。假设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好，其扩展性也不如NAT44。NAT64执行已经得到改进，而且会持续得到改进，但似乎无法像NAT44那样得心应手。
一项名为Dual Stack Lite的解决方案可谓折中之选，该方案利用隧道技术而不是地址家族转换技术，从而消除了NAT464的复杂性。在以后的文章中，我们将为大家介绍此方案。
大规模网络地址转换NAT（LSN）架构的介绍就结束了，希望大家应经理解。
【编辑推荐】
