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