X-Envelope-to: NOVELL@SUVM.BITNET
X-VMS-To: IN%"NOVELL@SUVM.BITNET"
X-VMS-Cc: JRD
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Newsgroups: bit.listserv.novell
Date:         Mon, 5 Oct 1992 18:12:24 -0600
Reply-To:     Novell LAN Interest Group <NOVELL@SUVM.BITNET>
From:         Joe Doupnik <JRD@USU.BITNET>
Subject:      Re: IP Tunneling - max # servers? WHY?

>
>In article <9210051410.AA15720@chaos.tci.com> Novell LAN Interest Group
><NOVELL@SUVM.BITNET> writes:
>>> And at least the protocol is well-defined. I'm talking
>>> about when someone brings up a server, and another server across town
>>> goes down, because they picked the same IPX network number. There's
>>nothing built into IP that makes network numbers unique - except for
>>central control. If you had central control of NetWare numbers, this would
>>never happen.
>
>Fine, but there _is_ no central control!  It's all very well saying
>"You should have set up a central authority in 1985", but sometimes
>it's hard (politically) to do that, and sometimes you have people who
>started off independent and then want to plug their system into your
>WAN. With IP tunnelling you can be sure that you are totally protected
>from anyone doing this.
>
>>> Of course, if Novell produced readily accessible technical documentation
>>> of their networking protocol (to the level of IBM's SNA, or at least to
>>> that of TCP/IP), there wouldn't be so much of a problem. The more one
>>> has to guess, the more one wants to be protected from the dumb guesses
>>> of other people.
>>
>>Now, that's a non-sequitur. Knowing the workings of IPX or NCP doesn't help
>>in picking network numbers, nor does it protect you from mischievious
>>packets.
>
>I'm not asking to know the workings. Indeed, I don't want to have to
>deduce a "set of rules that will make everything work ok" from the
>low-level protocol description.  What I want is a _high-level_ description
>so that I can say "I have such-and-such a network - is Server A visible
>from stations attached to Server B, with the local bridge filtering
>such-and-such a range of packets?" or "what do I have to tell this person
>so that their LAN is _guaranteed_ not to cause problems for ours?"
------------------
        Without meaning to bring such a nice warm discussion to an untimely
end by suggesting a high level system to organize all this without actually
doing very much, but may I suggest such a system?
        Your IP machines don't squabble over IP addresses because you have
a local Responsible Person to hand out IP addresses. Fine. Let's use the
same person to hand out more IP addresses, one for each NW server port, and
then make the Novell names and numbers track those. Put the IPX traffic on
the backbone, or get all up tight about it as you see fit, but this eliminates
the creativity part of your worries.
        This scheme is the one in place in the State of Utah, designed for
connecting arbitrary installations which have never heard of each other and
don't wish to change. Give me until tomorrow to finish the cover note on
this then look on netlab2.usu.edu (a NW 3.11 server btw) in directory misc
for file NETNAME.TXT. This will hold the cover note and a Postscript picture
of the rules and examples; it's ok if you read the picture first.
        I think you will want to adopt this self administering system because
managing an IP tunneled one is a nightmare.
        Joe D.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU