Adam D. McKenna wrote:

: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.

You don't sound very sure of your arguments. To which thousand companies are you referring?

Maybe it's my American accent that makes me sound that way? I don't need to know the thousands of companies by name. I do know that one of my customers simply had no choice but to use real external addresses because of the requirements of the companies they connect to. I do know that two major automobile companies are involved, as well as several large corporations they do construction work for. In addition, there are over a hundred sub-contracting companies they connect to.

: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.

Usage of RFC1918 space shouldn't be determined by "whims", it should be planned just like anything else at a company is planned, and it should be accounted for.

In a big company, certainly. In my previous job, that was my role. In a real small company, "planned and accounted for" == "whim". But the issue with RFC1918 is whether or not a company should be able to use those RFC1918 addresses internally, and in such a way that will not conflict with the external connections they have to other companies. This is something that RFCs have failed to address and I don't think they ever can. But I could be proven wrong by one that does whenever someone works out a solution to the problem. Of course at this late date, such a solution would not see the light of deployment for a long time thereafter (which is the same problem that keeps NAT from being there now, though it is slowing going into place).

There was a discussion of low-priced high-capacity NAT solutions a few months ago on NANOG, I'm sure if you look in the archives you will find it.

Were they there 4 years ago when the approach now in place was initially decided on? NAT is being deployed, but business does not just go changing things that currently work, so it usually goes into new remote offices and new subnets.

: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.

That's fine. As long as they don't mind spending time and money renumbering their entire network once it gets connected to the internet.

That's my point. With real addresses, it addressed the issues of having to renumber when new business interconnections were made, or when any of them decided to get on the Internet. NAT was not viable then, as it is today. NAT didn't make it to the sudden growth party, unfortunately. In fact I still have cases of customers we initially put on NAT only to find too many problems and end up giving them a /28 or something which makes things work just fine. I suspect the Ascend Pipeline NAT is buggy, but I just don't have the time to diagnose it. It costs less to number them on a real address block than to deal with wanna-be-techies on phone tech support.

: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.

RFC1918 is entitled "Address allocation for private internets". I think it describes exactly what you are talking about.

Nope. It completely misses. There are TWO separate concepts here: 1. Private internal networks that do not go outside of a given company. 2. External networks that connect between companies, and have at least some addresses (NAT would help keep these to a minimum) that other companies (not necessarily all of them but you never know) need to see UNIQUELY. #1 is what RFC1918 is for, and #2 is the case where RFC1918 won't work and real addresses (or some other solution) is needed. If you do try to use RFC1918 for #2, then you break it for #1 ... or rather, those businesses that do use RFC1918 for #1 cannot use it for #2.

:Dream on. : :You have to include _EVERY_ company that might ever do this.

Not really. Companies do not usually route their entire corporate network to each other. When one company wants to connect to another, all they need to do is come up with one or two common subnets that neither company is using at that particular time, and only route between those IP's. That way, it doesn't matter to company A what company G which is two "corporate hops" away is doing.

No, but they have to route enough of it. NAT would help today but it was not available when this common practice went into place. But it is gradually coming into place. It won't make a sudden entrance because that is not how business works. Company A and company G will matter to the company inbetween those two hops. That middle company (company C) wants company A and company G to have different addresses. That's easy if there are just 3 such companies. Now when company A connects to company X and company G connects to company Y the problem grows exponentially. Eventually ... and soon ... it gets to the point you just need a central address space allocation administration for all of it. That's where the use of real addreses took hold a few years ago. If that were just starting today, then definitely NAT would be the big thing to go with to keep the space usage small. But some of the issues would stil exist even with NAT, such as a central administration of the addresses of all the routers and firewall boxes so that no two firewalls have the same address. You still can't take RFC1918 for that because it still breaks RFC1918's intent which is for internal networks that need to be directly addressable at the firewall which also needs to see unique external nets, too. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* phil at intur.net * --