Re: A Splendid Example Of A Renumbering Disaster

["Andrew G. Malis" <[e-mail]>]

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]> wrote:

> On Sat, 24 Nov 2012, Sabahattin Gucukoglu wrote:
>
>  http://b.logme.in/2012/11/07/**changes-to-hamachi-on-**november-19th/<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
>