It's always a headache to learn that some container orchestration system doesn't support IPv6. Or an http client. Or a DNS resolver. Or whatever.
Not to mention the supreme annoyance I have that, to this day, my ISP still does not have IPv6 addressing available.
"Everywhere but nowhere" is sorta how I'd describe ipv6. Most hardware and lower-level software supports it, so obviously it wasn't impossible to support a new protocol, but it's not being used.
Exactly. I would love to have seen the world in which that happened, and where all the other parts of IPv6 were independently proposed (and likely many of them rejected as unwanted).
There were also some small things. And routers often having bad defaults for v6, which btw, would not even be a concern if they left the big thing alone.
Sure, "make the addresses bigger" would have required providing DHCPv6, DNS AAAA records, and various other protocol updates for protocols that embedded IP addresses. And making changes to the protocol header at the same time (e.g. removing the redundant checksum) were also a good idea.
It didn't require pushing SLAAC instead of DHCP.
It didn't require recommending (though fortunately not requiring) IPsec for all IPv6 stacks.
It didn't require changing the address syntax to use colons, causing pain for all protocols that used `IP:port` or similar.
It didn't require mandating link-local addresses for every interface.
It didn't require adding a mandatory address-collision-detection mechanism.
And I'm sure I'm forgetting a few.
It didn't require the Ruby Goldberg "on link" network mechanism.
It didn't require multicast instead of broadcasts for local network discovery.
It didn't require using DNS config (of all things) to specify V4/V6 priority.
It didn't require adding a "flow label" that is nobody to this day knows how to use properly.
The list of fails is ridiculous.
Disconnect your phone from Wi-Fi and visit https://ifconfig.co/ . If you're a Verizon customer, it's probably going to show you an IPv6 address. It's huge, right now, today.
One of the world's largest ISPs, Vodafone, is yet to support IPv6.
What Google supports is irrelevant if your ISP can't handle the traffic.
Vodafone's network is reported to handle around 20% of the world's traffic. It's not a random ISP. It's network does not support IPv6. It is how a big chunk of all internet users experience the internet. Claiming it doesn't matter in a discussion over IPv6 adoption rate is ludicrous.
Especially since getaddrinfo was ported over from more streams/OSI oriented stacks pretty late, precisely because BSD Sockets required separate path for every protocol.
On hw side, by mid-1990s even changing one routing-important field would mean possibly a new generation of ASICs needed with more capabilities.
Essentially, once you agree to break one field, the costs are so big why not try fixing other parts? Especially given that IETF has rejected an already implemented solution of just going with OSI for layer 3.
And btw, what I suggested would actually work without userspace code changes until you want to start subdividing the /32s. Cause v4 addresses would've still been valid in v6.
Next step would be upgrading all those parts like DNS, DHCP, etc to accept the 128-bit addrs, which again can be done in isolation. Then finally, ISPs or home routers can start handing out longer addresses like 1.1.1.1.2.
If it means upgrading every program, then your plan works but it's the same as how things work today. You're telling people to do a thing, and they aren't bothering. The "simple" step isn't simple at all.
If it doesn't mean upgrading every program, then your rollout fails on the last step. You start handing out longer addresses and legacy programs can't access them.
For a good decade a lot of software had to be slowly patched in every place that made a socket to add v6 support, and sometimes multiple times because getaddrinfo didn't reach everyone early enough.
> results in hardcoding protocol details in application code
Of course, code that operates on packets, in the TCP/IP stack of the OS would have still needed to be rewritten. But that is far less code than "every application that opens a socket".
Of course, this only applies to code that uses IPs only to open connections. There's lots of application code that does more things with IPs, such as parsing, displaying, validating etc. All of this code would still need to be rewritten to accept IPv6 addresses (and its much more complex string representations), that part is inevitable.
While the sockaddr struct allowed to to abstractly handle v4/v6 socket connections, there wasn’t a clean way to do all of that additional stuff and IP address logic leaked into all kinds of software where you wouldn’t first expect it.
Something as simple as a web app that needs to inspect proxy headers would even have it.
It also didn’t help that it became practice to explicitly not trust the addr resolution offered by the sockets API because it would do unexpected things like resolving something that looked like an integer to a uint32 and then a 4 byte V4 addr.
It isn't about upgrading one protocol to another but about having the operating system abstract away the different protocols from the application.
Resolve the A and AAAA records, and try to connect to them at the same time. The first successful connection wins (maaaaybe with a slight bias for IPv6).
This would have required an API that uses the host name and folds the DNS resolution and connection into one call. Instead, the BSD socket API remained at the "network assembly" level with the `sockaddr_in/sockaddr_in6` structures used for address information.
For the examples I am going to use the typical "HTTP to example.com" case.
Some OSI-focused stacks provided high level abstraction that gave you a socket already set for listening or connected to another service, based on combination of "host name", "service name", and "service type".
You'd use something like
connect("example.com", "http", SVC_STREAM_GRACEFUL_CLOSE) // using OSI-like name for the kind of service TCP provides
Similar approach was done in Plan 9 (and thus everyone who uses Go is going to see something similar) with the dial API:
dial("example.com!http",0,0,0)
When machine 2 receives a packet from 1.1.1.1 at 2.2.2.2 it sends a ipv6 ping-like packet to the ipv4-mapped address ::ffff:1.1.1.1 saying something like "hey you can also contact me at 22::22 and if machine 1 undertands then it can try to use the new address for the following packets.
I can see how it would be hard to secure this operation.
I always found that to be a desperate talking point. 'Prepare your network for the incredibly rare event where you intend to integrate directly' (didn't anyone hear of network segmentation?). It makes a lot more sense to worry about the ISP unilaterally changing your prefix - something that can only happen in IPv6.
ISPs unilaterally change your DHCP address on IPv4 all the time. And in any situation where you would have a static address for IPv4, your ISP should have no problem giving you a static v6 prefix. This argument makes no sense at all.
My understanding is that for some bizarre reason this is not usually the case with IPv6
Can you elaborate? Here, or with links? What kinds of overhead and cruft?
* You can't fragment packets.
* The redundant checksum header was removed.
* No more private addressing (unless you're a glutton for punishment).
* No more NAT (see above).
* Simpler routing.
* Doesn't require DHCP.
It benefits hugely from the lessons learned with IPv4.
Private addressing is still needed with IPv6, it's a crucial part of how address allocation works, and it's the only way to reliably connect to a client-like IPv6 device on the local network, since its public IP address will change all the time for privacy reasons, assuming it respects best practices.
Routing is only simpler if the ISPs actually hand out the large prefixes they are supposed to. Not all of them do.
DHCP is still required for many use cases. So now you have two solutions for handing out addresses, and you need to figure out when to use SLAAC and when to use DHCP. This is strictly more complex than IPv4, not simpler. SLAAC is mostly just unnecessary cruft, a cute little simple path for limited use cases, but it can never replace DHCPv6 for all use cases (e.g. for subnets smaller than a /64, for communicating additional information like a local DNS server or NTP server, for complex network topologies, for server machines etc).
OK. So what happens if your ISP connection goes down? Your router will detect this and withdraw the ISP's prefix.
So now you can't print because your printer doesn't have an address. Good luck.
> * Doesn't require DHCP.
This turns out to be a problem, as you can't easily see what's going on in the network.
The question of whether or not you use private addressing is, AFAICT, independent of the protocol. I mean, there's no material difference between private and public addressing.
> * No more NAT (see above).
Ditto. You don't have to NAT over IPv4, and you can NAT over IPv6; and - you may want to or need to, depending on restrictions on your connection.
> * Simpler routing
In what way?
> * Doesn't require DHCP.
IPv4 doesn't require DHCP either, IIANM.
But - point taken on the other simplifications!
* Private addressing is a feature, not a bug, in the datacenter.
* NAT is a feature, not a bug, in the datacenter.
* Simpler routing matters more on bad connections, but is less of a problem on good ones.
* DHCP is a feature, not a bug, in the datacenter.
Overall, it adds features that I don't need in my datacenter, and takes away others that I do and now need to add back. Like I said: it's great outside the datacenter, not so great inside it.