<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.10.1">
</HEAD>
<BODY>
You are right on target with vocabulary Barry, mine has been sloppy.<BR>
Allow me to try to bring clarity?<BR>
<BR>
On Tue, 2006-07-25 at 14:53 -0400, Barry Siegfried wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">["George (Skip) VerDuin" <<A HREF="mailto:k8rra@ameritech.net">k8rra@ameritech.net</A>> wrote]:</FONT>

</PRE>
</BLOCKQUOTE>
>SNIP<
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">> Take tun configuration as a jnos example.</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> Maiko and I had significant conversation a long time ago that resulted</FONT>
<FONT COLOR="#000000">> in:</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> [host ip 192.168.1.32]</FONT>
<FONT COLOR="#000000">> [autoexec.nos]:</FONT>
<FONT COLOR="#000000">> ip address 44.102.132.20</FONT>
<FONT COLOR="#000000">> ifconfig tun0 address 192.168.2.1</FONT>
<FONT COLOR="#000000">> shell ifconfig tun0 192.168.1.249 pointtopoint 192.168.2.1 ...]</FONT>
<FONT COLOR="#000000">> adopted as a go-by for configuration.</FONT>
<FONT COLOR="#000000">> It works just fine - it introduces two "</FONT>new network identities<FONT COLOR="#000000">".</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> On the other hand tun may successfully be configured as:</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> [host ip 192.168.1.32]</FONT>
<FONT COLOR="#000000">> [autoexec.nos]:</FONT>
<FONT COLOR="#000000">> ip address 44.102.132.20</FONT>
<FONT COLOR="#000000">> ifconfig tun0 address 44.102.132.20</FONT>
<FONT COLOR="#000000">> shell ifconfig tun0 192.168.1.32 pointtopoint 44.102.132.20 ...]</FONT>
<FONT COLOR="#000000">> This configuration uses the "</FONT>broader <FONT COLOR="#000000">n</FONT>etwork <FONT COLOR="#000000">i</FONT>dentity"<FONT COLOR="#000000"> on each end of the tun device.</FONT>
<FONT COLOR="#000000">> Both stacks do get the appropriate route configurations and ping works</FONT>
<FONT COLOR="#000000">> fine.</FONT>

<FONT COLOR="#000000">Generally, if ICMP works, so will everything else that rides under</FONT>
<FONT COLOR="#000000">IP.</FONT>

</PRE>
</BLOCKQUOTE>
>SNIP<
<BLOCKQUOTE TYPE=CITE>
<PRE>

<FONT COLOR="#000000">The tun "device" is just like any other interface and can take on</FONT>
<FONT COLOR="#000000">its own network "identity" with its own IP address.</FONT>
</PRE>
</BLOCKQUOTE>
OK - you are herein focused on the crux of my issue: When MUST (not "can take on" as above) a separate "identity" be established?  <BR>
<BR>
I can answer the obvious in the example when one host must support two "telnet servers" and not having the option to use a special port#, then two IPs must be established.  This is easy under unix-like platforms with two stacks and tun connecting them.  Telnet #1 on the 192... net from host platform and telnet #2 on the 44... net from jnos both using the same port# solves that configuration.  Is it equally easy under the DOS platform with one stack?  Now I suppose the server start command (or config file) needs to specify the IP to service in order to make the answer "yes"...  DOS is basically simpler because there is no need for the tun device?<BR>
<BR>
However the education I'm looking to acquire is not with the obvious - and may be seen in the above example detail of tun configuration.  Above I make the deductive observation that ping actually works under both varieties of configuration.  But I'm working toward documentation of jnos applications and deductive reasoning is not adequate - inductive reasoning is.  My logic works a little like this:  Example 2 is cleaner because ...2.1 IP in example 1 is a single node thus not really a network, and ...1.249 of example 1 serves no obvious purpose for the network.  (YES I know I used the work "obvious" and I'm not highly qualified to)  Here I'm expecting that if I use example #2 in documentation that tun may break for reasons I don't appreciate at this moment and that would be poor quality workmanship on my part...<BR>
<BR>
I like it a lot if the network design is so simple that one can say: <BR>
  "When the IP, port #, socket, and application, are not ambiguous then all is well in the network".<BR>
The alternative is to live long enough to have experienced a large enough body of examples that work/fail?
<BLOCKQUOTE TYPE=CITE>
<PRE>

</PRE>
</BLOCKQUOTE>
>SNIP<
<BLOCKQUOTE TYPE=CITE>
<PRE>

<FONT COLOR="#000000">Internetworking With TCP/IP</FONT>
<FONT COLOR="#000000">Principles, Protocols and Architecture</FONT>
<FONT COLOR="#000000">Copyright 1988</FONT>

<FONT COLOR="#000000">By Douglas Comer</FONT>
<FONT COLOR="#000000">Department of Computer Sciences</FONT>
<FONT COLOR="#000000">Purdue University</FONT>
<FONT COLOR="#000000">West Lafayette, IN 47907</FONT>

<FONT COLOR="#000000">Published By Prentice Hall</FONT>
<FONT COLOR="#000000">Englewood Cliffs, NJ 07632</FONT>
<FONT COLOR="#000000">A Division of Simon & Schuster</FONT>
</PRE>
</BLOCKQUOTE>
The title sounds appropriate.  I've begun the search....  THANKS.
<BLOCKQUOTE TYPE=CITE>
<PRE>

</PRE>
</BLOCKQUOTE>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<BR>
73<BR>
de Skip k8rra k<BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>