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

Mailman List Mirror (Read Only)
41

Then it's a firewall that mildly enhances protection by obstructing
90% of the port scanning attacks which happen against your computer.
It's a free country so you're welcome to believe that the presence or
absence of NAT has no impact on the probability of a given machine
being compromised. Of course, you're also welcome to join the flat
earth society. As for me, the causative relationship between the rise
of the "DSL router" implementing negligible security except NAT and
the fall of port scanning as a credible attack vector seems blatant
enough.

CGNs are not identical to home NAT functionality.

Didn't say they were. What I said was that claiming NAT has no
security impact was false on its face.

Even I have never claimed that. I think everyone pretty well understands at this point just how injurious NAT is to actual security.

CGNs are most certainly not full cone NATs. Full cone NATs guarantee
that any traffic which arrives at the external address is mapped to
the internal address at the same port, functionality which requires a
1:1 mapping between external addresses and active internal addresses.
Were they full-cone, with a 1:1 IP address mapping, CGNs would be
completely useless for the stated purpose of reducing consumption of
global addresses.

I'm given to understand that they do try to restrict a given internal
address to emitting packets on a particular range of ports on a
particular external address but that's functionality on top of a
restricted-port cone NAT, not a fundamentally different kind of NAT.

Actually, as I understand it, it's a hybrid. It's full cone (sort of) in that any packet that arrives within the port range will be translated to the corresponding internal address. It's restricted cone in that it's a port range instead of all ports. I'm not sure how the interior device is constrained to emitting only within the port range unless they are customizing all of the CPE in order to support that.

I assume that fewer than 1 in 10 eyeballs would find Internet service
behind a NAT unsatisfactory. Eyeballs are the consumers of content,
the modem, cable modem, residential DSL customers. Some few of them
are running game servers, web servers, etc. but 9 in 10 are the email,
vonage and netflix variety who are basically not impacted by NAT.

Netflix seems to have some funny interactions with some gateways and CGN.
[nat444-impacts]

Some NATs have serious bugs that aren't obvious until you try to stack them.

Which in itself is a pretty strong argument against CGN.

What about p2p?

If it worked with CGNs there'd be a whole lot less than 1 in 10 folks
needing to opt out.

So you are assuming <10% of the internet currently uses any p2p technology? Interesting.

You're going with linear growth? See nro.net/statistics.

I'm guessing sublinear given the major backpressure from having to
purchase or transfer IP addresses from other uses instead of getting
fresh ones from a registry but the evidence isn't in yet so I'll
conservatively estimate it at linear.

I don't think that backpressure really works against having new subscribers or towards reducing churn in the market place where there is competition. As such, I don't see how that would apply.

Is it more like 1 in 5 customers would cough up
an extra $5 rather than use a NAT address? The nearest comparable
would be your ratio of dynamic to static IP assignments. Does your
data support that being higher than 1 in 10? I'd bet the broad data
sets don't.

If an ISP is so close to running out of addresses that they need CGN,
let's say they have 1 year of addresses remaining. Given how many ports
apps use, recommendations are running to 10:1 user:address (but I could
well imagine that increasing to 50:1). That means that for every user you
NAT, you get 1/10 of an address.

So at 10:1 you get 9/10ths of an address back from each of the 9 in 10
eyeballs who converts to NAT. At a more likely ratio of 30:1 you get
29/30ths back. I'd have to rerun my numbers but that shaves something
on the order of 1 year off my 37 year estimate.

Actually, at 10:1, you get back 10/11ths, not 9/10ths.

However, if CGN's limitations pick up some bad press in the early days, that ratio may well convert to more like 1:10 where you get back 1/11th instead of 10/11ths. This all remains to be seen. Remember, the public will go much more with the emotional reaction to the first press accounts than it will go with rational or well thought out technical argument.

Owen

42

Not necessarily. Maybe they need CGN, but they need NAT64, not NAT44. Or
IVI.
Or maybe they should just hold their noses and buy addresses for a year or
a few.
What they need a transition strategy; it doesn't necessarily have to be
CGN.

