This is the only topic that tempts me to create a throwaway account. (I have not given in) None of the IPv6 proponents are willing to acknowledge that IPv6 is a pain.
All of them seem to have gone to some secret seminar somewhere where they receive their talking points:
- Everyone who dislikes IPv6 doesn't know how NAT works and thinks it's the same as a firewall.
- There's absolutely no downside whatsoever to being publicly addressable. (also this is a good time to reiterate that NO ONE understands that NAT is not a firewall)
- 128 bit addresses are exactly as convenient and memorable as as 32-bit addresses.
- The entire internet would be hosting home servers if not for the evils of NAT.
You forgot important thing: There will always be some security guy yelling that leaking your internal IP structure is bad.
There will also be another clown that does IP whitelisting as security measure and refuses to just whitelist single /64|/24 network "because it is too wide" (I literally had this conversation last week with one of the clients)
> - The entire internet would be hosting home servers if not for the evils of NAT.
Why are we, in 2026, still talking about ipv6? It is time to give it up and start over. Yes, it is unlikely we can agree on an ipv4 successor. But at this point we should be able to agree ipv6 is not going to be it.
I disagree that it would've been just as hard anyway. The people who say "I just wanted v4 with more bits" have a point that most of these arguments completely ignore, but this one touches on it:
Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition.
The practical use would've been going all-in on those, making it as easy as possible for users to switch. But instead, the default way of using v6 was those new addresses, also SLAAC and no NAT, and 6to4 was bolted on in a way that never worked very well.
The thing is, their objective wasn't just to add more bits, it was to defrag the old v4 routes. If you did it the "just add more bits" way, once everyone is on v6 but with the old v4 /32s, the new address space for sale is underneath those. Maybe there'd be a way to defrag afterwards in a separate effort.
How would this have worked in practice, in a way that the NAT464/NAT64 schemes that most mobile operators use haven’t? Would IANA have dedicated some blocks of IPv4 to be used for IPv4-compatible IPv6 addresses on the public internet?
Copy-paste the v4 blocks into v6 space under a common prefix, let's say 4::. Routers and software add ipv6 support (as they already have), but you only use 4::. Now once a user wants to switch, it looks the same. I'm still on NAT and DHCP. If I'm hitting Google.com on ipv6, I still use DNS4 and get 142.251.214.110, it actually sends to 4::142.251.214.110 takes the exact same route.
Time has to pass for all users to switch to v6. DNS6 and DHCP6 are in-place upgrades to the existing ones, not alternatives, so now they support longer fields. Once that's done, Google.com can say hey actually we're 142.251.214.110.1 now, and probably my ISP also gives me x.x.x.x.1.1 and leases x.x.x.x.2.2 to someone else.
You can also do all the above without the 4:: prefix. The point of that was to keep the possibility of offering all-new routes under the other v6 /8s, but that has its own friction.
This already exists in two forms, and has for basically the entire history of production dual stack deployments. The first are IPv4 mapped addresses (of the form ::ffff:x.x.x.x) which instruct the local machine’s network stack to use a local IPv4 address to communicate to the server. This still requires each machine to have a routable IPv4 address (though not necessarily a public one - it can be used with a NAT44 router).
If you don’t want the local machine to have a routable IPV4 address at all (which is a common practice on mobile networks), you can do something similar with a different prefix (usually 64:ff9b::/96) called NAT46. In this case the local machine’s network stack exclusively emits IPv6 packets, and the upstream router/network detects the prefix and performs stateful NAT using its own IPv4 address(es), just like NAT44. Depending on the use-case, the local machine doesn’t even have to understand what you’re doing at all. Instead you just have the local network’s DNS server return fake AAAA records with the corresponding 64:ff9b::x.x.x.x addresses when some particular domain doesn’t have native IPv6 support.
The only thing I can think of is making it easier to run your local network v6-only. But if you're translating at the router like that, you don't need any particular mappings.
> But instead, the default way of using v6 was those new addresses, also SLAAC and no NAT...
Well, the good news is that we've had DHCPv6 and IPv6 NAT for at least like 25 years. It's true that these weren't standardized in 1995, but I always wonder how long things need to be fully supported [0] before people stop acting like they don't exist.
It took something like a decade for IPv4 to get DHCP, and I don't know how long for it to get NAT, and yet I don't hear people saying that IPv4 has no default mechanism for address autoconfiguration or network address translation.
The defaults determine what like 95% of users end up actually using, even if they have their own preference. Like you said, even if I wanted to use DHCP6, Android won't use it. My router also doesn't support it.
I'm sorry your router sucks. If -for example- my router intermittently fucked up its IPv4 NAT and sent NATted packets into the Internet Bitbucket, it would be incorrect for me to claim that IPv4 NAT sucks or isn't supported by default. The correct claim would be that my router's NAT implementation sucks.
A router messing up IPv4 NAT would make it unusable for v4. My router still works with v6, just doesn't support an optional extension of it. (Idk if the v6 spec actually says DHCP is optional, but it de facto is because slaac isn't, likewise NAT isn't even part of v4 spec but a home router will need it.)
And it's not exactly a bad thing that most routers have only one right way to do v6 addressing. One thing that's explicitly optional in v6 is default-deny firewall, which is where those "v6 is insecure" "no you're just using it wrong" fights come from:
REC-49: Internet gateways with IPv6 simple security capabilities MUST
provide an easily selected configuration option that permits a
"transparent mode" of operation that forwards all unsolicited flows
regardless of forwarding direction, i.e., not to use the IPv6 simple
security capabilities of the gateway. The transparent mode of
operation MAY be the default configuration.
You could say well the user is dumb for not changing this setting, but there's a point where you should blame the design instead of the user if it's not generating the desired outcome across many users. This also goes if you actually want the router to leave your inbound alone and let the devices do firewalling, cause your device isn't going to be reachable when you're on someone's default-deny network.
they have no point. some random aesthetic aspect of a standard is not why it does or does not get adopted. it's an evolutionary standard that offers no direct incentives for adoption.
the real obstacle was enterprise sales, that is, someone had to pay Microsoft, Google, Amazon, etc. as a major customer of theirs to implement correct IPv6, which takes time. the people at Microsoft working on ipv6 for customers, they're only going to implement the parts that customers need, they're not going to proactively discover all the bugs and fix everything. this is true about everything, i'm not saying anything that unorthodox, except...
the reason we're talking about ipv6 now is, in a post LLM world, it is now possible to take a well written and thoughtful spec like ipv6 and Just Do It. you don't have to wait for a customer relationship to do it.
Despite the lack of incentive for some, it's gotten pretty far. Pretty much every network device and host supports it in a minimal way. It's just that people/corps don't want to switch because it introduces a lot of risk and changes in unexpected areas. Like you can fully understand the spec without knowing what the routes and reputation will look like.
I have a /56 at the datacenter and Google Fiber gives me something like a /64 or something so I have full IPv6 connectivity everywhere. For the most part this is fine, but I've noticed the Internet is 'less reliable' on IPv6 and so in my head I still feel like it's a little iffy. There are times where a AAAA record points to an IP that doesn't respond, but the A record responds and so on. I just think it's the same as my blog's Gemini protocol server. I don't use it and offer it for fun but it's a best-effort basis. If it went down for months I wouldn't notice.
Despite the article title, IPv6 is not the complication. The problem is that IPv4 is incumbent and IPv6 has to live along side of it. It doesn’t matter how it’s done, the dual stack nature of expanding the addressing system will always exist.
I think this is the kind of the topic that can be endlessly debated because you can not easily go back in time and test out alternate hypothesis. I will say that I do not like ipv6 because it tried to fix multiple accumulated problems. I know! How contrarian! How can you be against trying to fix things. But all of those issues made ipv6 a dual stack solution that replaced ipv4.
Address exhaustion, Routing table scalability, restore end to end routability, autoconfiguration, header simplification, mulitcast + anycast, security standardization.
Whereas, I think a lot of those things could have been solved in other ways, or more slowly. I would have preferred a ipv4.2 64 style because it would have prioritized
Address exhaustion, keeping backward operational compatibility, fewer changes to institutional knowledge, and still had incremental rollout (that I think would have occurred much more quickly than ipv6).
There was a proposal called SIP that mostly focused on increasing address length (it got published as a historic RFC eventually): https://www.rfc-editor.org/rfc/rfc8507
It still had the problem that it made it harder for middleboxen (compared to IPv4) to look at port numbers.
You are right that a 32 bit ipv4 stack can not understand a 64 bit packet format. The thing I am trying to get at is not native compatibility, it is operational compatibility via translation. I know, I know, you will probably say that is what ipv6 bridges do.
But in an ipv42 type setup, you would have determnistic embedding so that every ipv4 address is represented inside the larger address space. This would allow translation at network boundaries and let old systems continue to operate unchanged. Then the routers and systems would be upgraded incrementally. I think that is why it would have been upgraded more quickly.
I remember reading about that a long time ago. I wonder why it never really caught on?
I think part of the problem is not so much a technical one, as a coordination issue. Who are you more likely to get on board? ISP and backbone providers. What is the path forward? Here is the recommended path forward, kind of thing.
I went and re-read point 3B. I agree that some hypothetical ipv42 faces a translation problem.
But it does not follow that address design is irrelevant. The structure of the address space directly determines whether translation can be stateless and alogrithmic.
In a hypothetical ipv42 design that preserves a deterministic embedding relationship between old and new addresses, translation at the edges could be largely stateless and mechanically reversible, to reduce coordiation overhead between operators and it makes reachability more predictable.
In our world ipv6, the transition seems to require a mix of dual stack, nat64, dns64, tunneling aproaches. The mapping between ipv4 and ipv6 is not uniformly deterministic across all deployment contexts.
Also, there is just a human factor. The mental gymnastics that go on. The perception of what is the way forward? With ipv6, it feels like everyone has to go get their ipv6 stack in order. With a hypothetical ipv42, where the ISPs and backbone providers can throw in the translation layers, it feels like, to me, they would have gotten on board much more quickly. Yeah, I know, it is just a feeling.
I agree with you about the embedded addresses, and I don't understand why the space was moved to all zeros to a bunch of other mappings.
but the utility of this isn't that high. we already know how to handle 4-4 and 6-6 traffic just fine. but if a 4 host wants to talk to a 6 host, it just doesn't have the extra bits in order to describe it, so this just doesn't facilitate 4-6 endpoint communication at all. this is true even you substitute v6 with any other layer 3 with a larger address space.
where it does help is in a unified routing backbone, that would allow v4 prefixes to be announced in the v6 routing system. which is arguably useful.
I don't see how it matters we forced people into ipv6 as well. Who cares. It's more about the difference in mental models that prevented adoption especially among those who run the services that are on the internet.
This is a fake argument. Noone is arguing for backwards compatibility.
But there was also no necessity to demand reshaping networks and changing address assignment in a way that made migration extremely work intensive and hard to deploy in parallel.
Yes, but CGNAT is an inherently stateful system and as a result will always be more expensive to operate per packet than a stateless router. The reason we are seeing steady (if slow) growth in native IPv6 is because the workarounds for IPv4 exhaustion cost money, and eventually upgrading equipment and putting pressure on website operators to support IPv6 becomes cheaper than growing CGNAT capacity.
How you would have implemented backward compatibility? I am interested to hear the general technical details of how this could have been possible.
I am mostly interested in two basic scenarios. With expectation that only on one side is any changes made. Host from new addressing scheme connecting to old one and receiving data back. Host from old addressing scheme connecting to one in new one and receiving data back.
Personally, i feel it is complicated because ISPs are highly afraid of trying it. I understand that such novel technology would be risky to use. But after 20+ years there are still many countries, like Spain, which are barely using it. After that much time has passed, it is already well battle-tested. At this point, you don't want to make the move either because you are too afraid of anything or you have commercial reasons.
I believe Telefonica has reasons to not use IPv6... Although in the long run is turning to be a bad decision. Look at digi :p
I think they are not afraid, they just see 0 reasons to
without IPv6: everything works already, your customers can access any website
with IPv6: ...what are the benifits to them? they still have to provide IPv4 to customers or do some ipv6 to ipv4 translation to make sure ipv4 websites still work
(I've never worked at an ISP so my opinion might be useless)
> I think they are not afraid, they just see 0 reasons to
This is a big part of it. Apart from extra addresses, it offers remarkably little benefit in terms of networking features from an operational management perspective. It sounds like it should be better when you look at the features, but, in actual operation the features don't really offer that much.
Further, there's the general problem that for some reason the network equipment manufacturers seem to think that because you don't frequently need NAT that now you don't need to have a stateful firewall just always on by default on a network edge device.
Plus the general confusion among tech neophytes that NAT itself is offering actual security features, so that a stateful firewall is a downgrade. This is such a fundamental misunderstanding that you can't even communicate with a person that believes it to be the case. I fear that this confusion will remain with us for decades. I'm sure me even mentioning it will spawn a whole thread of people vehemently disagreeing, because there is always at least one.
This is coupled with the fact that the addresses are just ugly. Like, I'm sorry, but unless you're exactly an electrical engineer, the IPv6 addressing scheme is difficult to remember. IPv4 has the same problem -- the magic numbers are only easy to remember if you have memorized the binary values, too -- but it's really only a handful of things to remember in comparison. Hex values are just not as easy to read or remember compared to decimal numbers. So even though IPv6 isn't harder to use, it feels like it's much harder to use.
There are some reasons, which is why you do see IPv6 use increasing. IPv4 exhaustion means that almost all mobile (and in some countries landline) internet connections have to access the IPv4 internet through Carrier Grade NAT. ISPs have to buy the equipment to operate these and pay for their maintenance, and they have to do so in proportion to how much traffic is stuck on the IPv4 internet. At a certain point making the necessary investments to send more traffic over IPv6 end-to-end becomes a better bet than continuing to maintain a growing CGNAT stack.
The tough part is that while ISPs can largely control whether their mobile and residential users have IPv6 available they can’t really do so for their business users, let alone arbitrary website operators they have no relationship with. So the reality is that everyone is going to have to maintain both 4to6 and 6to4 basically forever. But as it becomes less common it’ll no longer need to be especially fast or efficient and the costs to operate it will come down.
IT and telecom tend to have an ultra conservative if it’s not broke don’t fix it attitude. It won’t get deployed until enough customers ask for it or it’s required for something important.
My personal opinion of having worked with all layers of networking for my job without developing a comprehensive understanding, is this:
We as consumers see and use the highest level, which is often https or friends, and due to the layered nature of the OSI stack, as often happens in software, if a layer is lacking in something, it gets fixed 1 or 2 layers up. If then said thing is then implemented on the layer its supposed to, its often unwelcome and just causes issues.
TCP/IP has already acknowledged this (haha) by offering UDP, on top of which you can build the network protocol of your dreams.
And people have. It's called QUIC or HTTP3. It does everything one could ask of a network protocol, with QoS, NAT punchthrough, packet based low latency/overhead comms, etc. etc.
And QUIC doesn't assume any sort of advanced mechanisms beneath, it works happily with IPv4.
And once you have everything figured out for you on the level you like to work, there's not really a need for the lower layers to pick up the slack, as long as they work reliably.
I installed a new bare metal server from a european cloud provider this week.
Both my clean Debian and the rescue system couldn’t reach internet through IPv6 despite getting an address through DHCP.
I immediately permanently disabled IPV6. I usually do that pretty late in my installation scripts anyway.
I understand the perfect solution didn’t exist and still doesn’t exist, but it’s frustrating. I wish IPv6 could work reliably, not only on major CDNs, and that is appreciated. Then IPv4 would be a vanishing memory.
It's supposed to Just Work on clean and rescue systems. Otherwise, it's a regression with respect to v4. The fact that it doesn't work is evidence that someone has been doing something wrong. The user at the receiving end of this clusterfuck is not that someone.
Or it means a ton of people can't connect to you because of your netcode preferences, and that makes your boss very upset. It'll get fixed extremely fast, and fixed means turning IPv4 back on.
The problems of IPv6 deployment are ones of incentives, not design.
Increasingly, the vast majority of services are accessed via the service cone of various CDNs and IAAS providers directly at edge servers local to them, and at some point it may be that the industry decides that it's not worth providing ordinary internet users the ability to talk to each other directly at all. At which point, we might just as well have stuck with IPv4. I don't particularly like that outcome, but it's possible.
> First of all, IPv6 really is a conservative design - it doesn't change the basic IP model of connectionless packet switching with topological addresses.
There's nothing stopping you from using memorable ULA prefixes on your LAN [0] and requiring the use of DHCPv6 for addressing so that each host gets a host part that is easy to remember. Hand-selecting your ULA prefix abandons the collision-resistance that you get from using The Technique to generate one, but if that's something you don't care about, then it's something you don't care about.
Plus, manual address assignment is just as viable in an IPv6 world as it is in IPv4.
[0] fd00::/64 is quite easy to remember, as are fd00::1 and similar.
If I hadn't put my long-running machines' -er- ULA-derived [0] SLAAC addresses into my local DNS ages ago, I'd either do exactly that, or slice off the "redundant" parts of the IPv4 address off, so that I could choose to assign sixteen additional bits of addresses to each host. That is:
- ipv6: prefix:192:168:0:42
would become
- ipv6: prefix::0:42:[0-ffff]
[0] I'm really not sure how to succinctly say "The autonomously-configured addresses on my LAN's ULA prefix".
Short answer: Too many cooks in the kitchen, and too many of 'em motivated to make it more complicated.
A computer standard that is still widely avoided almost 30 years after it became official is a computer standard that should have been tossed in the bin before the ink was dry.
ARP and DHCP really look really dirty whenever I look at them. Like pretty bad designs overall. From more neutral viewpoint it feels that whole stack would be better with something else than these clear hacks.
Is it a job security issue? Greyed Neckbeards keeping things overly complex because they’ve managed to cement themselves in with IPv4 systems and anti-IPv6 talk?
The changes to Ethernet lookup mandate that you have a link-local address in addition to your “real” address, and this starts the ball rolling on the idea that machines have multiple IP addresses in general. Which makes privacy addresses commonplace, ULA+GUA addresses on the same machine, etc.
I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity, and you can’t easily predict what address will be used when connecting somewhere. IP-based access control becomes impossible (not that it was ever a great idea in the first place), reverse DNS lookups become irrelevant, seeing IP’s in logs no longer tells you “what machine connected here”, it’s overall a big change in mental model.
But then you get over it, stop making assumptions that you can rely on IP addresses for knowing things about a host, and the rest of it is fine.
I'm not necessarily talking about fingerprinting or tracking here, it can be something a lot more mundane. Like if I have a homelab setup and I want to see what hosts connected to something, and I look at the logs and see privacy addresses, I know I'll never know what host it was. Or if I want to set up netgroups for access control to shares or something (just a hypothetical.)
In the classic sysadmin world, the idea that an IP you see could belong to any host and you have practically zero way of knowing, is rather different from what we expect in the IPv4 world. You just have to embrace it, basically.
> I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity, and you can’t easily predict what address will be used when connecting somewhere.
Can't you unset the "Use autonomous addressing" bit and set the "Use DHCPv6 for addressing and other config" bit in your RAs, and then refuse to hand out anything other than DHCPv6 Normal Addresses? Or do OS's ignore the fact that Temporary Addresses are an entire other category of DHCPv6 addresses and just go off and make their own "privacy addresses" off of the advertised prefix in the RA... ignoring the router's command to not use SLAAC for addressing? [0]
[0] Yes, I'm very aware that Android doesn't support anything that DHCPv6 provides other than getting an entire damn prefix delegated. For the duration of this discussion, let's ignore Android.
IME nothing pays attention to when you set a flag to not do autonomous addressing. macOS and iOS don't respect it AFAICT, I don't recall what Linux does by default, but I don't remember having any success.
But it's rather not really my point... best practices for IPv6 are to not do any of this, and you probably don't want to do it, because privacy addresses are an actually-important thing for privacy (so that sites can't correlate you easily.) You can say "oh but websites use fingerprinting anyway" (which doesn't help you when it's not a web browser you're using, but any other software that's connecting places) or "but sites don't trust the trailing 64 bits" (which only helps because everyone else is using privacy addresses, which rather proves my point.) When doing IPv6, you sort of have to abandon the idea that you're going to have a fixed, known IP address that you will use for all outbound connections. Fighting this is an exercise in pain.
> IME nothing pays attention to when you set a flag to not do autonomous addressing.
When I unset the Autonomous flag, Linux does the right thing, at least on the systems I have at hand. Android does the right thing. My Playstation 5 does the right thing. I'd be shocked if Windows doesn't do the right thing. While I wouldn't be surprised to hear that Apple devices absolutely do the wrong thing -given Apple's long history with flagrantly doing the disruptively-wrong thing in regards to networking-, based on the results I'm seeing, I expect that Apple devices work just fine. I think you came to the wrong conclusions because you fucked up your test.
> ...privacy addresses are an actually-important thing for privacy (so that sites can't correlate you easily.)
As you allude to, The Web has eleventy billion ways to track you that give absolutely zero shits about your IP address. "Privacy" addresses buy the typical user of The Internet effectively zero privacy. January's deprecation of DHCPv6 "Temporary Addresses" suggests that folks who deploy this stuff believe that this feature is far less useful than proponents might think it to be. Plus, absolutely nothing prevents a DHCPv6 server from randomly generating the host part of the addresses it hands out, as well as handing out entirely new addresses for each address request. If I believed that "privacy" addresses actually provided any meaningful privacy, that's how I'd configure mine to behave for hosts that I wasn't intentionally providing fixed addresses.
the intent behind the ipv6 spec was to remove dhcp as a requirement for establishing layer 3 connectivity. there was a generalized notion at the time that other service discovery (dns) would be handled by a more graceful multicast protocol. that was a very reasonable position to take.
but operational inertia got in the way. I don't think people really wanted to think about what a dhcp-less world would look like, even if it removed the requirement to manage a central service and the associated configuration.
this was kind of ok. but then things got ugly. people wanted to be able to get assigned prefixes dynamically from their upstream provider that they could subnet themselves. because we don't think about these issues architecturally anymore, someone put that function on dhcp. and since we don't think about these issues architecturally anymore no one really realized that that would require _another_ protocol on the inside of that boundary to manage assignments in the providers space.
and now we don't even have the option of depreciating dhcp gracefully.
SLAAC and DHCPv6 actually make a ton of sense, along with the other features of IPv6. I think you need a lot of experience in both networking and applications, at many scales, to understand the design decisions and appreciate how useful they are in which contexts. That said, you could publish a clear playbook for an ISP of residential Internet for ipv6 adoption, it wouldn't change much, because they are not deciding to adopt ipv6 based on either its aesthetics or its technical merits.
Article does not address the elephant: there is no ability to NAT with IPv6. Sure, absolutely, you shouldn't have to NAT, but in my datacenter, NAT is a feature, not a bug. The article specifically asks "did the ipv6 designers go mad" and then they list features I've never heard of or use to prove they didn't. Those features are not why I think they went mad. The inability to create a NAT is.
For this reason, at every shop I've ever worked at, the intranet is ipv4, often with ipv6 disabled, with dual stack on the load balancer for ingress traffic. Note, I do not set it up that way: it comes like that when I've arrived.
Its not just NAT, it's also DHCP. Somehow the nerds creating IPv6 decided to not only add bytes (which is what people wanted), but also "fix" DHCP and NAT, which nobody asked for.
When ipv6 was first created DHCP and NAT were new and not widely deployed. They weren't trying to "fix" them, they solved the same problems independently.
And if you need NAT or DHCP, there isn't any reason you can't use them with ipv6. DHCP6 had been around for a long time.
that's not at all true. DHCP was very much part of the operational canon of the internet at the time, which is why it persisted as a model. V6 really wanted to back that out so that networks 'just worked' without depending on an administrator to manage that local service.
NAT was already in use, and a substantial motivation for the IPv6 work was to provide an alternative before it got too entrenched, which sadly failed.
I'm not sure what you mean by "fix" DHCP and NAT, but FYI: RFC 3315 was published in 2003.
As far as NAT goes, it looks like iptables added IPv6 support to the MASQUERADE, SNAT, and DNAT targets in kernel version 3.7, released in 2012. IDK when other OSs added such support.
I wasn't around for the discussions at the time, but I would have asked for it if I was. SLAAC is IPv4LL, except that you usually get a globally-routable IP address from it. It's great. It's also quite a bit simpler than DHCP... "If the advertised prefix permits autonomous addressing, generate a host part in the non-fixed part of the prefix, run DAD on the generated address to ensure it's not in use, and start using it if it's not.".
> SLAAC was part of IPv6 since the original RFC...
An attentive reader notices that RFC 1883 and RFC 1971 are separated by nearly a year.
NAT is a crutch to circumvent the problem of "there are not enough addresses for each device".
I _assume_ you are referring to a default deny inbound firewall (so that devices are not reachable from the outside), but these are very different, completely orthogonal concerns (and independent of the IP version in use).
Everyone I've talked to with this opinion are typically mobile devs thinking about cell phones. Ipv6 works great there, but NATs are often used in corporate networks for isolation and in particular obfuscation. You can't tell what's behind a NAT by inspecting traffic coming from inside it like you can with no NAT networks. Some of the networks I administrate are contractually obligated to be so isolated.
> I administrate are contractually obligated to be so isolated
Yeah, I've seen those contracts. They just reference a SeCuRiTy doc that's 20+ years old, and has never been re-evaluated. Things are secure because they follow the doc, not because they have actually evaluated the reasonable attack space.
I've fighting customers for years on their ideas of proper TLS usage and it's always the same thing. They've got a security doc that never changes and has never evaluated any of the trade-offs. Almost to the point that the people who wrote them choose things that increase downtime and KTLO work without helping security.
Ah-yup. The equivalent in my world is contracts that insist we make our employees rotate their passwords every 2 months or whatever, which was a popular (but still dumb) idea 20 years ago and is strongly recommended against today.
On week one of my current job, I turned that off for the whole company. Here's the citation you can give your security department to show them why they're doing it wrong.
NIST Special Publication 800-63B, the July 2025 version, section 3.1.1.2, says:
"Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised."
The previous version from June 2017, section 5.1.1.2, says:
"Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator."
So 9 years ago, NIST said to stop requiring that. Last year, they clarified that to say, no, really, freaking stop it. Any company still making people do that today is 9 years out of date, and 1 year out of compliance.
Obfuscation. By inspecting packets coming from my network now you can tell what MAC addresses are in my network and also internal network topology. It's part of the reason your cell phone feels the need to randomize its MAC.
> my network now you can tell what MAC addresses are in my network
only if you're using EUI-64, but I don't think many things use that anymore. I think the only thing is cisco shit. but even then I suspect that they have RFC7217 on by default at least.
but why do you want NAT? to hide whats in the datacentre?
I mean thats what reverse proxies are for, if you're that worried.
NAT doesn't give you anything useful, apart from the veneer of security. Sure it feels like your safe because there isnt a direct routable link between host A and the outside world, but thats not actually true.
If you want that, then you need firewalls and reverse proxies, even in IPv4.
2. NAT is totally orthogonal to IP and addressing.
3. NAT (as in transparent packet modification to rewrite addresses) is utterly idiotic. Ephemeral, anonymous address allocation with inbound filtering is smart, but transparently rewriting packets to do that is one of the dumbest possible ways prone to horrible compatibility and ossification issues as has been proven empirically.
I engineer and design network device drivers and network protocol stacks.
NAT is a terrible network protocol. The correct protocol would have been a DHCP extension giving you a 49-bit address where your IPv4 address constitutes a /32 with a 17-bit unique local address.
I am reading about ipv6 nat. I guess it's possible but discouraged?
This contention point confuses me. I consistently get downvoted for this opinion, and I've seen contrarian voices online, but I have yet to meet an actual datacenter network admin who disagrees with me.
Facebook uses IPv6 virtually everywhere. They have NAT for ipv4 in dual stack (usually only on certain desktop machines), but not for IPv6 as that defeats the usefulness of it.
virtually all the datacentre is exclusively IPv6. they kinda have NAT in the sense that all the web proxies at the edge terminate the IP connections with the outside world, but thats higher up the stack rather than on the IP level.
However I never dealt with the edge stuff, as that was far away from what I was doing.
I am one, also disagree with you. Ipv6 nat is possible. I dont find nat particularly useful inside a network and dont use it unless strictly required to solve a problem like shared internet access or overlapping IP addresses. Isolation is best handled with separate physical networks, vlan or firewalls.
I think we've been shunted into an alternate universe by NAT - one which reinforces the power of large companies because we essentially cannot communicate computer to computer without going through some service.
As for security.........are we really that secure running code in our browsers that we downloaded from who knows where? Is nat really saving us?
And now here we are with IPv6 and the real age of the network could begin.
Personal experience that I see noone talk about with IPv6 is how much more expensive hardware that handles it correctly is for datacenters. On IPv4 your usual unit of allocation is a /32 for customers - that means a simple hashmap `1.1.1.1=destination mac` works wonderfully and is cheap (single memory lookup), but for ipv6 your usual unit is a /64 so its longest prefix match instead, which requires parsing the address to group it back into the /64 and alot of switches and routers that are already expensive still have very low limits on LPM memory banks.
Expensive switch at work we have can only do 3000 route entries for example on ipv6. If we did /128s it's basically infinite though, because it goes from a LPM to exact match, which has much much more memory available.
Doesn't help as well that for example, to be able to do SLAAC or even DHCPv6 (which barely works reliably in my experience) you need to do a /64 at minimum, those mechanisms dont even work otherwise, so for ISPs who can easily have more than 3000 downstream customers doing routed ipv6 is such an increase in hardware cost vs just doing NAT which they were already doing anyway.
Never mind the actual performance issues that I keep seeing in production deployments.
We have large networks that are essentially rolling on autopilot totally unmanaged, like Lumen'e recently sold Quantum Fiber asset that is now owned by AT&T holding company Forged Fiber 37 LLC
No native IPv6 still on this forgotten about network, 6RD keeps having weird routability issues, but if you just disable IPv6 everything works fine.
Why on earth would you ever want to route something smaller than a /64? At the ISP level, you'd only be concerned about your customers' /48 or maybe /56 networks.
OP seems to want to route /64 or larger to each customer, but can only have 3000 total entries larger than /128 in the expensive routers his firm owns.
Essentially the hardware doesn't support scaling a /64 or /56 to each customer, leaving OP in a terrible position when it comes to proper IPv6 deployment.
When you look at Ziply Fiber, they seem to be ripping out these types of Enterprise grade routers left and right in favor of a simple Linux box doing routing. I think a large portion of why they're doing this is due to limitations like what OP is experiencing
Both of which are LPM and cause the issue I just mentioned! It's not about "routing lower than a /64" its about LPM vs Exact Match memory bank usage (and for some reason, how much more expensive good hardware that handles LPM is).
NAT requires remembering every connection pair (IPv4:port for both internal and external sides of the NAT)
You don’t need more than the /64 to know where to send traffic, all of the bits required are still just in the prefix. One route per customer… the edge deals with addressing issues.
All of them seem to have gone to some secret seminar somewhere where they receive their talking points:
- Everyone who dislikes IPv6 doesn't know how NAT works and thinks it's the same as a firewall.
- There's absolutely no downside whatsoever to being publicly addressable. (also this is a good time to reiterate that NO ONE understands that NAT is not a firewall)
- 128 bit addresses are exactly as convenient and memorable as as 32-bit addresses.
- The entire internet would be hosting home servers if not for the evils of NAT.
There will also be another clown that does IP whitelisting as security measure and refuses to just whitelist single /64|/24 network "because it is too wide" (I literally had this conversation last week with one of the clients)
> - The entire internet would be hosting home servers if not for the evils of NAT.
ISPs will find a way to fuck up
The thing is, their objective wasn't just to add more bits, it was to defrag the old v4 routes. If you did it the "just add more bits" way, once everyone is on v6 but with the old v4 /32s, the new address space for sale is underneath those. Maybe there'd be a way to defrag afterwards in a separate effort.
Time has to pass for all users to switch to v6. DNS6 and DHCP6 are in-place upgrades to the existing ones, not alternatives, so now they support longer fields. Once that's done, Google.com can say hey actually we're 142.251.214.110.1 now, and probably my ISP also gives me x.x.x.x.1.1 and leases x.x.x.x.2.2 to someone else.
You can also do all the above without the 4:: prefix. The point of that was to keep the possibility of offering all-new routes under the other v6 /8s, but that has its own friction.
If you don’t want the local machine to have a routable IPV4 address at all (which is a common practice on mobile networks), you can do something similar with a different prefix (usually 64:ff9b::/96) called NAT46. In this case the local machine’s network stack exclusively emits IPv6 packets, and the upstream router/network detects the prefix and performs stateful NAT using its own IPv4 address(es), just like NAT44. Depending on the use-case, the local machine doesn’t even have to understand what you’re doing at all. Instead you just have the local network’s DNS server return fake AAAA records with the corresponding 64:ff9b::x.x.x.x addresses when some particular domain doesn’t have native IPv6 support.
IPv4-mapped IPv6 addresses (prefix ::ffff:0:0/96)
Network stacks do allow this today.
The only thing I can think of is making it easier to run your local network v6-only. But if you're translating at the router like that, you don't need any particular mappings.
Well, the good news is that we've had DHCPv6 and IPv6 NAT for at least like 25 years. It's true that these weren't standardized in 1995, but I always wonder how long things need to be fully supported [0] before people stop acting like they don't exist.
It took something like a decade for IPv4 to get DHCP, and I don't know how long for it to get NAT, and yet I don't hear people saying that IPv4 has no default mechanism for address autoconfiguration or network address translation.
[0] ...by everyone except Android, of course...
I'm sorry your router sucks. If -for example- my router intermittently fucked up its IPv4 NAT and sent NATted packets into the Internet Bitbucket, it would be incorrect for me to claim that IPv4 NAT sucks or isn't supported by default. The correct claim would be that my router's NAT implementation sucks.
And it's not exactly a bad thing that most routers have only one right way to do v6 addressing. One thing that's explicitly optional in v6 is default-deny firewall, which is where those "v6 is insecure" "no you're just using it wrong" fights come from:
You could say well the user is dumb for not changing this setting, but there's a point where you should blame the design instead of the user if it's not generating the desired outcome across many users. This also goes if you actually want the router to leave your inbound alone and let the devices do firewalling, cause your device isn't going to be reachable when you're on someone's default-deny network.the real obstacle was enterprise sales, that is, someone had to pay Microsoft, Google, Amazon, etc. as a major customer of theirs to implement correct IPv6, which takes time. the people at Microsoft working on ipv6 for customers, they're only going to implement the parts that customers need, they're not going to proactively discover all the bugs and fix everything. this is true about everything, i'm not saying anything that unorthodox, except...
the reason we're talking about ipv6 now is, in a post LLM world, it is now possible to take a well written and thoughtful spec like ipv6 and Just Do It. you don't have to wait for a customer relationship to do it.
Address exhaustion, Routing table scalability, restore end to end routability, autoconfiguration, header simplification, mulitcast + anycast, security standardization.
Whereas, I think a lot of those things could have been solved in other ways, or more slowly. I would have preferred a ipv4.2 64 style because it would have prioritized
Address exhaustion, keeping backward operational compatibility, fewer changes to institutional knowledge, and still had incremental rollout (that I think would have occurred much more quickly than ipv6).
It still had the problem that it made it harder for middleboxen (compared to IPv4) to look at port numbers.
It is not possible to be backwards compatibility with a larger address space
But in an ipv42 type setup, you would have determnistic embedding so that every ipv4 address is represented inside the larger address space. This would allow translation at network boundaries and let old systems continue to operate unchanged. Then the routers and systems would be upgraded incrementally. I think that is why it would have been upgraded more quickly.
IPv6 supports that, but it ended up not getting used very much.
See https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan...
I think part of the problem is not so much a technical one, as a coordination issue. Who are you more likely to get on board? ISP and backbone providers. What is the path forward? Here is the recommended path forward, kind of thing.
But it does not follow that address design is irrelevant. The structure of the address space directly determines whether translation can be stateless and alogrithmic.
In a hypothetical ipv42 design that preserves a deterministic embedding relationship between old and new addresses, translation at the edges could be largely stateless and mechanically reversible, to reduce coordiation overhead between operators and it makes reachability more predictable.
In our world ipv6, the transition seems to require a mix of dual stack, nat64, dns64, tunneling aproaches. The mapping between ipv4 and ipv6 is not uniformly deterministic across all deployment contexts.
Also, there is just a human factor. The mental gymnastics that go on. The perception of what is the way forward? With ipv6, it feels like everyone has to go get their ipv6 stack in order. With a hypothetical ipv42, where the ISPs and backbone providers can throw in the translation layers, it feels like, to me, they would have gotten on board much more quickly. Yeah, I know, it is just a feeling.
but the utility of this isn't that high. we already know how to handle 4-4 and 6-6 traffic just fine. but if a 4 host wants to talk to a 6 host, it just doesn't have the extra bits in order to describe it, so this just doesn't facilitate 4-6 endpoint communication at all. this is true even you substitute v6 with any other layer 3 with a larger address space.
where it does help is in a unified routing backbone, that would allow v4 prefixes to be announced in the v6 routing system. which is arguably useful.
But there was also no necessity to demand reshaping networks and changing address assignment in a way that made migration extremely work intensive and hard to deploy in parallel.
I am mostly interested in two basic scenarios. With expectation that only on one side is any changes made. Host from new addressing scheme connecting to old one and receiving data back. Host from old addressing scheme connecting to one in new one and receiving data back.
I believe Telefonica has reasons to not use IPv6... Although in the long run is turning to be a bad decision. Look at digi :p
without IPv6: everything works already, your customers can access any website
with IPv6: ...what are the benifits to them? they still have to provide IPv4 to customers or do some ipv6 to ipv4 translation to make sure ipv4 websites still work
(I've never worked at an ISP so my opinion might be useless)
This is a big part of it. Apart from extra addresses, it offers remarkably little benefit in terms of networking features from an operational management perspective. It sounds like it should be better when you look at the features, but, in actual operation the features don't really offer that much.
Further, there's the general problem that for some reason the network equipment manufacturers seem to think that because you don't frequently need NAT that now you don't need to have a stateful firewall just always on by default on a network edge device.
Plus the general confusion among tech neophytes that NAT itself is offering actual security features, so that a stateful firewall is a downgrade. This is such a fundamental misunderstanding that you can't even communicate with a person that believes it to be the case. I fear that this confusion will remain with us for decades. I'm sure me even mentioning it will spawn a whole thread of people vehemently disagreeing, because there is always at least one.
This is coupled with the fact that the addresses are just ugly. Like, I'm sorry, but unless you're exactly an electrical engineer, the IPv6 addressing scheme is difficult to remember. IPv4 has the same problem -- the magic numbers are only easy to remember if you have memorized the binary values, too -- but it's really only a handful of things to remember in comparison. Hex values are just not as easy to read or remember compared to decimal numbers. So even though IPv6 isn't harder to use, it feels like it's much harder to use.
The tough part is that while ISPs can largely control whether their mobile and residential users have IPv6 available they can’t really do so for their business users, let alone arbitrary website operators they have no relationship with. So the reality is that everyone is going to have to maintain both 4to6 and 6to4 basically forever. But as it becomes less common it’ll no longer need to be especially fast or efficient and the costs to operate it will come down.
There is little value to run dual stack.
Find me a business that would like to spend a lot of money on something of little value.
We as consumers see and use the highest level, which is often https or friends, and due to the layered nature of the OSI stack, as often happens in software, if a layer is lacking in something, it gets fixed 1 or 2 layers up. If then said thing is then implemented on the layer its supposed to, its often unwelcome and just causes issues.
TCP/IP has already acknowledged this (haha) by offering UDP, on top of which you can build the network protocol of your dreams.
And people have. It's called QUIC or HTTP3. It does everything one could ask of a network protocol, with QoS, NAT punchthrough, packet based low latency/overhead comms, etc. etc.
And QUIC doesn't assume any sort of advanced mechanisms beneath, it works happily with IPv4.
And once you have everything figured out for you on the level you like to work, there's not really a need for the lower layers to pick up the slack, as long as they work reliably.
Both my clean Debian and the rescue system couldn’t reach internet through IPv6 despite getting an address through DHCP.
I immediately permanently disabled IPV6. I usually do that pretty late in my installation scripts anyway.
I understand the perfect solution didn’t exist and still doesn’t exist, but it’s frustrating. I wish IPv6 could work reliably, not only on major CDNs, and that is appreciated. Then IPv4 would be a vanishing memory.
They said the same in Y2K, and turned out that people were able to extend their date fields and the systems ran just fine.
When you want your packets to work on other people's routers, it stops being fine.
Or it means a ton of people can't connect to you because of your netcode preferences, and that makes your boss very upset. It'll get fixed extremely fast, and fixed means turning IPv4 back on.
Increasingly, the vast majority of services are accessed via the service cone of various CDNs and IAAS providers directly at edge servers local to them, and at some point it may be that the industry decides that it's not worth providing ordinary internet users the ability to talk to each other directly at all. At which point, we might just as well have stuck with IPv4. I don't particularly like that outcome, but it's possible.
> First of all, IPv6 really is a conservative design - it doesn't change the basic IP model of connectionless packet switching with topological addresses.
All of talk about the technical merits or demerits misses the point. I can spout of a dozen or more memorized IPv4 addresses. IPv6? Good luck.
Plus, manual address assignment is just as viable in an IPv6 world as it is in IPv4.
[0] fd00::/64 is quite easy to remember, as are fd00::1 and similar.
A computer standard that is still widely avoided almost 30 years after it became official is a computer standard that should have been tossed in the bin before the ink was dry.
The SLAAC vs DHCPv6 mess is not really a problem with the core V6 spec.
Maybe they’re comparing the minimal implementation on a home network. But even then I’m not sure the claim holds up.
People learned IPv4 when they were younger in a more incremental manner and take it for granted now.
I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity, and you can’t easily predict what address will be used when connecting somewhere. IP-based access control becomes impossible (not that it was ever a great idea in the first place), reverse DNS lookups become irrelevant, seeing IP’s in logs no longer tells you “what machine connected here”, it’s overall a big change in mental model.
But then you get over it, stop making assumptions that you can rely on IP addresses for knowing things about a host, and the rest of it is fine.
a little over half the bytes of a typical IPv6 visitor's address is comparable in identification to what all four bytes of an IPv4 address tells you
In the classic sysadmin world, the idea that an IP you see could belong to any host and you have practically zero way of knowing, is rather different from what we expect in the IPv4 world. You just have to embrace it, basically.
Can't you unset the "Use autonomous addressing" bit and set the "Use DHCPv6 for addressing and other config" bit in your RAs, and then refuse to hand out anything other than DHCPv6 Normal Addresses? Or do OS's ignore the fact that Temporary Addresses are an entire other category of DHCPv6 addresses and just go off and make their own "privacy addresses" off of the advertised prefix in the RA... ignoring the router's command to not use SLAAC for addressing? [0]
[0] Yes, I'm very aware that Android doesn't support anything that DHCPv6 provides other than getting an entire damn prefix delegated. For the duration of this discussion, let's ignore Android.
But it's rather not really my point... best practices for IPv6 are to not do any of this, and you probably don't want to do it, because privacy addresses are an actually-important thing for privacy (so that sites can't correlate you easily.) You can say "oh but websites use fingerprinting anyway" (which doesn't help you when it's not a web browser you're using, but any other software that's connecting places) or "but sites don't trust the trailing 64 bits" (which only helps because everyone else is using privacy addresses, which rather proves my point.) When doing IPv6, you sort of have to abandon the idea that you're going to have a fixed, known IP address that you will use for all outbound connections. Fighting this is an exercise in pain.
When I unset the Autonomous flag, Linux does the right thing, at least on the systems I have at hand. Android does the right thing. My Playstation 5 does the right thing. I'd be shocked if Windows doesn't do the right thing. While I wouldn't be surprised to hear that Apple devices absolutely do the wrong thing -given Apple's long history with flagrantly doing the disruptively-wrong thing in regards to networking-, based on the results I'm seeing, I expect that Apple devices work just fine. I think you came to the wrong conclusions because you fucked up your test.
> ...privacy addresses are an actually-important thing for privacy (so that sites can't correlate you easily.)
As you allude to, The Web has eleventy billion ways to track you that give absolutely zero shits about your IP address. "Privacy" addresses buy the typical user of The Internet effectively zero privacy. January's deprecation of DHCPv6 "Temporary Addresses" suggests that folks who deploy this stuff believe that this feature is far less useful than proponents might think it to be. Plus, absolutely nothing prevents a DHCPv6 server from randomly generating the host part of the addresses it hands out, as well as handing out entirely new addresses for each address request. If I believed that "privacy" addresses actually provided any meaningful privacy, that's how I'd configure mine to behave for hosts that I wasn't intentionally providing fixed addresses.
but operational inertia got in the way. I don't think people really wanted to think about what a dhcp-less world would look like, even if it removed the requirement to manage a central service and the associated configuration.
this was kind of ok. but then things got ugly. people wanted to be able to get assigned prefixes dynamically from their upstream provider that they could subnet themselves. because we don't think about these issues architecturally anymore, someone put that function on dhcp. and since we don't think about these issues architecturally anymore no one really realized that that would require _another_ protocol on the inside of that boundary to manage assignments in the providers space.
and now we don't even have the option of depreciating dhcp gracefully.
This is the author’s assumption and not a conclusion. Why did the other designers even bother if this was the case?
For this reason, at every shop I've ever worked at, the intranet is ipv4, often with ipv6 disabled, with dual stack on the load balancer for ingress traffic. Note, I do not set it up that way: it comes like that when I've arrived.
NAT for IPv4 is a workaround for the scarcity of publicly routed addresses, nothing more. It bought us decades.
NAT for IPv6 does exist, but it's more often done with network prefix translation. If you want "security", you set up a firewall.
And if you need NAT or DHCP, there isn't any reason you can't use them with ipv6. DHCP6 had been around for a long time.
NAT was already in use, and a substantial motivation for the IPv6 work was to provide an alternative before it got too entrenched, which sadly failed.
I'm not sure what you mean by "fix" DHCP and NAT, but FYI: RFC 3315 was published in 2003.
As far as NAT goes, it looks like iptables added IPv6 support to the MASQUERADE, SNAT, and DNAT targets in kernel version 3.7, released in 2012. IDK when other OSs added such support.
SLAAC was part of IPv6 since the original RFC, its a horribly over engineered stateless replacement of DHCP. Nobody asked for that.
I mean thats not true. SLAAC is great for public/untrusted networks where you just let the clients figure that shit out.
the only thing thats a bummer is not being able to map DNS records to addresses, which is kinda the point, for privacy.
I wasn't around for the discussions at the time, but I would have asked for it if I was. SLAAC is IPv4LL, except that you usually get a globally-routable IP address from it. It's great. It's also quite a bit simpler than DHCP... "If the advertised prefix permits autonomous addressing, generate a host part in the non-fixed part of the prefix, run DAD on the generated address to ensure it's not in use, and start using it if it's not.".
> SLAAC was part of IPv6 since the original RFC...
An attentive reader notices that RFC 1883 and RFC 1971 are separated by nearly a year.
I _assume_ you are referring to a default deny inbound firewall (so that devices are not reachable from the outside), but these are very different, completely orthogonal concerns (and independent of the IP version in use).
Yeah, I've seen those contracts. They just reference a SeCuRiTy doc that's 20+ years old, and has never been re-evaluated. Things are secure because they follow the doc, not because they have actually evaluated the reasonable attack space.
I've fighting customers for years on their ideas of proper TLS usage and it's always the same thing. They've got a security doc that never changes and has never evaluated any of the trade-offs. Almost to the point that the people who wrote them choose things that increase downtime and KTLO work without helping security.
NIST Special Publication 800-63B, the July 2025 version, section 3.1.1.2, says:
"Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised."
The previous version from June 2017, section 5.1.1.2, says:
"Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator."
So 9 years ago, NIST said to stop requiring that. Last year, they clarified that to say, no, really, freaking stop it. Any company still making people do that today is 9 years out of date, and 1 year out of compliance.
only if you're using EUI-64, but I don't think many things use that anymore. I think the only thing is cisco shit. but even then I suspect that they have RFC7217 on by default at least.
I mean thats what reverse proxies are for, if you're that worried.
NAT doesn't give you anything useful, apart from the veneer of security. Sure it feels like your safe because there isnt a direct routable link between host A and the outside world, but thats not actually true.
If you want that, then you need firewalls and reverse proxies, even in IPv4.
2. NAT is totally orthogonal to IP and addressing.
3. NAT (as in transparent packet modification to rewrite addresses) is utterly idiotic. Ephemeral, anonymous address allocation with inbound filtering is smart, but transparently rewriting packets to do that is one of the dumbest possible ways prone to horrible compatibility and ossification issues as has been proven empirically.
[1] https://www.ietf.org/archive/id/draft-mrw-nat66-00.html
NAT is a terrible network protocol. The correct protocol would have been a DHCP extension giving you a 49-bit address where your IPv4 address constitutes a /32 with a 17-bit unique local address.
This contention point confuses me. I consistently get downvoted for this opinion, and I've seen contrarian voices online, but I have yet to meet an actual datacenter network admin who disagrees with me.
virtually all the datacentre is exclusively IPv6. they kinda have NAT in the sense that all the web proxies at the edge terminate the IP connections with the outside world, but thats higher up the stack rather than on the IP level.
However I never dealt with the edge stuff, as that was far away from what I was doing.
As for security.........are we really that secure running code in our browsers that we downloaded from who knows where? Is nat really saving us?
And now here we are with IPv6 and the real age of the network could begin.
Expensive switch at work we have can only do 3000 route entries for example on ipv6. If we did /128s it's basically infinite though, because it goes from a LPM to exact match, which has much much more memory available.
Doesn't help as well that for example, to be able to do SLAAC or even DHCPv6 (which barely works reliably in my experience) you need to do a /64 at minimum, those mechanisms dont even work otherwise, so for ISPs who can easily have more than 3000 downstream customers doing routed ipv6 is such an increase in hardware cost vs just doing NAT which they were already doing anyway.
We have large networks that are essentially rolling on autopilot totally unmanaged, like Lumen'e recently sold Quantum Fiber asset that is now owned by AT&T holding company Forged Fiber 37 LLC
No native IPv6 still on this forgotten about network, 6RD keeps having weird routability issues, but if you just disable IPv6 everything works fine.
Essentially the hardware doesn't support scaling a /64 or /56 to each customer, leaving OP in a terrible position when it comes to proper IPv6 deployment.
When you look at Ziply Fiber, they seem to be ripping out these types of Enterprise grade routers left and right in favor of a simple Linux box doing routing. I think a large portion of why they're doing this is due to limitations like what OP is experiencing
You don’t need more than the /64 to know where to send traffic, all of the bits required are still just in the prefix. One route per customer… the edge deals with addressing issues.