NAT is such a trashy abstraction. IPv4 needs to die.
The other week I moved my ISP. The AS my house belonged to obviously changed to the new ISP, and I got a new v4 IP
All I had to do was update my Wan router to forward trafffic from the new Ip.
Instead with ipv6 I would have to change every node on my network, update my internal DNS.
Now in theory I could have my own /48 which I take with me. That relies on my new ISP being willing to advertise it (which my current one does) but it’s not particularly common.
However a week ago my phone line was cut. I got a 5g mifi out and moved my wan connectivity through that until the cable was fixed. Again a nice simple masquerade on that interface and all was good (well not that good - very poor signal where I live)
But the elephant in the room is of course all that ipv6 stuff aside, I still need to run a dual stack (or use trashy nat abstractions). It increases my work for no benefit.
But taking about work, how about there?
I have a fleet of vehicles on internal 172.16/12 subnets, they plug together and route to each other, and route from where they are via a variety of vpn connectivity (hoping that at least one method will work, as there’s rarely a signal in the basements these park)
If I moved them to ipv6 then again I’m back to having to move my /48s. Except these vehicles get internet from various sporting venues - most of which struggle to turn off MITM/443 or unblock UDP, that’s just not going to work in a world where they turn up at 10am Saturday morning and need to be working 2 hours later.
What business benefit is there for me to double the workload and double the risk by moving to dual stack?
There would be no DNS configuration at all, all local machines would use anycast DNS for the services and a well known server for Internet addresses.
One of the primary goals of IPv6 was to avoid needing manual configuration if anything on the network. It is supposed to be as automated as possible.
Assumptions and dragons be here.
Ok, lets say I have a web server - www.example.com running on 192.168.0.100:80/2001:db8::::::100 port 80 - and a game server - game.example.com running on 192.168.0.99:27015/2001:db8::::::99 port 27015. The IPv4 DNS A records point to a CNAME record of server.example.com, which has an A record for an IPv4 addrss which then forwards via NAT to the above. The IPv6 AAAA records point directly to the above addresses and go via a transparent firewall (which likely does router advertisement).
How do I handle an address change when I change ISPs here?
For IPv4 it's very simple - I update the CNAME record and there's no further configuration required - my NAT works and traffic flows. Assumedly I could automate this simply with a DDNS client my router likely already has built in.
For IPv6, I presume I need to look up all the machines (likely via logging into them as DHCPv6 doesn't appear the norm), then go through an update all records? I understand a static suffix may help on inferring the new address, but surely I either have lots of manual updating to do now or need to run a DDNS client per machine?
I have tried running a dual stack, but every time I try it seems to be significantly more steps and complexity than IPv4, but maybe I'm missing something.
Alternatively, if your devices have a stable suffix, https://dynv6.com/ supports prefix updates across multiple records.
Sure, but depending on what you have set up a lot of maintenance and complexity compared to NAT.
> Alternatively, if your devices have a stable suffix, https://dynv6.com/ supports prefix updates across multiple records.
That is cool and interesting, thanks! Like a lot of people self hosting, the hosted nature of it is unappealing to be, but the concept is workable with a self-hosted solution for sure.
In the future you can probably go "IPv6-mostly" with a CLAT engine to ditch dual-stack: https://blog.apnic.net/2022/11/21/deploying-ipv6-mostly-acce...
If you don't need cross subnet communication of your self hosted services you can also get away with just a static link-local and a dynamic general.
...although there still isn't any kernel support for the necessary SIIT v4<->v6 translation, so to implement CLAT you end up using unmaintained (and unmergeably bad) out-of-tree kernel modules or unmaintained (and slow) userspace daemons hanging off a tuntap interface.
With the (IMHO) big advantage that unless some madman has configured NAT66, the traffic over ULA will *never* get out into the internet.
The fact you have GUAs allocated doesn't mean you have to necessarily use them for your internal traffic. Most of the time link local addresses (on small scale, with auto discovery via LLMNR or mDNS) or ULAs are way more convenient than GUAs or IPv4 local addresses.
Now, try starting a new ISP without CGNAT (which will lead to a garbage experience for everyone) or IPv6. You'll have to spend literal tens (if not hundreds) of millions just on IP addresses alone.
Now there is.
Except it is not. Where it works, it works extremely well. IPv6 connections are, by default, always preferred on all modern operating systems.
I’d also take the entire article with a grain of salt, because it calls a fundamental impossibility (lack if interoperability of v6 and v4 addresses) as a “mistake”. Not having interoperability was the only way, not a “mistake”.
Virtually all the pain points have been dealt with. Any further transition to IPv6 is going to happen without anyone really noticing. Except for the couple of gamers and sysadmins who were wrongly advised to "disable IPv6" to fix "connectivity problems".
We have to deal with the world we live in, not the world we’d like.
https://datatracker.ietf.org/doc/draft-mishra-6man-variable-...
> We have to deal with the world we live in, not the world we’d like.
No we don't. Some choose to just put up with shittiness, others enact change.
As for me, I want IPv4 to stay forever. It works for me and I don't see any reason to spend time and migrate to something else.
Your "ISP" is a sysadmin at work who gives you one address to your cube.
You otherwise like the work and the team, and the compensation is fine.
Now what?
You advocate for change. You make the case.
You might not win the battle, but you're by no means forced to accept the status quo. The more who fight the battle, the more win. The more win, the faster progress, which benefits us all.
If you can solve a problem technically, without involving people, that is best.
IPv6 with assigning end users a whole /64 and end-devices continually churning through privacy addresses is a start. But even then some form of NAT is still required to nimbly use source prefixes from different horizon providers - eg to avoid spilling your geographic location or opening yourself up to low-effort legal shakedowns.
An example: on my local network I've got an everyday web browsing VM and a torrent VM. They each have static 192.168.x.x addresses, both so I can ssh in for administration and also to control their view of network services. They each see a completely different Internet horizon through the router - the web browsing goes out from a rotating datacenter IP, and the torrent one goes out from a consumer VPN. Each of those outgoing horizons uses NAT - any of my hosts using that rotating data center IP appears the same, and any of my host using the consumer VPN appears the same as every other customer using that same VPN node.
What is the no-NAT equivalent of this? Make that rotating data center IP and VPN external IP into subnet allocations, somehow feed that addressing information back to the hosts that are using it, and dual-home each VM with two routable addresses? For equivalent mixing on the consumer VPN there would also need to be some ARP-like protocol that let me continually rotate the address.
At least for web-browsing and other HTTP/TCP use-cases: Cut off internet from your hosts and use centralized local proxies for all outgoing connections. Presumably you already have reverse proxies in place for the incoming. There is no need for NAT if all the traffic is taken care of in higher layers. This reduces your consideration to the internet-facing forward- and reverse-proxies only.
Sounds like you already have bittorrent figured out via VPN (Wireguard I guess? Well there we have one more UDP exit-point to consider).
BTW, I largely agree with your sentiment: Benefit of (especially migrating to) IPv6/DS for individual networks is often unclear or questionable and metadata privacy is a valid consideration where I believe correct solutions are not readily available and understood even by your well-intentioned and seasoned senior admins. Maybe globally the number of people who will get this right ranges in the 1000s? 10,000s if we're lucky? How many networks do we need to migrate again for "IPv4 to die"?
I guess the only way forward is for more people to do that migration and share their findings and solutions, though ;)
It certainly seems possible to get a NAT-equivalent privacy from properly set up SLAAC. Although a sibling comment says that the proposal for variable length prefixes was just submitted this year?!? Equivalent privacy would also require things like consumer VPN providers allowing you to request a few new addresses every few minutes, whereas NAT makes a shared uniform distribution the default.
Using a proxy instead of NAT is a good point, although there are certainly reasons I moved towards managing egress flows at the packet level with VMs rather than configuring software to play nice with proxies. And spiritually I would say that a proxy is an even more heavyweight version of NAT one layer up.
[0] Although I don't personally think the web would have developed any less centralized without NAT as many people like to imagine