IPv6过渡方案-DS-lite

IPv4地址耗尽后轻量级的双栈宽带部署

摘 要

在过去的十几年中人们一直认为IPv6过渡会基于双栈模型，在耗尽IPv4资源之前大部分方案都会按这种方式对报文进行转换。

但它并没有发生，而如果没有大规模的IPv6部署，IANA的空闲地址池即将耗尽。

本文修正了双栈模型，并引入了轻量级的双栈模型技术，以在IPv6部署的问题上更好地平衡花费和利益之间的关系。轻量级的双栈模型为两种不同的协议间架起了一座桥梁，为因特网提供了在IANA IPv4地址池耗尽后继续前进的道路。

第一章引言

本文陈述了关于IPv4地址耗尽后IP部署问题的一些观点，以及一些必要的实现的技术。这些观点仅仅表达了作者的一些意见，并不表示Comcast公司会部署它或者Cisco公司会实现这项技术。

1.1 规定的语言

在本篇文章中的关键词如“必须”，“必须不”，“要求”，“会”，“不会”，“应该”，“不应该”，“推荐”，“可能”和“可选的”应该按照RFC2119所描述的去理解。

1.2 术语

本文将区分具有双栈能力和提供了双栈能力设备之间的区别。前者是指从网络层到应用层，都实现了IPv4和IPv6的设备，而后者是指此设备在它的接口中同时拥有IPv4地址和IPv6地址。通过进一步区分直接由服务提供者提供的接口和用户提供的接口之间的区别，本文将进一步提炼双栈这个概念。

1.3 IPv4地址比预期更早被耗尽

IANA空闲地址池（即未被使用的地址池）中的全球公共IPv4地址消耗的速度比几年前预期要快，现的的模型显示IPv4地址可能在2010年或者2011年被耗尽（更多细节请参考http://IPv4.potaroo.net）。这些预测是基于未来地址的消耗速度和今天的速度相似，通过观察近期的地址消耗图可以预测未来的地址消耗趋势。当然，我们不考虑当面临着地址迫切的紧缺时，人们会某种采取大型的IP技术部署方案或以其它方式来缓解地址的紧缺。

预测IANA空闲地址池的准确耗尽时间超出了本文的范围，但是从中却可以得到一个结论：不久的将来，IPv4地址将不可能被大量地提供，这样任何新的宽带部署方案可能需要考虑：不向边界设备面向WAN一端的接口提供IPv4地址。但是，传统的被认为是“提供了双栈能力”IPv6部署模型不能处理这样的场景。

第二章处理与遗留主机通信的问题

轻量级的双栈技术是针对在IPv4地址耗尽后，服务提供商在部署纯IPv6时，需要维持与传统遗留下来的IPv4设备连接。这部分描述了由轻量级的双栈产生的一些特殊的场景。

2.1 因特网上对于宽带用户的遗留边界

宽带用户通常拥有混合的IP设备，如近期的操作系统（Windows Vista, Mac OS X和各种版本的Linux）能在纯IPv6环境下操作，但是大部分的遗留设备却不能，如Windows XP不能通过IPv6传输进行DNS请求。而期望宽带用户自已大量升级他们的软件以部署IPv6通常是不切实际的。

2.2 因特网上的已存在的内容和服务

IPv6部署需要很长的时间才能落实，并且现在的情形是网络上几乎所以存在的内容和服务都不能通过IPv6进行访问，这种情形有可能在未来得到改变，但是现在，我们必须假设由宽带用户产生的流量大部分都会被发往IPv4结点。 

2.3 由新的宽带部署产生的额外的问题

即使是考虑新的，绿地上的（即green field，指未开发的），宽带部署方案，像总是被提到的4G，服务提供商都需要面对上面提到的情形，即：当前因特网上已存在的内容和服务几乎都必须通过IPv4而不能通过IPv6访问。这使得对于在绿地上的部署方案上想采用IPv6的想法变得更加困难。而像NAT-PT之类的解决方案，现在却遭到大量批评，不能提供一个满意的，可扩展的答案。

2.4 服务提供者方面的障碍

