Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

Sat Jan 19 02:56:26 UTC 2013

On 16 January 2013 08:12, fredrik danerklint <fredan-nanog at fredan.se> wrote:
> From the article:
>
> "Faced with the shortage of IPv4 addresses and the failure of IPv6 to take
> off, British ISP PlusNet is testing carrier-grade network address
> translation CG-NAT, where potentially all the ISP's customers could be
> sharing one IP address, through a gateway. The move is controversial as it
> could make some Internet services fail, but PlusNet says it is inevitable,
> and only a test at this stage."
>
> http://tech.slashdot.org/story/13/01/16/1417244/uk-isp-plusnet-testing-carrier-grade-nat-instead-of-ipv6
>
> I'm only here to bring you the news. So don't complain to me...

It is obvious that implementing CGN requires a lot of extra resources
and a lot of hardware/firmware support for both CPE and operator
equipment (the latter from both technical and legal-compliance
reasons, and both the former and the latter in order to implement some
kind of UPnP-compatible support to still allow some kind of p2p apps
to somehow function).

And this is at a time when a lot of the world internet traffic has
already moved to IPv6, and all major content providers that account
for most of the traffic today already support native IPv6: Google,
YouTube and FB.

Wouldn't it be better instead of the untested, unscalable and dead-end
IPv4 CGN to massively start implementing single-stacked IPv6 with
NAT64 at the ISP and *464XLAT* within the CPE RG?  (With 464XLAT, you
wouldn't even need a potentially troublesome DNS64.)  This way,
instead of having to account for subscriber growth presenting
scalability issues on your limited IPv4 resources and CGN-related
concerns, you can instead account for the content growth of
IPv6-enabled sites, and, basically, have to plan for just about no
extra IPv4 scaling budget whatsoever, since with every X subscribers
that still need IPv4, you'll have every XX old subscribers that will
be moving closer to being IPv6-only.  And with every year, a single
IPv4 address used for NAT64 will be perfectly able to scale up to
serve more and more customers, since fewer and fewer people will need
IPv4 connections.

So:

With CGN, we get to the same old chicken-and-egg story:  lack of IPv6
deployment and content/app support, yet an even more imminent shortage
of IPv4 addresses (and with every new customer you'll be so much more
closer to it) and the scalability and legal issues.

With 464XLAT on the CPE RG and NAT64 at the carrier instead, you get
all the benefits of CGN (namely, all non-p2p IPv4-only apps and
services will still work perfectly fine), but only a couple of the
drawbacks.  And it'll actually put the correct pressure for both
content and application developers to immediately switch to IPv6, and
avoid you, the operator, from having to be spending the extra
resources and having extra headaches on the IPv4 address shortage.  It
really makes no sense that any company would still want to invest a
single dime into CGN when instead they could be investing in IPv6 with
NAT64 and CPE RGs with 464XLAT.

I honestly think that 464XLAT can potentially solve all the chicken
and egg problems that the big players have been having.  Supposedly,
that's how T-Mobile USA is planning to move their network forward.
(I'm certainly looking towards the day when I could finally enable
IPv6 on a Google Nexus on T-Mo.)

On the other hand, it's really strange that 464XLAT is so brand bloody
new when IPv6 itself, as well as even NAT64 and DNS64, have been there
for ages.  The idea of 464XLAT is just so ingeniously straight and
simple!  Somewhat similar to 6rd, I guess.

I think that instead of any kind of CGN, all residential (and mobile)
broadband connections should be IPv6-only with NAT64 and 464XLAT.
That'll basically solve all the actual problems with one stone: lack
of IPv6 deployment from content publishers and IPv6 application
support (from app developers with no IPv6), and the immediate shortage
of the IPv4 addresses.

Cheers,
Constantine.