Hello,
I would like to know if any service providers have built their access
networks out using private IP space. It certainly would benefit the
global IP pool but it may adversely affect users with special
applications. At any rate, it sounds like good fodder for a debate.
Regards,
Christopher J. Wolff, VP CIO
Broadband Laboratories, Inc.
http://www.bblabs.com
90% of our customers all use private address space. We only give out
real address space to customers that have servers that need to be
visible. We run NAT on several customer facing routers.
Cool stuff we can do is setup PPTP VPNs on the same router to give
people "access from home" to their LAN. Same with L2TP/ILEC DSL.
Problems include:
We have a big nat pool on each router. If some twerp customer gets
infected with some windoze crap, tracking it down can be a bit more
work.
Until recently, the IOS could not take huge volumes of NAT without
tossing it's cookies from time to time.
We have been toying around with VRFs & NAT which was recently introduced
in the IOS, and it appears that in a NAT situation, the VRFs "leak"
between each other, which scares the crap out of me. We are going to
wait for a couple of revisions of the IOS before looking into that
again.
Dan.
"Christopher J. Wolff" wrote:
On Wed, Jun 04, 2003 at 12:51:51PM -0700, Christopher J. Wolff quacked:
Hello,
I would like to know if any service providers have built their access
networks out using private IP space. It certainly would benefit the
global IP pool but it may adversely affect users with special
applications. At any rate, it sounds like good fodder for a debate.
I've got a friend who puts all of his internal servers,
routers, and _customers_ on RFC1918 space and pipes them out
thrugh a PNAT. Fairly small ISP - maybe 15 megabits of bandwidth -
operating at the state local level.
It's an interesting setup. Kind of fun. The stateful pnat
functionality forces customers to specify exactly what inbound
services they want, which can't hurt security. Every customer
gets a /24 or greater, which helps convenience. On the other
hand, everyone has a NAT in front of them, which means that
they get clients who would have probably been putting a NAT
in front of themselves anyway. I probably wouldn't use that
setup myself, but then again, I subscribe to nanog...
-Dave
Christopher J. Wolff schrieb:
Hello,
I would like to know if any service providers have built their access
networks out using private IP space. It certainly would benefit the
global IP pool but it may adversely affect users with special
applications. At any rate, it sounds like good fodder for a debate.
I do know of a fairly big Italian ISP who's using that kind of setup, afair. It's www.fastweb.it
Their users are having big troubles connecting to IRCnet, that's why they wanted to link their own Server. That's one of the disadvantages of that kind of setup.
regards,
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
My first hop beyond my border for my home connection is a 10-net
address. Provider is RoadRunner. So, yes, ISP's are using RFC1918
space for access networks, which probably also has some bearing on
the recent thread regarding the frequency of attempted lookups of
RFC1918 in-addrs.
- --
William S. Duncanson caesar@starkreality.com
The driving force behind the NC is the belief that the companies who
brought us things like Unix, relational databases, and Windows can
make an appliance that is inexpensive and easy to use if they choose
to do that.
- -- Scott Adams
ISPs that provide RFC1918 space should also provide recursive DNS services
that would stop all RFC1918 in-addrs before hitting root-servers and
guidance to their users so they do the same on their servers if they don't
forward requests to the ISP recursive resolver.
Rubens
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
One would think so, wouldn't they? It seems, however, not to be the
case.
- --
William S. Duncanson caesar@starkreality.com
The driving force behind the NC is the belief that the companies who
brought us things like Unix, relational databases, and Windows can
make an appliance that is inexpensive and easy to use if they choose
to do that.
- -- Scott Adams
Why on earth would you do anything other than push NAT responsibility to
the end-user CPE?
So you can do the aforementiond "cool stuff"?
Andy
More stuff to manage if we push it out to the CPE.
I know this is mean to say, but most customers are STUPID and keeping it
centralized reduces our support load. Give them enough rope, they hang
themselves. We used to do lots more on the CPE, but between bad power
supplies, lost passwords, software upgrades, "power users", etc. we find our
time is better spent managing it all centrally.
Also, customers might exist in several locations, we can give them the same
1918 network in all locations, run NAT for them, do VPNs for them, bring
L2TP DSL into the fray, and only bill them for traffic that goes "out to the
Internet" quite easily.
(apologies to vendors watching) but I really think this "push intelligence
out to the edge" concept is entirely vendor invented to sell more stuff.
There are more edge devices than core devices.....
Dan.
Andy Dills wrote:
On Wed, Jun 04, 2003 at 12:51:51PM -0700, Christopher J. Wolff quacked:
>
> Hello,
>
> I would like to know if any service providers have built their access
> networks out using private IP space. It certainly would benefit the
> global IP pool but it may adversely affect users with special
> applications. At any rate, it sounds like good fodder for a debate.I've got a friend who puts all of his internal servers,
routers, and _customers_ on RFC1918 space and pipes them out
thrugh a PNAT. Fairly small ISP - maybe 15 megabits of bandwidth -
operating at the state local level.
Why on earth would they do this? What you've said implies DS3 level
connectivity, so to skimp on ARIN fees seems a little ridiculous.
It's an interesting setup. Kind of fun. The stateful pnat
functionality forces customers to specify exactly what inbound
services they want, which can't hurt security.
It doesn't help security any more than a standard firewall or filter
would. And even then, you'd have to retrain your customers to stick them
behind a firewall. Hell, even without filtering packets towards our
customers, I get three or four tickets a week escalated to me because some
user has been told by some other vendor that we must be filtering packets
because they couldn't get blah blah to work.
Every customer gets a /24 or greater, which helps convenience.
If you say so....
The customer can already achieve this by utilizing NAT themselves.
Convenience is impared by having customers who can't get VoIP, VPN or
Quake to work. Sure, that can be addressed, but this plan is not one with
convenience in mind.
On the other hand, everyone has a NAT in front of them, which means that
they get clients who would have probably been putting a NAT in front of
themselves anyway. I probably wouldn't use that setup myself, but then
again, I subscribe to nanog...
Yeah, I read you loud and clear. "My friend is a half-baked cluebie using
techniques I'll term fun and later encourage my competitors to employ". 
Using a technology because it's "possible" is the single stupidest
rationale, probably resulting in almost as much downtime as sheer
incompetence.
Andy
Date: Wed, 4 Jun 2003 17:56:15 -0300
From: Rubens Kuhl Jr.
ISPs that provide RFC1918 space should also provide
recursive DNS services that would stop all RFC1918 in-addrs
before hitting root-servers and guidance to their users so
they do the same on their servers if they don't forward
requests to the ISP recursive resolver.
s/that provide RFC1918 space//
Recursive resolver? No. AS112 anycast authoritative.
Eddy
More stuff to manage if we push it out to the CPE.
I know this is mean to say, but most customers are STUPID and keeping it
centralized reduces our support load. Give them enough rope, they hang
themselves. We used to do lots more on the CPE, but between bad power
supplies, lost passwords, software upgrades, "power users", etc. we find our
time is better spent managing it all centrally.
Well, wait. You either manage their router or you don't. I'm not
following...so in your new setup where YOUR routers manage NAT, you now
refuse to fix a problem on the CPE? If you manage the router, so they
don't get a password, then do NAT there, at the CPE. If you don't manage
the router, not having NAT on the CPE does nothing for you anyway, you
still have the issue of stupid users breaking things.
Also, customers might exist in several locations, we can give them the same
1918 network in all locations, run NAT for them, do VPNs for them, bring
L2TP DSL into the fray, and only bill them for traffic that goes "out to the
Internet" quite easily.
Why would you want to only bill them for the egress bandwidth? You should
be finding reasons to make that impossible, not the other way around. You
running a non-profit over there? You seem to assume a network with a
single NOC...I don't want to pay to backhaul Joe's file and print sharing
between states so that he won't have to.
As for the other reasons, still not convinced. This isn't as whacky as the
guy who runs his entire ISP behind a NAT box, but I still don't see what
efficiency you've created. The things you mention could be solved in other
ways.
(apologies to vendors watching) but I really think this "push intelligence
out to the edge" concept is entirely vendor invented to sell more stuff.
There are more edge devices than core devices.....
How do you figure? The customer needs a router, period. Whether or not you
do NAT on your router or their router should be a function of how much
other stuff your router does.
If the customer needs a router regardless, there are no more devices being
sold.
If you have to fix CPE problems unrelated to NAT _anyway_, why create
potential problems at your edge (let's set ourselves up for a multi-day
outage for most of our high-margin customers!) by doing the NAT for them,
when you could push that to their router?
Hell, unless there is a DOS underway, we make our customers filter there
own packets too. Why? That's the way it should be done.
I'll repeat your last sentence: "There are more edge devices than core
devices"...yes, and more CPEs than edge devices. That's hierarchy at
work...the point is that "work" (anything other than forwarding packets)
must be pushed as far away from the core as possible.
Furthermore, there's a general principle of "easy to manage, easy to
break" at work here. Implement NAT in one box, if NAT breaks, every single
customer attached dies. Implement NAT in one box for each customer, and if
NAT breaks, a single customer dies.
Andy
Date: Wed, 04 Jun 2003 18:48:01 -0400
From: Dan Armstrong
I know this is mean to say, but most customers are STUPID and
keeping it centralized reduces our support load. Give them
I'd almost go so far as to say most providers are stupid. "It
hasn't bitten yet, so it must be okay" is very common.
Ingress filtering of downstreams? Spoof protection for routers?
Separate ethernet segments? Ha. Just how "centralized" should
public address space be?
enough rope, they hang themselves. We used to do lots more
on the CPE, but between bad power supplies, lost passwords,
software upgrades, "power users", etc. we find our time is
better spent managing it all centrally.
And you can't do this with non-RFC1918 addresses?
Also, customers might exist in several locations, we can give
them the same 1918 network in all locations, run NAT for
them, do VPNs for them, bring L2TP DSL into the fray, and
only bill them for traffic that goes "out to the Internet"
quite easily.
And you can't do this with non-RFC1918 addresses?
Eddy
We used to do NAT for DSL customers as well. We started with two T1's to
Verizon, Cisco 3620 for DSL only and had problems here and there (couldn't
stop packets between customers in the same bridge group, such as netbios
broadcasts but could ACL tcp/udp connections between them easily.) We
switched to a Riverstone 8600 with an ATM DS3 from Verizon, moved everyone
over, and now don't do NAT for our customers at all. We provide the
customer with an ATM DSL Modem (Verizon provides Westells with ethernet &
USB.) Residential users are self-install almost always, except those that
want to pay a decently high install charge. Business users are always
charged a high enough install charge to do one quick wire drop or extension
& once DSL is verified operational, everything else is charged $85/hr. We
don't provide nor install a router for customers flat fee, only our regular
rate. When (not if) their $65 Linksys NAT Router has fits and overheats or
they touch it and it breaks, they pay a service charge to fix the problem.
By doing NAT ourselves, customers didn't need a router and thus did not need
us to provide any onsite networking services. Our consulting income has
increased noticeably since we don't do NAT and require customers to provide
their own NAT Router if they want one.
Why am I telling you this? If you're doing NAT for your customers,
providing vlan's across multiple DSL circuits to create an effective vlan
between offices, or doing all of the services for your customers on YOUR
router, you don't get to charge them for selling them hardware VPN routers
and configuring a VPN between them all. Business like buzzwords like VPN,
firewall, encryption & NAT, and they're more than willing to buy a $200
snapgear or $800 PIX 501 (w/3DES) to have their onsite firewall that
encrypts all data across their DSL circuit through a VPN tunnel to their
other offices, EVEN though it's going through the same router on your end
and on it's own VLAN where other clients can't possibly see it, AND you're
doing NAT for it so the outside world can't see it. Doesn't matter, you
MAKE NOTHING if you do it all on your router. You still get to manage their
router, firewall, whatever AND you get paid for it, AND you sell more of
them (one per site)
I know I don't run a non-profit and finding out that your customers don't
expect you to (at least most businesses 
) is a nice thing.
William
Push it out even further.
John
On Wed, Jun 04, 2003 at 07:07:28PM -0400, Andy Dills quacked:
>
> I've got a friend who puts all of his internal servers,
> routers, and _customers_ on RFC1918 space and pipes them out
> thrugh a PNAT. Fairly small ISP - maybe 15 megabits of bandwidth -
> operating at the state local level.Why on earth would they do this? What you've said implies DS3 level
connectivity, so to skimp on ARIN fees seems a little ridiculous.
Historical accident in many ways. I implied DS3-level
connectivity, but what it really means is multiple bonded
T1s from multiple providers. It started out as a T1 from
here, a T1 from there, and no local BGP knowledge (and
discouragement from the upstreams). In fact, using a bunch
of NATs is a great way to resell cheap upstream connections.
Yeah, I read you loud and clear. "My friend is a half-baked cluebie using
techniques I'll term fun and later encourage my competitors to employ".
Actually, I do mean the fun part. You can do some cool tricks with
it. Renumbering to different providers is mostly seamless,
particularly since he runs the DNS for his customers. Easy to
experiment with throwing transparent caches and things like that
in front of the customers since they're already going through a
firewall. Now that he's about large enough to get ARIN space, the game
is changing, and they're moving in the directions one would expect
them to.
It's not an approach that I would ever encourage a large ISP
to take. In fact, I don't necessarily think of him as providing
standard "Internet" services - he provides primarily web, mail,
and VPN services, and then some customized stuff on a per-customer
basis. But he's had a decent customer base for a small ISP, and
he seems to be filling a niche, and hasn't gone out of business
doing it.
-Dave
Hello,
I would like to know if any service providers have built their access
networks out using private IP space. It certainly would benefit the
global IP pool but it may adversely affect users with special
applications. At any rate, it sounds like good fodder for a debate.
Those who use 1918 space are apparently not interested in communicating
with the Internet. I regard this as grossly off-topic for NANOG.
Granted; there might be some ratification for 1918 space in OOB or
control plane networks, but on customer-facing interfaces it is a
no-no, and should be discouraged with some vengeance.
If somebody were trying to sell me a NATed connection and calling
it "Internet connectivity" I'd talk to the proper government authority
about fradulent behaviour.