Open Citrullin opened 2 years ago
dtaht
commented
2 years ago 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.
Citrullin
commented
2 years ago 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.
bingswen
commented
2 years ago 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.
dtaht
commented
2 years ago 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
Citrullin
commented
2 years ago 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.
jeandudey
commented
2 years ago Here are some of my criticisms of IPv6 as it stands today: Nearly no IoT stack supports it.
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
letoams
commented
2 years ago On Mon, 6 Jun 2022, Philipp Blum wrote:
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.
There is no reason to not do both. In fact, we should have done both 10 years ago.
The amount of work needed for this compared to like say teach all sysadmins and SRE people IPv6, is really negligable.
dtaht
commented
2 years ago 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.
dtaht
commented
2 years ago 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.
bingswen
commented
2 years ago ... "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.
Citrullin
commented
2 years ago 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.
Citrullin
commented
2 years ago 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.
bingswen
commented
2 years ago 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.
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)
Citrullin
commented
2 years ago 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.
letoams
commented
2 years ago On Mon, 13 Jun 2022, Philipp Blum wrote:
They had 20 years time to migrate.
Perhaps time to reflect why people didn't (and still don't) rush to this.
The time of being nice to people is over.
It is never a time to stop being nice to people.
Btw, you are risking my future oriented business.
That is on you. I have been there myself, where I ran a company that offered a technologically sound solution but the world took another 10 years to move there and I had to do something else. I can't blame the world here - only myself for not understanding it (and the market).
Every day people postpone IPv6 adoption makes it unnecessary harder for me to do business.
Every day, those people's life for some reason useful to them, have not adopted ipv6. Why? Why are their reasons less important than yours?
In order to migrate to IPv6 and not to extend its lifetime.
That is a whip instead of a carrot. If you don't have a carrot that works, something is wrong.
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.
So you don't like big businesses being successful at the expense of your small business faltering? It seems the market is speaking here in favour of keeping and extending ipv4 along with ipv6.
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.
Beatings will continue until IPv6 morale improves?
Anyway, as said before, nothing of this will prevent ipv6 from being a nice juicy carrot everyone wants instead of that lame old ipv4 thing.
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?