在IPv4地址池逐渐耗尽的时候，要想创建双协议堆栈网络，重点应放在宽带服务供应商身上，因为尽管IPv4地址池即将耗尽，他们仍然要继续为大量新客户提供地址。下列两种原因导致IPV6技术的推广心有余而力不足。
几乎公共互联网上所有可用服务都仅限IPv4。
虽然新技术的替换很快，但是许多宽带用户运行的操作系统要么不支持IPV6，要么在对IPV6的支持方面还存在缺陷。
LSN(大规模NAT)是对运营级NAT(CGN)更新更准确的称呼。它是位于服务供应商网络NAT，一般属于路由提供的一种服务，而不是一个单独的设备;LSN是否能达到运营级的性能标准和规模，还要拭目以待。
NAT444是在运营商和客户之间提供IPv4地址的最简单的架构。
客户端网络中已有的NAT也可以被利用，而相同的NAT44基本功能也会在运营商LSN中得到利用。但是，如我们在前面的文章中所提到的，在客户端连接上使用RFC1918地址需要考虑到一些问题，即客户端RFC1918地址和运营商指定的RFC1918地址之间的覆盖问题，以及相同LSN后客户之间的寻址问题。此前我们建议保留一些IPv4地址作为共享地址，以此预防RFC1918地址的覆盖问题，而且也可以避免客户之间的地址过滤问题。尽管如此，这也只是我们给出的建议，仅作参考，而目前尚未有人预留IPv4地址块作为共享地址。
而使用IPV6地址也是一种可行的方法。IPV6地址不仅可以解决共享地址能够解决的问题，而且还能为那些需要分配和管理IPv4地址与IPV6地址的运营商减轻负担。这一方法还能让运营商更接近自己的理想：一个纯粹的IPV6架构。而NAT464架构的不利面在于，CPE NAT 和LSN都必须进行IPv4与IPV6的转换，这种转换比较复杂，而且涉及很多性能，规模方面的问题。
Dual-Stack Lite是一种前景比较好的方法，因为它很好地利用了NAT464的优势又巧妙地避免了其不足：它在运营商和客户之间只使用IPV6链接，但是却不使用NAT64转换。当客户端网络的设备将IPv4数据包发送到外部终端时，IPv4数据包会被装载到一个IPV6数据包中，然后再将IPV6数据包发送到运营商网络。在LSN中，该数据包又被解开，以NAT44的方式执行。此隧道技术远比转换技术简单，因此性能和复杂性的顾虑全部被打消。
这样还不够，还要在LSN的NAT44中添加一项额外要素。
如果在对外数据包上执行内部IPv4源地址到外部IPv4源地址的简单映射，LSN可能无法区分不同客户网络中覆盖的RFC1918 IPv4地址。因此，还要为地址映射添加一项额外要素：要把用于封装的IPV6数据包的源地址添加到内部IPv4源地址。因为IPV6地址对于每个客户而言都是独一无二的，所以IPV6源地址+IPv4源地址+端口以后，就能使映射清楚明确。当作为响应的外部IPv4数据包被接收后，其IPv4终端地址和端口就可以与映射表中基于IPV6地址的NAT后的指定客户准确匹配;该数据包的IPv4终端地址和端口可以被映射到内部IPv4终端地址和端口，再将映射的IPV6地址作为IPV6终端地址将其包装成IPV6数据包，转发给客户。
来源：ZDNET网络频道
