Live data from Hacker News

HTTP/3 is everywhere but nowhere

httptoolkit.com

301–310 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#301

Earlier quoted context omitted.

The problem I keep running into is that IPv6 support in common infrastructure is somewhat lacking. 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.

Yep, it's tragic because it all stems from unforced differences vs ipv4. The design was reasonable, but with perfect hindsight, it needed to be different. They needed to keep the existing /32s and just make the address field bigger, despite the disadvantages. "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…

"It's not being used", except for nearly half of Google's traffic: https://www.google.com/intl/en/ipv6/statistics.html

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.

Re: HTTP/3 is everywhere but nowhere

#302

Earlier quoted context omitted.

The problem I keep running into is that IPv6 support in common infrastructure is somewhat lacking. 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.

Yep, it's tragic because it all stems from unforced differences vs ipv4. The design was reasonable, but with perfect hindsight, it needed to be different. They needed to keep the existing /32s and just make the address field bigger, despite the disadvantages. "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…

And it would have failed for exactly the same reasons, because just changing the address field size is enough to have everyone who uses BSD Sockets to rewrite all parts of code that create sockets.

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.

Re: HTTP/3 is everywhere but nowhere

#303

Earlier quoted context omitted.

I'm not an expert on HTTP/3, but vehemently disagree about IPv6. It removes tons of overhead and cruft, making it delightful for datacenter work. That, and basically guaranteeing you don't have to deal with the company you just acquired having deployed their accounts with the same 10/16 subnet your own company uses.

The problem I keep running into is that IPv6 support in common infrastructure is somewhat lacking. 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.

Major reason for that is BSD Sockets and their leaky abstraction that results in hardcoding protocol details in application code.

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.

Re: HTTP/3 is everywhere but nowhere

#304
post #60

Earlier quoted context omitted.

What exactly are sites supposed to do to prevent being the targets of DDoS, spam, fraud, aggressive bots, and other abuse? And it's not "locked down", it's usually just a CAPTCHA as long as you're not coming from an abusive IP range like might happen with a VPN. Also there are a thousand other signals besides HTTP/3. It's not going to make a difference.

The normalization of CAPTCHAs for simply reading what ought to be public information strikes me as very alarming, as does characterizing essential privacy and anti-censorship measures like VPNs as "abusive". Something like 1% of HTTP hits pose some risk of spam or fraud, those where somebody is trying to post a message or a transaction or something. The other 99% are just requesting a static HTML document or JPEG (or…

I would say absolutely not, for something that is actually run as static. How many websites could run as static, versus the clients that pay for those websites that believe they need to make a change at any time without going back to their web developers? In my experience, most clients rarely change their websites, and often request changes from my employer after having paid for a solution that allows them to have control should they want or need it. Due to this, I still need to run a dynamic website for truly static content.

A large part of this issue is web development being totally foreign to most users, and clients being burned by past developers that disappeared when needed the most, or hit with a large charge for an update that seems to be "simple". This pushes clients to want a solution where they can make the changes, and that leads to a dynamic website for static content. If you were to stop taking this type of business to further privacy, there are probably tens or hundreds of other companies in your own city that will gladly take on the work.

This absolutely is dystopian, but also current reality. Unless you are able to run completely privately online, the Internet as a whole has become dystopian because shutting down bad actors has been thrown into the hands of individuals instead of part of the backbone to how the Internet functions. Just my two cents, as a developer that needs to use these resources, but also runs a VPN on my phone and desktop nearly all the time for privacy (as well as some speed benefits, depending on the VPN provider).

Re: HTTP/3 is everywhere but nowhere

#305
post #302

Earlier quoted context omitted.

Yep, it's tragic because it all stems from unforced differences vs ipv4. The design was reasonable, but with perfect hindsight, it needed to be different. They needed to keep the existing /32s and just make the address field bigger, despite the disadvantages. "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…

And it would have failed for exactly the same reasons, because just changing the address field size is enough to have everyone who uses BSD Sockets to rewrite all parts of code that create sockets. 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-im…

All that code using BSD sockets is rewritten by now to support v6, right? If so, that can't be the reason, cause v4 is still dominant.

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.

Re: HTTP/3 is everywhere but nowhere

#306

Earlier quoted context omitted.

What do you mean? IPv6 PI is common and easy to get; there's no big difference between IPv4 and IPv6 there.

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 b…

Huh, I have one for my personal home network :-) Granted, that is in RIPE. As long as you're multihomed, how can they turn it down?

Re: HTTP/3 is everywhere but nowhere

#307

Earlier quoted context omitted.

Yep, it's tragic because it all stems from unforced differences vs ipv4. The design was reasonable, but with perfect hindsight, it needed to be different. They needed to keep the existing /32s and just make the address field bigger, despite the disadvantages. "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…

"It's not being used", except for nearly half of Google's traffic: https://www.google.com/intl/en/ipv6/statistics.html 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.

"Depended on" is what I should have said. An ISP or website can be v4-only or support both, but it's not going to be v6-only.

Re: HTTP/3 is everywhere but nowhere

#308

> Really it's hard to point to any popular open-source tools that fully support HTTP/3: rollout has barely even started. > This seems contradictory. What's going on? IT administrators and DevOps engineers such as myself typically terminate HTTP/3 connections at the load balancer, terminate SSL, then pass back HTTP 1.1 (_maybe_ 2 if the service is GRPC or GraphQL) to the backing service. This is way easier to administ…

I'm not an expert on HTTP/3, but vehemently disagree about IPv6. It removes tons of overhead and cruft, making it delightful for datacenter work. That, and basically guaranteeing you don't have to deal with the company you just acquired having deployed their accounts with the same 10/16 subnet your own company uses.

> It removes tons of overhead and cruft

Can you elaborate? Here, or with links? What kinds of overhead and cruft?

Re: HTTP/3 is everywhere but nowhere

#309

Earlier quoted context omitted.

Does the distinction matter?

In the case of GitHub, yeah. I don’t think a Microsoft source control “social network” would have taken off in the same way GitHub did. In fact when Microsoft purchased GitHub, quite a few people did leave and close their account. But GitHub already had such a monumental market lead that the departures ended up being a drop in the ocean. To be honest, I’m still waiting for the moment when Microsoft managed to fuck it…

Don't forget prior to GitHub Microsoft ran the home-grown, TFS-enabled Codeplex. It worked quite well if using Visual Studio but obviously, like Skype, there was no reason to run it when "something better" came along.

https://en.wikipedia.org/wiki/CodePlex

Re: HTTP/3 is everywhere but nowhere

#310

Earlier quoted context omitted.

"It's not being used", except for nearly half of Google's traffic: https://www.google.com/intl/en/ipv6/statistics.html 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.

"Depended on" is what I should have said. An ISP or website can be v4-only or support both, but it's not going to be v6-only.

this isn't true. I know because at some point XFinity started dropping ipv6 connections for me and I noticed because a number of sites (forget which) were broken
Post reply on HN