Heard about IPv6?
Citrullin opened this issue · 15 comments
I mean, cmon. Why are you fighting IPv6 so hard? This is adding more issues than it actually solves.
How about investing the time into pushing IPv6 adoption instead?
It's the future, people may be able to postpone it for some time, but it will come eventually.
So, you have to make a decision. Do you want to stick in the past or move forward into the future?
We are not fighting ipv6 at all, as we try to stress. Making improvements to ipv4 is not out of scope for the internet. It happens that most of our proposals reflect the current deployed base (increasingly so), are simple, and in many cases, save nanoseconds by punting policy out of the kernels.
We are not fighting ipv6 at all, as we try to stress.
You are fighting the adoption of IPv6. The problem is not the tech. The technology is there and it is used. People are the problem here. As long as there isn't enough pressure, people are not going to switch. Especially not in western countries, since they have enough capital to just buy IP addresses off the market. What price are we currently at? 70 USD per IPv4 address or something.
There are probably already some companies who have a hard time paying this.
Making improvements to ipv4 is not out of scope for the internet.
IPv6 is the improvement of IPv4. It's literally the next version of the IP protocol.
Well, let's be honest, we all must fight it, no compromise here: not IPv6, but IPv6 FUD.
All such "why so lazy/obstinate not to learn IPv6" FUD are harmful not only to IPv4 extensions but also to IPv6. We've learned lessons from the NAT extension to IPv4.
I am not sure if me establishing IPv6 cred will help. I have been involved with ipv6 since 1995 or so. I worked really hard, in cerowrt especially, to resolve dozens of bugs related to ipv6, to make it ready for ipv6 launch day. Also helped pioneer a few things like "source specific routing" to deal with multiple gateways... and I've despaired of getting the same idea into RA.
The technical work of the IPv4 unicast extensions project is largely complete. It mostly consisted of deleting code, not adding it. 240/4 and 0/8 are better supported now in the realm of iot than ipv6. It's just politics and inertia that will slow 240/4 down.
Here are some of my criticisms of IPv6 as it stands today: Nearly no IoT stack supports it. Despite proudly getting full support into openwrt in 2013, many vendors are still shipping 10+ year old linux kernels, and even in modern mainline OSes, we keep findind and fixing bugs leaving that long tail of flaky ipv6 implementations left to keep updating.
I would prefer those that insist that starving the ipv4 beast will solve anything to lean in on the services in the world that haven't deployed, learn why it hasn't deployed,
.... And in particular, please join with me on attempting to mandate that ipv6 support be required as part of the NTIA BEAD and broadband programs. It IS foolish for the US government to be burning $70B on broadband without mandating ipv6! If you think a political solution will help... please tell the politicians in filings and in language they understand:
https://broadbandusa.ntia.doc.gov/broadband-equity-access-and-deployment-bead-program
Here are some of my criticisms of IPv6 as it stands today: Nearly no IoT stack supports it. Despite proudly getting full support into openwrt in 2013, many vendors are still shipping 10+ year old linux kernels, and even in modern mainline OSes, we keep findind and fixing bugs leaving that long tail of flaky ipv6 implementations left to keep updating.
As you said, the Linux kernel supports it. So does RIOT OS I work on. I am able to connect a device via IPv6 over BLE to a linux router. It's still a little painful, but possible. The infrastructure is there. I agree with you though that a lot of cooperations struggle with adopting it. Old Linux kernels are a problem on routers, but also Smartphone. It's a general tendency of the tech industry to ship it out and not to care too much about it after that. That's something right-to-repair is pushing to fix.
And even if they don't change. I see it as a great opportunity to start your own router manufacturer. It's not black magic to build these devices. Happy to support anyone who does this serious. Willing to use my network to push this forward.
I would rather pledge to do this and challenge big tech cooperations, instead of playing in their hands by supporting short term profits rather than long term investments.
Here are some of my criticisms of IPv6 as it stands today: Nearly no IoT stack supports it.
- RIOT-OS includes first-class citizen support for IPv6.
- lwIP as well includes support for IPv6 (which is intended for mainstream applications of client<->server architectures as opposed to distributed systems). It's used by default on ESP32 platforms and many other vendors (e.g.: TI).
- Contiki-NG switched from IPv4 to IPv6.
- Thread (and the OpenThread implementation) use IPv6 in their standards.
IPv6 on IoT is mature enough and constantly evolving.
https://github.com/RIOT-OS/RIOT/pulls?q=is%3Apr+is%3Aopen+label%3A%22Area%3A+network%22
ESP32 was a pretty crippled and buggy uIP w/ipv6 when I last checked (about 3 years back)
RiotOS has come leaps and bounds since I last looked, but the tcp implementation is ... suboptimal ... to say the least. (I just looked it over, as I liked Riot the most of the alternatives) The new matter effort attempts also to get ipv6 into an iot stack.
If your use for iot ipv6 is "just enough support to get a udp packet out", then things are looking bright. Connecting such devices directly to the internet... um, well, let me know what happens on a packet flood from anywhere on RioT? Or on this suite:
https://linuxsecurity.expert/tools/thc-ipv6/
(these are honest questions, btw. Very few ipv6 stacks were resistant to thc when last I tested them)
All the ipv4 capable iot stacks had no special checks for IPv4 anything besides IN_MULTICAST and broadcast when I last checked.
In this podcast I hit on "Right to repair" really hard, and also starlink. I am happy to begin to see some of it become a reality, at least on repair of iphones and androids - this is partially fueled by the supply chain crisis of course.
https://www.youtube.com/watch?v=AjZXx4N1tmY - at the time I felt it was a losing cause. Haven't yet got musk & co to fix their routers yet either - the starlink router 2.0 is based on lede-17 which is 6 years old now. The first one, openwrt 15. They are kind of a poster child for the entire home router industry. Elsewhere, "new" wifi-6 products lke TP-link's EAP255 are shipping with linux 3.3.8.
So I do keep pushing for regulatory mandates for ipv6 as a means of moving this puppy along, but we keep finding new bugs in the ipv6 implementations in mainline kernels, for example one that stands out was a bonding bug recently found. I do figure the ipv6 cellphone deployment is driving some stability into ipv6 finally, but even that is a pretty crippled version that often still doesn't even support dhcpv6-pd properly. Here's an example - my wifi tether gets a /64 off the phone... but the usb tether does not.
Meanwhile, 240/4 has worked for 12 years, and 0/8 started working a few years back.
... "just enough support to get a udp packet out", then things are looking bright.
The same is largely true for IPv6 in enterprise networking, particularly the robust support of Active Directory, large-scale VPN, and backend databases.
It's child's play to just transmit IPv6 packets and declare "IPv6 connectivity", but serious business to match up to IPv4 product maturity.
If your use for iot ipv6 is "just enough support to get a udp packet out", then things are looking bright.
Yes, because we don't need more than that. All the IoT protocols use UDP and not TCP. That's also why the implementation in RIOT isn't as good. No one is really interested in it.
We see the same for the web as well. With HTTP/3 the web is also moving away from TCP.
It's child's play to just transmit IPv6 packets and declare "IPv6 connectivity", but serious business to match up to IPv4 product maturity.
As long as companys treat IPv6 as optional feature, this is not going to change.
I am not as good on the router/network front as you are. I just need IPv6 to make my IoT applications possible.
I would be happy to promote a router+modem for end-user that supports IPv6 etc. properly. There are so many competent people, alone in here. You can make that happen.
If these companies don't want to change, make them change.
we don't need more than that. All the IoT protocols use UDP and not TCP.
I appreciate this pragmatic way. Many people seem to forget that the IPv4 vs. IPv6 issue has never been a religious war but just to get your job done. Please allow me to add a few ideas (to get IPv4 extensions job done) here.
When it comes to an extension to IPv4, the strongest counter argument is always about seemingly the same amount of transition costs as IPv6 deployment: since any tiny IPv4 extension will lead to the same process of implementing it across the whole Internet and thus have an equivalent magnitude of multi-year transition process to IPv6, why not just implement IPv6 instead?
At least three key points are ignored by such an argument:
1, "patching IPv4" preserves existing technology base & business ecology, while rolling out a whole new IPv6 protocol stack reinstalls a whole new, parallel Internet.
2, many IPv4 extensions can be designed to deploy in an evolutionary approach, i.e., plug-play & incrementally, with new devices directly interworking with existing IPv4 networks. No IPv6 transition mechanisms so far support such an approach, be it dual-stack, tunnelling, or NAT64/46 based.
3. it implicitly assumes that IPv4 is ossified, a finished dead-end protocol that won't survive next week/month/.../decade. Nothing is further from the truth, cf. The Hidden Standards War, a report cited in his presentations by Dave @dtaht.
Regarding the deployment of this Unicast Extensions, I suggest that its implementation can be slightly improved to support an evolutionary transition, where its deployment can be supplemented with an efficient (L3-only) NAT + DNS based transition mechanism, "DNS4/4e" for short, to connect existing IPv4 devices to the unicast-extended new servers.
If you care to know, here is a little description of such an idea: DNS4/4e for unicast extensions.
This design is a simple modification of the NAT based transition method of a variable length addressing extension to IPv4 called IPswen, described in this paper (appearing in the IFIP Networking 2022 conference)
1, "patching IPv4" preserves existing technology base & business ecology, while rolling out a whole new IPv6 protocol stack reinstalls a whole new, parallel Internet.
They had 20 years time to migrate. It's time to move on. The time of being nice to people is over. Btw, you are risking my future oriented business. Every day people postpone IPv6 adoption makes it unnecessary harder for me to do business.
And I don't stuck in the past as so many other big cooperation that have billions in profits. Profits they could have used to make their business future proof.
2, many IPv4 extensions can be designed to deploy in an evolutionary approach, i.e., plug-play & incrementally, with new devices directly interworking with existing IPv4 networks. No IPv6 transition mechanisms so far support such an approach, be it dual-stack, tunnelling, or NAT64/46 based.
In order to migrate to IPv6 and not to extend its lifetime. But apparently a lot of big tech cooperation read that wrong and rather take the profits in dividends etc. instead of investing it in their infrastructure.
Regarding the deployment of this Unicast Extensions, I suggest that its implementation can be slightly improved to support an evolutionary transition, where its deployment can be supplemented with an efficient (L3-only) NAT + DNS based transition mechanism, "DNS4/4e" for short, to connect existing IPv4 devices to the unicast-extended new servers.
Have fun trying to get that through. I doubt people are going to support you with this. They rather prefer companies feeling the pain from now on. Apparently they need the pressure to move on. It's sad it has to come so far, but that is apparently the reality we live in. Short term profits rather than long term investments.