ISP and NAT (question and some thoughts)
John Todd
jtodd at loligo.com
Tue Oct 19 06:02:15 UTC 1999
(This rambling monologue may not have much to do with new twists on
tunnelling, IPv6, or header compression. It's simply discussion on
possible uses of NAT from a provider's standpoint.)
Alex -
The use of NAT as a provider-wide scheme for address allocation is
certainly a _technical_ possibility in many simplistic circumstances,
but it remains to be seen if customer service and education can scale
with such an undertaking.
In your "Classical" customer/ISP description (far below here in the
original post,) there is a well-understood concept: packets leaving
the enterprise (note: I didn't say "desktop") have the same IP
address through the upstream and the "Internet" as far as the
customer can tell. The use of NAT by parties who are external to the
enterprise is unsettling at the least, and completely confusing at
the worst. If the customer wants to debug or examine how packets are
getting from the desktop to a destination, the common assumption is
that when a packet leaves the enterprise it should get to the other
side of the connection unmolested. With NAT done by the upstream,
this is no longer the case. Debugging becomes more complex, and
current clue value of most IS managers is barely up to the point
where straight "textbook" TCP/IP problems are diagnosed correctly.
Granted, we don't live in the "end-to-end" world that used to be
true, but NAT really shakes the world of the easily confused.
This is not to say that the exclusive use of NAT by an upstream is
impossible, certainly. I've even suggested (not seriously) that a
super-low-budget ISP could survive with NO IP addresses at all save
those on it's externally-facing interfaces (private or public peers).
With the advent of large web-hosting and email outsourcing shops,
it's thinkable (though extremely farfetched) that connections from
office LANs would be complete NAT'able with no inbound traffic to
"servers" at all. Look at AOL; they have not gone to that extreme,
but their ratio of users-to-IP addresses is astronomical.
I have actually configured an entire ISP (a small cable modem shop
in the US) to run through NAT, which worked quite well in practice to
start but in the long run failed due to lack of an educational arm to
instruct internal and external customers on the process. Customers
were given a /24 automatically out of 10.0.0.0/8, with the first
three IP addresses in the range being "statically" mapped through NAT
into another block of addresses that I cut up into many small
portions. This allows for web, mail, and whatever other services to
be housed at the customer site - most customers didn't have more than
three servers on-site. The fourth address in the range was used for
NAT overload on "outbound" connections. Thus, an entire typical
office with all services and 40 desktops were using 4 IP addresses
with no special equipment or configurations. The NAT functionality
actually occurred in the ISP router at the border between the
customer and the core - this is the only way to make multi-path core
networks work easily ( or at all?). The customer understood the
concept of a /24 being "given" to them, and the education process
was: "All servers on .2, .3, and .4 - anything else is wherever you
want. If you need more addresses for servers, just ask. If you need
more addresses for desktop machines, just ask." Customers no longer
required NAT devices themselves, and could get as many "addresses" as
they wanted from their upstream. The address registry
(ARIN/RIPE/APNIC, whoever) is happy since there is almost 100% usage
of granted address space. Inverse and forward nameservice was easier
(less changes) but no longer could rest in the customer's hands
unless they understood exactly what was going on (for forwards.)
In theory, this method above works quite well. However, in
practice, this requires an installation team and customer service
staff who know exactly what they're talking about, and who can relay
these ideas to the customer. NAT is still not as widely taught and
understood as it needs to be, and inspires Fear, Uncertainty, and
Doubt in administrators who are fresh out of the "Windows TCP/IP For
Admins" classes. Overload NAT also still presents a problem for
those people who want to "temporarily" run a server on their desktop,
and don't understand why someone at ISP B can't see 10.3.39.45 ("But
my Network Settings says that's what my address is!") NAT on this
scale fails due to customer apprehension and inability for NAT to
automatically find "services" for static mapping requirements (e.g.:
temporary web server on a machine that is normally just a "client".)
NAT also fails if load-sharing is required across multiple outbound
providers, but that is a complex enough configuration that I could
probably say that upstreams should not use NAT on downstreams who are
multi-homed. DNS is still problematic due to where you place the
resolver, but that is not an insurmountable obstacle and simply
requires thought during design. Also presenting a problem is the
speed at which the NAT box can create sessions, but that is a
hardware/software design thing that I'll blissfully ignore at the
moment. ;)
Summary: Provider-wide NAT a great idea (IMHO), scales well, and
covers many of the stumbling blocks that ISPs are hitting today with
address conservation. It also provides a modicum of security for the
end user's workstations since NAT overload is one-way (don't confuse
"some security" with "secure"). I would not suggest it for those
that do not wish to hand-hold their customers through the learning
curve. (Remember when customer routers started to use classless
addressing? Same learning process, but... worse.)
I don't particularly like the idea of having the provider's
software learn about open or public services, as you describe below.
I'm uncertain on how that would work (even with DNS tricks) and I
think it would probably be better to just have a web page that allows
customers to configure their NAT sessions via that mechanism, so that
static and dynamic assignments could occur via a push from the
customer.
JT
>Today we see the classical schema ISP/customer; this means
>- the customer have his own address space, requested by him (directly or
>undirectly)
>- due to the lack of public addresses, the customers are forced to use
>NAT; just NAT provide some extra security
>- ISP do not provide NAT themself; NAT configuration is not easy task and
>cause a lot of headache for the customers (just as a lot of money they pay
>to the network admins).
>
>First question - is this picture right or it is wrong?
>
>The second question. What prevent the _future ISP_ from some another
>schema, when:
>- the customer always use the private address space, for example,
>10.0.0.0/8;
>- the provider bother about address translation, just as about name
>translation (DNS re-writing), just as about the address allocation (not
>the customer but the provider - if existing address space is not enough);
>- the providers's software learn about _open, or public_ services which
>must be translated statically, from the customer using (for example) DNS.
>
>Don't answer _it's too slow_.
>
>This is my attempt to predict where we are going this days. Today the
>_know-how_ the customer should know is too huge - if (if I am the admin of
>the company, not ISP!) I open electronic
>market or want to get Internet for the companies employees, I must
>allocate space (why? What for? It's not my concern, if we think a little),
>I must prove I need this addresses (why? This is my business how much
>addresses I need internally; and let's software decide how much addresses
>I need externally), and I should configure firewalls and NAT's. We used to
>think about it as about the normal admin's knowledge; but why we are sure
>it's normal. If you got a car (in USA, not in the Russia), you don't
>bother about the oil stations or about the roads - you just use it.
>
>This is not really a dump question. If it is possible to build such
>Internet service when every customer should be free to use any address
>space in the hidden way, and ISP (not the customer) bother about the
>global address and name translation, we should have just this hierarchical
>address schema IPv6 offer to us. On the other hand, it means a great
>increase in the NAT engine.
>
>
>Aleksei Roudnev, Network Operations Center, Relcom, Moscow
>(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095)
>230-41-41, N 13729 (pager)
>(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
More information about the NANOG
mailing list