[Dagger2]

Do I? I don't have v4 on this machine and I can reach GitHub, so that appears to be untrue. Also GitHub would need to continue having v4 so that v4 users could reach it, so it's untrue from that perspective too.

At some point or another, you have to do the work to support longer addresses. In your proposal, where is that work being done? Because right now it looks like you're either massively underestimating how much work it is or you're just outright ignoring it, but only for your own proposal and not for v6.

[mahboi]

Github.com doesn't have an AAAA record, so I don't know how you're reaching it if you don't have a v4 anywhere. Even if they had that, they said that basic features like cloning repos won't work over v6. Only one example of many services like this.

> In your proposal, where is that work being done?

Work for longer v5 addrs would be similar in difficulty to what v6 had to do, but it'd be done at a different time and place. Only thing that's the same is you need a new packet format that hardware can read, which could literally be the v6 format repurposed. I'd say 8 bytes is enough, leave the rest as 0s.

Ipv5 would share routing tables, DHCP, DNS, NAT, and various middleboxes with ipv4, unlike v6 which made separate versions of those with their own state. V5 with 4-byte addrs works with those instantly, no chicken and egg. Then those get patched or replaced to support longer addresses. Importantly, the upgraded versions easily support ipv4 too, so there's no reason not to upgrade.

[Dagger2]

  $ wget -4 https://github.com/HackerNews/API
  Resolving github.com (github.com)... 140.82.114.4
  Connecting to github.com (github.com)|140.82.114.4|:443... failed: Network is unreachable.
  $ git clone https://github.com/HackerNews/API
  Cloning into 'API'...
  remote: Enumerating objects: 142, done.
  remote: Counting objects: 100% (53/53), done.
  remote: Compressing objects: 100% (21/21), done.
  remote: Total 142 (delta 38), reused 32 (delta 32), pack-reused 89 (from 2)
  Receiving objects: 100% (142/142), 67.87 KiB | 668.00 KiB/s, done.
  Resolving deltas: 100% (39/39), done.

Seems to work fine.

> Ipv5 would share routing tables, DHCP, DNS, NAT, and various middleboxes with ipv4

Which is great, but all of these things are 4 bytes only. You need a separate set of tables etc for the longer addresses. Also v6 already shares all of these things and works with them instantly when working with 4-byte addresses, so this isn't new.

> Then those get patched or replaced to support longer addresses. Importantly, the upgraded versions easily support ipv4 too, so there's no reason not to upgrade.

Yes, like with v6. I would expect people to find endless excuses to never do the patch or replace part or to just refuse to configure their gear to enable longer addresses, like they do with v6.

All this leaves me wondering why this approach is bad when v6 came up with it but good when you came up with it.

[delotrag]

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.

[mahboi]

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

[delotrag]

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

[mahboi]

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.

[Dagger2]

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

[delotrag]

https://xkcd.com/1112