[ale] [OT] AT&T/UVerse going to carrier grade NAT?

[Michael H. Warfield]

On Thu, 2012-06-07 at 06:58 -0400, Michael Campbell wrote:
> ALErs,

> A buddy of mine on UVerse received a notice that he would have to change
> his LAN from 10/8 to 192.168/16 for some "improvements" that AT&T was about
> to roll out 6-Jul.

> The buzz on "dslreports.com" is that AT&T is moving to a carrier grade NAT
> setup, and will be issuing all subscribers a 10/8 address, resulting in
> subscribers no longer having a publicly visible IP (static or not).

CGN aka NAT444 aka LSN (Large Scale NAT) is not suppose to be using RFC
1918 addresses.  Last ARIN conference I was at, the discussion was
centered around allocating addresses above the multicast block, IOW
above 240.0.0.0 (multicast is 224.0.0.0/4).  They punted the whole thing
back over to the IETF to resolve, though, and it looks as though the
IETF went in a different direction and allocated 100.64.0.0/10 for CGN
instead in RFC 6598.  If AT&T is using 10.0.0.0/8 addresses, it's just
another fine example of their incompetence in networking in general.

http://en.wikipedia.org/wiki/Carrier-grade_NAT

An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition
http://tools.ietf.org/html/rfc6264

== 
> Carrier-Grade NAT (CGN) [CGN-REQS], also called NAT444 CGN or Large
> Scale NAT, compounds IPv4 operational problems when used alone but
> does nothing to encourage IPv4 to IPv6 transition.  Deployment of
> NAT444 CGN allows ISPs to delay the transition and therefore causes
> double transition costs (once to add CGN and again to support IPv6).
== 

That's just an informational RFC but still...


IANA-Reserved IPv4 Prefix for Shared Address Space
http://tools.ietf.org/html/rfc6598

== 
> Shared Address Space is distinct from RFC 1918 private address space
> because it is intended for use on Service Provider networks.  However,
> it may be used in a manner similar to RFC 1918 private address space
> on routing equipment that is able to do address translation across
> router interfaces when the addresses are identical on two different
> interfaces.
== 

Now, admittedly, this second one is a BCP, and not a standards track RFC
and it was only passed a couple of months ago.  Still...

Tell them to get with the program and follow the IETF RFCs.

Regards,
Mike

> I run a few minor servers on my home machine(s), and this will affect me in
> big ways if I can't get to them from "outside".

> Was wondering if anyone here knew anything about it, and/or if there are
> any tricks with ssh and tunneling to get "back in".  (My thought was to ssh
> to a publicly available machine from my home server with some reverse
> tunnels back to my home server, then talk to the publicly available machine
> on the ports I reverse tunneled - would that work?)

> Thoughts welcome.
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20120607/442ebfb1/attachment.bin