我没有完整的策略，但这是我在 $JOB[-1] 上做的粗略方法：

1. 从现有运营商或 RIR 获取 IPv6 块
2. 如果您有一个 ISP 块并且可能需要重新编号，您可能还想为完全内部子网标记一个 fc00::/7（唯一本地）块
3. 决定你的 v6 IGP，IS-IS 仍然是比 OSPFv3 更安全的选择，但很多工具包不会做 IS-IS
4. 在您的核心套件上启动 v6，从互联网边缘到 DC 核心交换机
5. 启动 v6 传输，如果您必须从 he.net 连接到 BGP 隧道，则可以在等待 ISP 在过去十年中卡住的同时工作（如果您有 iBGP 网格，请记住在您的 iBGP 网格上启用 v6）
6. 创建 v6 基础设施服务，主要是 DNS，v4 可访问在这里很好
7. 在单个服务器网络上启用 v6（您可能在这里有一个默认的拒绝防火墙）
8. 测试 v6 与世界的连通性，它会破坏吗？
9. 在第二个服务器网络上打开 v6 以实现冗余
10. 如果您想使用它，请启动一个 DHCPv6 服务器
11. 在单一接入网络上启动 v6（这里 IT 人员是一个不错的选择）
12. 测试。确保万无一失
13. 在剩余的服务器网络上启动 v6
14. 为您的域添加一个 v6 名称服务器，并为 MX 添加一个 v6 DNS 条目（一个或除一个之外的所有条目都是双栈的不错选择）

现在，在启动新服务或升级它们时，您可以测试它们是否适用于 v6，并添加适当的 DNS 记录（几乎所有 Web 服务都将“正常工作”），最终您可能会开始寻找保留在 v4 上的服务并修复它们，但并不着急。

我认为在这里区分两个不同的目标很重要：

• 处理 IPv6 启用。此目标的主要问题通常与您网络中不支持 IPv6 的设备有关，您必须使用某种隧道/传输解决方案来绕过这些元素。6rd 和 6PE 很受欢迎。
• 另一方面，有应对 IPv4 地址耗尽的策略。解决此问题的唯一方法是实施某种 NAT（运营商级 NAT、DSLite、NAT64...）

有些技术解决了第一个问题，有些技术解决了第二个问题，有些技术同时解决了这两个问题。

一切都在迅速发展，您必须注意出现新的解决方案。例如。最近备受关注的一种解决方案是 MAP-E 和 MAP-T，它们目前处于草案状态（MAP-E 即将成为 RFC），允许您以非常聪明的方式实现 IPv6 和解决 IPv4 地址耗尽问题。大大地。您可以在https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-06获取更多信息

要获得更详细的信息，我需要了解上下文和要求。我的意思是，解决方案取决于网络类型（服务提供商与内容提供商或小型企业网络非常不同）以及您要实现的目标。

亲切的问候，

迭戈·纽沃

高层次的 IPv6 迁移？

1. 在整个网络中启用 IPv6，直到 IPv6 功能和连接性与 IPv4 相当。
2. 等待 IPv4 不再相关的那一天。

现在为低级：

获得一个前缀（最好是来自 RIR）并宣布它，我建议您的 IGP 使用 OSPFv3，除非您碰巧正在运行一个您认为 IS-IS 更适合的大型扁平网络。如果您拥有仅支持 IPv4 的传统设备，请考虑通过跨设备执行 6in4 或 GRE 隧道来解决此问题。

制定地址管理计划，IPv6 空间并不宝贵，如果您有 /32 并且您认为客户想要比 /64 更大的东西，请将足够的空间路由到您的设备；如果一台路由器或路由器对服务100个客户，每个人得到一个/ 56，你的IGP应该不包含每一个/ 56 -对于路由器（对）分配一个/ 48，你就大功告成了。IPv6 空间如此巨大，如果您做得对，则子网碎片永远是不必要的。

确保您运行的所有服务都是双堆栈的，无论是 DNS、电子邮件还是其他任何服务 - 在大多数情况下，这就像确保将服务配置为侦听 v6 并且您的 DNS 具有 AAAA 记录一样简单。如果您提供托管服务、服务器等，请主动通知人们他们可以双重堆叠他们的产品。

当您没有 IPv4 空间并且无法获得更多空间时，开始熟悉可以防止灾难的技术 - 密切关注 NAT64 和 464XLAT 等事物的脉搏，以便在时机成熟时，您可以确定拥有仅 IPv6 主机与使用 RFC6598 空间和 NAT44(4)。建立实验室，进行实验。

然后？等待鼓励 IPv4 结束。

虽然 IPv4 地址不再像糖果一样被分发，但这并不意味着在不久的将来完全摆脱 IPv4 是必要的或实际的。

打开 ipv6 是一个很好的第一步https://networkengineering.stackexchange.com/a/261/20201很好地涵盖了这一点。这使您可以与互联网上仅 v6 的设备进行交互，它减少了 NAT 的负载，从而减少了为这些 NAT 提供服务所需的外部 IP/端口的数量。随着 google 和 facebook 等大型服务支持 IPv6，很大一部分互联网流量可能会转移（我见过高达 70% 的数字）。

您需要问自己的下一个问题是您的组织是否大到足以面临私有IPv4耗尽的风险。对于绝大多数组织而言，答案是否定的。

假设答案是否定的，我认为在不久的将来没有理由从现有部署中删除私有 IPv4。从长远来看，摆脱私有 IPv4 可能会稍微简化管理，但从短期来看，它会带来很多额外的破坏，但收益甚微。

如果您的公共 v4 用完，下一步将是审核您的公共 v4 使用情况。寻找可以通过更改子网划分来释放的浪费的公共 v4 地址。寻找可以从公共 ipv4 迁移到 ipv6 或私有 ipv4 的系统。考虑像负载均衡器和 DNAT 这样的方案，它们可以将一个小的公共 V4 地址池应用到需要它们的地方，并且在某些情况下，在多个服务之间共享一个公共 v4 地址。

考虑部署 NAT64/DNS64 网关，以便新系统只能使用 v6，并且仍然可以访问 ipv4 互联网上的资源。