technical contact at ATT Wireless

Fri Jun 29 02:53:36 UTC 2012

On Thu, Jun 28, 2012 at 7:35 PM, Joel Maslak <jmaslak at antelope.net> wrote:
> On Thu, Jun 28, 2012 at 1:35 PM, PC <paul4004 at gmail.com> wrote:
>
>> While you're at it, I've been also trying to complain about them using
>> RFC1918 (172.16.) address space for the DNS servers they assign to their
>> datacard subscribers.  Causes all sorts of problems with people trying to
>> VPN in as the same IP range is used by me.
>
> Which is why enterprises generally shouldn't use RFC1918 IPs for
> servers when clients are located on networks not controlled by the
> same entity.  Servers that serve multiple administration domains (such
> as VPN users on AT&T - or on some random home Linksys box) probably
> shouldn't be addressed using addresses that conceivably could be used
> at the other end.  But I'm probably fighting a losing battle saying
> that...
>
> It's why at my last enterprise net admin jobs, I refused to establish
> a site-to-site VPN session with organizations using RFC1918 space as
> part of the tunnel definition (it's amazing how few organizations
> wanted to use global IPs for inter-domain routing, but most came
> around, although I had to loan IP addresses to several so they could
> static NAT their servers behind them).  It's simple: If I wouldn't
> accept IPs in that range over a public BGP peering, I didn't want it
> over a private static route either.  I couldn't control what you did
> for RFC1918, nor could you control what I did - so I exposed public
> IPs, and expected you to do the same.  :)
>
> RFC1918 and VPN becomes non-scalable fast when you connect to lots of
> different organizations - it doesn't take long before two
> organizations you connect to both want to use 172.16.0.x/24 or
> 10.0.0.x/24 or 192.168.0.0/24, or similar).  The same logic goes for
> VPN clients - if one end is potentially using RFC1918, the other end
> better not use it.  Since you can usually only control one end of the
> VPN for road-warrior VPN, it's best to make that end not use RFC1918.
> Otherwise you may find you need to route 192.168.x.y, but that just so
> happens to be the user's default gateway, name server, printer, or
> other key device.  Of course having another set of NAT addresses for
> CGN will solve everything (yes, that's sarcastic, but I can predict
> how they'll be used to "solve" this type of problem).
>
> Just because "it usually works" doesn't mean using RFC1918 addresses
> for left and/or right subnets in a VPN is a good idea.
>

And, then there is this case where AT&T DSL is moving towards 10.x.x.x
in the access network and they are guiding customers to move off that
network in their LANs

http://www.broadbandreports.com/forum/r27139468-Uverse-wants-me-to-change-my-network-address-

NET NET, ipv4 is getting more unreliable every day.  Probably should
consider IPv6 more strongly.

And, getting AT&T to change their infrastructure is an exercise in
futility.  Your time is better spent changing your VPN to tunnel all
traffic, including DNS, and / or moving to use an alternate DNS
server.

CB