总的来说，宽带服务提供商可能需要面对这样的情形：IPv4用户需要与因特网上的IPv4服务器通信，但是却没有剩余的IPv4地址提供给这样的客户。某个服务提供商可能同样面对另外一种情形：服务提供商想在骨干网中部署IPv6以避免使用稀缺的IPv4地址，但是，如果没有某种与IPv4向后兼容的方式，部署IPv6的代价与利益将不平衡，使得增量部署IPv6变得十分困难。

第三章 对轻量级双栈部署方案的预期

3.1 基于家用网关场景的预期

这部分主要针对由于家用网关的存在，导致的一些家用类型的网络的场景。

在家用网络内部的传统的，未修改的，纯IPv4的设备应该继续使用RFC1918规定的地址空间，即192.168.0.0/16，并且它们应该可以通过类似于现在的家用网关IPv4 NAT的方式，访问IPv4因特网。

未修改的IPv6设备应该可以不需要通过翻译，直接访问IPv6因特网。大部分具有IPv6能力的设备都应该同样具有IPv4的能力，并且能在家用网关上按照RFC1918规定的形式进行简单的配置即可拥有这样的能力，然后就能像传统IPv4设备一样在家里访问IPv4因特网。

没有实现IPv4栈的纯IPv6设备不在本文的考虑范围之内。

家用网关通过服务提供者，应该是可以软件升级或者是可替换的。在IPv4耗尽之前的早期IPv6部署方案里面，大部分都用到了隧道的形式，这对于将任意IPv6服务引入到家中都是必须的。这个家用网关应该是一个具有双栈能力的设备，并且面向WAN的一端只提供IPv6地址，而面向LAN的一端同时提供IPv4和IPv6地址，注意这里提供给接口IPv4地址就该是RFC1918里面规定的地址，这里的关键点在于不再向家用网关设备提供任何IPv4地址。

3.2 直连到宽带服务提供商网络的设备的预期

在这个部署模型之下，不经过家用网关直连到宽带服务提供商网络的设备应该是具有双栈能力的。面向服务提供商一端的接口仅被提供IPv6，在这样的设备的本地其它接口上，IPv4可能会也可能不会被提供。像上部分讲到的一样，这里的关键点在于服务提供商不会再给这些直连设备提供任何IPv4地址。

直连的设备按照预期应该实现一些代码，以支持轻量级的双栈的工作。最低的要求是一个在IPv6之上的IPv4隧道。

纯IPv4和纯IPv6的设备不在本文的讨论范围之内，大部分现在的与服务提供商网络直连的设备应该没有存储方面的约束，以实现双栈。

3.3 应用程序的预期

大部分现在的可以通过NAT网关透明工作的应用程序都应该可以继续透明地工作。但是，有些在NAT下需要特殊的端口分配或映射的应用程序可能不会正常工作。对于应用程序的行为的细节和建议超出了本文的范围，并有应该在behave工作组讨论。

3.4 服务提供商网络的预期

轻量级的双栈模型的基本思想是，一个IPv4地址将由若干个客户共享。这表示NAT功能将从家用网络移到位于服务提供商网络的设备中去。需要注意到，这个功能并不一定在服务提供商网络的核心实现，当它在靠近客户流量的聚合点实现时，情形有可能好点。

第四章轻量级的双栈

轻量级的双栈的核心思想是：

从一个全球地址由一个用户拥有，并且由若干在此用户基础上的设备共享的部署模型，转向一个全球地址由若干用户共享的部署模型；

通过一个纯IPv6的核心网络为用户提供IPv4流量的传输。

轻量级的双栈模型是通过在IPv6上的IPv4隧道来穿越网络到达一个承载级别的IPv4-IPv4的NAT，而不是通过级连的NATs和NAT-PT。通过纯IPv6的方式，它简化了服务提供商网络的管理，并使得用户从单层NAT中获益。这个模型附加的好处还有，它在保证向后与IPv4兼容的同时，在因特网上逐步引入IPv6。

4.1 应用程序的范围

