[Dagger2]

Why the double standard?

v6 already gives you what you're asking for here: you can turn it on without thinking about it, but actually using the extra addresses from it requires reconfiguring some things (not everything, mind).

Why is that bad when it's v6 doing it, but good when it's your 5-byte thing doing it? Or did you just not think through this enough to realize you were asking for something we already have?

[mahboi]

Because you can't generally turn on v6 without thinking about it. Maybe consumers can, even then not always cause it messes random things up. Power users and offices maybe can't. Service operators really can't. If it were as easy as you're saying, all those things like Github would already at least support v6.

[Dagger2]

Windows, Linux, OSX, Android and iOS all ship with v6 enabled by default out of the box, so it's already turned on without you needing to think about it. You have to deliberately go out of your way for this not to be the case.

> If it were as easy as you're saying, all those things like Github would already at least support v6.

This isn't the "turn it on" stage, it's the "people can start putting something besides 0 into that last byte" stage.

[mahboi]

You need ipv4 to reach GitHub right now. The ipv5 "people can turn it on but not use the last bytes" stage wouldn't require ipv4 to reach it.

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