As per Relevance of the word indicate, we have this rfc below:
Network Working Group W. Simpson,
Request for Comments: 1661
STD: 51 July 1994
Obsoletes: 1548
Category: Standards
The Point-to-Point Protocol (PPP
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
The Point-to-Point Protocol (PPP) provides a standard method
transporting multi-protocol datagrams over point-to-point links.
is comprised of three main components
1. A method for encapsulating multi-protocol datagrams
2. A Link Control Protocol (LCP) for establishing, configuring
and testing the data-link connection
3. A family of Network Control Protocols (NCPs) for
and configuring different network-layer protocols
This document defines the PPP organization and methodology, and
PPP encapsulation, together with an extensible option
mechanism which is able to negotiate a rich assortment
configuration parameters and provides additional
functions. The PPP Link Control Protocol (LCP) is described in
of this mechanism
Table of
1. Introduction .......................................... 1
1.1 Specification of Requirements ................... 2
1.2 Terminology ..................................... 3
2. PPP Encapsulation ..................................... 4
Simpson [Page i
RFC 1661 Point-to-Point Protocol July 1994
3. PPP Link Operation .................................... 6
3.1 Overview ........................................ 6
3.2 Phase Diagram ................................... 6
3.3 Link Dead (physical-layer not ready) ............ 7
3.4 Link Establishment Phase ........................ 7
3.5 Authentication Phase ............................ 8
3.6 Network-Layer Protocol Phase .................... 8
3.7 Link Termination Phase .......................... 9
4. The Option Negotiation Automaton ...................... 11
4.1 State Transition Table .......................... 12
4.2 States .......................................... 14
4.3 Events .......................................... 16
4.4 Actions ......................................... 21
4.5 Loop Avoidance .................................. 23
4.6 Counters and Timers ............................. 24
5. LCP Packet Formats .................................... 26
5.1 Configure-Request ............................... 28
5.2 Configure-Ack ................................... 29
5.3 Configure-Nak ................................... 30
5.4 Configure-Reject ................................ 31
5.5 Terminate-Request and Terminate-Ack ............. 33
5.6 Code-Reject ..................................... 34
5.7 Protocol-Reject ................................. 35
5.8 Echo-Request and Echo-Reply ..................... 36
5.9 Discard-Request ................................. 37
6. LCP Configuration Options ............................. 39
6.1 Maximum-Receive-Unit (MRU) ...................... 41
6.2 Authentication-Protocol ......................... 42
6.3 Quality-Protocol ................................ 43
6.4 Magic-Number .................................... 45
6.5 Protocol-Field-Compression (PFC) ................ 48
6.6 Address-and-Control-Field-Compression (ACFC
SECURITY CONSIDERATIONS ...................................... 51
REFERENCES ................................................... 51
ACKNOWLEDGEMENTS ............................................. 51
CHAIR'S ADDRESS .............................................. 52
EDITOR'S ADDRESS ............................................. 52
Simpson [Page ii
RFC 1661 Point-to-Point Protocol July 1994
1.
The Point-to-Point Protocol is designed for simple links
transport packets between two peers. These links provide full-
simultaneous bi-directional operation, and are assumed to
packets in order. It is intended that PPP provide a common
for easy connection of a wide variety of hosts, bridges and
[1].
The PPP encapsulation provides for multiplexing of
network-layer protocols simultaneously over the same link.
PPP encapsulation has been carefully designed to
compatibility with most commonly used supporting hardware
Only 8 additional octets are necessary to form the
when used within the default HDLC-like framing. In
where bandwidth is at a premium, the encapsulation and framing
be shortened to 2 or 4 octets
To support high speed implementations, the default
uses only simple fields, only one of which needs to be
for demultiplexing. The default header and information
fall on 32-bit boundaries, and the trailer may be padded to
arbitrary boundary
Link Control
In order to be sufficiently versatile to be portable to a
variety of environments, PPP provides a Link Control
(LCP). The LCP is used to automatically agree upon
encapsulation format options, handle varying limits on sizes
packets, detect a looped-back link and other
misconfiguration errors, and terminate the link. Other
facilities provided are authentication of the identity of its
on the link, and determination when a link is functioning
and when it is failing
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
Simpson [Page 1]
RFC 1661 Point-to-Point Protocol July 1994
respective network-layer protocols. These NCPs are defined
companion documents
It is intended that PPP links be easy to configure. By design
the standard defaults handle all common configurations.
implementor can 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
document is specified in terms of the Link Control Protocol (LCP),
the same facilities are designed to be used by other
protocols, especially 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
MUST This word, or the adjective "required", means that
definition is an absolute requirement of the specification
MUST NOT This phrase means that the definition is an
prohibition of the specification
SHOULD This word, or the adjective "recommended", means that
may exist valid reasons in particular circumstances
ignore this item, but the full implications must
understood and carefully weighed before choosing
different course
MAY This word, or the adjective "optional", means that
item is one of an allowed set of alternatives.
implementation which does not include this option MUST
prepared to interoperate with another implementation
does include the option
Simpson [Page 2]
RFC 1661 Point-to-Point Protocol July 1994
1.2.
This document frequently uses the following terms
datagram The unit of transmission in the network layer (such as IP).
A datagram may be encapsulated in one or more
passed to the data link layer
frame The unit of transmission at the data link layer. A
may include a header and/or a trailer, along with
number of units of data
packet The basic unit of encapsulation, which is passed across
interface between the network layer and the data
layer. A packet is usually mapped to a frame;
exceptions are when data link layer fragmentation is
performed, or when multiple packets are incorporated into
single frame
peer The other end of the point-to-point link
silently
The implementation discards the packet without
processing. The implementation SHOULD provide
capability of logging the error, including the contents
the silently discarded packet, and SHOULD record the
in a statistics counter
Simpson [Page 3]
RFC 1661 Point-to-Point Protocol July 1994
2. PPP
The PPP encapsulation is used to disambiguate
datagrams. This encapsulation requires framing to indicate
beginning and end of the encapsulation. Methods of providing
are specified in companion documents
A summary of the PPP encapsulation is shown below. The fields
transmitted from left to right
+----------+-------------+---------+
| Protocol | Information | Padding |
| 8/16 bits| * | * |
+----------+-------------+---------+
Protocol
The Protocol field is one or two octets, and its value
the datagram encapsulated in the Information field of the packet
The field is transmitted and received most significant
first
The structure of this field is consistent with the ISO 3309
extension mechanism for address fields. All Protocols MUST
odd; the least significant bit of the least significant octet
equal "1". Also, all Protocols MUST be assigned such that
least significant bit of the most significant octet equals "0".
Frames received which don't comply with these rules MUST
treated as having an unrecognized Protocol
Protocol field values in the "0***" to "3***" range identify
network-layer protocol of specific packets, and values in
"8***" to "b***" range identify packets belonging to
associated 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
packets as link-layer Control Protocols (such as LCP).
Simpson [Page 4]
RFC 1661 Point-to-Point Protocol July 1994
Up-to-date values of the Protocol field are specified in the
recent "Assigned Numbers" RFC [2]. This specification
the following values
Value (in hex) Protocol
0001 Padding
0003 to 001f reserved (transparency inefficient
007d reserved (Control Escape
00cf reserved (PPP NLPID
00ff reserved (compression inefficient
8001 to 801f
807d
80cf
80ff
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
Information
The Information field is zero or more octets. The
field contains the datagram for the protocol specified in
Protocol field
The maximum length for the Information field, including Padding
but not including the Protocol field, is termed the
Receive Unit (MRU), which defaults to 1500 octets.
negotiation, consenting PPP implementations may use other
for the MRU
On transmission, the Information field MAY be padded with
arbitrary number of octets up to the MRU. It is
responsibility of each protocol to distinguish padding octets
real information
Simpson [Page 5]
RFC 1661 Point-to-Point Protocol July 1994
3. PPP Link
3.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 and configure one or
network-layer protocols. Once each of the chosen network-
protocols has been configured, datagrams from each network-
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).
3.2. Phase
In the process of configuring, maintaining and terminating
point-to-point link, the PPP link goes through several
phases which are specified in the following simplified state diagram
+------+ +-----------+ +--------------+
| | UP | | OPENED | | SUCCESS/
| Dead |------->| Establish |---------->| Authenticate |--+
| | | | | | |
+------+ +-----------+ +--------------+ |
^ | | |
| FAIL | FAIL | |
+<--------------+ +----------+ |
| | |
| +-----------+ | +---------+ |
| DOWN | | | CLOSING | | |
+------------| Terminate |<---+<----------| Network |<-+
| | | |
+-----------+ +---------+
Not all transitions are specified in this diagram. The
semantics MUST be followed
Simpson [Page 6]
RFC 1661 Point-to-Point Protocol July 1994
3.3. Link Dead (physical-layer not ready
The link necessarily begins and ends with this phase. When
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 later) will be in
Initial or Starting states. The transition to the Link
phase will signal an Up event to the LCP automaton
Implementation Note
Typically, a link will return to this phase automatically
the disconnection of a modem. In the case of a hard-wired link
this phase may be extremely short -- merely long enough to
the presence of the device
3.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 later) has been both sent and received
All Configuration Options are assumed to be at default values
altered by the configuration exchange. See the chapter 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
Any non-LCP packets received during this phase MUST be
discarded
The receipt of the LCP Configure-Request causes a return to the
Establishment phase from the Network-Layer Protocol phase
Authentication phase
Simpson [Page 7]
RFC 1661 Point-to-Point Protocol July 1994
3.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 mandatory. If an
desires that the peer authenticate with some specific
protocol, then it MUST request 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 authentication has completed.
authentication fails, the authenticator SHOULD proceed instead to
Link Termination phase
Only Link Control Protocol, authentication protocol, and link
monitoring packets are allowed during this phase. All other
received during this phase MUST be silently discarded
Implementation Notes
An implementation SHOULD NOT fail authentication simply due
timeout or lack of response. The authentication SHOULD allow
method of retransmission, and proceed to the Link
phase only after a number of authentication attempts has
exceeded
The implementation responsible for commencing Link
phase is the implementation which has refused authentication
its peer
3.6. Network-Layer Protocol
Once PPP has finished the previous phases, each network-
protocol (such as IP, IPX, or AppleTalk) MUST be
configured by the appropriate Network Control Protocol (NCP).
Each NCP MAY be Opened and Closed at any time
Simpson [Page 8]
RFC 1661 Point-to-Point Protocol July 1994
Implementation Note
Because an implementation may initially use a significant
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-layer protocol packets received when the corresponding NCP
not in the Opened state MUST be silently discarded
Implementation Note
While LCP is in the Opened state, any protocol packet which
unsupported by the implementation MUST be returned in a Protocol
Reject (described later). Only protocols which are supported
silently discarded
During this phase, link traffic consists of any possible
of LCP, NCP, and network-layer protocol packets
3.7. Link Termination
PPP can terminate the link at any time. This might happen because
the loss of carrier, authentication failure, link quality failure
the expiration of an idle-period timer, or the administrative
of the link
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
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
Any non-LCP packets received during this phase MUST be
discarded
Simpson [Page 9]
RFC 1661 Point-to-Point Protocol July 1994
Implementation Note
The closing of the link by LCP is sufficient. There is no
for each NCP to send a flurry of Terminate packets. Conversely
the fact that one NCP has Closed is not sufficient reason to
the termination of the PPP link, even if that NCP was the only
currently in the Opened state
Simpson [Page 10]
RFC 1661 Point-to-Point Protocol July 1994
4. 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-Restart-
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-
Simpson [Page 11]
RFC 1661 Point-to-Point Protocol July 1994
4.1. 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; multiple actions may be implemented in
convenient order. The state may be followed by a letter,
indicates an explanatory footnote. The dash ('-') indicates
illegal transition
|
| 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 tlf/0 2 2 4 4
|
TO+ | - - - - str/4 str/5
TO- | - - - - tlf/2 tlf/3
|
RCR+ | - - sta/2 irc,scr,sca/8 4 5
RCR- | - - sta/2 irc,scr,scn/6 4 5
RCA | - - sta/2 sta/3 4 5
RCN | - - sta/2 sta/3 4 5
|
RTR | - - sta/2 sta/3 sta/4 sta/5
RTA | - - 2 3 tlf/2 tlf/3
|
RUC | - - scj/2 scj/3 scj/4 scj/5
RXJ+ | - - 2 3 4 5
RXJ- | - - tlf/2 tlf/3 tlf/2 tlf/3
|
RXR | - - 2 3 4 5
Simpson [Page 12]
RFC 1661 Point-to-Point Protocol July 1994
|
| 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 scj/9
RXJ+ | 6 6 8 9
RXJ- | tlf/3 tlf/3 tlf/3 tld,irc,str/5
|
RXR | 6 7 8 ser/9
The states in which the Restart timer is running are identifiable
the presence of TO events. Only the Send-Configure-Request, Send
Terminate-Request and Zero-Restart-Count actions start or re-
the Restart timer. The Restart timer is stopped when
from any state where the timer is running to a state where the
is not running
The events and actions are defined according to a message
architecture, rather than a signalling architecture. If an action
desired to control specific signals (such as DTR), additional
are likely to be required
[p] Passive option; see Stopped state discussion
[r] Restart option; see Open event discussion
[x] Crossed connection; see RCA event discussion
Simpson [Page 13]
RFC 1661 Point-to-Point Protocol July 1994
4.2.
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 14]
RFC 1661 Point-to-Point Protocol July 1994
the This-Layer-Finished action) and the Receive-Configure
Request event. When a Configure-Request arrives before
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, the Closed state
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 15]
RFC 1661 Point-to-Point Protocol July 1994
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
received. The Restart timer is running, since a Configure-Ack
not yet been received
In the Opened state, a Configure-Ack has been both sent
received. The Restart timer is not running
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
4.3.
Transitions and actions in the automaton are caused by events
This event occurs when a lower layer indicates that it is ready
carry packets
Typically, this event is used by a modem handling or
process, or by some other coupling of the PPP link to the
media, to signal LCP that the link is entering Link
phase
It also can be used by LCP to signal each NCP that the link
entering Network-Layer Protocol phase. That is, the This-Layer-
action from LCP triggers the Up event in the NCP
This event occurs when a lower layer indicates that it is
Simpson [Page 16]
RFC 1661 Point-to-Point Protocol July 1994
longer ready to carry packets
Typically, this event is used by a modem handling or
process, or by some other coupling of the PPP link to the
media, to signal LCP that the link is entering Link Dead phase
It also can be used by LCP to signal each NCP that the link
leaving Network-Layer Protocol phase. That is, the This-Layer
Down action from LCP triggers the Down event in the NCP
This event indicates that the link is administratively
for traffic; that is, the network administrator (human or program
has indicated that the link is allowed to be Opened. When
event occurs, and the link is not in the Opened state,
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 is necessary
Implementation Option
Experience has shown that users will execute an additional
command when they want to renegotiate the link. This
indicate that new values are to be negotiated
Since this is not the meaning of the Open event, it
suggested that when an Open user command is executed in
Opened, Closing, Stopping, or Stopped states,
implementation issue a Down event, immediately followed by
Up event. Care must be taken that an intervening Down
cannot occur from another source
The Down followed by an Up will cause an orderly
of the link, by progressing through the Starting to
Request-Sent state. This will cause the renegotiation of
link, without any harmful side effects
This event indicates that the link is not available for traffic
Simpson [Page 17]
RFC 1661 Point-to-Point Protocol July 1994
that is, the network administrator (human or program)
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
Implementation Note
When authentication fails, the link SHOULD be terminated,
prevent attack by repetition and denial of service to
users. Since the link is administratively available (
definition), this can be accomplished by simulating a
event to the LCP, immediately followed by an Open event.
must be taken that an intervening Close event cannot occur
another source
The Close followed by an Open will cause an orderly
of the link, by progressing through the Closing to the
state, and the This-Layer-Finished action can disconnect
link. The automaton waits in the Stopped or Starting
for the next connection attempt
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
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
Simpson [Page 18]
RFC 1661 Point-to-Point Protocol July 1994
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
This event occurs when a valid Configure-Ack packet is
from the peer. The Configure-Ack packet is a positive response
a Configure-Request packet. An out of sequence or
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
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
This event occurs when a Terminate-Request packet is received
The Terminate-Request packet indicates the desire of the peer
Simpson [Page 19]
RFC 1661 Point-to-Point Protocol July 1994
close the connection
Implementation Note
This event is not identical to the Close event (see above),
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
This event occurs when a Terminate-Ack packet is received from
peer. The Terminate-Ack packet is usually a response to
Terminate-Request packet. The Terminate-Ack packet may
indicate that the peer is in Closed or Stopped states, and
to re-synchronize the link configuration
Receive-Unknown-Code (RUC
This event occurs when an un-interpretable packet is received
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
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
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 an Echo-Request packet. There is no reply to
Echo-Reply or Discard-Request packet
Simpson [Page 20]
RFC 1661 Point-to-Point Protocol July 1994
4.4.
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 cannot occur in a
implemented automaton. The implementation has an internal error
which should be reported and logged. No transition is taken,
the implementation SHOULD NOT reset or freeze
This-Layer-Up (tlu
This action indicates to the upper layers that the automaton
entering the Opened state
Typically, this action is used by the LCP to signal the Up
to a NCP, Authentication Protocol, or Link Quality Protocol,
MAY be used by a NCP to indicate that the link is available
its network layer traffic
This-Layer-Down (tld
This action indicates to the upper layers that the automaton
leaving the Opened state
Typically, this action is used by the LCP to signal the Down
to a NCP, Authentication Protocol, or Link Quality Protocol,
MAY be used by a NCP to indicate that the link is no
available for its network layer traffic
This-Layer-Started (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
This results of this action are highly implementation dependent
This-Layer-Finished (tlf
This action indicates to the lower layers that the automaton
entering the Initial, Closed or Stopped states, and the
layer is no longer needed for the link. The lower layer
respond with a Down event when the lower layer has terminated
Simpson [Page 21]
RFC 1661 Point-to-Point Protocol July 1994
Typically, this action MAY be used by the LCP to advance to
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 results of this action are highly implementation dependent
Initialize-Restart-Count (irc
This action sets the Restart counter to the appropriate
(Max-Terminate or Max-Configure). The counter is decremented
each transmission, including the first
Implementation Note
In addition to setting the Restart counter, the
MUST set the timeout period to the initial value when
timer backoff is used
Zero-Restart-Count (zrc
This action sets the Restart counter to zero
Implementation Note
This action enables the FSA to pause before proceeding to
desired final state, allowing traffic to be processed by
peer. In addition to zeroing the Restart counter,
implementation MUST set the timeout period to an
value
Send-Configure-Request (scr
A Configure-Request packet is transmitted. This indicates
desire to open a connection with a specified set of
Options. The Restart timer is started when the Configure-
packet is transmitted, to guard against packet loss. The
counter is decremented each time a Configure-Request is sent
Send-Configure-Ack (sca
A Configure-Ack packet is transmitted. This acknowledges
reception of a Configure-Request packet with an acceptable set
Configuration Options
Send-Configure-Nak (scn
A Configure-Nak or Configure-Reject packet is transmitted,
appropriate. This negative response reports the reception of
Simpson [Page 22]
RFC 1661 Point-to-Point Protocol July 1994
Configure-Request packet with an unacceptable set of
Options
Configure-Nak packets are used to refuse a Configuration
value, and to suggest a new, acceptable value. Configure-
packets are used to refuse all negotiation about a
Option, typically because it is not recognized or implemented
The use of Configure-Nak versus Configure-Reject is more
described in the chapter on LCP Packet Formats
Send-Terminate-Request (str
A Terminate-Request packet is transmitted. This indicates
desire to close a connection. The Restart timer is started
the Terminate-Request packet is transmitted, to guard
packet loss. The Restart counter is decremented each time
Terminate-Request is sent
Send-Terminate-Ack (sta
A Terminate-Ack packet is transmitted. This acknowledges
reception of a Terminate-Request packet or otherwise serves
synchronize the automatons
Send-Code-Reject (scj
A Code-Reject packet is transmitted. This indicates the
of an unknown type of packet
Send-Echo-Reply (ser
An Echo-Reply packet is transmitted. This acknowledges
reception of an Echo-Request packet
4.5. 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 23]
RFC 1661 Point-to-Point Protocol July 1994
4.6. Counters and
Restart
There is one special timer used by the automaton. The
timer is used to time transmissions of Configure-Request
Terminate-Request packets. Expiration of the Restart timer
a Timeout event, and retransmission of the
Configure-Request or Terminate-Request packet. The Restart
MUST be configurable, but SHOULD default to three (3) seconds
Implementation Note
The Restart timer SHOULD be based on the speed of the link
The default value is designed for low speed (2,400 to 9,600
bps), high switching latency links (typical telephone lines).
Higher speed links, or links with low switching latency,
have correspondingly faster retransmission times
Instead of a constant value, the Restart timer MAY begin at
initial small value and increase to the configured final value
Each successive value less than the final value SHOULD be
least twice the previous value. The initial value SHOULD
large enough to account for the size of the packets, twice
round trip time for transmission at the link speed, and
least an additional 100 milliseconds to allow the peer
process the packets before responding. Some circuits
another 200 milliseconds of satellite delay. Round trip
for modems operating at 14,400 bps have been measured in
range of 160 to more than 600 milliseconds
Max-
There is one required restart counter for Terminate-Requests
Max-Terminate indicates the number of Terminate-Request
sent without receiving a Terminate-Ack before assuming that
peer is unable to respond. Max-Terminate MUST be configurable
but SHOULD 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
Configure-Reject before assuming that the peer is unable
respond. Max-Configure MUST be configurable, but SHOULD
to ten (10) transmissions
Simpson [Page 24]
RFC 1661 Point-to-Point Protocol July 1994
Max-
A related counter is recommended for Configure-Nak. Max-
indicates the number of Configure-Nak packets sent without
a Configure-Ack before assuming that configuration is
converging. Any further Configure-Nak packets for peer
options are converted to Configure-Reject packets, and
desired options are no longer appended. Max-Failure MUST
configurable, but SHOULD default to five (5) transmissions
Simpson [Page 25]
RFC 1661 Point-to-Point Protocol July 1994
5. 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).
In the interest of simplicity, there is no version field in the
packet. A correctly functioning LCP implementation will
respond to unknown Protocols and Codes with an easily
LCP packet, thus providing a deterministic fallback mechanism
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 as if no Configuration Options
negotiated. In particular, each Configuration Option specifies
default value. This ensures that such LCP packets are
recognizable, even when one end of the link mistakenly believes
link to be open
Exactly one LCP packet is encapsulated in the PPP Information field
where the PPP Protocol field indicates type hex c021 (Link
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 ...
+-+-+-+-+
The Code field is one octet, and identifies the kind of
Simpson [Page 26]
RFC 1661 Point-to-Point Protocol July 1994
packet. When a packet is received with an unknown Code field,
Code-Reject packet is transmitted
Up-to-date values of the LCP Code field are specified in the
recent "Assigned Numbers" RFC [2]. This document concerns
following values
1 Configure-
2 Configure-
3 Configure-
4 Configure-
5 Terminate-
6 Terminate-
7 Code-
8 Protocol-
9 Echo-
10 Echo-
11 Discard-
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 without affecting
automaton
The Length field is two octets, and indicates the length of
LCP packet, including the Code, Identifier, Length and
fields. The Length MUST NOT exceed the MRU of the link
Octets outside the range of the Length field are treated
padding and are ignored on reception. When a packet is
with an invalid Length field, the packet is silently
without affecting the automaton
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 27]
RFC 1661 Point-to-Point Protocol July 1994
5.1. Configure-
An implementation wishing to open a connection MUST transmit
Configure-Request. The Options field is filled with any
changes to the link defaults. Configuration Options SHOULD NOT
included with default values
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 MUST be changed whenever the contents of
Options field changes, and whenever a valid reply has
received for a previous request. For retransmissions,
Identifier MAY remain unchanged
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 chapter
Simpson [Page 28]
RFC 1661 Point-to-Point Protocol July 1994
5.2. Configure-
If every Configuration Option received in a Configure-Request
recognizable and all values are acceptable, then
implementation MUST transmit a Configure-Ack. The
Configuration Options MUST NOT be reordered or modified in
way
On reception of a Configure-Ack, the Identifier field MUST
that of the last transmitted Configure-Request. Additionally,
Configuration Options in a Configure-Ack MUST exactly match
of the last transmitted Configure-Request. Invalid packets
silently discarded
A summary of the Configure-Ack 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 ...
+-+-+-+-+
2 for Configure-Ack
The Identifier field is a copy of the Identifier field of
Configure-Request which caused this Configure-Ack
The Options field is variable in length, and contains the list
zero or more Configuration Options that the sender
acknowledging. All Configuration Options are always
simultaneously
Simpson [Page 29]
RFC 1661 Point-to-Point Protocol July 1994
5.3. Configure-
If every instance of the received Configuration Options
recognizable, but some values are not acceptable, then
implementation MUST transmit a Configure-Nak. The Options
is filled with only the unacceptable Configuration Options
the Configure-Request. All acceptable Configuration Options
filtered out of the Configure-Nak, but otherwise the
Options from the Configure-Request MUST NOT be reordered
Options which have no value fields (boolean options) MUST use
Configure-Reject reply instead
Each Configuration Option which is allowed only a single
MUST be modified to a value acceptable to the Configure-
sender. The default value MAY be used, when this differs from
requested value
When a particular type of Configuration Option can be listed
than once with different values, the Configure-Nak MUST include
list of all values for that option which are acceptable to
Configure-Nak sender. This includes acceptable values that
present in the Configure-Request
Finally, an implementation may be configured to request
negotiation of a specific Configuration Option. If that option
not listed, then that option MAY be appended to the list of Nak'
Configuration Options, in order to prompt the peer to include
option in its next Configure-Request packet. Any value fields
the option MUST indicate values acceptable to the Configure-
sender
On reception of a Configure-Nak, the Identifier field MUST
that of the last transmitted Configure-Request. Invalid
are silently discarded
Reception of a valid Configure-Nak indicates that when a
Configure-Request is sent, the Configuration Options MAY
modified as specified in the Configure-Nak. When
instances of a Configuration Option are present, the peer
select a single value to include in its next Configure-
packet
Some Configuration Options have a variable length. Since
Nak'd Option has been modified by the peer, the
MUST be able to handle an Option length which is different
Simpson [Page 30]
RFC 1661 Point-to-Point Protocol July 1994
the original Configure-Request
A summary of the Configure-Nak packet format is shown below.
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 ...
+-+-+-+-+
3 for Configure-Nak
The Identifier field is a copy of the Identifier field of
Configure-Request which caused this Configure-Nak
The Options field is variable in length, and contains the list
zero or more Configuration Options that the sender is Nak'ing
All Configuration Options are always Nak'd simultaneously
5.4. Configure-
If some Configuration Options received in a Configure-Request
not recognizable or are not acceptable for negotiation (
configured by a network administrator), then the
MUST transmit a Configure-Reject. The Options field is
with only the unacceptable Configuration Options from
Configure-Request. All recognizable and negotiable
Options are filtered out of the Configure-Reject, but
the Configuration Options MUST NOT be reordered or modified in
way
On reception of a Configure-Reject, the Identifier field
match that of the last transmitted Configure-Request
Additionally, the Configuration Options in a Configure-Reject
Simpson [Page 31]
RFC 1661 Point-to-Point Protocol July 1994
be a proper subset of those in the last transmitted Configure
Request. Invalid packets are silently discarded
Reception of a valid Configure-Reject indicates that when a
Configure-Request is sent, it MUST NOT include any of
Configuration Options listed in the Configure-Reject
A summary of the Configure-Reject 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 ...
+-+-+-+-+
4 for Configure-Reject
The Identifier field is a copy of the Identifier field of
Configure-Request which caused this Configure-Reject
The Options field is variable in length, and contains the list
zero or more Configuration Options that the sender is rejecting
All Configuration Options are always rejected simultaneously
Simpson [Page 32]
RFC 1661 Point-to-Point Protocol July 1994
5.5. Terminate-Request and Terminate-
LCP includes Terminate-Request and Terminate-Ack Codes in order
provide a mechanism for closing a connection
An implementation wishing to close a connection SHOULD transmit
Terminate-Request. Terminate-Request packets SHOULD continue
be sent until Terminate-Ack is received, the lower layer
that it has gone down, or a sufficiently large number have
transmitted such that the peer is down with reasonable certainty
Upon reception of a Terminate-Request, a Terminate-Ack MUST
transmitted
Reception of an unelicited Terminate-Ack indicates that the
is in the Closed or Stopped states, or is otherwise in need
re-negotiation
A summary of the Terminate-Request and Terminate-Ack packet
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 ...
+-+-+-+-+
5 for Terminate-Request
6 for Terminate-Ack
On transmission, the Identifier field MUST be changed whenever
content of the Data field changes, and whenever a valid reply
been received for a previous request. For retransmissions,
Identifier MAY remain unchanged
On reception, the Identifier field of the Terminate-Request
copied into the Identifier field of the Terminate-Ack packet
Simpson 