又一个IPv5提案

3 分•作者: bigcityslider•大约 1 个月前•原帖

在引入超过30年后，IPv6仍未取代IPv4。我之前见过那些“只需为IPv4添加更多位，称之为IPv5”的提案。它们往往忽略了重要细节，且与他人讨论时有些偏离，但它们确实有道理。在经过一段时间的细化后，我认为这实际上是可行的，它将带来显著的变化，并且可以在当前的IPv6头部下实现。背景... 假设IPv6数据包格式在路由器、主机等设备上已经得到了充分支持。这不再是障碍，反而是许多互联网服务提供商、像Github这样的网络服务和企业网络选择不采用IPv6。家庭路由器只是启用了IPv6，但对于服务来说，这并非易事，因为它与IPv4在各个方面都是一个独立的网络，需要进行大量的配置更改。最终结果是，几乎每个人都需要IPv4，而许多人使用IPv6但并不依赖它。 IPv6绝对需要一种新的数据包格式来支持超过32位的地址。但它还做出了更多选择，其中最大的选择是从一个全新的拓扑开始，而不是在现有的IPv4地址块下扩展空间。我理解这样做是为了摆脱IPv4的碎片化路由，并创造更公平的地址拥有权。其他选择更多是关于默认设置，比如优先使用SLAAC而不是DHCP，或者缺乏NAT。IPv6的支持者常常将这些选项呈现为两全其美，但实际上，默认设置更为重要，例如Android甚至不支持DHCPv6。而且，大多数路由器默认拒绝入站的IPv6 TCP/UDP连接，但并非所有路由器，可能是因为RFC 6092，REC-49的原因。 IPv6有几个扩展来简化从IPv4的过渡，我在这里不一一列举。共同的主题是，你在这些扩展上仍然在使用IPv4。这些措施有所帮助，但从IPv4到双栈的过渡总是需要一个飞跃，而从双栈到仅IPv6的过渡则更为艰难。提案，第一阶段... IPv5是一个在IPv4接口上切换的布尔设置。它与IPv4共享所有内容，除了数据包格式，实际上是一个带有5000:前缀的IPv6数据包。因此，如果你拥有1.2.3.4，现在你就有了5000:1.2.3.4。因此，IPv5拥有120位的地址空间。但在这一初始阶段，你仍然限于32位，以保持与IPv4的兼容性。关键是让每个人都能使用IPv5，而无需重新配置任何内容。这也需要对DHCP、NAT和DNS进行升级，以支持120位地址，但与IPv6不同，这些新版本仍然可以与IPv4客户端通信。一个IPv5主机仍然可以从1.1.1.1的DNS读取A记录。如果一个仅支持IPv4的主机被分配了192.168.1.2，那么在同一网络上的IPv5主机会将其视为5000:192.168.1.2，因为它们处于相同的状态。由于上述原因，IPv5和IPv4的数据包遵循相同的路由，网站对两者赋予相同的信誉，从而避免了用户在使用IPv6时最常见的问题。唯一的问题是，如果一个IPv5主机与一个仅支持IPv4的主机通信，会发生什么？路由器可以在知道下一个跳转的路由器/主机是仅支持IPv4时，将IPv5转换为IPv4。或者两端可以使用类似Happy Eyeballs的方式。实际上，IPv5与IPv6如何使用DNS来简化切换是平行的，只不过是在第三层进行。提案，第二阶段... 你只有在主机准备禁用IPv4时才能达到这一阶段，可能是因为世界已经充分采用了IPv5，或者因为它只需要与已知的IPv5主机通信。你将接口设置为仅IPv5模式。现在你的5000:1.2.3.4可以拆分为5000:1.2.3.4.1等等。任何在IPv5+IPv4环境中未收到通知的人仍然是兼容的。 DHCP和NAT仍然是默认设置，但每个ISP的客户都很容易拥有足够的地址来禁用NAT和/或在需要时使用SLAAC。回到IPv6... IPv5并不是为了取代IPv6。IPv5主机可以与IPv6主机通信。如果一个IPv5接口接收到RA数据包，它可以直接切换到IPv6。切换到IPv6可能是清理IPv4遗留路由的最简单方法。

查看原文

Over 30 years after its introduction, IPv6 has still not replaced IPv4. I've seen those "just add more bits to ipv4, call it ipv5" proposals before. They tend to skip the important details and talk past others, but they have a point. After filling in the details over time, I think this actually works, it'd make a serious difference, and it's doable with the current IPv6 header.<p>Background...<p>Let's assume the IPv6 packet format is already sufficiently supported on routers, hosts, etc. That's not the blocker anymore, rather plenty of ISPs, web services like Github, and corporate networks have chosen not to adopt IPv6. Home routers just enable it, but it's nontrivial for services because it's a separate network from v4 in every way, requiring extensive config changes. End result, almost everyone needs a v4, while many use v6 but don't depend on it.<p>IPv6 absolutely needed a new packet format to support >32-bit addrs. But it made more choices beyond that, largest of which was starting with a fresh topology instead of expanding the space under the existing IPv4 address blocks. I understand this was to ditch v4's fragmented routes and create fairer ownership.<p>The other choices were more about defaults, like SLAAC over DHCP, or lack of NAT. IPv6 proponents often present the options as the best of both worlds, but in reality the default is more important, for example Android doesn't even support DHCP6. And most routers deny inbound v6 TCP/UDP connections by default, but not all, maybe because of RFC 6092, REC-49.<p>IPv6 had several extensions to ease the transition from v4 that I won't list here. The common theme was you're still really using IPv4 on those. These things helped, but there's always a leap from v4 to dual stack and an even bigger leap from dual to v6-only.<p>Proposal, phase 1...<p>IPv5 is a boolean setting toggled on an IPv4 interface. It shares everything with v4 except the packet format, which is actually a v6 packet with a 5000: prefix. So if you owned 1.2.3.4, now you have 5000:1.2.3.4. IPv5 therefore has 120 bits of address space. But in this initial phase, you're still limited to 32-bit in order to maintain compatibility with v4. The point is to just get everyone onto IPv5 without making them reconfigure anything.<p>This also requires upgrades to DHCP, NAT, and DNS to support 120-bit addresses, but unlike v6, the new versions of those still talk to v4 clients. A v5 host can still read A records off 1.1.1.1 DNS. If a v4-only host gets 192.168.1.2 assigned, a v5 host on the same network sees that as 5000:192.168.1.2 due to the common state.<p>As consequences of the above, v5 and v4 packets follow the same routes, and websites assign the same reputations to both, avoiding the most common end user problems with IPv6.<p>The only snag here is, what happens if a v5 host talks to a v4-only one? Routers could translate v5 to v4 when they know the next hop router/host is v4-only. Or the ends could do something like Happy Eyeballs. In fact v5 is parallel to how v6 uses DNS to ease the cutover, except it's at layer 3 instead.<p>Proposal, phase 2...<p>You only reach this phase when a host is ready to disable IPv4, either because the world has sufficiently adopted v5 or because it only needs to talk to known v5 hosts. You put the iface into v5-only mode. Now your 5000:1.2.3.4 can be split into 5000:1.2.3.4.1 and so on. Anyone on v5+v4 who doesn't get the memo is still compatible too.<p>DHCP and NAT are still default, but each customer of an ISP easily has enough addresses to disable NAT and/or use SLAAC if desired.<p>Back to IPv6...<p>IPv5 isn't meant to replace IPv6. V5 hosts can talk with v6 hosts. And if a v5 iface receives an RA packet, it can just switch to v6. Shifting to v6 is probably the easiest way to clean up the routes left over from v4.