[thomasdziedzic]

IPv6 feels like we just can't admit to ourselves that it has been a failed transition. What would it take to come up with IPv7 which takes in the lessons of IPv6 and produces something better that we can all agree is worth transitioning to over IPv4.

[plqbfbv]

> What would it take to come up with IPv7 which takes in the lessons of IPv6 and produces something better that we can all agree is worth transitioning to over IPv4.

The only lesson to learn from IPv6 deployment is that if there's a workaround available and the world isn't burning, it'll take 30 years from initial design to actual adoption. So if you went out and took 10 years to design IPv7, it'd likely take until 2070 for it to gain some adoption. This is because big network hardware is costly and has very long replacement cycles.

IPv6 was already designed as a lessons-learnt protocol from IPv4 issues. The header is greatly simplified and it's more hardware-friendly, it incorporates the required features into the protocol and leaves extensibility as an optional add-on that doesn't slow down routing packets, all the while granting an infinite address space.

[throw0101c]

> IPv6 feels like we just can't admit to ourselves that it has been a failed transition. What would it take to come up with IPv7 which takes in the lessons of IPv6 and produces something better that we can all agree is worth transitioning to over IPv4.

Per Google, quite a few countries (including the US) are at >50%:

* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...

Every handset on T-Mobile US's network gets IPv6 (and they're not the only carrier like that):

* https://www.youtube.com/watch?v=d6oBCYHzrTA

So I'm not quite sure where "failed" enters the equation.

And what exactly would be different with IPv7? Anything that needs more address bits would have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A7" address (for "IPv7" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)

You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6.

[WorldMaker]

The only place the IPv6 transition seems to be failing is in "command-and-control" corporate networks. (A majority of home/consumer/cellular users are quietly using IPv6 by default every day, per most statistics.) The lessons to be learned there don't seem to be technical but economic incentives.

Big companies believe that they have plenty of IPv4 space, especially because they've always been lax in how they read IPv4 RFCs and use IPv4 routing behind corporate firewalls. Big companies also have the most cash to buy IPv4 blocks as they go to auction. Big companies have massive firewalls and strict VPNs which also insulate them from IPv4 scarcity.

IPv4 leases don't impact enough companies' bottom lines today that they need to assess IPv6 support.

Solving those economic incentive problems would likely be a massive sociopolitical problem: you would need IANA and the RIRs to agree to inflate costs in various ways (and in the short term that might have done a lot of harm to small countries already facing IPv4 inequity and their RIRs that lost the very earliest IPv4 assignment lotteries). You'd probably need new RFCs and political enforcement to support things like "taxing" company to company IPv4 block assignments. You'd probably need collusion or regulation from the big "Cloud Providers" to enforce higher costs on IPv4-only networking.

It would take those kind of "strong handed" tactics to speed up IPv6 adoption in corporate networks. Waiting for the "invisible hand" of the "free market" can be very slow and takes patience. That's mostly what we've been seeing with IPv6 adoption: the "invisible hand" is a lot slower than some people predicted. Especially engineers that hoped technical superiority alone would be a market winner.

[apearson]

What changes to IPv6 would you make to make it easier to transition?

[general1465]

Whole model same as IPv4 (DHCP, NAT, ICMP, DNS, ...) just in v6. If IPv6 and IPv4 would be essentially the same from the get go, IPv4 would be a niche 20 years.

Sure everything above IPv6 have, but it took years and years of screaming to get it.

[throw0101c]

> Whole model same as IPv4 (DHCP, NAT, ICMP, DNS, ...) just in v6.

All of those things exist in IPv6.

And it is physically impossible for DNS to be the same, as you have to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A7" address (for "IPv7" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.

[general1465]

> All of those things exist in IPv6.

And it has not existed at the start of the IPv6 and is one of the many reasons why after all those years we are having a poor penetration of IPv6.