|
Oh, sure, but my point isn't about implementation complexity, it's about network architecture. SLAAC doesn't work the way DHCP works. Do you have an IPAM tool that assigns addresses? Do you have a VMM/private cloud where addresses are in a database and you set up firewall rules? Do you have a guest wifi network where you assign a quarantine IP with a short lease and then a real IP once they authenticate? None of that works with SLAAC. Especially if you have an existing IPv4 network and are rolling out dual-stack and have no interest in breaking IPv4, adding IPv6 via SLAAC is hardly a matter of adding another column in your schema. It's an architectural change. Again, maybe that change is good, but that's the chore - not implementing the protocol (which is basically ip link | sed | ip addr add). For privacy addresses, if you were considering implementing IPv6 before they were widespread, you'd have to figure out a way to keep from leaking them. The obvious approach is NAT, but that's effectively not an option. So you decide not to make IPv6 available to clients, only servers that already have fixed IPv4 addresses and don't roam. Or you do manual (non-SLAAC, non-DHCPv6 because that wasn't an option) configuration. Once they became available and common in people's clients, sure, but that means we didn't have "20 years" for people to offer IPv6 on guest wifi networks, we had a lot less. Same with NATs. Implementing "not using a NAT" is absolutely trivial; you just... don't. Redesigning your network architecture not to use one, however meritorious it may be, is a massive task. |
If addresses are in a database and you set up firewall rules, you set up your clients to consistently use the same local suffix. This is approximately the same amount of work as setting up a fixed DHCP lease for a host, or setting up a static IPv4 address. Once this is done, firewall configuration is exactly the same as v4, just with a different address format.
Using a quarantine IP for new clients is a really weird way of doing things that I never saw in 5 years of working on mostly-v4 SMB enterprise environments. Clients don't support it well and never have, and revoking the lease on demand is a pain. Everyone already uses plain old firewall rules plus DNS hijacking to force people onto splash pages. If you do something that deeply weird, you're going to run into problems every time Apple slightly changes (shudder) iOS DHCP expiration logic, let alone during transition to IPv6.
You can still NAT if you want to on IPv6; you just don't have to. (In fact, NAT between an internal v6 and an external v4 network is a very widely deployed transition technology!)