Summary

  • RFC 1055 describes SLIP as a very small, nonstandard serial-line framing convention: END closes a packet and ESC prevents END or ESC data bytes from being mistaken for framing.
  • The suggested leading END is a cheap resynchronization operation. It flushes bytes that line noise may have left at the receiver; adjacent ENDs create an empty packet that the supplied receiver ignores.
  • A recovered boundary is not evidence of intact payload or aligned higher-layer state. RFC 1144 and later PPP framing make the division of labour visible rather than collapsing it into the delimiter.

A protocol that refused to pretend

The historical attraction of SLIP was not abundance. It was restraint. RFC 1055, published in 1988, calls Serial Line IP a de facto convention for point-to-point serial TCP/IP and says plainly that it is not an Internet Standard. Its description is even more revealing: SLIP is “merely a packet framing protocol.” It defines a sequence of characters that frames IP packets on a serial line, and nothing more.

That last phrase is a design boundary, not an apology. RFC 1055 explicitly says SLIP supplies no addressing, packet-type identification, error detection or correction, and no compression. Two peers need to know their IP addressing information by some other means. A link cannot use SLIP alone to carry multiple network protocols distinguished by a type field. A corrupted frame receives no SLIP-level certificate of integrity. The smallness that made the code easy to implement also left other systems with jobs to do.

It is tempting to read a spare historical format as an unfinished version of a later, richer one. That is usually the wrong question. The better question is: what decision could this mechanism make locally, deterministically and without claiming the rest of the world? For SLIP, the answer was a narrow one. A receiver consuming an uninterrupted serial byte stream needed to know where one IP datagram stopped. It needed a way to keep two special bytes from impersonating that answer inside ordinary data. It did not need a new mythology of link authority.

RFC 1055 assigns END octal 0300 (decimal 192) to the first job and ESC octal 0333 (decimal 219) to the second. While transmitting an IP packet, a sender replaces a data byte equal to END with ESC plus octal 0334, and a data byte equal to ESC with ESC plus octal 0335. After the final data byte, it sends END. The receiver reads bytes until END and reverses those two substitutions. The grammar is intentionally local: END is structural only to a SLIP receiver in the relevant state; ESC modifies only the two reserved values in the same grammar.

This is not generic “escaping.” It is a tiny allocation of responsibility. The transmitter preserves a data byte that would otherwise collide with the framing rule. The receiver restores it. Neither side learns whether the IP datagram is semantically desirable, whether a peer is entitled to use the line, or whether an earlier byte was damaged. The mechanism keeps a separator from being confused with payload. That is all.

Why send a separator before there is anything to separate?

The most memorable line in RFC 1055 is not the normal trailing END. Phil Karn’s suggested modification is to begin a packet with END as well as end it. The document gives a practical reason: the initial END flushes erroneous bytes that line noise may have caused to accumulate at the receiver.

At first this can look redundant. If the old frame ended with END and the next one begins with END, a healthy receiver sees two delimiters in succession. RFC 1055 accepts the cost. In the normal case, the adjacent values generate a zero-length or bad IP packet; the document notes that the IP implementation will discard it, and the sample receiver takes the simpler route of ignoring an END when it has collected no data. In the noisy case, however, the first new END terminates the unwanted accumulation. The bytes caused by noise are discarded before the following datagram is considered.

That one byte therefore means neither “the next packet is true” nor “the preceding bytes were false.” It means: do not let the current unfinished collection become the beginning of the next claimed datagram. It re-establishes a parser boundary. The cost is an intentionally disposable empty frame in the clean case; the benefit is that a possible noise fragment loses the chance to contaminate the next frame’s interpretation.

The distinction matters because a serial stream does not hand the receiver messages. It hands it octets in time. After a disturbance, a receiver can have bytes in its buffer without having a trustworthy reason to attach them to the next IP datagram. A leading END gives it a simple, observable reset point. It does not turn the medium into a reliable record store. It only limits the jurisdiction of bytes that arrived before the reset.

RFC 1055’s sample code makes the limit concrete. It returns a packet only when END arrives after data. It consumes the duplicated ENDs made by the leading-END suggestion. If ESC is followed by one of the two expected escape values, the receiver restores END or ESC; if it is followed by another value, the code calls that a protocol violation and stores the byte. This is not broad validation. It is a small decoder trying to preserve payload transparency while recognizing two controls.

Boundary, integrity and state are different facts

SLIP’s omissions become sharpest when the payload has its own dependence on history. RFC 1144, Jacobson’s TCP/IP header compression for low-speed serial links, is useful here because it does not blur the layers. Its block diagram sends an IP packet through a compressor and then to a framer. The compressor retains header state for connections on a serial link; a compressed packet can describe changes relative to a prior header.

The framing question is therefore not the state question. A receiver can find an END and correctly extract a byte sequence from a frame while still lacking evidence that the sequence is undamaged. It can receive an undamaged frame while its decompressor’s prior state is no longer the state assumed by the sender. RFC 1144’s error discussion says that error detection belongs at the framing level and that the decompressor needs an error indication so it can discard a bad packet rather than propagate a state error. The initial SLIP END does not provide that indication. It is not supposed to.

This is a powerful way to read the leading END without granting it invented powers. A boundary answers where should I restart parsing? Integrity asks are these contents intact? Stateful decoding asks are both ends using a compatible remembered context? A useful system can have one answer without the other two. Treating the three as the same fact is how a convenient delimiter gets made responsible for a failure it cannot observe.

The contrast with RFC 1662 is equally disciplined. PPP’s HDLC-like framing later specifies a flag that may indicate a beginning or end, octet stuffing, an FCS and invalid-frame handling. It also warns that saving an opening flag after idle time can trade reliability for delay: noise can be appended to the next frame unless the sender emits a new opening flag. The resemblance to SLIP’s leading END is informative, not a claim of identity. Both documents recognize that a marker can delimit and resynchronize; PPP places that work within a broader, explicitly specified link contract.

SLIP should not be rewritten in hindsight as a defective PPP. It was a thin convention whose known limits were named in its own document. Its leading END is valuable precisely because it shows how a small common rule can improve recovery without pretending to provide every adjacent property.

The framing authority must expire

Heng Lu’s Notes 64 and 65 offer the right editorial discipline for this history: identify the minimum deterministic function that running systems can verify locally, then do not inflate it into standing authority. In SLIP, END has authority only inside the serial framing grammar. ESC has authority only when it precedes one of the protected byte forms. Once an END has established the boundary, it cannot certify the bytes after it. Once a receiver has reconstructed bytes, the framing mechanism cannot certify the state that a separate compressor needs.

That is why the initial END is more than an old serial trick. It is a clean example of recoverable scope. The sender adds a boundary event. The receiver has a defined response. The event is cheap, inspectable and deliberately limited. No committee or decoder may infer more from it than the wire grammar states.

The operational review question is correspondingly plain. When a stream is disturbed, record which bytes preceded the resynchronization marker, whether a complete frame was observed after it, what integrity check—if any—accepted the frame, and whether any stateful layer was reset or resynchronized separately. A log that says merely “frame received after reset” joins three different claims into one untestable sentence.

Sources and evidence limits

The closed source set is RFC 1055, RFC 1144 and RFC 1662. It supports the stated byte grammar, the leading-END rationale, SLIP’s declared omissions, RFC 1144’s compressor/framer and error-state distinction, and the later PPP comparison. It does not establish universal SLIP deployment, any present serial-device behaviour, a measured line-noise rate, a security result, or that every SLIP link used header compression.