Years ago, I asked, "Why are we stuck with NAT?" I still ask that. I
believe that the reason we're stuck with it is that so many of us believe
we're stuck with it--we're resigned to failure, so we don't do anything
about it.
One of the largest problems we have with this transition is that no one
believes they have any influence on it: "I'm stuck with IPv4 until every
single other host on the Internet is using IPv6, and maybe for a while
after that, depending on happy eyeballs."
There are many levers of influence, but the most important ones to use are
those that shift externalities. The cost in transition, either in IPv6 or
in CGN (or both) will be incurred disproportionately by ISPs. Content
providers who care most about quality experience (and usefulness of IP
address information) now support IPv6. If you think creatively, you might
come up with several levers that could shift the expense from "it's up to
ISPs to translate" to "content and devices manufacturer businesses are at
risk if they don't support IPv6."

Then there's the question--how do you know when you're done? Every single
host on the Internet is running IPv6? All but 100? A million? A billion?
Probably somewhere in between, but each operator has to decide. Everyone
else has to decide when to support IPv6--and hope it's before operators
call the transition complete, because then it's too late, because
consumers will choose the competitor's product or service that works (on
IPv6). If Wordpress doesn't work because there's no IPv6, but Blogspot
and Blogger do, maybe consumers just switch.

Lee

43

Lee Howard wrote:

If an ISP is so close to running out of addresses that they need CGN,
let's say they have 1 year of addresses remaining. Given how many ports
apps use, recommendations are running to 10:1 user:address (but I could
well imagine that increasing to 50:1). That means that for every user
you
NAT, you get 1/10 of an address.
Example: An 10,000-user ISP is growing at 10% annually. They have
1,000
addresses left, so they implement CGN. You say to assuming 90% of them
can be NATted, so next year, 100 get a unique IPv4 address, the other
900
share 90 addresses. At 190 addresses per year, CGN bought you five
years.

I think your 90% is high. If it's 70%, you burn 370 per year.
That doesn't include the fact the increased support costs, or alienated
customer cancellations, or any of the stuff I talked about in TCO of
CGN.

Lee

2-5 years from a currently one year supply?
Factor in the current base and growth for at least another decade is
assured.
If it works for the new subscribers, it will work for the existing ones.

It is difficult to change an existing customer's service. Good luck.

Does anybody doubt that successful CGN deployment easily translates into
many years more of v4?

Yes, I doubt it. Although if you define "successful" as "many more years
of IPv4" my doubts vanish solipsistically.

We understand that there are hosts of theoretical and practical impacts.
What we do not yet know is how the public and providers at large will
react or adapt to these impacts.

If just the right balance of CGN negativity and resulting v6 adoption is
the result, then we will all muddle through more or less ok.

Otherwise we will be seeing either frantic v6 migration everywhere or
even slower pace then what we have now.

Fear, uncertainty, doubt. Possible frantic migration.
These sound bad to me.

Lee

44

Oddly enough, the drop in portscanning attacks maps even more closely
to the shipping of XP SP2, which turned on the onboard firewall by
default. Remember that some of the really big worm hits were when
they managed to get loose inside corporate networks behind the NAT...

Also, a NAT doesn't stop a Java or Adobe exploit in the least, as anybody
with security clue will tell you....

45

Corporate enterprises have been pushing GPO to the desktop for more
than a decade as well. Feel free to try to push GPO to Joe Sixpack's PC,
let me know how that works out for you.

46

Should NAT become prevalent and prevent innovation because of its
limitations, this means that innovation will happen only with IPv6 which
means the next "must have" viral applications will require IPv6 and this
may spur the move away from an IPv4 that has been crippled by NAT
everywhere.

47

Hi Lee,

We're stuck with NAT because -enterprise- network security folks
universally accept NAT's efficacy as a lynchpin component in their
system security architecture. They accept it because the reasoning in
support of the proposition makes sense and they consider the fact of
its efficacy to have been satisfactorily demonstrated in practice.

