home *** CD-ROM | disk | FTP | other *** search
/ Hackers Toolkit 2.0 / Hackers_Toolkit_v2.0.iso / HTML / archive / Texts / Rfc / RFC1055.TXT < prev    next >
Encoding:
Text File  |  1999-11-04  |  12.3 KB  |  343 lines
  1. Network Working Group                                          J. Romkey
  2. Request for Comments: 1055                                     June l988
  3.  
  4.  A NONSTANDARD FOR TRANSMISSION OF IP DATAGRAMS OVER SERIAL LINES: SLIP
  5.  
  6. INTRODUCTION
  7.  
  8.    The TCP/IP protocol family runs over a variety of network media:
  9.    IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines,
  10.    satellite links, and serial lines.  There are standard encapsulations
  11.    for IP packets defined for many of these networks, but there is no
  12.    standard for serial lines.  SLIP, Serial Line IP, is a currently a de
  13.    facto standard, commonly used for point-to-point serial connections
  14.    running TCP/IP.  It is not an Internet standard.  Distribution of
  15.    this memo is unlimited.
  16.  
  17. HISTORY
  18.  
  19.    SLIP has its origins in the 3COM UNET TCP/IP implementation from the
  20.    early 1980's.  It is merely a packet framing protocol: SLIP defines a
  21.    sequence of characters that frame IP packets on a serial line, and
  22.    nothing more. It provides no addressing, packet type identification,
  23.    error detection/correction or compression mechanisms.  Because the
  24.    protocol does so little, though, it is usually very easy to
  25.    implement.
  26.  
  27.    Around 1984, Rick Adams implemented SLIP for 4.2 Berkeley Unix and
  28.    Sun Microsystems workstations and released it to the world.  It
  29.    quickly caught on as an easy reliable way to connect TCP/IP hosts and
  30.    routers with serial lines.
  31.  
  32.    SLIP is commonly used on dedicated serial links and sometimes for
  33.    dialup purposes, and is usually used with line speeds between 1200bps
  34.    and 19.2Kbps.  It is useful for allowing mixes of hosts and routers
  35.    to communicate with one another (host-host, host-router and router-
  36.    router are all common SLIP network configurations).
  37.  
  38. AVAILABILITY
  39.  
  40.    SLIP is available for most Berkeley UNIX-based systems.  It is
  41.    included in the standard 4.3BSD release from Berkeley.  SLIP is
  42.    available for Ultrix, Sun UNIX and most other Berkeley-derived UNIX
  43.    systems.  Some terminal concentrators and IBM PC implementations also
  44.    support it.
  45.  
  46.    SLIP for Berkeley UNIX is available via anonymous FTP from
  47.    uunet.uu.net in pub/sl.shar.Z.  Be sure to transfer the file in
  48.    binary mode and then run it through the UNIX uncompress program. Take
  49.  
  50.  
  51.  
  52. Romkey                                                          [Page 1]
  53.  
  54.  
  55. RFC 1055                     Serial Line IP                    June 1988
  56.  
  57.  
  58.    the resulting file and use it as a shell script for the UNIX /bin/sh
  59.    (for instance, /bin/sh sl.shar).
  60.  
  61. PROTOCOL
  62.  
  63.    The SLIP protocol defines two special characters: END and ESC. END is
  64.    octal 300 (decimal 192) and ESC is octal 333 (decimal 219) not to be
  65.    confused with the ASCII ESCape character; for the purposes of this
  66.    discussion, ESC will indicate the SLIP ESC character.  To send a
  67.    packet, a SLIP host simply starts sending the data in the packet.  If
  68.    a data byte is the same code as END character, a two byte sequence of
  69.    ESC and octal 334 (decimal 220) is sent instead.  If it the same as
  70.    an ESC character, an two byte sequence of ESC and octal 335 (decimal
  71.    221) is sent instead.  When the last byte in the packet has been
  72.    sent, an END character is then transmitted.
  73.  
  74.    Phil Karn suggests a simple change to the algorithm, which is to
  75.    begin as well as end packets with an END character.  This will flush
  76.    any erroneous bytes which have been caused by line noise.  In the
  77.    normal case, the receiver will simply see two back-to-back END
  78.    characters, which will generate a bad IP packet.  If the SLIP
  79.    implementation does not throw away the zero-length IP packet, the IP
  80.    implementation certainly will.  If there was line noise, the data
  81.    received due to it will be discarded without affecting the following
  82.    packet.
  83.  
  84.    Because there is no 'standard' SLIP specification, there is no real
  85.    defined maximum packet size for SLIP.  It is probably best to accept
  86.    the maximum packet size used by the Berkeley UNIX SLIP drivers: 1006
  87.    bytes including the IP and transport protocol headers (not including
  88.    the framing characters).  Therefore any new SLIP implementations
  89.    should be prepared to accept 1006 byte datagrams and should not send
  90.    more than 1006 bytes in a datagram.
  91.  
  92. DEFICIENCIES
  93.  
  94.    There are several features that many users would like SLIP to provide
  95.    which it doesn't.  In all fairness, SLIP is just a very simple
  96.    protocol designed quite a long time ago when these problems were not
  97.    really important issues.  The following are commonly perceived
  98.    shortcomings in the existing SLIP protocol:
  99.  
  100.       - addressing:
  101.  
  102.          both computers in a SLIP link need to know each other's IP
  103.          addresses for routing purposes.  Also, when using SLIP for
  104.          hosts to dial-up a router, the addressing scheme may be quite
  105.          dynamic and the router may need to inform the dialing host of
  106.  
  107.  
  108.  
  109. Romkey                                                          [Page 2]
  110.  
  111.  
  112. RFC 1055                     Serial Line IP                    June 1988
  113.  
  114.  
  115.          the host's IP address.  SLIP currently provides no mechanism
  116.          for hosts to communicate addressing information over a SLIP
  117.          connection.
  118.  
  119.       - type identification:
  120.  
  121.          SLIP has no type field.  Thus, only one protocol can be run
  122.          over a SLIP connection, so in a configuration of two DEC
  123.          computers running both TCP/IP and DECnet, there is no hope of
  124.          having TCP/IP and DECnet share one serial line between them
  125.          while using SLIP.  While SLIP is "Serial Line IP", if a serial
  126.          line connects two multi-protocol computers, those computers
  127.          should be able to use more than one protocol over the line.
  128.  
  129.       - error detection/correction:
  130.  
  131.          noisy phone lines will corrupt packets in transit. Because the
  132.          line speed is probably quite low (likely 2400 baud),
  133.          retransmitting a packet is very expensive.  Error detection is
  134.          not absolutely necessary at the SLIP level because any IP
  135.          application should detect damaged packets (IP header and UDP
  136.          and TCP checksums should suffice), although some common
  137.          applications like NFS usually ignore the checksum and depend on
  138.          the network media to detect damaged packets.  Because it takes
  139.          so long to retransmit a packet which was corrupted by line
  140.          noise, it would be efficient if SLIP could provide some sort of
  141.          simple error correction mechanism of its own.
  142.  
  143.       - compression:
  144.  
  145.          because dial-in lines are so slow (usually 2400bps), packet
  146.          compression would cause large improvements in packet
  147.          throughput. Usually, streams of packets in a single TCP
  148.          connection have few changed fields in the IP and TCP headers,
  149.          so a simple compression algorithms might just send the changed
  150.          parts of the headers instead of the complete headers.
  151.  
  152.    Some work is being done by various groups to design and implement a
  153.    successor to SLIP which will address some or all of these problems.
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166. Romkey                                                          [Page 3]
  167.  
  168.  
  169. RFC 1055                     Serial Line IP                    June 1988
  170.  
  171.  
  172. SLIP DRIVERS
  173.  
  174.    The following C language functions send and receive SLIP packets.
  175.    They depend on two functions, send_char() and recv_char(), which send
  176.    and receive a single character over the serial line.
  177.  
  178.    /* SLIP special character codes
  179.     */
  180.    #define END             0300    /* indicates end of packet */
  181.    #define ESC             0333    /* indicates byte stuffing */
  182.    #define ESC_END         0334    /* ESC ESC_END means END data byte */
  183.    #define ESC_ESC         0335    /* ESC ESC_ESC means ESC data byte */
  184.  
  185.    /* SEND_PACKET: sends a packet of length "len", starting at
  186.     * location "p".
  187.     */
  188.    void send_packet(p, len)
  189.            char *p;
  190.            int len; {
  191.  
  192.      /* send an initial END character to flush out any data that may
  193.       * have accumulated in the receiver due to line noise
  194.       */
  195.         send_char(END);
  196.  
  197.      /* for each byte in the packet, send the appropriate character
  198.       * sequence
  199.       */
  200.            while(len--) {
  201.                    switch(*p) {
  202.                    /* if it's the same code as an END character, we send a
  203.                     * special two character code so as not to make the
  204.                     * receiver think we sent an END
  205.                     */
  206.                    case END:
  207.                            send_char(ESC);
  208.                            send_char(ESC_END);
  209.                            break;
  210.  
  211.                    /* if it's the same code as an ESC character,
  212.                     * we send a special two character code so as not
  213.                     * to make the receiver think we sent an ESC
  214.                     */
  215.                    case ESC:
  216.                            send_char(ESC);
  217.                            send_char(ESC_ESC);
  218.                            break;
  219.  
  220.  
  221.  
  222.  
  223. Romkey                                                          [Page 4]
  224.  
  225.  
  226. RFC 1055                     Serial Line IP                    June 1988
  227.  
  228.  
  229.                    /* otherwise, we just send the character
  230.                     */
  231.                    default:
  232.                            send_char(*p);
  233.                            }
  234.  
  235.                    p++;
  236.                    }
  237.  
  238.            /* tell the receiver that we're done sending the packet
  239.             */
  240.            send_char(END);
  241.            }
  242.  
  243.    /* RECV_PACKET: receives a packet into the buffer located at "p".
  244.     *      If more than len bytes are received, the packet will
  245.     *      be truncated.
  246.     *      Returns the number of bytes stored in the buffer.
  247.     */
  248.    int recv_packet(p, len)
  249.            char *p;
  250.            int len; {
  251.            char c;
  252.            int received = 0;
  253.  
  254.            /* sit in a loop reading bytes until we put together
  255.             * a whole packet.
  256.             * Make sure not to copy them into the packet if we
  257.             * run out of room.
  258.             */
  259.            while(1) {
  260.                    /* get a character to process
  261.                     */
  262.                    c = recv_char();
  263.  
  264.                    /* handle bytestuffing if necessary
  265.                     */
  266.                    switch(c) {
  267.  
  268.                    /* if it's an END character then we're done with
  269.                     * the packet
  270.                     */
  271.                    case END:
  272.                            /* a minor optimization: if there is no
  273.                             * data in the packet, ignore it. This is
  274.                             * meant to avoid bothering IP with all
  275.                             * the empty packets generated by the
  276.                             * duplicate END characters which are in
  277.  
  278.  
  279.  
  280. Romkey                                                          [Page 5]
  281.  
  282.  
  283. RFC 1055                     Serial Line IP                    June 1988
  284.  
  285.  
  286.                             * turn sent to try to detect line noise.
  287.                             */
  288.                            if(received)
  289.                                    return received;
  290.                            else
  291.                                    break;
  292.  
  293.                    /* if it's the same code as an ESC character, wait
  294.                     * and get another character and then figure out
  295.                     * what to store in the packet based on that.
  296.                     */
  297.                    case ESC:
  298.                            c = recv_char();
  299.  
  300.                            /* if "c" is not one of these two, then we
  301.                             * have a protocol violation.  The best bet
  302.                             * seems to be to leave the byte alone and
  303.                             * just stuff it into the packet
  304.                             */
  305.                            switch(c) {
  306.                            case ESC_END:
  307.                                    c = END;
  308.                                    break;
  309.                            case ESC_ESC:
  310.                                    c = ESC;
  311.                                    break;
  312.                                    }
  313.  
  314.                    /* here we fall into the default handler and let
  315.                     * it store the character for us
  316.                     */
  317.                    default:
  318.                            if(received < len)
  319.                                    p[received++] = c;
  320.                            }
  321.                    }
  322.            }
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337. Romkey                                                          [Page 6]
  338.  
  339.  
  340.  
  341.  
  342.  
  343.