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