IPv4 is never going away barring massive adoption of p2p protocols to drive the switch. Sadly NAT and SNI solve most of the problems well enough for things to limp along indefinitely. The only orgs with the power to fix this from the top down are incentivized to maintain the centralized status quo.
This was considered likely when IPng was being discussed in 1990s:
Furthermore, we note that, in all probability, there will be IPv4
hosts on the Internet effectively forever. IPng must provide
mechanisms to allow these hosts to communicate, even after IPng
has become the dominant network layer protocol in the Internet.
Yep. And the reason they were successful is because you can solve the problem on your end without the other end needing to do anything. IPv6 requires both parties to do something. So now we're stuck with NAT and SNI.
> what kind of p2p protocols are you thinking of ?
Skype was originally P2P, but because of NAT there had to exist "supernodes" which did STUN/TURN/ICE shenanigans to make it work (which caused scaling issues since there weren't enough of them):
file sharing, messaging, gaming, VOIP/VideoOIP, etc. basically everything we have today that has to route through a gateway in the cloud could be p2p . They actually all were int he 90s (e..g Napster, Limewire, ICQ) until vulnerabilities drove investment in aggressive firewall
When I used a small local ISP that did not support ipv6 before switching to AT&T fiber¹ I tried to set this up, but they demand an email on a non-gmail domain, and I wasn't going to pay to set that up nor was I going to use my work email. It's a bad assumption that any non-malicious user cares enough about websites to have one.
1: I'd prefer to have stayed with the local ISP despite the lack of ipv6, but they wanted $8,000 to bring fiber to my new place and that was not worth it with at&t fiber being present.
Gmail is a cesspool, and Google couldn't give the slightest bit of a shit. So does it really surprise you that people who share free services might not want to give those free services to people who use the cesspool service that doesn't care about abuse?
I've done a few ipv6 migrations. The IPv6 fan community (e.g on reddit and other forums ) needs to accept a dual-stack world and the doubling of complexity required to operate that way. All effort should be about education and support for dual stack. That will be the only successful path to ipv6 adoption.
Sure ipv6 has some better features, but dual-stack means you are doubling all of your config (ACLs, naming, firewalls, routing) test cases and vulnerability surface. Moreover, ipv6 is not as intuitive.
Shaming people into ipv6 will never work. More effort should be invested into best practices, patterns, migration guides, support communities & more to assist in operating in a dual-stack environment for the foreseeable future.
Pure ipv6 will never happen because the weak link breaks the chain. How many people set up an ipv6 VPC with great excitement, and late in the project they deploy from github with "NS lookup failed".
So IPv6 is about 30 years old, and the testimony being shared is the chair of the group spending years of research and millions of dollars, finally launching ipv6 corporate lans in 2023.
There's been endless effort into all of those things. What else are we supposed to do when people just aren't following them anyway?
It's not even double the config. For e.g. my firewall, which is a 300-line config that I've already designed and implemented, making it dual stack mostly involves writing "domain (ip ip6)" instead of "domain ip". That's simply not double.
It's not less intuitive than v4 either. That's a lack of experience talking. Meanwhile, trying to use v4 quickly devolves into needing to use NAT, which is less intuitive.
> Pure ipv6 will never happen because the weak link breaks the chain. How many people set up an ipv6 VPC with great excitement, and late in the project they deploy from github with "NS lookup failed".
My desktop is pure v6 and GitHub works fine, which I think disproves the "never" part.
double the firewall, double the listening sockets to manage, double the testing (e.g. my router was working ipv4 and broken ipv6 with the same daemon), double the app-level ACLs
You can argue "it's only one line" but that one line is a new socket and new test variant needing testing. something that worked perfectly well for 5-10 years now needing a re-test.
I'm not arguing against ipv6 . I'm arguing for honest assessments of the effort needing to migrate a network , especially residential networks, to IPv6 -- as the only way to make it happen. Shaming people with "it's so easy and simple" is just dishonest and doesn't help the cause.
I did this for a couple days when Comcast's DNS was fucking up when I moved into a new place and was stuck with their modem/router/AP for a bit (which was locked to like 6.6.6.6 or whatever it was).
Tried explaining it to several customer support techs but they all just gave up eventually.
Was fixed when I ended up getting my own modem and router/AP.
But those were an interesting few days. My partner was annoyed they couldn't use Pinterest but YouTube loaded fine. Google search worked but our local pizza joint's site didn't.
My networks are IPv6 only for a couple of years, but I do have to run NAT64 (jool) and use a DNS64 resolver (i use a google-provided, but you could run your own)
It had very little benefits at the beginning, but having dedicated publicly routed addresses started to become really conevinent.
IPv6 with a regulary changing dynamic prefix still sucks though to this day ... :-(
Huh, why IPv6 only instead of dual stack? Assuming you're talking about a home or small business network
The (occasionally, on Comcast) changing dynamic prefix was a pain for me too, when accessing things externally. For internal use I additionally set up a fixed ULA prefix.
The way I do this, my internal DNS resolves hosts to their fixed ULA addresses. For the handful that are accessible externally, public DNS resolves to their address on the current public prefix.
But I have to admit, that I ended up buying my own IPv6 block from a local ISP and tunnel to them. They have great interconnections, so bandwidth is not an issue, and latency penalty is less then 2 ms an average.
This guy cyber securities. Last thing I want are an infinite number of additional attack vectors on what will inevitably be a feeding frenzy of zero day exploits(not in the protocol but the implementation)
> Nowadays I consider IPv4 address scarcity almost a feature ...
The real godsend of IPv4 is that it accidentally forced NAT.
This saved, through the decades, hundreds of millions of vulnerable machines from being directly exposed and owned.
I consider IPv4 saved us from Windows botnets affecting nearly the entire world.
No, NAT is not security. But accidentally it prevented oh-so-many machines from getting owned.
When I got my first Internet connection I could literally access other people's Windows machine for my ISP was putting me on the same LAN as other people. I'd do silly things like have "Your Windows machine is insecure" printed on their printers. This was in IPv4 times: my ISP would put me on a subnet with 256 other machines (I'm talking about times where a 28.8 modem was still a thing btw).
I cannot being to imagine the total and complete chaos had IPv6 existed back then.
People don't understand how insecure and wild things were back in the days.
IPv4 saved the Internet, accidentally, thanks to NAT.
The only thing NAT achieved is that it leads people like you, who know little about it to believe it somehow increased security, which is completely wrong.
Any Firewall can simply block all incoming traffic and it would have the same effect as NAT, without the computational overhead that NAT incurs...
Thread was pretty much a greenfield deployment at the time, so it use of IPv6 was easy to specify. There was now legacy IPv4 to support or otherwise it would probably be a mess as well.
Readit News
So get out there and p2p
This was considered likely when IPng was being discussed in 1990s:
* https://datatracker.ietf.org/doc/html/rfc1726#section-5.5Skype was originally P2P, but because of NAT there had to exist "supernodes" which did STUN/TURN/ICE shenanigans to make it work (which caused scaling issues since there weren't enough of them):
* https://spectrum.ieee.org/skype-scuppered-by-problem-with-su...
* https://www.zdnet.com/article/skype-ditched-peer-to-peer-sup...
Hurricane Electric (for one) offers IPv6 tunnels:
* https://ipv6.he.net
You can configure it on your router:
* https://openwrt.org/docs/guide-user/network/ipv6/ipv6_henet
* https://docs.netgate.com/pfsense/en/latest/recipes/ipv6-tunn...
* https://docs.opnsense.org/manual/how-tos/ipv6_tunnelbroker.h...
Or an individual host:
* https://wiki.archlinux.org/title/IPv6_tunnel_broker_setup
* https://docs.rockylinux.org/guides/network/hurricane_electri...
* https://genneko.github.io/playing-with-bsd/networking/freebs...
1: I'd prefer to have stayed with the local ISP despite the lack of ipv6, but they wanted $8,000 to bring fiber to my new place and that was not worth it with at&t fiber being present.
- Cloudflare won't route to them. - Streaming services, such as Netflix, block them - They trigger extra validation all over the Internet
I used to have these on select hosts on my network and it was never a good experience.
That said, if it isn’t blocked for the services you use, I found it pretty straightforward to use.
Sure ipv6 has some better features, but dual-stack means you are doubling all of your config (ACLs, naming, firewalls, routing) test cases and vulnerability surface. Moreover, ipv6 is not as intuitive.
Shaming people into ipv6 will never work. More effort should be invested into best practices, patterns, migration guides, support communities & more to assist in operating in a dual-stack environment for the foreseeable future.
Pure ipv6 will never happen because the weak link breaks the chain. How many people set up an ipv6 VPC with great excitement, and late in the project they deploy from github with "NS lookup failed".
Define "pure". Jen Linkova has been running IPv6-only networks on Google's corporate networks for several years now:
* https://www.youtube.com/watch?v=UTRsi6mbAWM
She is a chair of the 6man WG (and involved in the v6ops WG), and has authored ten RFCs:
* https://datatracker.ietf.org/person/furry13@gmail.com
Microsoft also is IPv6-only on corporate networks (so more of their IPv4 addresses can be moved to Azure to produce revenue):
* https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...
The author of that article, Veronika McKillop, is head of the UK IPv6 Council:
* https://www.youtube.com/@ukipv6council468/videos
where you'll find lots of videos on ISPs and other institutions doing IPv6-only or IPv6-mostly (especially nowadays with DHCPv4 Option 108, RFC 8925).
You're not selling me on it's viability.
Deleted Comment
It's not even double the config. For e.g. my firewall, which is a 300-line config that I've already designed and implemented, making it dual stack mostly involves writing "domain (ip ip6)" instead of "domain ip". That's simply not double.
It's not less intuitive than v4 either. That's a lack of experience talking. Meanwhile, trying to use v4 quickly devolves into needing to use NAT, which is less intuitive.
> Pure ipv6 will never happen because the weak link breaks the chain. How many people set up an ipv6 VPC with great excitement, and late in the project they deploy from github with "NS lookup failed".
My desktop is pure v6 and GitHub works fine, which I think disproves the "never" part.
I'm having an issue with ipv6 sockets not receiving ipv4 traffic. setsockopt IPV6_V6ONLY = 0 is supposed to make ipv6 sockets listen on ipv4 as well
Can you take a look at this and see why it's not working
https://gist.github.com/tonymet/a85b43831179055d16403a9d9be1...
how?
You can argue "it's only one line" but that one line is a new socket and new test variant needing testing. something that worked perfectly well for 5-10 years now needing a re-test.
I'm not arguing against ipv6 . I'm arguing for honest assessments of the effort needing to migrate a network , especially residential networks, to IPv6 -- as the only way to make it happen. Shaming people with "it's so easy and simple" is just dishonest and doesn't help the cause.
Tried explaining it to several customer support techs but they all just gave up eventually.
Was fixed when I ended up getting my own modem and router/AP.
But those were an interesting few days. My partner was annoyed they couldn't use Pinterest but YouTube loaded fine. Google search worked but our local pizza joint's site didn't.
It had very little benefits at the beginning, but having dedicated publicly routed addresses started to become really conevinent.
IPv6 with a regulary changing dynamic prefix still sucks though to this day ... :-(
The (occasionally, on Comcast) changing dynamic prefix was a pain for me too, when accessing things externally. For internal use I additionally set up a fixed ULA prefix.
The way I do this, my internal DNS resolves hosts to their fixed ULA addresses. For the handful that are accessible externally, public DNS resolves to their address on the current public prefix.
* https://datatracker.ietf.org/doc/html/rfc8978
And "Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events":
* https://datatracker.ietf.org/doc/html/rfc9096
Also maybe "IPv6 Multihoming without Network Address Translation":
* https://datatracker.ietf.org/doc/html/rfc7157
Lots of good presentation at the IETF meeting for the 6man and 6ops WGs.
But I have to admit, that I ended up buying my own IPv6 block from a local ISP and tunnel to them. They have great interconnections, so bandwidth is not an issue, and latency penalty is less then 2 ms an average.
You just update the IP (or just the prefix) when the IP changes
Perhaps keep in mind that the interface id of the device the DNS entry should point is different for every device in the network.
Some use the router to update the IP and put the interface id of the router into the update url...
https://www.google.com/intl/en/ipv6/statistics.html
The real godsend of IPv4 is that it accidentally forced NAT.
This saved, through the decades, hundreds of millions of vulnerable machines from being directly exposed and owned.
I consider IPv4 saved us from Windows botnets affecting nearly the entire world.
No, NAT is not security. But accidentally it prevented oh-so-many machines from getting owned.
When I got my first Internet connection I could literally access other people's Windows machine for my ISP was putting me on the same LAN as other people. I'd do silly things like have "Your Windows machine is insecure" printed on their printers. This was in IPv4 times: my ISP would put me on a subnet with 256 other machines (I'm talking about times where a 28.8 modem was still a thing btw).
I cannot being to imagine the total and complete chaos had IPv6 existed back then.
People don't understand how insecure and wild things were back in the days.
IPv4 saved the Internet, accidentally, thanks to NAT.
Any Firewall can simply block all incoming traffic and it would have the same effect as NAT, without the computational overhead that NAT incurs...