61–70 of 649 posts
I think IPv6 internal-only is viable with some kind of NAT64 setup, maybe not at scale though. What is everyone using for NAT64?
https://twitter.com/iPv4depletion/status/1584376525427978240
IPv6 has been one of the biggest failures in the last couple of decades. And I don't mean adoption, I mean the standard itself. If IPv6 were IPv4 with more octets, then we would all have been using it for like a decade. Yes, I understand it would still require some breaking changes, but it would have been a million times easier to upgrade, as it would be a kind of superset of IPv4 (1.2.3.4 can be referred as 0.0.0.0.…
> (1.2.3.4 can be referred as 0.0.0.0.1.2.3.4). Which would need translation support at the edges between devices speaking only old-IPv4 and the superset-IPv4. Just as is done with IPv6.
Earlier quoted context omitted.
I'd love for some way to measure how much of my network's traffic outbound and inbound is IPv6. I assume there's some way to "count" it on the router, but Mikrotik doesn't seem to expose it directly.
iirc mikrotik supports netflow. that's how i account for proto balance. FWIW, owing to the nature of residential traffic, I've typically seen high (60-70% of traffic) as v6.
I think IPv6 internal-only is viable with some kind of NAT64 setup, maybe not at scale though. What is everyone using for NAT64?
afaik jool is the currently-recommended foss nat64 (since tayga is apparently unmaintained) alot of commercial vendors have mature nat64 implementations tho
I’m still waiting for Amazon to start supporting Elastic IPv6 in their AWS.
What are you using EIP's for and the ability to float them?
Having "grown up" with IPv4, I'm slow to learn everything necessary to set up an IPv6 infrastructure. The times I did look into it, IPv6 seemed so much more complicated than IPv4, but maybe that's just because I'm just not familiar with it. Are there any good resources on setting up IPv6 support from first principles? I still get confused as to the "right" way to set up internal networks for IPv6, especially when DHC…
Earlier quoted context omitted.
That's really cool that global accelerator got support, I was about to bash AWS. It's one of those things when trying to optimize product market fit and quick launches, that we needed global accelerator, but not IPv6 on a project I worked on. So when major AWS / cloud services don't have the ability to just turn it on, is one part of the chicken and egg that contributes to the lack of adoption. Thanks for pressuring…
Yep, there are unfortunately some other AWS services that still don't support IPv6, but at least with Global Accelerator and ALB support, we can hide that from end-customers that require IPv6 endpoints. https://aws.amazon.com/blogs/networking-and-content-delivery... ALB/ELB/NLB support for IPv6 is fairly recent as well, November 2021: https://aws.amazon.com/about-aws/whats-new/2021/11/applicati...
https://docs.aws.amazon.com/general/latest/gr/aws-ipv6-suppo...
The biggest problem remains cloud and CDN companies with poor to nonexistent IPv6 support. Most ISPs, especially on mobile, have it now or are adding it very soon. I've wondered whether some might be dragging their feet because they see an advantage in IP address scarcity to sell cloud gateways, CDNs, and other middle box type services. But the most likely explanation remains that not enough customers are asking for…
I've never been on a non-mobile connection with IPv6. It's not a thing in Norway.
IPv6 has been one of the biggest failures in the last couple of decades. And I don't mean adoption, I mean the standard itself. If IPv6 were IPv4 with more octets, then we would all have been using it for like a decade. Yes, I understand it would still require some breaking changes, but it would have been a million times easier to upgrade, as it would be a kind of superset of IPv4 (1.2.3.4 can be referred as 0.0.0.0.…
> If IPv6 were IPv4 with more octets, then we would all have been using it for like a decade. I don't really think so: it woulds still be completely backward incompatible and still require replacing a lot of costly network equipment. I think that's the main reason why large ISPs and enterprises have been postponing the upgrade since forever but operating systems, smartphones and other new devices didn't really have a…
The difference is that instead of their ipv6 being broken, partial, or correct but non functioning because it needs additional configuration, it would properly work and support with the much simpler "ipv4+"
Earlier quoted context omitted.
anyone who thinks "ipv6mess" is still relevant in 2022, doesn't understand the problem space it describes. part 1, interoperability failure/incompatibility: nat64+dns64 has been viable since 2008 part 2, incoherence: dual-stack was the transition plan, & was clearly communicated from the start (to anyone who listened). that turned out to not be so effective since so many ppl ignored the realities of legacy ip depleti…
> anyone who thinks "ipv6mess" is still relevant in 2022, doesn't understand the problem space it describes. It was relevant then -and it is relevant now- because there are good lessons in how to migrate from thing A to thing B, even if some of the then-missing necessary bits are in place now. Still, it's almost certainly the case that DJB's rant had no real effect, and that the necessary steps were bound to be taken…
It doesn't give a fix because no fix is possible. Because the problem comes from the design of v4, not from v6.
For some reason djb wasn't able to get his head around that, and people have been pointing to that damn page as if it's some big gotcha ever since. No, it's just the situation we're stuck with, thanks to the people that designed v4.