From ietf-ppp-request@ucdavis.ucdavis.edu Fri Apr 5 14:47:12 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12641; Fri, 5 Apr 91 14:31:34 -0800 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nsco.network.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12338; Fri, 5 Apr 91 14:17:10 -0800 Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA12958; Fri, 5 Apr 91 16:18:55 -0600 Received: from eros.network.com by anubis.network.com (4.0/SMI-4.0) id AA19840; Fri, 5 Apr 91 16:17:28 CST Date: Fri, 5 Apr 91 16:17:28 CST From: sjs@anubis.network.com (Steve Senum) Message-Id: <9104052217.AA19840@anubis.network.com> To: ietf-ppp@ucdavis.edu Subject: DECnet over PPP I am finally getting around to moving my Phase IV DECnet over PPP forward. What follows is the current draft. I hope to have this issued as a draft in the near future. Please send any comments to me, or to the PPP mailing list. Steve Senum, sjs@network.com, 612-424-4888 --------------------------------------------------------- Network Working Group Steven J. Senum Request for Comments: Internet Draft Network Systems Corporation November 23, 1990 Point-to-Point Procotol Extensions for DECnet Phase IV Status of this Memo This draft document will be submitted to the RFC editor as a protocol specification. Please send comments to the author. It is an extension of the Internet Point-to-Point Protocol described in RFC 1171 [1], targeting the use of Point-to-Point lines for DECnet. Distribution of this memo is unlimited. 1. Introduction The purpose of the memo is to define a method for transmitting DECnet data packets over a serial link using the PPP protocol as defined in [1]. This memo only applies to DECnet Routing messages (both data packets and control messages), and not to other DECnet protocols like MOP, LAT, etc. There are two basic approaches to routing DECnet over a serial line: 1. The approached that several router vendors have taken which is to treat the serial link as an Ethernet, using the same control messages an Ethernet would use. 2. The approach defined by Digital, which uses DDCMP and slighty different control messages. This memo will define a method that uses the first approach. 2. Overview Of Phase IV DNA Protocols The Phase IV DNA protocols which act as data link clients are: o DNA Phase IV Routing The Phase IV Digital Network Architecture (DNA) Routing protocol is a network layer protocol providing services similar to that of DoD IP. It routes messages in Phase IV DECnet networks and manages the packet flow. The complete definition Senum [Page 1] Internet Draft DECnet Point-to-Point November 23, 1990 of the DNA Phase IV Routing protocol can be found in [2]. o DNA System Console The Digital Network Architecture (DNA) System Console protocol is a maintenance protocol providing low level access to a system for the functions of: . Identify processor . Read data link counters . Boot system . Console carrier (a general purpose i/o channel) The complete definition of the DNA System Console protocol can be found in [3]. o Digital Customer Use The Digital Customer Use protocol type is a value reserved for use by Digital customers. It allocates a type for private use which will not conflict with Digital or other vendor protocols. o DNA Diagnostics The Digital Network Architecture (DNA) Diagnostics protocol type is reserved to allow diagnostic software communications in parallel with other data link clients. o DNA Naming Service (DNS) The Digital Network Architecture Naming Service (DNS) provides a distributed naming service. It allows clients to register named objects and to bind a set of attributes to the objects in a distributed database. o DNA Time Service (DTS) The Digital Network Architecture Time Service (DTS) is a protocol providing global clock synchronization in a distributed environment. o DNA Load/Dump The Digital Network Architecture (DNA) Load/Dump protocol is a maintenance protocol for copying the contents of processor memory to or from a remote system. For example, a system manager can load an operating system into an unattended, remote system. The complete definition of the Phase IV DNA Load/Dump protocol can be found in [3]. o DNA Experimental Use The Digital Network Architecture (DNA) Experimental Use protocol type allows Digital experimental protocols to share a data link with other data link clients. It is for use by Senum [Page 2] Internet Draft DECnet Point-to-Point November 23, 1990 Digital Equipment Corporation only. o DNA Communications Test The Digital Network Architecture (DNA) Communications Test protocol is a maintenance protocol for testing the data link communications path. The complete definition of the DNA Communications Test protocol can be found in [3]. o Digital Protocol X1 The Digital X1 protocol is a network layer protocol currently private to Digital. The following table gives the protocol types assigned to each of these protocols. Protocol Types for Phase IV DECnet Protocol Protocol Type Protocol Type of NCP DNA Phase IV Routing 0027 hex 8027 hex DNA System Console Digital Customer Use DNA Diagnostics DNA Naming Service DNA Time Service DNA Load/Dump DNA Experimental Use DNA Communications Test DNA Protocol X1 Table 1. 3. A PPP Network Control Protocol (NCP) for DECnet The DECnet Control Protocol (DNCP) is responsible for configuring, enabling, and disabling the DECnet protocol modules on both ends of the point-to-point link. As with the Link Control Protocol, this is accomplished through an exchange of packets. DNCP packets may not be exchanged until LCP has reached the Network-Layer Protocol Configuration Negotiation phase. DNCP packets received before this phase is reached should be silently discarded. Likewise, DECnet datagrams may not be exchanged until DNCP has first opened the connection (reached the Open state). The DECnet Control Protocol is exactly the same as the Link Control Protocol with the following exceptions: Senum [Page 3] Internet Draft DECnet Point-to-Point November 23, 1990 Data Link Layer Protocol Field Exactly one DECnet Control Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8027 (DECnet Phase IV Control Protocol). Code field Only Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in Code-Rejects. Timeouts DNCP packets may not be exchanged until the Link Control Protocol has reached the network-layer Protocol Configuration Negotiation phase. An implementation should be prepared to wait for Link Quality testing to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time. 3.1. DECnet Control Protocol Configuration Option Types The value for the Configuration Option Type field is 1 Node Type 3.1.1. Node Type Description This Configuration Option provides a way to ascertain the routing type of the nodes connected by the link. If a router discovers it is connected to an endnode, then the router may choose not to send Update messages over this link. If this Configuration Option is rejected, the router should assume the other end of the link is a Level 2 Router. A summary of the Configuration Option format is shown below. The fields are transmitted from left to right. Senum [Page 4] Internet Draft DECnet Point-to-Point November 23, 1990 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Routing Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length 4 Routing Type 1 Level 2 Router 2 Level 1 Router 3 Endnode 3.2. Sending DECnet Datagrams Before any DECnet packets may be communicated, both the Link Control Protocol and the DECnet Control Protocol must reach Open state. Exactly one octet-count field and one DECnet packet are encapsulated in the information field of PPP Data Link Layer frames where the Protocol field indicates type hex 0027 (DECnet Phase IV). The octet-count contains a count of the number of octets in the DECnet data packet. It is two octets in length itself, and is stored in VAX byte ordering, to be more consistent with DECnet (i.e. least significiant byte first). It is needed to disambiguate padding octets from real information. The maximum length of an DECnet packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame minus 2 octets (for the Length field). The format of the packets themselves is the same as the format used over Ethernet, without the Ethernet header, Pad, and FCS fields. A summary of the information field is shown below. The fields are transmitted from left to right. Senum [Page 5] Internet Draft DECnet Point-to-Point November 23, 1990 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length LSB | Length MSB | DATA | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length LSB Least significant byte of length field Length MSG Most significant byte of length field DATA DNA Phase IV Routing data, as specified in [2] 3.3. Other considerations When a topology change in the network occurs, DNA Phase IV Routing nodes immediately propagate changes via Level 1 and Level 2 Routing messages, with a 1 second minimum delay between updates. DNA Phase IV Routing nodes also periodically retransmit the complete Level 1 and Level 2 distance vectors to guard against data corruption in host memory, and (in the case of Ethernet) loss of packets due to media errors. Because Digital's serial links run a protocol that guarantees delivery of packets (DDCMP), the recommended default retransmit time is long (600 seconds), whereas for Ethernet, where packet delivery is not guaranteed, the recommended default is short (10 seconds). To achieve convergence of routes within a satisfactory time, the interval between updates must be based upon the error rate of underlying data link. The following values are recommended for the routing update timer on PPP links. o For bit error rates greater than 1 in 10^7, a reliable protocol (e.g. HDLC) may have to be used instead of PPP to achieve acceptable performance. o For bit error rates between 1 in 10^7 and 1 in 10^9, complete routing updates should be sent every 10 seconds. o For bit error rates less than 1 in 10^9, complete routing updates should be sent every 30 seconds. Senum [Page 6] Internet Draft DECnet Point-to-Point November 23, 1990 It is also recommended that the time between routing updates be user configurable per PPP inteface. The Hello timer and Listen timer shall be set according to the recommendations for broadcast links (15 and 45 seconds, respectively). Routers are not required to send routing updates if the remote node connected via the PPP link is an endnode. Endnodes are required to discard all routing updates received over a PPP link. Phase IV Routing should not be run over links of speed less than 56 Kbits per second. This will ensure that routing updates will never consume more that 3% of the nominal link bandwidth. Senum [Page 7] Internet Draft DECnet Point-to-Point November 23, 1990 References [1] Perkins, D., "The Point-to-Point Protocol for the Transmission of Multi-Protocol Datagrams Over Point-to-Point Links", RFC 1171, Carnegie Mellon Univerisity, July 1990. [2] Digital Equipment Corporation, "DNA Routing Layer Functional Specification", Version 2.0.0, Order No. AA-X435A-TK. [3] Digital Equipment Corporation, "DNA Maintenance Operations Functional Specification", Version 3.0.0, Order No. AA-X436A- TK. Security Considerations Security issues are not discussed in this memo. Chairman's Address This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). The working group can be contacted via the chair: Stev Knowles FTP Software 26 Princess Street Wakefield, MA 01880-3004 Phone: (617) 246-0900 x270 EMail: Stev@FTP.com Author's Address Questions about this memo can also be directed to the author: Steven J. Senum Network Systems Corporation 7600 Boone Avenue North Minneapolis, MN 55428 Phone: (612) 424-4888 EMail: sjs@network.com Senum [Page 8] Internet Draft DECnet Point-to-Point November 23, 1990 Acknowledgments The author wishes to thank Jim Muchow (Network Systems Corporation), and Arthur Harvey (Digital Equipment Corporation) for their input to this memo. Senum [Page 9] From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 16 00:45:26 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18005; Tue, 16 Apr 91 00:30:26 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17889; Tue, 16 Apr 91 00:21:22 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA25591; Tue, 16 Apr 91 03:21:28 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9104160721.AA25591@vela.acs.oakland.edu> Subject: revised PPP RFC To: ietf-ppp@ucdavis.edu Date: Tue, 16 Apr 91 3:21:23 EDT X-Mailer: ELM [version 2.3 PL6] As promised, I spent a few dozen hours reading the message archive and updated the PPP RFC. I also fixed 60 or so typing errors. This version of the PPP RFC has the LCP Options and LQM included. I am working on a separate IPCP RFC which includes McGregor's as yet unpublished Compression Option description. I am also making an Authentication Protocol RFC. If there has been any work on improved Authentication protocols, please let me know. Telebit has graciously agreed to submit a Kerberos-like one. Please pay special attention to the revised sections on the PPP Link Phases, and the revised Automaton. When making changes, I took great pains to ensure that *exactly* the same packets are exchanged as before. No old implementation should see any external differences, except that the new FSM will be ready to reconfigure without operator intervention. Most of the typing errors were in the LQM sections. While I think that I fixed them all, please see if all these similarly named variables make sense now. My Eyes Glaze Over. Finally, I can't figure out how to get the FORMFEED in the macros to actually generate a form-feed. I assume that someone out there knows what filter to use. Please tell me (and the list). Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu -------------------------------------------------------------------------------- Network Working Group Simpson Request for Comments: ???? editor Obsoletes: RFC 1171 & 1172 April 1991 The Point-to-Point Protocol 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. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. This proposal is the 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 Point-to-Point Protocol Working Group chair. 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 an extensible option negotiation protocol, which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. Although the option negotiation protocol 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 updated by Simpson FORMFEED[Page i] RFC ???? Point-to-Point Protocol April 1991 NCPs. The facilities and options used by IPCP are defined in a separate document. Control protocols for configuring and utilizing other network-layer protocols besides IP (e.g., DECNET, OSI) are expected to be developed as needed. updated by Simpson FORMFEED[Page ii] RFC ???? Point-to-Point Protocol April 1991 1. Introduction 1.1. 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. 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. One purpose of this memo is to remedy this problem. But even more importantly, the Point-to-Point Protocol proposes more than just an encapsulation scheme. 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 circuits (such as dial-ups). Some additional issues addressed by this specification of PPP include asynchronous (start/stop) and bit-oriented synchronous encapsulation, network protocol multiplexing, link configuration, link quality testing, peer authentication, error detection, and option negotiation for such capabilities as network-layer address negotiation and data compression negotiation. PPP addresses these issues by providing an extensible Link Control Protocol (LCP) and a family of Network Control Protocols (NCPs) to negotiate optional configuration parameters and facilities. 1.2. Overview of PPP PPP has three main components: 1. A method for encapsulating datagrams over serial links. PPP uses HDLC as a basis for encapsulating datagrams over point- to-point links. At this time, PPP specifies the use of updated by Simpson FORMFEED[Page 1] RFC ???? Point-to-Point Protocol April 1991 asynchronous or synchronous duplex circuits, either dedicated or circuit switched. 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. PPP is designed to allow the simultaneous use of multiple network- layer protocols. In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, PPP must send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link. The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (an inactivity timer expires or network administrator intervention). 1.3. Organization of the document This memo is divided into several sections. Section 2 discusses the physical-layer requirements of PPP. Section 3 describes the Data Link Layer including the PPP frame format and data link encapsulation scheme. Section 4 delineates the process of PPP link establishment, authentication, quality determination, and termination. Section 5 defines the option negotiation finite state automaton, and Section 6 defines the packet format used with the automaton by LCP. Section 7 specifies the LCP configuration options. Section 8 presents a model for Link Quality Monitoring. Appendix A summarizes important features of asynchronous HDLC, and Appendix B describes an efficient table-lookup algorithm for fast Frame Check Sequence (FCS) computation. updated by Simpson FORMFEED[Page 2] RFC ???? Point-to-Point Protocol April 1991 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 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 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). However, using such signals when available can allow greater functionality and performance. updated by Simpson FORMFEED[Page 3] RFC ???? Point-to-Point Protocol April 1991 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. Note: ISO 3309:1984/PDAD1 is a Proposed Draft standard. At present, it seems that ISO 3309:1984/PDAD1 is stable and likely to become an International Standard. Therefore, we feel comfortable about using it before it becomes an International Standard. The progress of this proposal should be tracked and encouraged by the Internet community. 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. updated by Simpson FORMFEED[Page 4] RFC ???? Point-to-Point Protocol April 1991 3.1. Frame Format A summary of the standard PPP frame structure is shown below. The fields are transmitted from left to right. +----------+----------+----------+----------+------------ | Flag | Address | Control | Protocol | Information | 01111110 | 11111111 | 00000011 | 16 bits | * +----------+----------+----------+----------+------------ ---+---------+----------+ | FCS | Flag | | 16 bits | 01111110 | ---+---------+----------+ This figure does not include start/stop bits (for asynchronous links) or any bits or octets inserted for transparency. When asynchronous links are used, all octets are transmitted with one start bit, eight bits of data, and one stop bit. There is no provision in either PPP or ISO 3309:1984/PDAD1 for seven bit asynchronous links. 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 order). Keep this in mind when comparing this document with the international standards documents. Flag Sequence The Flag Sequence is a single octet and indicates the beginning or end of a frame. The Flag Sequence consists of the binary sequence 01111110 (hexadecimal 0x7e). Address Field The Address field is a single octet and contains the binary sequence 11111111 (hexadecimal 0xff), the All-Stations address. PPP does not assign individual station addresses. The All-Stations address should always be recognized and received. The use of other address lengths and values may be defined at a later time, or by prior agreement. Frames with unrecognized Addresses should be reported through the normal network management facility. Control Field The Control field is a single octet and contains the binary sequence 00000011 (hexadecimal 0x03), the Unnumbered Information (UI) command updated by Simpson FORMFEED[Page 5] RFC ???? Point-to-Point Protocol April 1991 with the P/F bit set to zero. Frames with other Control field values should be silently discarded. Protocol Field The Protocol field is two octets and its value identifies the protocol encapsulated in the Information field of the frame. This Protocol field is defined by PPP and is not a field defined by HDLC. However, the Protocol field is consistent with the ISO 3309 extension mechanism for Address fields. All Protocols MUST be odd; the least significant bit of the least significant octet MUST equal "1". Also, all Protocols MUST be assigned such that the least significant bit of the most significant octet equals "0". Frames received which don't comply with these rules should be considered as having an unrecognized Protocol, and should be handled as specified by the LCP. The Protocol field is transmitted and received most significant octet first. Protocol field values in the "cxxx" range identify datagrams as belonging to the Link Control Protocol (LCP) or associated protocols. Values in the "8xxx" range identify datagrams belonging to the family of Network Control Protocols (NCPs). Values in the "0xxx" range identify the network protocol of specific datagrams. updated by Simpson FORMFEED[Page 6] RFC ???? Point-to-Point Protocol April 1991 The most up-to-date values of the Protocol field are specified in the most recent "Assigned Numbers" RFC [11]. Current values are assigned as follows: Value (in hex) Protocol 0001 to 001f reserved (transparency inefficient) 0021 Internet Protocol 0023 * OSI Network Layer 0025 * Xerox NS IDP 0027 * DECnet Phase IV 0029 * Appletalk 002b * Novell IPX 002d * Van Jacobson Compressed TCP/IP 002f * Van Jacobson Uncompressed TCP/IP 00ff reserved (compression inefficient) 8021 Internet Protocol Control Protocol 8023 * OSI Network Layer Control Protocol 8025 * Xerox NS IDP Control Protocol 8027 * DECnet Phase IV Control Protocol 8029 * Appletalk Control Protocol 802b * Novell IPX Control Protocol 802d * Reserved 802f * Reserved c021 Link Control Protocol c023 * Password Authentication Protocol * Reserved for future use; not described in this document. Information Field The Information field is zero or more octets. The Information field contains the datagram for the protocol specified in the Protocol field. The end of the Information field is found by locating the closing Flag Sequence and allowing two octets for the Frame Check Sequence field. The default maximum length of the Information field is 1500 octets. By prior agreement, consenting PPP implementations may use other values for the maximum Information field length. On transmission, the Information field may be padded with an arbitrary number of octets up to the maximum length. It is the responsibility of each protocol to disambiguate padding octets from real information. updated by Simpson FORMFEED[Page 7] RFC ???? Point-to-Point Protocol April 1991 Frame Check Sequence (FCS) Field The Frame Check Sequence field is normally 16 bits (two octets). By prior agreement, consenting PPP implementations may use a 32-bit (four-octet) FCS for improved error detection. The FCS field is calculated over all bits of the Address, Control, Protocol and Information fields not including any start and stop bits (asynchronous) and any bits (synchronous) or octets (asynchronous) inserted for transparency. This does not include the Flag Sequences or FCS field. The FCS is transmitted with the coefficient of the highest term first. Note: When octets are received which are flagged in the Async- Control-Character-Map, they are discarded before calculating the FCS. See the description in Appendix A. For more information on the specification of the FCS, see ISO 3309 [2] or CCITT X.25 [6]. Note: A fast, table-driven implementation of the 16-bit FCS algorithm is shown in Appendix B. This implementation is based on [7], [8], and [9]. Modifications to the Basic Frame Format The Link Control Protocol can negotiate modifications to the standard PPP frame structure. However, modified frames will always be clearly distinguishable from standard frames. updated by Simpson FORMFEED[Page 8] RFC ???? Point-to-Point Protocol April 1991 4. PPP Link Control In the process of configuring, maintaining and terminating the point-to-point link, the PPP link goes through several distinct phases: Link Dead (physical-layer not ready) The link necessarily begins and ends with this phase. When an external event (such as carrier detect or network administrator configuration) indicates that the physical-layer is ready to be used, PPP will proceed to the Link Establishment phase. Typically, a link will return to this phase automatically after the disconnection of a modem. In the case of a hard-wired line, this phase may be extremely short -- merely long enough to detect the presence of a connection. Note: This phase is distinct from the Closed state of the LCP automaton. When a Passive-Open command (described below) occurs while in this phase, the LCP automaton will transit to the Listen state. For an Active-Open command, the action should be postponed until the Link Establishment phase. It is suggested, based on user comments, that the LCP state be set to Listen while the Active-Open is pending. Link Establishment Phase The Link Control Protocol (LCP) is used to establish the connection through an exchange of Configure packets. This exchange is complete, and the LCP Opened state entered, once a Configure-Ack packet (described below) has been both sent and received. Any non-LCP packets received during this phase should be silently discarded. All Configuration Options are assumed to be at default values unless altered by the configuration exchange. See the section on LCP Configuration Options for further discussion. It is important to note that only Configuration Options which are independent of particular network-layer protocols are configured by LCP. Configuration of individual network-layer protocols is handled by separate Network Control Protocols (NCPs) during the Network-Layer Protocol phase. Authentication Phase On some links it may be desirable to require a peer to updated by Simpson FORMFEED[Page 9] RFC ???? Point-to-Point Protocol April 1991 authenticate itself before allowing network-layer protocol packets to be exchanged. By default, authentication is not necessary. If an implementation requires that the remote end authenticate with some specific authentication protocol, then it must negotiate the use of that authentication protocol during Link Establishment phase. Authentication should take place as soon as possible after link establishment. However, link quality determination may occur concurrently. An implementation should not allow the exchange of link quality determination packets to delay authentication indefinitely. Advancement from the Authentication phase to the Network-Layer Protocol phase must not occur until the peer is successfully authenticated using the negotiated authentication protocol. In the event of failure to authenticate, PPP should proceed instead to the Link Termination phase. To prevent discovery of authentication passwords and algorithms, transmission of authentication protocols should be limited to this phase. Any authentication protocol packets received during any other phase should be silently discarded. Network-Layer Protocol Phase Once PPP has finished the previous phases, each network-layer protocol (such as IP) may be separately configured by the appropriate Network Control Protocol (NCP). Each NCP may be Opened and Closed at any time. In particular, because an implementation may initially use a significant amount of time for link quality determination, implementations should avoid fixed timeouts when waiting for their peers to configure a NCP. After a NCP has reached the Opened state, PPP may transmit the corresponding network-layer protocol packets. Any network-layer protocol packets received when the corresponding NCP is not in the Opened state should be silently discarded. During this phase, link traffic consists of any possible combinations of LCP, NCP, and network-layer protocol packets. Any NCP or network-layer protocol packets received during any other phase should be silently discarded. Note: There is an exception to the preceding paragraphs, due to updated by Simpson FORMFEED[Page 10] RFC ???? Point-to-Point Protocol April 1991 the availability of the LCP Protocol-Reject (described below). While LCP is in the Opened state, any protocol packet which is unsupported by the implementation is returned in a Protocol- Reject. Only supported protocols are silently discarded. Link Termination Phase PPP may terminate the link at any time. This will usually be done at the request of a human user, but may happen because of a physical event such as the loss of carrier, authentication failure, link quality failure, or the expiration of an idle-period timer. LCP is used to close the link through an exchange of Terminate packets. When the link is closing, PPP informs the network-layer protocols so that they may take appropriate action. After the exchange of Terminate packets, the implementation may wish to signal the physical-layer to disconnect in order to enforce the termination of the link, particularly in the case of an authentication failure. PPP should proceed to the Link Dead phase. Note: The closing of the link by LCP is sufficient. There is no need for each NCP to send a flurry of Terminate packets. Conversely, the fact that a NCP has Closed is not sufficient reason to cause the termination of the PPP link, even if that NCP was the only currently Opened NCP. Link Quality Determination During the Authentication and Network-Layer Protocol phases, the link may be tested to determine if quality is sufficient for operation. This testing is completely optional. The procedure for link quality determination is unspecified and may vary from implementation to implementation, or because of user-configured parameters, but only so long as the procedure doesn't violate other aspects of LCP. One suggested method is to use LCP Link-Quality-Report packets (described below). updated by Simpson FORMFEED[Page 11] RFC ???? Point-to-Point Protocol April 1991 5. The Option Negotiation Automaton The finite-state automaton is defined by events, state transitions and actions. Events include receipt of external commands such as Open and Close, expiration of the Restart timer, and receipt of packets from a peer. Actions include the starting of the Restart timer and transmission of packets. 5.1. State Diagram The state diagram which follows describes the sequence of events for reaching agreement on Configuration Options (opening the PPP connection) and for later closing of the connection. The state machine is initially in the Closed state (1). Once the Opened state (6) has been reached, both ends of the link have met the requirement of having both sent and received a Configure-Ack packet. In the state diagram, events are shown above horizontal lines. Actions are shown below horizontal lines. Two types of packets -- Configure-Naks and Configure-Rejects -- are not differentiated in the state diagram. As will be described later, these packets do indeed serve different, though similar, functions. However, at the level of detail of this state diagram, they always cause the same transition. Since a more detailed specification of the automaton is given in a state transition table in the following section, implementation should be done by consulting it rather than this state diagram. updated by Simpson FORMFEED[Page 12] RFC ???? Point-to-Point Protocol April 1991 +----------------------------------------------------+ | | V | +---2---+ PO +---1---+ RTA +---7---+ | | |<-------------| |<-----------| | | |Listen | |Closed | |Closing| | RCR | | C | | | | | +----| |------------->| | | |<--+ | |scr +-------+ +-------+ +-------+ | | | AO | | TO | | | --- | +---->+ | | SCR | str ^ | | RCN/TO | | | | +-------->+<--------+ | | | | scr | | | | +---3---+ V TO +---4---+ +-------+ | | | | |<-----+<------| |<-----------| | | | | | Req- | scr | Ack- | scn | Good | | | | | Sent | RCA | Rcvd | RCR | Req? | | | | | |------------->| |----------->| | | | | +-------+ +-------+ +-------+ | | | | ^ | | | | RCR | +<--------+ | | | | --- | | | TO RCN --- | | | | | | --- +---------+ +-----+ sca | | | | V | scn scr | | scr | V | | | +-------+ +---5---+ | +---6---+ C | | +--->| |------------->| |<--+ | |---+ | | Good | sca | Ack- | |Opened | str | | Req? | RCR | Sent | RCA | | | | |<-------------| |----------->| | | +-------+ +-------+ +-------+ | ^ | | | | RCR | | RTR | +---------------------------------------+ +--------+ scr sta Events Actions RCR - Receive-Configure-Request scr - Send Configure-Request RCA - Receive-Configure-Ack sca - Send Configure-Ack RCN - Receive-Configure-Nak or Reject scn - Send Configure-Nak RTR - Receive-Terminate-Req or Reject RTA - Receive-Terminate-Ack str - Send Terminate-Req AO - Active-Open sta - Sent Terminate-Ack PO - Passive-Open C - Close TO - Timeout updated by Simpson FORMFEED[Page 13] RFC ???? Point-to-Point Protocol April 1991 5.2. State Transition Table The complete state transition table follows. States are indicated horizontally, and events are read vertically. State transitions and actions are represented in the form action/new-state. Two actions caused by the same event are represented as action1&action2. | State | 1 2 3 4 5 6 7 Events| Closed Listen Req-Sent Ack-Rcvd Ack-Sent Opened Closing ------+------------------------------------------------------------- AO | scr/3 scr/3 3 4 5 6 scr/3 PO | 2 2 3 4 5 6 7 C | 1 1 7* 7* str/7 str/7 7 PLD | 1 2 2 2 2 2 1* TO+ | 1 2 scr/3 scr/3 scr/3 6 str/7 TO- | 1 2 2 2 2 6 1* | RCR+ | sta/1 scr&sca/5 sca/5 sca/6 sca/5 scr&sca/5 7 RCR- | sta/1 scr&scn/3 scn/3 scn/4 scn/3 scr&scn/3 7 RCA | sta/1 sta/2 4 scr/3 6 scr/3 7 RCN | sta/1 sta/2 scr/3 scr/3 scr/5 scr/3 7 | RTR | sta/1 sta/2 sta/3 sta/3 sta/3 sta/2 sta/7 RTA | 1 2 3 3 3 scr/3 1* | RUC | scj/1 scj/2 scj/2 scj/2 scj/2 scj/2 scj/7 RCJ | 1 2 2 2 2 2 1* RER | sta/1 sta/2 3 4 5 ser/6 7 Events Actions TO+ - Timeout with counter > 0 TO- - Timeout with counter expired PLD - Physical-Layer-Down RCR+ - Receive-Configure-Request (Good) RCR- - Receive-Configure-Request (Bad) RCJ - Receive-Code-Reject RER - Receive-Echo-Request ser - Send-Echo-Reply RUC - Receive-Unknown-Code scj - Send-Code-Reject 1* - if Passive-Open since Close, go to Listen 7* - should set restart counter to 0. 5.3. Events Transitions and actions in the automaton are caused by events. Some updated by Simpson FORMFEED[Page 14] RFC ???? Point-to-Point Protocol April 1991 events are caused by commands executed at the local end (such as Active-Open, Passive-Open, and Close), others are caused by the receipt of packets from the remote end (such as Receive-Configure- Request, Receive-Configure-Ack, Receive-Configure-Nak, Receive- Terminate-Request and Receive-Terminate-Ack), and still others are caused by the expiration of the Restart timer started as the result of other events (Timeout). Active-Open (AO) The Active-Open event indicates the local execution of an Active- Open command by the network administrator (human or program). When this event occurs, the implementation should immediately attempt to open the connection by exchanging configuration packets with the remote peer. The actual event may be delayed until the physical-layer is ready (see Link Dead phase described above). Typically, the implementation will set a flag that will cause the Active-Open event to occur whenever the link progresses from the Link Dead phase to the Link Establishment phase. Passive-Open (PO) The Passive-Open event indicates the local execution of a Passive-Open command. the implementation should wait for the peer to send the first packet. This will only happen after an Active- Open event in the peer. The actual event MUST be delayed until any previous incarnation of the link has completely terminated. Typically, the implementation will set a flag that will cause the Passive-Open event to occur whenever the automaton state transits from Closing to Closed. Note: Use of the Active-Open command is to be preferred over the Passive-Open command whenever possible. Close (C) The Close event indicates the local execution of a Close command. When this event occurs, the implementation should immediately attempt to close the connection. It is presumed that the execution of an Active-Open or Passive- Open command mandates the establishment of the link until a Close command. Typically, the Close command will clear the flags set by the Active-Open and Passive-Open commands. updated by Simpson FORMFEED[Page 15] RFC ???? Point-to-Point Protocol April 1991 Note: To ensure that at least one Timeout interval has passed prior to any possible Passive-Open, transitions to the Closed state pass through the Closing state. Where the remote end may consider the link to be fully-Opened, a Terminate-Request is sent and the Restart timer and counter are set. Where the remote end may consider the link to be half-Opened, the Restart counter is cleared, and the current Restart timer is allowed to expire. Physical-Layer-Down (PLD) The Physical-Layer-Down event occurs when the Physical Layer indicates that it is down. Timeout (TO) The Timeout event indicates the expiration of the Restart timer. The Restart timer is used to time out transmissions of Configure- Request and Terminate-Request packets. Expiration of the Restart timer causes a Timeout event, which triggers the corresponding Configure-Request or Terminate-Request packet to be retransmitted. Receive-Configure-Request (RCR) The Receive-Configure-Request event occurs when a Configure- Request packet is received from the peer. The Configure-Request packet indicates the desire to open a connection and may specify Configuration Options. The Configure-Request packet is more fully described in a later section. Note: This event may occur on a connection which is already in the Opened state. The implementation must be prepared to immediately renegotiate the Configuration Options. Receive-Configure-Ack (RCA) The Receive-Configure-Ack event occurs when a valid Configure-Ack packet is received from the peer. The Configure-Ack packet is a positive response to a Configure-Request packet. Receive-Configure-Nak (RCN) The Receive-Configure-Nak event occurs when a valid Configure-Nak or Configure-Reject packet is received from the peer. The Configure-Nak and Configure-Reject packets are negative responses to a Configure-Request packet. Note: Although the Configure-Nak and Configure-Reject cause the updated by Simpson FORMFEED[Page 16] RFC ???? Point-to-Point Protocol April 1991 same state transition in the automaton, these packets have significantly different effects on the Configuration Options sent in the resulting Configure-Request packet. Receive-Terminate-Request (RTR) The Receive-Terminate-Request event occurs when a Terminate- Request packet is received. The Terminate-Request packet indicates the desire of the remote end of the link to close the link. Note: This event is not identical to the Close event (see above), and should not override the expressed commands of the local network administrator. The Terminate-Request may be immediately followed by a new Configure-Request, and the local machine must be prepared to receive it without network administrator intervention. Receive-Terminate-Ack (RTA) The Receive-Terminate-Ack event occurs when a Terminate-Ack packet is received from the peer. The Terminate-Ack packet is a usually response to a Terminate-Request packet. The Terminate-Ack packet may also indicate that the remote end is unexpectedly in Closed or Listen state, and serves to re-synchronize the link configuration. Receive-Unknown-Code (RUC) The Receive-Unknown-Code event occurs when an un-interpretable packet is received from the peer. A Code-Reject packet is sent in response. Receive-Code-Reject (RCJ) The Receive-Code-Reject event occurs when a Code-Reject packet is received from the peer. The Code-Reject packet communicates an unrecoverable error that immediately terminates the connection. Receive-Echo-Request (RER) The Receive-Echo-Request event occurs when a Echo-Request, Echo- Reply, Discard-Request or Link-Quality-Report packet is received from the peer. The Echo-Reply packet is a response to a Echo- Request packet. There is no reply to a Discard-Request or Link- Quality-Report. updated by Simpson FORMFEED[Page 17] RFC ???? Point-to-Point Protocol April 1991 5.4. Actions Actions in the automaton are caused by events and typically indicate the transmission of packets and/or the starting or stopping of the Restart timer. Following is a list of actions: Send-Configure-Request (scr) The Send-Configure-Request action transmits a Configure-Request packet. This indicates the desire to open a connection with a specified set of Configuration Options. The Restart timer is started after the Configure-Request packet is transmitted, to guard against packet loss. Send-Configure-Ack (sca) The Send-Configure-Ack action transmits a Configure-Ack packet. This acknowledges the receipt of a Configure-Request packet with an acceptable set of Configuration Options. Send-Configure-Nak (scn) The Send-Configure-Nak action transmits a Configure-Nak or Configure-Reject packet, as appropriate. This negative response reports the receipt of a Configure-Request packet with an unacceptable set of Configuration Options. Configure-Nak packets are used to refuse a Configuration Option value, and to suggest a new, acceptable value. Configure-Reject packets are used to refuse all negotiation about a Configuration Option, typically because it is not recognized or implemented. The use of Configure-Nak versus Configure-Reject is more fully described in the section on LCP Packet Formats. Send-Terminate-Req (str) The Send-Terminate-Request action transmits a Terminate-Request packet. This indicates the desire to close a connection. The Restart timer is started after the Terminate-Request packet is transmitted, to guard against packet loss. Send-Terminate-Ack (sta) The Send-Terminate-Request action transmits a Terminate-Ack packet. This acknowledges the receipt of a Terminate-Request packet or otherwise confirms the belief that the connection is Closed. updated by Simpson FORMFEED[Page 18] RFC ???? Point-to-Point Protocol April 1991 Send-Code-Reject (scj) The Send-Code-Reject action transmits a Code-Reject packet. This indicates the receipt of an unknown type of packet. Send-Echo-Reply (ser) The Send-Echo-Reply action transmits an Echo-Reply packet. This acknowledges the receipt of an Echo-Request packet. 5.5. States Following is a more detailed description of each automaton state. Closed (1) The initial and final state is the Closed state. In the Closed state the connection is down and there is no attempt to open it; all connection requests from peers are rejected. The Restart timer is not running in the Closed state. There are two events which cause a transition out of the Closed state, Active-Open and Passive-Open. Upon an Active-Open event, a Configure-Request is transmitted, the Restart timer is started, and the Request-Sent state is entered. Upon a Passive-Open event, the Listen state is entered immediately. Upon receipt of most packets, a Terminate-Ack is sent. Terminate-Acks are silently discarded to avoid creating a loop. Unknown codes generate the usual Code-Reject response. Listen (2) The Listen state is similar to the Closed state in that the connection is down and there is no attempt to open it. However, peer connection requests are no longer rejected. The Restart timer is not running in the Listen state. Upon receipt of a Configure-Request, a Configure-Request is immediately transmitted and the Restart timer is started. The received Configuration Options are examined and the proper response is sent. If a Configure-Ack is sent, the Ack-Sent state is entered. Otherwise, if a Configure-Nak or Configure-Reject is sent, the Request-Sent state is entered. In either case, the automaton exits its passive state, and begins to actively open the connection. Terminate-Ack packets are sent in response to most other packets. Unknown codes generate the usual Code-Reject response. updated by Simpson FORMFEED[Page 19] RFC ???? Point-to-Point Protocol April 1991 Request-Sent (3) In the Request-Sent state an active attempt is made to open the connection. A Configure-Request has been sent and the Restart timer is running, but a Configure-Ack has not yet been received nor has one been sent. Upon receipt of a Configure-Ack, the Ack-Received state is immediately entered. Upon receipt of a Configure-Nak or Configure-Reject, the Configure-Request Configuration Options are adjusted appropriately, a new Configure-Request is transmitted, and the Restart timer is restarted. Similarly, upon the expiration of the Restart timer, a new Configure-Request is transmitted and the Restart timer is restarted. Upon receipt of a Configure-Request, the Configuration Options are examined and if acceptable, a Configure-Ack is sent and the Ack-Sent state is entered. If the Configuration Options are unacceptable, a Configure-Nak or Configure-Reject is sent as appropriate. Since there is an outstanding Configure-Request in the Request- Sent state, special care must be taken to implement the Passive- Open and Close events; otherwise, it is possible for the peer to think the connection is open. Processing of either event should be postponed until there is reasonable assurance that the peer is not open. In particular, the Restart timer should be allowed to expire. Ack-Received (4) In the Ack-Received state, a Configure-Request has been sent and a Configure-Ack has been received. The Restart timer is still running since a Configure-Ack has not yet been transmitted. Upon receipt of a Configure-Request with acceptable Configuration Options, a Configure-Ack is transmitted, the Restart timer is stopped and the Opened state is entered. If the Configuration Options are unacceptable, a Configure-Nak or Configure-Reject is sent as appropriate. Upon the expiration of the Restart timer, a new Configure-Request is transmitted, the Restart timer is restarted, and the state machine returns to the Request-Sent state. Ack-Sent (5) In the Ack-Sent state, a Configure-Ack and a Configure-Request have been sent but a Configure-Ack has not yet been received. The Restart timer is always running in the Ack-Sent state. updated by Simpson FORMFEED[Page 20] RFC ???? Point-to-Point Protocol April 1991 Upon receipt of a Configure-Ack, the Restart timer is stopped and the Opened state is entered. Upon receipt of a Configure-Nak or Configure-Reject, the Configure-Request Configuration Options are adjusted appropriately, a new Configure-Request is transmitted, and the Restart timer is restarted. Upon the expiration of the Restart timer, a new Configure-Request is transmitted, the Restart timer is restarted, and the state machine returns to the Request- Sent state. Opened (6) In the Opened state, a connection exists and data may be communicated over the link. The Restart timer is not running in the Opened state. Upon receipt of a Close command, a Terminate-Request is transmitted, the Restart timer is started, and the Closing state is entered. Upon receipt of a Terminate-Request, a Terminate-Ack is transmitted and the Listen state is entered. Upon receipt of an Echo-Request, an Echo-Reply is transmitted. Similarly, Echo- Reply, Discard-Request and Link-Quality-Report packets are processed as expected without changing state. Receipt of a Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, or a Terminate-Ack indicate that the peer desires to reconfigure, or is out of step. In these cases, a Configure-Request packet is transmitted, the Restart timer is started, and the state is changed to reflect the renegotiation. Closing (7) In the Closing state, an active attempt is made to close the connection. A Terminate-Request has been sent and the Restart timer is running, but a Terminate-Ack has not yet been received. Upon receipt of a Terminate-Ack, the Closed state is immediately entered. Upon the expiration of the Restart timer, a new Terminate-Request is transmitted and the Restart timer is restarted. After the Restart timer has expired Max-Terminate times, this action may be skipped, and the Closed state may be entered. Since there is an outstanding Terminate-Request in the Closing state, special care must be taken to implement the Passive-Open event; otherwise, it is possible for the peer to think the connection is open. Processing of the Passive-Open event should be postponed until there is reasonable assurance that the peer is not open. In particular, the implementation should wait until the updated by Simpson FORMFEED[Page 21] RFC ???? Point-to-Point Protocol April 1991 state machine would normally transition to the Closed state because of a Receive-Terminate-Ack event or Max-Terminate Timeout events. 5.6. Loop Avoidance The protocol makes a reasonable attempt at avoiding Configuration Option negotiation loops. However, the protocol does NOT guarantee that loops will not happen. As with any negotiation, it is possible to configure two PPP implementations with conflicting policies that will never converge. It is also possible to configure policies which do converge, but which take significant time to do so. Implementors should keep this in mind and should implement loop detection mechanisms or higher level timeouts. If a timeout is implemented, it MUST be configurable. 5.7. Timers and Counters Restart Timer There is one special timer used by the automaton. The Restart timer is used to time out transmissions of Configure-Request and Terminate-Request packets. Expiration of the Restart timer causes a Timeout event, and retransmission of the corresponding Configure- Request or Terminate-Request packet. The Restart timer MUST be configurable, but should default to three (3) seconds. Max-Terminate There is one required restart counter. Max-Terminate indicates the number of Terminate-Request packet transmissions that are required before there is reasonable assurance that the link closed. Max- Terminate MUST be configurable, but should default to ten (10) transmissions. Max-Configure A similar counter is recommended for Configure-Request restarts. Max-Configure indicates the number of Configure-Request packet transmissions without receiving a Configure-Ack or Configure-Nak before assuming that the remote end is unable to respond. Max- Configure MUST be configurable, but should default to twenty (20) transmissions. Max-Failure A related counter is recommended for Configure-Nak. Max-Failure updated by Simpson FORMFEED[Page 22] RFC ???? Point-to-Point Protocol April 1991 indicates the number of Configure-Nak packet transmissions that are sent before assuming that configuration is not converging. Any further Configure-Nak packets are converted to Configure-Reject packets. Max-Failure MUST be configurable, but should default to ten (10) transmissions. updated by Simpson FORMFEED[Page 23] RFC ???? Point-to-Point Protocol April 1991 6. LCP Packet Formats There are three classes of LCP packets: 1. Link Configuration packets used to establish and configure a link (Configure-Request, Configure-Ack, Configure-Nak and Configure-Reject). 2. Link Termination packets used to terminate a link (Terminate- Request and Terminate-Ack). 3. Link Maintenance packets used to manage and debug a link (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, Discard-Request, and Link-Quality-Report). Exactly one Link Control Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex c021 (Link Control Protocol). A summary of the Link Control Protocol packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code The Code field is one octet and identifies the kind of LCP packet. When a packet is received with an invalid Code field, a Code- Reject packet is transmitted. updated by Simpson FORMFEED[Page 24] RFC ???? Point-to-Point Protocol April 1991 The most up-to-date values of the LCP Code field are specified in the most recent "Assigned Numbers" RFC [11]. Current values are assigned as follows: 1 Configure-Request 2 Configure-Ack 3 Configure-Nak 4 Configure-Reject 5 Terminate-Request 6 Terminate-Ack 7 Code-Reject 8 Protocol-Reject 9 Echo-Request 10 Echo-Reply 11 Discard-Request 12 Link-Quality-Report Identifier The Identifier field is one octet and aids in matching requests and replies. When a packet is received with an invalid Identifier field, the packet should be silently discarded. Length The Length field is two octets and indicates the length of the LCP packet including the Code, Identifier, Length and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. When a packet is received with an invalid Length field, the packet should be silently discarded. Data The Data field is zero or more octets as indicated by the Length field. The format of the Data field is determined by the Code field. Regardless of which Configuration Options are enabled, all LCP packets are always sent in the full, standard form, as if no Configuration Options were enabled. This ensures that LCP Configure-Request packets are always recognizable even when one end of the link mistakenly believes the link to be open. This document describes Version 1 of the Link Control Protocol. In the interest of simplicity, there is no version field in the LCP packet. If a new version of LCP is necessary in the future, the intention is that a new Data Link Layer Protocol field value should be used to differentiate Version 1 LCP from all other versions. A correctly functioning Version updated by Simpson FORMFEED[Page 25] RFC ???? Point-to-Point Protocol April 1991 1 LCP implementation will always respond to unknown Protocols (including other versions) with an easily recognizable Version 1 packet, thus providing a deterministic fallback mechanism for implementations of other versions. updated by Simpson FORMFEED[Page 26] RFC ???? Point-to-Point Protocol April 1991 6.1. Configure-Request Description A LCP implementation wishing to open a connection MUST transmit a LCP packet with the Code field set to 1 (Configure-Request) and the Options field filled with any desired changes to the default link Configuration Options. Upon reception of a Configure-Request, an appropriate reply MUST be transmitted. A summary of the Configure-Request packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+ Code 1 for Configure-Request. Identifier The Identifier field should be changed on each transmission. On reception, the Identifier field should be copied into the Identifier field of the appropriate reply packet. Options The options field is variable in length and contains the list of zero or more Configuration Options that the sender desires to negotiate. All Configuration Options are always negotiated simultaneously. The format of Configuration Options is further described in a later section. updated by Simpson FORMFEED[Page 27] RFC ???? Point-to-Point Protocol April 1991 6.2. Configure-Ack Description If every Configuration Option received in a Configure-Request is both recognizable and acceptable, then a LCP implementation should transmit a LCP packet with the Code field set to 2 (Configure- Ack), the Identifier field copied from the received Configure- Request, and the Options field copied from the received Configure-Request. The acknowledged Configuration Options MUST NOT be reordered or modified in any way. On reception of a Configure-Ack, the Identifier field must match that of the last transmitted Configure-Request, or the packet is invalid. Additionally, the Configuration Options in a Configure- Ack must match those of the last transmitted Configure-Request, or the packet is invalid. Invalid packets should be silently discarded. Reception of a valid Configure-Ack indicates that all Configuration Options sent in the last Configure-Request are acceptable. A summary of the Configure-Ack packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+ Code 2 for Configure-Ack. Identifier The Identifier field is a copy of the Identifier field of the Configure-Request which caused this Configure-Ack. Options The Options field is variable in length and contains the list of zero or more Configuration Options that the sender is acknowledging. All Configuration Options are always acknowledged updated by Simpson FORMFEED[Page 28] RFC ???? Point-to-Point Protocol April 1991 simultaneously. updated by Simpson FORMFEED[Page 29] RFC ???? Point-to-Point Protocol April 1991 6.3. Configure-Nak Description If every element of the received Configuration Options is recognizable but some are not acceptable, then a LCP implementation should transmit a LCP packet with the Code field set to 3 (Configure-Nak), the Identifier field copied from the received Configure-Request, and the Options field filled with only the unacceptable Configuration Options from the Configure-Request. All acceptable Configuration Options are filtered out of the Configure-Nak, but otherwise the Configuration Options from the Configure-Request MUST NOT be reordered. Each of the Nak'd Configuration Options MUST be modified to a value acceptable to the Configure-Nak sender. Options which have no value fields (boolean options) MUST use the Configure-Reject reply instead. Finally, an implementation may be configured to request the negotiation of a specific option. If that option is not listed, then that option may be appended to the list of Nak'd Configuration Options in order to request the remote end to list that option in its next Configure-Request packet. Any value fields for the option MUST indicate values acceptable to the Configure-Nak sender. On reception of a Configure-Nak, the Identifier field must match that of the last transmitted Configure-Request, or the packet is invalid and should be silently discarded. Reception of a valid Configure-Nak indicates that a new Configure-Request should be sent with the Configuration Options modified as specified in the Configure-Nak. Some Configuration Options have a variable length. Since the Nak'd Option has been modified by the sender, the receiver MUST be prepared to accept an Option length which is different than that originally sent. updated by Simpson FORMFEED[Page 30] RFC ???? Point-to-Point Protocol April 1991 A summary of the Configure-Nak packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+ Code 3 for Configure-Nak. Identifier The Identifier field is a copy of the Identifier field of the Configure-Request which caused this Configure-Nak. Options The Options field is variable in length and contains the list of zero or more Configuration Options that the sender is Nak'ing. All Configuration Options are always Nak'd simultaneously. updated by Simpson FORMFEED[Page 31] RFC ???? Point-to-Point Protocol April 1991 6.4. Configure-Reject Description If some Configuration Options received in a Configure-Request are not recognizable or are not acceptable for negotiation (as configured by a network administrator), then a LCP implementation should transmit a LCP packet with the Code field set to 4 (Configure-Reject), the Identifier field copied from the received Configure-Request, and the Options field filled with only the unacceptable Configuration Options from the Configure-Request. All recognizable and negotiable Configuration Options are filtered out of the Configure-Reject, but otherwise the Configuration Options MUST NOT be reordered or modified in any way. On reception of a Configure-Reject, the Identifier field must match that of the last transmitted Configure-Request, or the packet is invalid. Additionally, the Configuration Options in a Configure-Reject must be a proper subset of those in the last transmitted Configure-Request, or the packet is invalid. Invalid packets should be silently discarded. Reception of a Configure-Reject indicates that a new Configure- Request should be sent which does not include any of the Configuration Options listed in the Configure-Reject. A summary of the Configure-Reject packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+ Code 4 for Configure-Reject. Identifier The Identifier field is a copy of the Identifier field of the Configure-Request which caused this Configure-Reject. updated by Simpson FORMFEED[Page 32] RFC ???? Point-to-Point Protocol April 1991 Options The Options field is variable in length and contains the list of zero or more Configuration Options that the sender is rejecting. All Configuration Options are always rejected simultaneously. updated by Simpson FORMFEED[Page 33] RFC ???? Point-to-Point Protocol April 1991 6.5. Terminate-Request and Terminate-Ack Description LCP includes Terminate-Request and Terminate-Ack Codes in order to provide a mechanism for closing a connection. A LCP implementation wishing to close a connection should transmit a LCP packet with the Code field set to 5 (Terminate-Request) and the Data field filled with any desired data. Terminate-Request packets should continue to be sent until Terminate-Ack is received, the Physical Layer indicates that it has gone down, or a sufficiently large number have been transmitted such that the remote end is down with reasonable certainty. Upon reception of a Terminate-Request, a LCP packet MUST be transmitted with the Code field set to 6 (Terminate-Ack), the Identifier field copied from the Terminate-Request packet, and the Data field filled with any desired data. Reception of an unelicited Terminate-Ack indicates that the connection has been closed. A summary of the Terminate-Request and Terminate-Ack packet formats is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code 5 for Terminate-Request; 6 for Terminate-Ack. Identifier The Identifier field is one octet and aids in matching requests and replies. Data The Data field is zero or more octets and contains uninterpreted updated by Simpson FORMFEED[Page 34] RFC ???? Point-to-Point Protocol April 1991 data for use by the sender. The data may consist of any binary value and may be of any length from zero to the established maximum Information field length minus four. updated by Simpson FORMFEED[Page 35] RFC ???? Point-to-Point Protocol April 1991 6.6. Code-Reject Description Reception of a LCP packet with an unknown Code indicates that one of the communicating LCP implementations is faulty or incomplete. This error MUST be reported back to the sender of the unknown Code by transmitting a LCP packet with the Code field set to 7 (Code- Reject), and the inducing packet copied to the Rejected- Information field. Upon reception of a Code-Reject, a LCP implementation should make an immediate transition to the Closed state, and should report the error, since it is unlikely that the situation can be rectified automatically. A summary of the Code-Reject packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rejected-Packet ... +-+-+-+-+-+-+-+-+ Code 7 for Code-Reject. Identifier The Identifier field is one octet and is for use by the transmitter. Rejected-Information The Rejected-Information field contains a copy of the LCP packet which is being rejected. It begins with the Information field, and does not include any PPP Data Link Layer headers or the FCS. The Rejected-Information should be truncated to comply with the established maximum Information field length. updated by Simpson FORMFEED[Page 36] RFC ???? Point-to-Point Protocol April 1991 6.7. Protocol-Reject Description Reception of a PPP frame with an unknown Data Link Layer Protocol indicates that the remote end is attempting to use a protocol which is unsupported at the local end. This typically occurs when the remote end attempts to configure a new, but unsupported protocol. If the LCP state machine is in the Opened state, then this error MUST be reported back to the sender of the unknown protocol by transmitting a LCP packet with the Code field set to 8 (Protocol-Reject), the Rejected-Protocol field set to the received Protocol, and the inducing packet copied to the Rejected- Information field. Upon reception of a Protocol-Reject, a LCP implementation should stop transmitting frames of the indicated protocol. Protocol-Reject packets may only be sent in the LCP Opened state. Protocol-Reject packets received in any state other than the LCP Opened state should be discarded and no further action should be taken. A summary of the Protocol-Reject packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rejected-Protocol | Rejected-Information ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 8 for Protocol-Reject. Identifier The Identifier field is one octet and is for use by the transmitter. Rejected-Protocol The Rejected-Protocol field is two octets and contains the Protocol of the Data Link Layer frame which is being rejected. updated by Simpson FORMFEED[Page 37] RFC ???? Point-to-Point Protocol April 1991 Rejected-Information The Rejected-Information field contains a copy from the frame which is being rejected. It begins with the Information field, and does not include any PPP Data Link Layer headers or the FCS. The Rejected-Information should be truncated to comply with the established maximum Information field length. updated by Simpson FORMFEED[Page 38] RFC ???? Point-to-Point Protocol April 1991 6.8. Echo-Request and Echo-Reply Description LCP includes Echo-Request and Echo-Reply Codes in order to provide a Data Link Layer loopback mechanism for use in exercising both directions of the link. This is useful as an aid in debugging, link quality determination, performance testing, and for numerous other functions. An Echo-Request sender transmits a LCP packet with the Code field set to 9 (Echo-Request) and the Data field filled with any desired data, up to but not exceeding the receiver's established maximum Information field length minus eight. Upon reception of an Echo-Request, a LCP packet MUST be transmitted with the Code field set to 10 (Echo-Reply), the Identifier field copied from the received Echo-Request, and the Data field copied from the Echo-Request, truncating as necessary to avoid exceeding the peer's established maximum Information field length. Echo-Request and Echo-Reply packets may only be sent in the LCP Opened state. Echo-Request and Echo-Reply packets received in any state other than the LCP Opened state should be discarded and no further action should be taken. A summary of the Echo-Request and Echo-Reply packet formats is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic-Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code 9 for Echo-Request; 10 for Echo-Reply. updated by Simpson FORMFEED[Page 39] RFC ???? Point-to-Point Protocol April 1991 Identifier The Identifier field is one octet and aids in matching Echo- Requests and Echo-Replies. Magic-Number The Magic-Number field is four octets and aids in detecting loopbacked links. Unless modified by a Configuration Option, the Magic-Number MUST always be transmitted as zero and MUST always be ignored on reception. Further use of the Magic-Number is beyond the scope of this discussion. Data The Data field is zero or more octets and contains uninterpreted data for use by the sender. The data may consist of any binary value and may be of any length from zero to the established maximum Information field length minus eight. updated by Simpson FORMFEED[Page 40] RFC ???? Point-to-Point Protocol April 1991 6.9. Discard-Request Description LCP includes a Discard-Request Code in order to provide a Data Link Layer data sink mechanism for use in exercising the local to remote direction of the link. This is useful as an aid in debugging, performance testing, and for numerous other functions. A discard sender transmits a LCP packet with the Code field set to 11 (Discard-Request) and the Data field filled with any desired data, up to but not exceeding the receiver's established maximum Information field length minus eight. A discard receiver MUST simply throw away an Discard-Request that it receives. Discard-Request packets may only be sent in the LCP Opened state. A summary of the Discard-Request packet formats is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic-Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code 11 for Discard-Request. Identifier The Identifier field is one octet and is for use by the Discard- Request transmitter. Magic-Number The Magic-Number field is four octets and aids in detecting loopbacked links. Unless modified by a configuration option, the Magic-Number MUST always be transmitted as zero and MUST always be ignored on reception. Further use of the Magic-Number is beyond the scope of this discussion. updated by Simpson FORMFEED[Page 41] RFC ???? Point-to-Point Protocol April 1991 Data The Data field is zero or more octets and contains uninterpreted data for use by the sender. The data may consist of any binary value and may be of any length from zero to the established maximum Information field length minus four. updated by Simpson FORMFEED[Page 42] RFC ???? Point-to-Point Protocol April 1991 6.10. Link-Quality-Report Description LCP includes a Link-Quality-Report Code in order to provide a Data Link Layer mechanism for communicating measurements of data link performance. If an implementation desires that the remote end send Link-Quality-Report packets, then it MUST negotiate Link- Quality-Monitoring during Link Establishment phase. Every Reporting-Period interval, the sender transmits a LCP packet with the Code field set to 12 (Link-Quality-Report) and the Data field filled with the defined measurement fields. A Summary of the Link-Quality-Report packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic-Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Tx-LQRs | Last-In-Id | Reserved |V| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Tx-Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Tx-Octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Rx-Packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Rx-Octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Out-Tx-Packets-Ctr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Out-Tx-Octets-Ctr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As transmitted over the link, this packet format does not include the following fields which are logically appended to the packet after re- ception on the inbound link. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Rx-Packets-Ctr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Rx-Octets-Ctr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ updated by Simpson FORMFEED[Page 43] RFC ???? Point-to-Point Protocol April 1991 Code 12 for Link-Quality-Report. Identifier The Identifier field is one octet and indicates the sequence number for this Link-Quality-Report. The Identifier field is copied from the Out-Identifier-Ctr counter on transmission. On reception, the Identifier field is used to calculate In-Tx-LQRs and is stored in the local Last-In-Id. The Link-Quality-Report Identifier sequence number space MUST be separate from that of all other LCP packets. For example, transmission of an LCP Echo-Request must not cause the Out- Identifier-Ctr counter to be incremented. Length The Length field is two octets and indicates the length of the LQM packet including the Code, Identifier, Length and all defined fields. Octets outside the range of the length field should be treated as Data Link Layer padding and should be ignored on reception. In order for the correct In-Tx-Octets and In-Rx-Octets values to be calculated, Link-Quality-Reports MUST be consistently transmitted with the same amount of padding. Magic-Number The Magic-Number field is four octets and aids in detecting looped-back links. Unless modified by a Configuration Option, the Magic-Number MUST always be transmitted as zero and MUST always be ignored on reception. If Magic-Numbers have been negotiated, incoming LQM packets should be checked to make sure that the local end is not seeing its own Magic-Number and thus a looped-back link. In-Tx-LQRs The In-Tx-LQRs field is one octet and indicates the number of periods covered by the Measurements section of this Link-Quality- Report. The In-Tx-LQRs field is copied from the In-Tx-LQRs state variable on transmission. Last-In-Id The Last-In-Id field is one octet and indicates the last Link- Quality-Report Identifier received (by the sender). The Last-In- updated by Simpson FORMFEED[Page 44] RFC ???? Point-to-Point Protocol April 1991 Id field is copied from the Last-In-Id field on transmission. On reception, the Last-In-Id field may be compared with the Out- Identifier-Ctr to determine how many, if any, outbound Link- Quality-Reports have been lost. V The V field is 1 bit and indicates whether or not the Measurements section of this Link-Quality-Report is valid. The V field is copied from the Measurements-Valid state variable on transmission. If the V field is not set to 1, then the In-Tx-LQRs, Last-In-Id, In-Tx-Packets, In-Tx-Octets, In-Rx-Packets and In-Rx-Octets fields should be ignored. Reserved The Reserved field is 15 bits and is intended to pad the remaining packet fields to even four-octet boundaries for the convenience of hardware implementations. The Reserved field should always be transmitted as zero and ignored on reception. In-Tx-Packets The In-Tx-Packets field is four octets and indicates the number of packets transmitted on the inbound link of the Link-Quality-Report transmitter during the last measured period. The In-Tx-Packets field is copied from the In-Tx-Packets state variable on transmission. In-Tx-Octets The In-Tx-Octets field is four octets and indicates the number of octets transmitted on the inbound link of the Link-Quality-Report transmitter during the last measured period. The In-Tx-Octets field is copied from the In-Tx-Octets state variable on transmission. In-Rx-Packets The In-Rx-Packets field is four octets and indicates the number of packets received on the inbound link of the Link-Quality-Report transmitter during the last measured period. The In-Rx-Packets field is copied from the In-Rx-Packets state variable on transmission. In-Rx-Octets The In-Rx-Octets field is four octets and indicates the number of updated by Simpson FORMFEED[Page 45] RFC ???? Point-to-Point Protocol April 1991 octets received on the inbound link of the Link-Quality-Report transmitter during the last measured period. The In-Rx-Octets field is copied from the In-Rx-Octets state variable on transmission. Out-Tx-Packets-Ctr The Out-Tx-Packets-Ctr field is four octets and is used to calculate the number of packets transmitted on the outbound link of the Link-Quality-Report transmitter during a period. The Out- Tx-Packets-Ctr field is copied from the Out-Tx-Packets-Ctr counter on transmission. Out-Tx-Octets-Ctr The Out-Tx-Octets-Ctr field is four octets and is used to calculate the number of octets transmitted on the outbound link of the Link-Quality-Report transmitter during a period. The Out-Tx- Octets-Ctr field is copied from the Out-Tx-Octets-Ctr counter on transmission. In-Rx-Packets-Ctr The In-Rx-Packets-Ctr field is four octets and is used to calculate the number of packets received on the inbound link of the Link-Quality-Report receiver during a period. The In-Rx- Packets-Ctr field is copied from the In-Rx-Packets-Ctr counter on reception. The In-Rx-Packets-Ctr is not actually transmitted over the link. Rather, it is logically appended (in an implementation dependent manner) to the packet by the implementation's Rx process. In-Rx-Octets-Ctr The In-Rx-Octets-Ctr field is four octets and is used to calculate the number of octets received on the inbound link of the Link- Quality-Report receiver during a period. The In-Rx-Octets-Ctr field is copied from the In-Rx-Octets-Ctr counter on reception. The In-Rx-Octets-Ctr is not actually transmitted over the link. Rather, it is logically appended (in an implementation dependent manner) to the packet by the implementation's Rx process. updated by Simpson FORMFEED[Page 46] RFC ???? Point-to-Point Protocol April 1991 7. LCP Configuration Options LCP Configuration Options allow modifications to the standard characteristics of a point-to-point link to be negotiated. Negotiable modifications include such things as the maximum receive unit, async control character mapping, the link authentication method, etc. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed. The end of the list of Configuration Options is indicated by the end of the LCP packet. Unless otherwise specified, a specific Configuration Option should be listed no more than once in a Configuration Options list. Specific Configuration Options may override this general rule and may be listed more than once. The effect of this is Configuration Option specific and is specified by each such Configuration Option. Also unless otherwise specified, all Configuration Options apply in a half-duplex fashion. When negotiated, they apply to only one direction of the link, typically in the receive direction when interpreted from the point of view of the Configure-Request sender. updated by Simpson FORMFEED[Page 47] RFC ???? Point-to-Point Protocol April 1991 7.1. Format A summary of the Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The Type field is one octet and indicates the type of Configuration Option. The most up-to-date values of the LCP Option Type field are specified in the most recent "Assigned Numbers" RFC [11]. Current values are assigned as follows: 1 Maximum-Receive-Unit 2 Async-Control-Character-Map 3 Authentication-Type 4 NOT ASSIGNED 5 Magic-Number 6 Link-Quality-Monitoring 7 Protocol-Field-Compression 8 Address-and-Control-Field-Compression 9 32-bit-FCS Length The Length field is one octet and indicates the length of this Configuration Option including the Type, Length and Data fields. If a negotiable Configuration Option is received in a Configure-Request but with an invalid Length, a Configure-Nak should be transmitted which includes the desired Configuration Option with an appropriate Length and Data. Data The Data field is zero or more octets and indicates the value or other information for this Configuration Option. The format and length of the Data field is determined by the Type and Length fields. updated by Simpson FORMFEED[Page 48] RFC ???? Point-to-Point Protocol April 1991 7.2. Maximum-Receive-Unit Description This Configuration Option provides a way to negotiate the maximum packet size used across one direction of a link. By default, all implementations must be able to receive frames with 1500 octets of Information. This Configuration Option may be sent to inform the remote end that you can receive larger frames, or to request that the remote end send you smaller frames. If smaller frames are requested, an implementation MUST still be able to receive 1500 octet frames in case link synchronization is lost. A summary of the Maximum-Receive-Unit Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Maximum-Receive-Unit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length 4 Maximum-Receive-Unit The Maximum-Receive-Unit field is two octets and indicates the new maximum receive unit. The Maximum-Receive-Unit covers only the Data Link Layer Information field but not the header, trailer or any transparency bits or bytes. Default 1500 updated by Simpson FORMFEED[Page 49] RFC ???? Point-to-Point Protocol April 1991 7.3. Async-Control-Character-Map Description This Configuration Option provides a way to negotiate the use of control character mapping on asynchronous links. By default, PPP maps all control characters into an appropriate two character sequence. However, it is rarely necessary to map all control characters and often it is unnecessary to map any characters. A PPP implementation may use this Configuration Option to inform the remote end which control characters must remain mapped and which control characters need not remain mapped when the remote end sends them. The remote end may still send these control characters in mapped format if it is necessary because of constraints at the remote end. There may be some use of synchronous-to-asynchronous converters (some built into modems) in Point-to-point links resulting in a synchronous PPP implementation on one end of a link and an asynchronous implementation on the other. It is the responsibility of the converter to do all mapping conversions during operation. To enable this functionality, synchronous PPP implementations MUST always accept a Async-Control-Character-Map Configuration Option (it MUST always respond to an LCP Configure-Request specifying this Configuration Option with an LCP Configure-Ack). However, acceptance of this Configuration Option does not imply that the synchronous implementation will do any character mapping, since synchronous PPP uses bit-stuffing rather than character-stuffing. Instead, all such character mapping will be performed by the asynchronous-to-synchronous converter. A summary of the Async-Control-Character-Map Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Async-Control-Character-Map +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 updated by Simpson FORMFEED[Page 50] RFC ???? Point-to-Point Protocol April 1991 Length 6 Async-Control-Character-Map The Async-Control-Character-Map field is four octets and indicates the new async control character map. The map is encoded in big- endian fashion where each numbered bit corresponds to the ASCII control character of the same value. If the bit is cleared to zero, then that ASCII control character need not be mapped. If the bit is set to one, then that ASCII control character must remain mapped. E.g., if bit 19 is set to zero, then the ASCII control character 19 (DC3, Control-S) may be sent in the clear. Default All ones (0xffffffff). updated by Simpson FORMFEED[Page 51] RFC ???? Point-to-Point Protocol April 1991 7.4. Authentication-Type Description On some links it may be desirable to require a peer to authenticate itself before allowing network-layer protocol packets to be exchanged. This Configuration Option provides a way to negotiate the use of a specific authentication protocol. By default, authentication is not necessary. An implementation may allow the remote end to pick from more than one authentication protocol. To achieve this, it may include multiple Authentication-Type Configuration Options in its Configure-Request packets. An implementation receiving a Configure-Request specifying multiple Authentication-Types may accept at most one of the negotiable authentication protocols and should send a Configure-Reject specifying all of the other specified authentication protocols. It is recommended that each PPP implementation support configuration of authentication parameters at least on a per- interface basis, if not a per peer entity basis. The parameters should specify which authentication techniques are minimally required as a prerequisite to establishment of a PPP connection, either for the specified interface or for the specified peer entity. Such configuration facilities are necessary to prevent an attacker from negotiating a reduced security authentication protocol, or no authentication at all, in an attempt to circumvent this authentication facility. If an implementation sends a Configure-Ack with this Configuration Option, then it is agreeing to authenticate with the specified protocol. An implementation receiving a Configure-Ack with this Configuration Option should expect the remote end to authenticate with the acknowledged protocol. There is no requirement that authentication be full duplex or that the same authentication protocol be used in both directions. It is perfectly acceptable for different authentication protocols to be used in each direction. This will, of course, depend on the specific authentication protocols negotiated. updated by Simpson FORMFEED[Page 52] RFC ???? Point-to-Point Protocol April 1991 A summary of the Authentication-Type Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Authentication-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Type 3 Length >= 4 Authentication-Protocol The Authentication-Protocol field is two octets and indicates the authentication protocol desired. Values for the Authentication- Protocol are always the same as the PPP Data Link Layer Protocol field values for that same authentication protocol. The most up-to-date values of the Authentication-Type field are specified in the most recent "Assigned Numbers" RFC [11]. Current values are assigned as follows: Value (in hex) Protocol c023 Password Authentication Protocol Data The Data field is zero or more octets and contains additional data as determined by the particular authentication protocol. Default No authentication protocol necessary. updated by Simpson FORMFEED[Page 53] RFC ???? Point-to-Point Protocol April 1991 7.5. Magic-Number Description This Configuration Option provides a way to detect looped-back links and other Data Link Layer anomalies. This Configuration Option may be required by some other Configuration Options such as the Link-Quality-Monitoring Configuration Option. Before this Configuration Option is requested, an implementation must choose its Magic-Number. It is recommended that the Magic- Number be chosen in the most random manner possible in order to guarantee with very high probability that an implementation will arrive at a unique number. A good way to choose a unique random number is to start with an unique seed. Suggested sources of uniqueness include machine serial numbers, other network hardware addresses, time-of-day clocks, etc. Particularly good random number seeds are precise measurements of the inter-arrival time of physical events such as packet reception on other connected networks, server response time, or the typing rate of a human user. It is also suggested that as many sources as possible be used simultaneously. When a Configure-Request is received with a Magic-Number Configuration Option, the received Magic-Number should be compared with the Magic-Number of the last Configure-Request sent to the peer. If the two Magic-Numbers are different, then the link is not looped-back, and the Magic-Number should be acknowledged. If the two Magic-Numbers are equal, then it is possible, but not certain, that the link is looped-back and that this Configure- Request is actually the one last sent. To determine this, a Configure-Nak should be sent specifying a different Magic-Number value. A new Configure-Request should not be sent to the peer until normal processing would cause it to be sent (i.e., until a Configure-Nak is received or the Restart timer runs out). Reception of a Configure-Nak with a Magic-Number different from that of the last Configure-Nak sent to the peer proves that a link is not looped-back, and indicates a unique Magic-Number. If the Magic-Number is equal to the one sent in the last Configure-Nak, the possibility of a loop-back is increased, and a new Magic- Number should be chosen. In either case, a new Configure-Request should be sent with the new Magic-Number. If the link is indeed looped-back, this sequence (transmit Configure-Request, receive Configure-Request, transmit Configure- Nak, receive Configure-Nak) will repeat over and over again. If the link is not looped-back, this sequence may occur a few times, updated by Simpson FORMFEED[Page 54] RFC ???? Point-to-Point Protocol April 1991 but it is extremely unlikely to occur repeatedly. More likely, the Magic-Numbers chosen at either end will quickly diverge, terminating the sequence. The following table shows the probability of collisions assuming that both ends of the link select Magic-Numbers with a perfectly uniform distribution: Number of Collisions Probability -------------------- --------------------- 1 1/2**32 = 2.3 E-10 2 1/2**32**2 = 5.4 E-20 3 1/2**32**3 = 1.3 E-29 Good sources of uniqueness or randomness are required for this divergence to occur. If a good source of uniqueness cannot be found, it is recommended that this Configuration Option not be enabled; Configure-Requests with the option should not be transmitted and any Magic-Number Configuration Options which the peer sends should be either acknowledged or rejected. In this case, loop-backs cannot be reliably detected by the implementation, although they may still be detectable by the peer. If an implementation does transmit a Configure-Request with a Magic-Number Configuration Option, then it MUST NOT respond with a Configure-Reject if its peer also transmits a Configure-Request with a Magic-Number Configuration Option. That is, if an implementation desires to use Magic Numbers, then it MUST also allow its peer to do so. If an implementation does receive a Configure-Reject in response to a Configure-Request, it can only mean that the link is not looped-back, and that its peer will not be using Magic-Numbers. In this case, an implementation may act as if the negotiation had been successful (as if it had instead received a Configure-Ack). The Magic-Number also may be used to detect looped-back links during normal operation as well as during Configuration Option negotiation. All Echo-Request, Echo-Reply, Discard-Request, and Link-Quality-Report LCP packets have a Magic-Number field which MUST normally be transmitted as zero, and MUST normally be ignored on reception. However, once a Magic-Number has been successfully negotiated, an LCP implementation MUST begin transmitting these packets with the Magic-Number field set to its negotiated Magic- Number. Additionally, the Magic-Number field of these packets may be inspected on reception. All received Magic-Number fields should be equal to either zero or the peer's unique Magic-Number, depending on whether or not the peer negotiated one. Reception of a Magic-Number field equal to the negotiated local Magic-Number indicates a looped-back link. Reception of a Magic-Number other than the negotiated local Magic-Number or the peer's negotiated updated by Simpson FORMFEED[Page 55] RFC ???? Point-to-Point Protocol April 1991 Magic-Number, or zero if the peer didn't negotiate one, indicates a link which has been (mis)configured for communications with a different peer. Procedures for recovery from either case are unspecified and may vary from implementation to implementation. A somewhat pessimistic procedure is to assume an LCP Physical-Layer-Down event and make an immediate transition to the Closed state. A further Active-Open event will begin the process of re- establishing the link, which can't complete until the loop-back condition is terminated and Magic-Numbers are successfully negotiated. A more optimistic procedure (in the case of a loop- back) is to begin transmitting LCP Echo-Request packets until an appropriate Echo-Reply is received, indicating a termination of the loop-back condition. A summary of the Magic-Number Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Magic-Number +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Magic-Number (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 5 Length 6 Magic-Number The Magic-Number field is four octets and indicates a number which is very likely to be unique to one end of the link. A Magic- Number of zero is illegal and should always be Nak'd. Default None. updated by Simpson FORMFEED[Page 56] RFC ???? Point-to-Point Protocol April 1991 7.6. Link-Quality-Monitoring Description On some links it may be desirable to determine when, and how often, the link is dropping data. This process is called Link Quality Monitoring and is elaborated in Section 8. It is implemented by periodically transmitting Link-Quality-Report packets as described in Section 6.10. The Link-Quality-Monitoring Configuration Option provides a way to enable the use of Link- Quality-Report packets, and also to negotiate the rate at which they are transmitted. By default, Link Quality Monitoring and the use of Link-Quality-Report packets is disabled. A summary of the Link-Quality-Monitoring Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reporting-Period +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reporting-Period (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 6 Length 6 Reporting-Period The Reporting-Period field is four octets and indicates the maximum time in micro-seconds that the remote end should wait between transmission of LCP Link-Quality-Report packets. A value of zero is illegal and should always be Nak'd or Rejected. An LCP implementation is always free to transmit LCP Link-Quality-Report packets at a faster rate than that which was requested by, and acknowledged to, the remote end. Default None updated by Simpson FORMFEED[Page 57] RFC ???? Point-to-Point Protocol April 1991 7.7. Protocol-Field-Compression Description This Configuration Option provides a way to negotiate the compression of the Data Link Layer Protocol field. By default, all implementations must transmit standard PPP frames with two octet Protocol fields. However, PPP Protocol field numbers are chosen such that some values may be compressed into a single octet form which is clearly distinguishable from the two octet form. This Configuration Option may be sent to inform the remote end that you can receive single octet Protocol fields. Compressed Protocol fields may not be transmitted unless this Configuration Option has been received. As previously mentioned, the Protocol field uses an extension mechanism consistent with the ISO 3309 extension mechanism for the Address field; the Least Significant Bit (LSB) of each octet is used to indicate extension of the Protocol field. A binary "0" as the LSB indicates that the Protocol field continues with the following octet. The presence of a binary "1" as the LSB marks the last octet of the Protocol field. Notice that any number of "0" octets may be prepended to the field, and will still indicate the same value (consider the two representations for 3, 00000011 and 00000000 00000011). In the interest of simplicity, the standard PPP frame uses this fact and always sends Protocol fields with a two octet representation. Protocol field values less than 256 (decimal) are prepended with a single zero octet even though transmission of this, the zero and most significant octet, is unnecessary. However, when using low speed links, it is desirable to conserve bandwidth by sending as little redundant data as possible. The Protocol Compression Configuration Option allows a trade-off between implementation simplicity and bandwidth efficiency. If successfully negotiated, the ISO 3309 extension mechanism may be used to compress the Protocol field to one octet instead of two. The large majority of frames are compressible since data protocols are typically assigned with Protocol field values less than 256. In addition, PPP implementations must continue to be robust and MUST accept PPP frames with either double-octet or single-octet Protocol fields, and MUST NOT distinguish between them. By definition (value of 0xc021), the Protocol field must never be compressed when sending any LCP packet. This rule guarantees unambiguous recognition of LCP packets. updated by Simpson FORMFEED[Page 58] RFC ???? Point-to-Point Protocol April 1991 When a Protocol field is compressed, the Data Link Layer FCS field is calculated on the compressed frame, not the original uncompressed frame. A summary of the Protocol-Field-Compression Configuration Option for- mat is shown below. The fields are transmitted from left to right. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 7 Length 2 Default Disabled. updated by Simpson FORMFEED[Page 59] RFC ???? Point-to-Point Protocol April 1991 7.8. Address-and-Control-Field-Compression Description This Configuration Option provides a way to negotiate the compression of the Data Link Layer Address and Control fields. By default all implementations must transmit frames with Address and Control fields and must use the hexadecimal values 0xff and 0x03 respectively. Since these fields have constant values, they are easily compressed. This Configuration Option may be sent to inform the remote end that you can receive compressed Address and Control fields. Compressed Address and Control fields are formed by simply omitting them. The first octet of the Protocol field should never be 0xff (by definition and reservation). On reception, the Address and Control fields are decompressed by examining the first two octets. If they contain the values 0xff and 0x03, they are assumed to be the Address and Control fields. If not, it is assumed that the fields were compressed and were not transmitted. If a compressed frame is received when Address-and-Control-Field- Compression has not been negotiated, the result is implementation dependent. An implementation may silently discard the frame. The Address and Control fields must never be compressed when sending any LCP packet. This rule guarantees unambiguous recognition of LCP packets. When the Address and Control fields are compressed, the Data Link Layer FCS field is calculated on the compressed frame, not the original uncompressed frame. A summary of the Address-and-Control-Field-Compression configuration option format is shown below. The fields are transmitted from left to right. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8 updated by Simpson FORMFEED[Page 60] RFC ???? Point-to-Point Protocol April 1991 Length 2 Default Not compressed. updated by Simpson FORMFEED[Page 61] RFC ???? Point-to-Point Protocol April 1991 7.9. 32 Bit FCS Description This Configuration Option provides a way to negotiate a 32 bit FCS. The generation of the 32 bit checksum is not described in this document. A summary of the 32-Bit-FCS configuration option format is shown below. The fields are transmitted from left to right. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 9 Length 2 Default 16 bit FCS. updated by Simpson FORMFEED[Page 62] RFC ???? Point-to-Point Protocol April 1991 8. Link Quality Monitoring Data communications links are rarely perfect. Packets can be dropped or corrupted for various reasons (line noise, equipment failure, buffer overruns, etc.). Sometimes, it is desirable to determine when, and how often, the link is dropping data. Routers, for example, may want to temporarily allow another route to take precedence. An implementation may also have the option of disconnecting and switching to an alternate link. The process of determining data loss is called "Link Quality Monitoring". 8.1. Design Motivation There are many different ways to measure link quality, and even more ways to react to it. Rather than specifying a single scheme, Link Quality Monitoring is divided into a "mechanism" and a "policy". PPP fully specifies the "mechanism" for Link Quality Monitoring by defining the LCP Link-Quality-Report (LQR) packet and specifying a procedure for its use. PPP does NOT specify a Link Quality Monitoring "policy" -- how to judge link quality or what to do when it is inadequate. That is left as an implementation decision, and can be different at each end of the link. Implementations are allowed, and even encouraged, to experiment with various link quality policies. The Link Quality Monitoring mechanism specification insures that two implementations with different policies may communicate and interoperate. To allow flexible policies to be implemented, the PPP Link Quality Monitoring mechanism measures data loss in units of packets, octets, and Link-Quality-Reports. Each measurement is made separately for each half of the link, both inbound and outbound. All measurements are communicated to both ends of the link so that each end of the link can implement its own link quality policy for both its outbound and inbound links. Finally, the Link Quality Monitoring protocol is designed to be implementable on many different kinds of systems. Although it may be common to implement PPP (and especially Link Quality Monitoring) as a single software process, multi-process implementations with hardware support are also envisioned. The PPP Link Quality Monitoring mechanism provides for this by careful definition of the Link- Quality-Report packet format, and by specifying reference points for all data transmission and reception measurements. 8.2. Design Overview Each Link Quality Monitoring implementation maintains counts of the number of packets and octets transmitted and successfully received, updated by Simpson FORMFEED[Page 63] RFC ???? Point-to-Point Protocol April 1991 and periodically transmits this information to its peer in a Link- Quality-Report packet. These packets contain three sections: a Header section, a Counters section, and a Measurements section. The Header section of the packet consists of the normal LCP Link Maintenance packet header including Code, Identifier, Length and Magic-Number fields. The Counters section of the packet consists of four counters, and provides the information necessary to measure the quality of the link. The LQR transmitter fills in two of these counters: Out-Tx- Packets-Ctr and Out-Tx-Octets-Ctr (described later). The LQR receiver fills in the two remaining counters: In-Rx-Packets-Ctr and In-Rx-Octets-Ctr (described later). These counters are similar to sequence numbers; they are constantly increasing to give a "relative" indication of the number of packets and octets communicated across the outbound link. By comparing the values in successive Link- Quality-Reports, an LQR receiver can compute the "absolute" number of packets and octets communicated across its inbound link. Comparing these absolute numbers then gives an indication of an inbound link's quality. Relative numbers, rather than absolute, are transmitted because they greatly simplify link synchronization; an implementation merely waits to receive two LQR packets. The Measurements section of the packet consists of six state variables: In-Tx-LQRs, Last-In-Id, In-Tx-Packets, In-Tx-Octets, In- Rx-Packets, and In-Rx-Octets (described later). This section allows an implementation to report inbound link quality measurements to its peer (for which the report will instead indicate outbound link quality) by transmitting the absolute, rather than relative, number of LQRs, packets, and octets communicated across the inbound link. These values are calculated by observing the Counters section of the Link-Quality-Report packets received on the inbound link. Absolute numbers may be used in this section without synchronization problems because it is necessary to receive only one LQR packet to have valid information. Link Quality Monitoring is described in more detail in the following sections. First, a description of the processes comprising the Link Quality Monitoring mechanism is presented. This is followed by the packet and byte counters maintained; the measurements, calculations, and state variables used; the format of the Link-Quality-Report packet; some policy suggestions; and, finally, an example link quality calculation. 8.3. Processes The PPP Link Quality Monitoring mechanism is described using a updated by Simpson FORMFEED[Page 64] RFC ???? Point-to-Point Protocol April 1991 "logical process" model. As shown below, there are five logical processes duplicated at each end of the duplex link. +---------+ +-------+ +----+ Outbound | |-->| Mux |-->| Tx |=========> | Link- | +-------+ +----+ | Manager | | | +-------+ +----+ Inbound | |<--| Demux |<--| Rx |<========= +---------+ +-------+ +----+ Link-Manager The Link-Manager process transmits and receives Link-Quality- Reports, and implements the desired link quality policy. LQR packets are transmitted at a constant rate, which is negotiated by the LCP Link-Quality-Monitoring Configuration Option. The Link- Manager process fills in only the Header and Measurements sections of the packet; the Counters section of the packet is filled in by the Tx and Rx processes. Mux The Mux process multiplexes packets from the various protocols (e.g., LCP, IP, XNS, etc.) into a single, sequential, and prioritized stream of packets. Link-Quality-Report packets MUST be given the highest possible priority to insure that link quality information is communicated in a timely manner. Tx The Tx process maintains the counters Out-Tx-Packets-Ctr and Out- Tx-Octets-Ctr which are used to measure the amount of data which is transmitted on the outbound link. When Tx processes a Link- Quality-Report packet, it inserts the values of these counters into the Counters section of the packet. Because these counters represent relative, rather than absolute, values, the question of when to update the counters, before or after they are inserted into a Link-Quality-Report packet, is left as an implementation decision. However, an implementation MUST make this decision the same way every time. The Tx process MUST follow the Mux process so that packets are counted in the order transmitted to the link. Rx The Rx process maintains the counters In-Rx-Packets-Ctr and In- Rx-Octets-Ctr which are used to measure the amount of data which is received by the inbound link. When Rx processes a Link- updated by Simpson FORMFEED[Page 65] RFC ???? Point-to-Point Protocol April 1991 Quality-Report packet, it inserts the values of these counters into the Counters section of the packet. Again, the question of when to update the counters, before or after they are inserted into a Link-Quality-Report packet, is left as an implementation decision which MUST be made consistently the same way. Demux The Demux process demultiplexes packets for the various protocols. The Demux process MUST follow the Rx process so that packets are counted in the order received from the link. 8.4. Counters In order to fill in the Counters section of a Link-Quality-Report packet, Link Quality Monitoring requires the implementation of one 8-bit unsigned, and four 32-bit unsigned, monotonically increasing counters. These counters may be reset to any initial value before the first Link-Quality-Report is transmitted, but MUST NOT be reset again until LCP has left the Opened state. Counters wrap to zero when their maximum value is reached (for 32 bit counters: 0xffffffff + 1 = 0). Out-Identifier-Ctr Out-Identifier-Ctr is an 8-bit counter maintained by the Link- Manager process which increases by one for each transmitted Link- Quality-Report packet. Out-Tx-Packets-Ctr Out-Tx-Packets-Ctr is a 32-bit counter maintained by the Tx process which increases by one for each transmitted Data Link Layer packet. Out-Tx-Octets-Ctr Out-Tx-Octets-Ctr is a 32-bit counter maintained by the Tx process which increases by one for each octet in a transmitted Data Link Layer packet. All octets which are included in the FCS calculation MUST be counted, as should the FCS octets themselves. All other octets MUST NOT be counted. In-Rx-Packets-Ctr In-Rx-Packets-Ctr is a 32-bit counter maintained by the Rx process which increases by one for each successfully received Data Link Layer packet. Packets with incorrect FCS fields or other problems updated by Simpson FORMFEED[Page 66] RFC ???? Point-to-Point Protocol April 1991 MUST not be counted. In-Rx-Octets-Ctr In-Rx-Octets-Ctr is a 32-bit counter maintained by the Rx process which increases by one for each octet in a successfully received Data Link Layer packet. All octets which are included in an FCS calculation MUST be counted, as should the FCS octets themselves. All other octets MUST NOT be counted. 8.5. Measurements, Calculations, State Variables In order to fill in the Measurements section of a Link-Quality-Report packet, Link Quality Monitoring requires the Link-Manager process to make a number of calculations and keep a number of state variables. These calculations are made, and these state variables updated, each time a Link-Quality-Report packet is received from the inbound link. In-Tx-LQRs In-Tx-LQRs is an 8-bit state variable which indicates the number of Link-Quality-Report packets which the peer had to transmit in order for the local end to receive exactly one LQR. In-Tx-LQRs defines the length of the "period" over which In-Tx-Packets, In- Tx-Octets, In-Rx-Packets, and In-Rx-Octets were measured. In-Tx- LQRs is calculated by subtracting Last-In-Id from the received Identifier. If more than 255 LQRs in a row are lost, In-Tx-LQRs will be ambiguous since the Identifier field and all state variables based on it are only 8 bits. It is assumed that the Link Quality Monitoring policy will be robust enough to handle this case (it should probably close down the link long before this happens). Last-In-Id Last-In-Id is an 8-bit state variable which stores the value of the last received Identifier. Last-In-Id should be updated after In-Tx-LQRs has been calculated. In-Tx-Packets In-Tx-Packets is a 32-bit state variable which indicates the number of packets which were transmitted on the inbound link during the last period. In-Tx-Packets is calculated by subtracting Last-Out-Tx-Packets-Ctr from the received Out-Tx- Packets-Ctr. updated by Simpson FORMFEED[Page 67] RFC ???? Point-to-Point Protocol April 1991 Last-Out-Tx-Packets-Ctr Last-Out-Tx-Packets-Ctr is a 32-bit state variable which stores the value of the last received Out-Tx-Packets-Ctr. Last-Out-Tx- Packets-Ctr should be updated after In-Tx-Packets has been calculated. In-Tx-Octets In-Tx-Octets is a 32-bit state variable which indicates the number of octets which were transmitted on the inbound link during the last period. In-Tx-Octets is calculated by subtracting Last-Out- Tx-Octets-Ctr from the received Out-Tx-Octets-Ctr. Last-Out-Tx-Octets-Ctr Last-Out-Tx-Octets-Ctr is a 32-bit state variable which stores the value of the last received Out-Tx-Octets-Ctr. Last-Out-Tx- Octets-Ctr should be updated after In-Tx-Octets has been calculated. In-Rx-Packets In-Rx-Packets is a 32-bit state variable which indicates the number of packets which were received on the inbound link during the last period. In-Rx-Packets is calculated by subtracting Last-In-Rx-Packets-Ctr from the received In-Rx-Packets-Ctr. Last-In-Rx-Packets-Ctr Last-In-Rx-Packets-Ctr is a 32-bit state variable which stores the value of the last received In-Rx-Packets-Ctr. Last-In-Rx- Packets-Ctr should be updated after In-Rx-Packets has been calculated. In-Rx-Octets In-Rx-Octets is a 32-bit state variable which indicates the number of octets which were received on the inbound link during the last period. In-Rx-Octets is calculated by subtracting Last-In-Rx- Octets-Ctr from the received In-Rx-Octets-Ctr. Last-In-Rx-Octets-Ctr Last-In-Rx-Octets-Ctr is a 32-bit state variable which stores the value of the last received In-Rx-Octets-Ctr. Last-In-Rx-Octets- Ctr should be updated after In-Rx-Octets has been calculated. updated by Simpson FORMFEED[Page 68] RFC ???? Point-to-Point Protocol April 1991 Measurements-Valid Measurements-Valid is a 1-bit boolean state variable which indicates whether or not the In-Tx-Packets, In-Tx-Octets, In-Rx- Packets, and In-Rx-Octets state variables contain valid measurements. These measurements cannot be considered valid until two or more Link-Quality-Report packets have been received on the inbound link. This bit should be reset when LCP reaches the Opened state and should be set after the receipt of exactly two LQRs. 8.6. Policy Suggestions Link-Quality-Report packets provide a mechanism to determine the link quality, but it is up to each implementation to decide when the link is usable. It is recommended that this policy implement some amount of hysteresis so that the link does not bounce up and down. A particularly good policy is to use a K out of N algorithm. In such an algorithm, there must be K successes out of the last N periods for the link to be considered of good quality. Procedures for recovery from poor quality links are unspecified and may vary from implementation to implementation. A suggested approach is to immediately close all other Network-Layer protocols (i.e., cause IPCP to transmit a Terminate-Request), but to continue transmitting Link-Quality-Reports. Once the link quality again reaches an acceptable level, Network-Layer protocols can be reconfigured. 8.7. Example An example may be helpful. Assume that Link-Manager implementation A transmits a Link-Quality-Report which is received by Link-Manager implementation B at time t0 with the following values: Out-Tx-Packets 5 Out-Tx-Octets 100 In-Rx-Packets 3 In-Rx-Octets 70 Assume that A then transmits 20 IP packets with 200 octets, of which 15 packets and 150 octets are received by B. At time t1, A transmits another LQR which is received by B as follows: Out-Tx-Packets 26 (5 old, plus 20 IP, plus 1 LQR) Out-Tx-Octets 342 (42 for LQR) In-Rx-Packets 19 In-Rx-Octets 262 updated by Simpson FORMFEED[Page 69] RFC ???? Point-to-Point Protocol April 1991 Implementation B can now calculate the number of packets and octets transmitted, received and lost on its inbound link as follows: In-Tx-Packets = 26 - 5 = 21 In-Tx-Octets = 342 - 100 = 242 In-Rx-Packets = 10 - 3 = 16 In-Rx-Octets = 262 - 70 = 192 In-Lost-Packets = 21 - 16 = 5 In-Lost-Octets = 242 - 192 = 50 After doing these calculations, B evaluates the measurements in what ever way its implemented policy specifies. Also, the next time that B transmits an LQR to A, it will report these values in the Measurements section, thereby allowing A to evaluate these same measurements. updated by Simpson FORMFEED[Page 70] RFC ???? Point-to-Point Protocol April 1991 A. Asynchronous HDLC This appendix summarizes the modifications to ISO 3309-1979 proposed in ISO 3309:1984/PDAD1. These modifications allow HDLC to be used with 8-bit asynchronous links. Transmission Considerations Each octet is delimited by a start and a stop element. Flag Sequence The Flag Sequence is a single octet and indicates the beginning or end of a frame. The Flag Sequence consists of the binary sequence 01111110 (hexadecimal 0x7e). Transparency On asynchronous links, a character stuffing procedure is used. The Control Escape octet is defined as binary 01111101 (hexadecimal 0x7d) where the bit positions are numbered 87654321 (not 76543210, BEWARE). After FCS computation, the transmitter examines the entire frame between the two Flag Sequences. Each Flag Sequence, Control Escape octet and octet with value less than hexadecimal 0x20 which is flagged in the Remote Async-Control-Character-Map is replaced by a two octet sequence consisting of the Control Escape octet and the original octet with bit 6 complemented (i.e., exclusive-or'd with hexadecimal 0x20). Prior to FCS computation, the receiver examines the entire frame between the two Flag Sequences. Each octet with value less than hexadecimal 0x20 is checked. If it is flagged in the Local Async-Control-Character-Map, it is simply removed (it may have been inserted by intervening data communications equipment). For each Control Escape octet, that octet is also removed, but bit 6 of the following octet is complemented. A Control Escape octet immediately preceding the closing Flag Sequence indicates an invalid frame. Note: The inclusion of all octets less than hexadecimal 0x20 allows all ASCII control characters [10] excluding DEL (Delete) to be transparently communicated through almost all known data communications equipment. The transmitter may also send octets with value in the range 0x40 through 0xff (except 0x5e) in transparent format. Since these updated by Simpson FORMFEED[Page 71] RFC ???? Point-to-Point Protocol April 1991 octet values are not negotiable, this does not solve the problem of receivers which cannot handle all non-control characters. Also, since the technique does not change the 8th bit, this does not solve problems for communications links that can send only 7- bit characters. A few examples may make this more clear. Packet data is transmitted on the link as follows: 0x7e is encoded as 0x7d, 0x5e. 0x7d is encoded as 0x7d, 0x5d. 0x01 is encoded as 0x7d, 0x21. Some modems with software flow control may intercept outgoing DC1 and DC3 ignoring the 8th (parity) bit. This data would be transmitted on the link as follows: 0x11 is encoded as 0x7d, 0x31. 0x13 is encoded as 0x7d, 0x33. 0x91 is encoded as 0x7d, 0xC1. 0x93 is encoded as 0x7d, 0xC3. Aborting a Transmission On asynchronous links, frames may be aborted by transmitting a "0" stop bit where a "1" bit is expected (framing error) or by transmitting a Control Escape octet followed immediately by a closing Flag Sequence. Inter-frame Time Fill On asynchronous links, inter-octet and inter-frame time fill should be accomplished by transmitting continuous "1" bits (mark- hold state). Note: On asynchronous links, inter-frame time fill can be viewed as extended inter-octet time fill. Doing so can save one octet for every frame, decreasing delay and increasing bandwidth. This is possible since a Flag Sequence may serve as both a frame close and a frame begin. After having received any frame, an idle receiver will always be in a frame begin state. Robust transmitters should avoid using this trick over- zealously since the price for decreased delay is decreased reliability. Noisy links may cause the receiver to receive garbage characters and interpret them as part of an incoming frame. If the transmitter does not transmit a new opening Flag updated by Simpson FORMFEED[Page 72] RFC ???? Point-to-Point Protocol April 1991 Sequence before sending the next frame, then that frame will be appended to the noise characters causing an invalid frame (with high reliability). Transmitters should avoid this by transmitting an open Flag Sequence whenever "appreciable time" has elapsed since the prior closing Flag Sequence. It is suggested that implementations will achieve the best results by always sending an opening Flag Sequence if the new frame is not back-to-back with the last. The maximum value for "appreciable time" is likely to be no greater than the typing rate of a slow to average typist, say 1 second. updated by Simpson FORMFEED[Page 73] RFC ???? Point-to-Point Protocol April 1991 B. Fast Frame Check Sequence (FCS) Implementation B.1. FCS Computation Method The following code provides a table lookup computation for calculating the Frame Check Sequence as data arrives at the interface. This implementation is based on [7], [8], and [9]. The table is created by the code in section 2. /* * u16 represents an unsigned 16-bit number. Adjust the typedef for * your hardware. */ typedef unsigned short u16; /* * FCS lookup table as calculated by the table generator in section 2. */ static u16 fcstab[256] = { 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e, 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876, 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd, 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5, 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c, 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974, 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb, 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3, 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a, 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72, 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9, 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1, 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738, 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70, 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7, 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff, 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036, 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e, 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5, 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd, 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134, 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c, 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3, 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb, 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232, 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a, updated by Simpson FORMFEED[Page 74] RFC ???? Point-to-Point Protocol April 1991 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1, 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9, 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330, 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78 }; #define PPPINITFCS 0xffff /* Initial FCS value */ #define PPPGOODFCS 0xf0b8 /* Good final FCS value */ /* * Calculate a new fcs given the current fcs and the new data. */ u16 pppfcs(fcs, cp, len) register u16 fcs; register unsigned char *cp; register int len; { ASSERT(sizeof (u16) == 2); ASSERT(((u16) -1) > 0); while (len--) fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff]; return (fcs); } updated by Simpson FORMFEED[Page 75] RFC ???? Point-to-Point Protocol April 1991 B.2. Fast FCS table generator The following code creates the lookup table used to calculate the FCS. /* * Generate a FCS table for the HDLC FCS. * * Drew D. Perkins at Carnegie Mellon University. * * Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier. */ /* * The HDLC polynomial: x**0 + x**5 + x**12 + x**16 (0x8408). */ #define P 0x8408 main() { register unsigned int b, v; register int i; printf("typedef unsigned short u16;\n"); printf("static u16 fcstab[256] = {"); for (b = 0; ; ) { if (b % 8 == 0) printf("\n"); v = b; for (i = 8; i--; ) v = v & 1 ? (v >> 1) ^ P : v >> 1; printf("0x%04x", v & 0xFFFF); if (++b == 256) break; printf(","); } printf("\n};\n"); } updated by Simpson FORMFEED[Page 76] RFC ???? Point-to-Point Protocol April 1991 References [1] Electronic Industries Association, EIA Standard RS-232-C, "Interface Between Data Terminal Equipment and Data Communications Equipment Employing Serial Binary Data Interchange", August 1969. [2] International Organization For Standardization, ISO Standard 3309-1979, "Data communication - High-level data link control procedures - Frame structure", 1979. [3] International Organization For Standardization, ISO Standard 4335-1979, "Data communication - High-level data link control procedures - Elements of procedures", 1979. [4] International Organization For Standardization, ISO Standard 4335-1979/Addendum 1, "Data communication - High-level data link control procedures - Elements of procedures - Addendum 1", 1979. [5] International Organization For Standardization, Proposed Draft International Standard ISO 3309:1983/PDAD1, "Information processing systems - Data communication - High-level data link control procedures - Frame structure - Addendum 1: Start/stop transmission", 1984. [6] International Telecommunication Union, CCITT Recommendation X.25, "Interface Between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for Terminals Operating in the Packet Mode on Public Data Networks", CCITT Red Book, Volume VIII, Fascicle VIII.3, Rec. X.25., October 1984. [7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June, 1983. [8] Morse, G., "Calculating CRC's by Bits and Bytes", Byte, September 1986. [9] LeVan, J., "A Fast CRC", Byte, November 1987. [10] American National Standards Institute, ANSI X3.4-1977, "American National Standard Code for Information Interchange", 1977. [11] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990. updated by Simpson FORMFEED[Page 77] RFC ???? Point-to-Point Protocol April 1991 Security Considerations Security issues are discussed in sections 4 and 7.4. Acknowledgments This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Much of the text in this document is taken from previous documents produced by the IETF-PPP, formerly chaired by Drew Perkins of Carnegie Mellon University, and by Russ Hobby of the University of California at Davis. Many people spent significant time helping to develop the Point-to- Point Protocol. The complete list of people is too numerous to list, but the following people deserve special thanks: Ken Adelman (TGV), Craig Fox (NSC), Phill Gross (NRI), Russ Hobby (UC Davis), David Kaufman (Proteon), John LoVerso (Xylogics), Bill Melohn (Sun Microsystems), Mike Patton (MIT), Drew Perkins (CMU), Greg Satz (cisco systems) and Asher Waldfogel (Wellfleet). Chair's Address The working group can be contacted via the current chair: Stev Knowles FTP Software 26 Princess Street Wakefield, MA 01880-3004 Phone: (617) 246-0900 x270 EMail: Stev@FTP.com Author's Address Questions about this memo can also be directed to the most recent volunteer editor: William A Simpson Computer Systems Consulting Services P O Box 6205 East Lansing, MI 48826-6025 updated by Simpson FORMFEED[Page 78] RFC ???? Point-to-Point Protocol April 1991 EMail: Bill_Simpson@um.cc.umich.edu updated by Simpson FORMFEED[Page 79] RFC ???? Point-to-Point Protocol April 1991 Table of Contents 1. Introduction .......................................... 1 1.1 Motivation ...................................... 1 1.2 Overview of PPP ................................. 1 1.3 Organization of the document .................... 2 2. Physical Layer Requirements ........................... 3 3. The Data Link Layer ................................... 4 3.1 Frame Format .................................... 5 4. PPP Link Control ...................................... 9 5. The Option Negotiation Automaton ...................... 12 5.1 State Diagram ................................... 12 5.2 State Transition Table .......................... 14 5.3 Events .......................................... 14 5.4 Actions ......................................... 18 5.5 States .......................................... 19 5.6 Loop Avoidance .................................. 22 5.7 Timers and Counters ............................. 22 6. LCP Packet Formats .................................... 24 6.1 Configure-Request ............................... 27 6.2 Configure-Ack ................................... 28 6.3 Configure-Nak ................................... 30 6.4 Configure-Reject ................................ 32 6.5 Terminate-Request and Terminate-Ack ............. 34 6.6 Code-Reject ..................................... 36 6.7 Protocol-Reject ................................. 37 6.8 Echo-Request and Echo-Reply ..................... 39 6.9 Discard-Request ................................. 41 6.10 Link-Quality-Report ............................. 43 7. LCP Configuration Options ............................. 47 7.1 Format .......................................... 48 7.2 Maximum-Receive-Unit ............................ 49 7.3 Async-Control-Character-Map ..................... 50 7.4 Authentication-Type ............................. 52 7.5 Magic-Number .................................... 54 7.6 Link-Quality-Monitoring ......................... 57 7.7 Protocol-Field-Compression ...................... 58 7.8 Address-and-Control-Field-Compression ........... 60 7.9 32 Bit FCS ...................................... 62 8. Link Quality Monitoring ............................... 63 updated by Simpson FORMFEED[Page iii] RFC ???? Point-to-Point Protocol April 1991 8.1 Design Motivation ............................... 63 8.2 Design Overview ................................. 63 8.3 Processes ....................................... 64 8.4 Counters ........................................ 66 8.5 Measurements, Calculations, State Variables ..... 67 8.6 Policy Suggestions .............................. 69 8.7 Example ......................................... 69 APPENDICES ................................................... 71 A. Asynchronous HDLC ..................................... 71 B. Fast Frame Check Sequence (FCS) Implementation ........ 74 B.1 FCS Computation Method .......................... 74 B.2 Fast FCS table generator ........................ 76 REFERENCES ................................................... 77 SECURITY CONSIDERATIONS ...................................... 78 ACKNOWLEDGEMENTS ............................................. 78 CHAIR'S ADDRESS .............................................. 78 AUTHOR'S ADDRESS ............................................. 78 updated by Simpson FORMFEED[Page iv] From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 16 09:40:15 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25013; Tue, 16 Apr 91 09:18:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from EMERALD.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24843; Tue, 16 Apr 91 09:08:32 -0700 Received: by emerald.acc.com (4.1/SMI-4.1) id AA10570; Tue, 16 Apr 91 09:17:51 PDT Date: Tue, 16 Apr 91 09:17:51 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9104161617.AA10570@emerald.acc.com> To: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.edu Subject: Form Feed What you do is run the nroff output through the following filter. It assumes that you have the "page length" specifications .pl 58 but gives you the ability to override that Fred ========================================================== #include #define BUFFERSIZE 512 main (argc, argv) int argc; char *argv []; { char buffer [ BUFFERSIZE ]; int linecnt; int pagecnt; if (argc > 1) { pagecnt = atoi (argv [ 1 ]); } else { pagecnt = 58; } linecnt = 1; while (fgets (buffer, BUFFERSIZE, stdin) != NULL) { fputs (buffer, stdout); if (linecnt >= pagecnt) { fputs ("\f\n", stdout); linecnt = 0; } linecnt++; } } From ietf-ppp-request@ucdavis.ucdavis.edu Tue Apr 16 09:52:29 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25245; Tue, 16 Apr 91 09:30:58 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from EMERALD.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25041; Tue, 16 Apr 91 09:19:57 -0700 Received: by emerald.acc.com (4.1/SMI-4.1) id AA10601; Tue, 16 Apr 91 09:29:52 PDT Date: Tue, 16 Apr 91 09:29:52 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9104161629.AA10601@emerald.acc.com> To: ietf-ppp@ucdavis.edu Subject: A nit Loopback is a noun, the name of a state. Is it also a verb? Twice in the new document (and probably in the old, but I didn't notice it) there is the text "loopbacked links. Unless modified by a Configuration Option,". Suggestion: "links in the Loopback Condition.". Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 17 10:34:38 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18317; Wed, 17 Apr 91 10:02:53 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Mail.Think.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18264; Wed, 17 Apr 91 09:59:00 -0700 Return-Path: Received: from Think.COM by mail.think.com; Wed, 17 Apr 91 13:00:49 -0400 Received: from signet.UUCP by Early-Bird.Think.COM; Wed, 17 Apr 91 13:00:46 EDT Received: by signet.UUCP (4.0/SMI-4.0) id AA00365; Wed, 17 Apr 91 11:20:45 EDT Date: Wed, 17 Apr 91 11:20:45 EDT From: signet!kwab@Think.COM (Kwabena Akufo) Message-Id: <9104171520.AA00365@signet.UUCP> To: ietf-ppp@ucdavis.edu Subject: BOOTP and PPP Question 1. How can BOOTP be used across a serial link? BOOTP assumes there is a MAC address which a serial link does not have. Specifically how can BOOTP be used across a PPP link when the units on the two sides of the link don't know their IP address yet? 2. If the above questions are too specific to BOOTP and PPP then consider the following general question. I have two LANs, named A and B, interconnected by a router that routes between them across a serial link. I have an NMS (Server) on LAN A containing image files for all diskless units on LAN A and on LAN B. I know it is easy to boot diskless units on LAN A using BOOTP and TFTP since LAN A has the server and I can broadcast BOOTP on LAN A. How do I boot diskless units (e.g. B2) on LAN B using image files resident on the server on LAN A? -------- -------- PPP --------- --------- | NMS | | A1 |-------/ | B1 | | B2 | | | | | /--------| | | | -------- -------- --------- --------- | | | | ----------------------LAN A --------------------------- LAN B 3. Philosophical problem: I am building concentrators that need to be managed. I choose to use SNMP to manage them. SNMP calls for UDP/IP, etc. Suddenly, I am asking the user to build IP routing tables in the concentrators and be knowledgeable about IP. I know it makes sense technically but I have a philosophical problem with it. Any comments???? From ietf-ppp-request@ucdavis.ucdavis.edu Wed Apr 17 18:11:30 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27529; Wed, 17 Apr 91 17:46:31 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from PO2.ANDREW.CMU.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27482; Wed, 17 Apr 91 17:44:08 -0700 Received: by po2.andrew.cmu.edu (5.54/3.15) id for ietf-ppp@ucdavis.edu; Wed, 17 Apr 91 20:45:59 EDT Received: via switchmail; Wed, 17 Apr 91 20:45:55 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Wed, 17 Apr 91 20:45:30 -0400 (EDT) Received: from valkyries.andrew.cmu.edu via qmail ID ; Wed, 17 Apr 91 20:45:28 -0400 (EDT) Received: from BatMail.robin.v2.10.CUILIB.3.45.SNAP.NOT.LINKED.valkyries.andrew.cmu.edu.pmax.30 via MS.5.6.valkyries.andrew.cmu.edu.pmax_30; Wed, 17 Apr 91 20:45:26 -0400 (EDT) Message-Id: Date: Wed, 17 Apr 91 20:45:26 -0400 (EDT) From: Drew Daniel Perkins To: fbaker@acc.com (Fred Baker) Subject: Re: A nit Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9104161629.AA10601@emerald.acc.com> References: <9104161629.AA10601@emerald.acc.com> I think I was responsible for that poor terminology. I remember spending a lot of time worrying about the correct grammar for that one... Drwe From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 18 13:44:10 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16847; Thu, 18 Apr 91 13:17:50 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16560; Thu, 18 Apr 91 13:00:33 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA09106; Thu, 18 Apr 91 16:03:05 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9104182003.AA09106@vela.acs.oakland.edu> Subject: Re: A nit To: ddp+@andrew.cmu.edu (Drew Daniel Perkins) Date: Thu, 18 Apr 91 16:03:04 EDT Cc: ietf-ppp@ucdavis.edu In-Reply-To: ; from "Drew Daniel Perkins" at Apr 17, 91 8:45 pm X-Mailer: ELM [version 2.3 PL6] I'll fix it. Bill From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 18 13:48:18 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17287; Thu, 18 Apr 91 13:36:00 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16894; Thu, 18 Apr 91 13:19:16 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA10138; Thu, 18 Apr 91 16:21:55 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9104182021.AA10138@vela.acs.oakland.edu> Subject: status of ISO extension To: ietf-ppp@ucdavis.edu Date: Thu, 18 Apr 91 16:21:54 EDT X-Mailer: ELM [version 2.3 PL6] There is a "Note:" which encourages folks to monitor the progress of the async extension. Does anyone know what the status is? Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 18 17:34:06 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21465; Thu, 18 Apr 91 17:16:24 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uunet.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21233; Thu, 18 Apr 91 17:00:15 -0700 Received: from robin.telebit.COM by uunet.UU.NET with SMTP (5.61/UUNET-primary-gateway) id AA17475; Thu, 18 Apr 91 20:02:45 -0400 Received: from napa.telebit.com by robin.telebit.COM id aa20344; Thu, 18 Apr 91 17:02:55 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-1) id AA00655 to ddp+@andrew.cmu.edu; Thu, 18 Apr 91 16:59:12 PDT Date: Thu, 18 Apr 91 16:59:12 PDT From: Brian Lloyd Message-Id: <9104182359.AA00655> To: bsimpson@vela.acs.oakland.edu Cc: ddp+@andrew.cmu.edu, ietf-ppp@ucdavis.edu In-Reply-To: Bill Simpson's message of Thu, 18 Apr 91 16:03:04 EDT <9104182003.AA09106@vela.acs.oakland.edu> Subject: A nit Hey guys, if you are exchanging messages, could you count me in? I am interested in anything that has to do with changes to the PPP rfc's. Brian From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 18 19:18:55 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21465; Thu, 18 Apr 91 17:16:24 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uunet.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21233; Thu, 18 Apr 91 17:00:15 -0700 Received: from robin.telebit.COM by uunet.UU.NET with SMTP (5.61/UUNET-primary-gateway) id AA17475; Thu, 18 Apr 91 20:02:45 -0400 Received: from napa.telebit.com by robin.telebit.COM id aa20344; Thu, 18 Apr 91 17:02:55 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-1) id AA00655 to ddp+@andrew.cmu.edu; Thu, 18 Apr 91 16:59:12 PDT Date: Thu, 18 Apr 91 16:59:12 PDT From: Brian Lloyd Message-Id: <9104182359.AA00655> To: bsimpson@vela.acs.oakland.edu Cc: ddp+@andrew.cmu.edu, ietf-ppp@ucdavis.edu In-Reply-To: Bill Simpson's message of Thu, 18 Apr 91 16:03:04 EDT <9104182003.AA09106@vela.acs.oakland.edu> Subject: A nit Hey guys, if you are exchanging messages, could you count me in? I am interested in anything that has to do with changes to the PPP rfc's. Brian From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 18 21:53:34 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02712; Thu, 18 Apr 91 21:30:10 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from poe.aa.ox.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02476; Thu, 18 Apr 91 21:16:20 -0700 Received: by poe.aa.ox.com (/\=-/\ Smail3.1.18.1 #18.34) id ; Fri, 19 Apr 91 00:13 EDT Message-Id: To: tcp-ip@nic.ddn.mil Cc: ietf-ppp@ucdavis.edu Subject: call for discussion of usenet newsgroup 'comp.protocols.ppp'. Date: Fri, 19 Apr 91 00:13:26 EDT From: Edward Vielmetti [This will be familiar to you if you have read news.groups or comp.dcom.lans recently. I am not posting it from news because the gateway eats my address.] I am gathering opinions and interest for a new Usenet newsgroup, to be called 'comp.protocols.ppp'. It will discuss the Internet "Point to Point Protocol", implementations, protocol details, interoperability reports, software, hardware, etc. Currently there is a fair amount of discussion of PPP on Usenet; though it's scattered around in a number of groups, I was able to count on the order of 50+ relevant articles in a span of two weeks. Unfortunatly these articles were in more than a dozen different groups, and there's no single one group where the discussion would ordinarily gravitate. This group would cover the following subject: - the Point to Point Protocol - IETF efforts at standardizing and extending the protocol - free and commercial software implementations - interoperability reports - other protocols occupying similar ecological niches, including SLIP, compressed SLIP, and various HDLC things (but not other async protocols like Kermit or xmodem) - hardware details of async and sync communications, whenever that ends up being relevant. The usual Usenet ritual involves a "request for discussion", a period of time for hair-tearing and gnashing of teeth to determine whether the name is suitable, and then a "call for votes". The discussion thus far has centered on whether the name is too narrow and shouldn't be widened to encompass SLIP; I suspect that the actual discussion in a "ppp" group will include slip discussion for a while if only because of the installed base. Comments can go to me or to the list; discussion regarding the name is traditionally the playpen of news.groups. Substantive discussion of PPP would be best done in the two existing usenet groups that get most of the traffic (comp.dcom.lans and comp.dcom.modems) or on the IETF PPP mailing list (mail to ietf-ppp-request@ucdavis.edu to join). -- Msen Edward Vielmetti /|--- moderator, comp.archives emv@msen.com "With all of the attention and publicity focused on gigabit networks, not much notice has been given to small and largely unfunded research efforts which are studying innovative approaches for dealing with technical issues within the constraints of economic science." RFC 1216 From ietf-ppp-request@ucdavis.ucdavis.edu Thu Apr 18 23:00:29 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA03870; Thu, 18 Apr 91 22:46:28 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uunet.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA03797; Thu, 18 Apr 91 22:41:58 -0700 Received: from robin.telebit.COM by uunet.UU.NET with SMTP (5.61/UUNET-primary-gateway) id AA10588; Fri, 19 Apr 91 01:41:24 -0400 Received: from napa.telebit.com by robin.telebit.COM id aa20751; Thu, 18 Apr 91 22:41:34 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-1) id AA00924 to tcp-ip@nic.ddn.mil; Thu, 18 Apr 91 22:37:49 PDT Date: Thu, 18 Apr 91 22:37:49 PDT From: Brian Lloyd Message-Id: <9104190537.AA00924> To: emv@ox.com Cc: tcp-ip@nic.ddn.mil, ietf-ppp@ucdavis.edu In-Reply-To: Edward Vielmetti's message of Fri, 19 Apr 91 00:13:26 EDT Subject: call for discussion of usenet newsgroup 'comp.protocols.ppp'. I propose comp.protocols.serial-internetworking. The name is more in line with the likely discussion areas including slip, ppp, and using all this stuff to build or extend networks. Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@napa.telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 22 08:03:09 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04681; Mon, 22 Apr 91 07:46:15 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from VOODOO.UTCC.UTK.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04632; Mon, 22 Apr 91 07:43:14 -0700 Received: from LOCALHOST.utcc.utk.edu by voodoo.utcc.utk.edu with SMTP (5.61++/2.6c-UTK) id AA10443; Mon, 22 Apr 91 10:42:38 -0400 Message-Id: <9104221442.AA10443@voodoo.utcc.utk.edu> To: ietf-ppp@ucdavis.edu Cc: snyder@voodoo.utcc.utk.edu Subject: What kind of work is in progress wrt PPP? Date: Mon, 22 Apr 91 10:42:37 EDT From: snyder@utkux1.utk.edu how about appletalk over PPP? or CLNP over PPP? And supposing one would want to implement another protocol over PPP, how would one go about getting a number assigned? Kim Snyder University of Tennessee, Knoxville snyder@utkux1.utk.edu From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 22 10:29:28 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA06927; Mon, 22 Apr 91 09:57:53 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nsco.network.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA06634; Mon, 22 Apr 91 09:41:05 -0700 Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA08601; Mon, 22 Apr 91 11:41:28 -0500 Received: from eros.network.com by anubis.network.com (4.0/SMI-4.0) id AA26272; Mon, 22 Apr 91 11:40:09 CDT Date: Mon, 22 Apr 91 11:40:09 CDT From: sjs@anubis.network.com (Steve Senum) Message-Id: <9104221640.AA26272@anubis.network.com> To: ietf-ppp@ucdavis.edu Subject: Re: What kind of work is in progress wrt PPP? Cc: veizades@apple.com > how about appletalk over PPP? or CLNP over PPP? > And supposing one would want to implement another protocol > over PPP, how would one go about getting a number assigned? > > Kim Snyder > University of Tennessee, Knoxville > snyder@utkux1.utk.edu I signed up to do the Appletalk over PPP RFC, and have a draft somewhat done, but since then several other people have expressed interest in doing such an RFC. They are: wbs@lll-crg.llnl.gov brad@Cayman.com Robert_Jeckell@3mail.3com.com I have sent them copies of my draft, and Frank Slaughter's (Shiva). I leave it to them to complete this work. Also, John Veizades (Apple-IP working group chair, veizades@apple.com) has asked to have any work generated on this passed to the Apple-IP group as well Steve Senum From ietf-ppp-request@ucdavis.ucdavis.edu Mon Apr 22 18:04:53 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16399; Mon, 22 Apr 91 17:48:01 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from cayman.cayman.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16178; Mon, 22 Apr 91 17:34:12 -0700 Received: from cuba.Cayman.COM by cayman.Cayman.COM (4.1/SMI-4.0) id AA21521; Mon, 22 Apr 91 20:33:36 EDT Received: from localhost by cuba.Cayman.COM (4.1/SMI-4.1) id AA26684; Mon, 22 Apr 91 20:33:33 EDT Message-Id: <9104230033.AA26684@cuba.Cayman.COM> To: sjs@anubis.network.com (Steve Senum) Cc: ietf-ppp@ucdavis.edu Subject: Re: What kind of work is in progress wrt PPP? In-Reply-To: Mail from sjs@anubis.network.com (Steve Senum) dated Mon, 22 Apr 91 11:40:09 CDT <9104221640.AA26272@anubis.network.com> Date: Mon, 22 Apr 91 20:33:33 -0400 From: brad@Cayman.COM >> > how about appletalk over PPP? or CLNP over PPP? >> > And supposing one would want to implement another protocol >> > over PPP, how would one go about getting a number assigned? >> > >> > Kim Snyder >> > University of Tennessee, Knoxville >> > snyder@utkux1.utk.edu >> >> I signed up to do the Appletalk over PPP RFC, and have a draft somewhat >> done, but since then several other people have expressed interest in >> doing such an RFC. They are: >> >> wbs@lll-crg.llnl.gov >> brad@Cayman.com >> Robert_Jeckell@3mail.3com.com Yes, indeady. I am working (slowly) on this and have made some progress. I made the mistake if actually implementing some of it at the same time (and boy has that slowed progress!) I do plan to put something about shortly, but both I *and* Dave McCool of Shiva are getting married on the *same day* (this saturday), so we're not giving it our full attention ;-) (neither of our fiancees know anyting about PPP and both concider it a urinary disorder) Please feel free to bug me in 3 weeks and/or send me mail. -brad From ietf-ppp-request@ucdavis.ucdavis.edu Sat Apr 27 14:14:05 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04044; Sat, 27 Apr 91 13:47:10 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [141.210.10.2] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA03853; Sat, 27 Apr 91 13:32:25 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA14863; Sat, 27 Apr 91 16:30:35 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9104272030.AA14863@vela.acs.oakland.edu> Subject: Re: call for discussion of usenet newsgroup 'comp.protocols.ppp'. To: brian@napa.telebit.com (Brian Lloyd) Date: Sat, 27 Apr 91 16:30:34 EDT Cc: tcp-ip@nic.ddn.mil, ietf-ppp@ucdavis.edu In-Reply-To: <9104190537.AA00924>; from "Brian Lloyd" at Apr 18, 91 10:37 pm X-Mailer: ELM [version 2.3 PL6] Too complicated. What about comp.protocols.serial, and gateway to/from the ietf-ppp list? Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Sat Apr 27 17:46:11 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA06472; Sat, 27 Apr 91 17:33:29 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uunet.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA06354; Sat, 27 Apr 91 17:28:44 -0700 Received: from robin.telebit.COM by uunet.UU.NET with SMTP (5.61/UUNET-primary-gateway) id AA13073; Sat, 27 Apr 91 20:27:59 -0400 Received: from napa.telebit.com by robin.telebit.COM id aa16849; Sat, 27 Apr 91 17:26:56 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910424) id AA18965 to tcp-ip@nic.ddn.mil; Sat, 27 Apr 91 17:23:37 PDT Date: Sat, 27 Apr 91 17:23:37 PDT From: Brian Lloyd Message-Id: <9104280023.AA18965@napa.TELEBIT.COM> To: bsimpson@vela.acs.oakland.edu Cc: tcp-ip@nic.ddn.mil, ietf-ppp@ucdavis.edu In-Reply-To: Bill Simpson's message of Sat, 27 Apr 91 16:30:34 EDT <9104272030.AA14863@vela.acs.oakland.edu> Subject: call for discussion of usenet newsgroup 'comp.protocols.ppp'. I am not sure that ietf-ppp should go away. There needs to be a place where implementors can go to talk where the S/N ratio remains high. Brian