Network Working Group W. Simpson Request for Comments: 1331 Daydreamer Obsoletes: RFCs 1171, 1172 May 1992 The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links Status of this Memo This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is comprised of three main components: 1. A method for encapsulating datagrams over serial links. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the PPP encapsulation scheme, together with the PPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list. Simpson [Page i] RFC 1331 Point-to-Point Protocol May 1992 Table of Contents 1. Introduction .......................................... 1 1.1 Specification of Requirements ................... 3 1.2 Terminology ..................................... 3 2. Physical Layer Requirements ........................... 4 3. The Data Link Layer ................................... 5 3.1 Frame Format .................................... 6 4. PPP Link Operation .................................... 10 4.1 Overview ........................................ 10 4.2 Phase Diagram ................................... 10 4.3 Link Dead (physical-layer not ready) ............ 10 4.4 Link Establishment Phase ........................ 11 4.5 Authentication Phase ............................ 11 4.6 Network-Layer Protocol Phase .................... 12 4.7 Link Termination Phase .......................... 12 5. The Option Negotiation Automaton ...................... 14 5.1 State Diagram ................................... 15 5.2 State Transition Table .......................... 16 5.3 States .......................................... 18 5.4 Events .......................................... 20 5.5 Actions ......................................... 24 5.6 Loop Avoidance .................................. 26 5.7 Counters and Timers ............................. 27 6. LCP Packet Formats .................................... 28 6.1 Configure-Request ............................... 30 6.2 Configure-Ack ................................... 31 6.3 Configure-Nak ................................... 32 6.4 Configure-Reject ................................ 33 6.5 Terminate-Request and Terminate-Ack ............. 35 6.6 Code-Reject ..................................... 36 6.7 Protocol-Reject ................................. 38 6.8 Echo-Request and Echo-Reply ..................... 39 6.9 Discard-Request ................................. 40 7. LCP Configuration Options ............................. 42 7.1 Format .......................................... 43 7.2 Maximum-Receive-Unit ............................ 44 7.3 Async-Control-Character-Map ..................... 45 7.4 Authentication-Protocol ......................... 47 7.5 Quality-Protocol ................................ 49 7.6 Magic-Number .................................... 51 Simpson [Page ii] RFC 1331 Point-to-Point Protocol May 1992 7.7 Protocol-Field-Compression ...................... 54 7.8 Address-and-Control-Field-Compression ........... 56 APPENDICES ................................................... 58 A. Asynchronous HDLC ..................................... 58 B. Fast Frame Check Sequence (FCS) Implementation ........ 61 B.1 FCS Computation Method .......................... 61 B.2 Fast FCS table generator ........................ 63 C. LCP Recommended Options ............................... 64 SECURITY CONSIDERATIONS ...................................... 65 REFERENCES ................................................... 65 ACKNOWLEDGEMENTS ............................................. 66 CHAIR'S ADDRESS .............................................. 66 AUTHOR'S ADDRESS ............................................. 66 Simpson [Page iii] RFC 1331 Point-to-Point Protocol May 1992 1. Introduction Motivation In the last few years, the Internet has seen explosive growth in the number of hosts supporting TCP/IP. The vast majority of these hosts are connected to Local Area Networks (LANs) of various types, Ethernet being the most common. Most of the other hosts are connected through Wide Area Networks (WANs) such as X.25 style Public Data Networks (PDNs). Relatively few of these hosts are connected with simple point-to-point (i.e., serial) links. Yet, point-to-point links are among the oldest methods of data communications and almost every host supports point-to-point connections. For example, asynchronous RS-232-C [1] interfaces are essentially ubiquitous. Encapsulation One reason for the small number of point-to-point IP links is the lack of a standard encapsulation protocol. There are plenty of non-standard (and at least one de facto standard) encapsulation protocols available, but there is not one which has been agreed upon as an Internet Standard. By contrast, standard encapsulation schemes do exist for the transmission of datagrams over most popular LANs. PPP provides an encapsulation protocol over both bit-oriented synchronous links and asynchronous links with 8 bits of data and no parity. These links MUST be full-duplex, but MAY be either dedicated or circuit-switched. PPP uses HDLC as a basis for the encapsulation. PPP has been carefully designed to retain compatibility with most commonly used supporting hardware. In addition, an escape mechanism is specified to allow control data such as XON/XOFF to be transmitted transparently over the link, and to remove spurious control data which may be injected into the link by intervening hardware and software. The PPP encapsulation also provides for multiplexing of different network-layer protocols simultaneously over the same link. It is intended that PPP provide a common solution for easy connection of a wide variety of hosts, bridges and routers. Some protocols expect error free transmission, and either provide error detection only on a conditional basis, or do not provide it at all. PPP uses the HDLC Frame Check Sequence for error detection. This is commonly available in hardware Simpson [Page 1] RFC 1331 Point-to-Point Protocol May 1992 implementations, and a software implementation is provided. By default, only 8 additional octets are necessary to form the encapsulation. In environments where bandwidth is at a premium, the encapsulation may be shortened to as few as 2 octets. To support high speed hardware implementations, PPP provides that the default encapsulation header and information fields fall on 32-bit boundaries, and allows the trailer to be padded to an arbitrary boundary. Link Control Protocol More importantly, the Point-to-Point Protocol defines more than just an encapsulation scheme. In order to be sufficiently versatile to be portable to a wide variety of environments, PPP provides a Link Control Protocol (LCP). The LCP is used to automatically agree upon the encapsulation format options, handle varying limits on sizes of packets, authenticate the identity of its peer on the link, determine when a link is functioning properly and when it is defunct, detect a looped-back link and other common misconfiguration errors, and terminate the link. Network Control Protocols Point-to-Point links tend to exacerbate many problems with the current family of network protocols. For instance, assignment and management of IP addresses, which is a problem even in LAN environments, is especially difficult over circuit-switched point-to-point links (such as dial-up modem servers). These problems are handled by a family of Network Control Protocols (NCPs), which each manage the specific needs required by their respective network-layer protocols. These NCPs are defined in other documents. Configuration It is intended that PPP be easy to configure. By design, the standard defaults should handle all common configurations. The implementor may specify improvements to the default configuration, which are automatically communicated to the peer without operator intervention. Finally, the operator may explicitly configure options for the link which enable the link to operate in environments where it would otherwise be impossible. This self-configuration is implemented through an extensible option negotiation mechanism, wherein each end of the link describes to the other its capabilities and requirements. Although the option negotiation mechanism described in this Simpson [Page 2] RFC 1331 Point-to-Point Protocol May 1992 document is specified in terms of the Link Control Protocol (LCP), the same facilities may be used by the Internet Protocol Control Protocol (IPCP) and others in the family of NCPs. 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 1.2. Terminology This document frequently uses the following terms: peer The other end of the point-to-point link. silently discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. Simpson [Page 3] RFC 1331 Point-to-Point Protocol May 1992 2. Physical Layer Requirements The Point-to-Point Protocol is capable of operating across any DTE/DCE interface (e.g., EIA RS-232-C, EIA RS-422, EIA RS-423 and CCITT V.35). The only absolute requirement imposed by PPP is the provision of a full-duplex circuit, either dedicated or circuit- switched, which can operate in either an asynchronous (start/stop) or synchronous bit-serial mode, transparent to PPP Data Link Layer frames. PPP does not impose any restrictions regarding transmission rate, other than those imposed by the particular DTE/DCE interface in use. PPP does not require any particular synchronous encoding, such as FM, NRZ, or NRZI. Implementation Note: NRZ is currently most widely available, and on that basis is recommended as a default. When configuration of the encoding is allowed, NRZI is recommended as an alternative, because of its relative immunity to signal inversion configuration errors. PPP does not require the use of modem control signals, such as Request To Send (RTS), Clear To Send (CTS), Data Carrier Detect (DCD), and Data Terminal Ready (DTR). Implementation Note: When available, using such signals can allow greater functionality and performance. In particular, such signals SHOULD be used to signal the Up and Down events in the Option Negotiation Automaton (described below). Simpson [Page 4] RFC 1331 Point-to-Point Protocol May 1992 3. The Data Link Layer The Point-to-Point Protocol uses the principles, terminology, and frame structure of the International Organization For Standardization's (ISO) High-level Data Link Control (HDLC) procedures (ISO 3309-1979 [2]), as modified by ISO 3309:1984/PDAD1 "Addendum 1: Start/stop transmission" [5]. ISO 3309-1979 specifies the HDLC frame structure for use in synchronous environments. ISO 3309:1984/PDAD1 specifies proposed modifications to ISO 3309-1979 to allow its use in asynchronous environments. The PPP control procedures use the definitions and Control field encodings standardized in ISO 4335-1979 [3] and ISO 4335- 1979/Addendum 1-1979 [4]. The PPP frame structure is also consistent with CCITT Recommendation X.25 LAPB [6], since that too is based on HDLC. The purpose of this memo is not to document what is already standardized in ISO 3309. We assume that the reader is already familiar with HDLC, or has access to a copy of [2] or [6]. Instead, this paper attempts to give a concise summary and point out specific options and features used by PPP. Since "Addendum 1: Start/stop transmission", is not yet standardized and widely available, it is summarized in Appendix A. To remain consistent with standard Internet practice, and avoid confusion for people used to reading RFCs, all binary numbers in the following descriptions are in Most Significant Bit to Least Significant Bit order, reading from left to right, unless otherwise indicated. Note that this is contrary to standard ISO and CCITT practice which orders bits as transmitted (i.e., network bit ord