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

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

I would hope that PlusNet has valid, well-thought-out reasons for deploying CGN instead of IPv6. Not knowing those, I can only jugde their position on its face: foolish and short-sighted.

To quote a NANOG veteran: "I encourage my competitors to do this" :slight_smile:

jms

A lot of ISPs have customers who are foolish and short-sighted (or
customers unable to move away from suppliers who are foolish and
short-sighted,) and need to support those customers. I'd be very surprised
if this move isn't in addition to IPv6 support, even though the article
reads as though it is instead of IPv6 support.

In other words, it makes sense to be able to support customers who won't
move to IPv6 in the short-medium term, even though in the long term it's
inevitable.

Dan

Move along, nothing to see here. Barring a few fanatics, everyone here
has known for several years now that CGN would be required for
continuing IPv4 support regardless of the progress of IPv6.

If you spin it right, it's a "Free network-based firewall to be
installed next month. Opt out here if you don't want it." And the
fewer than 1 in 10 folks who opt out really aren't a problem.

Regards,
Bill Herrin

I agree, IPv6 isn't an answer to "we're out of IPv4 addresses" right now. So CGNAT44 i combination with IPv6 rollout makes perfect sense.

I would hope that PlusNet has valid, well-thought-out reasons for deploying
CGN instead of IPv6. Not knowing those, I can only jugde their position on
its face: foolish and short-sighted.

Move along, nothing to see here. Barring a few fanatics, everyone here
has known for several years now that CGN would be required for
continuing IPv4 support regardless of the progress of IPv6.

If you spin it right, it's a "Free network-based firewall to be
installed next month. Opt out here if you don't want it." And the
fewer than 1 in 10 folks who opt out really aren't a problem.

Even tough you have very good arguments, my suggestion would be to have a class A network (I got that right, right?) for all the users and only having 6rd as service on that network.

ARIN and IETF cooperated last year to allocate 100.64.0.0/10 for CGN
use. See RFC 6598. This makes it possible to implement a CGN while
conflicting with neither the user's RFC1918 activity nor the general
Internet's use of assigned addresses. Hijacking a /8 somewhere instead
is probably not a great move.

Regards,
Bill Herrin

Even tough you have very good arguments, my suggestion would be to have a
class A network (I got that right, right?) for all the users and only having
6rd as service on that network.

ARIN and IETF cooperated last year to allocate 100.64.0.0/10 for CGN
use. See RFC 6598. This makes it possible to implement a CGN while
conflicting with neither the user's RFC1918 activity nor the general
Internet's use of assigned addresses. Hijacking a /8 somewhere instead
is probably not a great move.

Ok.

If I have calculated the netmasks right that would mean to set aside:

2001:0DB8:6440::/42

for the use of 6rd service:

2001:0DB8:6440:0000::/64 = 100.64.0.0
....
2001:0DB8:647F:FFFF::/64 = 100.127.255.255

Hi,

If I have calculated the netmasks right that would mean to set aside:

2001:0DB8:6440::/42

for the use of 6rd service:

2001:0DB8:6440:0000::/64 = 100.64.0.0
....
2001:0DB8:647F:FFFF::/64 = 100.127.255.255

You probably should add a few extra bits for subnetting behind the 6rd CPE. Delegating one /64 would be annoying as more and more CPEs have separate home/office/guest networks. Giving a /56 to each customer would be good and would only take an IPv6 /34 to map from 100.64.0.0/10. That is a quarter of the smallest IPv6 allocation an ISP can get.

ISPs can get plenty of IPv6 address space these days if they need it. Smaller ISPs don't need to map the whole 100.64.0.0/10, they could just start with 100.64.0.0/16 for example, which would only take a /40 to give every customer a /56. More blocks can always be added to the 6rd setup later.

Cheers,
Sander

ARIN and IETF cooperated last year to allocate 100.64.0.0/10 for CGN
use. See RFC 6598. This makes it possible to implement a CGN while
conflicting with neither the user's RFC1918 activity nor the general
Internet's use of assigned addresses. Hijacking a /8 somewhere instead
is probably not a great move.

If I have calculated the netmasks right that would mean to set aside:

2001:0DB8:6440::/42

for the use of 6rd service:

2001:0DB8:6440:0000::/64 = 100.64.0.0
....
2001:0DB8:647F:FFFF::/64 = 100.127.255.255

Sander already touched on this, but when implementing 6rd you'll want
*at least* 4 bits on the subnetting side of the IPv6 block associated
with each IPv4 address and you'll want that netmask to be evenly
divisible by 4. A /60 or a /56, not a /64.

In IPv4 your customer has a "DSL router," potentially with distinct
wired and wireless LANs running different RFC1918 address blocks. In
IPv6 each of those LANs will consume a /64, so he'll need more than
one.

