Tech
你真的还需要IPv4吗？
如今，搭建和维护接入网络需要双倍的努力，因为IPv6和IPv4的并行共存。双栈网络工程师和系统管理员要做的工作量翻了一番，这背后肯定有充分的理由，对吧？
答案是“可能不需要了”！除了那些在近30年后仍不支持IPv6的局域网设备外，IPv4网络实际上已不再需要。即便在这种情况下，也有解决方案可以大幅减少这一问题的影响。
我们将讨论从接入网络中移除IPv4的当前最新技术。它如何实现、需要什么条件，以及如何在这种转变过程中处理大部分问题。
首先，让我们明确一个显而易见的事实：大多数设备将不得不与遗留服务通信。尽管对此的借口正在减少，本文不会反驳这一点。
幸运的是，仅支持IPv6的设备仍然可以与仅支持IPv4的设备通信，而且这比以往任何时候都更容易。但是怎么做到的呢？
NAT64
因为IPv6拥有比其遗留对应版本多得惊人的地址，我们可以将世界上每一个IPv4地址映射到单个IPv6子网的一小部分。我们可以将1.1.1.1映射到2a0d:3dc0::1.1.1.1，将8.8.8.8映射到2a0d:3dc0::8.8.8.8，等等。
通过这种方式，一个仅拥有IPv6地址、没有IPv4的设备仍然可以向遗留主机发送数据包。它只需要发送到与以前不同的地址。
但是这个数据包如何到达目的地呢？
我们需要一个同时拥有IPv6和IPv4的设备来为我们做这种转换。这个设备可以是本地路由器，甚至可以跨越整个互联网。它需要做的很简单：
对于发往这个特殊转换前缀的传入IPv6数据包，创建一个目的地地址与IPv6目的地址编码相同的IPv4数据包。源地址则使用你自己的一个地址。
对于发往这些特殊IPv4 NAT地址的传入IPv4数据包，查找发起者，然后将其转换为IPv6，并发送回给他们。
这与IPv4世界中的NAT工作原理完全相同，除了协议间的转换。如果你现在正在为IPv4做NAT，使用这种方法你不会失去任何东西。一切仍然以相同的方式工作，包括端口转发。
但你如何知道这个可以发送数据包并将其神奇地转换为IPv4数据包的神奇前缀呢？
快速答案是，有一个特殊的前缀被分配给这个确切的目的，即64:ff9b::/96。但这需要设备知道它，并且不能保证一定有效，可能会有点棘手。有些设备会尝试查看转换是否发生，并使用它，但这并不是最佳方式。有更好的解决方案：
DNS64
这是DNS中的一个聪明技巧。你使用的是一个特殊的DNS解析器，它的作用如下：如果你收到一个关于非A(IPv4)DNS记录的问题，那么正常回应。如果有人询问具有AAAA(IPv6)记录的域名地址，只需给他们就是了，因为他们有IPv6，将会顺利连接。但是，如果你被问到一个A记录，那么就“欺骗”他们。告诉他们one.one.one.one的地址不是1.1.1.1，而是64:ff9b::1.1.1.1的AAAA记录。
现在我们实现的是以下情况：
如果我连接到daknob.net并且它有IPv6，我会没问题。
如果我连接到github.com而它没有IPv6，我会被告知它有IPv6，并且我只需要在64:ff9b::A.B.C.D.这个地址下访问它。我的设备会向这个地址发送数据包，而我们之前看到的NAT64会神奇地将它们转换成IPv4数据包。
现在，任何建立的连接到任何域名都会像魔法一样工作。但是硬编码的IPv4地址怎么办？如果我的电脑没有IPv4，我ping或ssh到比如8.8.8.8，我会收到一个错误消息，它不会工作。为什么会这样？因为我没有询问智能DNS64服务器，我试图直接连接到一个IP地址，这是不可行的。
我们能做些什么呢？
CLAT
由于世界上许多移动网络(5G、4G等)仅支持IPv6，没有IPv4，幸运的是，已经有解决方案了。它已经内置在iPhones、安卓设备和Macs等设备中，并且是它们操作系统的一部分。唯一的区别是它们也在WiFi上启用了它，而不仅仅是在数据连接上。
当启用了名为CLAT的机制时，设备会为本地接口分配一个IPv4地址，通常是192.0.0.2，任何发送到这个IPv4地址的东西都会通过操作系统的IPv4->IPv6转换。
虽然这不是一个真正的IP地址，也没有分配到一个真正的物理接口上，但一切仍然运行得很好。如果有数据包在没有使用DNS的情况下发送到8.8.8.8，应用程序会将其传递给操作系统，操作系统会撒谎说IPv4存在，并将这个转换成IPv6数据包，并在幕后通过IPv6发送。
这很棒：所有应用程序，即使是那些直接连接到IPv4主机的应用程序，没有DNS，也会运行得很好。所有的遗留流量都将通过IPv6传输，它们甚至不需要知道IPv6是什么！
但是，这个“CLAT”东西什么时候开启？它肯定不能一直开启……
这实际上略有不同，取决于操作系统，有些通过检查DNS64和工作NAT64的存在来确定这一点，但有一个更好、更可靠的机制：
PREF64
当设备连接到网络并且需要接收IPv6地址时，使用一种称为SLAAC的机制。也有IPv6的DHCP，但它并不像SLAAC那么好。路由器向设备发送的前缀中的一些属性，就像IPv4一样，包括要使用的DNS服务器等。
可以传输的这些属性之一称为PREF64。这可以包括NAT64魔法前缀，以便所有客户端都被告知提供此类服务，并可以使用。
对于苹果操作系统和设备，以及几个主要版本，这个值的存在会自动启用CLAT。对于安卓和Windows，这通常也足够，但两者都更加碎片化，不能绝对确定。
但是，对于那些甚至无法获得IPv6地址的设备怎么办？
路由器处的转换
不幸的是，即使IPv6引入已经近30年了，仍然有一些设备无法获得IPv6地址。它们几乎总是IoT/“智能”设备或非常老旧的设备。这些设备仍然需要连接，所以我们不得不想出一个解决方案。
答案是简单的：让路由器为它们做转换。对于需要它的局域网，你添加一个IPv4地址，你像平常一样设置DHCP，但不是路由那个网络，而是在它进来的那一刻就把它转换成IPv6。
有两种方法可以做到这一点：
CLAT + NAT44
第一种方法是在你的路由器上也进行CLAT，并进行NAT44(传统的IPv4 NAT)到虚拟IP地址。现在所有传入的IPv4流量都将被转换成IPv6，然后通过网络发送。
这实际上是移动设备在热点功能下连接设备时会做的事情。
SIIT
另一种方法是使用SIIT。这是一种无状态机制，所有IPv4流量都被编码在IPv6数据包中，无论是源还是目的地。为了更好地理解这一点，让我们看一下以下图表：
SIIT的工作原理
“智能”灯泡有一个IPv4地址。这个地址只需要在它的路由器内是唯一的。如果你有100个路由器，它们都连接着10.1.1.0/24，那也没关系。
这个设备现在将其所有流量发送到具有IPv6连接性的本地路由器，但路由器也有一个特殊的IPv6前缀。当收到IPv4流量时，所有数据包都会无状态地转换成IPv6，通过将最后32位设置为设备的源IPv4。目的地也是无状态的：它是NAT64魔法前缀加上目的IPv4的最后32位。
当该数据包转发到NAT64时，它将被有状态地翻译并映射到一个公共IPv4地址并分配一个端口号。
在继续在本地网络和/或互联网上传输后，它将到达目的地，得到响应，NAT64将发送其响应：
源IP将是64:ff9b::8.8.8.8，目的IP将是2a0d:3dc0::10.1.1.2(路由器的SIIT前缀，加上10.1.1.2)。
当路由器收到这个响应时，它将无状态地将其转换回IPv4，并发送一个源IP为8.8.8.8，目的IP为10.1.1.2的数据包给灯泡。
旁注：你可能注意到SIIT前缀是/96(32位)，而我们只有一个IPv4 /24(8位)。这可能看起来浪费，但考虑到我们拥有的IPv6地址数量，将所有IPv4映射而不是单独的局域网是可以的。一个典型的住宅客户无论如何都会获得72位的公共IPv6 ;)
由于接入路由器往往是小型的，甚至可以是便宜的CPE，无状态转换总体上需要较少的资源。
混合接入
这很棒，我们可以使用仅支持IPv6的设备实现现代和旧互联网的端到端连接。但有时我们可能会有一个局域网，其中一些设备运行良好，而其他设备仍然需要IPv4。或者，可能是分几个阶段进行的IPv6(仅限)迁移。
一旦我们打开DHCP，所有设备也会获得IPv4地址，并且它们可能无法充分利用我们的仅支持IPv6的基础设施，或者可能会不必要地将大量转换任务卸载到路由器上，而它们完全有能力自己执行这些任务。
这就是IPv6-only优先DHCP选项的用武之地。它是一个标准(RFC8925)，任何能够在仅支持IPv6的环境中运行的设备都会在IPv4地址的DHCP请求中包含这些信息。基本上，当它们请求IPv4地址时，它们告诉网络，除非没有支持仅支持IPv6的操作，否则它们不需要它。
如果DHCP服务器意识到这一点，或者只是盲目配置为回复，它将告诉它们它理解请求，并且不会分配IPv4地址。
这里的好消息是，我们现在能够拥有一个单一的局域网，所有对自己的仅支持IPv6能力有信心的设备都可以完全跳过IPv4部分，而所有其他不知道发生了什么的设备将尽力进行仅支持IPv6的操作，或者他们将退回到IPv4(aaS over IPv6)以获得连接。
根据APNIC在2022年的一篇文章，在他们的一个活动中，WiFi网络使用这个DHCP选项运行，65%的设备没有获得IPv4地址，因为他们向服务器发送了这个信息。这与我的前同事Jen在她关于这项技术的IETF草案中报告的范围相同(60%-70%)。根据我自己的经验，运营一些公共/开放WiFi网络，这在某些环境中可以达到85%。
DHCP选项108，也称为DHCP Option 108，有几个好处：
它减少了对IPv4的需求(需要2x-4x更小的子网)
它暴露了IPv6连接性的问题(因为它们不再被平滑回退到IPv4所掩盖)
它允许更慢、更平滑、更可控的过渡到IPv6
NAT64与NAT44
由于IPv4地址有限，大多数网络无论如何都需要某种NAT才能到达IPv4。无论你是将IPv4翻译成IPv4还是IPv6翻译成IPv4，最终结果都是一样的。但实际上，运行NAT64网关比运行NAT44或CGNAT网关在操作上更容易。
NAT44的工作原理是，有一个设备位于流量的关键路径上，重写源IP和端口。所有需要NAT的流量都必须通过这些设备，除非你执行复杂的策略路由，否则它们必须位于私有IP空间和互联网之间。
对于NAT64来说，情况并非如此。所有需要到达IPv4网络的流量都会流向NAT64前缀，它可以在网络上的任何地方。事实上，如果你使用一个公共IPv6地址，它也可以在你的网络之外，在整个互联网上！就所有路由器而言，这是IPv6单播流量。
这允许极大的灵活性：从接入设备到互联网的关键路径可以运行在100%无状态IP路由器上，使用高端硅片或甚至Tbit级软件路由。然后，前往IPv4网络的流量可以分支到一个完全独立的路径，进行翻译。这些NAT64网关的路径可以通过你的IGP控制，如OSPF、IS-IS或BGP，并且可以像任何高可用性、水平可扩展服务一样进行管理。
你不需要将流量分散到50个CGNAT盒子中，并试图均匀地做到这一点，当你可以简单地添加50个NAT64网关，所有这些网关都通过OSPF广告NAT64前缀，每个都有自己的IPv4和端口池，让ECMP处理其余的事情。当其中一个宕机时，前缀被撤回，新连接击中剩余的网关，无需任何干预，几秒钟内完成。
你还可以在全国各个地点运营NAT64服务。
例如，ISP可以在每个城市都有这些网关，将所有翻译保持在用户的本地。如果一个城市的服务器(但不是网络)出现故障，或者简单地需要重启进行更新，最近城市的翻译器将接管工作。
单IPv4安装
部署一个IPv6优先或仅IPv6网络不需要高级路由、自治系统、BGP或你自己的地址。这里描述的一切都可以在一个住宅互联网连接中发生，它通过PPPoE获取IPv4地址，并通过DHCPv6-PD获取/56的IPv6空间。事实上，我很快会发布一篇文章介绍如何在这里实现，所以请订阅我的RSS Feed :)
但在这种情况下，你将IPv6翻译到哪里呢？
你可以在你的路由器的回环接口中添加一个私有IPv4地址，例如10.10.10.10，然后将其NAT64翻译。现在所有的IPv6流量都会被翻译成10.10.10.10，这将反过来被你的WAN IPv4地址伪装。
你不需要静态IPv4地址，甚至不需要超过一个主地址，你只需要确保——就像IPv4一样——你有足够的源端口来应对你的流量量。
现有的ACL怎么办？
如果你在运行一个企业网络，你可能在各处有很多引用你的IPv4地址的访问控制列表和防火墙规则。在转向主要使用IPv6的情况下，尤其是如果接入网络首先升级，你可能需要NAT64来到达你的基础设施的其他部分。
例如，IT可能使用10.0.0.0/24，开发人员可能使用10.0.1.0/24，根据源IP，他们可能会或可能不会获得访问10.0.10.0/24 LAN中各种服务的权限。
当IT和开发人员迁移到IPv6时，你的NAT64可以检查源IPv6地址，然后将每个LAN映射到该网络内的IPv4地址。你可以分配一个新的地址(例如10.0.0.254)，或者你也可以使用路由器的地址(例如10.0.0.1)。现在所有的IT在10.0.10.0/24中的服务器看来都是10.0.0.254，这应该仍然在他们现有的ACL之内并被允许。
充满希望的未来
有了现有的IPv6过渡机制和当前的操作系统和软件支持状态，不仅在网络设备上，也在终端设备上，我真诚地相信许多现代接入LAN可以在没有问题的情况下运行仅IPv6设置。我在现实世界中看到了这种情况，在大型企业和企业部署中，问题非常少，大多数问题都可以轻易解决。
此外，过渡可以平稳进行。在现有的仅IPv4网络中，你只需简单地打开IPv6，进行双栈操作。你可以从小的SLAAC定时器开始，例如5或10分钟，并从你的更多技术用户开始。如果有什么不对劲，你随时可以关闭它。
然后你可以设置NAT64。通过手动更改你的DNS服务器到一些设备来验证它是否工作。如果没有，就恢复它。然后逐步将更多的LAN移动到NAT64 DNS服务器，这又可以从小的定时器开始，并且很容易逆转。
下一步可以是在SLAAC中添加PREF64，看看很多设备开始转向仅IPv6。你猜对了！这也可以通过小的定时器来完成，并且也可以很容易地逆转。你可以先对几个VLAN这样做，然后逐渐推出。
最后，你可以让你的DHCPv4服务器发送选项108，如果你仔细观察，它只有一个32位的值：一个计时器，以秒为单位！所以即使这个也可以导致一个平稳的推出。