|
|
|
|
|
by delotrag
36 days ago
|
|
What do you mean when you say IPv5 works "instantly" with v4 routing tables, DHCP, DNS, and NAT? I think you're misunderstanding that any way you slice it, there will be a protocol translation. We already have many protocol translation options for v4<->v6, like NAT64, which I believe was referenced obliquely in the discussion about GitHub. You should consider, if this "v4 with more bytes" idea works so well, why hasn't it been done already? Why hasn't anyone shown this idea working in practice? I'd say the answer is that, when discussing it in the abstract, it's easy to get confused by the printed address representation and miss that you're building in implicit protocol translations you don't realize have the exact same deployment difficulties as IPv6. Take DNS as an example- when you say it works "instantly," I assume you mean "v4 works as normal, v5 reads A records and appends a zero byte"- congratulations, you've invented DNS64. |
|
Packet translation isn't strictly needed. Yeah in the 4-byte-addr phase, you could stick translators directly next to boxes, but probably better to just wait for at least routers to parse v5 packets natively. Then for the rest you do something like happy eyeballs to fall back from v5 to v4. The 8-byte phase only starts when v4 has been abandoned.
> I assume you mean "v4 works as normal, v5 reads A records and appends a zero byte"- congratulations, you've invented DNS64.
Yes to how v5 DNS works, but DNS64 doesn't work that way. It gives you a v4-mapped-v6, your packet goes there, and NAT64 translates the packet to v4. So you're still relying on ipv4, plus it takes a notoriously unpredictable route to reach the NAT64.
You could say that ipv5 is kinda like if you made v4-mapped-v6 the only way to use ipv6, didn't do NAT64, and then expanded those to >4 bytes at a later time.
> why hasn't it been done already?
It must've been considered. I'm guessing it's one or more of the IETF way back in 1998:
1. not wanting to maintain the old ipv4 blocks going forward, rather start with a clean slate to build more efficient routes
2. seeing the ipv6 design with SLAAC etc as more elegant, which in some ways it is, but some parts also didn't age well, hence the privacy extensions added later
3. thinking people would be more willing to switch
4. overestimating how many people wanted P2P connections; they were originally recommending v6 default-allow inbound, then later said consumer routers should default-deny, but this is still less idiotproof than NAT