diff options
Diffstat (limited to 'doc/rfc/rfc1661.txt')
| -rw-r--r-- | doc/rfc/rfc1661.txt | 2976 |
1 files changed, 2976 insertions, 0 deletions
diff --git a/doc/rfc/rfc1661.txt b/doc/rfc/rfc1661.txt new file mode 100644 index 0000000..02112bd --- /dev/null +++ b/doc/rfc/rfc1661.txt @@ -0,0 +1,2976 @@ + + + + + + +Network Working Group W. Simpson, Editor +Request for Comments: 1661 Daydreamer +STD: 51 July 1994 +Obsoletes: 1548 +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. + + +Table of Contents + + + 1. Introduction .......................................... 1 + 1.1 Specification of Requirements ................... 2 + 1.2 Terminology ..................................... 3 + + 2. PPP Encapsulation ..................................... 4 + + +Simpson [Page i] + RFC 1661 Point-to-Point Protocol July 1994 + + + 3. PPP Link Operation .................................... 6 + 3.1 Overview ........................................ 6 + 3.2 Phase Diagram ................................... 6 + 3.3 Link Dead (physical-layer not ready) ............ 7 + 3.4 Link Establishment Phase ........................ 7 + 3.5 Authentication Phase ............................ 8 + 3.6 Network-Layer Protocol Phase .................... 8 + 3.7 Link Termination Phase .......................... 9 + + 4. The Option Negotiation Automaton ...................... 11 + 4.1 State Transition Table .......................... 12 + 4.2 States .......................................... 14 + 4.3 Events .......................................... 16 + 4.4 Actions ......................................... 21 + 4.5 Loop Avoidance .................................. 23 + 4.6 Counters and Timers ............................. 24 + + 5. LCP Packet Formats .................................... 26 + 5.1 Configure-Request ............................... 28 + 5.2 Configure-Ack ................................... 29 + 5.3 Configure-Nak ................................... 30 + 5.4 Configure-Reject ................................ 31 + 5.5 Terminate-Request and Terminate-Ack ............. 33 + 5.6 Code-Reject ..................................... 34 + 5.7 Protocol-Reject ................................. 35 + 5.8 Echo-Request and Echo-Reply ..................... 36 + 5.9 Discard-Request ................................. 37 + + 6. LCP Configuration Options ............................. 39 + 6.1 Maximum-Receive-Unit (MRU) ...................... 41 + 6.2 Authentication-Protocol ......................... 42 + 6.3 Quality-Protocol ................................ 43 + 6.4 Magic-Number .................................... 45 + 6.5 Protocol-Field-Compression (PFC) ................ 48 + 6.6 Address-and-Control-Field-Compression (ACFC) + + SECURITY CONSIDERATIONS ...................................... 51 + REFERENCES ................................................... 51 + ACKNOWLEDGEMENTS ............................................. 51 + CHAIR'S ADDRESS .............................................. 52 + EDITOR'S ADDRESS ............................................. 52 + + + + + + + + + + +Simpson [Page ii] + RFC 1661 Point-to-Point Protocol July 1994 + + +1. Introduction + + The Point-to-Point Protocol is designed for simple links which + transport packets between two peers. These links provide full-duplex + simultaneous bi-directional operation, and are assumed to deliver + packets in order. It is intended that PPP provide a common solution + for easy connection of a wide variety of hosts, bridges and routers + [1]. + + Encapsulation + + The PPP encapsulation provides for multiplexing of different + network-layer protocols simultaneously over the same link. 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 within the default HDLC-like 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, detect a looped-back link and other common + misconfiguration errors, and terminate the link. Other optional + facilities provided are authentication of the identity of its peer + on the link, and determination when a link is functioning properly + and when it is failing. + + 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 + + + +Simpson [Page 1] + RFC 1661 Point-to-Point Protocol July 1994 + + + respective network-layer protocols. These NCPs are defined in + companion documents. + + 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 2] + RFC 1661 Point-to-Point Protocol July 1994 + + +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 + The implementation discards the packet without further + processing. The implementation SHOULD provide the + capability of logging the error, including the contents of + the silently discarded packet, and SHOULD record the event + in a statistics counter. + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 3] + RFC 1661 Point-to-Point Protocol July 1994 + + +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. + + A summary of the PPP encapsulation is shown below. The fields are + transmitted from left to right. + + +----------+-------------+---------+ + | Protocol | Information | Padding | + | 8/16 bits| * | * | + +----------+-------------+---------+ + + + Protocol Field + + The Protocol field is one or 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). + + + + + + + + + + + +Simpson [Page 4] + RFC 1661 Point-to-Point Protocol July 1994 + + + Up-to-date values of the Protocol field are specified in the most + recent "Assigned Numbers" RFC [2]. This specification reserves + the following values: + + Value (in hex) Protocol Name + + 0001 Padding Protocol + 0003 to 001f reserved (transparency inefficient) + 007d reserved (Control Escape) + 00cf reserved (PPP NLPID) + 00ff reserved (compression inefficient) + + 8001 to 801f unused + 807d unused + 80cf unused + 80ff unused + + 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. + + The maximum length for the Information field, including Padding, + but not including the Protocol field, 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. + + + + + + +Simpson [Page 5] + RFC 1661 Point-to-Point Protocol July 1994 + + +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 which are specified in the following simplified state diagram: + + +------+ +-----------+ +--------------+ + | | UP | | OPENED | | SUCCESS/NONE + | Dead |------->| Establish |---------->| Authenticate |--+ + | | | | | | | + +------+ +-----------+ +--------------+ | + ^ | | | + | FAIL | FAIL | | + +<--------------+ +----------+ | + | | | + | +-----------+ | +---------+ | + | DOWN | | | CLOSING | | | + +------------| Terminate |<---+<----------| Network |<-+ + | | | | + +-----------+ +---------+ + + Not all transitions are specified in this diagram. The following + semantics MUST be followed. + + + + + + + +Simpson [Page 6] + RFC 1661 Point-to-Point Protocol July 1994 + + +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 later) will be in the + Initial or Starting states. The transition to the Link Establishment + phase will signal an Up event to the LCP 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 link, + 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 later) has been both sent and received. + + All Configuration Options are assumed to be at default values unless + altered by the configuration exchange. See the chapter 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. + + The receipt of the LCP Configure-Request causes a return to the Link + Establishment phase from the Network-Layer Protocol phase or + Authentication phase. + + + + + + + + +Simpson [Page 7] + RFC 1661 Point-to-Point Protocol July 1994 + + +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 request the use of that authentication + protocol during Link Establishment phase. + + Authentication SHOULD take place as soon as possible after link + establishment. However, link quality determination MAY occur + concurrently. An implementation MUST NOT allow the exchange of link + quality determination packets to delay authentication indefinitely. + + Advancement from the Authentication phase to the Network-Layer + Protocol phase MUST NOT occur until authentication has completed. If + authentication fails, the authenticator SHOULD proceed instead to the + Link Termination phase. + + Only Link Control Protocol, authentication protocol, and link quality + monitoring packets are allowed during this phase. All other packets + received during this phase MUST be silently discarded. + + Implementation Notes: + + An implementation SHOULD NOT fail authentication simply due to + timeout or lack of response. The authentication SHOULD allow some + method of retransmission, and proceed to the Link Termination + phase only after a number of authentication attempts has been + exceeded. + + The implementation responsible for commencing Link Termination + phase is the implementation which has refused authentication to + its peer. + + + +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. + + + + + +Simpson [Page 8] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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 supported + network-layer protocol packets received when the corresponding NCP is + not in the Opened state MUST be silently discarded. + + Implementation Note: + + While LCP is in the Opened state, any protocol packet which is + unsupported by the implementation MUST be returned in a Protocol- + Reject (described later). 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 + 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. + + + + +Simpson [Page 9] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 10] + RFC 1661 Point-to-Point Protocol July 1994 + + +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 + + TO+ = Timeout with counter > 0 irc = Initialize-Restart-Count + TO- = Timeout with counter expired zrc = Zero-Restart-Count + + 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 + + + + + + + + + + +Simpson [Page 11] + RFC 1661 Point-to-Point Protocol July 1994 + + +4.1. 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 tlf/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 12] + RFC 1661 Point-to-Point Protocol July 1994 + + + + | 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-Count 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. + + The events and actions are defined according to a message passing + architecture, rather than a signalling architecture. If an action is + desired to control specific signals (such as DTR), additional actions + are likely to be required. + + [p] Passive option; see Stopped state discussion. + + [r] Restart option; see Open event discussion. + + [x] Crossed connection; see RCA event discussion. + + + + + + +Simpson [Page 13] + RFC 1661 Point-to-Point Protocol July 1994 + + +4.2. 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. + + 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 + + + +Simpson [Page 14] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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. + + 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, the Closed state is + 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 + + + +Simpson [Page 15] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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 running, since a Configure-Ack has + not yet been received. + + Opened + + In the Opened state, a Configure-Ack has been both sent and + received. The Restart timer is not running. + + 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.3. Events + + Transitions and actions in the automaton are caused by events. + + Up + + This 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 + + This event occurs when a lower layer indicates that it is no + + + +Simpson [Page 16] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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 + + This 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. + + 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. Care must be taken that an intervening Down event + cannot occur from another source. + + The Down followed by an Up will cause an orderly renegotiation + of the link, by progressing through the Starting to the + Request-Sent state. This will cause the renegotiation of the + link, without any harmful side effects. + + Close + + This event indicates that the link is not available for traffic; + + + +Simpson [Page 17] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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. Care + must be taken that an intervening Close event cannot occur from + another source. + + The Close followed by an Open will cause an orderly termination + of the link, by progressing through 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- + 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 + + + +Simpson [Page 18] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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) + + This 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. + + 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) + + This event occurs when a Terminate-Request packet is received. + The Terminate-Request packet indicates the desire of the peer to + + + +Simpson [Page 19] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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) + + This 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) + + This 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 + 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 an Echo-Request packet. There is no reply to an + Echo-Reply or Discard-Request packet. + + + + + + +Simpson [Page 20] + RFC 1661 Point-to-Point Protocol July 1994 + + +4.4. Actions + + Actions in the automaton are caused by events and typically indicate + the transmission of packets and/or the starting or stopping of the + Restart timer. + + 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 + 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. + + This results of this action are highly implementation dependent. + + This-Layer-Finished (tlf) + + This action indicates to the lower layers that the automaton is + entering the Initial, Closed or Stopped 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. + + + +Simpson [Page 21] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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. + + This results of this action are highly implementation dependent. + + Initialize-Restart-Count (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. + + 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-Count (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) + + A Configure-Request packet is transmitted. 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) + + A Configure-Ack packet is transmitted. This acknowledges the + reception of a Configure-Request packet with an acceptable set of + Configuration Options. + + Send-Configure-Nak (scn) + + A Configure-Nak or Configure-Reject packet is transmitted, as + appropriate. This negative response reports the reception of a + + + +Simpson [Page 22] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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 chapter on LCP Packet Formats. + + Send-Terminate-Request (str) + + A Terminate-Request packet is transmitted. 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) + + A Terminate-Ack packet is transmitted. This acknowledges the + reception of a Terminate-Request packet or otherwise serves to + synchronize the automatons. + + Send-Code-Reject (scj) + + A Code-Reject packet is transmitted. This indicates the reception + of an unknown type of packet. + + Send-Echo-Reply (ser) + + An Echo-Reply packet is transmitted. This acknowledges the + reception of an Echo-Request packet. + + + +4.5. 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. + + + + + +Simpson [Page 23] + RFC 1661 Point-to-Point Protocol July 1994 + + +4.6. 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 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. + + + + +Simpson [Page 24] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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 for peer requested + options are converted to Configure-Reject packets, and locally + desired options are no longer appended. Max-Failure MUST be + configurable, but SHOULD default to five (5) transmissions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 25] + RFC 1661 Point-to-Point Protocol July 1994 + + +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 + 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). + + In the interest of simplicity, there is no version field in the LCP + packet. A correctly functioning LCP implementation will always + respond to unknown Protocols and Codes with an easily recognizable + LCP 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 + negotiated. In particular, each Configuration Option specifies a + default value. This ensures that such LCP packets are always + recognizable, even when one end of the link mistakenly believes the + link to be open. + + 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 ... + +-+-+-+-+ + + + Code + + The Code field is one octet, and identifies the kind of LCP + + + +Simpson [Page 26] + RFC 1661 Point-to-Point Protocol July 1994 + + + packet. When a packet is received with an unknown 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 document 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 without affecting the + automaton. + + Length + + The Length field is two octets, and indicates the length of the + LCP packet, including the Code, Identifier, Length and Data + fields. The Length MUST NOT exceed the MRU of the link. + + 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 + without affecting the automaton. + + 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. + + + + + + + + +Simpson [Page 27] + RFC 1661 Point-to-Point Protocol July 1994 + + +5.1. Configure-Request + + Description + + An implementation wishing to open a connection MUST transmit a + Configure-Request. The Options field is 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 contents 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 chapter. + + + + + + + + + +Simpson [Page 28] + RFC 1661 Point-to-Point Protocol July 1994 + + +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 Configure-Ack. The acknowledged + Configuration Options MUST NOT be reordered or modified in any + way. + + On reception of a Configure-Ack, the Identifier field MUST match + that of the last transmitted Configure-Request. Additionally, the + Configuration Options in a Configure-Ack MUST exactly match those + of the last transmitted Configure-Request. Invalid packets are + silently discarded. + + A summary of the Configure-Ack packet format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+ + + + Code + + 2 for Configure-Ack. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Configure-Request which caused this Configure-Ack. + + Options + + The Options field is variable in length, and contains the list of + zero or more Configuration Options that the sender is + acknowledging. All Configuration Options are always acknowledged + simultaneously. + + + + + + + + +Simpson [Page 29] + RFC 1661 Point-to-Point Protocol July 1994 + + +5.3. Configure-Nak + + Description + + If every instance of the received Configuration Options is + recognizable, but some values are not acceptable, then the + implementation MUST transmit a Configure-Nak. The Options field + is 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 + 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 when a new + Configure-Request is sent, the Configuration Options MAY be + 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 + + + +Simpson [Page 30] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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 ... + +-+-+-+-+ + + + 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 Configure-Reject. The Options field is 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 + + + +Simpson [Page 31] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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 when a new + Configure-Request is sent, it MUST NOT include any of the + Configuration Options listed in the Configure-Reject. + + A summary of the Configure-Reject packet format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+ + + + Code + + 4 for Configure-Reject. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Configure-Request which caused this Configure-Reject. + + 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. + + + + + + + + + + + + + + + + + + +Simpson [Page 32] + RFC 1661 Point-to-Point Protocol July 1994 + + +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. + + An implementation wishing to close a connection SHOULD transmit a + Terminate-Request. 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 Terminate-Ack MUST be + transmitted. + + 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 + 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. + + + + +Simpson [Page 33] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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. The end of the field is indicated by the Length. + + + +5.6. Code-Reject + + Description + + Reception of a LCP packet with an unknown Code indicates that the + peer is operating with a different version. This MUST be reported + back to the sender of the unknown Code by transmitting a Code- + Reject. + + Upon reception of the Code-Reject of a code which is fundamental + to this version of the protocol, the implementation SHOULD report + the problem and drop the connection, since it is unlikely that the + situation can be rectified automatically. + + A summary of the Code-Reject packet format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Rejected-Packet ... + +-+-+-+-+-+-+-+-+ + + + Code + + 7 for Code-Reject. + + Identifier + + The Identifier field MUST be changed for each Code-Reject sent. + + Rejected-Packet + + The Rejected-Packet 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-Packet MUST be truncated to comply with the peer's + + + +Simpson [Page 34] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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 automaton is in the Opened + state, then this MUST be reported back to the peer by transmitting + a Protocol-Reject. + + 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. + + 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. + + + +Simpson [Page 35] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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. + + Upon reception of an Echo-Request in the LCP Opened state, an + Echo-Reply MUST be transmitted. + + Echo-Request and Echo-Reply packets MUST 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. + + + +Simpson [Page 36] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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. + + 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. The end of the field is indicated by the Length. + + + +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. + + Discard-Request packets MUST only be sent in the LCP Opened state. + On reception, the receiver MUST silently discard any Discard- + Request that it receives. + + + + + + + + + + + + + +Simpson [Page 37] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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. + + 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. The end of the field is indicated by the Length. + + + + + + + + + + + + + + + + +Simpson [Page 38] + RFC 1661 Point-to-Point Protocol July 1994 + + +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 field 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. + + Design Philosophy + + The options indicate additional capabilities or requirements of + the implementation that is requesting the option. An + implementation which does not understand any option SHOULD + interoperate with one which implements every option. + + A default is specified for each option which allows the link to + correctly function without negotiation of the option, although + perhaps with less than optimal performance. + + Except where explicitly specified, acknowledgement of an option + does not require the peer to take any additional action other than + the default. + + It is not necessary to send the default values for the options in + a Configure-Request. + + + 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 ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + +Simpson [Page 39] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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]. + This document concerns the following values: + + 0 RESERVED + 1 Maximum-Receive-Unit + 3 Authentication-Protocol + 4 Quality-Protocol + 5 Magic-Number + 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 or unrecognized 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 contains information + specific to the Configuration Option. The format and length of + the Data field is determined by the Type and Length fields. + + When the Data field is indicated by the Length to extend beyond + the end of the Information field, the entire packet is silently + discarded without affecting the automaton. + + + + + + + + + + + + + + + + +Simpson [Page 40] + RFC 1661 Point-to-Point Protocol July 1994 + + +6.1. Maximum-Receive-Unit (MRU) + + 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. + + 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. + + + + +Simpson [Page 41] + RFC 1661 Point-to-Point Protocol July 1994 + + +6.2. 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 protocol for authentication. By default, + authentication is not required. + + 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. + + The implementation sending the Configure-Request is indicating + that it expects authentication from its peer. If an + implementation sends a Configure-Ack, then it is agreeing to + authenticate with the specified protocol. An implementation + receiving a Configure-Ack 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 + + + + + +Simpson [Page 42] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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: + + 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.3. 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. + + The implementation sending the Configure-Request is indicating + that it expects to receive monitoring information from its peer. + If an implementation sends a Configure-Ack, then it is agreeing to + send the specified protocol. An implementation receiving a + Configure-Ack SHOULD expect the peer to send the acknowledged + protocol. + + There is no requirement that quality monitoring be full-duplex or + + + +Simpson [Page 43] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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 + + 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. + + + + + + +Simpson [Page 44] + RFC 1661 Point-to-Point Protocol July 1994 + + +6.4. 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 a unique seed. Suggested sources of + uniqueness include machine serial numbers, other network hardware + addresses, time-of-day clocks, etc. Particularly good random + number seeds are precise measurements of the inter-arrival time of + physical events such as packet reception on other connected + networks, server response time, or the typing rate of a human + user. It is also suggested that as many sources as possible be + used simultaneously. + + When a Configure-Request is received with a Magic-Number + Configuration Option, the received Magic-Number is compared with + the Magic-Number of the last Configure-Request sent to the peer. + If the two Magic-Numbers are different, then the link is not + looped-back, and the Magic-Number SHOULD be acknowledged. If the + two Magic-Numbers are equal, then it is possible, but not certain, + that the link is looped-back and that this Configure-Request is + actually the one last sent. To determine this, a Configure-Nak + 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- + + + +Simpson [Page 45] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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, looped-back links 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 when 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 + 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. + + + +Simpson [Page 46] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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, 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 looped-back condition is + terminated, and Magic-Numbers are successfully negotiated. A more + optimistic procedure (in the case of a looped-back link) is to + begin transmitting LCP Echo-Request packets until an appropriate + Echo-Reply is received, indicating a termination of the looped- + back condition. + + A summary of the Magic-Number Configuration Option format is shown + below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Magic-Number + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Magic-Number (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 5 + + Length + + 6 + + Magic-Number + + The Magic-Number field is four octets, and indicates a number + which is very likely to be unique to one end of the link. A + Magic-Number of zero is illegal and MUST always be Nak'd, if it is + not Rejected outright. + + + + + + + +Simpson [Page 47] + RFC 1661 Point-to-Point Protocol July 1994 + + +6.5. Protocol-Field-Compression (PFC) + + 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 + 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 + + + +Simpson [Page 48] + RFC 1661 Point-to-Point Protocol July 1994 + + + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 49] + RFC 1661 Point-to-Point Protocol July 1994 + + +6.6. Address-and-Control-Field-Compression (ACFC) + + 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. + + 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 + + + + + + + +Simpson [Page 50] + RFC 1661 Point-to-Point Protocol July 1994 + + +Security Considerations + + Security issues are briefly discussed in sections concerning the + Authentication Phase, the Close event, and the Authentication- + Protocol Configuration Option. + + + +References + + [1] Perkins, D., "Requirements for an Internet Standard Point-to- + Point Protocol", RFC 1547, Carnegie Mellon University, + December 1993. + + [2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC + 1340, USC/Information Sciences Institute, July 1992. + + +Acknowledgements + + 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@merit.edu mailing list. + + Much of the text in this document is taken from the working group + requirements [1]; and RFCs 1171 & 1172, by Drew Perkins while at + Carnegie Mellon University, and by Russ Hobby of the University of + California at Davis. + + William Simpson was principally responsible for introducing + consistent terminology and philosophy, and the re-design of the phase + and negotiation state machines. + + 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, Ken + Adelman, Fred Baker, Mike Ballard, Craig Fox, Karl Fox, Phill Gross, + Kory Hamzeh, former WG chair Russ Hobby, David Kaufman, former WG + chair Steve Knowles, Mark Lewis, former WG chair Brian Lloyd, John + LoVerso, Bill Melohn, Mike Patton, former WG chair Drew Perkins, Greg + Satz, John Shriver, Vernon Schryver, and Asher Waldfogel. + + Special thanks to Morning Star Technologies for providing computing + resources and network access support for writing this specification. + + + + + + + +Simpson [Page 51] + RFC 1661 Point-to-Point Protocol July 1994 + + +Chair's Address + + The working group can be contacted via the current chair: + + Fred Baker + Advanced Computer Communications + 315 Bollay Drive + Santa Barbara, California 93117 + + fbaker@acc.com + + + +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 + + Bill.Simpson@um.cc.umich.edu + bsimpson@MorningStar.com + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 52] + + |