Large ISPs doing NAT?

Mailman List Mirror (Read Only)
1

I hope not.

If you're NATing your customers you're no longer an ISP. You're a
sort-of-tcp-service-provider (maybe a little udp too). NAT (PAT even more
so) breaks so many things that it would be unconscionable to advertise as
an ISP. Even some tcp apps fail under NAT. The NAT box may include a
number of "fix-ups" but such will never be equivalent to giving the
customer a public address.

An Internet Service Provider gives the customer a full connection to the
Internet. All IP protocols should work.

I'm in favor of using NAT only where there is a good argument for it and
the customers are given the straight story about what they're buying and
what it won't be able to do. Don't call yourself an ISP.

Tony Rall

2

> Is anybody here doing NAT for their customers?

Tony Rall:

If you're NATing your customers you're no longer an ISP. You're a
sort-of-tcp-service-provider (maybe a little udp too). NAT (PAT even more

Depends on scale and application. We have lots of customers
that we NAT, one way or another. And a lot more that we don't.
Some customers WANT to 'just see out' and they like all the 'weird stuff
turned off'. Sometimes it's a box at the customers end, sometimes
it's nat'd IP's on the dial-up/ISDN/FracT1/T1/Wireless connection itself.

Saying we are not an ISP because we do some NAT is a little harsh.
Giving the customer options and making things work (when done right,
and explained properly.... we have no sales droids) is good business
and I think good for the 'net. It gives the clueless (and sometimes
cluefull) just a little more isolation.

What is wrong is NAT'ing when you should not.

3

I don't know if this is an annual argument yet, but the frog is in the pot, and the flame is on. Guess who's playing the part of the frog? Answer: ISPs who do this sort of thing. Value added security is a nice thing. Crippling Internet connections will turn the Internet into the phone company, where only the ISP gets to say what services are good and which ones are bad. While an ISP might view it appealing to be a baby bell, remember from whence we all come: the notion that the middle should not inhibit the endpoints from doing what they want. You find this to be a support headache? Offer a deal on Norton Internet Security or some such. Offer to do rules merges. Even offer a provisioning interface to some access-lists. Just make sure that when that next really fun game is delivered on a play station that speaka de IP your customers can play it, and that you haven't built a business model around them not being able to play it.

Eliot

mike harrison wrote:

4

I don't know if this is an annual argument yet, but the frog is in the
pot, and the flame is on. Guess who's playing the part of the frog?
Answer: ISPs who do this sort of thing. Value added security is a nice
thing. Crippling Internet connections will turn the Internet into the
phone company, where only the ISP gets to say what services are good and
which ones are bad. While an ISP might view it appealing to be a baby
bell, remember from whence we all come: the notion that the middle should
not inhibit the endpoints from doing what they want. You find this to be
a support headache? Offer a deal on Norton Internet Security or some
such. Offer to do rules merges. Even offer a provisioning interface to
some access-lists. Just make sure that when that next really fun game is
delivered on a play station that speaka de IP your customers can play it,
and that you haven't built a business model around them not being able to
play it.

As long as it is _clear_ from the get-go that customers behind NAT are
getting that service, and not publicly-routable IP space, I don't see the
problem. If they don't like it, they don't have to sign up to begin with - as
long as there is no doubt as to what kind of service they're getting, there
shouldn't be a problem (legally, at any rate).

This is not to say that if, as Eliot posits, the next Big Thing on the market
requires public IPs that your customer base won't all jump ship. That's a
risk that providers will have to weigh against the benefits of NAT.

5

There was a reason I said *ALMOST*. :wink: Thanks, Eliot.

6

I don't know if this is an annual argument yet, but the frog is in the
pot, and the flame is on. Guess who's playing the part of the frog?
Answer: ISPs who do this sort of thing. Value added security is a nice
thing. Crippling Internet connections will turn the Internet into the
phone company, where only the ISP gets to say what services are good and
which ones are bad. While an ISP might view it appealing to be a baby
bell, remember from whence we all come: the notion that the middle should
not inhibit the endpoints from doing what they want. You find this to be
a support headache? Offer a deal on Norton Internet Security or some
such. Offer to do rules merges. Even offer a provisioning interface to
some access-lists. Just make sure that when that next really fun game is
delivered on a play station that speaka de IP your customers can play it,
and that you haven't built a business model around them not being able to
play it.