Selecting a netmask evenly divisible by 4 has two major benefits.
First, it exactly matches one character in the written address. The
customer doesn't have ...:ABC4:* through ...:ABC7:*, he has
...:ABC*::. Second, each delegable RDNS zone takes up the same 4 bits
so the assignment will be right on an RNDS zone boundary.

Even tough you have very good arguments, my suggestion would be to have a
class A network (I got that right, right?) for all the users and only having
6rd as service on that network.

I assume you meant this a little differently than what you wrote here.
It wouldn't make any kind of sense to stand up a private IPv4 network
with no IPv4 Internet connection in order to facilitate IPv6 via a 6rd
deployment. For one thing it'd be a Rube Goldberg machine. For
another, I suspect you'd find it very challenging to acquire a
threshold number of paying customers for an IPv6-only network at the
moment.

Regards,
Bill Herrin

Apparently they aren't _totally_ blind to v6, but it sounds like it's been put in the mystery "when we have a spare moment!" bin:

http://community.plus.net/forum/index.php/topic,106125.0.html

S.

No. With 6rd you DROP the top 10 bits and you give every customer
a /56. And you can repeat the exercise 4 times within a /32.

/etc/dhcpd.conf:
subnet 100.64.0.0 netmask 255.240.0.0 {
  range 100.64.0.2 100.64.255.254;
  router 100.64.0.1;
  option 6rd 10 34 2001:DB8:: 2001:DB8::1;
}
subnet 100.64.0.0 netmask 255.240.0.0 {
  range 100.64.0.2 100.64.255.254;
  router 100.64.0.1;
  option 6rd 10 34 2001:DB8:4000: 2001:DB8:4000:1;
}
subnet 100.64.0.0 netmask 255.240.0.0 {
  range 100.64.0.2 100.64.255.254;
  router 100.64.0.1;
  option 6rd 10 34 2001:DB8:8000: 2001:DB8:8000:1;
}
subnet 100.64.0.0 netmask 255.240.0.0 {
  range 100.64.0.2 100.64.255.254;
  router 100.64.0.1;
  option 6rd 10 34 2001:DB8:c000: 2001:DB8:C000:1;
}

i am not network engineer, but I follow this list to be updated about
important news that affect internet stability.

NAT is already a problem for things like videogames. You want people
to be able to host a multiplayer game, and have his friends to join
the game. A free to play MMO may want to make a ban for a bad person
permanent, and for this banning a IP is useful, if a whole range of
players use a ip, it will be harder to stop these people from
disrupting other people fun. Players that can't connect to the other
players whine on the forums, and ask the game devs to fix the problem,
costing these people money. People that can't connect to other
players, for a problem that is not in his side, or under his control,
get frustrated. This type of problems are hard to debug for users.

The people on this list have a influence in how the Internet run, hope
somebody smart can figure how we can avoid going there, because there
is frustrating and unfun.

If you follow this list then you should already know the answer,
functional* IPv6 deployments.

- Mike

*Some ISPs have some very weird ideas that I hope never catch on.

AND game developers who build IPv6 functionality into their products. Do you hear us, PS3 and Xbox?

Oscar, make sure you are telling your favorite game developers that they need to support IPv6 if they want to avoid the NAT mess.

..

AND game developers who build IPv6 functionality into their products. Do
you hear us, PS3 and Xbox?

Oscar, make sure you are telling your favorite game developers that they
need to support IPv6 if they want to avoid the NAT mess.

Ok. I will pass the message.

Some of them ( FOSS guys) already did

For most commercial projects it don't have my hopes very high. Most
game software development are rushed to release.

"Free network-based firewall to be installed next month. OPT OUT HERE
if you don't want it."

It's not a hard problem. There are yet plenty of IPv4 addresses to go
around for all the people who actually care whether or not they're
behind a NAT.

Regards,
Bill Herrin

The people on this list have a influence in how the Internet run, hope
somebody smart can figure how we can avoid going there, because there
is frustrating and unfun.

"Free network-based firewall to be installed next month. OPT OUT HERE
if you don't want it."

I haven't heard anyone talking about carrier-grade firewalls. To make CGN
work a little, you have to enable full-cone NAT, which means as long as
you're connected to anything on IPv4, anyone can reach you (and for a
timeout period after that). And most CGN wireline deployments will have
some kind of bulk port assignment, so the same ports always go to the same
users. NAT != security, and if you try to make it, you will lose more
customers than I predicted.

It's not a hard problem. There are yet plenty of IPv4 addresses to go
around for all the people who actually care whether or not they're
behind a NAT.

I doubt that very much, and look forward to your analysis supporting that
statement.

Lee

The people on this list have a influence in how the Internet run, hope
somebody smart can figure how we can avoid going there, because there
is frustrating and unfun.

"Free network-based firewall to be installed next month. OPT OUT HERE
if you don't want it."

