Comment by throw0101c
1 day ago
> 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?