As long as it is _clear_ from the get-go that customers behind NAT are
getting that service, and not publicly-routable IP space, I don't see the
problem. If they don't like it, they don't have to sign up to begin with - as
long as there is no doubt as to what kind of service they're getting, there
shouldn't be a problem (legally, at any rate).

You've got to be kidding. Do you think it's clear to the average consumer
buying a GPRS phone what NAT is, and why they might or might not want it?
Do you think the use of NAT will be explained to these customers? Or
clearly stated in 5pt text on page 17 of the service agreement?

IMHO, as one of the people who will likely be using Cingular's GPRS network
with a Danger HipTop, I _strongly_ hope they choose to use routable address
space instead of NAT. I would hate for NAT to be an impediment to some cool
new app no one has thought of yet because these gizmos aren't in widespread
use yet.

This is not to say that if, as Eliot posits, the next Big Thing on the market
requires public IPs that your customer base won't all jump ship. That's a
risk that providers will have to weigh against the benefits of NAT.

I'm more concerned that if the major metropolitan markets deploying GPRS
all use NAT, then the Next Big Thing won't ever happen on GPRS devices.
Customers won't jump ship if they have no where to jump to. That might
sound attractive to the bean counters, but think of the customers you might
never get in the first place. Also, I don't see how deploying NAT could be
a cost savings over requesting real IP space.

-pmb

7

I think a lot of the GRPS stuff is heading towards IPv6 w/IPv4
gatewaying.

