Incompetance abounds at the InterNIC

Regan, Sharon Sharon_Regan at newcourt.com
Wed Jan 20 18:15:34 UTC 1999


Good Afternoon:

As the network admin in an organization such as described, i.e. a
"semi"-private network communicating with numerous partner companies, as
well as multi-homed to the Internet, I can only agree with Phil Howard's
sentiments.

Whereas early on the thinking may have been that networks were either
"public" or "private", that is truly no longer the case.  In a truly
"private" network, the exclusive use of RFC1918 may very well be adequate;
however a good percentage of major organizations today engage in
internetworking with one another, and therefore the issue of "uniqueness"
within this environment indeed becomes an issue.  And, while net 10
certainly seems to contain a large number of host addresses, the reality is
that establishing the "Use of Net 10 Committees" within these environments
is not workable ... and any agreements established by such committees would
be unenforceable.  Which is why organization's such as mine insist on global
uniqueness.  The distinction between the capital I Internet and large,
international, multi-organizational Intranets is becoming blurred and may
indeed one day not exist.

Respecting the issue of domain registration, it only makes sense to register
a unique domain name rather than simply inventing one ... I've seen
instances where an organization with bosus internal domains renders a good
portion of the internet inaccessible to themselves.

Just my two cents worth. 

Sharon Regan 
Internetworks 
Newcourt Credit Group, Inc. 


-----Original Message-----
From: Phil Howard [mailto:phil at whistler.intur.net]
Sent: Wednesday, January 20, 1999 12:49 PM
To: dredd at megacity.org
Cc: nanog at merit.edu
Subject: Re: Incompetance abounds at the InterNIC


> 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        * --



More information about the NANOG mailing list