轻量级的双栈部署模型是为宽带网络而设计的。虽然作者没有明确表示，但是它当然也可以应用到其它的地方。

4.2 轻量级双栈接口

对于一个在具有轻量级双栈能力设备上的轻量级双栈模型的接口，它是被作为一个点到点的IPv6上的IPv4隧道的。它的配置需要服务提供商给此设备提供给一个IPv6地址但是并不要求提供一个全球的IPv4地址。

对于在轻量级双栈隧道末端的用户网络，可以配置任何一个本地唯一的IPv4地址。在5.2节中介绍的例子中，轻量级双栈的隧道末端是在主机内部，轻量级双栈实现时可以使用著名地址范围e.f.g.h/p(由IANA定义)内的任何一个地址，但是第一个地址（子网域为全零）应该被当作隧道的IPv4主机端，相同地址范围的最后一个地址应该被当作IPv4默认网关的地址，此时使用子网掩码来覆盖一个/p的网络。

标注1：对于一个多宿主的节点，在终端可能配置多个轻量级双栈接口，每个这样的接口都应该配置从保留的地址范围中选取的一个地址。

标注2：因为这里的静态配置使用著名的地址，所以没有必要在一个轻量级双栈接口上运行DHCPv4的客户程序。

轻量级双栈接口面向服务提供商网络的末端结点是服务提供商网络中，一个轻量级双栈承载级NAT的IPv6地址。

4.3 轻量级双栈设备

一个轻量级双栈设备是一个实现轻量级双栈接口的具有轻量级双栈能力的设备。在缺少更好的路由信息的时候，一个轻量级双栈设备将在轻量级双栈接口上静态配置一个IPv4的默认路由。

4.4 轻量级双栈家用路由器

一个轻量级双栈家用路由器是一个在它的WAN接口上，实现了轻量级双栈接口的具有轻量级双栈能力的家用路由器。在缺少更好的路由信息的时候，一个轻量级双栈家用路由器将在轻量级双栈接口上静态配置一个IPv4的默认路由。轻量级双栈家用路由器可以使用拥有e.f.g.h/p前缀的任何一个为a.b.c.c的IPv4地址来作为它自已的IPv4包的源地址，并将其嵌入到IPv6隧道中去。如果一个轻量级双栈家用路由器需要配置一个指向一个IPv4默认路由器的路由器时，它可以为此使用e.f.g.h/p范围的最后一个地址，此时使用子网掩码来覆盖一个/p的网络。

注：一个轻量级的双栈家用路由器不应该执行任何IPv4的地址翻译工作，它仅仅应该执行一个路由器的功能，即转发从LAN到轻量级双栈接口上的报文，或者相反的方向，而不应该改变报文的地址。轻量级双栈路由器应该考虑隧道减小的MTU（相对于非隧道方式而言）问题，并且可能执行IPv4分片的工作。

4.5 轻量级的双栈路由器

轻量级的双栈家用路由器的概念可以推广到任何一个作为一个IP子域与之外的因特网之间的IPv4路由器。

4.6 轻量级双栈的承载级NAT设备的发现

轻量级双栈的承载级NAT设备上的IPv6地址可以通过各种方法在轻量级双栈接口上配置，如带外机制，手工配置，DHCPv6选项及IPv6路由广播机制（后两项尚未完全定义）。所有的以上的方法在不久都将得到定义，但是这些方法的要求和规范超出了本文的范围 。

4.7 轻量级双栈的承载级NAT

一个轻量级双栈的承载级NAT是一个在服务提供商网络上的特殊的IPv4-IPv4的NAT。用户通过IPv6上的IPv4隧道可以访问它。

一个轻量级双栈的承载级NAT利用IPv6源地址和内部IPv4源地址的组合来建立和维持IPv4 NAT映射表。

一个轻量级双栈的承载级NAT不需要执行任何IPv6-IPv6，IPv6-IPv4，IPv4-IPv6的NAT功能。

一个轻量级双栈的承载级NAT能利用e.f.g.h/p范围内的最后一个IPv4地址，来生成IPv4的ICMP报文，传送给轻量级双栈的客户端，以生成有用的ping和traceroute结果。

