Network stack - I think we should prefer IPV6 as a default
kuba
Posts: 94
in Propeller 2
I'd suggest that anyone doing an IP stack for P2 focus on IPV6 first. It's much nicer to work with. It truly takes zero configuration in the rather typical scenario of plugging a device into an Ethernet switch and then accessing it from Windows 10. It's not the sort of "fallback" or "poor-man's network" thing we had with IPV4.
IPV6 design has taken lessons from IPV4 and fixed some real shortcomings. In IPV4, the autoconfigured addresses are in a subnet that's not accessible if there's typical central administration of network addresses (a.k.a. DHCP). The traffic to those addresses goes into the gateway and gets forwarded to a bit-bucket there. That's the typical case I've seen on most "centrally" administered networks. So if you plug in a device that doesn't bother listening to DHCP, or that the DHCP server refuses to assign an address to, you won't be able to use it on an IPV4 network without resorting to talking to it over a raw socket.
With IPV6, the router advertisements are just that: they let devices know where to send packets to get them routed outside of the broadcast domain, and they let the devices know what IPV6 address prefix they should use if they want an Internet-routable address for themselves. But that's all optional. A device can autoconfigure its sole IPV6 address - and rather quicker than on IPV4. And then it's accessible from all other devices that can exchange broadcast traffic with it. It's not a second-class citizen anymore.
In terms of user experience, it's much nicer than IPV4. For example, if you're writing any sort of an end-user application to speak to your device, you won't need to bother explaining anything about network setup. It's truly plug-and-play, even if the network segment has no IPV4 support, i.e. if the router/gateway/firewall/smart switch has IPV6 disabled.
On some corporate networks IPV6 is centrally disabled on Windows endpoints by domain policy, and then it's a bummer of course, but it's hopefully a receding trend.
Device segregation is also much nicer with IPV6, since there's no need to administer L3 subnets. Since the IPV6 header is extensible, switches can embed L2 vlan id into into the IPV6 header. This can be used by the routing/firewall infrastructure to classify traffic without the need to maintain the VLAN:SUBNET correspondence that was a fact of life in IPV4 - due to the inflexibility of the IPV4 header.
IPV6 design has taken lessons from IPV4 and fixed some real shortcomings. In IPV4, the autoconfigured addresses are in a subnet that's not accessible if there's typical central administration of network addresses (a.k.a. DHCP). The traffic to those addresses goes into the gateway and gets forwarded to a bit-bucket there. That's the typical case I've seen on most "centrally" administered networks. So if you plug in a device that doesn't bother listening to DHCP, or that the DHCP server refuses to assign an address to, you won't be able to use it on an IPV4 network without resorting to talking to it over a raw socket.
With IPV6, the router advertisements are just that: they let devices know where to send packets to get them routed outside of the broadcast domain, and they let the devices know what IPV6 address prefix they should use if they want an Internet-routable address for themselves. But that's all optional. A device can autoconfigure its sole IPV6 address - and rather quicker than on IPV4. And then it's accessible from all other devices that can exchange broadcast traffic with it. It's not a second-class citizen anymore.
In terms of user experience, it's much nicer than IPV4. For example, if you're writing any sort of an end-user application to speak to your device, you won't need to bother explaining anything about network setup. It's truly plug-and-play, even if the network segment has no IPV4 support, i.e. if the router/gateway/firewall/smart switch has IPV6 disabled.
On some corporate networks IPV6 is centrally disabled on Windows endpoints by domain policy, and then it's a bummer of course, but it's hopefully a receding trend.
Device segregation is also much nicer with IPV6, since there's no need to administer L3 subnets. Since the IPV6 header is extensible, switches can embed L2 vlan id into into the IPV6 header. This can be used by the routing/firewall infrastructure to classify traffic without the need to maintain the VLAN:SUBNET correspondence that was a fact of life in IPV4 - due to the inflexibility of the IPV4 header.
Comments
That sounds like a great way for the Prop to stall.
IPv4 is the standard.
IPv6 has had 22 years, and is still not close to breaking 50%.
However would be interested in seeing your results.
That said, the chips are there, tools developing nicely.
Write a V6 stack, and see where it all goes. You do have the power to make it first and excellent.
And once we have that, then we can start doing development of whatever protocol we might want.
Exactly the logic applied that has seen IPv6 fail to gain ground.
Dual stack is the way to go. However, as we are talking about a resource constrained system, dedicating large amounts of resources to support some of the more esoteric tricks of IPv4 isn't going to give good return on investment, so only basic IPv4 capabilities should be standard.
Making any IP stack modular might be the best way to go, allowing options for IPv6, and different levels of IPv4 support, selectable at build time for the system.
AJL, that logic is called reality and basic economics.
I do networking for F500, and none of them really care a whit about v6.
Outside of maybe telcom, if F500 don't care, the rest of the world of customers don't care, then that probably why there is no demand and thus to incentive to implement. Kind of why its still at 30% after 22 years.
The logic is sound, and proven.
When v6 is needed, it will create demand and then resources will be dedicated to fill that demand.
Why the P/P2 should make it a priority over a current demanded standard like v4 is lacking in logic.
Of course, you and the OP are welcome to put hundreds or more hours into creating an object that does that, its your right.
v6 and P/P2 IMHO is about as useful as pushing a rope uphill.
http://savannah.nongnu.org/projects/lwip/
And at this for a small OS with all of that integrated (although I believe contiki integrates uIP, lwip's smaller brother):
https://www.contiki-ng.org/
Edit: might be interesting to see if fastspin C can compile this
You may have missed the part where I advocated for a dual stack implementation. Most of the work to allow it has already been done as rosco_pc has pointed out. That is reality and basic economics.
Your 'sound, and proven' logic ignores the fact that decisions with technical implications are often made by people with no technical understanding, and that smaller customers might care but aren't seen to form a sufficient mass to drive the changes necessary. I've seen many conversation go along the lines of -
Customer: "We'd like to use IPv6 if possible, as it promises to greatly simplify the network configuration"
Networking expert: "The IPv6 implementation is broken in the network equipment we are using, so we'll just use NAT and multiple VLANs to get past the issues facing the project"
Without sufficient insistence from organizations buying the network equipment, IPv6 will always be starved for the development funds necessary to fix IPv6 implementations allowing them to become the preferred option.
Both Apple and Microsoft think that IPv6 is worth implementing, but while ever the IPv4 kludges are supported instead of use of IPv6 the situation will continue.
All of that said, I have no expectation of altering your view on the matter.
You seem to have an irrational dislike for v4 because of this or that reason.
My "sound and proven logic" are sound because I'm not implying that so many others are people with no technical understanding.
And, you haven't given any sort of factual reason for why you think my logic is faulty.
But you seem to have proven my point overall, there hasn't been sufficient insistence from organizations buying network equipment to include v6. Devices are continuing to be made that are v4 compliant by many companies, by many very smart and well educated people. The market doesn't seem to have penalized them either.
I don't group all those engineers and business suits as non-technical understanding people.
Even in large companies with expansive WANs , I've yet to run across anyone ever even mentioning v6 as needed for future growth, or for much of any reason at all. I guess we're all just not technical enough.
If someone here wants to prioritize a v6 IP, more power to them.
However I'm in the camp, since we're having the chutzpah to try to tell other people how to spend their time, that thinks v4 would likely be more useful.
In the US at least, every Spectrum/Time Warner customer has their home devices on public IPv6, all routable, no NAT involved. Guess what... the sky hasn't fallen, there's no outrage, stuff works as designed. Most of them wouldn't notice if IPv4 was turned off on the local network. Everything would still work the same. Many people can't quite disassociate the function of a router from the function of a firewall, and that adds to the confusion. With IPv6, the router between the ISP and the internal network doesn't need to do NAT, and its function is thus rather trivial, whereas the firewall is of course still there so it's not as if, magically, everything becomes wide open just because devices have unique public IPv6.
I'm far from telling anyone what to do here - I'm recounting what has worked thus far. Sure, it's not all friction-free given that lots of people simply don't know much about IPv6, and usually turn it off out of some unfounded fear. But if all you need is full IP functionality, then IPv6 - maybe surprisingly - covers it, without quite a bit of the historical cruft that IPv4 got.
I tried a few times changing between wifi and ethernet but the same error kept occurring. I then logged into the house router and disabled the IPv6 features it had. All was good after that.
EDIT: Typo fix.
Should things support IPv6? Yes.
Should things only support IPv6? That smells like a tire fire seasoned with money.