RFC 1055 (rfc1055) - Page 2 of 6

Nonstandard for transmission of IP datagrams over serial lines: SLIP

RFC 1055                     Serial Line IP                    June 1988


   the resulting file and use it as a shell script for the UNIX /bin/sh
   (for instance, /bin/sh sl.shar).

PROTOCOL

   The SLIP protocol defines two special characters: END and ESC. END is
   octal 300 (decimal 192) and ESC is octal 333 (decimal 219) not to be
   confused with the ASCII ESCape character; for the purposes of this
   discussion, ESC will indicate the SLIP ESC character.  To send a
   packet, a SLIP host simply starts sending the data in the packet.  If
   a data byte is the same code as END character, a two byte sequence of
   ESC and octal 334 (decimal 220) is sent instead.  If it the same as
   an ESC character, an two byte sequence of ESC and octal 335 (decimal
   221) is sent instead.  When the last byte in the packet has been
   sent, an END character is then transmitted.

   Phil Karn suggests a simple change to the algorithm, which is to
   begin as well as end packets with an END character.  This will flush
   any erroneous bytes which have been caused by line noise.  In the
   normal case, the receiver will simply see two back-to-back END
   characters, which will generate a bad IP packet.  If the SLIP
   implementation does not throw away the zero-length IP packet, the IP
   implementation certainly will.  If there was line noise, the data
   received due to it will be discarded without affecting the following
   packet.

   Because there is no 'standard' SLIP specification, there is no real
   defined maximum packet size for SLIP.  It is probably best to accept
   the maximum packet size used by the Berkeley UNIX SLIP drivers: 1006
   bytes including the IP and transport protocol headers (not including
   the framing characters).  Therefore any new SLIP implementations
   should be prepared to accept 1006 byte datagrams and should not send
   more than 1006 bytes in a datagram.

DEFICIENCIES

   There are several features that many users would like SLIP to provide
   which it doesn't.  In all fairness, SLIP is just a very simple
   protocol designed quite a long time ago when these problems were not
   really important issues.  The following are commonly perceived
   shortcomings in the existing SLIP protocol:

      - addressing:

         both computers in a SLIP link need to know each other's IP
         addresses for routing purposes.  Also, when using SLIP for
         hosts to dial-up a router, the addressing scheme may be quite
         dynamic and the router may need to inform the dialing host of



Romkey