Re: RFC 1918 in "production networks"
If we use 192.168.1.0/24 for the RIPE meeting, and your corporate network at home uses 192.168.1.0/24 as well, most VPN clients will NOT be able to build a working connection. Try it. Given the number of attendees, the chances for address collisions with at least one participant's home network can be assumed to be near 100%.
One workaround would be to have two (vastly different) 1918 prefixes and giving people the possibility to switch (so, 2 SSID's, 2 prefixes, say 192.168.224.0/20 and 10.210.32.0/20). Chances that someone will conflict with both, are small. For better or worse, we will need to learn how to deal with this - denying these issues doesn't fix the fact that these situations will happen, without the escape of availability of public IPv4 addresses, in the near future. And, of course, if nobody puts pressure on the VPN-sellers, these issues will stick around for *years*. Geert Jan
Hi, On Wed, Feb 03, 2010 at 12:53:43PM +0100, Geert Jan de Groot wrote:
If we use 192.168.1.0/24 for the RIPE meeting, and your corporate network at home uses 192.168.1.0/24 as well, most VPN clients will NOT be able to build a working connection. Try it. Given the number of attendees, the chances for address collisions with at least one participant's home network can be assumed to be near 100%.
One workaround would be to have two (vastly different) 1918 prefixes and giving people the possibility to switch (so, 2 SSID's, 2 prefixes, say 192.168.224.0/20 and 10.210.32.0/20). Chances that someone will conflict with both, are small.
For better or worse, we will need to learn how to deal with this -
We're dealing with this every day, outside of RIPE meetings. The RIPE meeting network is not a playground or experimental environment, but is there for the primary purpose that people who attend RIPE meetings can be able to contact their home networks in case something urgently need to be done there. With as little extra pain as possible. Having test networks in addition (!) to that is good. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
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... Regards Francis.Dupont@fdupont.fr PS: note the key point is a private address is not routable in the Internet, i.e., you can change "private address" by "not routed" and all considerations still apply.
Am 04.02.2010 um 20:59 schrieb Francis Dupont:
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...
Regards
Francis.Dupont@fdupont.fr
PS: note the key point is a private address is not routable in the Internet, i.e., you can change "private address" by "not routed" and all considerations still apply.
+1 thanks Francis regards Marc -- Les enfants teribbles - research / deployment Marc Manthey- Vogelsangerstrasse 97 50823 Köln - Germany Tel.:0049-221-29891489 Mobil:0049-1577-3329231 project : http://opencu.org blog: http://macbroadcast.org Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months.
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
On 05.02.10 3:02, Shane Kerr wrote:
-- 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
Sorry - but all this discussion reminded me about current situation too (http://labs.ripe.net/content/pollution-18 ) Such vpn solution/services as h a m a c h i, etc (easily can be fpound) intensifely use 5/8, 1/8 and may be some others /8s. Dima
Hi, On Fri, Feb 05, 2010 at 01:02:18AM +0100, Shane Kerr wrote:
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!
Pick your ISP by different criteria than "who is offering the lowest price?". (Every ISP *could* assign public IPv4 addresses [according to RIPE policies, of course :-) ], but the larger mass-market ISPs usually don't do this, because evaluating network requests and handling RIPE documentation etc. costs money...) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Hi, Thus wrote Gert Doering (gert@space.net):
On Fri, Feb 05, 2010 at 01:02:18AM +0100, Shane Kerr wrote:
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!
Pick your ISP by different criteria than "who is offering the lowest price?".
(Every ISP *could* assign public IPv4 addresses [according to RIPE policies, of course :-) ], but the larger mass-market ISPs usually don't do this, because evaluating network requests and handling RIPE documentation etc. costs money...)
Even the larger mass-market ISPs will give you a range if you pick a business contract instead of a residential private user one. As to what you do when you are a small business is simple: you pick a local range that is different than what your phone company uses, and tell your "road warrior" people to use their data plan in a fix, resp renumber your 5 internal servers and DHCP range if it collides with a partners' network range. You can do -that- very easily over a weekend. It gets a lot more interesting for large companies (much harder to renumber) connecting to other large companies. There not only is double NAT, which is bad enough in a static setting, there's the crawling horror of having someone tell you "oh you can get the necessary info by soap from 10.9.8.7" and you get a merry game of finding out which 10.9.8.7 they were referring to, how it is natted, how your server is natted (and whether both are natted the right way, ie not as client on a collective address but on their own addresses), and making sure the firewalls in the path open to the right addresses for that segment of the path (add fun: have six different departments controlling routers, firewalls and servers). I can't wait to have globally unique addresses everywhere. regards, spz -- spz@serpens.de (S.P.Zeidler)
In your previous mail you wrote: The specific issue raised was for VPNs, so it's more like this: => it is not th standard VPN case but a particular case named the road warrior VPN. Fortunately for obvious security reasons the routing system is in general fully overwritten to disallow "local" communications so the address collision is not an issue. 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 => I saw that: funny (if you have no prefix in 1.0.0.0/8). Thanks Francis.Dupont@fdupont.fr
participants (7)
-
Dmitry Burkov -
Francis Dupont -
Geert Jan de Groot -
Gert Doering -
Marc Manthey -
S.P.Zeidler -
Shane Kerr