第五章示例体系结构

在轻量级双栈后的基本技术是两种著名技术的组合：NAT和隧道技术。这个组合通过softwire工作组开发的术语如Softwire NAT或者SNAT,可以得到很好的描述。

可以为轻量级双栈开发两种体系结构，一种是针对在网关后的安装在传统纯IPv4主机，另一种则针对具有双栈能力的主机，它们能自已建立隧道。

5.1 基于路由器的体系结构

这个体系结构是针对传统的宽带部署，但是它可以运用到其它纯IPv4设备占多数的类型。

如图5-1所述，此轻量级双栈部署模型由三部分组成：轻量级双栈家用路由器，轻量级双栈的承载级NAT，以及位于家用轻量级双栈家用路由器内的softwire发起者（SI）和轻量级双栈承载级NAT内的softwire聚集点（SC）。这里轻量级双栈承载级的NAT执行IPv4-IPv4的NAT翻译工作以使得多个用户复用一个IPv4地址。由用户使用的重复的地址空间通过隧道端点的标识来进行区分。

图5-1 SNAT 基于网关的体系结构 图5-2 向外的报文       图5-3 入方向报文

注意：

轻量级双栈家用路由器并不要求和主机在同一个链路上；

轻量级双栈家用路由器可以被一个位于服务提供商网络上的轻量级双栈路由器替代。

最终的方案将会接受一个IPv4报文，将其翻译成一个IPv4-in-IPv6的softwire报文，并将其在softwire中传送。在对应的末端时，IPv4报文将被解封装，最终翻译IPv4地址并将翻译后的IPv4地址插入到报文中。

5.1.1 示例消息流

在图5-2所示的例子中，在轻量级双栈的承载级的NAT上的翻译表将被配置为在IP/TCP（10.0.0.1/10000）和IP/TCP（129.0.0.1/5000）之间转发，即：当轻量级双栈路由器从地址为10.0.0.1的主机端收到一个使用端口号为10000报文，此报文将在因特网上被翻译为源地址为129.0.0.1，TCP端口为5000的报文。

表5-1报文头部的内容

当它收到报文2后，轻量级双栈的承载级NAT将IPv4报文交给NAT，NAT会从它的翻译表中知道通过Softwire_1收到并且TCP源端口为10000的报文，应该被翻译成IP源地址为129.0.0.1且TCP源端口为5000的报文3。

图5-3显示了由轻量级双栈的承载级的一个入方向的消息，当在轻量级双栈的承载级内部的NAT收到报文1时，它在翻译表中查看IP/TCP 目的地址/端口。如图5-3中的例子，NAT将把TCP目的端口翻译成10000，设置IP目的地址为10.0.0.1并且将报文交给SC然后通过Softwire_1进行传送。轻量级双栈的家用路由器收到这个报文并进行解封装得到IPv4报文，然后转发给客户主机。

表5-2报文头部内容

轻量级双栈的承载级NAT中的NAT在softwire/端口对与IPv4地址/端口对之间进行翻译，在从设备的外部接口以及softwire末端收到的报文都要经过这样的翻译。

在图5-2中，在轻量级双栈的承载级NAT的翻译盒的网络接口是在因特网上的，softwire接口是与轻量级双栈家用路由器连接的。轻量级双栈的承载级的NAT翻译盒的配置如下：

网络接口：将IPv4目的地址和TCP目的端口翻译为softwire标识和TCP目的端口。

Softwire接口：将softwire标识和TCP源端口翻译为IPv4源地址和TCP源端口。

下面讲述图5-3中的翻译过程是如何工作的：

轻量级双栈的承载级NAT在网络接口上收到报文1后，翻译盒在它的翻译表中查看IPv4地址/端口对，将IPv4目的地址重写为10.0.0.1，TCP源端口重写为10000，然后将报文交给SE并在softwire上进行转发；

轻量级双栈的家用网关上的SI收到这个IPv4报文，SI功能解封装得到IPv4报文，然后轻量级双栈家用网关转发报文3给客户主机。

