Nginx (F5) and Go (Google) are hardly scrappy open source projects with limited resources. The former is semi-commercial, you can pay for Nginx and still not have stable HTTP3 support. Google was one of the main drivers of the HTTP3 spec and has supported it both in Chromium and on their own cloud for years, but for whatever reason they haven't put the same effort into Go's stdlib.
The backwards compatibility guarantees are for the language and not the standard library. They won't make breaking changes nilly willy but it can and has happened for the std.
The comparison with IPv6 is interesting. IPv6 isn't mainly driven by open source or community. It is driven by the needs of large corporations, including both ISPs and tech companies. ISPs like T-mobile wanting to run an IPv6-only backbone network, and tech companies like Apple forcing every app in the App Store to work in IPv6-only mode (DNS64+NAT64). New operating system levels features for IPv6 are often proposed by big tech companies and then implemented eagerly by them; see for example DHCP option 108.
In a sense the need for IPv6 is driven by corporates just like that for HTTP/3.
IPv6 always seemed to me to be driven by a certain class of purist networking geeks. Then some corporations started getting on board like you said, but many couldn't care less.
The largest use of IPv6 is in mobile (cell) networks. When they effectively killed IP block mobility (provider independent netblocks), they (the standards bodies) effectively killed it's adoption everywhere else.
I work in the networking space and outside of dealing with certain European subsidiaries, we don't use IPv6 anywhere. It's a pain to use and the IPv6 stacks on equipment (routers, firewalls, etc) are no where near the quality, affordability, and reliability of their IPv4 stacks.
I've gone through dozens of applications for a PI block and all been turned down. Heard the same from most of the networking people I know of. One even had their company become a LIR just so they could lock down a block.
Outside of Europe I don't know anyone not FAANG sized that managed to get it done in the last few years.
In my dealings with small to medium sized biz, I usually go the SDWAN route to aggregate and balance in IPv4 space instead as it is MUCH easier to get it done from an ISP.
You lost me at “multiple per-interface NAT rules […] with some load balancing trick” being “stupid easy”…
But BGP+PI is indeed how multihoming is supposed to work, both in IPv4 and IPv6. (Well, in IPv6, you can put two prefixes on-link and do poor man's multihoming that way, which you cannot reliably in IPv4.) Of course, if you define “it cannot be BGP+PI”, then indeed it's probably harder, but if you exclude the intended solution, obviously there's no intended solution.
Depends on the country. New Zealand has zero mobile IPv6 users -- not one carrier has deployed IPv6 on mobile (and none plan to do so anytime soon). This includes two carriers that have deployed IPv6 on their xDSL/Fibre networks so it's not like they don't know how. It's interesting that some countries (e.g. NZ) see IPv6 deployed mostly on fixed line (i.e. xDSL/Fibre) while others (e.g. US) are mostly mobile. Perhaps it's not the fixed/mobile layer of the network stack that influences the decision to go IPv6 or not.
The exhaustion of IPv4 address pool was easy to predict even in 2000, just by extrapolation of the growth curve.
Then came IP telephony backbone and the mobile internet, topped up with the cloud, and the need became acute. For the large corporations involved, at least.
Oh many purist networking geeks joined large corporations so that these corporations began to push IPv6 in a direction set by the geeks. They understood that as independent geeks they have essentially no say in the evolution of IPv6. My favorite example here is Android refusing to support stateful DHCPv6; it's clear that it's being pushed by purist networking geeks inside Google.
With IPv6 RAs, there's no need for DHCPv6. I don't use it at all and I use IPv6 just fine on mobile. One place where DHCPv6 may make some sense is the router<->WAN/ISP connection. However once your router has a IPv6 prefix, it can easily advertise it on your LAN/WLAN for devices to capture it via IPv6 RAs for its IPv6 autoconfiguration which Just Works. Given that Android devices will attach to a WLAN router (and not directly to your WAN/ISP) it makes sense for there to be no DHCPv6 as it's not necessary for end user devices that aren't expected to be attached directly to the WAN/ISP.
My home network doesn't use stateful DHCPv6 either. I agree there's no need.
The bigger thing is carrying this "you don't need it" attitude to a product used by billions. Thousands of network operators who do not believe in "you don't need it" are now forced to make their network work for Android. If those purists had guts they should go to the IETF and formally deprecate stateful DHCPv6.
> My favorite example here is Android refusing to support stateful DHCPv6; it's clear that it's being pushed by purist networking geeks inside Google.
If you read the huge bug on it, Google's counter argument is stateful dhcpv6 significantly complicates tethering to the point of needing an ipv6 nat. That's a very practical position to take, hardly "purist network objectionists"
So what? The Linux kernel already supports NAT66. Android uses the Linux kernel. I use Tailscale and when I use an IPv6-only node as the exit node, NAT66 is being used. Use `ip6tables -t nat -vnL` to check. You can also grep for `v6nat = true` in Tailscale logs.
It's those purists at Google that decide that NAT66 is evil and should not be used and therefore they have chosen not to support stateful DHCPv6.
Yes, right now every large provider does that, which is great. That was not the case when the first p2p networks were growing big (Napster, Gnutella, that kind of thing).
Ummm… Google invented QUIC and pushed it into Chrome and shuttled it through IETF to be ratified as a standard. Some of the large OSS projects are maintained by large companies (eg quiche is by Cloudflare) and Microsoft has MsQuic which you can link against directly or just use the kernel mode version built into the OS directly since Windows 11. The need for QUIC is actually even more driven by corporates since IPv6 was a very small comparative pain point compared to better reaching customers with large latency network connections.
99% of the benefit of HTTP/3 is on distributed web serving where clients are connecting to multiple remote ends on a web page (which lets be honest, is mostly used for serving ads faster).
Why would the open source community prioritize this?
Yes, but they've likely already optimized any code that's part of their ad networks to support http/3 anyways. They're not necessarily going to lose sleep if other components doesn't support it.
So nobody considered HTTP/3 interesting enough to rush and add support for it very quickly. It'll get there, but fast? I don't think so, see IPv6.
Also, nobody considered HTTP/3 worth enough of paying for maintainers to add support for it.