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…
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.
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?
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.
- 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.