表5-3轻量级双栈的承载级NAT的翻译表

这个体系结构是针对新的，大规模的，具有双栈能力并且实现了轻量级双栈接口的设备的部署。

如图5-4所述，这个轻量级双栈的部署模型由三个部分组成：轻量级双栈的主机，轻量级双栈的承载级NAT以及在主机内SI和轻量级双栈的承载级NAT内的SC之间的softwire。这个轻量级双栈的主机被认为是具有IPv6服务的并且能与轻量级双栈的承载级NAT交换IPv6流量。

轻量级双栈的承载级NAT通过一个IPv4地址为多个客户实现IPv4-IPv4的NAT翻译，轻量级双栈主机之间重叠的地址空间通过隧道端点的标识进行区分。

在这种情况下，轻量级的双栈主机配置一个著名范围e.f.g.h/p中的一个地址a.b.c.d给它的执行SI任务的轻量级双栈接口。它还会将保留范围的最后一个IPv4地址配置作为它的默认网关的地址，此时用子网掩码来覆盖一个/p的网络。

图5-4 入方向报文    图5-5 SNAT基于主机的体系结构   图5-6 出方向报文

最终的解决方案接收一个IPv4报文，并将其翻译成一个IPv4-in-IPv6的softwire报文然后在softwire中进行传输，在对应的末端，IPv4报文被解封装，最终翻译IPv4地址并将翻译后得到的IPv4地址插入到报文中去。

5.2.1 示例消息流

在图5-5的示例中，轻量级双栈的承载级NAT内的翻译表将被配置为在IP/TCP（a.b.c.d/10000）和IP/TCP（129.0.0.1/5000）之间转发，即：当从一个地址为a.b.c.d的主机收到一个TCP目的端口为10000的报文时，将会在因特网上把它翻译为一个IP源地址为129.0.0.1，TCP源端口为5000的报文。

表5-4 报文头部内容

当它收到报文1时，轻量级双栈的承载级NAT内的SC将IPv4报文交给NAT，NAT将根据翻译表得到：从softwire_1上收到的TCP源端口为10000的报文应该被翻译成IP源地址为129.0.0.1以及TCP源端口为5000的报文3。

图5-6显示一个轻量级双栈的承载级NAT上收到的入消息，当轻量级双栈的承载级NAT收到报文1时，它在翻译表中查看它的IP/TCP目的地址/端口。在图5-3的示例中，NAT将TCP目的端口翻译为10000，将IP目的地址设为a.b.c.d并将报文交给SC然后通过softwire_1进行传输。轻量级家用路由器中的SI将收到的入方向的softwire报文解封装得到IPv4报文，最后将它转发给客户主机。

表5-5 报文头部内容

在轻量级双栈的承载级NAT内部的翻译和前面的例子一样，所有使用的e.f.g.h/p范围中的著名IPv4地址a.b.c.d的主机将通过softwire的IPv6源地址得到区分。

第六章封装

在最简单的部署部型中，轻量级双栈只要求IPv4 in IPv6的封装即可，在更复杂的场景里，比如一个站点的网关想同时承担SI（softwire initiator）的任务，则需要用到更复杂的封装。这样，轻量级双栈主机，轻量级双栈家用网关以及轻量级双栈NAT设备必须最少实现IPv4 in IPv6的封装。此外，轻量级双栈NAT设备还可能支持其它封装方式，如L2TPv2/v3,GRE,MPLS,… 如果它们的确支持的话，他们应该按照IETF softwire辐射型（hub&spoke）框架要求的那样支持L2TPv2。 

第七章关于承载级NAT的考虑

一个轻量级双栈的承载级NAT应该按照目前最好的行为来实现，在[RFC4787], [I-D.ietf-behave-tcp] 和 [I-D.ietf-behave-nat-icmp]里可以找到这些行为的要求。其它的一些关于承载级NAT的要求可以在[I-D.nishitani-cgn]里找到。讨论：这些要求需要被统一以达到一致。

7.1 对于每个用户端口的分配

