-----Original Message----- 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?
On Monday, 2002-04-29 at 08:43 MST, Beckmeyer <beck@pacbell.net> wrote:
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 -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first.
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..
On Tue, 30 Apr 2002 12:13:11 PDT, kevin graham said:
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.
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. ---- Presumably, the people it would cause problems for would be the customers of someone getting paid to care about them. :) Deepak Jain AiNET
On Wed, 1 May 2002, Deepak Jain wrote:
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..
On Wed, 1 May 2002 11:00:01 -0400 (EDT) mike harrison <meuon@highertech.net> wrote:
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.
As well as perpetuates the neglect for fixing the real problem. John
participants (6)
-
Daniska Tomas -
Deepak Jain -
John Kristoff -
kevin graham -
mike harrison -
Valdis.Kletnieks＠vt.edu