This is an interesting take, however from what I seen its other way around. Most security conscious operators would only allow IPv4 instead of IPv6. Your ACL rules and tools are still better at handling/managing IPv4 compared to IPv6
> Most security conscious operators would only allow IPv4 instead of IPv6.
I strongly disagree. That's obsolete knowledge, thrown around by people who want to be considered security conscious but haven't actually updated their knowledge in many years. A statement with similar implications might be "security conscious operators require their users to rotate their passwords monthly", which is what a lot of people use to think a decade ago, and now what it really communicates is that you're talking to a dinosaur.
No, it's not. If you really want a NAT there is no reason you can't use a NAT with ipv6. In fact, it can work even better because instead of using a random port for the translation, you can use a random ip address for each connection.
Why would it be reachable? It might be name-able but that doesn't imply reachable.
You're conflating the two parts of NAT: address translation and inbound filtering. A router can block any inbound traffic coming from WAN, even if the IPv6s on the LAN side are public.
In fact, hole punching for IPv4 shows this distinction. By default inbound traffic is blocked, but as soon as private host has opened up a connection, it is (indirectly) reachable and nameable (via the routers public IP + port).
BTW, static IPv4 NAT with public addresses on both sides exists as well.
Addressable means routable. Otherwise the distinction between a Public and Private address becomes one of firewall rules rather than a meaningful property of the IP Address.
And as you say, hole punching is still “PUBLIC IP” + port. Not an IP and any port you fancy unless the firewall was configured correctly.
Maybe I am wrong, maybe you’re confused, maybe IPv6 is just rubbish. Maybe all 3.
You were asking about reachable, not routable. Of course, an address behind a firewall might be adressable and theoretically routable, but it certainly isn't reachable.
The default config of a SoHo router has both: (a) NAT44 separating public vs. private IPv4, (b) and also a firewall that blocks any unknown ingress traffic on IPv4 and IPv6.
From a security standpoint, it doesn't matter if the IP get translated inbetween. Only the ingress firewall counts: If the firewall is in-place both IPv4 and IPv6 traffic will be blocked. If you open up the firewall (via hole punching or port forwarding on IPv4, or via IP allows for IPv6), I can send packets to your public IPv4 + port and they will arrive at you private server, or I send them to your servers GUA IPv6 and it arrives. There is no security difference.
The fact that the private IPv4 block is not globally reachable counts for something. If I accidentally give you my private IP (192.168.17.102, by the way!) you can't do anything, absent other details, no matter how much misconfiguration occurs. If I give you my IPv6 GUA, there's a lot more variability.
I “inherently” reachable. You can play semantics but the point stands.
> From a security standpoint, it doesn't matter if the IP get translated inbetween. Only the ingress firewall counts
This is complete nonsense. Security is about layers and risk mitigation. You know what is better than firewall rules that can be misconfigured or overridden due to conflict or interface name changes and so on? An IP that can be addressed from global space. Wild!
What do you mean globally accessible? All the devices on my network have global IPv6 addresses for the last 5 years - since my ISP enabled IPv6 but none of them are accessible unless I configure it.
Do you ever wonder if most people don’t “see the facts” and after almost 3 decades and so much the adoption at 50% might mean to consider if the technology is just rubbish?
I do! But then I ask those people to explain how to go about doing v6 in a way that isn't rubbish, and the only answers I get to that are a) impossible, b) no answer/refuse to answer, or c) they start reinventing v6 but with weird names for everything. Or some combination of the above ("just add two octets and have a flag day" is a common one, combining (c) with (a)).
I've more or less come to the conclusion that the people who think v6 is bad don't know what they're talking about. If none of these people can come up with a better approach than v6, that suggests that v6 really is more or less the best approach available.
> after almost 3 decades and so much the adoption at 50%
I think we all wish it had been faster, but the v4->v6 transition is the first time humanity has ever done a transition like this, on this scale, involving so many disparate networks controlled by so many people in so many countries. How do you know that 50% at 3 decades is slow? Maybe this is just the par time for this kind of thing.
They key things is that pretending interoperability with IPv4 can be an after thought or dual stack is a good idea was just stupid and proven to be so. Flag day or IPv4 fading into oblivion never going to happen.
I know 50% is slow because that is LESS than new deployments over the past 3 days, so if someone thing “better” can be deployed to new projects until all old projects migrate is broken.
I've seen that draft. It's not backwards compatible in any ways that v6 isn't.
The people designing v6 knew from the start that interoperability with v4 was a requirement. It's written right into the list of requirements for v6[1], right in the same place that they say that a flag day is never going to happen.
Why do you believe otherwise? The RFC is right there for anybody, including you, to read.
You don’t understand it then. In V8 every IPv4 address is a valid address, that means you can have IPv4 and IPv8 on same IPv8-lan and first class support for translation into the protocol instead of an array of hacks is a miles better solution than the pile of rubbish that v6 is. In fact, IPv6 isn’t even a new version of IPv4, it is a different protocol entirely and a rubbish one.
Most IPv4 "security" is a side-effect of NAT. NAT was not intended as a security feature, but it does provide a level of security in the common consumer implementation (PAT, single external IP, unroutable internal network.)
There's more that's been written about configuring/protecting IPv4 networks and if you learn about network security from a mentor or from coworkers at a job, rather than reading books/the internet/LLMs, you're more likely to learn about IPv4 security.
But if you've ever had to deal with endpoint security, if you're just doing static rule based blocking/throttling, /32 or /24 blocking is often your best option. Thanks to CGNAT this often means having a pretty large impact since an ISP's residential customer might end up getting randomly assigned a "bad" address and the cooldown for these rules is often months long or more.
In IPv6 land, you can just block a /128 or even a /64 and rarely hit anyone else in the crossfire.
Blocking /128 is unlikely to block anyone for very long around here. Both the major ISPs give out /56 blocks with prefix delegation. In almost 4 years, mine hasn't changed.