You can chase any other reasons for using NAT to the ends of the Earth
and you'll never achieve a network where NAT's use can be
discontinued.

Regards,
Bill Herrin

48

It won't happen and I'll tell you why not.

Client to client communication block diagrams:

Without NAT:
Client->Router->Router->Router->Router->Router->Client

With NAT:
Client->Router->Router->Relay->Router->Router->Client

At a high level, the two communication diagrams are virtually identical.

Add killer app. By it's nature, a killer app is something folks will
pay good money for. This means that 100% of killer apps have
sufficient funding to install those specialty relays.

Odds of a killer app where one router can't be replaced with a
specialty relay while maintaining the intended function: not bloody
likely.

Regards,
Bill Herrin

49

Back in the late 1980s, large computer manufacturers such as Digital,
HP, IBM were pressured to adopt the future in networking: OSI as
transport and X.400 for emails.

These stacks were eventually developped and implemented.

However, the much simpler and more cost effective "Internet" ended up
winning and it didn't take that long for governments to remove the
requirements to be "OSI compliant" and accepted IPv4 and SMTP as the new
standard.

OSI and X.400 never gained much of a foothole and the millenium
generation probably never heard of them.

Is it possible that the same fate awaits IPv6 ? There is pressure to go
to IPv6, but if solutions are found for IPv4 which are simpler and more
easily deployed, won't that kill any/all efforts to move to IPv6 ?

50

The killer app of the internet is called p2p.

Don't we already have a shortage of IPv4 addresses to start abandoning
p2p, and requiring every service to be server-based, wasting extra
precious IPv4 addresses?

Where's the logic behind this: make it impossible for two computers
to community directly because we have a shortage of addresses, yet
introduce a third machine with, again, rather limited resources, to
waste another IPv4 address? Wasting all kinds of extra resources and
adding extra latency? That's not a killer app, that's the
inefficiency of capitalism.

C.

51

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.

52

Constantine,

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."

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

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.

Brilliant so far ...

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.)

OK... i am wading into dangerous territory now: Why are you waiting?

This page has the 464XLAT software and procedure for Nexus S, Galaxy
Nexus, as well as apk for any rooted Android that can handle IPv6 on
cellular clatd on Android

Or for the more pure IPv6-only NAT64/DNS64 out-of-the-box experience

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.

Well, i certainly fought it as long as i could. I was really drinking
the Kool-Aid that apps that could not support IPv6 would be
de-selected since they were unfit for the internet. I figured
evolution would win, but inertia was certainly making things too slow,
thus we needed a way to make IPv4-apps (cough cough Skype, Netflix
Android App, ...) work on IPv6.

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.

Rock on. I have been on IPv6-only + NAT64/DNS64 for 2 years on mobile
full-time, works fine for all my use cases (i dont use skype, voice
minutes are close enough to free for many people)

CB

53

There is no "suckerage" to V6. Really, it's not that hard. While
CGN is the reality, we need to keep focused on the ultimate goal -- a
single long term solution. Imagine a day where there is no dual
stack, no IPv4, and no more band-aids. It will be amazing.

david.

54

No, because NAT-like solutions to perpetuate v4 only handle the client side of the transaction. At some point there will not be any more v4 address to assign/allocate to content provider networks. They have seen the writing on the wall, and many of the largest (both by traffic and market share) have already moved to providing their content over v6.

Doug

55

Potentially another source of IPv4 addresses - every content network
(/hosting provider/etc) that decides they don't want to give their
customers IPv6 reachability is a future bankrupt ISP with a load of
IPv4 to sell off :slight_smile:

- Mike

56

The killer app of the internet is called p2p.

P2p is not an app, it's a technique for implementing an app. There are
few apps which require p2p and can't be trivially redesigned not to.
If you'll pardon me saying so (and even if you won't) those few boil
down to bit torrent and its cousins: used almost exclusively for
unlawful activities by cheapskates whose wallets are too few and too
small to drive the system.

that's the
inefficiency of capitalism.

