A FRAMEWORK FOR EXTENDING SLIP TO IPv6 AND BEYOND INTRODUCTION RFC 1055 describes one way of carrying IP datagrams over serial lines. For all that it calls itself a "nonstandard", it rapidly became a de-facto standard for encapsulating IP datagrams in serial lines, and was widely used, especially as it was shipped with a popular Unix derivative. It had many deficiencies, and in part because of them, a successor was designed, the Point-to-Point Protocol, PPP (see RFC 1661). However, compared to SLIP, PPP is comparatively heavyweight, and common implementations of it have other problems which, while not inherent in the protocol, do render it less useful in many circumstances that it might otherwise be. In some of those circumstances, SLIP is a more appropriate solution than PPP. However, SLIP has one highly visible failing in today's Internet: as defined and as commonly implemented, it does not support any protocols except IPv4. This draft outlines an experimental framework for lifting this restriction and describes how it has been used on a small scale to transport IPv6 traffic. PROTOCOL The SLIP protocol is very simple. The underlying link is assumed to be an 8-bit-clean data path, ie, an octet stream. All that is needed, then, is to impose framing, to discern where packet boundaries fall. To this end, SLIP sends most octets as themselves; only two octet values are singled out for special treatment. These are 0xc0 (called END) and 0xdb (RFC 1055 calls this ESC; despite the possibility of confusion with the ASCII ESC character, 0x1b, this memo follows RFC 1055 in this usage). END is used to mark packet boundaries: an END octet is sent at the end of every packet. (For better noise tolerance, many implementations follow the recommendation in RFC 1055 and send it at the beginning of each packet as well, at least if the line has been idle.) This requires some way to handle 0xc0 octets occurring within packet data. The ESC octet is used for this purpose; it marks the following octet for special treatment, and two values for that following octet are defined to represent data octets with the values colliding with END and ESC (specifically, a data octet with value 0xc0 is sent as 0xdb 0xdc; a data octet with value 0xdb is sent as 0xdb 0xdd). However, as RFC 1055 notes, packets are not explicitly marked with protocol types, addresses, or anything else. RFC 1055 says of the multi-protocol issue, 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. Fortunately, this is not true. A little thought will reveal that there are 254 two-octet sequences beginning with ESC that have no meaning defined by the SLIP "nonstandard"; these can be used to extend SLIP. This memo proposes a specific way of doing so to carry protocols other than IPv4. This proposal allocates 16 of those 254 two-octet sequences to mark a packet's protocol: ESC 0x80 through ESC 0x8f. IPv4 packets will be encoded without using any of these markers; other protocols will use one to mark the packet as belonging to that protocol (the marker can appear anywhere in the encoded octet stream that a data byte can; its exact location is irrelevant, and it applies to the entire packet it appears in). ESC 0x80 indicates IPv6; ESC 0x81 through ESC 0x8e are reserved for other protocols, with ESC 0x8f reserved for possible future specification for a much wider variety of protocols. I have made suitable changes to the NetBSD SLIP code to support the use of ESC 0x80 to transport IPv6. Initial experience is that it works as well as can be expected given the underlying medium. Note that no ambiguity is introduced: just as a data octet of 0xdd is represented by itself, because that octet has no special significance unless it is preceded by ESC, the newly-defined octets 0x80-0x8f have no special significance unless preceded by ESC. An implementation using this scheme can correctly receive packets from older implementations without trouble, since ESC followed by anything other than 0xdc or 0xdd had no defined meaning and hence should never be generated. (Such packets will perforce be IPv4 packets, of course.) An implementation using this scheme can also send packets to older implementation, provided the newer one does not send anything but IPv4 packets, since IPv4 packets are encoded precisely as specified by RFC 1055. If a packet in some other protocol is mistakenly sent, the older receiver of course will not understand it correctly. The possibility exists that it could crash as a result; however, since line noise has always meant that stray corrupted octets can occur, such an implementation could also crash in the presence of simple line noise. This is a quality-of-implementation issue; if faced with an implementation sufficiently buggy to crash under such circumstances, the obvious remedy is to disable sending anything but IPv4 packets (the peer will not be able to handle them anyway). RATIONALE The question has been asked, why not simply use the IP type field, the first four bits of an IP packet, to determine whether the packet is IPv4 or IPv6. Most generally, the answer to this is that it is good to carry type information out-of-band with respect to the data. Two specific ways in which adherence to this principle has good effects here are - This proposal can work equally well with protocols that do not have distinctive values in the first four bits of their packets, or which have distinctive values which collide with IP's values. Possible examples include DECnet, ISO OSI, and Chaosnet, though I do not know them well enough to know whether they actually qualify. - It is not upset by Van Jacobson header compression (vide infra). POSSIBLE FUTURE DIRECTIONS As noted above, this scheme is completely orthogonal to Van Jacobson header compression. The proposed marking of packets as belonging to various protocols does not depend on packet contents in any way and thus is not disturbed by header compression changing the first octet of IPv4 packets. I have made no attempt to implement (or even design) a header compression scheme for IPv6 packets; presumably this could be done. I also have not attempted to lift any of the other restrictions SLIP imposes, such as manual address configuration or (lack of) detection of dead hosts or disconnected links. For my purposes these are unnecessary and undesired, and if carried out they would probably amount to reinventing PPP. I have not defined any other protocol values. It is not clear to me which other protocols are used heavily enough to deserve their own type octet and which ones should be lumped under the ESC 0x8f escape. Future experience may even indicate that the proposed scheme is in some wise unsuitable and should be entirely redone. One possible use that has been suggested for ESC 0x8f is to use Ethernet's 16-bit type field in the next two octets, allowing carrying over a serial line anything that can be carried over Ethernet. SECURITY CONSIDERATIONS This proposal does not have any security implications beyond those implicit in providing a packet transport for the affected protocol(s). If widely implemented it could convert a single-protocol link into a multi-protocol link as a silent side effect of an OS upgrade; in an environment where security depends on "dangerous" protocols having no path via which they could reach a vulnerable host, this could create a security risk. COPYRIGHT This memo is in the public domain. Anyone may use it and the ideas outlined in it in any way for any purpose. I am not aware of any intellectual property rights (such as patents) that would necessarily apply to an implementation of this spec.