(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)