|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Incompetance abounds at the InterNIC
:: Derek Balling writes ::
>
> 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.
In 1994, my employer has WAN connections to one external company. We
now have about 17 such connections. Most of the 17 companies are
engaged in some form of work for my employer. All 17 had networks prior
to the time the sold, or even attempted to sell, their services to my
employer. So, they all designed their networks completely unaware of
each other, but it is now all essential that all 17 have IP unqiue IP
addresses, because they all connect to my employer, and I can't route
the same IP address to two places. Most of these 17 companies, even
today, are unaware of the existance of the other 16.
Furthermore, many these 17 companies all have WAN links to some of
their other customers. And those other customers have WAN links. And
so on. In fact, it would be interesting to see what percentage of U S
industry is reachable from my employer without traversing any portion
of the public internet -- I would guess it's rather large.
(Hypothetically speaking -- obviously, none of these 17 companies are
providing any form of transit for my employer, and my employer is
providing no transit for them -- I'm just guessing that by following
private WAN links and assuming complete transit, I could get damn near
anywhere in the country, and probably a lot of places overseas. The
point being that you end up needing to coordinate usage of 10.X.X.X
over just about the whole world.)
Just as an example, do you use any RC1918 space internally? Are you
sure that you will never need to connect to my employer? If not, are
you sure that your RFC1918 addresses don't conflict with mine? (I use
RFC1918, but only for strictly internal stuff. Not for anything that
anybody external to my employer will ever need to contact, even via
private WAN links).
> 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.
Would you like a list of protocols that I need to support that don't
NAT? :)
How are you going to deal with the fact that this would effectively
make servers (not just clients) appear as different IP addresses
depending on where the client is located? Are you suggesting that I
should run 17 different DNS's. Or provide hacked zone files to
everyone I connect to, and load the hacked zone files they provide me
on my DNS?
> >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.
OK. Let's say you need to implement some 10/8 space tomorrow. How do
you plan to coordinate with everyone you will ever connect with?
> So the companies come together - once - and allocate space for each other.
> 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.
I allow no one behind my firewall. But I won't NAT. (Some stuff I
need to run doesn't NAT, although I probably wouldn't NAT even if it
did). And I won't run hacked zone files. And I won't run separate
DNS's for everyone who wants to connect to me.
But even if I did allow other companies with whom my employer has a
good relationship in behind my firewall, I cannot predict today every
company that my employer would ever have a good relationship with.
> 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, ...
Hmm. An excellent idea. It wouldn't even necessarily have to just be
for 1918 space. Just some name space that is guaranteed to never
become a tld in the public internet.
- Brett ([email protected])
------------------------------------------------------------------------------
... Coming soon to a | Brett Frankenberger
.sig near you ... a Humorous Quote ... | [email protected]
|