doc: Add RFC documents

1 files changed, 333 insertions, 0 deletions

diff --git a/doc/rfc/rfc1055.txt b/doc/rfc/rfc1055.txt
new file mode 100644
index 0000000..a754540
--- /dev/null
+++ b/doc/rfc/rfc1055.txt
@@ -0,0 +1,333 @@
+Network Working Group                                          J. Romkey
+Request for Comments: 1055                                     June l988
+
+ A NONSTANDARD FOR TRANSMISSION OF IP DATAGRAMS OVER SERIAL LINES: SLIP
+
+INTRODUCTION
+
+   The TCP/IP protocol family runs over a variety of network media:
+   IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines,
+   satellite links, and serial lines.  There are standard encapsulations
+   for IP packets defined for many of these networks, but there is no
+   standard for serial lines.  SLIP, Serial Line IP, is a currently a de
+   facto standard, commonly used for point-to-point serial connections
+   running TCP/IP.  It is not an Internet standard.  Distribution of
+   this memo is unlimited.
+
+HISTORY
+
+   SLIP has its origins in the 3COM UNET TCP/IP implementation from the
+   early 1980's.  It is merely a packet framing protocol: SLIP defines a
+   sequence of characters that frame IP packets on a serial line, and
+   nothing more. It provides no addressing, packet type identification,
+   error detection/correction or compression mechanisms.  Because the
+   protocol does so little, though, it is usually very easy to
+   implement.
+
+   Around 1984, Rick Adams implemented SLIP for 4.2 Berkeley Unix and
+   Sun Microsystems workstations and released it to the world.  It
+   quickly caught on as an easy reliable way to connect TCP/IP hosts and
+   routers with serial lines.
+
+   SLIP is commonly used on dedicated serial links and sometimes for
+   dialup purposes, and is usually used with line speeds between 1200bps
+   and 19.2Kbps.  It is useful for allowing mixes of hosts and routers
+   to communicate with one another (host-host, host-router and router-
+   router are all common SLIP network configurations).
+
+AVAILABILITY
+
+   SLIP is available for most Berkeley UNIX-based systems.  It is
+   included in the standard 4.3BSD release from Berkeley.  SLIP is
+   available for Ultrix, Sun UNIX and most other Berkeley-derived UNIX
+   systems.  Some terminal concentrators and IBM PC implementations also
+   support it.
+
+   SLIP for Berkeley UNIX is available via anonymous FTP from
+   uunet.uu.net in pub/sl.shar.Z.  Be sure to transfer the file in
+   binary mode and then run it through the UNIX uncompress program. Take
+
+
+
+Romkey                                                          [Page 1]
+
+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                                                          [Page 2]
+
+RFC 1055                     Serial Line IP                    June 1988
+
+
+         the host's IP address.  SLIP currently provides no mechanism
+         for hosts to communicate addressing information over a SLIP
+         connection.
+
+      - type identification:
+
+         SLIP has no type field.  Thus, only one protocol can be run
+         over a SLIP connection, so in a configuration of two DEC
+         computers running both TCP/IP and DECnet, there is no hope of
+         having TCP/IP and DECnet share one serial line between them
+         while using SLIP.  While SLIP is "Serial Line IP", if a serial
+         line connects two multi-protocol computers, those computers
+         should be able to use more than one protocol over the line.
+
+      - error detection/correction:
+
+         noisy phone lines will corrupt packets in transit. Because the
+         line speed is probably quite low (likely 2400 baud),
+         retransmitting a packet is very expensive.  Error detection is
+         not absolutely necessary at the SLIP level because any IP
+         application should detect damaged packets (IP header and UDP
+         and TCP checksums should suffice), although some common
+         applications like NFS usually ignore the checksum and depend on
+         the network media to detect damaged packets.  Because it takes
+         so long to retransmit a packet which was corrupted by line
+         noise, it would be efficient if SLIP could provide some sort of
+         simple error correction mechanism of its own.
+
+      - compression:
+
+         because dial-in lines are so slow (usually 2400bps), packet
+         compression would cause large improvements in packet
+         throughput. Usually, streams of packets in a single TCP
+         connection have few changed fields in the IP and TCP headers,
+         so a simple compression algorithms might just send the changed
+         parts of the headers instead of the complete headers.
+
+   Some work is being done by various groups to design and implement a
+   successor to SLIP which will address some or all of these problems.
+
+
+
+
+
+
+
+
+
+
+
+
+Romkey                                                          [Page 3]
+
+RFC 1055                     Serial Line IP                    June 1988
+
+
+SLIP DRIVERS
+
+   The following C language functions send and receive SLIP packets.
+   They depend on two functions, send_char() and recv_char(), which send
+   and receive a single character over the serial line.
+
+   /* SLIP special character codes
+    */
+   #define END             0300    /* indicates end of packet */
+   #define ESC             0333    /* indicates byte stuffing */
+   #define ESC_END         0334    /* ESC ESC_END means END data byte */
+   #define ESC_ESC         0335    /* ESC ESC_ESC means ESC data byte */
+
+   /* SEND_PACKET: sends a packet of length "len", starting at
+    * location "p".
+    */
+   void send_packet(p, len)
+           char *p;
+           int len; {
+
+     /* send an initial END character to flush out any data that may
+      * have accumulated in the receiver due to line noise
+      */
+        send_char(END);
+
+     /* for each byte in the packet, send the appropriate character
+      * sequence
+      */
+           while(len--) {
+                   switch(*p) {
+                   /* if it's the same code as an END character, we send a
+                    * special two character code so as not to make the
+                    * receiver think we sent an END
+                    */
+                   case END:
+                           send_char(ESC);
+                           send_char(ESC_END);
+                           break;
+
+                   /* if it's the same code as an ESC character,
+                    * we send a special two character code so as not
+                    * to make the receiver think we sent an ESC
+                    */
+                   case ESC:
+                           send_char(ESC);
+                           send_char(ESC_ESC);
+                           break;
+
+
+
+
+Romkey                                                          [Page 4]
+
+RFC 1055                     Serial Line IP                    June 1988
+
+
+                   /* otherwise, we just send the character
+                    */
+                   default:
+                           send_char(*p);
+                           }
+
+                   p++;
+                   }
+
+           /* tell the receiver that we're done sending the packet
+            */
+           send_char(END);
+           }
+
+   /* RECV_PACKET: receives a packet into the buffer located at "p".
+    *      If more than len bytes are received, the packet will
+    *      be truncated.
+    *      Returns the number of bytes stored in the buffer.
+    */
+   int recv_packet(p, len)
+           char *p;
+           int len; {
+           char c;
+           int received = 0;
+
+           /* sit in a loop reading bytes until we put together
+            * a whole packet.
+            * Make sure not to copy them into the packet if we
+            * run out of room.
+            */
+           while(1) {
+                   /* get a character to process
+                    */
+                   c = recv_char();
+
+                   /* handle bytestuffing if necessary
+                    */
+                   switch(c) {
+
+                   /* if it's an END character then we're done with
+                    * the packet
+                    */
+                   case END:
+                           /* a minor optimization: if there is no
+                            * data in the packet, ignore it. This is
+                            * meant to avoid bothering IP with all
+                            * the empty packets generated by the
+                            * duplicate END characters which are in
+
+
+
+Romkey                                                          [Page 5]
+
+RFC 1055                     Serial Line IP                    June 1988
+
+
+                            * turn sent to try to detect line noise.
+                            */
+                           if(received)
+                                   return received;
+                           else
+                                   break;
+
+                   /* if it's the same code as an ESC character, wait
+                    * and get another character and then figure out
+                    * what to store in the packet based on that.
+                    */
+                   case ESC:
+                           c = recv_char();
+
+                           /* if "c" is not one of these two, then we
+                            * have a protocol violation.  The best bet
+                            * seems to be to leave the byte alone and
+                            * just stuff it into the packet
+                            */
+                           switch(c) {
+                           case ESC_END:
+                                   c = END;
+                                   break;
+                           case ESC_ESC:
+                                   c = ESC;
+                                   break;
+                                   }
+
+                   /* here we fall into the default handler and let
+                    * it store the character for us
+                    */
+                   default:
+                           if(received < len)
+                                   p[received++] = c;
+                           }
+                   }
+           }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Romkey                                                          [Page 6]
+