|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Incompetance abounds at the InterNIC
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 * --
|