Comment by VCFundedGenYer
1 day ago
IPv4 is perfectly and objectively fine on internal networks. IPv6 is overkill and way too complicated for most.
IPv6 can be selectively applied to say, NAT addresses, but other than that, IPv4 is just fine and your statement is incorrect.
> IPv4 is perfectly and objectively fine on internal networks. IPv6 is overkill and way too complicated for most.
Unless there's a merger/acquisition and the two companies both use 10.0.0.0.
Most home networks use 192.168, and so you can't use that in corporate environments, because the WFH people who VPN in could then have routing snags between local and remote locations.
Also, in your VPN software be sure to perhaps not use 172 addresses (like my previous job did), as some of those ranges are used by Docker by default, and so you can cause issues for developers.
But other than that IPv4 RFC 1918 is not complicated at all…
IPv6 discussions keep having this scenario - which is barely relevant to how nearly all IPv4 LANs operate.
It's assuming a huge zero-trust point-to-point network where it's a rare scenario for IPv4 LANs. IPv4 LANs tend to assume the internal network is semi-trusted and route through hubs, so merging networks is a bad idea even when the mapping does not conflict (which often doesn't if the companies are tiny like most are). Even in a zero-trust point-to-point environment you'd want to review the other side, convert it to your software, etc. And the people on the being acquired side have little reason to care too.
It's a scenario that's only relevant for a huge company constantly acquiring other companies that operates via zero-trust point-to-point networking and strongly tries to minimize human review - basically Google/Alphabet.
In theory IPv6 solves the problem by putting all of this under a single prefix (fc00::/8) and asking nicely that implementation/admins add 40 random bits to form their prefix. Which is plenty to prevent (almost all) eventual conflicts.
The thing is, asking nicely doesn't always work. Sure, automated tools like docker/incus/wireguard/tailscale will respect it. But admins who don't want to be stuck typing long addresses? Not so much. I've lost count of how often I encounter a network admin that manually set their prefix to some fcXX::, when it's not outright fc00::.
Of course you can (and should) blame this on admins and not on IPv6, but then the same could be said of IPv4 where adding entropy to 10.X.X.0 is the usual recommended way of doing things.
> In theory IPv6 solves the problem by putting all of this under a single prefix (fc00::/8) and asking nicely that implementation/admins add 40 random bits to form their prefix. Which is plenty to prevent (almost all) eventual conflicts.
IPv6 solves this by making it easy for everyone to get their own 200::/3 address so that when two companies get together they have completely different /48s (or whatever).
> […] but then the same could be said of IPv4 where adding entropy to 10.X.X.0 is the usual recommended way of doing things.
There has never been a recommendation to add entropy to 10/8 addresses. At least I have never heard of such a thing. Can you provide a citation for this (alleged) recommendation? Is there an RFC of some kind?
You can't selectively use IPv6 in the WAN and IPv4 in the LAN.
How would an IPv4 client send a packet to an IPv6 server? The IPv4 packet has only 4 bytes to spare for the destination address.
You can't.
Anything longer, even if it's just 1 bit, would require a new IP version.
You can run a 4to6 NAT, where specific v6 addresses (the ones you’re talking to) are aliased to reserved v4 addresses out of the PUA.
I have seen people suggesting this before, but it's problematic for a few reasons:
- If you are managing the 4to6 mappings manually, it's obviously not going to be scalable. Just to give people an idea, websites nowadays can connect to 10+ IPs in a single page due to CDN load balancing and stuff.
- If you are handling the mappings automatically, such as by monitoring DNS queries and creating dynamic mappings based on that, the issues become more insidious: applications with hardcoded IP literals would fail without an obvious reason.
The "solution" is that IPv6-only servers do not exist and will never exist.
I have encountered multiple IPv6-only domains - certain random domains were accessible through Chrome, but unreachable from any command line tools. Turns out they were IPv6-only, and Chrome was doing its own DNS resolution, while anything that was using the platform DNS stack was hitting a black hole between OPNsense and my ONT.
Alternatively, IPv4 simply does not scale effectively on the LAN, whereas IPv6 allows much simpler addressing and routing topologies. Simple = good.