Conference gyro::internet_toolss

And so do they want to the whole of each other's network
available?  If not & they can isolate the systems with
shared info, that would simplify matters.

Do you know if they're actually using the same addresses
on each network? Have the subnetted their networks?

If the network addresses don't overlap and/or you can
group the shared servers into one or more defined subnets,
then it should be doable by subnetting & routing.  E.g.
company A uses subnets 10.1.1.0 - 10.50.255.0 mask 255.255.255.0,
company B uses 10.51.1.0 - 10.100.255.0.  However, if the
end systems are configured with a mask of 255.0.0.0, they would
have to change (why does everyone choose network 10?  there
are other class B & C non-routed network addresses which 
would have sufficient address space & be less likely to cause
this kind of conflict).

Has these customers really thought through the implications
of joining the 2 networks?  A cheap solution could prove
rather expensive in terms of security problems, network
address conflicts, etc.  What about a couple of firewalls
and a "shared" rednet (not in network 10), where the shared
information servers will reside?

One client is in charge of their network, and has been using their 10 addresses 
for some time. Changing would be painful.

The other is part of a state network where everybody is using 10 addresses, and 
is not necessarily in charge of their network.

Even if the addresses were mutually non-overlapping, the body in charge of 
client 2 almost certainly wouldn't go to the trouble of rearranging their 
network to allow this. (They've got enough problems of their own.)

Joining the networks is out of the question: they're two entirely different 
administrative and political animals. Having shared servers would be difficult 
for the same reasons: they're significantly separated geographically.

PJDM

Nope,

One of the problems with using RFC1918 (1597) addresses, I'm afraid.

They will have to use address translation gateways, I know, for example, of 
no way of doing this with AltaVista Firewall. 

Cheers,
Stuart

What if they use two proxies in serial for each required connection? The first 
goes from a 10 network to a 192 network, and the second goes from the 192 
network to the other 10 network.

Would that work?

PJDM

Hmm, yes that might work, try it and see.

Stu

|> I have a client who uses 10.*.*.* as their intranet address.
|> 
|> They have a partner who also uses 10.*.*.* as their intranet address.
|> 
|> These two want access to systems on each others intranet.

To a first approximation, they're SOL.  Yes, there are mechanisms for
doing address translation that will do some of what they may want.
However, the choice of using net 10 for their intranets is tantamount
to deciding "these hosts are guaranteed never to talk to any machines
not on our network."  Routers on the Internet are both allowed and
encouraged to drop all packets destined to or from net 10.

If they want to have machines that can be reached from outside, I
recommend a separate part of the intranet on some registered network,
and a router (probably a screening router or firewall) between that
network, which is connected to the outside world (presumably by a
firewall as well), and the net 10 part of the intranet.

--
Ed Gould	  [email protected]		Digital Equipment Corporation
+1 415 688 1309	  Network Systems Lab	250 University Ave, Palo Alto, CA 94301
[posted by Notes-News gateway]

I don't understand how CISCO is able to solve the problem.

I wrote a length reply that represents my evolving thoughts on this problem.
Once I realized that this problem would be easily solved if the systems were
using DECnet (upgrade to DECnet PLUS and then assign multiple addresses to
the systems in each enterprise that needed to talk to each other and then
connect them with an OSI router), I realized that the solution is the same
for this problem.

For the systems that need to talk to each other directly, which would be a
small number of systems, assign a second IP address out of a network which
is distinct from 10.0.  For example, use addresses out of 16.0 (yes, I
intentionally chose DECs net.)  Configure a router to route only net 16 and
provide the necessary physical, or if you virtual networking capability, logical
connections from the systems that need to be in this common network to this
router, and you're all set.

The degenerate case of the above is to have a single system in each enterprise
configured with dual addresses (say 16.1 and 16.2), which eliminates the need
for a router.

The way that you solve the problem generally is to switch to text addresses.
You can do virtually everything with text addresses (URLs) by using proxy
servers.  Standard proxy servers already offer 95% of the services that you
want.

But this just shifts the problem to the naming.

Do these two enterprises have unique top level domains?

And do either of these two enterprises have real internet connectivity, which
would obviously be via a firewall.

This is going to be a long term, and increasingly common problem.

Consider the fact that Digital has spread 2500 /24 nets across a possible 65000
/24 nets which has completely precluded setting up a significant new presence
in a new geography.  (For example, if you consider that Russia has about the
same number of college educated people and a comparable geography, I can easily
imagine that in five years the political climate might allow DEC employing
20,000 people in 100 different locations in Russia.  This would be more complex
than the Eastern States region which is allocated about 500 /24 nets in two
blocks.  Without renumbering systems, we can't expand our IP network into Russia
in any significant way without a signficantly more involved network management.

Can we view the likelihood that the political system in Russia will keep its
people restricted in freedom and restrict our opportunity to grow as a company
as a blessing?

The Cisco PIX box uses "True Network Address Translation as discussed in RFC 
1631".

By the time we expand that much into Russia, we'll have IPv6 and the problem 
won't exist.

PJDM

>By the time we expand that much into Russia, we'll have IPv6 and the problem 
>won't exist.

Fifteen years ago I attended a presentation on Phase V; one of the topics
discussed was the feasibility of running link state routing on RSX-11M.
Phase V has been available foe all the operating systems deemed critical
to Digital today for 3-6 years depending on whether you think that VMS is
a critical operating system.  (unix support goes back a long time.)

The major obstacle to deploying Phase V is the robustness of DECdns, which
is at V2 of the protocol because of the problems scaling to DEC's network.

IPv6 proposes a similar update to the directory service; ie., dynamic address
registration and updating, enhanced security, replication, etc.  In my judgement
the work in this area isn't as advanced as DECdns was a decade ago.  Of course,
one might argue that Internet time will result in a faster resolution, but
that is likely to be done by a shoot out between Oracle/Novell and Microsoft???

Personally, I sure hope that we are doing a lot of business in Russia before
IPv6 is be deployed internally.