Earlier quoted context omitted.
Personally I’d look for the coveted 5 eights uptime.
66.6% uptime anyone?
IPv6 traffic crosses the 50% mark
551–560 of 643 posts
Re: IPv6 traffic crosses the 50% mark
#552Earlier quoted context omitted.
I don't know what the percentage would be, but we do have some historical precedent that could give us a clue. Best one I can think of is when bigger websites started actually dropping SSLv3 and TLSv1.0 (and later TLSv1.1) support, cutting off older browsers and operating systems. Google and Amazon still support TLSv1.0, but plenty of others (including Microsoft) have dropped 1.0 and 1.1. HN itself doesn't accept 1.1…
a browser you at least have the ability to change though. if your ISP doesn't offer v6 you're SOL really
Re: IPv6 traffic crosses the 50% mark
#553Re: IPv6 traffic crosses the 50% mark
#554Earlier quoted context omitted.
Somehow it's really hard to find numbers, but AFAIK at least Telekom and 1&1 don't use CGNAT for home connections, which already rules out that 77% have it.
Questions like this suggest that 1&1 do: https://forum.openwrt.org/t/solved-dsl-over-ds-lite-with-isp... I'm less sure about Telekom. For obvious reasons, it's hard to find info in English.
Re: IPv6 traffic crosses the 50% mark
#555Re: IPv6 traffic crosses the 50% mark
#556Earlier quoted context omitted.
I don't even know why clouds offer public IP addresses. In my opinion all clouds should only have a gateway that routes via host header for millions of customers. IPv4 should be a special priv for special situations at a higher price. Then these clouds could own maybe 20 IPs total instead of millions.
> host header Not all workloads are HTTP. > gateway .. for millions of customers That's basically what an AWS ALB is. It's not provisioning bespoke infrastructure when you create it.. it's just a routing rule in their shared infra. If Amazon wanted, they could easily have shared IP's but the cost of an IPv4 isn't so great that this approach has been warranted yet, clearly.
Let's let the people that want non http workloads pay more.
Re: IPv6 traffic crosses the 50% mark
#557And still, in the year of our lord 2026, GitHub does not support IPv6. https://github.com/orgs/community/discussions/10539
GitHub should absolutely support IPv6, but until then... transip.eu provide IPv6 addresses which transparently proxy to github.com: https://www.transip.eu/knowledgebase/5277-using-transip-gith... You'll need to update your DNS server to include those as AAAA records. Do providers like NextDNS or RethinkDNS allow these sorts of overrides?
> Do providers like NextDNS or RethinkDNS allow these sorts of overrides
Not on the resolver, but on the Android client (Rethink DNS + Firewall) we do (if enabled) manipulate DNS answers to implement an opportunistic 464xlat (over Kasper Dupont's public relays [0]).
[0] https://github.com/celzero/firestack/blob/c10c155464e0d4a81a...
Re: IPv6 traffic crosses the 50% mark
#558I consistently get 100x as many captchas from google over V6 as over V4, on many different networks: it is obnoxious and obviously broken on their end.
Re: IPv6 traffic crosses the 50% mark
#559Every year I just wish someone will come up with IPv4-with-more-bytes and we can switch to it before IPv6 gets another percent usage share.
If you change the address format even the tiniest amount, if you add one single additional bit, your new protocol is already completely incompatible with all existing IPv4 software and equipment.
Re: IPv6 traffic crosses the 50% mark
#560Earlier quoted context omitted.
GitHub is at the point where it immediately rate limits me if I try to look at a project's commit history without being logged in, as in the first time I even open a single URL to the commit history, I get "Too Many Requests" from GitHub thrown at me. I don't know if my work's antivirus stack is causing GitHub to be suspicious of me, but it's definitely egregious.
It’s not you or your setup. I experience the same behavior. Tried with and without Private Relay, residential and commercial ISPs at different locations, and more to debug it. Same results. I think GitHub has just gotten so aggressive with their rate limit policies that it’s straight up incompatible with their own product. The charitable interpretation is that they aren’t keeping good track of how many requests each…