Meant that the states in those boxes work with ipv5. Yeah a totally unmodified ipv4 DHCP server would only accept queries over v4, but the address it leases would be valid for v5 too. I get why this part was unclear, it was assuming the aforementioned part about making things parse v5 packets was already done. Also doesn't make a lot of sense that a DHCP server would parse v5 but not support 8-byte addrs, but it could happen particularly if you put v5-v4 translation outside the box. The separation makes more sense for software-defined routers, where just making it able to parse v5 is a whole separate task from upgrading the routing tables to support 8 bytes.

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

> 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.

I guess I don't understand. This seems to boil down to: expand the address space, but don't actually use the additional space until a flag day that occurs after every piece of networking equipment on the Internet gets upgraded? Surely there would be even _less_ incentive to upgrade, because instead of getting local benefits that are incomplete until the entire network upgrades, you get _no_ benefits until the entire network upgrades.

This seems strictly worse than the situation we have now, where at least locally, you can reap benefits from IPv6's expanded address space. I benefit from having a routable /56 at home, even though I can't get to it from some legacy networks.

You can use the 8-byte addresses earlier if you want, just requires your hosts and stuff in between to support v5, same story as with v6 there.

The point is that you aren't asking everyone to do nearly as difficult of a migration to support v5. Github would've been on it already, all the v6 pieces are already there.

Except you are, because all the same work needs to be done.

> You can use the 8-byte addresses earlier if you want

You can't have both this and "The 8-byte phase only starts when v4 has been abandoned" simultaneously. Decide whether you want a flag day or not and then be consistent about it. (And when you're deciding, bear in mind that flags days on the Internet are impossible.)