I haven't heard anyone talking about carrier-grade firewalls. To make CGN
work a little, you have to enable full-cone NAT, which means as long as
you're connected to anything on IPv4, anyone can reach you (and for a
timeout period after that). And most CGN wireline deployments will have
some kind of bulk port assignment, so the same ports always go to the same
users. NAT != security, and if you try to make it, you will lose more
customers than I predicted.

Hi Lee,

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.

It's not a hard problem. There are yet plenty of IPv4 addresses to go
around for all the people who actually care whether or not they're
behind a NAT.

I doubt that very much, and look forward to your analysis supporting that
statement.

If you have the data I'll be happy to crunch it but I'm afraid I'll
have to leave the data collection to someone who is paid to do that
very exhaustive work.

Nevertheless, I'll be happy to document my assumptions and show you
where they lead.

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.

I assume that 75% or more of the IPv4 addresses which are employed in
any use (not sitting idle) are employed by eyeball customers. Verizon
Wireless has - remind me - how many /8's compared to, say, Google?

If you count from the explosion of interest in the Internet in 1995 to
now, it took 18 years to consume all the IPv4 addresses. Call it
consumption of 1/18th of the address space per year.

From my assumption, 25% of the addresses are consumed by non-eyeball

customers who will continue consuming them at 1/(18*4)= 1/72 of the
address space per year. Assuming that server ops still need that many
addresses when acquiring them is not so close to free.

From my assumptions 75% * 0.9 = 67.5% of the addresses are currently

consumed by eyeball customers who can convert to NAT. Match the
previous paragraph's math at 49/72's of the address space recoverable
at some cost that while not trivial is also not exorbitant.

Eyeballs were consuming at (1*3)/(18*4)= 3/72's per year but if only 1
in 10 needs a global address that slows to 3/720's.

13/720's per year consumes 490/720's after 37 years.

37 years.

So, where am I wrong? 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.

Is the current use pattern more like 50/50 between server users and
eyeball users? That'd cut things closer to a decade and a half but
what data I've glanced at from CAIDA, ARIN and the like doesn't seem
to support a belief that eyeballs aren't the major direct user of IPv4
addresses.

Perhaps consumption is accelerating, but a lot of that has been
low-key hoarding during the past 5 years or so. Even with accelerating
consumption we're still looking at a couple decades before we have to
really scrape for IPv4 addresses.

Perhaps I fouled the math itself. I've been known to miscarry a 1. All
the same, the sky doesn't seem to be falling.

Regards,
Bill Herrin

Nevertheless, I'll be happy to document my assumptions and show you
where they lead.

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.

And this is where you run off the rails… You are assuming that NAT today
and CGN provide similar functionality from an end-user perspective.

The reality is that they do not. CGN is a substantially more degraded
form of internet access than current traditional per-site NAT.

1. The end-site does not control the NAT box.
2. UPnP and NAT-PMP do NOT work through CGN.
3. There is no other provision in most CGNs to allow for inbound
  connection trickery that allows many of today's applications to
  function in spite of NAT.

Some few of them
are running game servers, web servers, etc. but 9 in 10 are the email,
voyage and netflix variety who are basically not impacted by NAT.

Vonage will, in most cases fail through CGN as will Skype, Xbox-360,
and many of the other IM clients.

I assume that 75% or more of the IPv4 addresses which are employed in
any use (not sitting idle) are employed by eyeball customers. Verizon
Wireless has - remind me - how many /8's compared to, say, Google?

Are you sure that 75% of VZW's IP addresses are assigned to end-customer
devices? I am not.

If you count from the explosion of interest in the Internet in 1995 to
now, it took 18 years to consume all the IPv4 addresses. Call it
consumption of 1/18th of the address space per year.

I'll leave the obvious math error in this assumption as an exercise for
the reader.

From my assumption, 25% of the addresses are consumed by non-eyeball

customers who will continue consuming them at 1/(18*4)= 1/72 of the
address space per year. Assuming that server ops still need that many
addresses when acquiring them is not so close to free.

This assumption ignores non-customer use of addresses which, while minor,
is not insignificant.

From my assumptions 75% * 0.9 = 67.5% of the addresses are currently

consumed by eyeball customers who can convert to NAT. Match the
previous paragraph's math at 49/72's of the address space recoverable
at some cost that while not trivial is also not exorbitant.

This makes a rather absurd assumption that the majority of those eyeball
addresses are not already assigned to eyeball NAT pools. This is the
second place where your assumptions run wildly off the rails IMHO.

Eyeballs were consuming at (1*3)/(18*4)= 3/72's per year but if only 1
in 10 needs a global address that slows to 3/720's.

While the math works, it would be a lot more clear to say 1/4 * 3/18 = 3/72.

13/720's per year consumes 490/720's after 37 years.

37 years.

So, where am I wrong? 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.

First, it's more like 1/100 customers that are not already behind NAT
of some form, so your 37 years drops to 0.37 years (a little more than
4 months).

This seems very disruptive and rather heavy on the overhead for a 4-month
stop-gap.

Owen