As per Relevance of the word indicate, we have this rfc below:
Network Working Group W.
Request for Comments: 1331
Obsoletes: RFCs 1171, 1172 May 1992
The Point-to-Point Protocol (PPP
for
Transmission of Multi-protocol
over Point-to-Point
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
The Point-to-Point Protocol (PPP) provides a method for
datagrams over serial point-to-point links. PPP is comprised
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
and configuring different network-layer protocols
This document defines the PPP encapsulation scheme, together with
PPP Link Control Protocol (LCP), an extensible option
protocol which is able to negotiate a rich assortment
configuration parameters and provides additional
functions
This RFC is a product of the Point-to-Point Protocol Working Group
the Internet Engineering Task Force (IETF). Comments on this
should be submitted to the ietf-ppp@ucdavis.edu mailing list
Simpson [Page i
RFC 1331 Point-to-Point Protocol May 1992
Table of
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.
In the last few years, the Internet has seen explosive growth
the number of hosts supporting TCP/IP. The vast majority of
hosts are connected to Local Area Networks (LANs) of
types, Ethernet being the most common. Most of the other
are connected through Wide Area Networks (WANs) such as X.25
Public Data Networks (PDNs). Relatively few of these hosts
connected with simple point-to-point (i.e., serial) links. Yet
point-to-point links are among the oldest methods of
communications and almost every host supports point-to-
connections. For example, asynchronous RS-232-C [1]
are essentially ubiquitous
One reason for the small number of point-to-point IP links is
lack of a standard encapsulation protocol. There are plenty
non-standard (and at least one de facto standard)
protocols available, but there is not one which has been
upon as an Internet Standard. By contrast, standard
schemes do exist for the transmission of datagrams over
popular LANs
PPP provides an encapsulation protocol over both bit-
synchronous links and asynchronous links with 8 bits of data
no parity. These links MUST be full-duplex, but MAY be
dedicated or circuit-switched. PPP uses HDLC as a basis for
encapsulation
PPP has been carefully designed to retain compatibility with
commonly used supporting hardware. In addition, an
mechanism is specified to allow control data such as XON/XOFF
be transmitted transparently over the link, and to remove
control data which may be injected into the link by
hardware and software
The PPP encapsulation also provides for multiplexing of
network-layer protocols simultaneously over the same link. It
intended that PPP provide a common solution for easy connection
a wide variety of hosts, bridges and routers
Some protocols expect error free transmission, and either
error detection only on a conditional basis, or do not provide
at all. PPP uses the HDLC Frame Check Sequence for
detection. This is commonly available in
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
encapsulation. In environments where bandwidth is at a premium
the encapsulation may be shortened to as few as 2 octets.
support high speed hardware implementations, PPP provides that
default encapsulation header and information fields fall on 32-
boundaries, and allows the trailer to be padded to an
boundary
Link Control
More importantly, the Point-to-Point Protocol defines more
just an encapsulation scheme. In order to be
versatile to be portable to a wide variety of environments,
provides a Link Control Protocol (LCP). The LCP is used
automatically agree upon the encapsulation format options,
varying limits on sizes of packets, authenticate the identity
its peer on the link, determine when a link is
properly and when it is defunct, detect a looped-back link
other common misconfiguration errors, and terminate the link
Network Control
Point-to-Point links tend to exacerbate many problems with
current family of network protocols. For instance, assignment
management of IP addresses, which is a problem even in
environments, is especially difficult over circuit-
point-to-point links (such as dial-up modem servers).
problems are handled by a family of Network Control
(NCPs), which each manage the specific needs required by
respective network-layer protocols. These NCPs are defined
other documents
It is intended that PPP be easy to configure. By design,
standard defaults should handle all common configurations.
implementor may specify improvements to the default configuration
which are automatically communicated to the peer without
intervention. Finally, the operator may explicitly
options for the link which enable the link to operate
environments where it would otherwise be impossible
This self-configuration is implemented through an
option negotiation mechanism, wherein each end of the
describes to the other its capabilities and requirements
Although the option negotiation mechanism described in
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
Protocol (IPCP) and others in the family of NCPs
1.1. Specification of
In this document, several words are used to signify the
of the specification. These words are often capitalized
This word, or the adjective "required", means that the
is an absolute requirement of the specification
MUST
This phrase means that the definition is an absolute
of the specification
This word, or the adjective "recommended", means that there
exist valid reasons in particular circumstances to ignore
item, but the full implications should be understood and
weighed before choosing a different course
This word, or the adjective "optional", means that this item
one of an allowed set of alternatives. An implementation
does not include this option MUST be prepared to interoperate
another implementation which does include the option
1.2.
This document frequently uses the following terms
The other end of the point-to-point link
silently
This means the implementation discards the packet without
processing. The implementation SHOULD provide the capability
logging the error, including the contents of the
discarded packet, and SHOULD record the event in a
counter
Simpson [Page 3]
RFC 1331 Point-to-Point Protocol May 1992
2. Physical Layer
The Point-to-Point Protocol is capable of operating across
DTE/DCE interface (e.g., EIA RS-232-C, EIA RS-422, EIA RS-423
CCITT V.35). The only absolute requirement imposed by PPP is
provision of a full-duplex circuit, either dedicated or circuit
switched, which can operate in either an asynchronous (start/stop)
synchronous bit-serial mode, transparent to PPP Data Link
frames. PPP does not impose any restrictions regarding
rate, other than those imposed by the particular DTE/DCE interface
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
recommended as a default. When configuration of the encoding
allowed, NRZI is recommended as an alternative, because of
relative immunity to signal inversion configuration errors
PPP does not require the use of modem control signals, such
Request To Send (RTS), Clear To Send (CTS), Data Carrier
(DCD), and Data Terminal Ready (DTR).
Implementation Note
When available, using such signals can allow greater
and performance. In particular, such signals SHOULD be used
signal the Up and Down events in the Option Negotiation
(described below).
Simpson [Page 4]
RFC 1331 Point-to-Point Protocol May 1992
3. The Data Link
The Point-to-Point Protocol uses the principles, terminology,
frame structure of the International Organization
Standardization's (ISO) High-level Data Link Control (HDLC
procedures (ISO 3309-1979 [2]), as modified by ISO 3309:1984/PDAD
"Addendum 1: Start/stop transmission" [5]. ISO 3309-1979
the HDLC frame structure for use in synchronous environments.
3309:1984/PDAD1 specifies proposed modifications to ISO 3309-1979
allow its use in asynchronous environments
The PPP control procedures use the definitions and Control
encodings standardized in ISO 4335-1979 [3] and ISO 4335-
1979/Addendum 1-1979 [4]. The PPP frame structure is also
with CCITT Recommendation X.25 LAPB [6], since that too is based
HDLC
The purpose of this memo is not to document what is
standardized in ISO 3309. We assume that the reader is
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
options and features used by PPP. Since "Addendum 1: Start/
transmission", is not yet standardized and widely available, it
summarized in Appendix A
To remain consistent with standard Internet practice, and
confusion for people used to reading RFCs, all binary numbers in
following descriptions are in Most Significant Bit to
Significant Bit order, reading from left to right, unless
indicated. Note that this is contrary to standard ISO and
practice which orders bits as transmitted (i.e., network bit order).
Keep this in mind when comparing this document with the
standards documents
Simpson [Page 5]
RFC 1331 Point-to-Point Protocol May 1992
3.1. Frame
A summary of the standard PPP frame structure is shown below.
figure does not include start/stop bits (for asynchronous links),
any bits or octets inserted for transparency. The fields
transmitted from left to right
+----------+----------+----------+----------+------------
| Flag | Address | Control | Protocol |
| 01111110 | 11111111 | 00000011 | 16 bits | *
+----------+----------+----------+----------+------------
---+----------+----------+-----------------
| FCS | Flag | Inter-frame
| 16 bits | 01111110 | or next
---+----------+----------+-----------------
Inter-frame Time
For asynchronous links, inter-frame time fill SHOULD be
in the same manner as inter-octet time fill, by
continuous "1" bits (mark-hold state).
For synchronous links, the Flag Sequence SHOULD be transmitted
inter-frame time fill. There is no provision for inter-octet
fill
Implementation Note
Mark idle (continuous ones) SHOULD NOT be used for
synchronous inter-frame time fill. However, certain types
circuit-switched links require the use of mark idle,
those that calculate accounting based on bit activity. When
idle is used on a synchronous link, the implementation MUST
at least 15 consecutive "1" bits between Flags, and that the
Sequence is generated at the beginning and end of a frame
Flag
The Flag Sequence is a single octet and indicates the beginning
end of a frame. The Flag Sequence consists of the binary
01111110 (hexadecimal 0x7e).
The Flag is a frame separator. Only one Flag is required between
frames. Two consecutive Flags constitute an empty frame, which
ignored
Simpson [Page 6]
RFC 1331 Point-to-Point Protocol May 1992
Implementation Note
The "shared zero mode" Flag Sequence "011111101111110" SHOULD
be used. When not avoidable, such an implementation MUST
that the first Flag Sequence detected (the end of the frame)
promptly communicated to the link layer
Address
The Address field is a single octet and contains the binary
11111111 (hexadecimal 0xff), the All-Stations address. PPP does
assign individual station addresses. The All-Stations address
always be recognized and received. The use of other address
and values may be defined at a later time, or by prior agreement
Frames with unrecognized Addresses SHOULD be silently discarded,
reported through the normal network management facility
Control
The Control field is a single octet and contains the binary
00000011 (hexadecimal 0x03), the Unnumbered Information (UI)
with the P/F bit set to zero. Frames with other Control field
SHOULD be silently discarded
Protocol
The Protocol field is two octets and its value identifies
protocol encapsulated in the Information field of the frame
This Protocol field is defined by PPP and is not a field defined
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
"1". Also, all Protocols MUST be assigned such that the
significant bit of the most significant octet equals "0".
received which don't comply with these rules MUST be considered
having an unrecognized Protocol, and handled as specified by the LCP
The Protocol field is transmitted and received most significant
first
Protocol field values in the "0---" to "3---" range identify
network-layer protocol of specific datagrams, and values in the "8--
-" to "b---" range identify datagrams belonging to the
Network Control Protocols (NCPs), if any
Protocol field values in the "4---" to "7---" range are used
protocols with low volume traffic which have no associated NCP
Protocol field values in the "c---" to "f---" range
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
most recent "Assigned Numbers" RFC [11]. Current values are
as follows
Value (in hex) Protocol
0001 to 001f reserved (transparency inefficient
0021 Internet
0023 OSI Network
0025 Xerox NS
0027 DECnet Phase
0029
002b Novell
002d Van Jacobson Compressed TCP/
002f Van Jacobson Uncompressed TCP/
0031 Bridging
0033 Stream Protocol (ST-II
0035 Banyan
0037 reserved (until 1993)
00ff reserved (compression inefficient
0201 802.1d Hello
0231
0233 Sigma Network
8021 Internet Protocol Control
8023 OSI Network Layer Control
8025 Xerox NS IDP Control
8027 DECnet Phase IV Control
8029 Appletalk Control
802b Novell IPX Control
802d
802f
8031 Bridging
8033 Stream Protocol Control
8035 Banyan Vines Control
c021 Link Control
c023 Password Authentication
c025 Link Quality
c223 Challenge Handshake Authentication
Developers of new protocols MUST obtain a number from the
Assigned Numbers Authority (IANA), at IANA@isi.edu
Simpson [Page 8]
RFC 1331 Point-to-Point Protocol May 1992
Information
The Information field is zero or more octets. The Information
contains the datagram for the protocol specified in the
field. The end of the Information field is found by locating
closing Flag Sequence and allowing two octets for the Frame
Sequence field. The default maximum length of the Information
is 1500 octets. By negotiation, consenting PPP implementations
use other values for the maximum Information field length
On transmission, the Information field may be padded with
arbitrary number of octets up to the maximum length. It is
responsibility of each protocol to disambiguate padding octets
real information
Frame Check Sequence (FCS)
The Frame Check Sequence field is normally 16 bits (two octets).
use of other FCS lengths may be defined at a later time, or by
agreement
The FCS field is calculated over all bits of the Address, Control
Protocol and Information fields not including any start and stop
(asynchronous) and any bits (synchronous) or octets (asynchronous
inserted for transparency. This does not include the Flag
or the FCS field itself. The FCS is transmitted with the
of the highest term first
Note: When octets are received which are flagged in the Async
Control-Character-Map, they are discarded before calculating
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
algorithm is shown in Appendix B. This implementation is based
[7], [8], and [9].
Modifications to the Basic Frame
The Link Control Protocol can negotiate modifications to the
PPP frame structure. However, modified frames will always be
distinguishable from standard frames
Simpson [Page 9]
RFC 1331 Point-to-Point Protocol May 1992
4. PPP Link
4.1.
In order to establish communications over a point-to-point link,
end of the PPP link must first send LCP packets to configure and
the data link. After the link has been established, the peer may
authenticated. Then, PPP must send NCP packets to choose
configure one or more network-layer protocols. Once each of
chosen network-layer protocols has been configured, datagrams
each network-layer protocol can be sent over the link
The link will remain configured for communications until explicit
or NCP packets close the link down, or until some external
occurs (an inactivity timer expires or network
intervention).
4.2. Phase
In the process of configuring, maintaining and terminating
point-to-point link, the PPP link goes through several
phases
+------+ +-----------+ +--------------+
| | UP | | OPENED | | SUCCESS/
| 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
external event (such as carrier detection or network
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
Initial or Starting states. The transition to the Link
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
the disconnection of a modem. In the case of a hard-wired line
this phase may be extremely short -- merely long enough to
the presence of the device
4.4. Link Establishment
The Link Control Protocol (LCP) is used to establish the
through an exchange of Configure packets. This exchange is complete
and the LCP Opened state entered, once a Configure-Ack
(described below) has been both sent and received. Any non-
packets received during this phase MUST be silently discarded
All Configuration Options are assumed to be at default values
altered by the configuration exchange. See the section on
Configuration Options for further discussion
It is important to note that only Configuration Options which
independent of particular network-layer protocols are configured
LCP. Configuration of individual network-layer protocols is
by separate Network Control Protocols (NCPs) during the Network-
Protocol phase
4.5. Authentication
On some links it may be desirable to require a peer to
itself before allowing network-layer protocol packets to
exchanged
By default, authentication is not necessary. If an
requires that the peer authenticate with some specific
protocol, then it MUST negotiate the use of that
protocol during Link Establishment phase
Authentication SHOULD take place as soon as possible after
establishment. However, link quality determination MAY
concurrently. An implementation MUST NOT allow the exchange of
quality determination packets to delay authentication indefinitely
Advancement from the Authentication phase to the Network-
Protocol phase MUST NOT occur until the peer is
authenticated using the negotiated authentication protocol. In
event of failure to authenticate, PPP SHOULD proceed instead to
Link Termination phase
Simpson [Page 11]
RFC 1331 Point-to-Point Protocol May 1992
4.6. Network-Layer Protocol
Once PPP has finished the previous phases, each network-
protocol (such as IP) MUST be separately configured by
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
of time for link quality determination, implementations
avoid fixed timeouts when waiting for their peers to configure
NCP
After a NCP has reached the Opened state, PPP will carry
corresponding network-layer protocol packets. Any network-
protocol packets received when the corresponding NCP is not in
Opened state SHOULD be silently discarded
During this phase, link traffic consists of any possible
of LCP, NCP, and network-layer protocol packets. Any NCP
network-layer protocol packets received during any other phase
be silently discarded
Implementation Note
There is an exception to the preceding paragraphs, due to
availability of the LCP Protocol-Reject (described below).
LCP is in the Opened state, any protocol packet which
unsupported by the implementation MUST be returned in a Protocol
Reject. Only supported protocols are silently discarded
4.7. Link Termination
PPP may terminate the link at any time. This will usually be done
the request of a human user, but might happen because of a
event such as the loss of carrier, authentication failure,
quality failure, or the expiration of an idle-period timer
LCP is used to close the link through an exchange of
packets. When the link is closing, PPP informs the network-
protocols so that they may take appropriate action
After the exchange of Terminate packets, the implementation
signal the physical-layer to disconnect in order to enforce
termination of the link, particularly in the case of
authentication failure. The sender of the Terminate-Request
Simpson [Page 12]
RFC 1331 Point-to-Point Protocol May 1992
disconnect after receiving a Terminate-Ack, or after the
counter expires. The receiver of a Terminate-Request SHOULD wait
the peer to disconnect, and MUST NOT disconnect until at least
Restart time has passed after sending a Terminate-Ack. PPP
proceed to the Link Dead phase
Implementation Note
The closing of the link by LCP is sufficient. There is no
for each NCP to send a flurry of Terminate packets. Conversely
the fact that a NCP has Closed is not sufficient reason to
the termination of the PPP link, even if that NCP was the
currently NCP in the Opened state
Simpson [Page 13]
RFC 1331 Point-to-Point Protocol May 1992
5. The Option Negotiation
The finite-state automaton is defined by events, actions and
transitions. Events include reception of external commands such
Open and Close, expiration of the Restart timer, and reception
packets from a peer. Actions include the starting of the
timer and transmission of packets to the peer
Some types of packets -- Configure-Naks and Configure-Rejects,
Code-Rejects and Protocol-Rejects, or Echo-Requests, Echo-Replies
Discard-Requests -- are not differentiated in the
descriptions. As will be described later, these packets do
serve different functions. However, they always cause the
transitions
Events
Up = lower layer is Up tlu = This-Layer-
Down = lower layer is Down tld = This-Layer-
Open = administrative Open tls = This-Layer-
Close= administrative Close tlf = This-Layer-
TO+ = Timeout with counter > 0 irc = initialize
TO- = Timeout with counter expired zrc = zero restart
RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-
RCR- = Receive-Configure-Request (Bad
RCA = Receive-Configure-Ack sca = Send-Configure-
RCN = Receive-Configure-Nak/Rej scn = Send-Configure-Nak/
RTR = Receive-Terminate-Request str = Send-Terminate-
RTA = Receive-Terminate-Ack sta = Send-Terminate-
RUC = Receive-Unknown-Code scj = Send-Code-
RXJ+ = Receive-Code-Reject (permitted
or Receive-Protocol-
RXJ- = Receive-Code-Reject (catastrophic
or Receive-Protocol-
RXR = Receive-Echo-Request ser = Send-Echo-
or Receive-Echo-
or Receive-Discard-
- = illegal
Simpson [Page 14]
RFC 1331 Point-to-Point Protocol May 1992
5.1. State
The simplified state diagram which follows describes the sequence
events for reaching agreement on Configuration Options (opening
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
transition table
Events are in upper case. Actions are in lower case. For
purposes, the state machine is initially in the Closed state.
the Opened state has been reached, both ends of the link have met
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
The complete state transition table follows. States are
horizontally, and events are read vertically. State transitions
actions are represented in the form action/new-state.
actions are separated by commas, and may continue on succeeding
as space requires. The state may be followed by a letter,
indicates an explanatory footnote
Rationale
In previous versions of this table, a simplified non-
finite-state automaton was used, with considerable
information specified in the semantics. This lead
interoperability problems from differing interpretations
This table functions similarly to the previous versions, with
up/down flags expanded to explicit states, and the active/
paradigm eliminated. It is believed that this table
with previous versions better than those versions themselves
|
| 0 1 2 3 4 5
Events| Initial Starting Closed Stopped Closing
------+-----------------------------------------------------------
Up | 2 irc,scr/6 - - - -
Down | - - 0 tls/1 0 1
Open | tls/1 1 irc,scr/6 3r 5r 5
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
|
| 6 7 8 9
Events| Req-Sent Ack-Rcvd Ack-Sent
------+-----------------------------------------
Up | - - - -
Down | 1 1 1 tld/1
Open | 6 7 8 9
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/6
RCN |irc,scr/6 scr/6x irc,scr/8 tld,scr/6
|
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
the presence of TO events. Only the Send-Configure-Request, Send
Terminate-Request and Zero-Restart-Counter actions start or re-
the Restart timer. The Restart timer SHOULD be stopped
transitioning from any state where the timer is running to a
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.
Following is a more detailed description of each automaton state
In the Initial state, the lower layer is unavailable (Down),
no Open has occurred. The Restart timer is not running in
Initial state
The Starting state is the Open counterpart to the Initial state
An administrative Open has been initiated, but the lower layer
still unavailable (Down). The Restart timer is not running in
Starting state
When the lower layer becomes available (Up), a Configure-
is sent
In the Closed state, the link is available (Up), but no Open
occurred. The Restart timer is not running in the Closed state
Upon reception of Configure-Request packets, a Terminate-Ack
sent. Terminate-Acks are silently discarded to avoid creating
loop
The Stopped state is the Open counterpart to the Closed state.
is entered when the automaton is waiting for a Down event
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
response is sent. Upon reception of other packets, a Terminate
Ack is sent. Terminate-Acks are silently discarded to
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 (
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
Down event, the Down event will supercede by returning
automaton to the Starting state. This prevents attack
repetition
Implementation Option
After the peer fails to respond to Configure-Requests,
implementation MAY wait passively for the peer to
Configure-Requests. In this case, the This-Layer-
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
have no status signals available, but SHOULD NOT be used
switched circuits
In the Closing state, an attempt is made to terminate
connection. A Terminate-Request has been sent and the
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-
is transmitted and the Restart timer is restarted. After
Restart timer has expired Max-Terminate times, this action may
skipped, and the Closed state may be entered
The Stopping state is the Open counterpart to the Closing state
A Terminate-Request has been sent and the Restart timer
running, but a Terminate-Ack has not yet been received
Rationale
The Stopping state provides a well defined opportunity
terminate a link before allowing new traffic. After the
has terminated, a new configuration may occur via the
or Starting states
Request-
In the Request-Sent state an attempt is made to configure
connection. A Configure-Request has been sent and the
timer is running, but a Configure-Ack has not yet been
Simpson [Page 19]
RFC 1331 Point-to-Point Protocol May 1992
nor has one been sent
Ack-
In the Ack-Received state, a Configure-Request has been sent and
Configure-Ack has been received. The Restart timer is
running since a Configure-Ack has not yet been sent
Ack-
In the Ack-Sent state, a Configure-Request and a Configure-
have both been sent but a Configure-Ack has not yet been received
The Restart timer is always running in the Ack-Sent state
In the Opened state, a Configure-Ack has been both sent
received. The Restart timer is not running in the Opened state
When entering the Opened state, the implementation SHOULD
the upper layers that it is now Up. Conversely, when leaving
Opened state, the implementation SHOULD signal the upper
that it is now Down
5.4.
Transitions and actions in the automaton are caused by events
The Up event occurs when a lower layer indicates that it is
to carry packets. Typically, this event is used to signal
that the link is entering Link Establishment phase, or used
signal a NCP that the link is entering Network-Layer
phase
The Down event occurs when a lower layer indicates that it is
longer ready to carry packets. Typically, this event is used
signal LCP that the link is entering Link Dead phase, or used
signal a NCP that the link is leaving Network-Layer
phase
The Open event indicates that the link is
available for traffic; that is, the network administrator (
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
layer is Down, or a previous Close event has not completed),
establishment of the link is automatically delayed
When a Terminate-Request is received, or other events occur
cause the link to become unavailable, the automaton will
to a state where the link is ready to re-open. No
administrative intervention should be necessary
Implementation Note
Experience has shown that users will execute an additional
command when they want to renegotiate the link. Since this
not the meaning of the Open event, it is suggested that when
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
renegotiation of the link, without any harmful side effects
The Close event indicates that the link is not available
traffic; that is, the network administrator (human or program)
indicated that the link is not allowed to be Opened. When
event occurs, and the link is not in the Closed state,
automaton attempts to terminate the connection. Futher
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.
Restart timer is used to time responses to Configure-Request
Terminate-Request packets
The TO+ event indicates that the Restart counter continues to
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
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
Simpson [Page 21]
RFC 1331 Point-to-Point Protocol May 1992
the peer. The Configure-Request packet indicates the desire
open a connection and may specify Configuration Options.
Configure-Request packet is more fully described in a
section
The RCR+ event indicates that the Configure-Request
acceptable, and triggers the transmission of a
Configure-Ack
The RCR- event indicates that the Configure-Request
unacceptable, and triggers the transmission of a
Configure-Nak or Configure-Reject
Implementation Note
These events may occur on a connection which is already in
Opened state. The implementation MUST be prepared
immediately renegotiate the Configuration Options
Receive-Configure-Ack (RCA
The Receive-Configure-Ack event occurs when a valid Configure-
packet is received from the peer. The Configure-Ack packet is
positive response to a Configure-Request packet. An out
sequence or otherwise invalid packet is silently discarded
Implementation Note
Since the correct packet has already been received
reaching the Ack-Rcvd or Opened states, it is
unlikely that another such packet will arrive. As specified
all invalid Ack/Nak/Rej packets are silently discarded, and
not affect the transitions of the automaton
However, it is not impossible that a correctly formed
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-
packet is received from the peer. The Configure-Nak
Configure-Reject packets are negative responses to a Configure
Request packet. An out of sequence or otherwise invalid packet
silently discarded
Simpson [Page 22]
RFC 1331 Point-to-Point Protocol May 1992
Implementation Note
Although the Configure-Nak and Configure-Reject cause the
state transition in the automaton, these packets
significantly different effects on the Configuration
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
indicates the desire of the peer to close the connection
Implementation Note
This event is not identical to the Close event (see above),
does not override the Open commands of the local
administrator. The implementation MUST be prepared to
a new Configure-Request without network
intervention
Receive-Terminate-Ack (RTA
The Receive-Terminate-Ack event occurs when a Terminate-Ack
is received from the peer. The Terminate-Ack packet is usually
response to a Terminate-Request packet. The Terminate-Ack
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-
packet is received from the peer. A Code-Reject packet is sent
response
Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-)
This event occurs when a Code-Reject or a Protocol-Reject
is received from the peer
The RXJ+ event arises when the rejected value is acceptable,
as a Code-Reject of an extended code, or a Protocol-Reject of
NCP. These are within the scope of normal operation.
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-
of LCP! This event communicates an unrecoverable error
Simpson [Page 23]
RFC 1331 Point-to-Point Protocol May 1992
terminates the connection
Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-
(RXR
This event occurs when an Echo-Request, Echo-Reply or Discard
Request packet is received from the peer. The Echo-Reply
is a response to a Echo-Request packet. There is no reply to
Echo-Reply or Discard-Request packet
5.5.
Actions in the automaton are caused by events and typically
the transmission of packets and/or the starting or stopping of
Restart timer
Illegal-Event (-)
This indicates an event that SHOULD NOT occur. The
probably has an internal error
This-Layer-Up (tlu
This action indicates to the upper layers that the automaton
entering the Opened state
Typically, this action MAY be used by the LCP to signal the
event to a NCP, Authentication Protocol, or Link Quality Protocol
or MAY be used by a NCP to indicate that the link is available
its traffic
This-Layer-Down (tld
This action indicates to the upper layers that the automaton
leaving the Opened state
Typically, this action MAY be used by the LCP to signal the
event to a NCP, Authentication Protocol, or Link Quality Protocol
or MAY be used by a NCP to indicate that the link is no
available for its traffic
This-Layer-Start (tls
This action indicates to the lower layers that the automaton
entering the Starting state, and the lower layer is needed for
link. The lower layer SHOULD respond with an Up event when
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
entering the Stopped or Closed states, and the lower layer is
longer needed for the link. The lower layer SHOULD respond with
Down event when the lower layer has terminated
Typically, this action MAY be used by the LCP to advance to
Link Dead phase, or MAY be used by a NCP to indicate to the
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
(Max-Terminate or Max-Configure). The counter is decremented
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
desired final state. In addition to zeroing the
counter, the implementation MUST set the timeout period to
appropriate value
Send-Configure-Request (scr
The Send-Configure-Request action transmits a Configure-
packet. This indicates the desire to open a connection with
specified set of Configuration Options. The Restart timer
started when the Configure-Request packet is transmitted, to
against packet loss. The Restart counter is decremented each
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
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
Configure-Reject packet, as appropriate. This negative
reports the reception of a Configure-Request packet with
unacceptable set of Configuration Options. Configure-Nak
are used to refuse a Configuration Option value, and to suggest
new, acceptable value. Configure-Reject packets are used
refuse all negotiation about a Configuration Option,
because it is not recognized or implemented. The use
Configure-Nak versus Configure-Reject is more fully described
the section on LCP Packet Formats
Send-Terminate-Request (str
The Send-Terminate-Request action transmits a Terminate-
packet. This indicates the desire to close a connection.
Restart timer is started when the Terminate-Request packet
transmitted, to guard against packet loss. The Restart counter
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
otherwise serves to synchronize the state machines
Send-Code-Reject (scj
The Send-Code-Reject action transmits a Code-Reject packet.
indicates the reception of an unknown type of packet
Send-Echo-Reply (ser
The Send-Echo-Reply action transmits an Echo-Reply packet.
acknowledges the reception of an Echo-Request packet
5.6. Loop
The protocol makes a reasonable attempt at avoiding
Option negotiation loops. However, the protocol does NOT
that loops will not happen. As with any negotiation, it is
to configure two PPP implementations with conflicting policies
will never converge. It is also possible to configure policies
do converge, but which take significant time to do so.
should keep this in mind and should implement loop
mechanisms or higher level timeouts
Simpson [Page 26]
RFC 1331 Point-to-Point Protocol May 1992
5.7. Counters and
Restart
There is one special timer used by the automaton. The Restart
is used to time transmissions of Configure-Request and Terminate
Request packets. Expiration of the Restart timer causes a
event, and retransmission of the corresponding Configure-Request
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.
default value is designed for low speed (19,200 bps or less),
switching latency links (typical telephone lines). Higher
links, or links with low switching latency, SHOULD
correspondingly faster retransmission times
Max-
There is one required restart counter for Terminate-Requests. Max
Terminate indicates the number of Terminate-Request packets
without receiving a Terminate-Ack before assuming that the peer
unable to respond. Max-Terminate MUST be configurable, but
default to two (2) transmissions
Max-
A similar counter is recommended for Configure-Requests. Max
Configure indicates the number of Configure-Request packets
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-
A related counter is recommended for Configure-Nak. Max-
indicates the number of Configure-Nak packets sent without sending
Configure-Ack before assuming that configuration is not converging
Any further Configure-Nak packets are converted to Configure-
packets. Max-Failure MUST be configurable, but should default to
(10) transmissions
Simpson [Page 27]
RFC 1331 Point-to-Point Protocol May 1992
6. LCP Packet
There are three classes of LCP packets
1. Link Configuration packets used to establish and configure
link (Configure-Request, Configure-Ack, Configure-Nak
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
(Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply,
Discard-Request).
This document describes Version 1 of the Link Control Protocol.
the interest of simplicity, there is no version field in the
packet. If a new version of LCP is necessary in the future,
intention is that a new Data Link Layer Protocol field value will
used to differentiate Version 1 LCP from all other versions.
correctly functioning Version 1 LCP implementation will
respond to unknown Protocols (including other versions) with
easily recognizable Version 1 packet, thus providing a
fallback mechanism for implementations of other versions
Regardless of which Configuration Options are enabled, all LCP
Configuration, Link Termination, and Code-Reject packets (codes 1
through 7) are always sent in the full, standard form, as if
Configuration Options were enabled. This ensures that
Configure-Request packets are always recognizable even when one
of the link mistakenly believes the link to be open
Exactly one Link Control Protocol packet is encapsulated in
Information field of PPP Data Link Layer frames where the
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
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
the most recent "Assigned Numbers" RFC [11]. Current values
assigned as follows
1 Configure-
2 Configure-
3 Configure-
4 Configure-
5 Terminate-
6 Terminate-
7 Code-
8 Protocol-
9 Echo-
10 Echo-
11 Discard-
12
The Identifier field is one octet and aids in matching
and replies. When a packet is received with an invalid
field, the packet is silently discarded
The Length field is two octets and indicates the length of the
packet including the Code, Identifier, Length and Data fields
Octets outside the range of the Length field should be treated
Data Link Layer padding and should be ignored on reception.
a packet is received with an invalid Length field, the packet
silently discarded
The Data field is zero or more octets as indicated by the
field. The format of the Data field is determined by the
field
Simpson [Page 29]
RFC 1331 Point-to-Point Protocol May 1992
6.1. Configure-
A LCP implementation wishing to open a connection MUST transmit
LCP packet with the Code field set to 1 (Configure-Request)
the Options field filled with any desired changes to the
link Configuration Options
Upon reception of a Configure-Request, an appropriate reply
be transmitted
A summary of the Configure-Request packet format is shown below.
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 ...
+-+-+-+-+
1 for Configure-Request
The Identifier field SHOULD be changed on each transmission.
reception, the Identifier field should be copied into
Identifier field of the appropriate reply packet
The options field is variable in length and contains the list
zero or more Configuration Options that the sender desires
negotiate. All Configuration Options are always
simultaneously. The format of Configuration Options is
described in a later section
Simpson [Page 30]
RFC 1331 Point-to-Point 