因为IPv4地址将由多个用户共享并且通常有可能采用一个较大的地址空间减小因子，平均来说，对于一个用户只有有限的N个TCP或UDP端口号是可以使用的。这意味着某些需要开放大量TCP端口的应用程序将变得难以工作。例如，据称一个著名的网站使用了AJAX技术并且对于同一个网页能开启69个TCP端口。如果我们假设地址空间减小因子为100（一个IPv4地址由100个用户使用），一个IPv4地址共有65k个端口可以使用，这使得在轻量级双栈隧道端点后的所有设备能够同时使用650个端口。

N个端口分配方式可以按照cookie-cutter（指固定的分配方式）方式，也可以按照对于入方向的连接按要求分配的方式，但这两种方式会造成很大的区别。这里的区别在于平均有N个端口和最多有N个端口之间的区别。若干服务提供商据称已将每个用户的平均连接数定为个位数，但是相反，任何单个用户都可以通过浏览大量的AJAX/Web 2.0站点使用上万的端口。我们需要有每个用户平均使用端口数目的概念，所以使用为100的地址空间减小因子是现实的。

监听入方向连接的应用程序，比如点到点的应用程序，变得越来越流行，这些应用程序使用了极有限的端口数目，通常只有一个。保证这些应用程序在轻量级双栈的环境下正常工作是十分重要的。类似的，需要某些类型的ALG来穿越NAT的应用程序也变得越来越多，服务提供商的承载级NAT不应该按照这种方法来部署这样的应用程序，所以，有必要保留一部分的端口让端用户自已控制。这是一个混合的环境，在这里大部的端口都是由承载级NAT从共享地址池里进行动态分配，而有限的部分是分配给每个用户的，由用户自已掌握。

一个服务提供商可以为每个用户静态保留一部端口号。注：它们可能是TCP和UDP端口号。最简单的让用户控制相关的NAT绑定的方法是：提供一个web接口（比如这是服务提供商门户网站的一部分），用户通过web进行验证，一量通过，用户即可以通过以下方式的一种，来在承载级NAT配置一个固定的外部IPv4地址/端口：

让承载级NAT在这个地址/端口上转发入方向流量到轻量级双栈的家用网关上，然后让这个设备对它进行处理，这需要在家用网关上支持A+P的语义；

或者让承载级NAT改写那些将发送到拥有私有地址的家用网络的入方向报文的目的地址，但是由于明显的安全原因，重定向至全球IPv4地址的行为是不规范的。注：这个行为与大部分家用网关上的端口转发功能是十分类似的。

为每个用户保留的端口的准确数目是基于服务提供商的考虑的，如果除了静态分配的端口外还需要保留更多的端口，则更多的端口可以进行动态保留。NAT-PMP [I-D.cheshire-nat-pmp]对于这个问题是一个很好的解决方案；像[I-D.bajko-v6ops-port-restrict ed-ipaddr-assign]中提到的DHCPv6选项也是一个对于进一步保留端口的有趣的解决方案，但是这种方式可能会上面提到的A+P的语义，因此可能没有方法来显式得控制端口转发的语义。

更多关于共享IPv4地址的考虑可以在"I-D.ford-shared-addressing-issues"中找到。

7.2 ALG

承载级NAT只应该为了一些传统的应用程序如FTP，RTSP/RTP，IPsec和PPTP VPN的穿越，而执行一小部分的ALG，并能使用户能够在静态或动态保留的端口号上使用他们自已的ALG。

特别是，承载级NAT不应该为了一个用户，在保留的端口上（不管理静态或是动态分配的）执行任何ALG的功能。

7.3 UPnP

有可能会有用户尝试让家用网关通过隧道向承载级NAT传输UPnP消息，但是不幸的是，这不会取得成功。一些应用程序坚持要在一个著名的端口上运行，并且利用UPnP请求NAT保留这个端口，但是这个端口有可能可用也有可能不可用，它们有可能被另外一个用户正在使用。使用UPnP，一个NAT盒没有办法将此应用程序重定向到其它的端口去，唯一的办法只有否决这个请求。这些应用程序通常会循环尝试某个小范围内的端口，直到最终放弃。这些端口已经被其它用户使用了的可能性是十分大的，所以UPnP不能在这样的轻量级双栈的环境中得到支持。

