summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1331.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1331.txt')
-rw-r--r--doc/rfc/rfc1331.txt3867
1 files changed, 3867 insertions, 0 deletions
diff --git a/doc/rfc/rfc1331.txt b/doc/rfc/rfc1331.txt
new file mode 100644
index 0000000..b61fcc5
--- /dev/null
+++ b/doc/rfc/rfc1331.txt
@@ -0,0 +1,3867 @@
+
+
+
+
+
+
+Network Working Group W. Simpson
+Request for Comments: 1331 Daydreamer
+Obsoletes: RFCs 1171, 1172 May 1992
+
+
+
+ The Point-to-Point Protocol (PPP)
+ for the
+ Transmission of Multi-protocol Datagrams
+ over Point-to-Point Links
+
+
+Status of this Memo
+
+ This RFC specifies an IAB standards track protocol for the Internet
+ community, and requests discussion and suggestions for improvements.
+ Please refer to the current edition of the "IAB Official Protocol
+ Standards" for the standardization state and status of this protocol.
+ Distribution of this memo is unlimited.
+
+Abstract
+
+ The Point-to-Point Protocol (PPP) provides a method for transmitting
+ datagrams over serial point-to-point links. PPP is comprised of
+ three main components:
+
+ 1. A method for encapsulating datagrams over serial links.
+
+ 2. A Link Control Protocol (LCP) for establishing, configuring,
+ and testing the data-link connection.
+
+ 3. A family of Network Control Protocols (NCPs) for establishing
+ and configuring different network-layer protocols.
+
+ This document defines the PPP encapsulation scheme, together with the
+ PPP Link Control Protocol (LCP), an extensible option negotiation
+ protocol which is able to negotiate a rich assortment of
+ configuration parameters and provides additional management
+ functions.
+
+ This RFC is a product of the Point-to-Point Protocol Working Group of
+ the Internet Engineering Task Force (IETF). Comments on this memo
+ should be submitted to the ietf-ppp@ucdavis.edu mailing list.
+
+
+
+
+
+
+
+
+Simpson [Page i]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+Table of Contents
+
+
+ 1. Introduction .......................................... 1
+ 1.1 Specification of Requirements ................... 3
+ 1.2 Terminology ..................................... 3
+
+ 2. Physical Layer Requirements ........................... 4
+
+ 3. The Data Link Layer ................................... 5
+ 3.1 Frame Format .................................... 6
+
+ 4. PPP Link Operation .................................... 10
+ 4.1 Overview ........................................ 10
+ 4.2 Phase Diagram ................................... 10
+ 4.3 Link Dead (physical-layer not ready) ............ 10
+ 4.4 Link Establishment Phase ........................ 11
+ 4.5 Authentication Phase ............................ 11
+ 4.6 Network-Layer Protocol Phase .................... 12
+ 4.7 Link Termination Phase .......................... 12
+
+ 5. The Option Negotiation Automaton ...................... 14
+ 5.1 State Diagram ................................... 15
+ 5.2 State Transition Table .......................... 16
+ 5.3 States .......................................... 18
+ 5.4 Events .......................................... 20
+ 5.5 Actions ......................................... 24
+ 5.6 Loop Avoidance .................................. 26
+ 5.7 Counters and Timers ............................. 27
+
+ 6. LCP Packet Formats .................................... 28
+ 6.1 Configure-Request ............................... 30
+ 6.2 Configure-Ack ................................... 31
+ 6.3 Configure-Nak ................................... 32
+ 6.4 Configure-Reject ................................ 33
+ 6.5 Terminate-Request and Terminate-Ack ............. 35
+ 6.6 Code-Reject ..................................... 36
+ 6.7 Protocol-Reject ................................. 38
+ 6.8 Echo-Request and Echo-Reply ..................... 39
+ 6.9 Discard-Request ................................. 40
+
+ 7. LCP Configuration Options ............................. 42
+ 7.1 Format .......................................... 43
+ 7.2 Maximum-Receive-Unit ............................ 44
+ 7.3 Async-Control-Character-Map ..................... 45
+ 7.4 Authentication-Protocol ......................... 47
+ 7.5 Quality-Protocol ................................ 49
+ 7.6 Magic-Number .................................... 51
+
+
+
+Simpson [Page ii]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 7.7 Protocol-Field-Compression ...................... 54
+ 7.8 Address-and-Control-Field-Compression ........... 56
+
+ APPENDICES ................................................... 58
+
+ A. Asynchronous HDLC ..................................... 58
+
+ B. Fast Frame Check Sequence (FCS) Implementation ........ 61
+ B.1 FCS Computation Method .......................... 61
+ B.2 Fast FCS table generator ........................ 63
+
+ C. LCP Recommended Options ............................... 64
+
+ SECURITY CONSIDERATIONS ...................................... 65
+
+ REFERENCES ................................................... 65
+
+ ACKNOWLEDGEMENTS ............................................. 66
+
+ CHAIR'S ADDRESS .............................................. 66
+
+ AUTHOR'S ADDRESS ............................................. 66
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page iii]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+1. Introduction
+
+ Motivation
+
+ In the last few years, the Internet has seen explosive growth in
+ the number of hosts supporting TCP/IP. The vast majority of these
+ hosts are connected to Local Area Networks (LANs) of various
+ types, Ethernet being the most common. Most of the other hosts
+ are connected through Wide Area Networks (WANs) such as X.25 style
+ Public Data Networks (PDNs). Relatively few of these hosts are
+ connected with simple point-to-point (i.e., serial) links. Yet,
+ point-to-point links are among the oldest methods of data
+ communications and almost every host supports point-to-point
+ connections. For example, asynchronous RS-232-C [1] interfaces
+ are essentially ubiquitous.
+
+ Encapsulation
+
+ One reason for the small number of point-to-point IP links is the
+ lack of a standard encapsulation protocol. There are plenty of
+ non-standard (and at least one de facto standard) encapsulation
+ protocols available, but there is not one which has been agreed
+ upon as an Internet Standard. By contrast, standard encapsulation
+ schemes do exist for the transmission of datagrams over most
+ popular LANs.
+
+ PPP provides an encapsulation protocol over both bit-oriented
+ synchronous links and asynchronous links with 8 bits of data and
+ no parity. These links MUST be full-duplex, but MAY be either
+ dedicated or circuit-switched. PPP uses HDLC as a basis for the
+ encapsulation.
+
+ PPP has been carefully designed to retain compatibility with most
+ commonly used supporting hardware. In addition, an escape
+ mechanism is specified to allow control data such as XON/XOFF to
+ be transmitted transparently over the link, and to remove spurious
+ control data which may be injected into the link by intervening
+ hardware and software.
+
+ The PPP encapsulation also provides for multiplexing of different
+ network-layer protocols simultaneously over the same link. It is
+ intended that PPP provide a common solution for easy connection of
+ a wide variety of hosts, bridges and routers.
+
+ Some protocols expect error free transmission, and either provide
+ error detection only on a conditional basis, or do not provide it
+ at all. PPP uses the HDLC Frame Check Sequence for error
+ detection. This is commonly available in hardware
+
+
+
+Simpson [Page 1]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ implementations, and a software implementation is provided.
+
+ By default, only 8 additional octets are necessary to form the
+ encapsulation. In environments where bandwidth is at a premium,
+ the encapsulation may be shortened to as few as 2 octets. To
+ support high speed hardware implementations, PPP provides that the
+ default encapsulation header and information fields fall on 32-bit
+ boundaries, and allows the trailer to be padded to an arbitrary
+ boundary.
+
+ Link Control Protocol
+
+ More importantly, the Point-to-Point Protocol defines more than
+ just an encapsulation scheme. In order to be sufficiently
+ versatile to be portable to a wide variety of environments, PPP
+ provides a Link Control Protocol (LCP). The LCP is used to
+ automatically agree upon the encapsulation format options, handle
+ varying limits on sizes of packets, authenticate the identity of
+ its peer on the link, determine when a link is functioning
+ properly and when it is defunct, detect a looped-back link and
+ other common misconfiguration errors, and terminate the link.
+
+ Network Control Protocols
+
+ Point-to-Point links tend to exacerbate many problems with the
+ current family of network protocols. For instance, assignment and
+ management of IP addresses, which is a problem even in LAN
+ environments, is especially difficult over circuit-switched
+ point-to-point links (such as dial-up modem servers). These
+ problems are handled by a family of Network Control Protocols
+ (NCPs), which each manage the specific needs required by their
+ respective network-layer protocols. These NCPs are defined in
+ other documents.
+
+ Configuration
+
+ It is intended that PPP be easy to configure. By design, the
+ standard defaults should handle all common configurations. The
+ implementor may specify improvements to the default configuration,
+ which are automatically communicated to the peer without operator
+ intervention. Finally, the operator may explicitly configure
+ options for the link which enable the link to operate in
+ environments where it would otherwise be impossible.
+
+ This self-configuration is implemented through an extensible
+ option negotiation mechanism, wherein each end of the link
+ describes to the other its capabilities and requirements.
+ Although the option negotiation mechanism described in this
+
+
+
+Simpson [Page 2]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ document is specified in terms of the Link Control Protocol (LCP),
+ the same facilities may be used by the Internet Protocol Control
+ Protocol (IPCP) and others in the family of NCPs.
+
+1.1. Specification of Requirements
+
+ In this document, several words are used to signify the requirements
+ of the specification. These words are often capitalized.
+
+ MUST
+
+ This word, or the adjective "required", means that the definition
+ is an absolute requirement of the specification.
+
+ MUST NOT
+
+ This phrase means that the definition is an absolute prohibition
+ of the specification.
+
+ SHOULD
+
+ This word, or the adjective "recommended", means that there may
+ exist valid reasons in particular circumstances to ignore this
+ item, but the full implications should be understood and carefully
+ weighed before choosing a different course.
+
+ MAY
+
+ This word, or the adjective "optional", means that this item is
+ one of an allowed set of alternatives. An implementation which
+ does not include this option MUST be prepared to interoperate with
+ another implementation which does include the option.
+
+1.2. Terminology
+
+ This document frequently uses the following terms:
+
+ peer
+
+ The other end of the point-to-point link.
+
+ silently discard
+
+ This means the implementation discards the packet without further
+ processing. The implementation SHOULD provide the capability of
+ logging the error, including the contents of the silently
+ discarded packet, and SHOULD record the event in a statistics
+ counter.
+
+
+
+Simpson [Page 3]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+2. Physical Layer Requirements
+
+ The Point-to-Point Protocol is capable of operating across any
+ DTE/DCE interface (e.g., EIA RS-232-C, EIA RS-422, EIA RS-423 and
+ CCITT V.35). The only absolute requirement imposed by PPP is the
+ provision of a full-duplex circuit, either dedicated or circuit-
+ switched, which can operate in either an asynchronous (start/stop) or
+ synchronous bit-serial mode, transparent to PPP Data Link Layer
+ frames. PPP does not impose any restrictions regarding transmission
+ rate, other than those imposed by the particular DTE/DCE interface in
+ use.
+
+ PPP does not require any particular synchronous encoding, such as FM,
+ NRZ, or NRZI.
+
+ Implementation Note:
+
+ NRZ is currently most widely available, and on that basis is
+ recommended as a default. When configuration of the encoding is
+ allowed, NRZI is recommended as an alternative, because of its
+ relative immunity to signal inversion configuration errors.
+
+ PPP does not require the use of modem control signals, such as
+ Request To Send (RTS), Clear To Send (CTS), Data Carrier Detect
+ (DCD), and Data Terminal Ready (DTR).
+
+ Implementation Note:
+
+ When available, using such signals can allow greater functionality
+ and performance. In particular, such signals SHOULD be used to
+ signal the Up and Down events in the Option Negotiation Automaton
+ (described below).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 4]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+3. The Data Link Layer
+
+ The Point-to-Point Protocol uses the principles, terminology, and
+ frame structure of the International Organization For
+ Standardization's (ISO) High-level Data Link Control (HDLC)
+ procedures (ISO 3309-1979 [2]), as modified by ISO 3309:1984/PDAD1
+ "Addendum 1: Start/stop transmission" [5]. ISO 3309-1979 specifies
+ the HDLC frame structure for use in synchronous environments. ISO
+ 3309:1984/PDAD1 specifies proposed modifications to ISO 3309-1979 to
+ allow its use in asynchronous environments.
+
+ The PPP control procedures use the definitions and Control field
+ encodings standardized in ISO 4335-1979 [3] and ISO 4335-
+ 1979/Addendum 1-1979 [4]. The PPP frame structure is also consistent
+ with CCITT Recommendation X.25 LAPB [6], since that too is based on
+ HDLC.
+
+ The purpose of this memo is not to document what is already
+ standardized in ISO 3309. We assume that the reader is already
+ familiar with HDLC, or has access to a copy of [2] or [6]. Instead,
+ this paper attempts to give a concise summary and point out specific
+ options and features used by PPP. Since "Addendum 1: Start/stop
+ transmission", is not yet standardized and widely available, it is
+ summarized in Appendix A.
+
+ To remain consistent with standard Internet practice, and avoid
+ confusion for people used to reading RFCs, all binary numbers in the
+ following descriptions are in Most Significant Bit to Least
+ Significant Bit order, reading from left to right, unless otherwise
+ indicated. Note that this is contrary to standard ISO and CCITT
+ practice which orders bits as transmitted (i.e., network bit order).
+ Keep this in mind when comparing this document with the international
+ standards documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 5]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+3.1. Frame Format
+
+ A summary of the standard PPP frame structure is shown below. This
+ figure does not include start/stop bits (for asynchronous links), nor
+ any bits or octets inserted for transparency. The fields are
+ transmitted from left to right.
+
+ +----------+----------+----------+----------+------------
+ | Flag | Address | Control | Protocol | Information
+ | 01111110 | 11111111 | 00000011 | 16 bits | *
+ +----------+----------+----------+----------+------------
+ ---+----------+----------+-----------------
+ | FCS | Flag | Inter-frame Fill
+ | 16 bits | 01111110 | or next Address
+ ---+----------+----------+-----------------
+
+ Inter-frame Time Fill
+
+ For asynchronous links, inter-frame time fill SHOULD be accomplished
+ in the same manner as inter-octet time fill, by transmitting
+ continuous "1" bits (mark-hold state).
+
+ For synchronous links, the Flag Sequence SHOULD be transmitted during
+ inter-frame time fill. There is no provision for inter-octet time
+ fill.
+
+ Implementation Note:
+
+ Mark idle (continuous ones) SHOULD NOT be used for idle
+ synchronous inter-frame time fill. However, certain types of
+ circuit-switched links require the use of mark idle, particularly
+ those that calculate accounting based on bit activity. When mark
+ idle is used on a synchronous link, the implementation MUST ensure
+ at least 15 consecutive "1" bits between Flags, and that the Flag
+ Sequence is generated at the beginning and end of a frame.
+
+Flag Sequence
+
+ The Flag Sequence is a single octet and indicates the beginning or
+ end of a frame. The Flag Sequence consists of the binary sequence
+ 01111110 (hexadecimal 0x7e).
+
+ The Flag is a frame separator. Only one Flag is required between two
+ frames. Two consecutive Flags constitute an empty frame, which is
+ ignored.
+
+
+
+
+
+
+Simpson [Page 6]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ Implementation Note:
+
+ The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT
+ be used. When not avoidable, such an implementation MUST ensure
+ that the first Flag Sequence detected (the end of the frame) is
+ promptly communicated to the link layer.
+
+Address Field
+
+ The Address field is a single octet and contains the binary sequence
+ 11111111 (hexadecimal 0xff), the All-Stations address. PPP does not
+ assign individual station addresses. The All-Stations address MUST
+ always be recognized and received. The use of other address lengths
+ and values may be defined at a later time, or by prior agreement.
+ Frames with unrecognized Addresses SHOULD be silently discarded, and
+ reported through the normal network management facility.
+
+Control Field
+
+ The Control field is a single octet and contains the binary sequence
+ 00000011 (hexadecimal 0x03), the Unnumbered Information (UI) command
+ with the P/F bit set to zero. Frames with other Control field values
+ SHOULD be silently discarded.
+
+Protocol Field
+
+ The Protocol field is two octets and its value identifies the
+ protocol encapsulated in the Information field of the frame.
+
+ This Protocol field is defined by PPP and is not a field defined by
+ HDLC. However, the Protocol field is consistent with the ISO 3309
+ extension mechanism for Address fields. All Protocols MUST be odd;
+ the least significant bit of the least significant octet MUST equal
+ "1". Also, all Protocols MUST be assigned such that the least
+ significant bit of the most significant octet equals "0". Frames
+ received which don't comply with these rules MUST be considered as
+ having an unrecognized Protocol, and handled as specified by the LCP.
+ The Protocol field is transmitted and received most significant octet
+ first.
+
+ Protocol field values in the "0---" to "3---" range identify the
+ network-layer protocol of specific datagrams, and values in the "8--
+ -" to "b---" range identify datagrams 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
+
+
+
+Simpson [Page 7]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ datagrams as link-layer Control Protocols (such as LCP).
+
+ The most up-to-date values of the Protocol field are specified in the
+ most recent "Assigned Numbers" RFC [11]. Current values are assigned
+ as follows:
+
+ Value (in hex) Protocol Name
+
+ 0001 to 001f reserved (transparency inefficient)
+ 0021 Internet Protocol
+ 0023 OSI Network Layer
+ 0025 Xerox NS IDP
+ 0027 DECnet Phase IV
+ 0029 Appletalk
+ 002b Novell IPX
+ 002d Van Jacobson Compressed TCP/IP
+ 002f Van Jacobson Uncompressed TCP/IP
+ 0031 Bridging PDU
+ 0033 Stream Protocol (ST-II)
+ 0035 Banyan Vines
+ 0037 reserved (until 1993)
+ 00ff reserved (compression inefficient)
+
+ 0201 802.1d Hello Packets
+ 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
+
+ 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.
+
+
+
+
+
+Simpson [Page 8]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+Information Field
+
+ The Information field is zero or more octets. The Information field
+ contains the datagram for the protocol specified in the Protocol
+ field. The end of the Information field is found by locating the
+ closing Flag Sequence and allowing two octets for the Frame Check
+ Sequence field. The default maximum length of the Information field
+ is 1500 octets. By negotiation, consenting PPP implementations may
+ use other values for the maximum Information field length.
+
+ On transmission, the Information field may be padded with an
+ arbitrary number of octets up to the maximum length. It is the
+ responsibility of each protocol to disambiguate padding octets from
+ real information.
+
+Frame Check Sequence (FCS) Field
+
+ The Frame Check Sequence field is normally 16 bits (two octets). The
+ use of other FCS lengths may be defined at a later time, or by prior
+ agreement.
+
+ The FCS field is calculated over all bits of the Address, Control,
+ Protocol and Information fields not including any start and stop bits
+ (asynchronous) and any bits (synchronous) or octets (asynchronous)
+ inserted for transparency. This does not include the Flag Sequences
+ or the FCS field itself. The FCS is transmitted with the coefficient
+ of the highest term first.
+
+ Note: When octets are received which are flagged in the Async-
+ Control-Character-Map, they are discarded before calculating the
+ FCS. See the description in Appendix A.
+
+ For more information on the specification of the FCS, see ISO 3309
+ [2] or CCITT X.25 [6].
+
+ Note: A fast, table-driven implementation of the 16-bit FCS
+ algorithm is shown in Appendix B. This implementation is based on
+ [7], [8], and [9].
+
+Modifications to the Basic Frame Format
+
+ The Link Control Protocol can negotiate modifications to the standard
+ PPP frame structure. However, modified frames will always be clearly
+ distinguishable from standard frames.
+
+
+
+
+
+
+
+Simpson [Page 9]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+4. PPP Link Operation
+
+4.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).
+
+4.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 |<-+
+ | | | |
+ +-----------+ +---------+
+
+4.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.
+
+
+
+
+Simpson [Page 10]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 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.
+
+4.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. Any non-LCP
+ packets received during this phase MUST be silently discarded.
+
+ All Configuration Options are assumed to be at default values unless
+ altered by the configuration exchange. See the section on LCP
+ Configuration Options for further discussion.
+
+ It is important to note that only Configuration Options which are
+ independent of particular network-layer protocols are configured by
+ LCP. Configuration of individual network-layer protocols is handled
+ by separate Network Control Protocols (NCPs) during the Network-Layer
+ Protocol phase.
+
+4.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 necessary. If an implementation
+ requires that the peer authenticate with some specific authentication
+ protocol, then it MUST negotiate the use of that authentication
+ protocol during Link Establishment phase.
+
+ Authentication SHOULD take place as soon as possible after link
+ establishment. However, link quality determination MAY occur
+ concurrently. An implementation MUST NOT allow the exchange of link
+ quality determination packets to delay authentication indefinitely.
+
+ Advancement from the Authentication phase to the Network-Layer
+ Protocol phase MUST NOT occur until the peer is successfully
+ authenticated using the negotiated authentication protocol. In the
+ event of failure to authenticate, PPP SHOULD proceed instead to the
+ Link Termination phase.
+
+
+
+
+
+Simpson [Page 11]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+4.6. Network-Layer Protocol Phase
+
+ Once PPP has finished the previous phases, each network-layer
+ protocol (such as IP) MUST be separately configured by the
+ appropriate Network Control Protocol (NCP).
+
+ Each NCP may be Opened and Closed at any time.
+
+ 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 SHOULD be silently discarded.
+
+ During this phase, link traffic consists of any possible combinations
+ of LCP, NCP, and network-layer protocol packets. Any NCP or
+ network-layer protocol packets received during any other phase SHOULD
+ be silently discarded.
+
+ 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 supported protocols are silently discarded.
+
+4.7. Link Termination Phase
+
+ PPP may terminate the link at any time. This will usually be done at
+ the request of a human user, but might happen because of a physical
+ event such as the loss of carrier, authentication failure, link
+ quality failure, or the expiration of an idle-period timer.
+
+ LCP is used to close the link through an exchange of Terminate
+ packets. When the link is closing, PPP informs the network-layer
+ protocols so that they may take appropriate action.
+
+ After the exchange of Terminate packets, the implementation 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
+
+
+
+Simpson [Page 12]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 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.
+
+ 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 a NCP has Closed is not sufficient reason to cause
+ the termination of the PPP link, even if that NCP was the only
+ currently NCP in the Opened state.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 13]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+5. 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-Start
+ Close= administrative Close tlf = This-Layer-Finished
+
+ 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
+ - = illegal action
+
+
+
+
+
+
+
+
+Simpson [Page 14]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+5.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.
+
+ 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 15]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+5.2. State Transition Table
+
+ The complete state transition table follows. States are indicated
+ horizontally, and events are read vertically. State transitions and
+ actions are represented in the form action/new-state. Multiple
+ actions are separated by commas, and may continue on succeeding lines
+ as space requires. The state may be followed by a letter, which
+ indicates an explanatory footnote.
+
+ Rationale:
+
+ In previous versions of this table, a simplified non-deterministic
+ finite-state automaton was used, with considerable detailed
+ information specified in the semantics. This lead to
+ interoperability problems from differing interpretations.
+
+ This table functions similarly to the previous versions, with the
+ up/down flags expanded to explicit states, and the active/passive
+ paradigm eliminated. It is believed that this table interoperates
+ with previous versions better than those versions themselves.
+
+ | 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 16]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ | 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 tld,scj,scr/6
+ 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 SHOULD be 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 17]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+5.3. 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 18]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 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, 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
+
+
+
+Simpson [Page 19]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 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.
+
+ 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.
+
+5.4. 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 to signal LCP
+ that the link is entering Link Establishment phase, or used to
+ signal a NCP that the link is entering Network-Layer Protocol
+ phase.
+
+ Down
+
+ The Down event occurs when a lower layer indicates that it is no
+ longer ready to carry packets. Typically, this event is used to
+ signal LCP that the link is entering Link Dead phase, or used to
+ signal a NCP that the link is leaving Network-Layer Protocol
+ phase.
+
+ Open
+
+ The Open event indicates that the link is administratively
+ available for traffic; that is, the network administrator (human
+
+
+
+Simpson [Page 20]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 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 should be necessary.
+
+ Implementation Note:
+
+ Experience has shown that users will execute an additional Open
+ command when they want to renegotiate the link. 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.
+
+ 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
+
+
+
+Simpson [Page 21]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 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.
+
+ 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.
+
+
+
+
+
+Simpson [Page 22]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 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
+ 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
+
+
+
+Simpson [Page 23]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 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.
+
+5.5. 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 SHOULD NOT occur. The implementation
+ probably has an internal error.
+
+ This-Layer-Up (tlu)
+
+ This action indicates to the upper layers that the automaton is
+ entering the Opened state.
+
+ Typically, this action MAY be 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 traffic.
+
+ This-Layer-Down (tld)
+
+ This action indicates to the upper layers that the automaton is
+ leaving the Opened state.
+
+ Typically, this action MAY be 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 traffic.
+
+ This-Layer-Start (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.
+
+
+
+
+Simpson [Page 24]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ This action is highly implementation dependent.
+
+ 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.
+
+ This action is highly implementation dependent.
+
+ 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.
+
+ 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. 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.
+
+
+
+
+
+Simpson [Page 25]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 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
+ 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.
+
+5.6. Loop Avoidance
+
+ The protocol makes a reasonable attempt at avoiding Configuration
+ Option negotiation loops. However, the protocol does NOT guarantee
+ that loops will not happen. As with any negotiation, it is possible
+ to configure two PPP implementations with conflicting policies that
+ will never converge. It is also possible to configure policies which
+ do converge, but which take significant time to do so. Implementors
+ should keep this in mind and should implement loop detection
+ mechanisms or higher level timeouts.
+
+
+
+
+Simpson [Page 26]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+5.7. 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 MAY 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 (19,200 bps or less), high
+ switching latency links (typical telephone lines). Higher speed
+ links, or links with low switching latency, SHOULD have
+ correspondingly faster retransmission times.
+
+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.
+
+
+
+
+
+
+
+Simpson [Page 27]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+6. LCP Packet Formats
+
+ There are three classes of LCP packets:
+
+ 1. Link Configuration packets used to establish and configure a
+ link (Configure-Request, Configure-Ack, Configure-Nak and
+ Configure-Reject).
+
+ 2. Link Termination packets used to terminate a link (Terminate-
+ Request and Terminate-Ack).
+
+ 3. Link Maintenance packets used to manage and debug a link
+ (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, 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 Data Link Layer Protocol field value will be
+ used to differentiate Version 1 LCP from all other versions. A
+ correctly functioning Version 1 LCP implementation will always
+ respond to unknown Protocols (including other versions) with an
+ easily recognizable Version 1 packet, thus providing a deterministic
+ fallback mechanism for implementations of other versions.
+
+ Regardless of which Configuration Options are enabled, all LCP Link
+ Configuration, Link Termination, and Code-Reject packets (codes 1
+ through 7) are always sent in the full, standard form, as if no
+ Configuration Options were enabled. This ensures that LCP
+ Configure-Request packets are always recognizable even when one end
+ of the link mistakenly believes the link to be open.
+
+ Exactly one Link Control Protocol packet is encapsulated in the
+ Information field of PPP Data Link Layer frames where the Protocol
+ field indicates type hex c021 (Link Control Protocol).
+
+ A summary of the Link Control Protocol packet format is shown below.
+ The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Identifier | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data ...
+ +-+-+-+-+
+
+
+
+
+
+Simpson [Page 28]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ Code
+
+ The Code field is one octet and identifies the kind of LCP packet.
+ When a packet is received with an invalid Code field, a Code-
+ Reject packet is transmitted.
+
+ The most up-to-date values of the LCP Code field are specified in
+ the most recent "Assigned Numbers" RFC [11]. Current values are
+ assigned as follows:
+
+ 1 Configure-Request
+ 2 Configure-Ack
+ 3 Configure-Nak
+ 4 Configure-Reject
+ 5 Terminate-Request
+ 6 Terminate-Ack
+ 7 Code-Reject
+ 8 Protocol-Reject
+ 9 Echo-Request
+ 10 Echo-Reply
+ 11 Discard-Request
+ 12 RESERVED
+
+ Identifier
+
+ The Identifier field is one octet and aids in matching requests
+ and replies. When a packet is received with an invalid Identifier
+ field, the packet is silently discarded.
+
+ Length
+
+ The Length field is two octets and indicates the length of the LCP
+ packet including the Code, Identifier, Length and Data fields.
+ Octets outside the range of the Length field should be treated as
+ Data Link Layer padding and should be ignored on reception. When
+ a packet is received with an invalid Length field, the packet is
+ silently discarded.
+
+ Data
+
+ The Data field is zero or more octets as indicated by the Length
+ field. The format of the Data field is determined by the Code
+ field.
+
+
+
+
+
+
+
+
+Simpson [Page 29]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+6.1. Configure-Request
+
+ Description
+
+ A LCP implementation wishing to open a connection MUST transmit a
+ LCP packet with the Code field set to 1 (Configure-Request) and
+ the Options field filled with any desired changes to the default
+ link Configuration Options.
+
+ Upon reception of a Configure-Request, an appropriate reply MUST
+ be transmitted.
+
+ A summary of the Configure-Request packet format is shown below. The
+ fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Identifier | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ...
+ +-+-+-+-+
+
+ Code
+
+ 1 for Configure-Request.
+
+ Identifier
+
+ The Identifier field SHOULD be changed on each transmission. On
+ reception, the Identifier field should be copied into the
+ Identifier field of the appropriate reply packet.
+
+ Options
+
+ The options field is variable in length and contains the list of
+ zero or more Configuration Options that the sender desires to
+ negotiate. All Configuration Options are always negotiated
+ simultaneously. The format of Configuration Options is further
+ described in a later section.
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 30]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+6.2. Configure-Ack
+
+ Description
+
+ If every Configuration Option received in a Configure-Request is
+ both recognizable and acceptable, then a LCP implementation should
+ transmit a LCP packet with the Code field set to 2 (Configure-
+ Ack), the Identifier field copied from the received Configure-
+ Request, and the Options field copied from the received
+ Configure-Request. The acknowledged Configuration Options MUST
+ NOT be reordered or modified in any way.
+
+ On reception of a Configure-Ack, the Identifier field must match
+ that of the last transmitted Configure-Request. Additionally, the
+ Configuration Options in a Configure-Ack must exactly match those
+ of the last transmitted Configure-Request. Invalid packets are
+ silently discarded.
+
+ A summary of the Configure-Ack packet format is shown below. The
+ fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Identifier | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ...
+ +-+-+-+-+
+
+ Code
+
+ 2 for Configure-Ack.
+
+ Identifier
+
+ The Identifier field is a copy of the Identifier field of the
+ Configure-Request which caused this Configure-Ack.
+
+ Options
+
+ The Options field is variable in length and contains the list of
+ zero or more Configuration Options that the sender is
+ acknowledging. All Configuration Options are always acknowledged
+ simultaneously.
+
+
+
+
+
+
+
+Simpson [Page 31]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+6.3. Configure-Nak
+
+ Description
+
+ If every element of the received Configuration Options is
+ recognizable but some are not acceptable, then a LCP
+ implementation should transmit a LCP packet with the Code field
+ set to 3 (Configure-Nak), the Identifier field copied from the
+ received Configure-Request, and the Options field filled with only
+ the unacceptable Configuration Options from the Configure-Request.
+ All acceptable Configuration Options are filtered out of the
+ Configure-Nak, but otherwise the Configuration Options from the
+ Configure-Request MUST NOT be reordered.
+
+ Each of the Nak'd Configuration Options MUST be modified to a
+ value acceptable to the Configure-Nak sender. Options which have
+ no value fields (boolean options) use the Configure-Reject reply
+ instead.
+
+ Finally, an implementation may be configured to request the
+ negotiation of a specific option. If that option is not listed,
+ then that option may be appended to the list of Nak'd
+ Configuration Options in order to request the peer to list that
+ option in its next Configure-Request packet. Any value fields for
+ the option MUST indicate values acceptable to the Configure-Nak
+ sender.
+
+ On reception of a Configure-Nak, the Identifier field must match
+ that of the last transmitted Configure-Request. Invalid packets
+ are silently discarded.
+
+ Reception of a valid Configure-Nak indicates that a new
+ Configure-Request MAY be sent with the Configuration Options
+ modified as specified in the Configure-Nak.
+
+ Some Configuration Options have a variable length. Since the
+ Nak'd Option has been modified by the peer, the implementation
+ MUST be able to handle an Option length which is different from
+ the original Configure-Request.
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 32]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ A summary of the Configure-Nak packet format is shown below. The
+ fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Identifier | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ...
+ +-+-+-+-+
+
+ Code
+
+ 3 for Configure-Nak.
+
+ Identifier
+
+ The Identifier field is a copy of the Identifier field of the
+ Configure-Request which caused this Configure-Nak.
+
+ Options
+
+ The Options field is variable in length and contains the list of
+ zero or more Configuration Options that the sender is Nak'ing.
+ All Configuration Options are always Nak'd simultaneously.
+
+
+6.4. Configure-Reject
+
+ Description
+
+ If some Configuration Options received in a Configure-Request are
+ not recognizable or are not acceptable for negotiation (as
+ configured by a network administrator), then a LCP implementation
+ should transmit a LCP packet with the Code field set to 4
+ (Configure-Reject), the Identifier field copied from the received
+ Configure-Request, and the Options field filled with only the
+ unacceptable Configuration Options from the Configure-Request.
+ All recognizable and negotiable Configuration Options are filtered
+ out of the Configure-Reject, but otherwise the Configuration
+ Options MUST NOT be reordered or modified in any way.
+
+ On reception of a Configure-Reject, the Identifier field must
+ match that of the last transmitted Configure-Request.
+ Additionally, the Configuration Options in a Configure-Reject must
+ be a proper subset of those in the last transmitted Configure-
+ Request. Invalid packets are silently discarded.
+
+
+
+
+Simpson [Page 33]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 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.
+
+ 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 34]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+6.5. Terminate-Request and Terminate-Ack
+
+ Description
+
+ LCP includes Terminate-Request and Terminate-Ack Codes in order to
+ provide a mechanism for closing a connection.
+
+ A LCP implementation wishing to close a connection should transmit
+ a LCP packet with the Code field set to 5 (Terminate-Request) and
+ the Data field filled with any desired data. Terminate-Request
+ packets should continue to be sent until Terminate-Ack is
+ received, the 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
+ is shown below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Identifier | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data ...
+ +-+-+-+-+
+
+ Code
+
+ 5 for Terminate-Request;
+
+ 6 for Terminate-Ack.
+
+ Identifier
+
+ The Identifier field is one octet and aids in matching requests
+ and replies.
+
+
+
+
+
+
+Simpson [Page 35]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 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
+ maximum Information field length minus four.
+
+
+6.6. Code-Reject
+
+ Description
+
+ Reception of a LCP packet with an unknown Code indicates that one
+ of the communicating LCP implementations is faulty or incomplete.
+ This error MUST be reported back to the sender of the unknown Code
+ by transmitting a LCP packet with the Code field set to 7 (Code-
+ Reject), and the inducing packet copied to the Rejected-
+ Information field.
+
+ Upon reception of a Code-Reject, the implementation SHOULD report
+ the error, since it is unlikely that the situation can be
+ rectified automatically.
+
+ A summary of the Code-Reject packet format is shown below. The
+ fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Identifier | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Rejected-Packet ...
+ +-+-+-+-+-+-+-+-+
+
+ Code
+
+ 7 for Code-Reject.
+
+ Identifier
+
+ The Identifier field is one octet and is for use by the
+ transmitter.
+
+ Rejected-Information
+
+ The Rejected-Information field contains a copy of the LCP packet
+ which is being rejected. It begins with the Information field,
+ and does not include any PPP Data Link Layer headers nor the FCS.
+
+
+
+Simpson [Page 36]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ The Rejected-Information MUST be truncated to comply with the
+ peer's established maximum Information field length.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 37]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+6.7. Protocol-Reject
+
+ Description
+
+ Reception of a PPP frame with an unknown Data Link Layer Protocol
+ indicates that the peer is attempting to use a protocol which is
+ unsupported. This usually occurs when the peer attempts to
+ configure a new protocol. If the LCP state machine is in the
+ Opened state, then this error MUST be reported back to the peer by
+ transmitting a LCP packet with the Code field set to 8 (Protocol-
+ Reject), the Rejected-Protocol field set to the received Protocol,
+ and the inducing packet copied to the Rejected-Information field.
+
+ Upon reception of a Protocol-Reject, a LCP implementation SHOULD
+ stop transmitting frames of the indicated protocol.
+
+ Protocol-Reject packets may only be sent in the LCP Opened state.
+ Protocol-Reject packets received in any state other than the LCP
+ Opened state SHOULD be silently discarded.
+
+ A summary of the Protocol-Reject packet format is shown below. The
+ fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Identifier | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Rejected-Protocol | Rejected-Information ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Code
+
+ 8 for Protocol-Reject.
+
+ Identifier
+
+ The Identifier field is one octet and is for use by the
+ transmitter.
+
+ Rejected-Protocol
+
+ The Rejected-Protocol field is two octets and contains the
+ Protocol of the Data Link Layer frame which is being rejected.
+
+ Rejected-Information
+
+ The Rejected-Information field contains a copy from the frame
+
+
+
+Simpson [Page 38]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ which is being rejected. It begins with the Information field,
+ and does not include any PPP Data Link Layer headers nor the FCS.
+ The Rejected-Information MUST be truncated to comply with the
+ peer's established maximum Information field length.
+
+
+6.8. Echo-Request and Echo-Reply
+
+ Description
+
+ LCP includes Echo-Request and Echo-Reply Codes in order to provide
+ a Data Link Layer loopback mechanism for use in exercising both
+ directions of the link. This is useful as an aid in debugging,
+ link quality determination, performance testing, and for numerous
+ other functions.
+
+ An Echo-Request sender transmits a LCP packet with the Code field
+ set to 9 (Echo-Request), the Identifier field set, the local
+ Magic-Number inserted, and the Data field filled with any desired
+ data, up to but not exceeding the peer's established maximum
+ Information field length minus eight.
+
+ Upon reception of an Echo-Request, a LCP packet MUST be
+ transmitted with the Code field set to 10 (Echo-Reply), the
+ Identifier field copied from the received Echo-Request, the local
+ Magic-Number inserted, and the Data field copied from the Echo-
+ Request, truncating as necessary to avoid exceeding the peer's
+ established maximum Information field length.
+
+ Echo-Request and Echo-Reply packets may only be sent in the LCP
+ Opened state. Echo-Request and Echo-Reply packets received in any
+ state other than the LCP Opened state SHOULD be silently
+ discarded.
+
+ 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 ...
+ +-+-+-+-+
+
+
+
+
+
+Simpson [Page 39]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ Code
+
+ 9 for Echo-Request;
+
+ 10 for Echo-Reply.
+
+ Identifier
+
+ The Identifier field is one octet and aids in matching Echo-
+ Requests and Echo-Replies.
+
+ Magic-Number
+
+ The Magic-Number field is four octets and aids in detecting links
+ which are in the looped-back condition. Unless modified by a
+ Configuration Option, the Magic-Number MUST be transmitted as zero
+ and MUST be ignored on reception. 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
+ maximum Information field length minus eight.
+
+
+6.9. Discard-Request
+
+ Description
+
+ LCP includes a Discard-Request Code in order to provide a Data
+ Link Layer data sink mechanism for use in exercising the local to
+ remote direction of the link. This is useful as an aid in
+ debugging, performance testing, and for numerous other functions.
+
+ A discard sender transmits a LCP packet with the Code field set to
+ 11 (Discard-Request) the Identifier field set, the local Magic-
+ Number inserted, and the Data field filled with any desired data,
+ up to but not exceeding the peer's established maximum Information
+ field length minus eight.
+
+ A discard receiver MUST simply throw away an Discard-Request that
+ it receives.
+
+ Discard-Request packets may only be sent in the LCP Opened state.
+
+
+
+
+
+Simpson [Page 40]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ A summary of the Discard-Request packet formats is shown below. The
+ fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Code | Identifier | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Magic-Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data ...
+ +-+-+-+-+
+
+ Code
+
+ 11 for Discard-Request.
+
+ Identifier
+
+ The Identifier field is one octet and is for use by the Discard-
+ Request transmitter.
+
+ Magic-Number
+
+ The Magic-Number field is four octets and aids in detecting links
+ which are in the looped-back condition. Unless modified by a
+ configuration option, the Magic-Number MUST be transmitted as zero
+ and MUST be ignored on reception. 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
+ maximum Information field length minus four.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 41]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+7. LCP Configuration Options
+
+ LCP Configuration Options allow modifications to the standard
+ characteristics of a point-to-point link to be negotiated.
+ Negotiable modifications include such things as the maximum receive
+ unit, async control character mapping, the link authentication
+ method, etc. If a Configuration Option is not included in a
+ Configure-Request packet, the default value for that Configuration
+ Option is assumed.
+
+ The end of the list of Configuration Options is indicated by the
+ length of the LCP packet.
+
+ Unless otherwise specified, each Configuration Option is not listed
+ more than once in a Configuration Options list. Some Configuration
+ Options MAY be listed more than once. The effect of this is
+ Configuration Option specific and is specified by each such
+ Configuration Option.
+
+ Also unless otherwise specified, all Configuration Options apply in a
+ half-duplex fashion. When negotiated, they apply to only one
+ direction of the link, typically in the receive direction when
+ interpreted from the point of view of the Configure-Request sender.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 42]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+7.1. Format
+
+ A summary of the Configuration Option format is shown below. The
+ fields are transmitted from left to right.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Data ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ The Type field is one octet and indicates the type of
+ Configuration Option. The most up-to-date values of the LCP
+ Option Type field are specified in the most recent "Assigned
+ Numbers" RFC [11]. Current values are assigned as follows:
+
+ 1 Maximum-Receive-Unit
+ 2 Async-Control-Character-Map
+ 3 Authentication-Protocol
+ 4 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 indicates the value or
+ other information for this Configuration Option. The format and
+ length of the Data field is determined by the Type and Length
+ fields.
+
+
+
+
+
+
+
+
+
+Simpson [Page 43]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+7.2. Maximum-Receive-Unit
+
+ Description
+
+ This Configuration Option may be sent to inform the peer that the
+ implementation can receive larger frames, or to request that the
+ peer send smaller frames. If smaller frames are requested, an
+ implementation MUST still be able to receive 1500 octet frames in
+ case link synchronization is lost.
+
+ A summary of the Maximum-Receive-Unit Configuration Option format is
+ shown below. The fields are transmitted from left to right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Maximum-Receive-Unit |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 1
+
+ Length
+
+ 4
+
+ Maximum-Receive-Unit
+
+ The Maximum-Receive-Unit field is two octets and indicates the new
+ maximum receive unit. The Maximum-Receive-Unit covers only the
+ Data Link Layer Information field. It does not include the
+ header, padding, FCS, nor any transparency bits or bytes.
+
+ Default
+
+ 1500
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 44]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+7.3. Async-Control-Character-Map
+
+ Description
+
+ This Configuration Option provides a way to negotiate the use of
+ control character mapping on asynchronous links. By default, PPP
+ maps all control characters into an appropriate two character
+ sequence. However, it is rarely necessary to map all control
+ characters and often it is unnecessary to map any characters. A
+ PPP implementation may use this Configuration Option to inform the
+ peer which control characters must remain mapped and which control
+ characters need not remain mapped when the peer sends them. The
+ peer may still send these control characters in mapped format if
+ it is necessary because of constraints at the peer.
+
+ There may be some use of synchronous-to-asynchronous converters
+ (some built into modems) in Point-to-Point links resulting in a
+ synchronous PPP implementation on one end of a link and an
+ asynchronous implementation on the other. It is the
+ responsibility of the converter to do all mapping conversions
+ during operation. To enable this functionality, synchronous PPP
+ implementations MUST always accept a Async-Control-Character-Map
+ Configuration Option (it MUST always respond to an LCP Configure-
+ Request specifying this Configuration Option with an LCP
+ Configure-Ack). However, acceptance of this Configuration Option
+ does not imply that the synchronous implementation will do any
+ character mapping, since synchronous PPP uses bit-stuffing rather
+ than character-stuffing. Instead, all such character mapping will
+ be performed by the asynchronous-to-synchronous converter.
+
+ A summary of the Async-Control-Character-Map Configuration Option
+ format is shown below. The fields are transmitted from left to
+ right.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Async-Control-Character-Map
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ACCM (cont) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 2
+
+
+
+
+
+
+Simpson [Page 45]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ Length
+
+ 6
+
+ Async-Control-Character-Map
+
+ The Async-Control-Character-Map field is four octets and indicates
+ the new async control character map. The map is encoded in big-
+ endian fashion where each numbered bit corresponds to the ASCII
+ control character of the same value. If the bit is cleared to
+ zero, then that ASCII control character need not be mapped. If
+ the bit is set to one, then that ASCII control character must
+ remain mapped. E.g., if bit 19 is set to zero, then the ASCII
+ control character 19 (DC3, Control-S) may be sent in the clear.
+
+ Note: The bit ordering of the map is as described in section
+ 3.1, Most Significant Bit to Least Significant Bit. 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.
+
+ Default
+
+ All ones (0xffffffff).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 46]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+7.4. Authentication-Protocol
+
+ Description
+
+ On some links it may be desirable to require a peer to
+ authenticate itself before allowing network-layer protocol packets
+ to be exchanged. This Configuration Option provides a way to
+ negotiate the use of a specific authentication protocol. By
+ default, authentication is not necessary.
+
+ An implementation SHOULD 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 Rejected, then the
+ implementation could attempt the next most desirable protocol in
+ the next Configure-Request.
+
+ An implementation receiving a Configure-Request specifying
+ Authentication-Protocols MAY choose at most one of the negotiable
+ authentication protocols and MUST send a Configure-Reject
+ including the other specified authentication protocols. The
+ implementation MAY reject all of the proposed authentication
+ protocols.
+
+ 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 ...
+ +-+-+-+-+
+
+
+
+
+
+
+Simpson [Page 47]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ Type
+
+ 3
+
+ Length
+
+ >= 4
+
+ Authentication-Protocol
+
+ The Authentication-Protocol field is two octets and indicates the
+ authentication protocol desired. Values for this field are always
+ the same as the PPP Data Link Layer Protocol field values for that
+ same authentication protocol.
+
+ The most up-to-date values of the Authentication-Protocol field
+ are specified in the most recent "Assigned Numbers" RFC [11].
+ Current values are assigned as follows:
+
+ Value (in hex) Protocol
+
+ c023 Password Authentication Protocol
+ c223 Challenge Handshake Authentication
+ Protocol
+
+ Data
+
+ The Data field is zero or more octets and contains additional data
+ as determined by the particular protocol.
+
+Default
+
+ No authentication protocol necessary.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 48]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+7.5. 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 way 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
+
+ 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 Data Link Layer Protocol field values
+ for that same monitoring protocol.
+
+ The most up-to-date values of the Quality-Protocol field are
+ specified in the most recent "Assigned Numbers" RFC [11]. Current
+ values are assigned as follows:
+
+
+
+
+Simpson [Page 49]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 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.
+
+ Default
+
+ None
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 50]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+7.6. Magic-Number
+
+ Description
+
+ This Configuration Option provides a way to detect looped-back
+ links and other Data Link Layer anomalies. This Configuration
+ Option MAY be required by some other Configuration Options such as
+ the Monitoring-Protocol Configuration Option.
+
+ Before this Configuration Option is requested, an implementation
+ must choose its Magic-Number. It is recommended that the Magic-
+ Number be chosen in the most random manner possible in order to
+ guarantee with very high probability that an implementation will
+ arrive at a unique number. A good way to choose a unique random
+ number is to start with an unique seed. Suggested sources of
+ uniqueness include machine serial numbers, other network hardware
+ addresses, time-of-day clocks, etc. Particularly good random
+ number seeds are precise measurements of the inter-arrival time of
+ physical events such as packet reception on other connected
+ networks, server response time, or the typing rate of a human
+ user. It is also suggested that as many sources as possible be
+ used simultaneously.
+
+ When a Configure-Request is received with a Magic-Number
+ Configuration Option, the received Magic-Number is compared with
+ the Magic-Number of the last Configure-Request sent to the peer.
+ If the two Magic-Numbers are different, then the link is not
+ looped-back, and the Magic-Number should be acknowledged. If the
+ two Magic-Numbers are equal, then it is possible, but not certain,
+ that the link is looped-back and that this Configure-Request is
+ actually the one last sent. To determine this, a Configure-Nak
+ should be sent specifying a different Magic-Number value. A new
+ Configure-Request should not be sent to the peer until normal
+ processing would cause it to be sent (i.e., until a Configure-Nak
+ is received or the Restart timer runs out).
+
+ Reception of a Configure-Nak with a Magic-Number different from
+ that of the last Configure-Nak sent to the peer proves that a link
+ is not looped-back, and indicates a unique Magic-Number. If the
+ Magic-Number is equal to the one sent in the last Configure-Nak,
+ the possibility of a looped-back link is increased, and a new
+ Magic-Number should be chosen. In either case, a new Configure-
+ Request should be sent with the new Magic-Number.
+
+ If the link is indeed looped-back, this sequence (transmit
+ Configure-Request, receive Configure-Request, transmit Configure-
+ Nak, receive Configure-Nak) will repeat over and over again. If
+ the link is not looped-back, this sequence might occur a few
+
+
+
+Simpson [Page 51]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ times, but it is extremely unlikely to occur repeatedly. More
+ likely, the Magic-Numbers chosen at either end will quickly
+ diverge, terminating the sequence. The following table shows the
+ probability of collisions assuming that both ends of the link
+ select Magic-Numbers with a perfectly uniform distribution:
+
+ Number of Collisions Probability
+ -------------------- ---------------------
+ 1 1/2**32 = 2.3 E-10
+ 2 1/2**32**2 = 5.4 E-20
+ 3 1/2**32**3 = 1.3 E-29
+
+ Good sources of uniqueness or randomness are required for this
+ divergence to occur. If a good source of uniqueness cannot be
+ found, it is recommended that this Configuration Option not be
+ enabled; Configure-Requests with the option SHOULD NOT be
+ transmitted and any Magic-Number Configuration Options which the
+ peer sends SHOULD be either acknowledged or rejected. In this
+ case, loop-backs cannot be reliably detected by the
+ implementation, although they may still be detectable by the peer.
+
+ If an implementation does transmit a Configure-Request with a
+ Magic-Number Configuration Option, then it MUST NOT respond with a
+ Configure-Reject if its peer also transmits a Configure-Request
+ with a Magic-Number Configuration Option. That is, if an
+ implementation desires to use Magic Numbers, then it MUST also
+ allow its peer to do so. If an implementation does receive a
+ Configure-Reject in response to a Configure-Request, it can only
+ mean that the link is not looped-back, and that its peer will not
+ be using Magic-Numbers. In this case, an implementation 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 which MUST normally be
+ zero, and MUST normally be ignored on reception. 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 one.
+
+ Reception of a Magic-Number field equal to the negotiated local
+
+
+
+Simpson [Page 52]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 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) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ 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.
+
+ Default
+
+ None.
+
+
+
+
+
+
+Simpson [Page 53]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+7.7. Protocol-Field-Compression
+
+ Description
+
+ This Configuration Option provides a way to negotiate the
+ compression of the Data Link Layer Protocol field. By default,
+ all implementations MUST transmit standard PPP frames with two
+ octet Protocol fields. However, PPP Protocol field numbers are
+ chosen such that some values may be compressed into a single octet
+ form which is clearly distinguishable from the two octet form.
+ This Configuration Option is sent to inform the peer that the
+ implementation can receive such single octet Protocol fields.
+ Compressed Protocol fields MUST NOT be transmitted unless this
+ Configuration Option has been negotiated.
+
+ As previously mentioned, the Protocol field uses an extension
+ mechanism consistent with the ISO 3309 extension mechanism for the
+ Address field; the Least Significant Bit (LSB) of each octet is
+ used to indicate extension of the Protocol field. A binary "0" as
+ the LSB indicates that the Protocol field continues with the
+ following octet. The presence of a binary "1" as the LSB marks
+ the last octet of the Protocol field. Notice that any number of
+ "0" octets may be prepended to the field, and will still indicate
+ the same value (consider the two representations for 3, 00000011
+ and 00000000 00000011).
+
+ In the interest of simplicity, the standard PPP frame uses this
+ fact and always sends Protocol fields with a two octet
+ representation. Protocol field values less than 256 (decimal) are
+ prepended with a single zero octet even though transmission of
+ this, the zero and most significant octet, is unnecessary.
+
+ However, when using low speed links, it is desirable to conserve
+ bandwidth by sending as little redundant data as possible. The
+ Protocol Compression Configuration Option allows a trade-off
+ between implementation simplicity and bandwidth efficiency. If
+ successfully negotiated, the ISO 3309 extension mechanism may be
+ used to compress the Protocol field to one octet instead of two.
+ The large majority of frames are compressible since data protocols
+ are typically assigned with Protocol field values less than 256.
+
+ In addition, PPP implementations must continue to be robust and
+ MUST accept PPP frames with either double-octet or single-octet
+ Protocol fields, and MUST NOT distinguish between them.
+
+ The Protocol field is never compressed when sending any LCP
+ packet. This rule guarantees unambiguous recognition of LCP
+ packets.
+
+
+
+Simpson [Page 54]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ When a Protocol field is compressed, the Data Link Layer FCS field
+ is calculated on the compressed frame, not the original
+ uncompressed frame.
+
+ A summary of the Protocol-Field-Compression Configuration Option
+ format is shown below. The fields are transmitted from left to
+ right.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Type
+
+ 7
+
+ Length
+
+ 2
+
+ Default
+
+ Disabled.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 55]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+7.8. Address-and-Control-Field-Compression
+
+ Description
+
+ This Configuration Option provides a way to negotiate the
+ compression of the Data Link Layer Address and Control fields. By
+ default, all implementations MUST transmit frames with Address and
+ Control fields and MUST use the hexadecimal values 0xff and 0x03
+ respectively. Since these fields have constant values, they are
+ easily compressed. This Configuration Option is sent to inform
+ the peer that the implementation can receive compressed Address
+ and Control fields.
+
+ Compressed Address and Control fields are formed by simply
+ omitting them. By definition the first octet of a two octet
+ Protocol field will never be 0xff, and the Protocol field value
+ 0x00ff is not allowed (reserved) to avoid ambiguity.
+
+ On reception, the Address and Control fields are decompressed by
+ examining the first two octets. If they contain the values 0xff
+ and 0x03, they are assumed to be the Address and Control fields.
+ If not, it is assumed that the fields were compressed and were not
+ transmitted.
+
+ If a compressed frame is received when Address-and-Control-Field-
+ Compression has not been negotiated, the implementation MAY
+ silently discard the frame.
+
+ The Address and Control fields MUST NOT be compressed when sending
+ any LCP packet. This rule guarantees unambiguous recognition of
+ LCP packets.
+
+ When the Address and Control fields are compressed, the Data Link
+ Layer FCS field is calculated on the compressed frame, not the
+ original uncompressed frame.
+
+ A summary of the Address-and-Control-Field-Compression configuration
+ option format is shown below. The fields are transmitted from left
+ to right.
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+Simpson [Page 56]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ Type
+
+ 8
+
+ Length
+
+ 2
+
+ Default
+
+ Not compressed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 57]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+A. Asynchronous HDLC
+
+ This appendix summarizes the modifications to ISO 3309-1979 proposed
+ in ISO 3309:1984/PDAD1, as applied in the Point-to-Point Protocol.
+ These modifications allow HDLC to be used with 8-bit asynchronous
+ links.
+
+ Transmission Considerations
+
+ All octets are transmitted with one start bit, eight bits of data,
+ and one stop bit. There is no provision in either PPP or ISO
+ 3309:1984/PDAD1 for seven bit asynchronous links.
+
+ Flag Sequence
+
+ The Flag Sequence is a single octet and indicates the beginning or
+ end of a frame. The Flag Sequence consists of the binary sequence
+ 01111110 (hexadecimal 0x7e).
+
+ Transparency
+
+ On asynchronous links, a character stuffing procedure is used.
+ The Control Escape octet is defined as binary 01111101
+ (hexadecimal 0x7d) where the bit positions are numbered 87654321
+ (not 76543210, BEWARE).
+
+ After FCS computation, the transmitter examines the entire frame
+ between the two Flag Sequences. Each Flag Sequence, Control
+ Escape octet and octet with value less than hexadecimal 0x20 which
+ is flagged in the Remote Async-Control-Character-Map is replaced
+ by a two octet sequence consisting of the Control Escape octet and
+ the original octet with bit 6 complemented (i.e., exclusive-or'd
+ with hexadecimal 0x20).
+
+ Prior to FCS computation, the receiver examines the entire frame
+ between the two Flag Sequences. Each octet with value less than
+ hexadecimal 0x20 is checked. If it is flagged in the Local
+ Async-Control-Character-Map, it is simply removed (it may have
+ been inserted by intervening data communications equipment). For
+ each Control Escape octet, that octet is also removed, but bit 6
+ of the following octet is complemented. A Control Escape octet
+ immediately preceding the closing Flag Sequence indicates an
+ invalid frame.
+
+ Note: The inclusion of all octets less than hexadecimal 0x20
+ allows all ASCII control characters [10] excluding DEL (Delete)
+ to be transparently communicated through almost all known data
+ communications equipment.
+
+
+
+Simpson [Page 58]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ The transmitter may also send octets with value in the range 0x40
+ through 0xff (except 0x5e) in Control Escape format. Since these
+ octet values are not negotiable, this does not solve the problem
+ of receivers which cannot handle all non-control characters.
+ Also, since the technique does not affect the 8th bit, this does
+ not solve problems for communications links that can send only 7-
+ bit characters.
+
+ A few examples may make this more clear. Packet data is
+ transmitted on the link as follows:
+
+ 0x7e is encoded as 0x7d, 0x5e.
+ 0x7d is encoded as 0x7d, 0x5d.
+ 0x01 is encoded as 0x7d, 0x21.
+
+ Some modems with software flow control may intercept outgoing DC1
+ and DC3 ignoring the 8th (parity) bit. This data would be
+ transmitted on the link as follows:
+
+ 0x11 is encoded as 0x7d, 0x31.
+ 0x13 is encoded as 0x7d, 0x33.
+ 0x91 is encoded as 0x7d, 0xb1.
+ 0x93 is encoded as 0x7d, 0xb3.
+
+ Aborting a Transmission
+
+ On asynchronous links, frames may be aborted by transmitting a "0"
+ stop bit where a "1" bit is expected (framing error) or by
+ transmitting a Control Escape octet followed immediately by a
+ closing Flag Sequence.
+
+ Time Fill
+
+ On asynchronous links, inter-octet and inter-frame time fill MUST
+ be accomplished by transmitting continuous "1" bits (mark-hold
+ state).
+
+ Note: On asynchronous links, inter-frame time fill can be
+ viewed as extended inter-octet time fill. Doing so can save
+ one octet for every frame, decreasing delay and increasing
+ bandwidth. This is possible since a Flag Sequence may serve as
+ both a frame close and a frame begin. After having received
+ any frame, an idle receiver will always be in a frame begin
+ state.
+
+ Robust transmitters should avoid using this trick over-
+ zealously since the price for decreased delay is decreased
+ reliability. Noisy links may cause the receiver to receive
+
+
+
+Simpson [Page 59]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ garbage characters and interpret them as part of an incoming
+ frame. If the transmitter does not transmit a new opening Flag
+ Sequence before sending the next frame, then that frame will be
+ appended to the noise characters causing an invalid frame (with
+ high reliability). Transmitters should avoid this by
+ transmitting an open Flag Sequence whenever "appreciable time"
+ has elapsed since the prior closing Flag Sequence. It is
+ suggested that implementations will achieve the best results by
+ always sending an opening Flag Sequence if the new frame is not
+ back-to-back with the last. The maximum value for "appreciable
+ time" is likely to be no greater than the typing rate of a slow
+ to average typist, say 1 second.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 60]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+B. Fast Frame Check Sequence (FCS) Implementation
+
+B.1. FCS Computation Method
+
+ The following code provides a table lookup computation for
+ calculating the Frame Check Sequence as data arrives at the
+ interface. This implementation is based on [7], [8], and [9]. The
+ table is created by the code in section B.2.
+
+ /*
+ * u16 represents an unsigned 16-bit number. Adjust the typedef for
+ * your hardware.
+ */
+ typedef unsigned short u16;
+
+
+ /*
+ * FCS lookup table as calculated by the table generator in section
+ * B.2.
+ */
+ static u16 fcstab[256] = {
+ 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf,
+ 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7,
+ 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e,
+ 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876,
+ 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd,
+ 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5,
+ 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c,
+ 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974,
+ 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb,
+ 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3,
+ 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a,
+ 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72,
+ 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9,
+ 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1,
+ 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738,
+ 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70,
+ 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7,
+ 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff,
+ 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036,
+ 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e,
+ 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5,
+ 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd,
+ 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134,
+ 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c,
+ 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3,
+ 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb,
+ 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232,
+
+
+
+Simpson [Page 61]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a,
+ 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1,
+ 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9,
+ 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330,
+ 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78
+ };
+
+ #define PPPINITFCS 0xffff /* Initial FCS value */
+ #define PPPGOODFCS 0xf0b8 /* Good final FCS value */
+
+ /*
+ * Calculate a new fcs given the current fcs and the new data.
+ */
+ u16 pppfcs(fcs, cp, len)
+ register u16 fcs;
+ register unsigned char *cp;
+ register int len;
+ {
+ ASSERT(sizeof (u16) == 2);
+ ASSERT(((u16) -1) > 0);
+ while (len--)
+ fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff];
+
+ return (fcs);
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 62]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+B.2. Fast FCS table generator
+
+ The following code creates the lookup table used to calculate the
+ FCS.
+
+ /*
+ * Generate a FCS table for the HDLC FCS.
+ *
+ * Drew D. Perkins at Carnegie Mellon University.
+ *
+ * Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier.
+ */
+
+ /*
+ * The HDLC polynomial: x**0 + x**5 + x**12 + x**16 (0x8408).
+ */
+ #define P 0x8408
+
+
+ main()
+ {
+ register unsigned int b, v;
+ register int i;
+
+ printf("typedef unsigned short u16;\n");
+ printf("static u16 fcstab[256] = {");
+ for (b = 0; ; ) {
+ if (b % 8 == 0)
+ printf("\n");
+
+ v = b;
+ for (i = 8; i--; )
+ v = v & 1 ? (v >> 1) ^ P : v >> 1;
+
+ printf("0x%04x", v & 0xFFFF);
+ if (++b == 256)
+ break;
+ printf(",");
+ }
+ printf("\n};\n");
+ }
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 63]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+C. 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson [Page 64]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+Security Considerations
+
+ Security issues are briefly discussed in sections concerning the
+ Authentication Phase, and the Authentication-Protocol Configuration
+ Option. Further discussion is planned in a separate document
+ entitled PPP Authentication Protocols.
+
+References
+
+ [1] Electronic Industries Association, EIA Standard RS-232-C,
+ "Interface Between Data Terminal Equipment and Data
+ Communications Equipment Employing Serial Binary Data
+ Interchange", August 1969.
+
+ [2] International Organization For Standardization, ISO Standard
+ 3309-1979, "Data communication - High-level data link control
+ procedures - Frame structure", 1979.
+
+ [3] International Organization For Standardization, ISO Standard
+ 4335-1979, "Data communication - High-level data link control
+ procedures - Elements of procedures", 1979.
+
+ [4] International Organization For Standardization, ISO Standard
+ 4335-1979/Addendum 1, "Data communication - High-level data
+ link control procedures - Elements of procedures - Addendum 1",
+ 1979.
+
+ [5] International Organization For Standardization, Proposed Draft
+ International Standard ISO 3309:1983/PDAD1, "Information
+ processing systems - Data communication - High-level data link
+ control procedures - Frame structure - Addendum 1: Start/stop
+ transmission", 1984.
+
+ [6] International Telecommunication Union, CCITT Recommendation
+ X.25, "Interface Between Data Terminal Equipment (DTE) and Data
+ Circuit Terminating Equipment (DCE) for Terminals Operating in
+ the Packet Mode on Public Data Networks", CCITT Red Book,
+ Volume VIII, Fascicle VIII.3, Rec. X.25., October 1984.
+
+ [7] Perez, "Byte-wise CRC Calculations", IEEE Micro, June, 1983.
+
+ [8] Morse, G., "Calculating CRC's by Bits and Bytes", Byte,
+ September 1986.
+
+ [9] LeVan, J., "A Fast CRC", Byte, November 1987.
+
+ [10] American National Standards Institute, ANSI X3.4-1977,
+ "American National Standard Code for Information Interchange",
+
+
+
+Simpson [Page 65]
+
+RFC 1331 Point-to-Point Protocol May 1992
+
+
+ 1977.
+
+ [11] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
+ USC/Information Sciences Institute, March 1990.
+
+Acknowledgments
+
+ Much of the text in this document is taken from the WG Requirements
+ (unpublished), 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 (NSC), Karl Fox (Morning Star Technologies), Phill Gross (NRI),
+ former WG chair Russ Hobby (UC Davis), David Kaufman (Proteon),
+ former WG chair Steve Knowles (FTP Software), John LoVerso
+ (Xylogics), Bill Melohn (Sun Microsystems), Mike Patton (MIT), former
+ WG chair Drew Perkins (CMU), Greg Satz (cisco systems) and Asher
+ Waldfogel (Wellfleet).
+
+Chair's Address
+
+ The working group can be contacted via the current chair:
+
+ Brian Lloyd
+ Lloyd & Associates
+ 3420 Sudbury Road
+ Cameron Park, California 95682
+
+ Phone: (916) 676-1147
+
+ EMail: brian@ray.lloyd.com
+
+
+Author's Address
+
+ Questions about this memo can also be directed to:
+
+ William Allen Simpson
+ Daydreamer
+ Computer Systems Consulting Services
+ P O Box 6205
+ East Lansing, MI 48826-6025
+
+ EMail: bsimpson@ray.lloyd.com
+
+
+
+Simpson [Page 66]
+