Francis, On 2010-02-04 20:59, Francis Dupont wrote:
I'd like to kill this private address collision issue: at the exception of some rare protocols designed to handle this case, the schema: private-address - NAT - Internet - NAT - private-address simply doesn't allow free communication between both end-points. So it doesn't matter the private addresses collide...
The specific issue raised was for VPNs, so it's more like this: [ USER HERE ] private-address (VPN) - 10.0.0.1 private-address (conference network) - net 10.0.0.0/24 NAT (public-address) - 1.1.1.1 Internet - net 0.0.0.0/0 public-address - 1.2.3.4 private-address (VPN) - net 10.0.0.0/24 [ SUPER-SECRET CORPORATE NETWORK HERE ] Nobody terminates a VPN using a non-routable address, so that's not the issue. I think the issue is the collision of the RFC 1918 address space between the VPN and the local network for the user. As you see above, if the conference network and the VPN both use 10.0.0.0/24, communication gets... tricky. Well written VPN software can probably work around this in many cases, perhaps all, but I have no doubt there is a lot of poorly-written VPN software. :) Non-software solutions are using an IPv6 VPN (of course) or using public addresses for your VPN. Perhaps publicly-routable IPv4 addresses are easy for people on this list to get, but I am sure that is difficult for a lot of businesses. I wouldn't know how to do this if I had a small company of my own! -- Shane p.s. Note that 1.1.1.1 and 1.2.3.4 chosen as example addresses in honor of this research: http://labs.ripe.net/content/pollution-18