Nonstandard for transmission of IP datagrams over serial lines: SLIP

Phil Karn proposed beginning each packet transmission with an END character as well as ending with one. This flushes any erroneous bytes accumulated from line noise; in the normal case the receiver sees two back-to-back END characters and discards the resulting zero-length IP packet harmlessly.

SLIP has no type field, so only one protocol can run over a SLIP connection. This is identified as a deficiency: two multi-protocol hosts (e.g., running both TCP/IP and DECnet) cannot share a single SLIP serial line between different protocol stacks.

SLIP intentionally provides only packet framing and nothing more—no addressing, packet type identification, error detection/correction, or compression. This extreme simplicity was a deliberate design choice from the early 1980s that made the protocol very easy to implement and widely portable.

SLIP provides no mechanism for communicating IP addressing information across the link. Both endpoints must already know each other's IP addresses; in dial-up scenarios the router has no in-band way to inform the dialing host of its assigned address.

The absence of header compression is flagged as a significant deficiency for dial-up use. At 2400 bps, TCP/IP streams have highly redundant headers across successive packets; a simple incremental-header compression scheme (later addressed by CSLIP/RFC 1144) would substantially increase effective throughput.

Because SLIP lacks a type field, only one network-layer protocol may run over a given SLIP connection at a time. Implementations that need to carry multiple protocols over the same serial line must use a successor framing protocol (e.g., PPP) instead.

There is no formal SLIP standard, so no single authoritative maximum packet size exists. The Berkeley UNIX driver limit of 1006 bytes is presented as the de facto interoperability baseline that new implementations should observe for compatibility with deployed systems.

Any new SLIP implementation should be prepared to accept datagrams of up to 1006 bytes (including IP and transport protocol headers, excluding framing characters) and should not send more than 1006 bytes in a single datagram. This de facto limit derives from the Berkeley UNIX SLIP drivers.

SLIP frames IP packets on a serial line using two special characters (END and ESC) and byte stuffing. A data byte equal to END is replaced by the two-byte sequence ESC + ESC_END; a data byte equal to ESC is replaced by ESC + ESC_ESC. The framed packet is terminated by an END character.

The recommended send algorithm is: (1) transmit an initial END byte to flush line noise, (2) iterate over payload bytes applying byte stuffing for END and ESC values, (3) transmit a final END byte to signal packet completion. The receive algorithm loops until END is received, applying inverse byte-unstuffing for ESC sequences.

SLIP provides no error detection or correction. Corrupted packets must be caught by upper-layer checksums (IP header, TCP, UDP). Some applications such as NFS ignore checksums and rely on the network medium; on noisy serial lines those applications may silently accept corrupted data.

security

SLIP defines four special byte values: END = 0300 (decimal 192) marks packet boundaries; ESC = 0333 (decimal 219) introduces a byte-stuffed escape sequence; ESC_END = 0334 (decimal 220) represents a literal END byte in data; ESC_ESC = 0335 (decimal 221) represents a literal ESC byte in data.