Re: A Splendid Example Of A Renumbering Disaster

Benson Schliesser <bensons@xxxxxxxxxxxxx> · Mon, 26 Nov 2012 12:12:42 -0500



    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 <paul@xxxxxxxxx>
          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