计算机网络技术与服务/迁移到 IPv6
在迁移阶段，主机应该逐渐开始能够到达 IPv6 目标，同时保持能够到达 IPv4 目标。迁移所有网络设备是一个必要的条件，但不是充分条件：用户需要通过为整个网络制定新的地址计划来使它们协同工作。
在应用程序中引入 IPv6 支持会导致需要更改源代码
- 服务器：服务器上运行的进程应该打开两个线程，一个监听 IPv4 套接字，另一个监听 IPv6 套接字，以便能够服务于 IPv4 和 IPv6 请求；
- 客户端：诸如 Web 浏览器之类的应用程序应该能够以新格式打印输出并获得输入地址。
-
双栈，无双层。 -
双栈，有双层。
应用程序主要依赖于操作系统库，这些库可以通过采用 **双栈** 方法来引入 IPv6 支持
- 无双层：操作系统独立处理 IPv4 和 IPv6 地址→软件应该能够管理 IPv4 和 IPv6 地址；
- 有双层：操作系统能够将 IPv4 地址转换为 IPv4 映射的 IPv6 地址→软件可以只支持 IPv6 地址，而无需关心 IPv4 地址。
有双层的变体是最常用的，因为它将复杂性转移到操作系统核心。
虽然理论上交换机应该不受第 3 层更改的影响，因为它们的工作范围仅限于第 2 层，但一些附加功能可能会出现问题：例如 **IGMP 侦听**，用于过滤传入多播数据包的功能，需要查看数据包内部→由于数据包格式和字段发生了变化，交换机无法识别多播 IPv6 数据包，因此会丢弃它们。
如今，大多数路由器都已准备好支持 IPv6，即使 IPv6 的性能仍然比 IPv4 差，因为缺乏经验和流量需求较低。
典型情况下，支持 IPv6 的路由器采用双栈“夜航”式方法：IPv4 和 IPv6 由传输层两个独立的栈支持→这需要所有组件的完整复制：路由协议、路由表、访问列表等。
IPv6 中的路由与 IPv4 的执行方式相同，但它需要两个不同的路由表，一个用于 IPv4 路由，另一个用于 IPv6 路由。IPv6 路由表可以存储多种类型的条目，包括
- 间接条目（O/S 代码）：它们指定要将数据包发送到远程链路的下一跳路由器的接口地址，通常是链路本地地址；
- 直接条目：它们指定路由器本身用于将数据包发送到本地链路的接口；
- 连接的网络（C 代码）：它们指定本地链路的网络前缀；
- 接口地址（L 代码）：它们指定本地链路中的接口标识符。
支持 IPv6 的路由协议可以采用两种方法
- 集成路由（例如 BGP）：协议允许同时交换 IPv4 和 IPv6 路由信息→属于同一目的地的 IPv4 和 IPv6 地址可以通过单条消息传输→效率更高；
- 夜晚的船只 (例如 RIP、OSPF)：该协议只允许交换 IPv6 路由信息 → 给定一个目标，需要发送一个消息获取其 IPv4 地址，另一个消息获取其 IPv6 地址，并且这些消息完全独立 → 更高的灵活度：可以使用两种不同的协议，一种用于 IPv4 路由信息，另一种用于 IPv6 路由信息。
支持 IPv6 的 DNS 可以将两个 IP 地址映射到同一个别名：一个 IPv4 地址和一个 IPv6 地址 → 公共目标可以通过 IPv4 或 IPv6 访问。
支持 IPv6 的 DNS 不仅可以通过 IPv6 返回 IPv6 地址，还可以通过 IPv4 返回：实际上，DNS 消息属于应用程序层，因此用于转发 DNS 查询和应答的传输层无关紧要。DNSv6 查询通过以下命令执行set q=aaaa.
一家公司可能决定也通过 IPv6 提供对其公共网站的访问。然而，目前大多数流量是通过 IPv4 进行的，因此通常，IPv4 流量的服务在性能和容错性方面比 IPv6 流量服务更可靠。因此，公司，尤其是如果其业务建立在网站上的话，不希望通过 IPv6 连接的用户因性能问题而选择其他竞争对手的网站。一种可能的解决方案是执行一些初步评估，以测试用户和公司服务器之间连接的性能，并在 DNS 中实现额外的机制：它们应该能够查看 DNS 查询的源地址，并在没有执行连接评估时只返回 IPv4 地址，或者在性能足够好时返回 IPv4 和 IPv6 地址。
网络不会从第一天起就兼容 IPv6 → IPv6 流量可能需要穿越仅支持 IPv4 的网络部分。面向网络的隧道解决方案即使在仅支持 IPv4 的基础设施之间连接，也能使 IPv6 网络之间实现连接，这可以通过将 IPv6 数据包封装在 IPv4 首部中来实现，只是为了在隧道中进行传输。
隧道数据包的大小，包括 20 字节长的 IPv4 首部，不能超过 IPv4 数据包的最大大小 → 两种解决方案是可能的
- 分片：路由器应该在将 IPv4 数据包发送到隧道之前对其进行分片 → 由于性能原因，分片已过时；
- 更小的 IPv6 数据包：主机应该生成具有更小 MTU 大小的 IPv6 数据包，以考虑由于插入 IPv4 首部而导致的额外大小 → 路由器可以通过 '路由器通告' ICMPv6 消息指定允许的 MTU 大小。
面向主机的隧道解决方案对于主机来说更加即插即用，但它们不是专业的解决方案，不能解决 IPv4 地址短缺的问题，因为每台主机仍然需要一个 IPv4 地址。这类解决方案有
- 使用 IPv6 IPv4 兼容地址，在主机或路由器上进行隧道终止；
- 6over4；
- ISATAP。
它们假设双栈主机在需要联系 IPv4 目标时，会将 IPv6 数据包发送到一个 IPv4 兼容的 IPv6 地址，该地址的 96 位最高有效位为零，其余 32 位与目标 IPv4 地址的 32 位一致。然后，这个 IPv6 数据包被封装在一个 IPv4 数据包中，其目标地址取决于您是要在目标主机上终止隧道还是在双栈路由器上终止隧道，具体来说是
- 端到端终止：双栈主机上的伪接口将数据包封装在一个目标为要联系的主机的 IPv4 数据包中；
- 路由器双栈终止：主机上的伪接口将目标为主机的包发送到双栈路由器的 IPv4 地址，因此
- 会为目标生成一个 IPv6 IPv4 兼容地址，如前所述；
- IPv6 数据包被封装在一个目标为双栈路由器的 IPv4 数据包中；
- 双栈路由器解封装数据包并将其发送到目标主机。
其思路是通过 IPv4 模拟一个支持多播的本地网络。实际上，对于通过底层以太网连接两台 IPv6 主机，会使用邻居发现，并依赖于以太网具有广播机制这一事实，在这个解决方案中，我们假设 IPv4 是更低层的协议，并将邻居发现更改为查找 IPv4 地址而不是 MAC 地址。这个讨论可以推广到我们想要连接的不是单个主机，而是通过双栈路由器在 IPv4 网络中通信的 IPv6 网络云的情况。在这种情况下，除了邻居发现之外，还可以使用修改后的路由器发现，以便发送路由器请求，以发现连接到主机 IPv4 网络的路由器的 IPv4 地址，这些路由器允许到达各种 IPv6 网络；实际上，从路由器通告中，主机可以获取有关可以从该路由器到达的 IPv6 网络的信息。
这个解决方案的问题是使用了 IPv4 多播，而 IPv4 多播通常在涉及不同提供商的网络中被禁用。这个解决方案可以在您控制整个网络时使用：因此，它不能用于将全局网络从 IPv4 迁移到 IPv6。
根据 RFC 的提议，IPv6 地址被映射到 IPv4 地址：实际上，IPv4 地址被用作目标 IPv6 地址的接口标识符。这将使迄今为止说明的机制变得不必要，因为主机可以直接进行隧道传输，而无需邻居发现来了解 IPv4 地址。这显然在 IPv6 地址不是从 IPv4 地址构建的情况下不适用，因此仍然需要更通用的机制来联系路由器。因此，假设只知道一个 IPv6 地址，邻居发现将发送到请求节点多播地址（例如，如果 IPv6 地址是fe80::101:101那么它将发送到ff02::1:ff01:101) 在 IPv4 6over4 多播网络上的地址239.192.x.y，用 IPv6 地址的最后 16 位构建（因此在前面的例子中，它将是239.192.1.1).
其思路类似于 6over4，即使用 IPv4 网络作为物理链路来到达 IPv6 目标，但我们想克服请求多播支持的限制。在没有邻居发现机制的情况下，使用 ISATAP 的目标的 IPv4 地址被合并到 IPv6 地址中，更确切地说是接口标识符中，其格式为0000:5efe:x:y，其中x和y是 IPv4 地址的 32 位。如您所见，这个解决方案没有解决引入 IPv6 的问题，即 IPv4 地址的稀缺性。然而，这个解决方案在 IPv4 链路连接的不是主机，而是边界上有 IPv6 云的路由器的情况下更实用。在这种情况下，IPv4 网络中的主机想要以 IPv6 与属于云的主机通信，必须配备潜在路由器列表 (PRL)。此时出现的问题是
- 如何获取 PRL？
- 存在两种不同的解决方案：前者是专有的，基于使用 DHCP；后者是标准的，基于使用 DNS。在后者中，对于具有以下格式的特定名称的 DNS 查询isatap.dominio.it，它将提供连接到查询中指定的域的 IPv4 网络的 IPv6 路由器的 PRL。
- 应该将发往 IPv6 目标的报文发送到哪个路由器？
- 对每个 PRL 路由器使用单播路由器发现，以便通过路由器通告获得回复。请记住，实际上，在通告路由器中，路由器还可以通告可以通过它们到达的 IPv6 网络列表（参见L=0标志在ICMP 路由器通告的前缀信息选项中）。
通常，面向网络的隧道解决方案需要手动配置，封装可以基于 IPv6 在 IPv4（协议类型 = 41）、GRE、IPsec 等。
从之前的解决方案中取得的最大进步来自这样一个考虑：在新场景中，有一个完整的 IPv6 网络需要一个 IPv4 地址才能从 IPv6 云中出来，不再是一个单独的主机。然后，在 IPv6 前缀中完成两个地址之间的映射，而不是在接口标识符中：为所有 IPv6 网络分配一个特殊的前缀，该前缀包含分配给面向云的双栈路由器的接口的 IPv4 地址。前缀2002::/16标识正在使用 6to4 的 IPv6 站点：在接下来的 32 位中设置 IPv4 地址，并且还有 16 位可用于表示多个不同的子网，而接口标识符则像其他 IPv6 用例中一样获得。在这个解决方案中，还有一个路由器具有特殊的作用，即6to4 中继，它必须是 6to4 路由器的默认网关，以便将没有刚才看到的 6to4 格式的报文转发到全局 IPv6。这个路由器的地址是192.88.99.1，这是一个任播地址：它被谁构思了 6to4，因为它被认为是在同一网络中有多个 6to4 中继的场景，这将导致必须使用不同地址的问题。相反，由于任播地址通过路由协议以不同的方式处理，因此可以使用相同的地址，并提供负载平衡。
假设有两个连接到 IPv4 云的 IPv6 云，并且双栈路由器的接口对于连接到 IPv6 云的接口，具有地址192.1.2.3对于网络 A，以及9.254.2.252对于网络 B。假设网络 A 中的主机 a 想要向网络 B 中的主机 b 发送一个报文。从概述的配置和已经说过的话可以清楚地看到，存在于网络 A 中的主机将具有类型为2002:c001:02:03/48的地址，而存在于网络 B 中的主机将具有2002:09fe:02fc::/48的地址。从 a 到 b 的 IPv6 报文将封装在一个 IPv4 报文中，该报文的目的地地址为9.254.2.252，从目的 IPv6 地址的前缀中获得：当报文到达该路由器时，它将被解封装并根据包含网络 B 的云的 IPv6 地址计划转发。
它与 6to4 非常相似，除了封装是在包含在 IPv4 报文中的 UDP 段内完成的，而不是简单地封装在 IPv4 中。这样做是为了克服 6to4 的限制，即穿越 NAT：由于在 6to4 中，封装 IPv4 报文内没有 2 级段，因此 NAT 无法工作。
6to4 解决方案的问题是它不够通用：你被绑定到使用2002::/16地址，你不能使用通常的全局单播。在隧道代理解决方案中，由于不再能够从 IPv6 前缀中推断出应该将报文发送到哪个端点，因此使用了一个服务器，该服务器在给定一个通用的 IPv6 地址后，提供了要联系的端点隧道的地址。实现隧道代理的路由器称为隧道服务器，而提供映射的服务器称为隧道代理服务器。隧道像 6to4 一样创建，因此 IPv6 在 IPv4 内：如果存在穿越 NAT 的问题，你也可以考虑使用 Teredo 的方法，通过封装在 UDP 内，然后封装在 IPv4 内。
需要配置隧道代理服务器：隧道信息控制（TIC）用于将有关给定隧道服务器可达网络的信息从正在配置的隧道服务器转发到隧道代理服务器。隧道建立协议（TSP）用于向隧道代理服务器请求信息。同样，你可以为全局 IPv6 网络有一个默认网关。总之，具有此配置的路由器，当一个报文到达时，可以
- 如果它与路由表中的条目匹配，则直接转发它（经典情况）；
- 询问隧道代理服务器以查看它是否是一个需要隧道的地址；
- 如果隧道代理服务器的响应为否定，则将其发送到全局 IPv6 默认网关。
- 它是一个集中式解决方案，因此隧道代理服务器是一个单点故障。
- 它使控制计划变得复杂。
- 如果此服务器用于互连不同的网络，即使这些网络属于不同的提供商，也会出现其管理责任的问题。
- 它比 6to4 更灵活，因为它允许使用所有全局单播地址。
目标是迁移大型提供商的网络，以便网络边缘的 IPv4 和/或 IPv6 云可以使用 IPv6 骨干网进行互操作。常见的场景是一个用户想要通过提供商的 IPv6 网络连接到 IPv4 目标。
所有可用的选项都使用 NAT。NAT 的使用有点逆潮流而行，因为 IPv6 的目标之一是避免在网络中使用 NAT，因为 NAT 带来了许多问题（报文在传输中的更改，对等网络问题等）。但是，这些解决方案基于 NAT 事实上带来了许多优点：NAT 在网络中广泛传播，它们的优缺点是已知的，可能在穿越 NAT 时出现问题的应用程序是已知的；因此，总的来说，优势在于迄今为止获得的巨大经验。
在基于 NAT 的解决方案中，有三个主要组件
- 客户机房设备（CPE）：它是客户边缘的路由器，就在提供商的网络之前；
- 地址族转换路由器（AFTR）：它是IPv6 隧道集中器，即 IPv6 隧道的末端的设备；
- NAT44/NAT64：它是用于将 IPv4/IPv6 地址转换为 IPv4 地址的 NAT。
- NAT64;
- 双栈精简版 (DS-Lite): NAT44 + 4-over-6 隧道；
- 双栈精简版地址+端口 (DS-Lite A+P): 带有预配置端口范围的 DS-Lite；
- NAT444：CGN + CPE NAT44，即当家庭用户从电话公司获得服务时，在其家庭网络中添加 NAT；从家庭网络发出的每个数据包都会进行两次地址转换；
- 运营商级 NAT (CGN)：大规模 NAT44，即电话公司用来将数十万个（用户）私有地址映射到可用的有限公共地址的 NAT。
对于面向移动设备的大型网络迁移，选择 NAT64 解决方案。
为了迁移到 IPv6，在网络边缘保持 IPv4 兼容性，一些电话运营商正在计划大规模迁移到 DS-Lite，因为它经过充分测试，并且已经有几种兼容设备上市。
由于缺乏经验，A+P 解决方案目前还没有被认真考虑。
- IPv6 专用用户类型www.example.com输入到他的浏览器中，由于是 IPv6，他向提供商的 DNS64 发送 AAAA 查询。假设www.example.com具有 IPv4 地址 '20.2.2.2'。
- DNS64 在没有名称解析的情况下，需要将查询发送到上级 DNS，假设在 IPv4 网络中。
- 在最佳情况下，DNS64 将 AAAA 查询发送到上级 DNS，并获得类型为 AAAA（即 IPv6）的回复，它会原样将回复传输回主机（通过 IPv4 数据包发送需要将名称解析为 IPv6 地址的 DNS 查询是完全可能的）。
- 在最坏的情况下，上级 DNS 不支持 IPv4，因此会回复 '名称错误'；DNS64 再次发送查询，但这次是类型 A，然后它将获得正确的回复。此回复将被转换为 AAAA 并传输回主机。在传输给主机的回复中，最后 32 位与上级 DNS 在类型 A 记录中发送的 32 位相同，而其他 96 位完成 IPv6 地址；因此最终地址将是 '64:FF9B::20.2.2.2'。
- 现在主机已准备好建立 TCP 连接到www.example.com.
- NAT64 开始发挥作用：它将来自主机的 IPv6 数据包转换为 IPv4，并对来自 20.2.2.2 的数据包执行反向操作。
- 在这种情况下，没有隧道：IPv6 头只是被 IPv4 头替换，反之亦然。
- IPv6 专用主机并不知道目标地址与 IPv4 地址相关联。
- NAT64 不仅能够将 IPv6 地址转换为 IPv4 地址，而且在某种程度上使网络相信有 232 个 IPv6 地址可用，因为来自主机到 NAT64 的每个数据包都将具有 '64:FF9B::20.2.2.2'，前缀为 '64:FF9B/96'，作为目标地址。
- 提供商的网络（即 NAT64 和 DNS64 所在的网络）是 IPv6 原生的，因此提供商网络中的主机可以直接与另一个支持 IPv6 的主机进行通信，而根本不涉及 NAT64。
- '64:FF9B/96' 是专门为此转换技术标准化的寻址空间，分配给 NAT64，但网络管理员可以根据需要更改它。请注意，网络管理员需要配置路由，以便每个具有该前缀的数据包都将发送到 NAT64，并且需要配置 NAT64，以便它将每个具有该前缀的 IPv6 数据包转换为 IPv4，并将其转发到 IPv4 云中。
- NAT 的存在会带来一个典型问题：NAT 后面的主机不容易从外部访问。
- 通常，当 DNS 没有地址解析时，它根本不回复，而是发送 '名称错误'；这会导致 DNS64 等待超时的时间延长，当超时到期时，它会发送类型 A 的查询。
- 如果用户想要直接输入 IPv4 地址，此解决方案将不起作用：用户始终需要指定目标的名称。
双栈精简版 (DS-Lite) 解决方案包括简化 CPE，将 NAT 和 DHCP 功能移到提供商网络的边缘，即到充当 AFTR 和 CGN-NAT44 的设备。
- 提供商的 DHCP 服务器为每个 CPE 的每个主机分配一个在提供商网络内唯一的 IPv6 地址。
- 当用户需要发送 IPv4 数据包时，需要进行隧道操作，以便将 IPv4 数据包封装到 IPv6 数据包中，因为提供商的网络是 IPv6 专用的。因此，当 CPE 接收到 IPv4 数据包时，它需要将其隧道化到 IPv6 数据包中，以便能够将其发送到 AFTR，然后是 IPv4 云；因此，该场景由提供商的 IPv6 网络中 AFTR 与多个用户 CPE 之间的大量隧道操作组成。特别是，CPE 和 AFTR 之间的数据包的源 IPv6 地址将是 AFTR 的地址，目标 IPv4 地址将是 IPv4 网络中的目标地址。
- AFTR 在删除 IPv6 头后，将其发送到 NAT44，NAT44 会将 IPv4（私有）源地址替换为 NAT 将接收与该流关联的数据包的 IPv4 地址。
DS-Lite 的主要优势是显着减少了提供商的公共地址数量。
提供商网络中是否存在任何重复的 IPv4 地址？不，因为 NAT44 直接将主机的 IPv4 地址转换为可用的公共 IPv4 地址。如果存在重复的私有 IPv4 地址，NAT 将会遇到歧义问题。
- IPv4 主机无法联系 IPv6 目标→ IPv6 目标只能由 IPv6 主机访问。相反，IPv6 主机可以发送和接收来自 IPv6 节点的數據包，而无需通过提供商的 AFTR。
- 某些类型的应用程序在这种情况下无法运行：NAT 无法由用户管理，因为它不再位于 CPE 上，这使得无法执行一些常见操作，例如打开/关闭特定应用程序所需的端口。
双栈精简版地址+端口 (DS-Lite A+P) 解决方案仍然包含提供商的 IPv6 专用网络，但 NAT 被移到 CPE 上，以便用户可以根据需要对其进行配置。
与 DS-Lite 一样，从 CPE 发出的 IPv4 数据包仍然需要进行隧道化，因为提供商的网络是 IPv6 专用的。
每个 CPE 上的 NAT 需要一个公共 IPv4 地址，这是通过允许复制公共 IPv4 地址来解决的，并且基于端口来区分 CPE。事实上，每个 CPE 使用一个特定的端口范围，AFTR 了解每个 CPE 使用的端口范围，能够区分来自特定 CPE 或发送到特定 CPE 的流，尽管有几个 CPE 具有相同的公共 IPv4 地址。
此解决方案与 DS-Lite 类似，但私有 IPv4 地址空间在最终用户控制下的程度更高，因为 NAT 位于用户 CPE 上，用户可以对其进行配置，即使有一些限制：他无法打开和使用不在其范围内的端口。此方法允许节省 IPv4 地址（但与 DS-Lite 相比仍然较少）。
此解决方案在意大利基本上是非法的，因为端口号没有被记录下来，如果发生攻击，将无法追踪到攻击者。
主要目标是在全球网络上实现 IPv6 流量，同时不影响现有的 IPv4 网络，该网络已经运行了 20 多年，目前运行良好。在全球范围内迁移到 IPv6 并彻底改变现有的 IPv4 网络，其人力和技术成本是无法承受的。
6 Provider Edge (6PE) 解决方案的目标是通过 MPLS 骨干网将 IPv6 云互连。6PE 要求运营商的网络通过 MPLS 工作。在这种情况下，提供商的边缘由用户 CPE 遇到的第一台路由器表示。
- 保持网络核心不变（不排除将来更改的可能性）。
- 在提供商网络的边缘添加 IPv6 支持。
- 通过 MPLS/BGP 传输 IPv6 路由信息，就像在 VPN 中一样：
计算机网络技术和服务/VPN#第 3 层：BGP。
主要需求是拥有一个 MPLS 核心网络。
在图中
- MPLS 核心网络是由 PE-1、P-1、P-2、PE-2 组成的；
- 两侧设备 PE-1 和 PE-2 部分“沉浸”在 MPLS 网络中；
- CE 和 PE 之间的链路可以被认为是为家庭用户提供 ADSL 连接的链路。
6PE 的思路是采用一个完全工作的核心网络，该网络能够通过 MPLS 传输 IPv4 数据包，并在提供商的边缘路由器 (PE) 上添加 IPv6 支持仅。事实上，一旦数据包被封装成 MPLS 数据包，中间设备就不再关心所包含数据包的类型，而是只关心标签，该标签允许它们区分要路由到的 LSP。
事实上，在 PE 上需要进行进一步的更新，以便添加 MG-BGP 支持，该协议允许传输和通信 IPv4 和 IPv6 路由。
那么，这种解决方案的优势在于只需要更新 PE，而不需要更新所有中间路由器：毕竟，这是一个提供商可以在低成本下管理的操作。
- CE-3 宣传它能够到达 IPv6 网络“2001:3::/64”。
- PE-2 也收到了此信息。
- PE-2 将此信息发送给网络中的所有 PE，说明它能够通过下一个跃点“FFFF:20.2.2.2”到达“2001:3::/64”，但它的接口是 IPv4（这是因为如果 IPv6 路由被赋予 IPv6 下一个跃点，则需要提供 IPv6 下一个跃点）。
- PE-1 收到此信息。
- PE-1 将收到的信息发送给连接到它的所有路由器，包括家庭 CE，说明它能够到达网络“2001:3::/64”。
- 如果 PE-1 和地址“20.2.2.2”之间的 MPLS 路径尚不存在，则使用传统的 MPLS 机制（即 LDPv4 信号协议）来建立此路径。
为了路由 IPv6 数据包，使用两个标签
| LDP/IGPv4 外部标签到 PE-2 | MP-BGP 内部标签到 CE-3 | IPv6 数据包到 IPv6 目的地 |
- MP-BGP 标签（内部）：它标识目的地 PE 需要将数据包发送到的目的地 CE；
- LDP/IGPv4 标签（外部）：它标识 MPLS 网络上两个 PE 之间的 LSP。
假设网络“2001:1::/64”中的主机想要发送一个数据包到网络“2001:3::/64”中的主机
- 数据包到达 CE-1；
- CE-1 知道网络“2001:3::1/64”存在，并将数据包发送到 PE-1；
- PE-1 在数据包前面放置两个标签：内部标签和外部标签；
- PE-1 将数据包发送到 P-1，P-1 将数据包发送到 P-2；
- P-2 是倒数第二个跃点，它从数据包中删除外部标签（倒数第二个标签弹出），并将数据包发送到 PE-2；
- PE-2 删除内部标签并将数据包发送到 CE-3；
- CE-3 将数据包转发到网络“2001:3::/64”中的目的地。
- PE 路由器必须是双栈并支持 MP-BGP，而中间路由器不需要任何更改。
- 此解决方案为客户提供本机 IPv6 服务，无需更改 IPv4 MPLS 核心网络（需要最小的运营成本和风险）。
- 只要部署的 IPv6 云很少，此解决方案就能扩展。
人们对安全问题的经验很少，因为 IPv6 还没有得到广泛使用→ IPv6 可能仍然存在未被发现的安全漏洞，这些漏洞可能会被攻击者利用。此外，在迁移阶段，主机需要同时打开两个端口，一个用于 IPv4，另一个用于 IPv6→ 需要保护这两个端口免受外部攻击。
- 使用 SYN 泛洪的 DDoS 攻击
主机接口可以有多个 IPv6 地址→ 它可以生成多个 TCP SYN 请求，每个请求都使用不同的源地址，以使服务器打开多个未关闭的 TCP 连接，从而使服务器的内存饱和。
- 伪造的路由器通告消息
主机可能会开始发送“路由器通告”消息，以宣传虚假的网络前缀→ 链路中的其他主机将开始使用源地址中错误的网络前缀发送数据包。