From b6a1268714671904e96a49b88680dc3ff07aaa1c Mon Sep 17 00:00:00 2001 From: Kozlov Dmitry Date: Wed, 6 Oct 2010 16:43:14 +0400 Subject: project cleanup and prepare to release --- rfc/rfc1548.txt | 2971 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2971 insertions(+) create mode 100644 rfc/rfc1548.txt (limited to 'rfc/rfc1548.txt') diff --git a/rfc/rfc1548.txt b/rfc/rfc1548.txt new file mode 100644 index 0000000..7b8a33a --- /dev/null +++ b/rfc/rfc1548.txt @@ -0,0 +1,2971 @@ + + + + + + +Network Working Group W. Simpson +Request for Comments: 1548 Daydreamer +Obsoletes: RFC 1331 December 1993 +Category: Standards Track + + + The Point-to-Point Protocol (PPP) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The Point-to-Point Protocol (PPP) provides a standard method for + transporting multi-protocol datagrams over point-to-point links. PPP + is comprised of three main components: + + 1. A method for encapsulating multi-protocol datagrams. + + 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 organization and methodology, and the + PPP encapsulation, together with an extensible option negotiation + mechanism which is able to negotiate a rich assortment of + configuration parameters and provides additional management + functions. The PPP Link Control Protocol (LCP) is described in terms + of this mechanism. + + This document is the product of the Point-to-Point Protocol Working + Group of the Internet Engineering Task Force (IETF). Comments should + be submitted to the ietf-ppp@ucdavis.edu mailing list. + + + + + + + + + + + +Simpson [Page 1] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +Table of Contents + + 1. Introduction ................................................3 + 1.1 Specification of Requirements ...............................4 + 1.2 Terminology .................................................5 + 2. PPP Encapsulation ...........................................5 + 3. PPP Link Operation ..........................................8 + 3.1 Overview ....................................................8 + 3.2 Phase Diagram ...............................................8 + 3.3 Link Dead (physical-layer not ready) ........................9 + 3.4 Link Establishment Phase ....................................9 + 3.5 Authentication Phase ........................................9 + 3.6 Network-Layer Protocol Phase ................................10 + 3.7 Link Termination Phase ......................................10 + 4. The Option Negotiation Automaton ............................11 + 4.1 State Diagram ...............................................12 + 4.2 State Transition Table ......................................14 + 4.3 A Day in the Life ...........................................15 + 4.4 States ......................................................16 + 4.5 Events ......................................................19 + 4.6 Actions .....................................................23 + 4.7 Loop Avoidance ..............................................26 + 4.8 Counters and Timers .........................................26 + 5. LCP Packet Formats ..........................................27 + 5.1 Configure-Request ...........................................29 + 5.2 Configure-Ack ...............................................30 + 5.3 Configure-Nak ...............................................31 + 5.4 Configure-Reject ............................................33 + 5.5 Terminate-Request and Terminate-Ack .........................34 + 5.6 Code-Reject .................................................35 + 5.7 Protocol-Reject .............................................36 + 5.8 Echo-Request and Echo-Reply .................................37 + 5.9 Discard-Request .............................................39 + 6. LCP Configuration Options ...................................40 + 6.1 Maximum-Receive-Unit ........................................41 + 6.2 Async-Control-Character-Map .................................42 + 6.3 Authentication-Protocol .....................................43 + 6.4 Quality-Protocol ............................................45 + 6.5 Magic-Number ................................................46 + 6.6 Protocol-Field-Compression ..................................49 + 6.7 Address-and-Control-Field-Compression .......................50 + APPENDIX A. LCP Recommended Options ..............................51 + SECURITY CONSIDERATIONS ..........................................51 + REFERENCES .......................................................52 + ACKNOWLEDGEMENTS .................................................52 + CHAIR'S ADDRESS ..................................................52 + EDITOR'S ADDRESS .................................................53 + + + + +Simpson [Page 2] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +1. Introduction + + Encapsulation + + The PPP encapsulation provides for multiplexing of different + network-layer protocols simultaneously over the same link. It is + intended that PPP provide a common solution for easy connection of + a wide variety of hosts, bridges and routers [1]. + + The PPP encapsulation has been carefully designed to retain + compatibility with most commonly used supporting hardware. + + Only 8 additional octets are necessary to form the encapsulation + when used with the default HDLC framing. In environments where + bandwidth is at a premium, the encapsulation and framing may be + shortened to 2 or 4 octets. + + To support high speed implementations, the default encapsulation + uses only simple fields, only one of which needs to be examined + for demultiplexing. The default header and information fields + fall on 32-bit boundaries, and the trailer may be padded to an + arbitrary boundary. + + Link Control Protocol + + In order to be sufficiently versatile to be portable to a wide + variety of environments, PPP provides a Link Control Protocol + (LCP). The LCP is used to automatically agree upon the + encapsulation format options, handle varying limits on sizes of + packets, authenticate the identity of its peer on the link, + determine when a link is functioning properly and when it is + defunct, detect a looped-back link and other common + misconfiguration errors, and terminate the link. + + Network Control Protocols + + Point-to-Point links tend to exacerbate many problems with the + current family of network protocols. For instance, assignment and + management of IP addresses, which is a problem even in LAN + environments, is especially difficult over circuit-switched + point-to-point links (such as dial-up modem servers). These + problems are handled by a family of Network Control Protocols + (NCPs), which each manage the specific needs required by their + respective network-layer protocols. These NCPs are defined in + companion documents. + + + + + + +Simpson [Page 3] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Configuration + + It is intended that PPP links be easy to configure. By design, + the standard defaults handle all common configurations. The + implementor can specify improvements to the default configuration, + which are automatically communicated to the peer without operator + intervention. Finally, the operator may explicitly configure + options for the link which enable the link to operate in + environments where it would otherwise be impossible. + + This self-configuration is implemented through an extensible + option negotiation mechanism, wherein each end of the link + describes to the other its capabilities and requirements. + Although the option negotiation mechanism described in this + document is specified in terms of the Link Control Protocol (LCP), + the same facilities are designed to be used by other control + protocols, especially the family of NCPs. + +1.1 Specification of Requirements + + In this document, several words are used to signify the + requirements of the specification. These words are often + capitalized. + + MUST + + This word, or the adjective "required", means that the definition + is an absolute requirement of the specification. + + MUST NOT + + This phrase means that the definition is an absolute prohibition + of the specification. + + SHOULD + + This word, or the adjective "recommended", means that there may + exist valid reasons in particular circumstances to ignore this + item, but the full implications must be understood and carefully + weighed before choosing a different course. + + MAY + + This word, or the adjective "optional", means that this item is + one of an allowed set of alternatives. An implementation which + does not include this option MUST be prepared to interoperate with + another implementation which does include the option. + + + + +Simpson [Page 4] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +1.2 Terminology + + This document frequently uses the following terms: + + datagram + + The unit of transmission in the network layer (such as IP). A + datagram may be encapsulated in one or more packets passed to the + data link layer. + + frame + + The unit of transmission at the data link layer. A frame may + include a header and/or a trailer, along with some number of units + of data. + + packet + + The basic unit of encapsulation, which is passed across the + interface between the network layer and the data link layer. A + packet is usually mapped to a frame; the exceptions are when data + link layer fragmentation is being performed, or when multiple + packets are incorporated into a single frame. + + peer + + The other end of the point-to-point link. + + silently discard + + This means the implementation discards the packet without further + processing. The implementation SHOULD provide the capability of + logging the error, including the contents of the silently + discarded packet, and SHOULD record the event in a statistics + counter. + +2. PPP Encapsulation + + The PPP encapsulation is used to disambiguate multiprotocol + datagrams. This encapsulation requires framing to indicate the + beginning and end of the encapsulation. Methods of providing framing + are specified in companion documents. + + + + + + + + + +Simpson [Page 5] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + A summary of the PPP encapsulation is shown below. The fields are + transmitted from left to right. + + +----------+-------------+---------+ + | Protocol | Information | Padding | + | 16 bits | * | * | + +----------+-------------+---------+ + + Protocol Field + + The Protocol field is two octets and its value identifies the + datagram encapsulated in the Information field of the packet. The + field is transmitted and received most significant octet first. + + The structure of this 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 + treated as having an unrecognized Protocol. + + Protocol field values in the "0***" to "3***" range identify the + network-layer protocol of specific packets, and values in the + "8***" to "b***" range identify packets belonging to the + associated Network Control Protocols (NCPs), if any. + + Protocol field values in the "4***" to "7***" range are used for + protocols with low volume traffic which have no associated NCP. + Protocol field values in the "c***" to "f***" range identify + packets as link-layer Control Protocols (such as LCP). + + Up-to-date values of the Protocol field are specified in the most + recent "Assigned Numbers" RFC [2]. Current values are assigned as + follows: + + Value (in hex) Protocol Name + + 0001 Padding Protocol + 0003 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 + + + +Simpson [Page 6] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 0031 Bridging PDU + 0033 Stream Protocol (ST-II) + 0035 Banyan Vines + 0037 unused + 0039 AppleTalk EDDP + 003b AppleTalk SmartBuffered + 003d Multi-Link + 005d reserved (compression inefficient) + 00cf reserved (PPP NLPID) + 00fd 1st choice compression + 00ff reserved (compression inefficient) + + 0201 802.1d Hello Packets + 0203 IBM Source Routing BPDU + 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 + 8035 Banyan Vines Control Protocol + 8037 unused + 8039 Reserved + 803b Reserved + 803d Multi-Link Control Protocol + 80fd Compression Control Protocol + 80ff Reserved + + c021 Link Control Protocol + c023 Password Authentication Protocol + c025 Link Quality Report + c223 Challenge Handshake 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. + + + +Simpson [Page 7] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + The maximum length for the Information field, including Padding, + is termed the Maximum Receive Unit (MRU), which defaults to 1500 + octets. By negotiation, consenting PPP implementations may use + other values for the MRU. + + Padding + + On transmission, the Information field MAY be padded with an + arbitrary number of octets up to the MRU. It is the + responsibility of each protocol to distinguish padding octets from + real information. + +3. PPP Link Operation + +3.1 Overview + + 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, the peer MAY be + authenticated. Then, 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). + +3.2 Phase Diagram + + In the process of configuring, maintaining and terminating the + point-to-point link, the PPP link goes through several distinct + phases: + + +------+ +-----------+ +--------------+ + | | UP | | OPENED | | SUCCESS/NONE + | Dead |------->| Establish |---------->| Authenticate |--+ + | | | | | | | + +------+ +-----------+ +--------------+ | + ^ FAIL | FAIL | | + +<--------------+ +----------+ | + | | | + | +-----------+ | +---------+ | + | DOWN | | | CLOSING | | | + +------------| Terminate |<---+<----------| Network |<-+ + | | | | + +-----------+ +---------+ + + + +Simpson [Page 8] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +3.3 Link Dead (physical-layer not ready) + + The link necessarily begins and ends with this phase. When an + external event (such as carrier detection or network administrator + configuration) indicates that the physical-layer is ready to be used, + PPP will proceed to the Link Establishment phase. + + During this phase, the LCP automaton (described below) will be in the + Initial or Starting states. The transition to the Link Establishment + phase will signal an Up event to the automaton. + + Implementation Note: + + 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 the device. + +3.4 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. + + 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. + + Any non-LCP packets received during this phase MUST be silently + discarded. + +3.5 Authentication Phase + + On some links it may be desirable to require a peer to authenticate + itself before allowing network-layer protocol packets to be + exchanged. + + By default, authentication is not mandatory. If an implementation + desires that the peer authenticate with some specific authentication + protocol, then it MUST negotiate the use of that authentication + protocol during Link Establishment phase. + + + +Simpson [Page 9] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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 authentication has completed, + using the negotiated authentication protocol. If authentication + fails, PPP SHOULD proceed instead to the Link Termination phase. + + Any Network Control Protocol or network-layer protocol packets + received during this phase MUST be silently discarded. + +3.6 Network-Layer Protocol Phase + + Once PPP has finished the previous phases, each network-layer + protocol (such as IP, IPX, or AppleTalk) MUST be separately + configured by the appropriate Network Control Protocol (NCP). + + Each NCP MAY be Opened and Closed at any time. + + Implementation Note: + + 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 will carry the + corresponding network-layer protocol packets. Any network-layer + protocol packets received when the corresponding NCP is not in the + Opened state MUST be silently discarded. + + Implementation Note: + + There is an exception to the preceding paragraphs, due to the + availability of the LCP Protocol-Reject (described below). While + LCP is in the Opened state, any protocol packet which is + unsupported by the implementation MUST be returned in a Protocol- + Reject. Only protocols which are supported are silently + discarded. + + During this phase, link traffic consists of any possible + combination of LCP, NCP, and network-layer protocol packets. + +3.7 Link Termination Phase + + PPP can terminate the link at any time. This might happen because of + + + +Simpson [Page 10] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + the loss of carrier, authentication failure, link quality failure, + the expiration of an idle-period timer, or the administrative closing + of the link. 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 SHOULD + signal the physical-layer to disconnect in order to enforce the + termination of the link, particularly in the case of an + authentication failure. The sender of the 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 peer to disconnect, and MUST NOT disconnect until at least one + Restart time has passed after sending a Terminate-Ack. PPP SHOULD + proceed to the Link Dead phase. + + Any non-LCP packets received during this phase MUST be silently + discarded. + + Implementation 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 one NCP has Closed is not sufficient reason to cause + the termination of the PPP link, even if that NCP was the only NCP + currently in the Opened state. + +4. The Option Negotiation Automaton + + The finite-state automaton is defined by events, actions and state + transitions. Events include reception of external commands such as + Open and Close, expiration of the Restart timer, and reception of + packets from a peer. Actions include the starting of the Restart + timer and transmission of packets to the peer. + + Some types of packets -- Configure-Naks and Configure-Rejects, or + Code-Rejects and Protocol-Rejects, or Echo-Requests, Echo-Replies and + Discard-Requests -- are not differentiated in the automaton + descriptions. As will be described later, these packets do indeed + serve different functions. However, they always cause the same + transitions. + +Events Actions + +Up = lower layer is Up tlu = This-Layer-Up +Down = lower layer is Down tld = This-Layer-Down +Open = administrative Open tls = This-Layer-Started +Close= administrative Close tlf = This-Layer-Finished + + + +Simpson [Page 11] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +TO+ = Timeout with counter > 0 irc = Initialize-Restart-Counter +TO- = Timeout with counter expired zrc = Zero-Restart-Counter + +RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-Request +RCR- = Receive-Configure-Request (Bad) +RCA = Receive-Configure-Ack sca = Send-Configure-Ack +RCN = Receive-Configure-Nak/Rej scn = Send-Configure-Nak/Rej + +RTR = Receive-Terminate-Request str = Send-Terminate-Request +RTA = Receive-Terminate-Ack sta = Send-Terminate-Ack + +RUC = Receive-Unknown-Code scj = Send-Code-Reject +RXJ+ = Receive-Code-Reject (permitted) + or Receive-Protocol-Reject +RXJ- = Receive-Code-Reject (catastrophic) + or Receive-Protocol-Reject +RXR = Receive-Echo-Request ser = Send-Echo-Reply + or Receive-Echo-Reply + or Receive-Discard-Request + +4.1 State Diagram + + The simplified state diagram which follows describes the sequence of + events for reaching agreement on Configuration Options (opening the + PPP link) and for later termination of the link. + + This diagram is not a complete representation of the automaton. + Implementation MUST be done by consulting the actual state transition + table. + + Events are in upper case. Actions are in lower case. For these + purposes, the state machine is initially in the Closed state. Once + the Opened state has been reached, both ends of the link have met the + requirement of having both sent and received a Configure-Ack packet. + + + + + + + + + + + + + + + + + +Simpson [Page 12] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + RCR TO+ + +--sta-->+ +------->+ + | | | | + +-------+ | RTA +-------+ | Close +-------+ + | |<-----+<------| |<-str-+<------| | + |Closed | |Closing| |Opened | + | | Open | | | | + | |------+ | | | | + +-------+ | +-------+ +-------+ + | ^ + | | + | +-sca----------------->+ + | | ^ + RCN,TO+ V RCR+ | RCR- RCA | RCN,TO+ + +------->+ | +------->+ | +--scr-->+ + | | | | | | | | + +-------+ | TO+ +-------+ | +-------+ | + | |<-scr-+<------| |<-scn-+ | |<-----+ + | Req- | | Ack- | | Ack- | + | Sent | RCA | Rcvd | | Sent | + +-scn->| |------------->| | +-sca->| | + | +-------+ +-------+ | +-------+ + | RCR- | | RCR+ | RCR+ | | RCR- + | | +------------------------------->+<-------+ | + | | | + +<-------+<------------------------------------------------+ + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 13] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +4.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. Multiple + actions are separated by commas, and may continue on succeeding lines + as space requires; multiple actions may be implemented in any + convenient order. The state may be followed by a letter, which + indicates an explanatory footnote. The dash ('-') indicates an + illegal transition. + + + | State + | 0 1 2 3 4 5 + Events| Initial Starting Closed Stopped Closing Stopping + ------+----------------------------------------------------------- + Up | 2 irc,scr/6 - - - - + Down | - - 0 tls/1 0 1 + Open | tls/1 1 irc,scr/6 3r 5r 5r + Close| 0 0 2 2 4 4 + | + TO+ | - - - - str/4 str/5 + TO- | - - - - tlf/2 tlf/3 + | + RCR+ | - - sta/2 irc,scr,sca/8 4 5 + RCR- | - - sta/2 irc,scr,scn/6 4 5 + RCA | - - sta/2 sta/3 4 5 + RCN | - - sta/2 sta/3 4 5 + | + RTR | - - sta/2 sta/3 sta/4 sta/5 + RTA | - - 2 3 tlf/2 tlf/3 + | + RUC | - - scj/2 scj/3 scj/4 scj/5 + RXJ+ | - - 2 3 4 5 + RXJ- | - - tlf/2 tlf/3 tlf/2 tlf/3 + | + RXR | - - 2 3 4 5 + + + + + + + + + + + + + + +Simpson [Page 14] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + | State + | 6 7 8 9 + Events| Req-Sent Ack-Rcvd Ack-Sent Opened + ------+----------------------------------------- + Up | - - - - + Down | 1 1 1 tld/1 + Open | 6 7 8 9r + Close|irc,str/4 irc,str/4 irc,str/4 tld,irc,str/4 + | + TO+ | scr/6 scr/6 scr/8 - + TO- | tlf/3p tlf/3p tlf/3p - + | + RCR+ | sca/8 sca,tlu/9 sca/8 tld,scr,sca/8 + RCR- | scn/6 scn/7 scn/6 tld,scr,scn/6 + RCA | irc/7 scr/6x irc,tlu/9 tld,scr/6x + RCN |irc,scr/6 scr/6x irc,scr/8 tld,scr/6x + | + RTR | sta/6 sta/6 sta/6 tld,zrc,sta/5 + RTA | 6 6 8 tld,scr/6 + | + RUC | scj/6 scj/7 scj/8 scj/9 + RXJ+ | 6 6 8 9 + RXJ- | tlf/3 tlf/3 tlf/3 tld,irc,str/5 + | + RXR | 6 7 8 ser/9 + + The states in which the Restart timer is running are identifiable by + the presence of TO events. Only the Send-Configure-Request, Send- + Terminate-Request and Zero-Restart-Counter actions start or re-start + the Restart timer. The Restart timer is stopped when transitioning + from any state where the timer is running to a state where the timer + is not running. + + [p] Passive option; see Stopped state discussion. + + [r] Restart option; see Open event discussion. + + [x] Crossed connection; see RCA event discussion. + +4.3 A Day in the Life + + Here is an example of how a typical implementation might use the + automaton to implement LCP in a dial-up environment: + + - The Network Access Server is powered on (Initial state, Link Dead + phase). + + - A configuration file indicates that a particular link is to be + + + +Simpson [Page 15] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + used for PPP access (Open: tls/Starting). The This-Layer-Started + event turns on DTR to a modem, readying it for accepting calls. + + - An incoming call is answered. The modem CD triggers configuration + negotiation (Up: irc,scr/Req-Sent, Link Establishment phase). + + - A Configure-Request is received, which is acknowleged (RCR+: + sca/Ack-Sent). + + - The Request is acknowleged (RCA: irc,tlu/Opened). The This- + Layer-Up event starts authentication and quality monitoring + protocols (Authentication phase). + + - When authentication and quality monitoring are satisfied, they + send an Up event to start the available NCPs (Network-Layer + Protocol phase). + + - Later, the peer is finished, and closes the link. A Terminate- + Request arrives (RTR: tld,zrc,sta/Stopping, Termination phase). + The This-Layer-Down action sends the Down event to any NCPs, while + the Terminate-Ack is sent. The Zero-Restart-Counter action causes + the link to wait for the peer to process the Terminate-Ack, with + no retries. + + - When the Restart Timer times out (TO-: tlf/Stopped), the This- + Layer-Finished action signals the modem to hang up by dropping + DTR. + + - When the CD from the modem drops (Down: tls/Starting), the This- + Layer-Started action raises DTR again, readying it for the next + call (returning to the Link Dead phase). + +4.4 States + + Following is a more detailed description of each automaton state. + + Initial + + In the Initial state, the lower layer is unavailable (Down), and + no Open has occurred. The Restart timer is not running in the + Initial state. + + Starting + + The Starting state is the Open counterpart to the Initial state. + An administrative Open has been initiated, but the lower layer is + still unavailable (Down). The Restart timer is not running in the + Starting state. + + + +Simpson [Page 16] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + When the lower layer becomes available (Up), a Configure-Request + is sent. + + Closed + + In the Closed state, the link is available (Up), but no Open has + occurred. The Restart timer is not running in the Closed state. + + Upon reception of Configure-Request packets, a Terminate-Ack is + sent. Terminate-Acks are silently discarded to avoid creating a + loop. + + Stopped + + The Stopped state is the Open counterpart to the Closed state. It + is entered when the automaton is waiting for a Down event after + the This-Layer-Finished action, or after sending a Terminate-Ack. + The Restart timer is not running in the Stopped state. + + Upon reception of Configure-Request packets, an appropriate + response is sent. Upon reception of other packets, a Terminate- + Ack is sent. Terminate-Acks are silently discarded to avoid + creating a loop. + + Rationale: + + The Stopped state is a junction state for link termination, link + configuration failure, and other automaton failure modes. These + potentially separate states have been combined. + + There is a race condition between the Down event response (from + the This-Layer-Finished action) and the Receive-Configure- Request + event. When a Configure-Request arrives before the Down event, + the Down event will supercede by returning the automaton to the + Starting state. This prevents attack by repetition. + + Implementation Option: + + After the peer fails to respond to Configure-Requests, an + implementation MAY wait passively for the peer to send Configure- + Requests. In this case, the This-Layer-Finished action is not + used for the TO- event in states Req-Sent, Ack- Rcvd and Ack-Sent. + + This option is useful for dedicated circuits, or circuits which + have no status signals available, but SHOULD NOT be used for + switched circuits. + + + + + +Simpson [Page 17] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Closing + + In the Closing state, an attempt is made to terminate the + connection. A Terminate-Request has been sent and the Restart + timer is running, but a Terminate-Ack has not yet been received. + + Upon reception of a Terminate-Ack, the Closed state is 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. + + Stopping + + The Stopping state is the Open counterpart to the Closing state. + A Terminate-Request has been sent and the Restart timer is + running, but a Terminate-Ack has not yet been received. + + Rationale: + + The Stopping state provides a well defined opportunity to + terminate a link before allowing new traffic. After the link has + terminated, a new configuration may occur via the Stopped or + Starting states. + + Request-Sent + + In the Request-Sent state an attempt is made to configure 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. + + Ack-Received + + 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 sent. + + Ack-Sent + + In the Ack-Sent state, a Configure-Request and a Configure-Ack + have both been sent but a Configure-Ack has not yet been received. + The Restart timer is always running in the Ack-Sent state. + + Opened + + In the Opened state, a Configure-Ack has been both sent and + received. The Restart timer is not running in the Opened state. + + + +Simpson [Page 18] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + When entering the Opened state, the implementation SHOULD signal + the upper layers that it is now Up. Conversely, when leaving the + Opened state, the implementation SHOULD signal the upper layers + that it is now Down. + +4.5 Events + + Transitions and actions in the automaton are caused by events. + + Up + + The Up event occurs when a lower layer indicates that it is ready + to carry packets. + + Typically, this event is used by a modem handling or calling + process, or by some other coupling of the PPP link to the physical + media, to signal LCP that the link is entering Link Establishment + phase. + + It also can be used by LCP to signal each NCP that the link is + entering Network-Layer Protocol phase. That is, the This-Layer-Up + action from LCP triggers the Up event in the NCP. + + Down + + The Down event occurs when a lower layer indicates that it is no + longer ready to carry packets. + + Typically, this event is used by a modem handling or calling + process, or by some other coupling of the PPP link to the physical + media, to signal LCP that the link is entering Link Dead phase. + + It also can be used by LCP to signal each NCP that the link is + leaving Network-Layer Protocol phase. That is, the This-Layer- + Down action from LCP triggers the Down event in the NCP. + + Open + + The Open event indicates that the link is administratively + available for traffic; that is, the network administrator (human + or program) has indicated that the link is allowed to be Opened. + When this event occurs, and the link is not in the Opened state, + the automaton attempts to send configuration packets to the peer. + + If the automaton is not able to begin configuration (the lower + layer is Down, or a previous Close event has not completed), the + establishment of the link is automatically delayed. + + + + +Simpson [Page 19] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + When a Terminate-Request is received, or other events occur which + cause the link to become unavailable, the automaton will progress + to a state where the link is ready to re-open. No additional + administrative intervention is necessary. + + Implementation Option: + + Experience has shown that users will execute an additional Open + command when they want to renegotiate the link. This might + indicate that new values are to be negotiated. + + Since this is not the meaning of the Open event, it is suggested + that when an Open user command is executed in the Opened, Closing, + Stopping, or Stopped states, the implementation issue a Down + event, immediately followed by an Up event. This will cause the + renegotiation of the link, without any harmful side effects. + + Close + + The Close event indicates that the link is not available for + traffic; that is, the network administrator (human or program) has + indicated that the link is not allowed to be Opened. When this + event occurs, and the link is not in the Closed state, the + automaton attempts to terminate the connection. Futher attempts + to re-configure the link are denied until a new Open event occurs. + + Implementation Note: + + When authentication fails, the link SHOULD be terminated, to + prevent attack by repetition and denial of service to other users. + Since the link is administratively available (by definition), this + can be accomplished by simulating a Close event to the LCP, + immediately followed by an Open event. + + The Close followed by an Open will cause an orderly termination of + the link, by progressing from the Closing to the Stopping state, + and the This-Layer-Finished action can disconnect the link. The + automaton waits in the Stopped or Starting states for the next + connection attempt. + + Timeout (TO+,TO-) + + This event indicates the expiration of the Restart timer. The + Restart timer is used to time responses to Configure-Request and + Terminate-Request packets. + + The TO+ event indicates that the Restart counter continues to be + greater than zero, which triggers the corresponding Configure- + + + +Simpson [Page 20] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Request or Terminate-Request packet to be retransmitted. + + The TO- event indicates that the Restart counter is not greater + than zero, and no more packets need to be retransmitted. + + Receive-Configure-Request (RCR+,RCR-) + + This 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. + + The RCR+ event indicates that the Configure-Request was + acceptable, and triggers the transmission of a corresponding + Configure-Ack. + + The RCR- event indicates that the Configure-Request was + unacceptable, and triggers the transmission of a corresponding + Configure-Nak or Configure-Reject. + + Implementation Note: + + These events 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. An out of + sequence or otherwise invalid packet is silently discarded. + + Implementation Note: + + Since the correct packet has already been received before reaching + the Ack-Rcvd or Opened states, it is extremely unlikely that + another such packet will arrive. As specified, all invalid + Ack/Nak/Rej packets are silently discarded, and do not affect the + transitions of the automaton. + + However, it is not impossible that a correctly formed packet will + arrive through a coincidentally-timed cross-connection. It is + more likely to be the result of an implementation error. At the + very least, this occurance SHOULD be logged. + + + + + +Simpson [Page 21] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Receive-Configure-Nak/Rej (RCN) + + This 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. An out of sequence or otherwise invalid packet is + silently discarded. + + Implementation 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 close the connection. + + Implementation Note: + + This event is not identical to the Close event (see above), and + does not override the Open commands of the local network + administrator. The implementation MUST be prepared to receive a + new Configure-Request 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 in Closed or Stopped states, + 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, Receive-Protocol-Reject (RXJ+,RXJ-) + + This event occurs when a Code-Reject or a Protocol-Reject packet + is received from the peer. + + The RXJ+ event arises when the rejected value is acceptable, such + + + +Simpson [Page 22] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + as a Code-Reject of an extended code, or a Protocol-Reject of a + NCP. These are within the scope of normal operation. The + implementation MUST stop sending the offending packet type. + + The RXJ- event arises when the rejected value is catastrophic, + such as a Code-Reject of Configure-Request, or a Protocol-Reject + of LCP! This event communicates an unrecoverable error that + terminates the connection. + + Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request + (RXR) + + This event occurs when an Echo-Request, Echo-Reply or Discard- + Request packet is received from the peer. The Echo-Reply packet is + a response to a Echo-Request packet. There is no reply to an Echo- + Reply or Discard-Request packet. + +4.6 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. + + Illegal-Event (-) + + This indicates an event that cannot occur in a properly + implemented automaton. The implementation has an internal error, + which should be reported and logged. No transition is taken, and + the implementation SHOULD NOT reset or freeze. + + This-Layer-Up (tlu) + + This action indicates to the upper layers that the automaton is + entering the Opened state. + + Typically, this action is used by the LCP to signal the Up event + to a NCP, Authentication Protocol, or Link Quality Protocol, or + MAY be used by a NCP to indicate that the link is available for + its network layer traffic. + + This-Layer-Down (tld) + + This action indicates to the upper layers that the automaton is + leaving the Opened state. + + Typically, this action is used by the LCP to signal the Down event + to a NCP, Authentication Protocol, or Link Quality Protocol, or + MAY be used by a NCP to indicate that the link is no longer + + + +Simpson [Page 23] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + available for its network layer traffic. + + This-Layer-Started (tls) + + This action indicates to the lower layers that the automaton is + entering the Starting state, and the lower layer is needed for the + link. The lower layer SHOULD respond with an Up event when the + lower layer is available. + + Implementation Note: + + This results of this action are highly implementation dependent. + + The transitions where this event is indicated are defined + according to a message passing architecture, rather than a + signalling architecture. If the action is desired to control + specific signals (such as DTR), other transitions for the action + are likely to be required (Open in Closed, RCR in Stopped). + + This-Layer-Finished (tlf) + + This action indicates to the lower layers that the automaton is + entering the Stopped or Closed states, and the lower layer is no + longer needed for the link. The lower layer SHOULD respond with a + Down event when the lower layer has terminated. + + Typically, this action MAY be used by the LCP to advance to the + Link Dead phase, or MAY be used by a NCP to indicate to the LCP + that the link may terminate when there are no other NCPs open. + + Implementation Note: + + This results of this action are highly implementation dependent. + + The transitions where this event is indicated are defined + according to a message passing architecture, rather than a + signalling architecture. If the action is desired to control + specific signals (such as DTR), other transitions for the action + are likely to be required (Close in Starting, Down in Closing). + + Initialize-Restart-Counter (irc) + + This action sets the Restart counter to the appropriate value + (Max-Terminate or Max-Configure). The counter is decremented for + each transmission, including the first. + + + + + + +Simpson [Page 24] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Implementation Note: + + In addition to setting the Restart counter, the implementation + MUST set the timeout period to the initial value when Restart + timer backoff is used. + + Zero-Restart-Counter (zrc) + + This action sets the Restart counter to zero. + + Implementation Note: + + This action enables the FSA to pause before proceeding to the + desired final state, allowing traffic to be processed by the peer. + In addition to zeroing the Restart counter, the implementation + MUST set the timeout period to an appropriate value. + + 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 when the Configure-Request packet is transmitted, to guard + against packet loss. The Restart counter is decremented each time + a Configure-Request is sent. + + Send-Configure-Ack (sca) + + The Send-Configure-Ack action transmits a Configure-Ack packet. + This acknowledges the reception 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 reception 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-Request (str) + + The Send-Terminate-Request action transmits a Terminate-Request + + + +Simpson [Page 25] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + packet. This indicates the desire to close a connection. The + Restart timer is started when the Terminate-Request packet is + transmitted, to guard against packet loss. The Restart counter is + decremented each time a Terminate-Request is sent. + + Send-Terminate-Ack (sta) + + The Send-Terminate-Ack action transmits a Terminate-Ack packet. + This acknowledges the reception of a Terminate-Request packet or + otherwise serves to synchronize the state machines. + + Send-Code-Reject (scj) + + The Send-Code-Reject action transmits a Code-Reject packet. This + indicates the reception of an unknown type of packet. + + Send-Echo-Reply (ser) + + The Send-Echo-Reply action transmits an Echo-Reply packet. This + acknowledges the reception of an Echo-Request packet. + +4.7 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. + + +4.8 Counters and Timers + + Restart Timer + + There is one special timer used by the automaton. The Restart + timer is used to time 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. + + Implementation Note: + + The Restart timer SHOULD be based on the speed of the link. The + default value is designed for low speed (2,400 to 9,600 bps), high + + + +Simpson [Page 26] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + switching latency links (typical telephone lines). Higher speed + links, or links with low switching latency, SHOULD have + correspondingly faster retransmission times. + + Instead of a constant value, the Restart timer MAY begin at an + initial small value and increase to the configured final value. + Each successive value less than the final value SHOULD be at least + twice the previous value. The initial value SHOULD be large + enough to account for the size of the packets, twice the round + trip time for transmission at the link speed, and at least an + additional 100 milliseconds to allow the peer to process the + packets before responding. Some circuits add another 200 + milliseconds of satellite delay. Round trip times for modems + operating at 14,400 bps have been measured in the range of 160 to + more than 600 milliseconds. + + Max-Terminate + + There is one required restart counter for Terminate-Requests. + Max- Terminate indicates the number of Terminate-Request packets + sent without receiving a Terminate-Ack before assuming that the + peer is unable to respond. Max-Terminate MUST be configurable, + but SHOULD default to two (2) transmissions. + + Max-Configure + + A similar counter is recommended for Configure-Requests. Max- + Configure indicates the number of Configure-Request packets sent + without receiving a valid Configure-Ack, Configure-Nak or + Configure- Reject before assuming that the peer is unable to + respond. Max- Configure MUST be configurable, but SHOULD default + to ten (10) transmissions. + + Max-Failure + + A related counter is recommended for Configure-Nak. Max-Failure + indicates the number of Configure-Nak packets sent without sending + a Configure-Ack 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. + +5. 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 + + + +Simpson [Page 27] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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, and + Discard-Request). + + 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 PPP 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 Link + Configuration, Link Termination, and Code-Reject packets (codes 1 + through 7) are always sent as if no Configuration Options were + enabled. This ensures that such LCP packets are always recognizable + even when one end of the link mistakenly believes the link to be + open. + + Implementation Note: + + In particular, the Async-Control-Character-Map (ACCM) default for + the type of link is used, and no address, control, or protocol + field compression is allowed. + + Exactly one LCP packet is encapsulated in the PPP Information + field, where the PPP 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 ... + +-+-+-+-+ + + + + + +Simpson [Page 28] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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. + + Up-to-date values of the LCP Code field are specified in the most + recent "Assigned Numbers" RFC [2]. This specification concerns + the following values: + + 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 + + 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 are treated as + padding and are 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. + +5.1 Configure-Request + + Description + + An implementation wishing to open a connection MUST transmit a LCP + packet with the Code field set to 1 (Configure-Request), and the + + + +Simpson [Page 29] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Options field filled with any desired changes to the link + defaults. Configuration Options SHOULD NOT be included with + default values. + + 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 MUST be changed whenever the content of the + Options field changes, and whenever a valid reply has been + received for a previous request. For retransmissions, the + Identifier MAY remain unchanged. + + 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. + +5.2 Configure-Ack + + Description + + If every Configuration Option received in a Configure-Request is + recognizable and all values are acceptable, then the + implementation MUST 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. + + + +Simpson [Page 30] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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. + +5.3 Configure-Nak + + Description + + If every element of the received Configuration Options is + recognizable but some values are not acceptable, then the + implementation MUST 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. + + Options which have no value fields (boolean options) MUST use the + + + +Simpson [Page 31] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Configure-Reject reply instead. + + Each Configuration Option which is allowed only a single instance + MUST be modified to a value acceptable to the Configure-Nak + sender. The default value MAY be used, when this differs from the + requested value. + + When a particular type of Configuration Option can be listed more + than once with different values, the Configure-Nak MUST include a + list of all values for that option which are acceptable to the + Configure-Nak sender. This includes acceptable values that were + present in the Configure-Request. + + Finally, an implementation may be configured to request the + negotiation of a specific Configuration Option. If that option is + not listed, then that option MAY be appended to the list of Nak'd + Configuration Options in order to prompt the peer to include 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. When multiple + instances of a Configuration Option are present, the peer SHOULD + select a single value to include in its next Configure-Request + packet. + + 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. + + 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 ... + +-+-+-+-+ + + + + +Simpson [Page 32] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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. + +5.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 the implementation + MUST 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. + + 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. + + A summary of the Configure-Reject packet format is shown below. The + fields are transmitted from left to right. + + + + + + + + + +Simpson [Page 33] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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. + +5.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 lower 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 Stopped states, or is otherwise in need of + re-negotiation. + + A summary of the Terminate-Request and Terminate-Ack packet formats + + + +Simpson [Page 34] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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 + + On transmission, the Identifier field MUST be changed whenever the + content of the Data field changes, and whenever a valid reply has + been received for a previous request. For retransmissions, the + Identifier MAY remain unchanged. On reception, the Identifier + field of the Terminate-Request is copied into the Identifier field + of the Terminate-Ack packet. + + 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 peer's established + MRU minus four. + + +5.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, the implementation SHOULD report + the error, since it is unlikely that the situation can be + rectified automatically. + + + + +Simpson [Page 35] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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 MUST be changed for each Code-Reject sent. + + 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 Data Link Layer headers nor an FCS. The + Rejected-Information MUST be truncated to comply with the peer's + established MRU. + + +5.7 Protocol-Reject + + Description + + Reception of a PPP packet with an unknown Protocol field 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, the implementation MUST stop + sending packets of the indicated protocol at the earliest + opportunity. + + Protocol-Reject packets can 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. + + + +Simpson [Page 36] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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 MUST be changed for each Protocol-Reject + sent. + + Rejected-Protocol + + The Rejected-Protocol field is two octets and contains the PPP + Protocol field of the packet which is being rejected. + + Rejected-Information + + The Rejected-Information field contains a copy of the packet which + is being rejected. It begins with the Information field, and does + not include any Data Link Layer headers nor an FCS. The + Rejected-Information MUST be truncated to comply with the peer's + established MRU. + +5.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), the Identifier field set, the local + Magic-Number (if any) inserted, and the Data field filled with any + desired data, but not exceeding the peer's established MRU minus + eight. + + + +Simpson [Page 37] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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, the local + Magic-Number (if any) inserted, and the Data field copied from the + Echo-Request, truncating as necessary to avoid exceeding the + peer's established MRU. + + 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. + + 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 + + On transmission, the Identifier field MUST be changed whenever the + content of the Data field changes, and whenever a valid reply has + been received for a previous request. For retransmissions, the + Identifier MAY remain unchanged. + + On reception, the Identifier field of the Echo-Request is copied + into the Identifier field of the Echo-Reply packet. + + Magic-Number + + The Magic-Number field is four octets and aids in detecting links + which are in the looped-back condition. Until the Magic-Number + Configuration Option has been successfully negotiated, the Magic- + Number MUST be transmitted as zero. See the Magic-Number + Configuration Option for further explanation. + + + +Simpson [Page 38] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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 peer's established + MRU minus eight. + +5.9 Discard-Request + + Description + + LCP includes a Discard-Request Code in order to provide a Data + Link Layer 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. + + The sender transmits a LCP packet with the Code field set to 11 + (Discard-Request), the Identifier field set, the local Magic- + Number (if any) inserted, and the Data field filled with any + desired data, but not exceeding the peer's established MRU minus + eight. + + Discard-Request packets may only be sent in the LCP Opened state. + On reception, the receiver MUST simply throw away any Discard- + Request that it receives. + + A summary of the Discard-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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic-Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + Code + + 11 for Discard-Request. + + Identifier + + The Identifier field MUST be changed for each Discard-Request + sent. + + + +Simpson [Page 39] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Magic-Number + + The Magic-Number field is four octets and aids in detecting links + which are in the looped-back condition. Until the Magic-Number + Configuration Option has been successfully negotiated, the Magic- + Number MUST be transmitted as zero. See the Magic-Number + Configuration Option for further explanation. + + 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 peer's established + MRU minus four. + +6. LCP Configuration Options + + LCP Configuration Options allow negotiation of modifications to the + default characteristics of a point-to-point link. If a Configuration + Option is not included in a Configure-Request packet, the default + value for that Configuration Option is assumed. + + 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 description. (None of the Configuration + Options in this specification can be listed more than once.) + + The end of the list of Configuration Options is indicated by the + length of the LCP packet. + + Unless otherwise specified, all Configuration Options apply in a + half-duplex fashion; typically, in the receive direction of the link + from the point of view of the Configure-Request sender. + + 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. Up-to-date values of the LCP Option Type + field are specified in the most recent "Assigned Numbers" RFC [2]. + + + +Simpson [Page 40] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + This specification concerns the following values: + + 1 Maximum-Receive-Unit + 2 Async-Control-Character-Map + 3 Authentication-Protocol + 4 Quality-Protocol + 5 Magic-Number + 6 RESERVED + 7 Protocol-Field-Compression + 8 Address-and-Control-Field-Compression + + 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 information specific to + the Configuration Option. The format and length of the Data field + is determined by the Type and Length fields. + +6.1 Maximum-Receive-Unit + + Description + + This Configuration Option may be sent to inform the peer that the + implementation can receive larger packets, or to request that the + peer send smaller packets. + + The default value is 1500 octets. If smaller packets are + requested, an implementation MUST still be able to receive the + full 1500 octet information field in case link synchronization is + lost. + + Implementation Note: + + This option is used to indicate an implementation capability. The + peer is not required to maximize the use of the capacity. For + example, when a MRU is indicated which is 2048 octets, the peer is + not required to send any packet with 2048 octets. The peer need + not Configure-Nak to indicate that it will only send smaller + packets, since the implementation will always require support for + at least 1500 octets. + + + +Simpson [Page 41] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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 specifies the + maximum number of octets in the Information and Padding fields. + It does not include the framing, Protocol field, FCS, nor any + transparency bits or bytes. + +6.2 Async-Control-Character-Map + + Description + + This Configuration Option provides a method to negotiate the use + of control character transparency on asynchronous links. + + For asynchronous links, the default value is 0xffffffff, which + causes all octets less than 0x20 to be mapped into an appropriate + two octet sequence. For most other links, the default value is 0, + since there is no need for mapping. + + However, it is rarely necessary to map all control characters, and + often it is unnecessary to map any control characters. The + Configuration Option is used to inform the peer which control + characters MUST remain mapped when the peer sends them. + + The peer MAY still send any other octets in mapped format, if it + is necessary because of constraints known to the peer. The peer + SHOULD Configure-Nak with the logical union of the sets of mapped + octets, so that when such octets are spuriously introduced they + can be ignored on receipt. + + + + +Simpson [Page 42] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ACCM (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 2 + + Length + + 6 + + Async-Control-Character-Map + + The Async-Control-Character-Map field is four octets and indicates + the set of control characters to be mapped. The map is sent most + significant octet first. + + Each numbered bit corresponds to the octet of the same value. If + the bit is cleared to zero, then that octet need not be mapped. + If the bit is set to one, then that octet MUST remain mapped. For + example, if bit 19 is set to zero, then the ASCII control + character 19 (DC3, Control-S) MAY be sent in the clear. + + Note: The least significant bit of the least significant octet + (the final octet transmitted) is numbered bit 0, and would map + to the ASCII control character NUL. + +6.3 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 method to negotiate the use + of a specific authentication protocol. By default, authentication + is not required. + + + + +Simpson [Page 43] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + An implementation MUST NOT include multiple Authentication- + Protocol Configuration Options in its Configure-Request packets. + Instead, it SHOULD attempt to configure the most desirable + protocol first. If that protocol is Configure-Nak'd, then the + implementation SHOULD attempt the next most desirable protocol in + the next Configure-Request. + + 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 protocol be used in both directions. It is perfectly + acceptable for different protocols to be used in each direction. + This will, of course, depend on the specific protocols negotiated. + + 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 Protocol field values for that same + authentication protocol. + + Up-to-date values of the Authentication-Protocol field are + specified in the most recent "Assigned Numbers" RFC [2]. Current + values are assigned as follows: + + + + +Simpson [Page 44] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Value (in hex) Protocol + + c023 Password Authentication Protocol + c223 Challenge Handshake Authentication Protocol + + Data + + The Data field is zero or more octets and contains additional data + as determined by the particular protocol. + +6.4 Quality-Protocol + + 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. + + This Configuration Option provides a method to negotiate the use + of a specific protocol for link quality monitoring. By default, + link quality monitoring is disabled. + + There is no requirement that quality monitoring be full duplex or + that the same protocol be used in both directions. It is + perfectly acceptable for different protocols to be used in each + direction. This will, of course, depend on the specific protocols + negotiated. + + A summary of the Quality-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 | Quality-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Type + + 4 + + Length + + >= 4 + + + + + +Simpson [Page 45] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Quality-Protocol + + The Quality-Protocol field is two octets and indicates the link + quality monitoring protocol desired. Values for this field are + always the same as the PPP Protocol field values for that same + monitoring protocol. + + Up-to-date values of the Quality-Protocol field are specified in + the most recent "Assigned Numbers" RFC [2]. Current values are + assigned as follows: + + Value (in hex) Protocol + + c025 Link Quality Report + + Data + + The Data field is zero or more octets and contains additional data + as determined by the particular protocol. + +6.5 Magic-Number + + Description + + This Configuration Option provides a method 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 Quality-Protocol Configuration Option. By default, the + Magic-Number is not negotiated, and zero is inserted where a + Magic-Number might otherwise be used. + + 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. + + + +Simpson [Page 46] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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 + MUST 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 (that is, 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 looped-back link is increased, and a new + Magic-Number MUST 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 + 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 it receives 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 + + + +Simpson [Page 47] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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 SHOULD 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 LCP Echo-Request, Echo-Reply, and Discard- + Request packets have a Magic-Number field. If Magic-Number has + been successfully negotiated, an implementation MUST transmit + these packets with the Magic-Number field set to its negotiated + Magic-Number. + + The Magic-Number field of these packets SHOULD be inspected on + reception. All received Magic-Number fields MUST be equal to + either zero or the peer's unique Magic-Number, depending on + whether or not the peer negotiated a Magic-Number. 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 + 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 + 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + +Simpson [Page 48] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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, if it is not + Rejected outright. + +6.6 Protocol-Field-Compression + + Description + + This Configuration Option provides a method to negotiate the + compression of the PPP Protocol field. By default, all + implementations MUST transmit packets with two octet PPP Protocol + fields. + + 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 the implementation can + receive such single octet Protocol fields. + + 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 binary representations for 3, + 00000011 and 00000000 00000011). + + When using low speed links, it is desirable to conserve bandwidth + by sending as little redundant data as possible. The Protocol- + Field-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 packets are compressible since data + + + +Simpson [Page 49] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + protocols are typically assigned with Protocol field values less + than 256. + + Compressed Protocol fields MUST NOT be transmitted unless this + Configuration Option has been negotiated. When negotiated, PPP + implementations MUST accept PPP packets with either double-octet + or single-octet Protocol fields, and MUST NOT distinguish between + them. + + The Protocol field is never compressed when sending any LCP + packet. This rule guarantees unambiguous recognition of LCP + packets. + + 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 + +6.7 Address-and-Control-Field-Compression + + Description + + This Configuration Option provides a method 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 appropriate to the link framing. + + Since these fields usually have constant values for point-to-point + links, they are easily compressed. This Configuration Option is + sent to inform the peer that the implementation can receive + compressed Address and Control fields. + + + +Simpson [Page 50] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 8 + + Length + + 2 + +A. LCP Recommended Options + + The following Configurations Options are recommended: + + SYNC LINES + + Magic Number Link Quality Monitoring No Address and Control Field + Compression No Protocol Field Compression + + ASYNC LINES + + Async Control Character Map Magic Number Address and Control Field + Compression Protocol Field Compression + +Security Considerations + + Security issues are briefly discussed in sections concerning the + Authentication Phase, the Close event, and the Authentication- + + + +Simpson [Page 51] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Protocol Configuration Option. Further discussion is in a companion + document entitled PPP Authentication Protocols. + + +References + + [1] Perkins, D., "Requirements for an Internet Standard + Point-to-Point Protocol", RFC 1547, December 1993. + + [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, + USC/Information Sciences Institute, July 1992. + +Acknowledgments + + Much of the text in this document is taken from the WG Requirements, + and RFCs 1171 & 1172, 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: Rick Adams (UUNET), + Ken Adelman (TGV), Fred Baker (ACC), Mike Ballard (Telebit), Craig + Fox (Network Systems), Karl Fox (Morning Star Technologies), Phill + Gross (AN&S), former WG chair Russ Hobby (UC Davis), David Kaufman + (Proteon), former WG chair Steve Knowles (FTP Software), former WG + chair Brian Lloyd (L&A), John LoVerso (Xylogics), Bill Melohn (Sun + Microsystems), Mike Patton (MIT), former WG chair Drew Perkins + (Fore), Greg Satz (cisco systems), John Shriver (Proteon), Vernon + Schryver (Silicon Graphics), and Asher Waldfogel (Wellfleet). + + The "Day in the Life" example was instigated by Kory Hamzeh (Avatar). + In this version, improvements in wording were also provided by Scott + Ginsburg, Mark Moraes, and Timon Sloan, as they worked on + implementations. + + Special thanks to Morning Star Technologies for providing computing + resources and network access support for writing this specification. + +Chair's Address + + The working group can be contacted via the current chair: + + Fred Baker + Advanced Computer Communications + 315 Bollay Drive + Santa Barbara, California, 93111 + + EMail: fbaker@acc.com + + + +Simpson [Page 52] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +Editor's Address + + Questions about this memo can also be directed to: + + William Allen Simpson + Daydreamer + Computer Systems Consulting Services + 1384 Fontaine + Madison Heights, Michigan 48071 + + EMail: Bill.Simpson@um.cc.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 53] + -- cgit v1.2.3