From: Tony Rall [mailto:trall@almaden.ibm.com]
Sent: 30. apr�la 2002 19:59
To: nanog@merit.edu
Subject: Re: Large ISPs doing NAT?
> Is anybody here doing NAT for their customers?
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.
well.. yes and no.
depends on definition and how you set the services. i don't know how you treat this in u.s. but in europe gprs is mostly considered being a value-added service to gsm instead of a real internet connectivity replacement.
if you think of gprs a bit it will never have enough capabilities to serve as a full-time inet service. it's a great solution for accessing your data remotely but it's very limited in means of capacity
and then you have those 'pdp-contexts' or how they call it. it's just another acronym for a vpn... if a corporate user requires full ip connectivity then why not give him a vpn uplink directly to their hq and the users can safely use private addresses according to corporate policy. in this way gprs is very similar to mpls. i have worked on gprs-mpls vpn integration and it works just fine.
An Internet Service Provider gives the customer a full
connection to the Internet. All IP protocols should work.
you also may give the [common] user an opportunity to have 'limited' service set (so you can use private addresses + nat/pat) for lower price or pay a bit more for 'full' service. i think the 'limited' in real life can safely cover requirements of 95% of the customers. do you think they will download mp3's and avi's via gprs? how? :)) from my point of view if you cover http, e-mail and various similar services you will provide most user with more than they ever would expect, wouldn't you?
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
deejay
and then you have those 'pdp-contexts' or how they call it. it's just
another acronym for a vpn... if a corporate user requires full ip
connectivity then why not give him a vpn uplink directly to their hq
This is probably impractical -- just try to (consistently) get your DSL
provider to provision multiple PVC's. Technology that's there, been there,
and makes alot of sense, but convincing someone to sell it is still
difficiult.
> An Internet Service Provider gives the customer a full
> connection to the Internet. All IP protocols should work.
you also may give the [common] user an opportunity to have 'limited'
service set (so you can use private addresses + nat/pat) for lower price
or pay a bit more for 'full' service.
Given the fairly common broadband SLA's that deny running any servers, it
almost seems prudent _to_ use NAT for these users. Going NAT rather than
NAPT takes care of almost all cases (AFAIK even more troublesome protocols
such as h323 are commonly accomodated). Besides, it gives vendor C an
excuse to push bigger and bigger PXF platforms.
Given the bellowing over some of the allocations in 24/8 that have been
heard here before, it would seem to be welcome. Sticking large numbers
of unadministered, always-on boxes that aren't supposed to be running
inbound services in unrouted space would save all of us headaches.
do you think they will download mp3's and avi's via gprs? how? :))
Unless I've fallen for marketing ambiguities, even current GPRS handsets
are including PC connectivity for GPRS data, so applications are a given;
though "would you want to" still remains (wouldn't imagine wireless
carriers are rushing to provide scads of connectivity while still nursing
WAP burns).
..kg..
That's almost a better justification for NAT than address-space conservation. 
> of unadministered, always-on boxes that aren't supposed to be running
> inbound services in unrouted space would save all of us headaches.
That's almost a better justification for NAT than address-space conservation.
Almost? I'd say it's hands down an EXCELLENT reason. In some configs
though, the NAT'd people can still see each other and cause problems,
but it still cuts down the exposure.
Almost? I'd say it's hands down an EXCELLENT reason. In some configs
though, the NAT'd people can still see each other and cause problems,
but it still cuts down the exposure.
I've received a couple off-list replies about containment within the
NAT'ed area, but I don't see this being a significant issue, as in order
to make this at all scalable, it would need to be done at a relatively
granular level, ie. directly at customer aggregation router, which would
limit scope a fair deal.
Support-staff debugging may also end up simpler, if for no other reason
that it forces them to go to the edge router to reach the customer
directly, eliminating ill-concieved 'shortcuts'. The benefits to core
engineering teams would be interesting as well, given that public space
becomes genuinely dynamic, even at the edge.
...and as has been mentioned, nothing precludes offering non-NAT as a
premium service, just as the DSL providers have done already w/ offering
/29's or static addresses.
..kg..
As well as perpetuates the neglect for fixing the real problem.
John