Re: A Splendid Example Of A Renumbering Disaster

[Benson Schliesser <[e-mail]>]

I expect to be flamed for suggesting it, but why not use the Shared 
Address Space for this purpose? (http://tools.ietf.org/html/rfc6598)

Cheers,
-Benson


On 11/26/12 11:52 AM, Andrew G. Malis wrote:
> As LogMein says, even with the TMobile and Rogers use, it's extremely 
> unlikely that their customers will need to communicate with any hosts 
> in 25/8. That said, I absolutely agree that an IPv4 range devoted to 
> VPNs would be great. I run a personal VPN to my home LAN, and I 
> specifically use different ranges of RFC 1918 space for the addresses 
> in my home and my VPN.
>
> Cheers,
> Andy
>
>
>
> On Sat, Nov 24, 2012 at 11:36 AM, Paul Wouters <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On Sat, 24 Nov 2012, Sabahattin Gucukoglu wrote:
>
>         http://b.logme.in/2012/11/07/changes-to-hamachi-on-november-19th/
>
>         LogMeIn Hamachi is basically a NAT-traversing layer 2 VPN
>         solution.  They avoided conflicts with RFC 1918 space by
>         hijacking IPv4 space in 5/8, now actively being allocated by
>         LIRs in Europe.  When that didn't work (see link above), they
>         moved to 25/8, allocated to the UK MoD.  While I'm almost sure
>         that they haven't got it quite so wrong this time, following
>         the comments says that the idea was not only a very bad one to
>         start with, it's cost a lot of people a lot of grief that IPv6
>         was clearly going to mitigate in renumbering.  Perhaps it is
>         why they recommend it per default, if not for the number of
>         applications that would be broken by it.
>
>
>     Both TMobile in the US, and Rogers/Fido in Canada use 25/8. Our IPsec
>     client per default only allows incoming NAT-T for ranges in
>     RFC1918, due
>     to security reasons (you don't want them hijacking google's ip
>     range). So
>     we actually had to add 25/8 to the white list a few years ago.
>
>     But, it would be nice to have an IPv4 range dedicated to VPN
>     ranges, so
>     you can setup things like L2TP tunnels without fear of collision
>     in the
>     RFC1918 space, although I guess technology has advanced enough to
>     implement proper segmentation and workarounds for this these days.
>
>     Paul
>
>