Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!think!ames!ucbcad!ucbvax!MATHOM.CISCO.COM!BILLW
From: BILLW@MATHOM.CISCO.COM (William Westfield)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: SLIP for IBM-PC
Message-ID: <12355088939.11.BILLW@MATHOM.CISCO.COM>
Date: Tue, 1-Dec-87 17:10:33 EST
Article-I.D.: MATHOM.12355088939.11.BILLW
Posted: Tue Dec  1 17:10:33 1987
Date-Received: Sat, 5-Dec-87 04:15:48 EST
References: 
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 57

Well, at cisco we are making SLIP server boxes, and there are
additional considerations.  Consider the following situation:

	    +--------+
   PC1------|  cisco |  Ethernet	HOST2
TERMINAL----|  slip  |==================================....
   PC2------| server |		HOST1		HOST3
	    +--------+

Let's assume that PC1 is permanently connected to the server.  Its address
is fixed, and it is not a problem.  TERMINAL is a terminal; it doesn't have
an IP address, so it is not a problem.  PC2, however, is on a dial-in port,
and might be some other PC at some other time.  It is the source of all
the problems.

Let's further assume that we have decided to use some variation of the
BOOTP protocol for PC2 to get/specify its own IP address (note that
BOOTP has a packet field for "Vendor specific information", and could
probably be easily extended to do anything we want, without having to
invent a NEW protocol).  There are a couple of possibilities as to who
would answer such a BOOTP request - either one of the HOSTs on the
ethernet, or the slip server itself.  The SLIP server HAS to know this
information, for obvious reasons, so it seems like the logical that it
should answer.

However, the usual function of the SLIP server is to receive SLIP
format IP packets from the serial lines and send them out the
ethernet, and to snarf appropriate packets off the ethernet and send
them down the serial line.  It never does much in the way of looking
inside any of the packets, beyond making sure they have valid IP
headers.  To have the server check each packet to see whether it
is a BOOTP request would be undesirable.  One solution that I sort
of like is to use a different IP version number in the bootp packet,
as a hack to indicate that it should be looked at by intermediate
gateway type entities.

In the MIT PC/IP model of the world, you probably want a separate
bootp program to set things up in the device driver - otherwise
every application has to have its own bootp code, which is probably
more work than necessary.  Presumably you could say something like
"bootp 326-1941", have it dial that number, do its thing, set up
the configuration, and exit...

An additional piece of information that needs to be requested/provided
somehow is whether the PC is going to attempt to be a gateway for some
other network behind it - this isn't necessarily possible (I sent a long
message to TCP-IP a while ago explaining the differences between gateway
and terminal-server models of SLIP servers - should I repost that to
this list also ?).

In general, I think that dial-in slip connections should have a fixed set
of IP addresses that are allowed.  Having a separate IP address for every
PC that could dial in will quickly become a address-management nightmare.

Bill Westfield
cisco Systems.
-------