NAT-PMP提供了更好的语义，使得NAT能够重定向应用程序到另外一未分配的端口上。

7.4 MTU

使用了封装技术（IP in IP或者L2TP）来在IPv6网上携带IPv4的流量将减小报文的有效MTU，不幸的是，路径MTU发现机制并不是一种可靠的处理它的机制，以下推荐一个组合的方案：

对于TCP流量，让承载级NAT重写第一个SYN报文里的MSS为一个较小的值；

对于非TCP流量，在家用网关和承载级NAT之间的隧道上执行分片和重组。在实践中，这意味着将一个IPv4报文放到一个较大的IPv6报文中，然后在隧道的端点分别对这个IPv6报文进行分片和重组。为此将要负出一定的代价，分片的代价不是特别大，但是重组的代价有可能很大，特别在承载级NAT这样需要保存大量流的信息的设备上，但是此时的承载级NAT仅仅需要重组用户发出的大的UDP报文，而不需要重组发往用户的大的UDP报文，这表明，发往一个客户的视频流数据对承载级NAT不会造成严重的影响，但是这需要在家用网关上做更多的工作。

第八章未来的工作

这一章的描述将包含在本文的以后的版本或是在另一个不同的文章里。

8.1 关于组播的考虑

本文仅仅描述了单播IPv4因为IPv4组播在宽带网络中还没有大规模的部署。关于IPv4组播的考虑将在本文以后的版本中考虑。

8.2 第三方承载级NAT

轻量级双栈的体系结构应该很容易地进行扩展，以支持第三方承载级NAT，轻量级双栈接口仅仅需要指向第三方承载级NAT的IPv6地址而不是服务提供商的承载级NAT的IPv6地址即可。轻量级双栈的实现应该让用户可以采用不同的机制，以实现承载级NAT的自动发现或者，例如：手动输入选中的承载级NAT的DNS名称。

8.3 接口初始化

在轻量级双栈结点上每个接口的初始化顺序还尚待分析，决定各个接口是在IPv4模式，IPv6模式，双栈模式或是轻量级双栈模式上工作需要启发式的方法。在请求/应答消息中是否存在上面讨论到的DHCPv6选项可能触发将在哪种模式下操作。

第九章与多层NAT的体系结构对比

一个不同的体系结构是由多层朝着服务提供商网络边界的IPv4-IPv4的NAT。这些体系结构有一个关键的优点是：它能与任何已经存在的IPv4家用网关协同工作；但是，它有很多的缺点：

每个处于路径上的NAT都有它自已的应用层网关，这加大了网络失败或是错误配置的可能性；

现在大范围的可用私有IPv4地址空间是10.0.0.0/8，理论上，它能容纳一千六百万个地址，但实际上，它只有80%的利用率，只能容纳一千三百万个地址。这对于现在或将来的大规模部署是不够的，因此需要同时使用10网段地址的多个重叠拷贝，它本身增长了复杂性：

如果使用了网段10地址的多个拷贝，则解决网络上的故障会变得更加困难，测试时，向家用网关发送ping消息前需要明确指出客户位于哪个10网段域。这意味着为了包含这些信息，支撑系统需要做一定的改变；

多个重叠的10网段的拷贝经常在路由器或防火墙等地设备处聚集，在这些设备上考虑重叠的地址空间并需要仔细地进行配置，由于错误配置导致的调试问题也会变得相当耗时；

传统的拥有全球IPv4地址的用户和新的拥有私有IPv4地址的用户可能连接到相同的聚集路由器上，这个路由器必须基于源地址决定是直接将报文转发到因特网上还是送往一个翻译盒，即源地址路由。虽然要实现它并不是没有可能，但是这同样也增加了网络管理的复杂性。

上面所述的没有哪个问题可以彻底推翻多层NAT体系结构，但是综合起来，它们严重地增加了网络管理的复杂性。

第一十章与NAT-PT体系结构比较（或者NAT-PT的替代方案）

