The real migration challenges are in the server side/consumer home internet space which I'm not sure if there are clear stats around the adoption there.
I think IPV6 is a great example of over engineering, trying to do too much in one iteration. In an ideal scenario this could work, but in the context of large scale change with no single responsible party, it usually doesn't work well.
This is a tricky problem; providers don't have an easy way to correlate addresses or update policies pro-actively. And customers hate it when things suddenly break no matter how well you go about it.
[1] https://docs.github.com/en/enterprise-cloud@latest/organizat...
If you're not an expert in this area it's worth a read - I certainly learned a few things!
Try going IPv6-only by disabling IPv4 on your computer as a test and notice that almost nothing works except Google. End users shouldn't need to set up NAT64/6to4 tunneling. It should be ISPs doing that to prepare for the transition.
Also, notice how Android and iOS don't support turning off IPv4.
The real question is, why are the crests so predictable? They're always on Saturdays; Sunday dips down a little below the crest, then Monday-Friday is down in the 45% range before the next Saturday jumps up to 50% again. (Fridays usually have a small rise, up to the 46-47% area).
My theory: mobile access rises on weekends. People are more often accessing Google services from their work computers Monday-Friday, but on Saturdays and Sundays most (not all) people are away from the office. Many of them will end up using smartphones rather than laptops for Internet access, for various reasons such as being outdoors. And since smartphones are nearly all using IPv6 these days, that means an uptick in IPv6 usage over the weekends.
- In a cafe wifi, I had partial connectivity. For some reason my wifi interface had an ipv6 address but no ipv4 address. As a result, some sites worked just fine but github.com (which is, incredibly, ipv4-only) didn't
- I created a ipv6-only hetzner server (because it's 2026) but ended up giving up and bought a ipv6 address because lack of ipv4 access caused too many headaches. Docker didn't work with default settings (I had to switch to host networking) and package managers fail or just hang when there's no route to the host. All of which is hard to debug and gets in your way
> IPv6 traffic crosses the 50% mark
Graph description:
> The graph shows the percentage of users that access Google over IPv6
There are reasons to expect both much more and much less traffic per user on IPv6 compared to IPv4...
amazon.com needs to get with the program. Still IPv4 only.
Things have developed so much, a Internet2 is still going on I take it, however is more focussed on university research.
As ever a killer strength is something that draws people to a new technology, I imagine there's various demographics that benefit from use of ipv6.
Further I imagine that there are some levels of criticality which when reached are more self sustaining (dare I say it the network effect?).
I've been posting this graph over the years, and it really has slowed down hugely close to this 50%. This is a global ipv6 support, so some countries are racing ahead, others weirdly like Denmark have a stash of ipv4 addresses and seems content.
France and Germany are at about 80%, but there's the rest of the world of course.
0/10 in Latvia with a local ISP, fun times.
My company is ipv4 still, and some customers are having issues with ipv6 only connections.
Also we log the ip addresses, and that's only in ipv4.
One such stat is here:
> adoption ranging from 71% among the top 100 to 32% in the long tail
https://commoncrawl.org/blog/ipv6-adoption-across-the-top-10...
Getting full coverage on AWS (/GCP/Azure) and few other key services (GitHub...) would be significant here imho.
Does anybody know why that might be the case? What's the story of IPv6 deployment in France?
I get the whole s-curve trend but if I squint at 2017, there is an inflection to slow the s-curve down.
Annoyingly, when setting up service with a fiber company in the last couple months, I explicitly asked about IPv6 connectivity and they said, "yes." Turns out "yes, but not in my region."
This will probably help adoption. On the one hand it will generate more IPv6 traffic. On the other hand it will expose more developers to IPv6; which will expose them to any lack of support for IPv6 within their own products.
[1]: https://9to5mac.com/2025/08/14/apples-first-mac-with-5g-cell...
- I don't want to have a permanent global unchanged ipv6 as in id of my traffic.
- IPv6 privacy extensions would change that but then I can not reach my two devices I do want to reach from outside anymore as my access router only supports DynDNS for its own address and no NAT in IPv6
Personal web server running dual stack since early 2010s currently sees 18-20% v6 traffic. When split by type, counting only mobile users it reaches 30% at peak.
Bot/crawler traffic is ironically 100% v4.
Meanwhile: enabled h3 in september last year for the fun of it, instantly at >40% traffic by request count, passing 50% since the beginning of the year, h2 accounting almost all the remaining traffic and plain ssl/http requests <1% being just bots.
Personally I think the design of IPv6 offers very little benefit; supposedly the Dept of Defense/Dept of War holds some 175 million IPv4 addresses, with other companies also holding large allocations - that should have been addressed 25-30 years ago as an administrative matter.
The story is that at the beginning I had IPv6, and a shared dynamic IPv4 behind a CGNAT, I asked for a rollback to a full duplex static IPv4 and for three years I had both a static personal IPv4 and an IPv6. A few weeks ago my router went down and since it went back up, I no longer have an IPv6 address. I called my ISP and they explained that I could either have IPv6 or a static IPv4, but not both, and that it's abnormal that I had both for so long… welp, it's sad to see IPv6 but getting it back is not worth abandoning my static IPv4 and going back to a dynamic shared IPv4.
The only way this will change is by increasing pressure on the resource of IPv4 networks. It was a few years ago that AWS broke the news to me that I'd be paying for IPv4 addresses but IPv6 would remain free. If enough services are forced, financially, to abandon an IPv4 presence, then their clients would be likewise forced to adopt IPv6 in order to retain connectivity.
But with the ubiquity of CGNAT and other technologies, it seems unrealistic that IPv4 will become so rare that it becomes prohibitively expensive, or must be widely abandoned. So that availability of the legacy protocol will inhibit widespread adoption and transitions to IPv6.
As of now, there is no way to have a 100% internal ipv6. Many of the services, including CloudSQL or the connection between external and internal load balancers do not support ipv6, even when the external load balancer support ipv6 forwarding rules at the front end.
This means that careful internal ipv4 allocations still matter.
That seems to be a promising approach.
I think most of us know that their design failure here was a lack of backwards compatibility. But at least it's getting adopted.
Is it because they have more carrier NAT?
In Denmark I can get cheap 1 / 1 Gbit/s fiber, but still no ipv6 :(
Does it mean we better put our chips on IPv8?
It sounds to me like its a tool which is available to be used when needed and when no better workarounds exist, and it is slowly but surely being adopted as needed.
Unless your own organisation in the RR has the IP addresses assigned to you as Provider Independent resources, there just seems to be so many places where 'your' IP address could, albeit most likely accidentally, become not yours any more. And even then, just like domain names, stop renewing the registration and someone else will get them - I was that someone else recently...
[1] AS202858
Yes, they do. It's called DNSSEC.
https://www.arcep.fr/la-regulation/grands-dossiers-internet-...
We actually have a /128 address only, and had to tweak several settings including enabling IPv6 masquerading (NAT).
I haven't the slightest clue why they didn't give us a block.
This gives operators a benefit of the vertical control for the whole ecosystem - from top to the bottom, including intricate parts of protocols and routing. And France, in contrast to other countries, does not suck here too - operators usually do a good job of meticulously maintaining their assets.
My personal impression is that this is the result of several cultural factors:
1. Ingrained respect of privacy, private property, and a peace of heart as they call it. As a practical result of that, you do not get spammy messages and ads from operators, banks, etc. You may get some, like 3 or 4 discounts/offers in a year. Compare that to other countries where you can easily get 10s/100s messages like that in a single day. In other countries, instead of upgrading the infrastructure, people are busy with spamming each other.
2. The harsh oceanic environment with hurricanes and storms fosters an appreciation for reliability and functionality. It also encourages a certain frugality: every cent matters. As a result, people tend to develop a strong sensitivity to situations where form is prioritized over function, and such approaches are quickly dismissed as impractical. This gives a certain internal freedom of being able to see through things to determine what they are in the long run and not what they appear to be on the surface.
3. French people don't like to overwork outside of working hours. So choosing something like IPv6 over IPv4 seems like a natural forward-looking investment for the future where you can have less maintenance burden and thus you can devote more time to enjoying other things in life.
Having all those things combined, it's not hard to see why France chose IPv6. It's a natural choice there and it's imposed by survival.
P.S. I've spent some time in France, but was born in another country.
Well, the curve has got to level-out at 100%.
There's value in restricting access and reducing ones attack surface, if only to reduce noice in monitoring.
EDIT: After reading Tailscale's article, I noticed that I overlooked our neverending dependence to NAT despite that IPv6 seems to eliminate it.
Is it plateauing? From the chart it doesn't look that way at all to me.
You could say it's flat between August 2025 and now, but it also was from Jun 2024-Feb 2025, or August 2023-March 2024. There's just a lot of noise to it -- lots of short plateaus or even dips followed by lots of sudden jumps. Indeed, it seems to have a bit of a yearly cycle to it, suggesting we're at the inflection point of another jump upwards.
So it still seems to be growing strongly to me. The rate of growth has slowed maybe the tiniest bit 2024-2026 compared 2018-2023, but I don't see it anywhere close to plateauing yet.
Maybe we shouldn't even measure percentage adoption and instead just if github has finally adopted..
Has something changed for the worse?
ABC, Always Be Closing.
So you want laptops to cost <whatever the laptop costs> plus a measly 19.99/month for internet connectivity?
What's wrong with just tethering to my existing phone?
Maybe they are finally coming, however the rumors are older then the iPhone. Example from 2008: https://pcr-online.biz/2008/11/03/3g-macbooks-on-the-way/
If you are single, have a phone contract, you would need some extra contract for a landline internet and wifi router because thats what a lot of people just do and now they can just add an esim and pay a little bit more.
Interesting that this sounds/feels a lot more right or useful than it did 5 years ago.
A cheap VPS or one with spare bandwidth with > /64 that is properly routed (some providers do NDP for some reason) and a Wireguard tunnel would also get you a simple DIY solution.
Cloud computing doesn't mitigate IPv4 issues, it just moves it around. The big cloud providers buy up any IPv4 space they can, leaving less for everyone else. The difference is that they then get to collect rent, by the hour, on any IPs their customers use.
Load balancers...yeah, actually that is a valid approach to reduce IPv4 use, assuming you mean the "reverse proxy" variety of load balancer. Cloudflare's proxy service is doing exactly this, on a pretty huge scale. (CLoudflare can then send the traffic on to an IPv6-only server, regardless of the client's protocol.) The downside is, like cloud, consolidating a lot of infrastructure into the hands of a small number of companies.
Just log onto AOL and type in keyword "WALMART" and save! It's friendly and safe.
But in reality at the moment there will probably always be at least one thing that only works with v4 a lot of the time.
Incentives are misaligned as well - it saves you money as the EC2 instance user, but the owner of the website you're trying to access has to support v4 anyway so they don't have a big incentive to change anything
IP filtering is a valuable factor for security. I know which IPs belong to my organisation and these can be a useful factor in allowing access.
I've written rules which say that access should only be allowed when the client has both password and MFA and comes from a known IP address. Why shouldn't I do that?
And there are systems which only support single-factor (password) authentication so I've configured IP filtering as a second factor. I'd love them to have more options but pragmatically this works.
Do you have a writeup of your setup somewhere or can you recommend some learning materials ?
This is a misconception. It is not the successor to IPv4, it is an alternative. Maybe the alternative is so good it will eventually make the older extinct, but it does not look like that
IMO with the right market conditions, IPv6 could spread really fast within 6-24 months. For example, most cloud providers are now charging for IPv4 addresses when IPv6 is free. Small changes like that push in the right direction.
It's fine. IPv4 and IPv6 can be used at the same time. There's no hurry. Network interfaces support anything as long as both sides agree (nothing stopping you from building your own IPX network over MPLS).
People can move to IPv6 when the IPv4-as-real-estate speculators get out of control, and if IPv6 prevents IPv4 rental prices from going haywire, then it's served a useful purpose.
I saw a news article that said something about India considering moving to IPv6-only? That's going to be interesting if the rest of the world moves to IPv6 and the U.S. doesn't.
> End users shouldn't need to set up NAT64/6to4 tunneling. It should be ISPs doing that to prepare for the transition.
100%
Which is what ISP are doing with 464XLAT deployments. IPv6-mostly networking and IPv4-as-a-service are things that are happening in real world right now.
Meanwhile corporate IT for business and education networks have less incentive to upgrade and typically lag behind in adoption in general.
Especially given that it is now owned by Microsoft, which has been working on IPv6-only (at least on their corporate network) for almost a decade:
* https://blog.apnic.net/2017/01/19/ipv6-only-at-microsoft/
* https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...
Turns out we could not connect to Twilio's API which is IPv4 only.
An excellent reason to move away from Github, I find.
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?
github.com doesn’t have an IPv6 address.
github.io does have an IPv6 address. Indeed, one workaround for getting rate limited when using a carrier NAT with github.com is to have a github.io page and pull data from github.io instead of github.com.
Edit: About a decade ago, all of my hosting had full IPv6 support, and I tried to move over to IPv6. However, there was an issue with Letsencrypt certs not validating over IPv6, so I made my web pages IPv4 only. Recently, I gave IPv6 a go again, and the cert issue has been fixed, so now my webpages finally have both IPv4 and IPv6 addresses.
I wish hosting providers would give you a local routed ipv4 on ipv6 servers with a default NAT server. It is not that expensive I move 10Gbps "easily" and they could charge for that traffic.
I do understand the value of blocking unwanted networks/addresses, but that's a bit different problem space.
Initial writeup based on IPv6: https://abarber.com/Setting-Up-ASN-IPv6-Routing-BIRD-Teltoni...
Have been having fun recently with an IPv4 block and Asynchronous routing, working on writing that up right now :)
IPv6 just tried to do too much so it failed at everything. Putting letters in IP addresses made it near impossible to remember what your network settings were supposed to be.
It is nothing short of a miracle that devices can even get IPv6 addresses. SLAAC was supposed to replace DHCP, but it couldn't provide DNS server addresses. DHCPv6 was introduced to replace SLAAC, but this time they forgot to add a way to communicate a default route. This lead to Cisco, Microsoft, and Google all taking completely different approaches, and the IETF helpfully blocking any efforts at cross vendor standardization because of v6 zealots.
This was at the behest of mobile network. E.g., T-Mobile US has 140M subscribers, and moved to IPv6-only many years ago:
Source https://konecipv4.cz/en/
I'm with an ISP whose landline/fibre division does not have IPv6, but whose mobile division gives IPv6 to handsets.
Are you sure? I don't see it.
Name: github.io
Addresses: 185.199.111.153 185.199.110.153 185.199.108.153 185.199.109.153
When I lived in India, everything had IPv6 out of the box.
Yet I can still rent a VPS with IPv4 for $12/year from a wide variety of providers.
One more thing to troubleshoot at 3 am, one more thing to teach to a disinterested tier 1 support team, one more thing for Chrome to be weird about, hundreds more rules to manage in a hostile load balancer, logging tools that don't understand ipv6.
Turned it off. End customer asked why the site got a little slower (CGN) and when we can turn ipv6 back on. As far as I know it's still on the backlog.
You mean like AWS NatGW https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gat...
It's been discussed on the apnic blog and at meetings heaps
EDIT: Apparently it's 77% https://pulse.internetsociety.org/en/news/2026/01/china-hits...
But at least a reasonable facsimile eventually came out with NAT64.
(You can also do NAT46, but it requires one IPv4 address for every IPv6 destination you want to be reachable from the IPv4 Internet, so it doesn't scale very well.)
How would Google know what users have the potential for IPv6 if they are not using it?
The author of the RFC is the author of the slides.
For a long time, there really was next to no progress. Between the introduction in 1996 and about 2011, there was very little adoption. And since 2012 when pushing really started, we're at about 50% globally, with large variance by country and network type. 15 years between creation and real deployment seems like a lot, and 15 years of deployment getting to 50% also seems likes a lot.
But wikipedia says touch tone dialing was first offered to consumers in the 1960s and didn't become majority until the 1980s, so maybe 30 years isn't that slow.
They will. One from facebook, one from google, one from tiktok, several from Palantir and its partners...
The $1 to $5 a month to have excellent, reliable connectivity (that no residential connection provides), DDoS protection, and isn't tied to my home IP outweighs any home hosting benefit in my experience.
...but that's based on pre-IANA-runout rates, though, and doesn't account for the pent-up backpressure of demand. So probably a lot less, in reality.
Not even remotely worth the effort, even if there were a legal pretext for "reclaiming" IPv4 space (there isn't; there's already precedent denying it).
It affects anything where latency matters, e.g. from Facebook: "We’ve observed that accessing Facebook can be 10-15 percent faster over IPv6." (https://engineering.fb.com/2015/09/14/networking-traffic/ipv...).
SLAAC-by-default is not, in my experience implementing IT automation, an actual barrier for adopters. You have a router sending out RS instead of a DHCP server, to an admin this is not a meaningful change.
But the one interface that touches the internet can use v6: the one with a functionally infinite address space.
The most difficult parts for a homelab in my experience is getting Docker to play nicely. All of the other stuff sort of just works these days. Even things like using DHCPv6 prefix delegation to obtain a routable subnet is almost trivial with how well-supported the protocol is with modern networking software.
They use 464XLAT, basically NAT64/DNS64 with some extra cooperation on the OS’s part for backwards compatibility with apps that hard-code IPv4. You get only a v6 address, and your OS basically synthesizes an v4 network on your device in cooperation with their NAT64 router. But all the bytes going from your device through to their towers are ipv6. Talking to a v4-only website uses carrier-grade NAT64 when leaving the t-mobile network.
There might be a child behind the NAT, thus IPv6 requirement.
I have owned several Dell, HP and Lenovo Laptops in the past 15 years and I have never had a cellular modem.
When Apple makes a change like that it impacts a lot of customers because they have way fewer skews.
So what would be the correct setup with IPv6 when using privacy extensions?
I don't see any benefit in allowing IPv6 traffic or using IPv6, but a couple of new problems coming up with it.
How so?
"Skyrocket" is wrong but the market cap of IPv4 addresses is quite high.
> if IPv6 prevents IPv4 rental prices from going haywire, then it's served a useful purpose.
Competition is good.
I also remember the first IPv6 Workshop on W2k SP3 back in 2002. Not that long ago.
QA found it a couple weeks later when they were testing alerting, and SMSes weren't coming through.
v6 adoption is often an all or nothing, because if you run both stacks, you have to ensure they are consistent. While you can reasonably do it on your home LAN, doing it across an entire infrastructure is the worst.
Now you have to make sure all your subnets, routing, VLANs, firewall rules, etc work exactly the same in two protocols that have very little in common.
It is the equivalent of shipping two programs in different languages and maintaining exact feature parity between both at all times.
"The past is never dead. It's not even past"
You'd think they'd have sprinted for that feature as fast as they could go.
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 page actually performs in order to calibrate rate limiting.
Things have definitely gotten better over time, though. The massive 90s style corporate networks will probably never transition, but smaller and more modern companies don't have that issue.
Apple mandating that apps are IPv6 compatible and various government legislation forcing companies to make their shitty middleware IPv6-compatible has improved things quite a bit so far. As uptake keeps rising, the need for technologies like STUN and TURN will slowly start decreasing, and as a result more and more people will end up in "untested" situations where not having IPv6 and falling back to legacy paths starts becoming a problem.
* https://engineering.fb.com/2017/01/17/production-engineering...
* https://www.internetsociety.org/blog/2014/09/facebook-launch...
IPv4 is actually the "leftover" stuff they have to deal with at the front end.
But they are an eye-balls heavy service, with a lot of mobile devices, which also tend to be IPv6-native.
At what level did you need to pay for IPv4 addresses in this stack? You should have been able to make this work with a private IPv4 space, have the ECS services be dual-stack and be on both the v6 network and the v4 network to talk to the database server, have the ALB be v6, and then have Cloudfront be v6. If you wanted, you could also just ignore v6 for the ECS services and have them just live in that same v4 subnet entirely.
I could be wrong (and please tell me what I'm missing) but you shouldn't have had to pay for IPv4 in this case. I do just wish RDS (and so much else) would just support IPv6 though, you shouldn't need to have a bunch of extra subnets just to talk to your database.
What I am building won’t exhaust that, but I hear some customers are blowing through even that.
PSC has a builtin NAT. That also helps stitch things together.
… or we can have ipv6.
To the local network, it looks like there's native IPv4, but it's translated to IPv6 by the gateway, and sent to the "nearest" NAT64 PoP to be translated back and sent along its merry way.
But I wouldn't be surpised if we start seeing self-hosted minecraft or factorio servers with ipv6 only.
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.
This is incompatible with TCP/IP networking. In TCP connections, (sender_address, sender_port, receiver_address, receiver_port) is a unique combination. Those numbers together uniquely identify the sender talking to the receiver. For a public webserver:
* sender_address is the client machine's IP address
* sender_port is a random number from 0..65535 (not quite, but let's pretend)
* receiver_address is the webserver's IP address
* receiver_port is 443
That means it'd be impossible for one client IP to be connected to one server IP more than 65535 times. Sounds like a lot, right?
* sender_address is the outbound NAT at an office with 10,000 employees
Now each user can have at most 6.5 connections on average to the same webserver. That's probably not an issue, as long as the site isn't a major news org and nothing critical is happening. Now given your scheme:
* receiver_address is the gateway shared by 10000 websites
Now each user can have at most 6.5 connections to all of those 10000 websites combined, at once, total, period. Or put another way, 100,000,000 client/website combos would have to fit into the same 65535 possible sender_ports. Hope you don't plan on checking your webmail and buying airline tickets at the same time.
I think currently Apple still helps you with these via "bump in the stack" (i.e. they can translate internal v4 structures and addresses into NAT64-prefixed v6 at the kernel level), but they probably don't want to commit to doing that forever.
I'm suggesting moving on to IPvNN which requires device and ISP forced guarantees that the originator is not under the effect nor the lack of any medication or other substance, not being coerced and not using non-human assistants in content creation.
This approach prevents outbound connections from leaking the address needed to connect to your servers. On v4, it's likely that any outbound connection from your network gives the server the IP they need to do that.
USG also set a whole bunch of security requirements under FedRAMP that Microsoft can never meet, but they received an ATO anyway because they are so heavily entrenched in government.
The requirement is simply that the app does AAAA queries, and that it attempts to connect to them if they exist. It doesn't matter whether the server does v6 natively or if the ISP is covering for a v4-only server via backwards compatibility. (Native v6 will probably perform better, but any site that wants to give up that advantage is free to do so.)
I'm using OpenWRT and paid for a static IP so I had to manually configure all the details for the MAP-E tunnel in OpenWRT myself, I think typically the routers sold to consumers pick up the configuration automatically somehow.
I've been setting up Snapcast (open-source multi-room audio), and needed to move the server to a different machine. While I was setting up the new system, I told it to only bind to localhost. Somehow this only affects the ipv4 networking stack, as some of my clients started automatically connecting to the new server even before I had finished all my testing.
Turns out that it was advertising some kind of ipv6 link-local address that showed up in autodiscovery. In my case there wasn't any harm, but this type of thing could very easily result in a major security vulnerability.
"No". Not every human is psychologically prepared to do that. They want to acquiesce, to go along to get along, you need somebody to be firm. "No".
https://ipv6.he.net/certification/ has instructions on how to get started.
What’s nicer is 464XLAT, or more generally NAT64 prefix announcements. Then your local OS can just synthesize NAT64 addresses from v4 literals, either at the socket library or kernel networking (via “bump in the stack” translation) layer.
I didn't need to do any configuration for DS-Lite or MAP-E, as DHCPv6 with a configured prefix got IPv6 working, although DNS is still broken when turning off IPv4 entirely.
I remember when I was first using my alma mater's online sign up for classes in the very early 2000s, their class sign up site had office hours.
v4 was built around the idea of multiple free standing networks linked by gateways. v6 was built around the idea of a universal network.
I dont care about what your LAN adress space look like when I'm in my LAN, because we are not in the same v4 network. I am sovereign in my network.
With v6, everyone is effectively in the same network. I have to ask my ISP for a prefix that he will rent me for money even for my LAN. If I want some freedom from said ISP prefix, I am mercifully granted the honor of managing ULA/NAT66 (granted I paid for a fancy router).
Also if I want any kind of privacy, I will have to manage privacy extensions and the great invention of having to use automatically generated, dynamically routed, essentially multiple random IPs per interface. How lucky am I to use such a great new technology.
Seriously v6 was created by nerds in a lab with no practical experience of what people wanted.
I have also found that an uncomfortable number of people do not consider it appropriate in any way shape or form. Even when it’s ultimately your call and no one else’s.
Folks don’t really like waves. They like looking at them from the shore, but freak out when it’s their turn to hang 10
I'm less sure about Telekom. For obvious reasons, it's hard to find info in English.
I guess we both agree that both humor and sarcasm are difficult to convey on the internet and LLMs do not make the job any easier :-)
Privacy extensions are orthogonal here; they only affect the suffix, not the prefix. As for dealing with a changing prefix... I'm afraid you'll just have to find some way to automate the DNS updates. You can do it with a program running on one of the servers -- I can't suggest a specific one offhand since I have a static prefix and haven't needed it, but they do exist.
That's a matter for the legacy network on the other side of the internet to handle, as it converts my IPv6 packets to IPv4.
But at some point, getting a native connection to all of these started becoming increasingly rare, and now these are largely emulated/tunneled on top of IP. The same can happen for IPv4.
I don't think this is what v4 was built around, but rather what v4 turned into.
CIDR wasn't introduced until 1993 apparently. NAT in 1994
> With v6, everyone is effectively in the same network.
Just like IPv4.
> I have to ask my ISP for a prefix that he will rent me for money even for my LAN.
Just like IPv4, if you need a static address.
> If I want some freedom from said ISP prefix, I am mercifully granted the honor of managing ULA/NAT66 (granted I paid for a fancy router).
Compared with IPv4, where if you want some freedom from said ISP subnet, you are mercifully granted the honor of managing RFC-1918 addresses/NAT (granted you paid for a router that doesn't screw it up).
> Also if I want any kind of privacy, I will have to manage privacy extensions
...which are enabled by default nearly universally
> and the great invention of having to use automatically generated, dynamically routed, essentially multiple random IPs per interface.
Make up your mind. Are rotating, privacy-preserving addresses good or bad? The way it works in real life, not in the strawman version, is that you (automatically!) use the random addresses for outgoing connections and the fixed addresses for incoming.
Random Google result with a bit more:
https://www.captaindns.com/en/blog/ipv6-subnet-sizes-48-vs-5...
So if I wanted to annoy GitHub, I could connect to them without ever using the same IP twice. Their response would have to be banning my /64, or possibly /56.
In corporate software development, we work the tickets assigned, and keep our KPIs up so that we don't face the wrath of the bean counters.
I'm sure it's totally my fault but that's the point: folks who know how ipv4 works may have huge blind spots for ipv6.
But having the ipv6 prefix change you get a pile of problems (DNS, firewall), you don't have with ipv4.
No, as it's supposed to be implemented a single internet-routable /64 is used per *network* and then most devices are expected to assign themselves a single address within that network using SLAAC.
ISPs are then expected to provide each connected *site* with at least a /56 and in some cases a /48 so the site's admins can then split that apart in to /64s for whatever networks they may have running at the site. That said, I'm on AT&T fiber and I am allocated a /60 instead, which IMO is still plenty for a home internet connection because even the most insane homelab setups are rarely going to need more than 16 subnets.
> So if I wanted to annoy GitHub, I could connect to them without ever using the same IP twice. Their response would have to be banning my /64, or possibly /56.
Well yeah, but it's not like it's exactly rocket science to implement any sorts of IP rate limiting or blocking at the subnet level instead of individual IP. For those purposes you can basically assume that a v6 /64 is equivalent to a v4 /32. A /56 is more or less comparable to /25 through /29 block assignments from a normal ISP, and a /48 is comparable to a /24 as the smallest network that can be advertised in the global routing tables.
The usual convention for configuring listening interfaces usually involves listing IP addresses or interface names. There's very little room for misconfiguration here, although it's possible. More likely to be a bug in Snapcast (it's almost certainly not an issue in the Linux kernel).
Moreover, this general problem (i.e. configuring listening interfaces) is not/should not be different between IPv4 and IPv6. So introducing IPv6 should not™ incur any additional risk at this level.
But as said, it's hard to get more concrete without knowing exactly what happened in your case.