4.3 隧道技术
4.3.1 隧道技术基本原理
隧道技术通过对报文的封装/解封装，使得两个同构网络能够在一个异构网络的两边桥接起来，从而实现相互通信。隧道技术只需在网络的边缘路由器上配置好封装表就可实现对分组的透明传输，是无状态且轻量级的。但隧道技术也存在只能实现相同协议之间的互联，不能解决传统的IPv4网络和IPv6网络互通的问题。
隧道技术基本原理，为跨越中间的异构网络（IPvX）传输外部网络（IPvY）的数据报文（IPvX和IPvY用来代表两种不同的IP层协议），将隧道的两个端点置于中间网络的边界上，在隧道的入口节点（隧道端点1）用中间IPvX网络的协议头封装来自外部IPvY网络的数据报文，将原IPvY报文作为IPvX报文的载荷，使得数据报文能够通过中间网络；然后在隧道出口（隧道端点2）解封装数据报文，取出原始数据包继续在外部网络中转发。在封装时，IPvX报文的目的地址必须确保该报文在IPvX网络中能被路由到隧道端点2上，因此通常用隧道端点2的IPvX地址作为封装目的地址；反之亦然。隧道技术可以实现IPv4网络或主机穿越中间的IPv6网络（IPv4-over-IPv6），以及IPv6网络或主机穿越中间的IPv4网络（IPv6-over-IPv4）的互访。
通过上面的描述可知隧道技术的基本操作是封装/解封装。在IPv6过渡场景下，按实际需求，可采用IP-IP[29]、GRE[30][31]、L2TP[32]、MPLS[33][34]、IPSec[35]等多种封装方式。为保证数据层面的正确封装转发，在控制层面上，还需要实现跨中间网络的IPvY路由交互，以及隧道端点上封装地址的映射维护。在简单的场景或需求（如运营商内部网络或两个运营商间的指定路径）下，可以采取传统的配置隧道实现异构穿越。一般的情况下则需要采取一些新的隧道机制来实现穿越的需求。按穿越场景不同，可分为网状隧道和星形隧道两种。
4.3.2 网状隧道机制
6to4隧道机制[8]用于解决IPv6孤岛穿越IPv4网络实现相互通信，以及IPv6孤岛穿越IPv4网络与IPv6互联网通信。IPv6孤岛之间的相互通信是由6to4边界路由器（连接IPv6子网和IPv4网络）间的自动隧道实现的。隧道采用IPv6-in-IPv4的封装方式。为自动生成IPv4封装源和目的地址，避免维护地址映射，6to4将IPv6子网的地址与6to4路由器的IPv4地址耦合：IPv6子网的地址使用48位的固定前缀（2002：IPv4ADDR：/48），其中嵌套的32位IPv4ADDR为本子网连接的6to4路由器IPv4地址。这样，两个IPv6孤岛通信时，6to4路由器需要对数据包进行封装，所需要的目的地址就可以直接从IPv6目的地址中提取出来。封装包在IPv4网络中可以被正确地转发到目的IPv6子网。IPv6子网与IPv6互联网通信时，要在6to4路由器和6to4中继之间建立隧道。在这种情况下，6to4路由器需要提前学习到中继的IPv4地址，用做封装的目的地址。同时，6to4中继需要向每个IPv6孤岛网络宣告本地前缀2002：IPv4ADDR：/48。
6to4可以使6to4路由器和中继无状态通信。和SIIT类似，它对数据包进行统一的处理，并且数据层面上的性能并不受用户数量的限制。6to4促进了IPv6的发展，但是6to4中继的使用带来了路由可扩展性问题。6to4将众所周知的前缀2002：/16划分成多个IPv6网络前缀，而这些网络前缀在中继是无法聚合的。每一个6to4中继需要将IPv6客户网所有的/48前缀宣告到全球IPv6 RIB（Routing Information Base）和FIB（Forwarding Information Base）。另外，中继可能丢失一些用户发的数据包或收到没用的数据。随着IPv6互联网的发展，全球IPv6 FIB和RIB就需要承受大规模的这样的/48的前缀。因此6to4并不能成为一个可持续发展的IPv6-over-IPv4的网络解决方案。6to4路由和中继也存在着从IPv4入侵IPv6的漏洞，这也是隧道机制普遍存在的问题。
网状软线（Softwire Mesh）[36][37][38]也是一种网状穿越场景下路由器到路由器的隧道机制，它应用的场景是I-IP（Internal IP）主干网下E-IP（External IP）客户网间的互联，包括IPv4-over-IPv6和IPv6-over-IPv4两类场景，与6to4机制不同，Softwire Mesh保持IPv4和IPv6编址的独立性。通过扩展MP-BGP协议实现客户网E-IP路由信息在I-IP主干网边路由器AFBR间的传播，这些路由信息在各AFBR上形成E-IP目的前缀与I-IP封装目的地址的映射关系。当AFBR需要进行I-IP封装时，它会采用最长前缀匹配原则从封装表中选取和E-IP目的地址匹配的表项，然后用这个E-IP的地址作为目的地址封装数据包。另外，E-IP over I-IP的路由选择也是通过iBGP网络实现的。
网状软线机制中，AFBR需要维护映射关系，但映射表的规模仅是前缀级别的，其大小不会超过E-IP转发表。所以查找封装表所花费的时间在可以接受的范围之内。网状软线保持了46独立编址，因此它具有良好的可扩展性，可适用于大规模网络。另外，网状软线支持多种隧道类型，包括IP-IP、GRE、MPLS、L2TP、IPSec等，并通过扩展BGP提供了通用的信令机制支持。网状软线机制用IPv6网络传输IPv4数据包，提高了IPv6的利用率，进一步推进了IPv6互联网的发展。由于iBGP具有成熟的安全机制，所以保证了机制在控制层面上的安全性；在数据层面上仍会发生欺骗攻击，但可以通过应用E-IP目的地址检验来减少攻击。
6PE[39]采用了类似的方法来解决IPv6网络穿越IPv4 MPLS传输网的问题。6PE与softwire Mesh的区别在于，6PE使用标准BGP传递IPv6路由，其下一跳为PE路由器IPv4地址映射的IPv6地址，在PE进行封装转发时使用IPv6-over-MPLS隧道，根据映射IPv6地址对应的IPv4地址在传输网内的MPLS标签信息进行封装。
4.3.3 主机间隧道机制
6over4[9]是一种端到端的隧道机制，它主要应用与IPv4网络中的独立的支持IPv6的主机与IPv6互联互通。6over4的主要思想是利用IPv4组播在支持IPv6的主机之间建立虚拟“局域网”。换句话说，就是一条IPv6 over IPv4组播隧道。然而这种机制在控制层面上的编址机制和状态维护有很高的要求：主机和网络基础设施都需要支持组播；需要在虚拟局域网中支持一些IPv6局域网协议，如SLAAC、ND和RA等。另外，6over4的故障模式也是很复杂的。在数据层面上，组播转发模式造成多余的数据传输，如一个节点可能收到并非发给自己的数据包。除此之外，主机上的隧道端点并不考虑数据层面上的性能。6over4中最大的安全问题就是攻击ND协议，来自IPv4网络的攻击者通过注入单播的ND信息来破坏ND过程或伪造成6over4的终端。由于上述原因还有当前ISP对有限的组播支持，导致6over4并没有像预期的那样大规模应用。
ISATAP[40]是另外一种IPv6端用户穿越IPv4网络的隧道机制，但是和6over4不同的是，ISATAP隧道将IPv4网络看做一个非广播的点到多点的链路（NBMA）。一个ISATAP主机使用IPv6本地链路地址，其前缀是fe80：5efe/96，后接主机的32位IPv4地址。数据层面的数据处理采用的是典型的无状态方式，当封装IPv6数据包时，源和目的IPv4地址可以直接从IPv6地址中提取出来。除了规律的编址外，ISATAP可以有一个或多个网关路由作为隧道的端点，这些网关路由器可以利用ND协议来供IPv6访问ISATAP主机。然而虚拟链路没有广播报文就不能实现自动的路由发现机制，因此网关的地址要手动配置到主机上。然后网关路由器就可以提供全球可达的IPv6前缀，进而使ISATAP主机可以接入IPv6网络。在这种情况下，ISATAP变成一种星形隧道，同时这也是当前对ISATAP的主要应用方式。
ISATAP的一个优点在于数据层面是无状态的，但作为星形隧道机制时，控制层面的复杂程度仍然高于新的6RD机制。ISATAP通过在IPv4环境中支持IPv6终端快捷部署来推动IPv6互联网发展。它的安全问题和6over4的相似，一个恶意的IPv4主机可以假装ISATAP主机并发起攻击。
4.3.4 星形隧道机制
1.星形软线机制
星形软线（Hub＆spoke softwire）[41]采用L2TP-over-UDP-over-IPv4/IPv6的隧道，解决IPv4/IPv6域内的主机或家庭网络通过IPv4与IPv6边界的汇集节点访问IPv6/IPv4互联网的问题，适用于IPv4-over-IPv6和IPv6-over-IPv4两种场景。该方案在隧道内层使用L2TP隧道虚拟出数据链路层的环境，在该二层环境上进而形成点到点的IP层连接，包括获取IP地址。L2TP-over-UDP的隧道过于复杂，需要烦琐的信令与状态维护过程，也需要绑定IPv4地址和IPv6地址，即将外层的地址映射到不同的隧道上。在数据层面上，UDP包含在封装头上。发起点将数据封装发到对应的汇聚点，而汇聚点需要查找有状态的地址映射表以选择正确的发起点作为封装的目的地址。因此星形软线的数据层面需要维护的映射表是每用户级的。L2TP和PPP需要维护每流的状态和多种信令，而这些在大规模部署中将会产生很大的影响；另外，它也向攻击者暴露了很多漏洞，L2TP隧道和PPP会话可能被拦截，而且PPP会话也可能被中断；DoS攻击也可能发生在多个层面上。这些原因导致了当前集中发展纯粹的IP-IP隧道。
2.星形IPv6-over-IPv4场景下的过渡机制
在星形网络场景下的一个IP-IP解决方案是6RD[42][43]。6RD原理。6RD技术将6to4隧道应用到星形IPv6-over-IPv4场景下，使得6to4隧道的一端集中为IPv4与IPv6边界的路由器6RD BR，另一端则为大量分散的家庭网络CPE设备或主机，称为6RD CE。基于6to4，6RD的封装是无状态的，BR无须记录地址映射关系。6RD对6to4技术进行扩展，用ISP实际的可变前缀（Network Specific Prefix）取代2002：/16的固定前缀，即CE侧的IPv6网络或主机使用NSP：CE_IPv4_addr：/的前缀；而在BR的IPv6侧，ISP则将该NSP前缀的路由发布到全网中。这样就避免了6to4的可扩展性问题，保证了使用6RD的主机的全网唯一性与可达性。由于有地址映射规则，BR数据层面上的封装是无状态的，并不需要维护IPv4和IPv6的地址映射。无状态封装的另一个优点是当两个CE之间需要通信时，这两个CE可以直接建立隧道，而不需要通过与BR分别建立隧道。
由于6RD无状态和简单的特性，所以6RD具有良好的性能，能够达到期望的数据处理速率。6RD支持IPv4环境中快速部署IPv6用户，这样有利于推进IPv6互联网的发展。然而，如果在6RD域中有攻击者循环地发出数据包，将会产生数据放大攻击，解决方法就是利用6RD的编址原则来创建入口过滤器。
在星形IPv6-over-IPv4场景仍然有一个特别的问题：IPv4网络中遍布地址转换方式。在中间的网络中存在一个或多个IPv4 NATs。6to4和6RD使用IP-in-IP封装方式，然而典型的NAT只允许TCP/UDP/ICMP包通过，而不会转发封装后的数据包。Teredo针对这个问题提出了一个解决方案：通过把IPv6数据包封装在UDP载荷中的方式穿过NAT。一个Teredo客户端（隧道发起点）采用无状态的编址方式：64位前缀由2001：0000/32和Teredo服务器的IPv4地址组成，接口ID包含外层NAT映射的UDP端口和IPv4地址。Teredo客户端通过与Teredo服务器交互学习到这个IPv4端口和地址，并且将这个地址和端口与NAT（s）绑定。客户端需要定时与服务器交互以更新这个绑定的地址和端口。随后两个Teredo客户就可以采用这种地址和IPv6-over-UDP-over-IPv4隧道通信。在封装的时候，IPv4目的地址和UDP目标端口可以直接从IPv6目的地址中取出。当客户端与普通的IPv6节点通信时，就需要Teredo中继来做隧道的汇聚点，中继须向IPv6网络宣告Teredo前缀的可达性。Teredo客户端可以自动发现中继，它会发送IPv6 ICMP包到一个可以与服务器建立隧道的端点，随后再发送到目的地。回应包将通过IPv6路由转发回中继，再通过隧道发往相应的客户端。通过检查封装包的IPv4地址和端口，客户端可以获得中继的IPv4地址和端口，在随后的封装中就作为封装的目的地址和端口。因此Teredo服务器只在控制层面上起作用，所以它的负载就会降低。Teredo[44]属于无状态的隧道机制，所以在数据层面上的性能比较好。然而控制层面上的功能要相对复杂。因此Teredo和6to4、ISATAP相比，部署范围要小得多。但是它是目前为止唯一可以通过IPv4 NAT的IPv6-over-IPv4方案。
3.星形IPv4-over-IPv6场景下的过渡机制
IPv4-over-IPv6场景要相对复杂一些，研究者考虑到IPv4地址紧缺，在该场景下增加了IPv4地址共享的特性。一种共享地址的方式是采用运营商级别的NAT，它聚集了IPv4地址资源，在有用户需要的时候动态地进行IPv4地址和端口映射；另一种共享的方式是分配端口段，每一个IPv4地址分成多个端口段，将地址和端口段分配给用户。另一个考虑是有状态封装和无状态封装。有状态封装需要在汇聚点维护发起点的IPv4地址和IPv6地址的映射；而无状态方式并不需要维护映射表，通过编址方式将发起点的IPv4地址嵌入IPv6地址中。基于上述的两点考虑，目前提出了三类星形IPv4-over-IPv6过渡方案。
Dual-stack lite[45]技术使用CGN方式和有状态封装来解决星形IPv4-over-IPv6问题，在该机制中本地网络/用户需要使用私有IPv4地址，而地址族转换路由器（AFBR，隧道汇聚点）就作为CGN对地址进行统一管理，将IPv4私有地址转换成公有地址。在Dual-stack lite中既不需要提前分配IPv4地址，也不需要IPv6编址机制，但AFTR须将其CGN的IPv4公有地址池的前缀发布到IPv4互联网中。基本原理，数据层面的出流量方向上，基本桥接宽带单元（B4，支持IPv6的主机或家庭网络的用户端设备）通过IPv4-in-IPv6的隧道将数据发送到AFTR上，AFTR解封装得到IPv4包，将IPv4的私有地址和端口映射为自己的公有地址和端口，并在映射中记录B4的IPv6地址，继而将数据包转发到IPv4互联网。反向的流量则先经AFTR通过绑定表对数据进行翻译和封装，再发送回B4。
和NAT64类似，查找CGN的操作也是Dual-stack lite性能的瓶颈。在使用软件实施的情况下，数据处理的速度将与CGN的规模成反比；而使用硬件来实现时，所需要的代价和容量将会随着绑定表规模的增加而增大。创建一条新的绑定条目的时延也会降低数据处理的速度。另外，CGN的使用解决了IPv4地址不足的问题，但也引入并在一定程度上扩大了NAT的问题，包括应用层翻译、状态维护、无法从外部发起访问等。Dual-stack lite一个优点是对地质资源的多路复用，并在将来的IPv6基础设施中保持了IPv4的可用性，因此也促进了IPv6的发展（4over6和MAP-E也是如此）。Dual-stack lite存在的一个较严重的安全问题就是对CGN的DoS攻击。考虑到Dual-stack lite的地址复用模式，ISPs需要为每一流创建一个五元组来保证用户可溯源，这也给ISPs带来了很大的负担。
4over6机制选择的是结合端口段和有状态封装。以此为基础，Public 4over6[46]描述的是分配完整的公有IPv4地址方案。Public 4over6并不需要IPv6编址规则，在IPv6域中利用用户和DHCP服务器间的IPv4-in-IPv6隧道承载DHCPv4过程，向IPv6主机或家庭网络用户端设备动态分配公有IPv4地址。当地址分配完毕后，该地址作为用户侧隧道内层地址。4over6的汇聚点就需要绑定分配的IPV4地址和发起点的IPv6地址，同时还需要向IPv4 Internet发布DHCP地址池的地址前缀。在数据层面的出流量方向上，发起点通过隧道将数据转发到汇聚点，汇聚点只需要将数据解封装还原成原始的IPv4数据包再转发到IPv4 Internet。在入流量方向上，汇聚点将需要查找绑定表，通过目的IPv4地址找到相应的IPv6地址，再对数据包进行封装，再转发到相应的发起点。Lightweight 4over6[47]是Public 4over6的扩展，它进一步实现了地址复用。和Public 4over6的区别就在于对端口段的支持：DHCPv4过程也需要扩展支持端口段的分配，在汇聚点的绑定表除了IPv4地址之外还需要增加端口段的信息。这两者结合作为封装表查找的目的地址。
H1
4over6的状态维护从每流的规模降到每用户的规模，因此它的性能更好。另外，4over6没有应用层翻译的问题，并且可以保持通信的双向透明性。其不足是地址的复用率没有Dual-stack lite高，每个用户的端口范围是受限制的。它主要的安全问题是对DHCP进行的中间人攻击，因此需要入口过滤机制和DHCP安全方案来防止攻击。
星形IPv4-over-IPv6的第三类解决方案是MAP-E[48]和4RD[49]，这类方案采用的是划分端口段和无状态封装。从本质上来讲，这两个机制非常相似，所以本章以MAP-E为例。MAP-E可以看成6RD在IPv4-over-IPv6场景的一个镜像，而不同的是它采用端口段地址复用方式，即客户边缘路由器（CE， IPv6主机或家庭网络的用户侧设备）分配的是地址加端口段。然而IPv4地址并不是直接分配的，而是从IPv6地址中计算出IPv4地址和端口段。为了实现这一过程，需要将IPv4地址和端口段的信息嵌入CE的IPv6地址中，因此就需要IPv6地址和IPv4地址耦合。具体来说，CE IPv6地址包括规定的IPv6地址前缀、地址嵌入位（包括IPv4地址后缀和端口段索引）、子网ID和64位接口ID。通过不同的IPv6地址前缀、IPv4地址前缀和地址复用率可以得到多个地址规则实例。通过BR（边界路由器，隧道汇聚点）维持所有的规则及向CE提供相应的规则，使得无状态封装方案得以实现。基于这些规则和IPv4目的地址和端口，BR和CE都可以计算出相应的IPv6目的封装地址。当一个CE维护一个远端CE的地址规则时，这个CE可以直接根据规则计算出封装所需要的CE的IPv6地址，然后直接将数据发送到远端的CE，此时就不需要分别与BR建立隧道。当CE没有相应的规则时，CE将数据封装转发到BR，再由BR做处理。另外，BR还需要对外宣告它所维护的所有的IPv4前缀。
与4over6和Dual-stack lite相比，MAP-E在无状态方面更有优势，所以它的性能也能够达到预期的效果。然而由于IPv4和IPv6地址的紧密耦合，在部署时灵活程度会下降：部署时需要全网部署，而不能只部署在需要的位置，否则就会造成IPv4地址浪费。MAP-E存在的安全问题是欺骗攻击和路由循环攻击，可以通过入口过滤和IPv4、IPv6地址一致性检测来解决这些问题。还有一个安全问题是，在DHCPv6分配规则时，会有攻击者通过中间人攻击劫持数据，因此还需要DHCP安全解决方案来避免此类事件发生。
4.星形IPv4-over-IPv6场景下地址分配机制
Public 4over6与Lightweight 4over6均通过DHCPv4-over-IPv6机制来完成IPv4资源分配。在对传统DHCPv4进行扩展的基础上，DHCPv4-over-IPv6能直接通过IPv6 UDP报文转发DHCPv4数据。与使用DHCPv6来完成DHCPv4功能相比，DHCPv4-over-IPv6实现了IPv4与IPv6的解耦合；而与使用IPv4-in-IPv6隧道传输的DHCPv4-over-Tunnel机制相比，DHCPv4-over-IPv6则不会产生维护IPv4-in-IPv6隧道的额外开销。
是DHCPv4 over IPv6传输场景。DHCPv4客户端与DHCPv4服务器分别处于IPv6网络的两侧。由于传统的DHCPv4是通过IPv4 UDP报文进行转发的，无论是通过单播还是广播，DHCPv4客户端的DHCPv4请求都无法传递给DHCPv4服务器/中继。因此只有使DHCPv4数据能通过IPv6 UDP报文进行转发，DHCPv4的资源分配流程才能在IPv6网络中顺利进行。
为了实现这一机制，需要对DHCPv4传输过程扩展，为DHCPv4客户端通过客户中继代理CRA（Client Relay Agent）与IPv6传输服务器TSV（IPv6-Transport Sever）进行通信的场景，而DHCPv4客户端通过CRA和IPv6传输中继代理TRA（IPv6-transport Relay Agent）与DHCPv4服务器进行通信的场景。
CRA与DHCPv4客户端处于同一主机中，负责对DHCPv4客户端与TSV/TRA之间的DHCPv4信息进行中继。CRA与DHCPv4客户端通过IPv4进行通信，与TSV/TRA则通过IPv6报文进行通信。在DHCPv4过程开始前，CRA通过DHCPv6选项或其他方法获得一个或若干个TSV/TRA的IPv6地址。
CRA在其IPv4侧的UDP 67端口，以及IPv6侧的UDP 68端口处监听DHCP信息。当其在IPv4侧收到DHCPv4客户端发来的DHCPv4信息时，CRA将其通过IPv6 UDP报文发往其IPv6侧所有已知的TSV/TRA的IPv6地址，该报文的源端口号与目的端口号均为67，期间CRA不能引入选项82，并且不能修改DHCP数据的giaddr位；当其在IPv6侧收到DHCPv4服务器发来的DHCPv4信息时，CRA首先检查该信息是否包含选项82，若包含则丢弃该信息，否则将其转交给IPv4侧的DHCPv4客户端。
除了与DHCPv4客户端处于同一主机外，CRA还可以和DHCPv客户端所在主机部署在同一IPv4链路上，此时的CRA称为链路CRA（LCRA）。LCRA所需要满足的要求与CRA基本相同，唯一不同的是CRA只服务于某一特定的DHCPv4客户端，而LCRA则服务于链路上所有DHCPv4客户端。
TSV是支持IPv6传输的DHCPv4服务器。它部署在IPv6网络中。它在IPv6侧的UDP 67端口监听DHCPv4信息。当它从IPv6侧收到DHCPv4信息时，TSV必须记录该信息的源IPv6地址，在之后返回DHCPv4消息时，TSV将使用该IPv6地址作为消息的目的地址，并且将目的端口设置为68。TSV也可像普通DHCPv4服务器一样监听IPv4侧的UDP 67端口，完成传统的DHCPv4服务器功能。
TRA部署在IPv6网络与IPv4网络之间，负责对CRA与纯IPv4的传统DHCPv4服务器之间的DHCPv4消息进行中继。TRA监听IPv6侧的67端口，以及IPv4侧的68端口。当TRA需要中继由CRA发往DHCPv4服务器的DHCPv4消息时，TRA必须为该消息增加选项82，并加上子选项CRA6ADDR，该子选项包含了该DHCPv4消息的源IPv6地址信息。当TRA需要中继由DHCPv4服务器发往CRA的DHCPv4消息时，TRA首先检查该消息的选项82是否包含子选项CRA6ADDR，若不包含则丢弃该消息，否则就按照RFC 3046所述处理该子选项，并将其转发给IPv6侧由子选项CRA6ADDR记录的IPv6地址，并且源端口设置为67，目的端口设置为68。
4.3.5 两次翻译和隧道的比较
理论上讲，IPvY-IPvX-IPvY穿越场景下，可以通过在入口隧道端点处做一次IPvY-IPvX翻译，在出口隧道端点处做一次IPvX-IPvY翻译，然而这种方式在IPv6-IPv4-IPv6场景下并不可行。尽管可以在第一次翻译时将IPv6地址转换成IPv4地址，但是在第二次翻译中，将32位的IPv4地址恢复成128位的IPv6地址是不可能的。关于IPv4-IPv6-IPv4场景，本书中介绍两个基于两次翻译的过渡方案。
一个是MAP-T，它是和MAP-E一同提出来的适应于IPv4-IPv6-IPv4星形结构的无状态方案。在MAP-T中两次翻译分别是在CE和BR上，其中CEs使用和MAP-E相同的编址规则。但是有一个小区别，在MAP-E中，CE和BR之间所封装的IPv6数据包中，BR的地址作为数据包的源或目的地址；而在MAP-T中，IPv6数据包在入流量方向的源地址和出流量方向的目的地址，都是由IPv4地址映射得来的。此外，远端终端的IPv4地址将会丢失。
另外一个适应于IPv4-IPv6-IPv4星形结构的有状态方案是464XLAT[50]，在一定程度上与Dual-stack lite相似。464XLAT实际上是用户端的SIIT和运营商侧的NAT64的结合。用户端的用户或家庭网络都使用私有IPv4地址。以数据层面上出流量方向为例，在“B4”设备上采用SIIT机制（将私有的IPv4地址嵌入IPv4翻译地址）将IPv4数据包翻译成IPv6数据包，再转发到本地的“AFTR”，再翻译成源地址是公有IPv4地址的数据包。从端到端的角度来看，464XLAT准确地实现了Dual-stack lite的效果。
从上面两个例子来看，隧道和两次翻译在它们的场景里似乎可以相互替代，然而精细的区别还是存在的。隧道通过保留原始数据包保持了内部IPv4的透明性，而翻译是做不到的。由于IPv4和IPv6协议的差异，翻译技术并不能保留原始协议头的所有信息。大部分字段都被保留了，而有一部分会丢失，如ToS、标示字段和标记。另外，两次翻译机制要比隧道暴露更多的内部IPv4地址信息，所以理论上讲，可能会为运营商提供更多的便利。
4.3.6 隧道机制总结
隧道机制的总结从表中可以看出，Softwire Mesh、6RD、Dual-stack lite、4over6和MAP-E这一系列隧道机制可以涵盖异构地址穿越的大部分场景。特别地，在IPv4-over-IPv6星形场景中，Dual-stack lite，4over6和MAP-E分别具有各自的优点和缺点。这三种机制一起可以满足该场景下不同的需求。作为一个例外，Teredo是唯一一个解决星形IPv6-over-IPv4问题的NAT穿越机制。
