couple of questions regarding 'lifeline' and large scale nat...

We're toying with the idea of a low bitrate 'lifeline' internet on our cable system, maybe even bundled with a certain level of cable service.

First question, if you happen to be doing something like this, what bit rates are you providing.
Second question, though 'real' internet customers all get real IP's, what would you think of doing something like this with 'large scale' nat instead. Understand, we're only talking about basic internet, something like a 256k/96k (or similar) connect, not something that would be used by a serious user. (One thing we are looking at is some older dial up users we still have, most of which could go onto cable just fine but don't want to pay the price).

Also when I say large scale, I doubt I'd have more than a few thousand customers for this. We're not a large ISP/cable company by any means.

In a message written on Fri, Feb 10, 2012 at 03:19:24PM -0600, Eric J Esslinger wrote:

First question, if you happen to be doing something like this, what bit rates are you providing.

Comcast has a program with some of the best marketing around it right
now, their Internet Essentials service: http://www.internetessentials.com/

$9.95/month, 1.5Mbps down, 384kbps up.

Second question, though 'real' internet customers all get real IP's, what would you think of doing something like this with 'large scale' nat instead.

Carriers do not want to run NAT's. You can go read the archives of the
CGN (Carrier Grade NAT) discussions where folks are looking at moving
the NAT into the service provider due to IPv4 exhaustion.

UPNP, NAT-PMP, the ability to enter static bypasses (DMZ's, NAT
passthrough), combined with the problems of some applications that
make thousands of TCP connections in a short order eating up ports
makes it a nightmare to manage and debug. Of course, if they are
doing illegal things you'd better keep some detailed records of who did
what when a LEO comes knocking.

The key to a low cost service is making it as low cost as possible,
moving the NAT inside the carrier will had a huge amount of headache and
support costs, not what you want.

A possibly relevant question with IPv4 exhaustion coming is could you
make this service IPv6 only so you don't have to find IPv4 addresses for
it.

Leo Bicknell wrote:

UPNP, NAT-PMP, the ability to enter static bypasses (DMZ's, NAT
passthrough), combined with the problems of some applications that
make thousands of TCP connections in a short order eating up ports
makes it a nightmare to manage and debug.

The applications can simply be debugged to use socket option
of REUSEPORT.

I pointed it out so along with static port mapping at the last
meeting in "Track: IPv4 runout, Doing More with Less".

Of course, if they are
doing illegal things you'd better keep some detailed records of who did
what when a LEO comes knocking.

Are you saying we MUST record all the IP addresses and
port numbers of all peers of your customers to prevent
illegal things?

If so, we have to do so, even if you are not using NAT,
I'm afraid.

If not and we only have to have information on which
port is used by which customer, static port mapping
is just fine.

Anyway, developers of virus software will be quite
cooperative to use REUSEPORT, to hide symptoms that
the virus software is installed.

The key to a low cost service is making it as low cost as possible,
moving the NAT inside the carrier will had a huge amount of headache and
support costs, not what you want.

Use NAT with static port mapping (and same port numbers are used
in and out), there is no headache and support cost caused by NAT.

A possibly relevant question with IPv4 exhaustion coming is could you
make this service IPv6 only so you don't have to find IPv4 addresses for
it.

IPv6 means considerably more amount of headache and
support costs than using NAT cleverly and simply.

            Masataka Ohta

In a message written on Sat, Feb 11, 2012 at 09:19:46AM +0900, Masataka Ohta wrote:

The applications can simply be debugged to use socket option
of REUSEPORT.

"Simple" is subjective. Keep in mind many users will have a home
gateway which also does NAT. And indeed double NAT in the home (router
doing NAT, third party device doing NAT) is depressingly common. That
means some of the troubleshooting will be via a triple-NAT if the
carrier is performing the conversion.

Are you saying we MUST record all the IP addresses and
port numbers of all peers of your customers to prevent
illegal things?

If the carrier NAT's, maybe.

Today port information need not be stored, because an IP is assigned
to a customer. Law enforcement can come request who was using an
IP, and be given the customer information. It's what everyone has
come to expect.

It's also not just what is legally required, but what is administratively
friendly. Will the law say you have to track ports with carrier
grade NAT, probably not. Will law enforcement spend a lot more
time with your staff trying to track down bad people costing you
time and money if you don't, probably.

Large operations tend to find that having a cost effective and staff
time effective way to deal with law enforcement is very important.

IPv6 means considerably more amount of headache and
support costs than using NAT cleverly and simply.

When IPv4 addresses are selling for $100 an address that equation
changes quickly. That day may be only a few months or years off.

We're toying with the idea of a low bitrate 'lifeline' internet on our
cable system, maybe even bundled with a certain level of cable service.

First question, if you happen to be doing something like this, what bit
rates are you providing.

Well, a lifeline telephone is effectively 64kb/s, up and down. Makes me
remember when I had my first ISDN line and was happy to get beyond dial-up
rates.

Second question, though 'real' internet customers all get real IP's, what
would you think of doing something like this with 'large scale' nat
instead. Understand, we're only talking about basic internet, something
like a 256k/96k (or similar) connect, not something that would be used by a
serious user. (One thing we are looking at is some older dial up users we
still have, most of which could go onto cable just fine but don't want to
pay the price).

Force SMTP to something sane, block all the 139, etc. MS ports. Basic web,
telnet, and ssh. Set it up like a coffee house. Use a proxy and make them
register. It's not like they are chatting 911, ya know. If they have NAT
issues, then they need a real account. If they can get to google,
wikimedia, or what ever a high school student needs to research papers,
then they have what they need for a life-line. Let chat protocols through,
that's low bandwidth. I'm guessing that this is done as a favor to the
customer that won't/can't pay for a real account. But let them know it's
not a real account. This is just to give them a taste of real IP and not a
solution to all their problems. Shove them a NATted DHCP address and if
they can't figure that out then refer them to the local wizkid or a better
plan with support. Let them know up front that this is a basic service and
don't expect phone support. If you're a cable company then they can call
and say the cable is out.

You might also want to think about it's not to far off that the gov starts
supplementing those cost of these users, with all the changes being made
in USF. Possible why comcast has started taking on these users to get a
good head count. Does anyone know with these low end comcast package does
the user still need to pay the $5 modem rental fee?

Carlos Alcantar
Race Communications / Race Team Member
101 Haskins Way, So. San Francisco, CA. 94080
Phone: +1 415 376 3314 / carlos@race.com / http://www.race.com

Leo Bicknell wrote:

The applications can simply be debugged to use socket option
of REUSEPORT.

"Simple" is subjective.

To "the problems of some applications that make thousands of
TCP connections in a short order eating up ports makes it a
nightmare to manage and debug", I gave you an objectively
simple answer.

Keep in mind many users will have a home
gateway which also does NAT. And indeed double NAT in the home (router
doing NAT, third party device doing NAT) is depressingly common.

Double NAT does not make things worse, as long as "static
bypasses" exist, which is your assumption.

OTOH, the double NAT, some of which may or may not IPv6 capable,
makes IPv6 deployment hard, if not impossible.

That
means some of the troubleshooting will be via a triple-NAT if the
carrier is performing the conversion.

The carrier should have a trouble shooting equipment within
its private network, which means trouble shooting over
the double NAT with IPv4 is much easier than with IPv6.

Are you saying we MUST record all the IP addresses and
port numbers of all peers of your customers to prevent
illegal things?

If the carrier NAT's, maybe.

Today port information need not be stored, because an IP is assigned
to a customer.

Wrong.

With your requirement to record IP address of peers, a carrier
must record port numbers of peers of its customer, if some
carriers of the peers use NAT.

Note that there already are carriers who use NAT.

Note also that, recording peers' IPv4 address needs 4Bs,
recording peers' IPv4 addresses and port numbers needs 6Bs
and recording peers' IPv6 addresses needs 16Bs.

Law enforcement can come request who was using an
IP, and be given the customer information. It's what everyone has
come to expect.

That's completely different from recording information of peers
of your customer.

Large operations tend to find that having a cost effective and staff
time effective way to deal with law enforcement is very important.

True. And, see the double NAT example you mentioned.

IPv6 means considerably more amount of headache and
support costs than using NAT cleverly and simply.

When IPv4 addresses are selling for $100 an address that equation
changes quickly. That day may be only a few months or years off.

Sorry, are you seriously saying that paying $100 once for a
customer is so much expense for a carrier?

Even if so, the carrier should deploy NAT, because $100 is
paid only once for hundreds of customers.

Moreover, wide deployment of NAT will further reduce prices
of IPv4 addresses.

            Masataka Ohta