NAT-PT主要处理IPv6与IPv4之间的互相翻译，但是，它没有解决为传统的IPv4主机提供IPv4服务的问题。NAT-PT是针对绿地（green field）上的IPv6部署，允许它们访问在IPv4因特网上的服务和内容，在这个意义上，NAT-PT能与轻量级双栈针对直连到服务提供商网络的新设备在绿地上的部署相比。

在这种情形下，NAT-PT具有能够在边界设备上移除所有IPv4栈的优点，这对于一些内存资源非常小，对内存较敏感的设备非常关键。但是，如果它些设备仅仅需要与具有IPv6能力的服务器通信，是否有必要优先访问整个IPv4网络则显得不确定了。

在许多更通常的例子里，轻量级双栈比NAT-PT有如下几个优点：

轻量级双栈不需要DNS的任何改变，换句话说，没有必要合成假的AAAA记录来代表IPv4地址，这使得DNSsec的可靠性增加。

因为DNS应用层网关的原因，NAT-PT在拓扑结构上存在局限性，大部分情况下都要求所有的流量都通过一个单一的结点。因为在轻量级双栈中没有DNS应用层网关并且每个轻量级双栈设备能地连接到不同的轻量级双栈NAT上去，所以轻量级双栈体系结构的可扩展性较好。

应用层网关有时需要处理负载中的IP地址，在IPv4-IPv4的NAT上，这只是一个简单的32位域的替换，而在IPv6-IPv4的例子中，一个32位的域需要被替换为128位的域或者相反，这使得NAT-PT的应用层网关比轻量级双栈的应用层网关更加复杂。

更多的细节，请参考与NAT-PT相关的问题，即[RFC4966]。

第一十一章与DSTM体系结构的比较

DSTM通过提供给双栈结点一个暂时的IPv4地址以保证IPv6向后与IPv4兼容，这里的连接性同样是通过在IPv6之上的IPv4隧道来保证的。但是，DSTM是基于节点的需要进行IPv4地址的申请与释放的。而且作者自已也认为在大规模的宽带部署时，这种机制可能不能提供足够大的地址空间。

第一十二章IANA的考虑

这个草案向IANA申请分配一块著名的IPv4网络前缀e.f.g.h/29，这个地址范围用来对轻量级的双栈接口进行计数。保留一个/29的前缀可以允许在一个多宿主的节点上最多有6个接口。此范围内最后一个IPv4地址被保留为这样的轻量级双栈主机上的默认网关的IPv4地址。

第一十三章安全考虑

与NAT相关的安全问题被研究了很久，请参考[RFC2663]和[RFC2993]。

但是，将NAT功能从家用网关移到服务提供商网络的核心并且由多个用户共享IPv4地址后，当需要进行数据记录以防止滥用时，需要有额外的要求。在一个IPv4地址并不唯一代表一台端主机的体系结构里，IPv4地址和一个时间戳不再能够标识一个特殊的宽带用户，需要有额外的信息如TCP端口号来实现这个目的。

相似的，有一些减轻攻击的技术当观测到一个IPv4地址有反常的行为后会将其置于一个“惩罚盒”中一段时间。但这样的技术运用到本文所述的体系中时，需要被修正，因为它在针对一个IPv4地址（假设是攻击者的地址）时有可能针对了多个用户。

当IPv4地址由多个用户共享时，端口变成了一种关键的资源，因此，在承载级NAT上需要采用某种技术来端口的使用，如分等级或者统一一个用户能使用的最大端口数目，如果这个数目是足够大的，它应该不会与通常的应用产生冲突并且同时对共享池提供一定的保护。

更多关于共享IPv4地址的考虑可以参考"I-D.ford-shared-addressing-issues"。

如果在宽带网络上部署了某种形式的IPv6入口过滤机制，并且轻量级双栈服务只提供给这类用户，那么从注册用户IPv6地址开始，到承载级NAT终止的隧道不能被伪造。那么，仅仅需要一张根据隧道传输源地址的访问控制表，即可以判断是否要在承载级NAT的接口上接收这些进入的流量。