I wouldn't put it that way but yeah, that's the gist of it. There's an
unambiguous and very strong capitalist profit incentive to make your
new technology work with IPv4 and NAT. The comparable profit incentive
to make it work with IPv6 is weak almost to the point of
non-existence. And there is a severe shortage of networking staff
capable of implementing technologies that are different than what an
organization has implemented before. That market push facilitates
deployment of CGNs while sucking manpower away from IPv6.

Regards,
Bill Herrin

57

The problem is that content networks tend to be a lot smaller than eyeball
networks. Even AS15169 fits inside a single /12. How long will that
sustain the average IPv6-adverse eyeball network?

58

There is no "suckerage" to V6. Really, it's not that hard. While
CGN is the reality, we need to keep focused on the ultimate goal -- a

Correct. CGN may be part of a transition towards IPv6. Not all
providers are necessarily going to see it that way. It's a
non-resolutely answered question, whether IPv4+CGN will win, and it
will become the new common delivery of IP, or if IPv6 will win.

What will be the ultimate cost, for a provider choosing to implement
only IPv4 CGN, and completely eschew/ignore IPv6, if IPv6, gets
massive buy-in and becomes a predominant IP networking technology,
in demand, adopted by all their competitors....
Potential loss of much business for the service provider, due to
competitive disadvantage.

Versus cost of careful design and building in IPv6 together with CGN
rollouts, so there
is one major redesign, to prepare for transition, and not two
separate rollouts
one for CGN and one later to completely rethink for IPv6...

In either scenario.... 1 ISP network implementation project for 1
wrong technology for dealing with IP exhaustion (IPv6 or CGN), and
not recognizing the problem early is a disaster -- business goes to
the competition.

2 ISP network implementation projects; first 1 technology, then the
other, after discovering, the wrong technology was chosen, is an
improvement (but still expensive) -- network redesign is time
consuming, network devices and software are expensive, and business
lost to the competition, at least until redesign is completed.

1 implementation of 1 right technology (IPv6 or CGN) and never the
other is ideal -- cost implementing CGN (or IPv6) is avoided, if
the technology never became necessary. (It's an unlikely scenario
after IP exhaustion, however, that either will be unnecessary.)

1 up front preparation/implementation of 2 technologies, in time for
IP exhaustion, has high upfront cost, but alleviates the high risk
of the first 2 scenarios.

single long term solution. Imagine a day where there is no dual
stack, no IPv4, and no more band-aids. It will be amazing.

It's probably about 20 years away.

59

From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu]

> On the technical side, enterprises have been doing large-scale NAT
for
> more than a decade now without any doomsday consequences. CGN is not
> different.

Corporate enterprises have been pushing GPO to the desktop for more
than a decade as well. Feel free to try to push GPO to Joe Sixpack's
PC,
let me know how that works out for you.

We don't even do NAT here. Our corporate parent has PI space that they've had since the Jurassic period of the internet and we mostly live on that (there are spots of 1918 addresses, but not for NAT purposes, think temporary networks in lab spaces). Access to the internet at large is all via proxy, there is no direct way out.

Jamie

60

From: Jeff Kell [mailto:jeff-kell@utc.edu]
Sent: Thursday, January 17, 2013 7:30 PM

[snip]

Not sure about Vonage, but Skype, Xbox, and just about everything else
imaginable (other than hosting a server) works just fine over NAT with
default-deny inbound here, and we have several thousand students in the
dorms that bang the heck out of those services. Most applications have
adapted to the SOHO NATing router that is prevalent today on broadband
internet. And if it didn't work, believe me, I'd hear about it :slight_smile:

Jeff

Really? We get a lot of students complaining about PS3s and Xboxes and giving us documentation for various games indicating that either NAT(PAT) must support UPnP or statically mapped inbound connections, or the game won't work. On the other hand, multi-player games are about the only thing that our users are actually telling us isn't working, we haven't heard any complaints about Skype, Vonage, or other VoIP or IM products.

Reference: Xbox Support