The NAT issue has certainly resulted in a quite a few disgruntled
satellite customers (I'm thinking here primarily of direcpc.com) who're
willing to put up with the large latencies, but get really irate when
their apps won't work via NAT, or who want to run RFC1918 space for a
LAN at home, then find out that lots of stuff can't stand being NATted
twice.

8

I'm more concerned that if the major metropolitan markets deploying GPRS
all use NAT, then the Next Big Thing won't ever happen on GPRS devices.
Customers won't jump ship if they have no where to jump to. That might
sound attractive to the bean counters, but think of the customers you might
never get in the first place. Also, I don't see how deploying NAT could be
a cost savings over requesting real IP space.

-pmb

9

Deepak Jain wrote:

MY question is -- How do you know if a justification for _public_ space
handling a large NAT'd pool is the proper size and not an over/under
allocation based on the customer in question?

Why is the answer to this question any different than it has been since BCP-12? The answer is that we don't, but we guard against the problem with methods such as slow start allocations.

Eliot

10

Roland,

I have a static IP w/DirecPC and I haven't noticed any problems running ICS on Win2K. Have things changed?

--Michael

11

The only people who'd be deploying GPRS are GSM cellular providers, no?

Verizon and Sprint PCS, in particular, are not using GPRS, but migrating
to CDMA-based 3G cellular technologies. I don't know that those
technologies use CDMA.

And of course, there are still markets like my very own hometown (2nd
largest city in Ohio) that don't have GSM yet (even though #1 and #3 do).
VoiceStream is supposedly launching their GSM network in Cleveland
(*snort* I've heard that before). But they're not here yet, AT&T is
nowhere near doing GSM here as far as I know, and Cingular's network here
(former AmeriBlech Cellular) is TDMA.

I could be completely off base, of course. Being a customer of Sprint PCS
and Verizon, and a former customer of Alltel and Northcoast PCS, I've not
had much reason to follow GSM developments; every one of the companies
I've used runs CDMA. Feel free to correct me if I am wrong.

12

I'm more concerned that if the major metropolitan markets deploying GPRS
all use NAT, then the Next Big Thing won't ever happen on GPRS devices.
Customers won't jump ship if they have no where to jump to.

The only people who'd be deploying GPRS are GSM cellular providers, no?

The concern exists regardless of the specifics of the always-on, cellular packet radio protocols being used, surely?

[GSM coverage is patchy in the US]

It's prevalent elsewhere. I'd be surprised if there aren't more GSM subscribers in the world than non-GSM subscribers.

Joe

13

[snip]

>As long as it is _clear_ from the get-go that customers behind NAT are
>getting that service, and not publicly-routable IP space, I don't see the
>problem. If they don't like it, they don't have to sign up to begin with - as
>long as there is no doubt as to what kind of service they're getting, there
>shouldn't be a problem (legally, at any rate).

You've got to be kidding. Do you think it's clear to the average consumer
buying a GPRS phone what NAT is, and why they might or might not want it?

The average customer buying a "web-enabled" phone doesn't need a
publicly-routeable IP. I challenge anybody to demonstrate why a cell phone
needs a public IP. It's a PHONE, not a server.

Do you think the use of NAT will be explained to these customers? Or
clearly stated in 5pt text on page 17 of the service agreement?

There's enough other fine print that adding this in somewhere should not be
an issue.

IMHO, as one of the people who will likely be using Cingular's GPRS network
with a Danger HipTop, I _strongly_ hope they choose to use routable address
space instead of NAT. I would hate for NAT to be an impediment to some cool
new app no one has thought of yet because these gizmos aren't in widespread
use yet.

I am totally in favor of public IPs being an _option_ for use with PDAs,
phones and the like - but for the average user, I do not see it being a
necessity, or even really a benefit.

>This is not to say that if, as Eliot posits, the next Big Thing on the market
>requires public IPs that your customer base won't all jump ship. That's a
>risk that providers will have to weigh against the benefits of NAT.

I'm more concerned that if the major metropolitan markets deploying GPRS
all use NAT, then the Next Big Thing won't ever happen on GPRS devices.
Customers won't jump ship if they have no where to jump to. That might
sound attractive to the bean counters, but think of the customers you might
never get in the first place. Also, I don't see how deploying NAT could be
a cost savings over requesting real IP space.

I'm not saying it's the best course of action necessarily; I was trying to
make the "best tool for the job" argument. There are cases where NAT is a
definite advantage, or where having a public IP offers no clear benefits, if
not any obvious risks. Until the model changes drastically, I just don't see
the average phone/wireless PDA user needing a public IP for every device
she/he has. But it should definitely remain an option - just like static IPs
on DSL is an option with most providers.

14

And what if I want to invent the next big thing? A game, that people play
in real time, with their palm-sized gizmo. What if that game can't be made
scalable unless those devices have real IPs? What if that game is the
catalyst that causes a million more customers to go buy a gizmo from
Cingular?

If providers assume that GPRS devices are all just "web-enabled phones",
then that's all they will _ever_ be, and no one will care, and no one will
buy them. If all I want is a PHONE, not a server, I can buy that today (and
Cingular doesn't have to spend millions to deply a whole new backend.)

IMHO, the attitude of "we already know what services you want" is at odds
with the intent of the Internet, and exactly the BS that Telcos have been
feeding customers for years.

I have yet to see any good argument for why mobile-IP providers should use
NAT instead of routable space. And no, "because they might get rooted" is
not a good reason. That's the responsibility of the device designers, NOT
THE NETWORK.

-pmb

15

please re-fetch the key from wwwkeys.us.pgp.net or your nearest mirror. I
updated this key a couple of months back, but it seems that many still have
the old one cached. Sorry about that.

16

[snip]

>> You've got to be kidding. Do you think it's clear to the average consumer
>> buying a GPRS phone what NAT is, and why they might or might not want it?
>
>The average customer buying a "web-enabled" phone doesn't need a
>publicly-routeable IP. I challenge anybody to demonstrate why a cell phone
>needs a public IP. It's a PHONE, not a server.

And what if I want to invent the next big thing? A game, that people play
in real time, with their palm-sized gizmo. What if that game can't be made
scalable unless those devices have real IPs? What if that game is the
catalyst that causes a million more customers to go buy a gizmo from
Cingular?

That's a lot of "if"s. As one other person wrote, IPv6 will probably be the
answer here - the only question is, how long it will be before it becomes de
facto (i.e. all standard networks support and transit it, by default), and
how much pain we will have to endure before this is the case.

If providers assume that GPRS devices are all just "web-enabled phones",
then that's all they will _ever_ be, and no one will care, and no one will
buy them. If all I want is a PHONE, not a server, I can buy that today (and
Cingular doesn't have to spend millions to deply a whole new backend.)

*nod* I'm as much a fan of new gizmos and new features as anybody (heck, my
cell phone does ssh! (it's a VisorPhone running TGssh)), but I think until we
get an infrastructure that can scale to support assigning a routeable IP to
even the _current_ number of cell phones, we need a stopgap measure in the
meantime. NAT is a good contender for that measure. IPv6 is, IMHO, the
ultimate solution, but I'm not sure we're there yet.

IMHO, the attitude of "we already know what services you want" is at odds
with the intent of the Internet, and exactly the BS that Telcos have been
feeding customers for years.

I apologize if that was the attitude that I conveyed; it is most assuredly
_not_ the attitude I hold. I merely meant to convey that a workable solution
now is better than the perfect solution 5 years from now. No reason why we
can't have both, though.

I have yet to see any good argument for why mobile-IP providers should use
NAT instead of routable space. And no, "because they might get rooted" is
not a good reason. That's the responsibility of the device designers, NOT
THE NETWORK.

And I still have yet to hear a convincing argument for why _right now_, NAT
is not, at the least, a workable solution to this issue. It can surely hold
us for a year or three until IPv6 has become the standard. (that timeframe
may be a bit optimistic ...) Given current devices and technology, why is NAT
not a temporary solution?

17

I'm not buying a phone I can't run ssh from. End of story. My current phone does all that and more. Why step back into the dark ages of analog-type services?

Best Regards,

Simon

18

The average customer doesn't even know what telnet is, let alone ssh.
All they care about is browsing pr0n.

-Dan

19

And what if I want to invent the next big thing? A game, that people play
in real time, with their palm-sized gizmo. What if that game can't be made
scalable unless those devices have real IPs? What if that game is the
catalyst that causes a million more customers to go buy a gizmo from
Cingular?

That's a lot of "if"s. As one other person wrote, IPv6 will probably be the
answer here - the only question is, how long it will be before it becomes de
facto (i.e. all standard networks support and transit it, by default), and
how much pain we will have to endure before this is the case.

Well, I'm looking at it from Cingular's perspective. They want to roll out
a new service. They want to make more money off it than from the old
service. They're willing to invest a bunch of money in new equipment if it
means they'll get enough people to sign up to pay for it. This service is
called GPRS.

If IPv6 is the answer, and it isn't available until the _next_ itteration
of this process, then _this_ itteration isn't going to be as profitable as
it could be. Cingular isn't going to redesign their backend a year from now
just because IPv6 is suddenly usable.

Mobile-IP devices are all about bringing the Internet to your pocket. That
doesn't mean just the web! The web is UI optimized for a desktop machine.
Who knows what specific applications might be developed for a user
accessing the Internet from a device the size of a bar of soap? What if I
want to write CUSeeMe for mobile phones? Or a scavanger hunt game?
Something that takes advantage of the mobility rarely found by a desktop
user?

It is these _form factor specific_ applications that will drive the sales
of devices that utilize this new network. Surfing the web is just the tip
of the iceberg that everyone already understands. If that's the only
application enabled by GPRS, then I don't forsee GPRS phones selling in
leaps and bounds. It seems like providers would be spending a whole lot of
money to upgrade their network for just one new application that only a few
customers are asking for.

I have yet to see any good argument for why mobile-IP providers should use
NAT instead of routable space. And no, "because they might get rooted" is
not a good reason. That's the responsibility of the device designers, NOT
THE NETWORK.

And I still have yet to hear a convincing argument for why _right now_, NAT
is not, at the least, a workable solution to this issue. It can surely hold
us for a year or three until IPv6 has become the standard. (that timeframe
may be a bit optimistic ...) Given current devices and technology, why is NAT
not a temporary solution?

A temporary solution to what problem?

Assuming the network can distribute NATed addresses, why can't it
distribute real ones?

Maybe I'm missing something. John Beckmeyer didn't say why they were
looking into using NAT, he only asked if anyone else was using it on this
scale.

The presumption of the first several responders was that it was to conserve
addresses, which they pointed out is not actually necessary. I'm hoping
that was the case, and that maybe the choice of NAT can be revisited...

-pmb

20

The concern exists regardless of the specifics of the always-on,
cellular packet radio protocols being used, surely?

You're right, of course. I was focusing on the wrong thing when I replied.

> [GSM coverage is patchy in the US]

It's prevalent elsewhere. I'd be surprised if there aren't more GSM
subscribers in the world than non-GSM subscribers.

GSM is *the* standard in Europe. Australia, Korea, Japan and a couple
other Pacific-Rim countries are primarily CDMA. South America is primarily
TDMA. Most of the rest of the world is GSM, if I'm not mistaken.