Path: utzoo!mnetor!uunet!husc6!think!ames!pasteur!ucbvax!ANDREW.CMU.EDU!ddp+ From: ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) Newsgroups: comp.protocols.tcp-ip Subject: Re: SLIP working group? Message-ID: Date: 4 Apr 88 21:50:49 GMT References: <8803302259.AA28640@beno.CSS.GOV> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 39 > *Excerpts from: 30-Mar-88 Re: SLIP working group? Rick Adams@seismo.CSS.GO* > *(1929)* > If you are going to add multiple protocol support to SLIP, please do it > in the following manner. > The first byte following a FRAME_END is the protocol type byte. > If the byte is 0x40 - 0x4F the packet is considered to be an IP packet > and the protocol type byte IS INCLUDED as part of the packet. I'd originally planned on doing it exactly that way. Quite a few people I talked to thought that it wasn't worth it so I dropped the idea. Maybe I should take another look at it. There is one small problem with it which makes it slightly restrictive. Just being able to receive old-style packets doesn't make you backward-compatible. You have to transmit them also. To do that you probably need to keep some state about whether or not you have received old-style packets. If the first packet you receive is an old-style packet then set some flag. If later you disconnect or receive a packet with a type field (first byte something other than 0x4x) then reset the flag. However, this assumes that the first host to transmit packets is the old host. What if it is the other way around? What if you send a packet with a type field to a host which doesn't understand them? The receiving end won't understand them and will hopefully drop them on the floor because the IP checksum was not valid (which suggests that type 0 and 0xff should not be used!) or maybe because the IP header is not version 4 (which won't be true in the suggested scheme). However since the packet is dropped, it won't elicit a response which will cause the transmitter to continue transmitting new-style packets unless we add some other hacks like counting transmitted packets and switching modes after N packets if we don't receive any. In the simple case where we are using slip to link pc's and gateways this might not be a problem. The gateways will likely be the first to change (smaller numbers) and the pc's will follow (or maybe not). However we are shooting for wider use of slip than this simple application. Supporting gateway-gateway connections is a definite goal. Comments? Drew