At 09:51 AM 1/20/99 -0600, you wrote:
Using RFC1918 space for this won't work because there has to be some kind of administration of the space to ensure enough uniqueness that no two companies that are visible to any one company have the same addressing. There can be only one such administration of any practicality even though this "closed Internet" is chopped into isolated segments.
Sure it will. It requires (gasp) some COMMUNICATION between the companies involved. I don't know of many companies who between them will completely fill 10.0.0.0/8 with all the machines that need to interconnect. I mean that's a pissload of machines. SIXTEEN MILLION machines.
"Some" communication? It's not an issue of "completely" fill ... it's an issue of logistics. This "communication" you speak of will involve probably thousands of companies when you consider the whole range of all of them that interconnect (even though they don't interroute). Any one of them that already has an established addressing _MAY_ end up connecting to any other of them that already has established addressing. That means this "communication" has to basically implement an entire allocation structure. And every business that is not even yet connected would have to be sure their use of RFC1918 space conforms to this allocation structure. Basically, it's like saying, RFC1918 space will no longer be private address space that can be used on a whim, but instead will now be allocated by yet another entity. It MAY be arguable for some entity to go to ARIN and get a /8 to do just that with. But for now, it works ... AND IS COST EFFECTIVE (something that is a very powrful driving force in business) ... by simply using the existing methods of address space allocation.
Further, many companies with these networks also allow direct access to the real open Internet. That means for sure that addresses in use on the open Internet cannot be duplicated anywhere else. So the allocation of space within the closed network has to be unique even compared to the open Internet.
The best way to do this is with a firewall (companies doing this probably already have one, otherwise their "private" network ain't so private), and just about every firewall worth putting on a box will do NAT. You map individual machines that need their own IP address directly through on a one-to-one relationship, and the rest you let the firewall masquerade through. Conserves "real" IP space.
NAT wasn't a common reliable tool when these things were established. The first of these I remember getting involved in over 4 years ago. It is a little better today, but the good ones are very costly. You will fail to convince the vast majority of these companies to buy an overpriced super firewall that does highly scalable NAT reliably when their needs are met with a low priced router (e.g. Ascend Pipeline 50 to Cisco 25XX scale). Yes, if you were starting this kind of thing today, NAT would probably be the better way to go. But as well all know, business does not just go around spending money to revamp what is currently working fine.
So it makes sense that every company connecting this way must obtain their own unique address space.
No, it doesn't.
You get to describe the model of how to make it work using technology that was available when it was set up, or describe the model of how to upgrade it to what is available today without spending any money.
1. There is not enough space in RFC1918 to assign UNIQUE addresses to each company that interconnects with many other companies, that further interconnect with many others, and on and on.
There's 16,000,000 addresses in 10/8... not to mention the rest of the space. Seems like VERY poor space management if the people involved can't fit in there.
When you trace these interconnects around and include all the businesses that are connected to each other, although not entirely routeable to each other, the numbers become staggering. Now toss in the logistics of assignment and allocation strategies, and the politics of the larger companies demanding big pieces, you eat that 10/8 up in a heart beat. And further, that also makes 10/8 unavailable for actual internal uses for which RFC1918 was intended. And since many such companies already do have RFC1918 in use for the intended purposes, this isn't the space that can be just simply moved in to. I won't disagree that you speak of the ideal way to establish networking. But it does not happen that way when you figure in business processing, financing, budgets, and politics. We're in the real world and it's a dirty place.
2. Even if there was enough space, there is no one doing any administration of such space to ensure that all such assignments are sufficiently unique to ensure that every company connecting to many others will never see two or more such companies using the space part of RFC1918 space.
So the companies come together - once - and allocate space for each other.
Dream on. You have to include _EVERY_ company that might ever do this.
If the companies have such a good relationship that they are allowing people in behind their firewalls and such, then communication amongst them shouldn't be a foreign concept.
They don't all have relations to each other. Company A connects to company B and company C. B connects to D and E. C connects to E and F. D connects to E and G and H. F connects to H and I. Of course company I and company A could use the same block of address space. ....until company A decides they now need to connect to company I. Decide on a strategy that takes this all into account. The only such strategy is for EVERY company that might ever connect to have an address that is totally unique from every other company. That definitely means an allocation agency is required. But why duplicate that when one already exists (which is now ARIN with "agents" being various ISPs that suballocate space). RFC1918 is NOT intended to be a universally assigned unique address space.
Likewise, name spaces also have to be unique, and the NS servers that are authority for them may not be reachable by you or perhaps even anyone else on the open Internet. But that doesn't mean they aren't real and being used by many different businesses.
This is an interesting concept... perhaps there ought to be an RFC1918-like TLD "prv" or something, which is reserved for resolving addesses that will only ever sit on RFC1918 space. Set aside certain addresses in RFC1918 space that the root servers could ostensibly "point" to as being the "official" nameservers for that TLD, ...
Actually, I have used "localhost" as a TLD, as well as "priv". But someone still has to make sure name spaces do not collide over the realm of all businesses that interconnect. InterNIC is currently performing that role whether they know it or not. It's (combined with national TLDs and their registries/ars) the only functioning facility. And most companies do decide that if they are going to pick a name to use in these private backbones, they might as well just get one that is going to be the same on the real open Internet. It makes sense even more so today because most businesses that don't have a web site now are sure they will get one eventually. And the network engineers they contract know this even more so. The only issue is whether they make that name be served on the real open Internet NOW or put it off until the finally get the budget to do the web site (which for many companies won't be until Y2K is past). If some domain you don't have any need to contact has a lame delegation from the root, or simply no known host "www", what's it to you? You can't see a non-existant web site and you can't ping their network, so what does it matter? Why are you even doing what would discover the lame delegation, anyway? I guess that people are just so fed up with speculators who typically do not establish DNS service that they are taking it out on legitimate businesses who register their real names but just don't choose to have the DNS on the open Internet at this time. Fortunately for my customers, we include such DNS services for free with any web site or LAN connection. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* phil at intur.net * --