From ietf-ppp-request@ucdavis.ucdavis.edu Thu May 2 04:00:05 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09736; Thu, 2 May 91 03:31:49 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from csusac.ecs.csus.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09618; Thu, 2 May 91 03:22:24 -0700 Received: by csusac.ecs.csus.edu (5.61/1.34) id AA03509; Thu, 2 May 91 06:21:14 -0400 Received: by unify.com (5.61/smail2.5/06-13-89/jwc.2) id AA20541; Thu, 2 May 91 02:29:44 -0700 Received: from retix.retix.com by relay1.UU.NET with UUCP (5.61/UUNET-internet-primary) id AA01975; Wed, 1 May 91 20:44:06 -0400 Received: from sun2.retix.com by retix.retix.com (5.65a/smail2.5/26-04-91) id AA05199; Wed, 1 May 91 15:43:22 -0700 Received: by sun2.retix.com (5.65a/smail2.5/9-30-90) id AA27719; Wed, 1 May 91 15:43:19 -0700 Date: Wed, 1 May 91 15:43:19 -0700 From: phj@sun2.retix.com (Paul Harding-Jones) Message-Id: <9105012243.AA27719@sun2.retix.com> To: fbaker@ACC.COM, ietf-ppp@ucdavis.edu Subject: Comments on RFC 1220 : Bridging PPP I've recently received the Bridging Point-to-Point Protocol RFC (1220), and would like to make a few comments about the protocol operation. My initial concern is that the protocol is perhaps too complex, and is attempting to provide unnecessary features, that simply increase the complexity of WAN bridging ports. The remote bridging model adopted by the protocol (serial link treated as a LAN) suggests that bridging processes can treat WAN and LAN ports similarly, which is ideal for the implementor and desirable for the network administrator as it provides a uniform interface for all bridging ports (LAN & WAN). However some of the ideas used in the protocol stray from this approach. IEEE802.1d SPANNING TREE PROTOCOL TRAFFIC The RFC describes a method for transmitting Spanning Tree Configuration (Hello) BPDUs down the serial link. I assume that the same frame format is also used for the other Spanning Tree BPDU type; Topology Change Notification (TCN) BPDUs, with the type field of the BPDU data used to distinguish between the two types, as with BPDUs received on LAN ports. I am a little concerned about the missing MAC header for these BPDUs. Obviously there is no standard MAC header to use for frames that have been generated for transmission to a WAN bridging port, but the destination address of the MAC header is used to distinguish the Spanning Tree domain the BPDU belongs to. It should be possible for the remote bridge halves to operate in separate STP domains as described in section 3.4 of the RFC. It is suggested that each end of the link be configured not to exchange BPDUs on the link in order to isolate the two Spanning Tree domains - however standard bridge operation would provide this funcitonality by simply adding a permanent filtering database entry for the domain address used in the partner unit with a disposition of discard. This would obviously require the MAC address to be sent with the BPDU data. Also in the MAC header would be the source MAC address - in this case the MAC address of the partner unit. If this address is not sent in the BPDU, then it will not be learnt in the filtering database, and any traffic destined for our partner will be flooded. Although frames will obviously get to our partner its not a particularly nice solution. Surely it would be better not to treat these BPDUs separately. They can be transmitted across the PPP link, with a MAC encapsulation (any of the MAC encapsulations, as long as the PPP MAC type field matched the encapsulation used). Now both the bridging receive processes and Spanning Tree Protocol processes can truly treat WAN and LAN ports alike, leading to simpler implementations and more uniform interfaces. MAC ADDRESSES The RFC states that the MAC addresses sent in bridged traffic across the PPP links should be in MAC order, with the MAC type field indicating the MAC type used. This is fine for simple bridges which are always bridging the same MAC types. However for units that bridge between MAC types it can cause problems. A sensible approach to bridging between different MAC types is to only work with a single MAC address order within the unit, with conversions to the relevant MAC order done at the interface to the LAN if necessary. A unit bridging 802.3 to 802.5 may only use canonical (802.3) order addresses within the unit with conversions being performed at the 802.5 interface. If such a unit were to also have a WAN link to a remote partner, the PPP protocol as it stands requires a redundant bit swap just to go across the serial link. Rather than insisting on the transmission of all MAC addresses in MAC order, would it not be possible to define a field (it only need be a single bit) in the bridging frame format to represent the order that the MAC address is in. This would provide much greater flexibility for the protocol users. LINE & RING IDENTIFIER NEGOTIATION This option seems to be a little superflous to source routing requirements. Source routing is not a plug-in-and-play protocol, and always requires preconfiguration by the network administrator. The protocol provides its own method of discovering LAN Id mismatches, through the validation of explorer frames - does the line & ring identification option provide any advantage to this. What should be done if the negotiation fails ? We certainly wouldn't want to change the configuration under our manager's feet. These options could be removed, and network configuration left entirely to the network manager. If a bridge needs to know whether its WAN link is represented by a virtual ring this can simply be a parameter of the port. Paul Harding-Jones Retix 2644 30th Street Santa Monica CA 90405 Phone: (213) 399-2200 From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 10 14:47:33 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA19830; Fri, 10 May 91 14:31:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [192.100.72.1] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA19641; Fri, 10 May 91 14:24:15 -0700 Received: from sun2.retix.com by retix.retix.com (5.65a/smail2.5/30-04-91) id AA08659; Fri, 10 May 91 14:22:47 -0700 Received: by sun2.retix.com (5.65a/smail2.5/9-30-90) id AA07250; Fri, 10 May 91 14:22:45 -0700 Date: Fri, 10 May 91 14:22:45 -0700 From: phj@sun2.retix.com (Paul Harding-Jones) Message-Id: <9105102122.AA07250@sun2.retix.com> To: fbaker@ACC.COM, ietf-ppp@ucdavis.edu Subject: Comments on Bridging Point-to-Point Protocol Apologies if you've already received and read this message - we've recently been changing our host machine, and I'm not entirely sure that the original message I sent out a couple of weeks ago ever reached the outside world ! If it did, then I'm not sure whether any replies would have made it back to me. I've received no responses to the original message, so here it is again...... I've recently received the Bridging Point-to-Point Protocol RFC (1220), and would like to make a few comments about the protocol operation. My initial concern is that the protocol is perhaps too complex, and is attempting to provide unnecessary features, that simply increase the complexity of WAN bridging ports. The remote bridging model adopted by the protocol (serial link treated as a LAN) suggests that bridging processes can treat WAN and LAN ports similarly, which is ideal for the implementor and desirable for the network administrator as it provides a uniform interface for all bridging ports (LAN & WAN). However some of the ideas used in the protocol stray from this approach. IEEE802.1d SPANNING TREE PROTOCOL TRAFFIC The RFC describes a method for transmitting Spanning Tree Configuration (Hello) BPDUs down the serial link. I assume that the same frame format is also used for the other Spanning Tree BPDU type; Topology Change Notification (TCN) BPDUs, with the type field of the BPDU data used to distinguish between the two types, as with BPDUs received on LAN ports. I am a little concerned about the missing MAC header for these BPDUs. Obviously there is no standard MAC header to use for frames that have been generated for transmission to a WAN bridging port, but the destination address of the MAC header is used to distinguish the Spanning Tree domain the BPDU belongs to. It should be possible for the remote bridge halves to operate in separate STP domains as described in section 3.4 of the RFC. It is suggested that each end of the link be configured not to exchange BPDUs on the link in order to isolate the two Spanning Tree domains - however standard bridge operation would provide this funcitonality by simply adding a permanent filtering database entry for the domain address used in the partner unit with a disposition of discard. This would obviously require the MAC address to be sent with the BPDU data. Also in the MAC header would be the source MAC address - in this case the MAC address of the partner unit. If this address is not sent in the BPDU, then it will not be learnt in the filtering database, and any traffic destined for our partner will be flooded. Although frames will obviously get to our partner its not a particularly nice solution. Surely it would be better not to treat these BPDUs separately. They can be transmitted across the PPP link, with a MAC encapsulation (any of the MAC encapsulations, as long as the PPP MAC type field matched the encapsulation used). Now both the bridging receive processes and Spanning Tree Protocol processes can truly treat WAN and LAN ports alike, leading to simpler implementations and more uniform interfaces. MAC ADDRESSES The RFC states that the MAC addresses sent in bridged traffic across the PPP links should be in MAC order, with the MAC type field indicating the MAC type used. This is fine for simple bridges which are always bridging the same MAC types. However for units that bridge between MAC types it can cause problems. A sensible approach to bridging between different MAC types is to only work with a single MAC address order within the unit, with conversions to the relevant MAC order done at the interface to the LAN if necessary. A unit bridging 802.3 to 802.5 may only use canonical (802.3) order addresses within the unit with conversions being performed at the 802.5 interface. If such a unit were to also have a WAN link to a remote partner, the PPP protocol as it stands requires a redundant bit swap just to go across the serial link. Rather than insisting on the transmission of all MAC addresses in MAC order, would it not be possible to define a field (it only need be a single bit) in the bridging frame format to represent the order that the MAC address is in. This would provide much greater flexibility for the protocol users. LINE & RING IDENTIFIER NEGOTIATION This option seems to be a little superflous to source routing requirements. Source routing is not a plug-in-and-play protocol, and always requires preconfiguration by the network administrator. The protocol provides its own method of discovering LAN Id mismatches, through the validation of explorer frames - does the line & ring identification option provide any advantage to this. What should be done if the negotiation fails ? We certainly wouldn't want to change the configuration under our manager's feet. These options could be removed, and network configuration left entirely to the network manager. If a bridge needs to know whether its WAN link is represented by a virtual ring this can simply be a parameter of the port. Paul Harding-Jones Retix 2644 30th Street Santa Monica CA 90405 Phone: (213) 399-2200 From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 10 16:37:29 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21818; Fri, 10 May 91 16:16:32 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from venera.isi.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21649; Fri, 10 May 91 16:07:56 -0700 Received: from bel.isi.edu by venera.isi.edu (5.61/5.61+local-2) id ; Fri, 10 May 91 16:06:44 -0700 Date: Fri, 10 May 91 16:06:17 PDT From: postel@ISI.EDU Posted-Date: Fri, 10 May 91 16:06:17 PDT Message-Id: <9105102306.AA15409@bel.isi.edu> Received: by bel.isi.edu (4.0/4.0.3-4) id ; Fri, 10 May 91 16:06:17 PDT To: brian@napa.telebit.com, bsimpson@vela.acs.oakland.edu, ghm@merit.edu, stev@babyoil.ftp.com Subject: Re: current PPP number assignments Cc: ietf-ppp@ucdavis.edu, jkrey@ISI.EDU, postel@ISI.EDU Hi. This is to confirm that the IANA (Joyce Reynolds) will be in charge of allocating PPP numbers from now on. Thanks to Bill Simpson for diging up the history of what was done previously. In the future please send requests for PPP number assignments to IANA@ISI.EDU. Thanks --jon. From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 10 16:47:02 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22158; Fri, 10 May 91 16:33:19 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from EMERALD.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21949; Fri, 10 May 91 16:25:54 -0700 Received: by emerald.acc.com (4.1/SMI-4.1) id AA16646; Fri, 10 May 91 16:24:12 PDT Date: Fri, 10 May 91 16:24:12 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9105102324.AA16646@emerald.acc.com> To: phj@sun2.retix.com Subject: Re: Comments on Bridging Point-to-Point Protocol Cc: ietf-ppp@ucdavis.edu Paul: Yes, I had seen your message, and not gotten around to responding to it. I guess my first wish is that you had found time to comment on it during the eight months it was an Internet Draft prior to being published as an RFC. Requested changes would have been much easier to effect. >> the destination address of the MAC header is used to distinguish the >> Spanning Tree domain the BPDU belongs to. Really? You might want to comment on P802.1d/D9 Section 3.12.6, tables 4 and 6. >> If this address is not sent in the BPDU, then it will not be learnt in >> the filtering database, and any traffic destined for our partner will >> be flooded. This is true, I suppose, but I submit that it is solvable. If traffic is being directed there, then traffic will surely return from it, and will then be learned, is this not true? So the ugliness only applies to the first message. The reason that the BPDU is sent as a separate message is because the LANs can be dissimilar, and this eases the discernment of the management traffic. Clearly, the intent of the protocol IS to treat the LAN and WAN sides similarly, but "similar" isn't as strong a word as "same". The WAN has mixed format headers, potentially, while a LAN is forced to pick a format, interpret details, and potentially drop traffic. Some have indicated that they would like to see all traffic converted to a canonical format (not just bit swapped in the header, but an actual common line format) but it hasn't been demonstrated to my satisfaction that a one to one and onto mapping exists from every MAC format to every MAC format, multicast address to functional address and back, etc - reference the "Apple Problem" in Ethernet-FDDI Bridging. So it seems simpler to me to make the BPDU be the same no matter what the LAN traffic mix is, and clearly identify the LAN traffic. >> The RFC states that the MAC addresses sent in bridged traffic across the PPP >> links should be in MAC order, with the MAC type field indicating the MAC type >> used. This is fine for simple bridges which are always bridging the same >> MAC types. However for units that bridge between MAC types it can cause >> problems. A sensible approach to bridging between different MAC types is to >> only work with a single MAC address order within the unit, with conversions >> to the relevant MAC order done at the interface to the LAN if necessary. That can be argued both ways. I wrote a router that co-existed with a bridge in the same remote device, and we included this swapping operation automatically on all 802.5 headers. You wouldn't believe what a bother it became trying to keep track of whether an address was in MAC or Canonical format at any given time. The canonical trick works well as long as the only thing the device ever is is a bridge. That's a bit antique, nowadays. You might also take a look at current technology CAMs. The MU9C1480 LANCAM (from MUSIC Semiconductors - no I don't own stock in them) is a very well designed part for multi-media bridges, having both CAM and RAM capabilities (so you can keep a "dirty" flag managed by the hardware keyed to each address, etc) and being able to consider any address from either orientation on a lookup-by-lookup basis. I frankly consider THAT the simpler approach overall. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 15 17:50:55 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA14391; Wed, 15 May 91 17:00:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA14204; Wed, 15 May 91 16:47:02 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA20308; Wed, 15 May 91 18:19:28 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9105152219.AA20308@vela.acs.oakland.edu> Subject: final draft of revised PPP RFC To: ietf-ppp@ucdavis.edu Date: Wed, 15 May 91 18:19:00 EDT X-Mailer: ELM [version 2.3 PL6] Here is my final draft of the revised PPP RFC. Thanks to those of you who commented on the previous version. This version adds definitions similar to the host and router requirements documents, and includes the latest IANA number assignments. I will forward the document for publication next week. Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu Network Working Group W A Simpson Request for Comments: DRAFT CSCS Obsoletes: RFC 1171 & 1172 May 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 the PPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. updated by Simpson [Page i] RFC DRAFT Point-to-Point Protocol May 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. 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 NCPs. These NCPs are defined in other documents. 1.2. Overview of PPP PPP has three main components: updated by Simpson [Page 1] RFC DRAFT Point-to-Point Protocol May 1991 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 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. Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and carefully updated by Simpson [Page 2] RFC DRAFT Point-to-Point Protocol May 1991 weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option must none-the-less be prepared to interoperate with another implementation which does include the option. 1.4. Terminology This document frequently uses the following terms: peer The other end of the point-to-point link. silently discard This means the implementation MUST discard the packet without further processing. However, for diagnosis of problems, the implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. updated by Simpson [Page 3] RFC DRAFT Point-to-Point Protocol May 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 [Page 4] RFC DRAFT Point-to-Point Protocol May 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 [Page 5] RFC DRAFT Point-to-Point Protocol May 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 MUST 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 updated by Simpson [Page 6] RFC DRAFT Point-to-Point Protocol May 1991 sequence 00000011 (hexadecimal 0x03), the Unnumbered Information (UI) command 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 MUST be considered as having an unrecognized Protocol, and handled as specified by the LCP. The Protocol field is transmitted and received most significant octet first. Protocol field values in the "0xxx" range identify the network- layer protocol of specific datagrams, and values in the "8xxx" range identify datagrams belonging to the associated Network Control Protocols (NCPs), if any. Protocol field values in the "4xxx" range are used for protocols with low volume traffic which have no associated NCP. Protocol field values in the "cxxx" range identify datagrams as Control Protocols (such as LCP). 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 Name 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 0031 Bridging PDU 0033 Stream Protocol (ST-II) 0037 reserved (until 1993) 00ff reserved (compression inefficient) updated by Simpson [Page 7] RFC DRAFT Point-to-Point Protocol May 1991 0201 802.1d Hello Packets 0221 DNA System Console 0223 Digital Customer Use 0225 DNA Diagnostics 0227 DNA Naming Service 0229 DNA Time Service 022b DNA Load/Dump 022d DNA Experimental Use 022f DNA Communications Test 0231 Luxcom 0233 Sigma Network Systems 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 8031 Bridging NCP 8033 Stream Protocol Control Protocol c021 Link Control Protocol c023 Password Authentication Protocol Developers of new protocols MUST obtain a number from the Internet Assigned Numbers Authority (IANA), at IANA@isi.edu. 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. Frame Check Sequence (FCS) Field The Frame Check Sequence field is normally 16 bits (two octets). updated by Simpson [Page 8] RFC DRAFT Point-to-Point Protocol May 1991 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 [Page 9] RFC DRAFT Point-to-Point Protocol May 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 (described below). When a Passive-Open command occurs while in this phase, the LCP automaton will enter 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 MUST 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 [Page 10] RFC DRAFT Point-to-Point Protocol May 1991 authenticate itself before allowing network-layer protocol packets to be exchanged. By default, authentication is not necessary. If an implementation requires that the peer 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 MUST 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, any authentication protocol packets received during any other phase MUST be silently discarded. Network-Layer Protocol Phase Once PPP has finished the previous phases, each network-layer protocol (such as IP) MUST 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 the availability of the LCP Protocol-Reject (described below). updated by Simpson [Page 11] RFC DRAFT Point-to-Point Protocol May 1991 While LCP is in the Opened state, any protocol packet which is unsupported by the implementation MUST be 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 might 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 [Page 12] RFC DRAFT Point-to-Point Protocol May 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 [Page 13] RFC DRAFT Point-to-Point Protocol May 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 [Page 14] RFC DRAFT Point-to-Point Protocol May 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 D | 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 D - Lower-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. updated by Simpson [Page 15] RFC DRAFT Point-to-Point Protocol May 1991 5.3. Events Transitions and actions in the automaton are caused by events. Some events are caused by commands executed locally (such as Active-Open, Passive-Open, and Close), others are caused by the receipt of packets from the peer (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 attempts to open the connection by sending configuration packets to the 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 waits 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 terminate 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 [Page 16] RFC DRAFT Point-to-Point Protocol May 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 peer may consider the link to be fully-Opened, a Terminate-Request is sent and the Restart timer and counter are set. Where the peer may consider the link to be half-Opened, the Restart counter is cleared, and the current Restart timer is allowed to expire. Down (D) The Down event occurs when a lower layer indicates that it is down. Typically, this event is used by the Physical Layer to signal LCP that the link has disconnected, or used by LCP to signal a NCP that the link is terminating. 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. updated by Simpson [Page 17] RFC DRAFT Point-to-Point Protocol May 1991 Note: Although the Configure-Nak and Configure-Reject cause the 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 peer to disconnect 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 might be quickly followed by a new Configure-Request, and the implementation 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 usually a response to a Terminate-Request packet. The Terminate-Ack packet may also indicate that the peer 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 [Page 18] RFC DRAFT Point-to-Point Protocol May 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 [Page 19] RFC DRAFT Point-to-Point Protocol May 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 [Page 20] RFC DRAFT Point-to-Point Protocol May 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 [Page 21] RFC DRAFT Point-to-Point Protocol May 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 indicates that the peer desires to reconfigure, or is otherwise no longer in the Opened state. 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 updated by Simpson [Page 22] RFC DRAFT Point-to-Point Protocol May 1991 not open. In particular, the implementation SHOULD wait until the 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 that are sent without receiving a Configure-Ack or Configure-Nak before assuming that the peer 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 [Page 23] RFC DRAFT Point-to-Point Protocol May 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 [Page 24] RFC DRAFT Point-to-Point Protocol May 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). 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 will be used to differentiate Version 1 LCP from all other versions. A correctly functioning Version 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. 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. 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 ... +-+-+-+-+ updated by Simpson [Page 25] RFC DRAFT Point-to-Point Protocol May 1991 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. 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 is 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 is 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. updated by Simpson [Page 26] RFC DRAFT Point-to-Point Protocol May 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 [Page 27] RFC DRAFT Point-to-Point Protocol May 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. Additionally, the Configuration Options in a Configure-Ack must exactly match those of the last transmitted Configure-Request. Invalid packets are silently discarded. 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 simultaneously. updated by Simpson [Page 28] RFC DRAFT Point-to-Point Protocol May 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) 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 peer 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. Invalid packets are silently discarded. Reception of a valid Configure-Nak indicates that a new Configure-Request MAY 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 peer, the implementation MUST be able to handle an Option length which is different from the original Configure-Request. updated by Simpson [Page 29] RFC DRAFT Point-to-Point Protocol May 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. 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. Additionally, the Configuration Options in a Configure-Reject must be a proper subset of those in the last transmitted Configure- Request. Invalid packets are silently discarded. updated by Simpson [Page 30] RFC DRAFT Point-to-Point Protocol May 1991 Reception of a valid 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. updated by Simpson [Page 31] RFC DRAFT Point-to-Point Protocol May 1991 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. 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 [Page 32] RFC DRAFT Point-to-Point Protocol May 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 peer 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 peer is in the Closed or Listen state. 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 [Page 33] RFC DRAFT Point-to-Point Protocol May 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. 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 MAY 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 MUST be truncated to comply with the established maximum Information field length. updated by Simpson [Page 34] RFC DRAFT Point-to-Point Protocol May 1991 6.7. Protocol-Reject Description Reception of a PPP frame with an unknown Data Link Layer Protocol indicates that the peer is attempting to use a protocol which is unsupported. This usually occurs when the peer attempts to configure a new protocol. If the LCP state machine is in the Opened state, then this error MUST be reported back to the peer 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 silently discarded. 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. Rejected-Information The Rejected-Information field contains a copy from the frame updated by Simpson [Page 35] RFC DRAFT Point-to-Point Protocol May 1991 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 MUST be truncated to comply with the established maximum Information field length. 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 silently discarded. updated by Simpson [Page 36] RFC DRAFT Point-to-Point Protocol May 1991 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. 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 links which are in the looped-back condition. Unless modified by a Configuration Option, the Magic-Number MUST be transmitted as zero and MUST 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. 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. updated by Simpson [Page 37] RFC DRAFT Point-to-Point Protocol May 1991 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. updated by Simpson [Page 38] RFC DRAFT Point-to-Point Protocol May 1991 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 links which are in the looped-back condition. Unless modified by a configuration option, the Magic-Number MUST be transmitted as zero and MUST 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 four. updated by Simpson [Page 39] RFC DRAFT Point-to-Point Protocol May 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 peer send Link-Quality-Report packets, then it MUST negotiate Link-Quality- Monitoring during the 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 reception on the inbound link. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Rx-Packets-Ctr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | In-Rx-Octets-Ctr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ updated by Simpson [Page 40] RFC DRAFT Point-to-Point Protocol May 1991 Code 12 for Link-Quality-Report (LQR). 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 LQR 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 links which are in the looped-back condition. Unless modified by a Configuration Option, the Magic-Number MUST be transmitted as zero and MUST be ignored on reception. If Magic-Numbers have been negotiated, incoming LQR packets SHOULD be checked to ensure 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 LQR. This field is copied from the state variable of the same name on transmission. Last-In-Id The Last-In-Id field is one octet and indicates the last LQR Identifier received (by the sender). This field is copied from updated by Simpson [Page 41] RFC DRAFT Point-to-Point Protocol May 1991 the state variable of the same name on transmission. On reception, the Last-In-Id field may be compared with the Out- Identifier-Ctr to determine how many, if any, outbound LQRs have been lost. V The V field is 1 bit and indicates whether or not the Measurements section of this LQR is valid. This 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. This field MUST 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 reported transmitted on the inbound link of the LQR transmitter during the last measured period. This field is copied from the state variable of the same name on transmission. In-Tx-Octets The In-Tx-Octets field is four octets and indicates the number of octets reported transmitted on the inbound link of the LQR transmitter during the last measured period. This field is copied from the state variable of the same name on transmission. In-Rx-Packets The In-Rx-Packets field is four octets and indicates the number of packets actually received on the inbound link of the LQR transmitter during the last measured period. This field is copied from the state variable of the same name on transmission. In-Rx-Octets The In-Rx-Octets field is four octets and indicates the number of octets actually received on the inbound link of the LQR transmitter during the last measured period. This field is copied from the state variable of the same name on transmission. updated by Simpson [Page 42] RFC DRAFT Point-to-Point Protocol May 1991 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 LQR transmitter during a period. This field is copied from the counter of the same name 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 LQR transmitter during a period. This field is copied from the counter of the same name 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 LQR receiver during a period. This field is copied from the counter of the same name 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 LQR receiver during a period. This field is copied from the counter of the same name 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 [Page 43] RFC DRAFT Point-to-Point Protocol May 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, each Configuration Option is not listed more than once in a Configuration Options list. Some Configuration Options 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 [Page 44] RFC DRAFT Point-to-Point Protocol May 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-Protocol 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 [Page 45] RFC DRAFT Point-to-Point Protocol May 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 peer that you can receive larger frames, or to request that the peer 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 [Page 46] RFC DRAFT Point-to-Point Protocol May 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 peer which control characters must remain mapped and which control characters need not remain mapped when the peer sends them. The peer may still send these control characters in mapped format if it is necessary because of constraints at the peer. 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 [Page 47] RFC DRAFT Point-to-Point Protocol May 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 [Page 48] RFC DRAFT Point-to-Point Protocol May 1991 7.4. Authentication-Protocol 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 peer to pick from more than one authentication protocol. To achieve this, it MAY include multiple Authentication-Protocol Configuration Options in its Configure- Request packets. An implementation receiving a Configure-Request specifying multiple Authentication-Protocols may accept at most one of the negotiable authentication protocols and MUST 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 peer 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 [Page 49] RFC DRAFT Point-to-Point Protocol May 1991 A summary of the Authentication-Protocol 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 this field 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-Protocol 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 [Page 50] RFC DRAFT Point-to-Point Protocol May 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 is 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 might occur a few updated by Simpson [Page 51] RFC DRAFT Point-to-Point Protocol May 1991 times, 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 [Page 52] RFC DRAFT Point-to-Point Protocol May 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 a LCP Down event. 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 MUST always be Nak'd. Default None. updated by Simpson [Page 53] RFC DRAFT Point-to-Point Protocol May 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 peer should wait between transmission of LCP Link-Quality-Report packets. A value of zero is illegal and MUST always be Nak'd or Rejected. An LCP implementation MAY transmit LCP Link-Quality-Report packets at a faster rate than that which was negotiated. Default None updated by Simpson [Page 54] RFC DRAFT Point-to-Point Protocol May 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 is sent to inform the peer that you can receive such single octet Protocol fields. Compressed Protocol fields MUST NOT be transmitted unless this Configuration Option has been negotiated. 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. The Protocol field must never be compressed when sending any LCP packet. This rule guarantees unambiguous recognition of LCP packets. updated by Simpson [Page 55] RFC DRAFT Point-to-Point Protocol May 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 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 7 Length 2 Default Disabled. updated by Simpson [Page 56] RFC DRAFT Point-to-Point Protocol May 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 is sent to inform the peer that you can receive compressed Address and Control fields. Compressed Address and Control fields are formed by simply omitting them. By definition the first octet of a two octet Protocol field will never be 0xff, and the Protocol field value 0x00ff is not allowed (reserved) to avoid ambiguity. 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 implementation MAY silently discard the frame. The Address and Control fields MUST NOT 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ updated by Simpson [Page 57] RFC DRAFT Point-to-Point Protocol May 1991 Type 8 Length 2 Default Not compressed. updated by Simpson [Page 58] RFC DRAFT Point-to-Point Protocol May 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 [Page 59] RFC DRAFT Point-to-Point Protocol May 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 [Page 60] RFC DRAFT Point-to-Point Protocol May 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 [Page 61] RFC DRAFT Point-to-Point Protocol May 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 [Page 62] RFC DRAFT Point-to-Point Protocol May 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 [Page 63] RFC DRAFT Point-to-Point Protocol May 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 [Page 64] RFC DRAFT Point-to-Point Protocol May 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 [Page 65] RFC DRAFT Point-to-Point Protocol May 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 [Page 66] RFC DRAFT Point-to-Point Protocol May 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 [Page 67] RFC DRAFT Point-to-Point Protocol May 1991 A. Asynchronous HDLC This appendix summarizes the modifications to ISO 3309-1979 proposed in ISO 3309:1984/PDAD1, as applied in the Point-to-Point Protocol. 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 updated by Simpson [Page 68] RFC DRAFT Point-to-Point Protocol May 1991 through 0xff (except 0x5e) in Control Escape format. Since these 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 affect 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, 0xb1. 0x93 is encoded as 0x7d, 0xb3. 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 updated by Simpson [Page 69] RFC DRAFT Point-to-Point Protocol May 1991 frame. If the transmitter does not transmit a new opening Flag 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 [Page 70] RFC DRAFT Point-to-Point Protocol May 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 B.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 B.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 [Page 71] RFC DRAFT Point-to-Point Protocol May 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 [Page 72] RFC DRAFT Point-to-Point Protocol May 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 [Page 73] RFC DRAFT Point-to-Point Protocol May 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 [Page 74] RFC DRAFT Point-to-Point Protocol May 1991 Security Considerations Security issues are discussed in sections 4 and 7.4. Acknowledgments Much of the text in this document is taken from previous documents produced by the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF), 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: William Allen Simpson Computer Systems Consulting Services P O Box 6205 East Lansing, MI 48826-6025 EMail: Bill_Simpson@um.cc.umich.edu updated by Simpson [Page 75] RFC DRAFT Point-to-Point Protocol May 1991 updated by Simpson [Page 76] RFC DRAFT Point-to-Point Protocol May 1991 Table of Contents 1. Introduction .......................................... 1 1.1 Motivation ...................................... 1 1.2 Overview of PPP ................................. 1 1.3 Requirements .................................... 2 1.4 Terminology ..................................... 3 2. Physical Layer Requirements ........................... 4 3. The Data Link Layer ................................... 5 3.1 Frame Format .................................... 6 4. PPP Link Control ...................................... 10 5. The Option Negotiation Automaton ...................... 13 5.1 State Diagram ................................... 13 5.2 State Transition Table .......................... 15 5.3 Events .......................................... 16 5.4 Actions ......................................... 19 5.5 States .......................................... 20 5.6 Loop Avoidance .................................. 23 5.7 Timers and Counters ............................. 23 6. LCP Packet Formats .................................... 25 6.1 Configure-Request ............................... 27 6.2 Configure-Ack ................................... 28 6.3 Configure-Nak ................................... 29 6.4 Configure-Reject ................................ 30 6.5 Terminate-Request and Terminate-Ack ............. 33 6.6 Code-Reject ..................................... 34 6.7 Protocol-Reject ................................. 35 6.8 Echo-Request and Echo-Reply ..................... 36 6.9 Discard-Request ................................. 37 6.10 Link-Quality-Report ............................. 40 7. LCP Configuration Options ............................. 44 7.1 Format .......................................... 45 7.2 Maximum-Receive-Unit ............................ 46 7.3 Async-Control-Character-Map ..................... 47 7.4 Authentication-Protocol ......................... 49 7.5 Magic-Number .................................... 51 7.6 Link-Quality-Monitoring ......................... 54 7.7 Protocol-Field-Compression ...................... 55 7.8 Address-and-Control-Field-Compression ........... 57 7.9 32 Bit FCS ...................................... 59 updated by Simpson [Page ii] RFC DRAFT Point-to-Point Protocol May 1991 8. Link Quality Monitoring ............................... 60 8.1 Design Motivation ............................... 60 8.2 Design Overview ................................. 60 8.3 Processes ....................................... 61 8.4 Counters ........................................ 63 8.5 Measurements, Calculations, State Variables ..... 64 8.6 Policy Suggestions .............................. 66 8.7 Example ......................................... 66 APPENDICES ................................................... 68 A. Asynchronous HDLC ..................................... 68 B. Fast Frame Check Sequence (FCS) Implementation ........ 71 B.1 FCS Computation Method .......................... 71 B.2 Fast FCS table generator ........................ 73 REFERENCES ................................................... 74 SECURITY CONSIDERATIONS ...................................... 75 ACKNOWLEDGEMENTS ............................................. 75 CHAIR'S ADDRESS .............................................. 75 AUTHOR'S ADDRESS ............................................. 75 From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 21 11:21:11 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23056; Tue, 21 May 91 10:45:49 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22848; Tue, 21 May 91 10:33:24 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA16174; Tue, 21 May 91 13:32:38 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9105211732.AA16174@vela.acs.oakland.edu> Subject: disconnect after termination To: ietf-ppp@ucdavis.edu Date: Tue, 21 May 91 13:32:37 EDT X-Mailer: ELM [version 2.3 PL6] In testing my new code which follows the revised RFC against Merit's dialup version this past weekend, I discovered that both ends waited for the other to disconnect after Close. Here are my thoughts on resolution. The sender of a Terminate-Request should disconnect after receiving a Terminate-Ack, or after the Restart counter expires. The receiver of a Terminate-Request should wait for the other end to disconnect, but MAY disconnect after sufficient time has passed for the other end to process the Terminate-Ack. If such a timer is used, it MUST be configurable, and SHOULD default to 30 seconds (the same as 10 * 3 used by the other end for sending T-R). If there are no objections, I will add this to the RFC. Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 21 16:13:46 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29081; Tue, 21 May 91 15:47:04 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28988; Tue, 21 May 91 15:41:04 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-DBC-910410) id AA25882; Tue, 21 May 91 15:35:37 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA15626 to ietf-ppp@ucdavis.edu; Tue, 21 May 91 15:33:44 PDT Date: Tue, 21 May 91 15:33:44 PDT From: brian@napa.Telebit.COM (Brian Lloyd) Message-Id: <9105212233.AA15626@napa.TELEBIT.COM> To: bsimpson@vela.acs.oakland.edu Cc: ietf-ppp@ucdavis.edu In-Reply-To: Bill Simpson's message of Tue, 21 May 91 13:32:37 EDT <9105211732.AA16174@vela.acs.oakland.edu> Subject: disconnect after termination If there are no objections, I will add this to the RFC. Recognition that the physical link is down (like carrier detect drops) is grounds for an immediate transition to the closed or listening state. This makes forcibly closing the link a clear indication that you are no longer connected to the other side :-). This is important when dealing with modems because V.32 modems have a tendency to drop the line and ask questions later. FYI, the NetBlazer treats a dropped line as I have suggested above. 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 Wed May 22 20:05:45 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25153; Wed, 22 May 91 19:46:56 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25051; Wed, 22 May 91 19:38:16 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA26806; Wed, 22 May 91 22:37:26 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9105230237.AA26806@vela.acs.oakland.edu> Subject: Why is LQR in LCP? To: ietf-ppp@ucdavis.edu Date: Wed, 22 May 91 22:37:24 EDT X-Mailer: ELM [version 2.3 PL6] I was asked a question that I can't answer: Why is the Link Quality Report part of LCP? It was pointed out to me that the report is mostly binary numbers, that as an LCP packet must be escaped when async (the most likely use). If it were a negotiated control protocol, other protocols could be used later. Such a syntax would be more like the Authentication Protocol option. In order to better understand the mechanism, I started (but did not finish) an implementation. It would be a *lot* easier to do as a separate protocol. Does anyone know of any completed implementations? Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Thu May 23 00:15:17 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28422; Thu, 23 May 91 00:00:06 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28367; Wed, 22 May 91 23:56:13 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-DBC-910410) id AA06865; Wed, 22 May 91 22:14:51 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA22871 to ietf-ppp@ucdavis.edu; Wed, 22 May 91 22:12:51 PDT Date: Wed, 22 May 91 22:12:51 PDT From: brian@napa.Telebit.COM (Brian Lloyd) Message-Id: <9105230512.AA22871@napa.TELEBIT.COM> To: bsimpson@vela.acs.oakland.edu Cc: ietf-ppp@ucdavis.edu In-Reply-To: Bill Simpson's message of Wed, 22 May 91 22:37:24 EDT <9105230237.AA26806@vela.acs.oakland.edu> Subject: Why is LQR in LCP? It is probably superfluous IF you have decent network management and can extract the information that way. On the other hand it is monitoring the quality of the link so perhaps placing it in the LCP is understandable. You should do it somewhere because some of the newer routing protocols provide a metric for reliability and LQM is useful for deducing the metric on a PPP link. 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 Thu May 23 19:03:39 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18078; Thu, 23 May 91 18:33:43 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from NETSERVER.ANDREW.CMU.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17958; Thu, 23 May 91 18:29:53 -0700 Received: by netserver.andrew.cmu.edu (5.57/Ultrix3.0-C) id AA06643; Thu, 23 May 91 21:28:55 EDT Received: from shady.interstream.com by interstream.com (4.1/SMI-4.1) id AA08152; Thu, 23 May 91 12:15:37 EDT Received: by shady.interstream.com (4.1/SMI-4.1) id AA02922; Thu, 23 May 91 12:20:47 EDT Date: Thu, 23 May 91 12:20:47 EDT From: shady!ddp@INTERSTREAM.COM (Drew D. Perkins) Message-Id: <9105231620.AA02922@shady.interstream.com> To: ietf-ppp@ucdavis.edu Subject: Re: Why is LQR in LCP? As I remember it, it was felt that Link Quality was a "link" function. One could easily argue that this is inconsistent if you consider the authentication option. I don't really see how you could make anything other than religious arguments against it though. I did an incomplete LQR implementation and honestly don't remember having any troubles with the fact that it was at the LCP layer. Why do you feel it would be easier to implement as a different protocol? Please note that the purpose of LQM is to "manage" the link and avoid using it during periods of "high" loss (where high is defined by an administrator). The primary goal is not to measure the loss so that it can be reported. This is a subgoal necessary to achieve the primary goal. Drew D. Perkins 1501 Reedsdale St., Pittsburgh, PA 15233-2329 INTERSTREAM, Inc. voice: (412) 323-8000 fax: (412) 323-1930 From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 24 07:15:54 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26684; Fri, 24 May 91 07:00:45 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA26622; Fri, 24 May 91 06:54:04 -0700 Received: from caicos.engineering ([143.137.50.9]) by cayman.Cayman.COM (4.1/SMI-4.0) id AA01231; Fri, 24 May 91 09:11:27 EDT Received: from localhost by caicos.engineering (4.1/SMI-4.1) id AA05383; Fri, 24 May 91 09:11:28 EDT Message-Id: <9105241311.AA05383@caicos.engineering> To: ietf-ppp@ucdavis.edu Subject: different versions of VJ compression? In-Reply-To: Mail from brian@napa.Telebit.COM (Brian Lloyd) dated Tue, 21 May 91 15:33:44 PDT <9105212233.AA15626@napa.TELEBIT.COM> Date: Fri, 24 May 91 09:11:27 -0400 From: brad@caicos.Cayman.COM I'm testing a home-grown PPP against ka9q/ppp (ppp.05?) from ucdavis, the latest ka9a from thumper, and a unix ppp which has Brad Clements and Drew Perkins's names all over it. It seems that the ucdacis ka9q versions works fine with the Clements/Perkins code until the VJ tcp compression kicks in and then it fails. Since my code does VJ header compression fine with the Clements/Perkins code naturally it fails with the ka9a also. Perhaps I should ask Katie Stevens or Phil Karn, and I plan to figure this out any way, but I thought I'd ask (since I'm lazy) Am I suffering from old versions are is there some confusion in the world of VJ header compress with PPP? -brad From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 24 09:13:08 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28386; Fri, 24 May 91 08:48:26 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28153; Fri, 24 May 91 08:31:52 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA07043; Fri, 24 May 91 11:30:50 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9105241530.AA07043@vela.acs.oakland.edu> Subject: Re: different versions of VJ compression? To: brad@caicos.cayman.com Date: Fri, 24 May 91 11:30:49 EDT Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9105241311.AA05383@caicos.engineering>; from "brad@caicos.Cayman.COM" at May 24, 91 9:11 am X-Mailer: ELM [version 2.3 PL6] Yes, the implementation of the VJ compression negotiation differs from version to version. Furthermore, there was a typo in RFC 1172 as to the protocol number. In December, Glenn McGregor of Merit -- after consultation with Van Jacobson himself while at SigComm -- drafted a definitive description, which this group agreed upon. I expect to see an RFC Real Soon Now.... Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 24 11:16:56 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00826; Fri, 24 May 91 11:00:45 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00615; Fri, 24 May 91 10:46:46 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA12378; Fri, 24 May 91 13:45:46 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9105241745.AA12378@vela.acs.oakland.edu> Subject: Re: Why is LQR in LCP? To: shady!ddp@interstream.com (Drew D. Perkins) Date: Fri, 24 May 91 13:45:45 EDT Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9105231620.AA02922@shady.interstream.com>; from "Drew D. Perkins" at May 23, 91 12:20 pm X-Mailer: ELM [version 2.3 PL6] In my case, it would have been easier as a separate protocol because the test for the protocol number is done sooner than the test for the LCP code. I'm going to have to get some kluge where every LCP packet carries the packet and octet count for later interpretation just in case it's a LQR. However, there are reportedly at least two implementations out there, so I am not inclined to change anything that will break them. Thanks for the history (Fred, too). Bill_Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 24 20:46:35 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10593; Fri, 24 May 91 20:30:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from merit.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10489; Fri, 24 May 91 20:24:07 -0700 Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA23528; Fri, 24 May 91 23:23:10 -0400 Received: by home.merit.edu (4.1/dumb-0.9) id AA08932; Fri, 24 May 91 23:23:09 EDT From: ghm@merit.edu Message-Id: <9105250323.AA08932@home.merit.edu> To: ietf-ppp@ucdavis.edu Cc: ghm@merit.edu Subject: Draft IPCP document with TCP/IP header compression negotiation Date: Fri, 24 May 91 23:23:09 -0400 Here's a version of the Van Jacobson TCP/IP header compression negotiation document, with the original NCP documentation for IPCP edited in. This restructuring of the original PPP options RFC is intended to mesh with Bill Simpson's revision of the PPP rfc. Glenn McGregor Merit Network, Inc. ghm@merit.edu ---- cut here ---- Network Working Group G McGregor Request for Comments: DRAFT Merit Obsoletes: RFC 1172 May 1991 The PPP Internet Protocol Control Protocol (IPCP) 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) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring the Internet Protocol [2] over PPP, and a method to negotiate and use Van Jacobson TCP/IP header compression [3] with PPP. McGregor [Page i] RFC DRAFT PPP IPCP May 1991 1. Introduction 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 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). McGregor [Page 1] RFC DRAFT PPP IPCP May 1991 2. A PPP Network Control Protocol (NCP) for IP The IP Control Protocol (IPCP) is responsible for configuring, enabling, and disabling the IP protocol modules on both ends of the point-to-point link. IPCP uses the same packet exchange machanism as the Link Control Protocol (LCP). IPCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. IPCP packets received before this phase is reached should be silently discarded. Likewise, IP datagrams may not be exchanged until IPCP has finished opening the connection (reached the Opened state). The IP Control Protocol is exactly the same as the Link Control Protocol with the following exceptions: Data Link Layer Protocol Field Exactly one IPCP packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8021 (IP 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 IPCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. An implementation should be prepared to wait for Authentication and Link Quality Determination 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. Configuration Option Types IPCP has a distinct set of Configuration Options, which are defined below. 2.1. Sending IP Datagrams Before any IP packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the IP Control Protocol must reach the Opened state. Exactly one IP packet is encapsulated in the Information field of PPP McGregor [Page 2] RFC DRAFT PPP IPCP May 1991 Data Link Layer frames where the Protocol field indicates type hex 0021 (Internet Protocol). The maximum length of an IP packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. Larger IP datagrams must be fragmented as necessary. If a system wishes to avoid fragmentation and reassembly, it should use the TCP Maximum Segment Size option [4], and MTU discovery [5]. McGregor [Page 3] RFC DRAFT PPP IPCP May 1991 3. IPCP Configuration Options IPCP Configuration Options allow negotiatiation of desirable Internet Protocol parameters. IPCP uses the same Configuration Option format defined for LCP [1], with a separate set of Options. The most up-to-date values of the IPCP Option Type field are specified in the most recent "Assigned Numbers" RFC [6]. Current values are as- signed as follows: 1 IP-Addresses 2 IP-Compression-Protocol McGregor [Page 4] RFC DRAFT PPP IPCP May 1991 3.1. IP-Addresses Description This Configuration Option provides a way to negotiate the IP addresses to be used on each end of the link. By default, no IP addresses are assigned to either end. An address specified as zero shall be interpreted as requesting the peer to specify the address. If an implementation allows the assignment of multiple IP addresses, then it may include multiple IP Address Configuration Options in its Configure-Request packets. An implementation receiving a Configure-Request specifying multiple IP Address Configuration Options may send a Configure-Reject specifying one or more of the specified IP Addresses. An implementation which desires that no IP addresses be assigned (such as a "half-gateway") may reject all IP Address Configuration Options. A summary of the IP-Addresses 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 | Source-IP-Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source-IP-Address (cont) | Destination-IP-Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination-IP-Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length 10 Source-IP-Address The four octet Source-IP-Address is the desired local address of the sender of a Configure-Request. In a Configure-Ack, Configure-Nak or Configure-Reject, the Source-IP-Address is the remote address of the sender, and is thus a local address with respect to the Configuration Option receiver. McGregor [Page 5] RFC DRAFT PPP IPCP May 1991 Destination-IP-Address The four octet Destination-IP-Address is the remote address with respect to the sender of a Configure-Request. In a Configure-Ack, Configure-Nak or Configure-Reject, the Destination-IP-Address is the local address of the sender, and is thus a remote address with respect to the Configuration Option receiver. Default No IP addresses assigned. McGregor [Page 6] RFC DRAFT PPP IPCP May 1991 3.2. IP-Compression-Protocol Description This Configuration Option provides a way to negotiate the use of a specific compression protocol. By default, compression is not enabled. A summary of the IP-Compression-Protocol 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 | IP-Compression-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Type 2 Length >= 4 IP-Compression-Protocol The IP-Compression-Protocol field is two octets and indicates the compression protocol desired. Values for this field are always the same as the PPP Data Link Layer Protocol field values for that same compression protocol. The most up-to-date values of the IP-Compression-Protocol field are specified in the most recent "Assigned Numbers" RFC [6]. Current values are assigned as follows: Value (in hex) Protocol 002d Van Jacobson Compressed TCP/IP Data The Data field is zero or more octets and contains additional data as determined by the particular compression protocol. McGregor [Page 7] RFC DRAFT PPP IPCP May 1991 Default No compression protocol enabled. McGregor [Page 8] RFC DRAFT PPP IPCP May 1991 4. Van Jacobson TCP/IP header compression Van Jacobson TCP/IP header compression reduces the size of the TCP/IP headers to as few as three bytes. This can be a significant improvement on slow serial lines, particularly for interactive traffic. The IP-Compression-Protocol Configuration Option is used to indicate the ability to receive compressed packets. Each end of the link must request this option if bi-directional compression is desired. The PPP Protocol field is set to the following values when transmitting IP packets: Value (in hex) 0021 Type IP. The IP protocol is not TCP, or the packet is a fragment, or cannot be compressed. 002d Compressed TCP. The TCP/IP headers are replaced by the compressed header. 002f Uncompressed TCP. The IP protocol field is replaced by the slot identifier. 4.1. Format A summary of the IP-Compression-Protocol Option format to negotiate Van Jacobson TCP/IP header compression 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 | IP-Compression-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max-Slot-Id | Comp-Slot-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Length 6 McGregor [Page 9] RFC DRAFT PPP IPCP May 1991 IP-Compression-Protocol 002d (hex) for Van Jacobson Compressed TCP/IP headers. Max-Slot-Id The Max-Slot-Id field is one octet and indicates the maximum slot identifier. This is one less than the actual number of slots; the slot identifier has values from zero to Max-Slot-Id. Note: There may be implementations that have problems with only one slot (Max-Slot-Id = 0). See the discussion in reference [3]. The sample implementation in [3] only supports Max-Slot-Id values 3 to 254. Comp-Slot-Id The Comp-Slot-Id field is one octet and indicates whether the slot identifier field may be compressed. 0 The slot identifier must not be compressed. All compressed TCP packets must set the C bit in every change mask, and must include the slot identifier. 1 The slot identifer may be compressed. The slot identifier must not be compressed if there is no ability for the PPP link level to indicate an error in reception to the decompression module. Synchronization after errors depends on receiving a packet with the slot identifier. See the discussion in reference [3]. McGregor [Page 10] RFC DRAFT PPP IPCP May 1991 References [1] Perkins, D., "The Point-to-Point Protocol for the Transmission of Multi-Protocol of Datagrams Over Point-to-Point Links", RFC 1171, July 1990. [2] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981. [3] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, January 1990. [4] Postel, J., "The TCP Maximum Segment Size Option and Related Topics", RFC 879, USC/Information Sciences Institute, November 1983. [5] Mogul, J.C., Deering, S.E., "Path MTU Discovery", RFC 1191, November 1990. [6] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990. Security Considerations Security issues are not discussed in this memo. Acknowledgments Much of the text in this document is taken from previous documents produced by the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF), formerly chaired by Drew Perkins of Carnegie Mellon University, and by Russ Hobby of the University of California at Davis. 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 McGregor [Page 11] RFC DRAFT PPP IPCP May 1991 EMail: Stev@FTP.com Author's Address Questions about this memo can also be directed to: Glenn McGregor Merit Network, Inc. 1075 Beal Avenue Ann Arbor, MI 48109-2099 Phone: (313) 763-1203 EMail: ghm@merit.edu McGregor [Page 12] RFC DRAFT PPP IPCP May 1991 Table of Contents 1. Introduction .......................................... 1 2. A PPP Network Control Protocol (NCP) for IP ........... 2 2.1 Sending IP Datagrams ............................ 2 3. IPCP Configuration Options ............................ 4 3.1 IP-Addresses .................................... 5 3.2 IP-Compression-Protocol ......................... 7 4. Van Jacobson TCP/IP header compression ................ 9 4.1 Format .......................................... 9 REFERENCES ................................................... 11 SECURITY CONSIDERATIONS ...................................... 11 ACKNOWLEDGEMENTS ............................................. 11 CHAIR'S ADDRESS .............................................. 11 AUTHOR'S ADDRESS ............................................. 12 From ietf-ppp-request@ucdavis.ucdavis.edu Sun May 26 14:30:15 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA05788; Sun, 26 May 91 14:16:30 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA05708; Sun, 26 May 91 14:06:36 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA22994; Sun, 26 May 91 17:05:43 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9105262105.AA22994@vela.acs.oakland.edu> Subject: Re: Draft IPCP document with TCP/IP header compression negotiation To: ietf-ppp@ucdavis.edu Date: Sun, 26 May 91 17:05:42 EDT In-Reply-To: <9105250323.AA08932@home.merit.edu>; from "ghm@merit.edu" at May 24, 91 11:23 pm X-Mailer: ELM [version 2.3 PL6] Thanks Glenn. Looks good. Hopefully this answers the question by Brad@caicos.Cayman.Com. Since all parts of this draft have been previously approved by the group (at least I can't spot any substantive changes), I suggest that this be submitted for publication expeditiously -- say June 5th. Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu