Found 2 records.

Status: Held for Document Update (2)

RFC 1055, "Nonstandard for transmission of IP datagrams over serial lines: SLIP", June 1988

Errata ID: 8562
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Michał K. Kłosowski
Date Reported: 2025-09-03
Held for Document Update by: Erik Kline
Date Held: 2025-09-04

Throughout the document, when it says:

                   /* 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;
                                   }

It should say:

                   /* 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. If "c" is
                            * an END character, the packet must end.
                            * The proper way to escape an END character
                            * is to prepend an ESC_END byte with an ESC.
                            */
                           switch(c) {
                           case ESC_END:
                                   c = END;
                                   break;
                           case ESC_ESC:
                                   c = ESC;
                                   break;
                           case END:
                                   return received;
                                   }

Notes:

The example implementation (function recv_packet()) would fail to terminate the packet if an ESC END (0333 0300) sequence were received. While the RFC doesn't address such a sequence, leaving its meaning ambiguous, this behavior ought to be considered erroneous, as the proper way to escape an END character is to produce an ESC ESC_END (0333 0334) sequence. An END character is used exclusively to terminate a packet; this behavior has a higher importance for the protocol than a non-standard way to escape an END byte.

Inspection of a relevant implementation of SLIP in the Linux kernel (see slip_unesc() in drivers/net/slip/slip.c as of commit e6b9dce0aeeb91dfc0974ab87f02454e24566182) shows the expected behavior, supporting this interpretation.

I am unaware of any implementation that encodes an escaped END byte sequence as ESC END.

In view of this, I have modified the example implementation of the protocol in the SLIP DRIVERS sections to handle this erroneous sequence correctly. This should help prevent bugs in any future implementations written based on the example in the RFC.

Note: A modern revision of the SLIP specification should explicitly address invalid escape sequences. While there is no consensus on handling improperly escaped arbitrary bytes (other than ESC_END, ESC_ESC, and END), handling ESC END as described is obvious and widely implemented.

Note to RFC Editor: I tried to input "SLIP DRIVERS" into the Section field on this erratum, but the editor didn't accept it. RFC 1055 doesn't have numbered sections.

Errata ID: 4619
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Bradshaw
Date Reported: 2016-02-16
Held for Document Update by: Brian Haberman
Date Held: 2016-04-05

Section ABSTRACT says:

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.

It should say:

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.  SLIP, Serial
Line IP, is commonly used for point-to-point serial connections
running TCP/IP. Distribution of this memo is unlimited.

Notes:

Status is INTERNET STANDARD however the title says it's non-standard and the abstract says "not a standard".

An update could also refer to PPP as a standard... I've removed the line saying there is no standard for serial lines.

Report New Errata