I'm pretty underwhelmed by IPv6. It looks like the typical "horse designed by committee."
I suspect that what will actually end up being implemented, will be a core subset of the spec.
We'll have to see what's still standing, when the dust settles.
I'm pretty underwhelmed by IPv6. It looks like the typical "horse designed by committee."
I suspect that what will actually end up being implemented, will be a core subset of the spec.
We'll have to see what's still standing, when the dust settles.
The IPv6 spec looks long because it also includes protocols that are separate on IPv4 (DHCP/SLAAC, NDP, depending on the document ICMPv6, mirroring DHCP, ARP, ICMP, NetBIOS, etc.), as well as the addressing schemes that were different RFCs in IPv4 such as multicast/unicast/network classes/subnets.
As for the implementation: just about anything more powerful than an ESP32 has the entire protocol implemented and running already.
As long as the SDKs to apps make it simple, we'll be good. I haven't seen much, so far.
Your computer, and every other computer on the planet, already supports the entire IPv6 spec. There is no subset.
I'm typing this on a computer running Android, which means it doesn't support DHCPv6. I would describe it as supporting a subset of IPv6 functionality.
I suppose that could be annoying, but technically DHCPv6 is not part of the IPv6 specification just as the original DHCP was not part of the original TCP/IP specification.
Well, we'll have to see what all the "in-between" bits do. There's a lot in it, that will require implementation by countless layers of routers, switches, caches, firewalls, etc.
Look at Bluetooth, for an example, or TIFF.
I printed out the Bluetooth spec once, just for Ss and Gs. It was over 2,000 pages (double-sided).
I once tried writing a fully-compliant TIFF reader. Didn't go so well.
Those all support IPv6 too. They’re the same computers, and they’ve all supported IPv6 for decades now. The IPv6 spec is a lot shorter than the spec for Bluetooth or TIFF.
Just because the physical and link layers support it, doesn't mean the application layer will.
You could say the same for Bluetooth chips.
I've seen stuff, man...
Apple requires that all iOS apps on the store function on an IPv6-only network (which is how several large mobile phone networks work), and everything works fine on the application layer.
Huh. I believe that, but didn’t know it (I write apps for Apple kit). I have done low-level networking stuff that would definitely have run into issues, but that was over ten years ago. These days, I rely on the upper layer of the stack.
I really should try an exercise like the one the author did. I’m not necessarily against IPv6, but I’m still a bit skeptical of it. We’ll likely be forced into it, as there’s no alternative, but that’s not exactly a ringing endorsement.
My carrier (NTT docomo in Japan) only provides IPv6 to the end device. Access to IPv4 servers is through DNS64/NAT64, where their DNS server rewrites any DNS response that has an IPv4 in it to [64:ff9b::(the IPv4)] which gets handled by a CGNAT gateway. So anything that looks up a server over DNS and connects to that works fine, but any hard-coded IPv4 address does not.
I presume Apples requirement is there so that all apps work on carriers like this.
The only times I've run into issues is when tethering and forgetting I can't ping an IPv4, or trying to tether a Nintendo Switch (which does not support IPv6)
If your low-level networking code (I assume you mean BSD sockets here) is correct, it shouldn't even need to be aware of v4 or v6. The BSD socket API is designed so that the addresses are in an opaque data structure that you just pass around.
Back when, I did BSD sockets stuff, but generally stay above that, these days.
You're right, and that's my plan.
I have heard, however, that quite a few folks stuck their oars into the IPv6 spec process. I've seen that kind of process before, and the end result can be ... less than ideal ...