You say ipv6 was supposed to get rid of NAT. Can you explain why it doesn't? You then say the problem was built into ipv6 from the start.
From looking it up it looks like it's mostly required when IP's change (e.g. when you change ISP), which for me is more of an argument to use DNS if you want fixed addresses.
One reason could be the proliferation of prefix delegation, meaning an ISP now controls the numbering of your internal network, and it keeps constantly changing the net block, so you can never get stable local addressing… so you just keep running dual stack or try to use nat66 with a ULA network as a kludge or something.
You can have multiple IPv6 addresses on your interface, so you can have both the ULA address for internal use as well as the global address - no need for NAT
However, the priority order on your OS for address selection, even when it comes to stuff like choosing which DNS results to use is IPv6 global address > IPv4 > ULAs. So on a dual stack network, ULAs with not be used unless the only address is a ULA.
And even if you run your internal services with only an AAAA record pointing to the ULA, the client's source address will likely be the global address of the client device unless you tweak the tables on each client, which then means you'll need to have your global address in all your firewall rules to access the internal services on ULAs, which then means you're not saved from having your ISP-provided global address in your configuration, which is what you were trying to avoid by using ULAs.
The problems this caused/s seems to have been an unintended / unforeseen consequence that was more exposed as people gained experience. There's a draft being worked on to officially change the priority:
> The behavior of ULA addressing as defined by [RFC6724] is preferred below legacy IPv4 addressing, thus rendering ULA IPv6 deployment functionally unusable in IPv4 / IPv6 dual-stacked environments. The lack of a consistent and supportable way to manipulate this behavior, across all platforms and at scale is counter to the operational behavior of GUA IPv6 addressing on nearly all modern operating systems that leverage a preference model based on [RFC6724].
Leaving aside that the draft is badly worded (there are long descriptions of the problem, but no short paragraph saying what must be changed), the long time until this is deployed if ever, the new order will still leave ULA below IPv6 global addresses - which means it doesn't solve stock_toaster's problem at all.
The only in theory clean alternative to the kludges you mentioned is to let DHCPv6 renumber your network automatically which is a major change in how you have to think about your network.
The existence of NAT66 and NPTv6 are proof that there is still a need for NAT in an ipv6 environment. Maybe not in your environment, but people wouldn't make these solutions if there wasn't a need.
Would you rather have a bunch of routers sending out advertisements which every client needs to sort out, or have one consistent multi wan load balancing/failover policy that is transparent to clients?
IPv6 purists think that you can simple have multiple IP addresses on each client, all configured magically, and reconfigured transparently when your ISP changes, with every device somehow knowing via some form of policy deployment (perhaps via dhcpv6) which network to use for a given flow.
That's so much simpler than simple src-natting your clients at the edge of your control and routing your outgoing traffic based on a policy at your natting device /s
There's certainly a requirement for them, but it would be good to know what the justification of that requirement was before we know if there's a need. E.g. the justification could be "our SOPs say all network traffic must go through NAT", and if you dig deeper you might find that the SOP was written to save money on IPv4 addresses. That would not indicate a fundamental need.
NAT works well as an ultra simple firewall. All those ancient IoT devices don’t need to accept traffic from arbitrary addresses, but they may need to communicate with the outside world.
Using a firewall is obviously an option, but why give an IP to something you don’t want accessible by the outside world?
There's something that works even better as an ultra simple firewall: An ultra simple firewall!
> why give an IP to something you don’t want accessible by the outside world?
- You might change your mind about it needing to be accessible by the outside world, and if it already has a global address you don't need to renumber everything.
- Addressing and routing aren't the same thing; it can be useful to have globally unique addressing even without global reachability.
Ultra simple firewalls that expose your internal network architecture are less secure than NAT. You simply cannot information about your internal network without risk and there’s zero direct benefit for doing so.
I don't think this is a useful thing to say. If I keep trying to fill up my electric car with petrol, and get so annoyed that it keeps spilling on the floor that I pay someone to install a petrol cap and fuel tank, it would be equally silly to say that electric cars failed in their mission to get rid of petrol use.
From looking it up it looks like it's mostly required when IP's change (e.g. when you change ISP), which for me is more of an argument to use DNS if you want fixed addresses.