RFC relevance of identifier

As per Relevance of the word identifier, we have this rfc below:

Network Working Group D.
Request for Comments: 1171
Obsoletes: RFC 1134 July 1990

The Point-to-Point
for
Transmission of Multi-Protocol Datagrams Over Point-to-Point

Status of this

This RFC specifies an IAB standards track protocol for the
community

Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol

This proposal is the product of the Point-to-Point Protocol
Group of the Internet Engineering Task Force (IETF). Comments on
memo should be submitted to the IETF Point-to-Point Protocol
Group chair

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 composed of
parts

1. A method for encapsulating datagrams over serial links

2. An extensible Link Control Protocol (LCP).

3. A family of Network Control Protocols (NCP) for
and configuring different network-layer protocols

This document defines the encapsulation scheme, the basic LCP, and
NCP for establishing and configuring the Internet Protocol (IP
(called the IP Control Protocol, IPCP).

The options and facilities used by the LCP and the IPCP are
in separate documents. Control protocols for configuring
utilizing other network-layer protocols besides IP (e.g., DECNET
OSI) are expected to be developed as needed

Perkins [Page i

RFC 1171 Point-to-Point Protocol July 1990

Table of

1. Introduction .......................................... 1
1.1 Motivation ...................................... 1
1.2 Overview of PPP ................................. 1
1.3 Organization of the document .................... 2

2. Physical Layer Requirements ........................... 3

3. The Data Link Layer ................................... 4
3.1 Frame Format .................................... 5

4. The PPP Link Control Protocol (LCP) ................... 9
4.1 The LCP Automaton ............................... 11
4.1.1 Overview ........................................ 11
4.1.2 State Diagram ................................... 11
4.1.3 State Transition Table .......................... 13
4.1.4 Events .......................................... 13
4.1.5 Actions ......................................... 16
4.1.6 States .......................................... 17
4.2 Loop Avoidance .................................. 20
4.3 Timers and Counters ............................. 20
4.4 Packet Format ................................... 21
4.4.1 Configure-Request ............................... 23
4.4.2 Configure-Ack ................................... 24
4.4.3 Configure-Nak ................................... 25
4.4.4 Configure-Reject ................................ 27
4.4.5 Terminate-Request and Terminate-Ack ............. 29
4.4.6 Code-Reject ..................................... 31
4.4.7 Protocol-Reject ................................. 32
4.4.8 Echo-Request and Echo-Reply ..................... 34
4.4.9 Discard-Request ................................. 36
4.5 Configuration Options ........................... 38
4.5.1 Format .......................................... 39

5. A PPP Network Control Protocol (NCP) for IP ........... 40
5.1 Sending IP Datagrams ............................ 40

APPENDICES ................................................... 42

A. Asynchronous HDLC ..................................... 42

B. Fast Frame Check Sequence (FCS) Implementation ........ 44
B.1 FCS Computation Method .......................... 44
B.2 Fast FCS table generator ........................ 46

REFERENCES ................................................... 47

Perkins [Page ii

RFC 1171 Point-to-Point Protocol July 1990

SECURITY CONSIDERATIONS ...................................... 48

CHAIRMAN'S ADDRESS ........................................... 48

Perkins [Page iii

RFC 1171 Point-to-Point Protocol July 1990

1.

1.1.

In the last few years, the Internet has seen explosive growth in
number of hosts supporting TCP/IP. The vast majority of these
are connected to Local Area Networks (LANs) of various types
Ethernet being the most common. Most of the other hosts
connected through Wide Area Networks (WANs) such as X.25 style
Data Networks (PDNs). Relatively few of these hosts are
with simple point-to-point (i.e., serial) links. Yet, point-to-
links are among the oldest methods of data communications and
every host supports point-to-point connections. For example
asynchronous RS-232-C [1] interfaces 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 of non
standard (and at least one defacto standard) encapsulation
available, but there is not one which has been agreed upon as
Internet Standard. By contrast, standard encapsulation schemes
exist for the transmission of datagrams over most popular LANs

One purpose of this memo is to remedy this problem. But even
importantly, the Point-to-Point Protocol proposes more than just
encapsulation scheme. Point-to-Point links tend to exacerbate
problems with the current family of network protocols. For instance
assignment and management of IP addresses, which is a problem even
LAN environments, is especially difficult over circuit
point-to-point circuits (e.g., dialups).

Some additional issues addressed by this specification of PPP
asynchronous (start/stop) and bit-oriented synchronous encapsulation
network protocol multiplexing, link configuration, link
testing, error detection, and option negotiation for
capabilities as network-layer address negotiation and
compression negotiation

PPP addresses these issues by providing an extensible Link
Protocol (LCP) and a family of Network Control Protocols (NCP)
negotiate optional configuration parameters and facilities

1.2. Overview of

PPP has three main components

1. A method for encapsulating datagrams over serial links.
uses HDLC as a basis for encapsulating datagrams over point
to-point links. At this time, PPP specifies the use

Perkins [Page 1]

RFC 1171 Point-to-Point Protocol July 1990

asynchronous or synchronous duplex circuits, either
or circuit switched

2. An extensible Link Control Protocol (LCP) to establish
configure, and test the data-link connection

3. A family of Network Control Protocols (NCP) for
and configuring different network-layer protocols. PPP
designed to allow the simultaneous use of multiple network
layer protocols

In order to establish communications over a point-to-point link,
originating PPP would first send LCP packets to configure and
the data link. After the link has been establish and
facilities have been negotiated as needed by the LCP, the
PPP would 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 (e.g., inactivity timer expires or user intervention).

1.3. Organization of the

This memo is divided into several sections. Section 2 discusses
physical-layer requirements of PPP. Section 3 describes the
Link Layer including the PPP frame format and data link
scheme. Section 4 specifies the LCP including the
establishment and option negotiation procedures. Section 5
the IP Control Protocol (IPCP), which is the NCP for the
Protocol, and describes the encapsulation of IP datagrams within
packets. Appendix A summarizes important features of
HDLC, and Appendix B describes an efficient table-lookup
for fast Frame Check Sequence (FCS) computation

Perkins [Page 2]

RFC 1171 Point-to-Point Protocol July 1990

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 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 the use of modem control signals, such
Request To Send (RTS), Clear To Send (CTS), Data Carrier
(DCD), and Data Terminal Ready (DTR). However, using such
when available can allow greater functionality and performance

Perkins [Page 3]

RFC 1171 Point-to-Point Protocol July 1990

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

Note: ISO 3309:1984/PDAD1 is a Proposed Draft standard.
present, it seems that ISO 3309:1984/PDAD1 is stable and likely
become an International Standard. Therefore, we feel
about using it before it becomes an International Standard.
progress of this proposal should be tracked and encouraged by
Internet community

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

Perkins [Page 4]

RFC 1171 Point-to-Point Protocol July 1990

3.1. Frame

A summary of the standard PPP frame structure is shown below.
fields are transmitted from left to right

+----------+----------+----------+----------+------------
| Flag | Address | Control | Protocol |
| 01111110 | 11111111 | 00000011 | 16 bits | *
+----------+----------+----------+----------+------------
---+---------+----------+
| FCS | Flag |
| 16 bits | 01111110 |
---+---------+----------+

This figure does not include start/stop bits (for asynchronous links
or any bits or octets inserted for transparency. When
links are used, all octets are transmitted with one start bit,
bits of data, and one stop bit. There is no provision in either
or ISO 3309:1984/PDAD1 for seven bit asynchronous links

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

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).

Address

The Address field is a single octet and contains the
sequence 11111111 (hexadecimal 0xff), the All-Stations address
PPP does not assign individual station addresses. The All
Stations address should always be recognized and received.
use of other address lengths and values may be defined at a
time, or by prior agreement. Frames with unrecognized
should be reported through the normal network management facility

Control

The Control field is a single octet and contains the

Perkins [Page 5]

RFC 1171 Point-to-Point Protocol July 1990

sequence 00000011 (hexadecimal 0x03), the Unnumbered
(UI) command with the P/F bit set to zero. Frames with
Control field values should be silently discarded

Protocol

The Protocol field is two octets and its value identifies
protocol encapsulated in the Information field of the frame.
most up-to-date values of the Protocol field are specified in
most recent "Assigned Numbers" RFC [12]. Initial values are
listed below

Protocol field values in the "cxxx" range identify datagrams
belonging to the Link Control Protocol (LCP) or
protocols. Values in the "8xxx" range identify datagrams
to the family of Network Control Protocols (NCP). Values in
"0xxx" range identify the network protocol of specific datagrams

This Protocol field is defined by PPP and is not a field
by HDLC. However, the Protocol field is consistent with the
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 should
considered as having an unrecognized Protocol, and should
handled as specified by the LCP. The Protocol field
transmitted and received most significant octet first

Perkins [Page 6]

RFC 1171 Point-to-Point Protocol July 1990

The Protocol field is initially assigned as follows

Value (in hex)

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/IP 1
002f * Van Jacobson Compressed TCP/IP 2

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 *

c021 Link Control
c023 * User/Password Authentication

* Reserved for future use; not described in this document

Information

The Information field is zero or more octets. The
field contains the datagram for the protocol specified in
Protocol field. The end of the Information field is found
locating the closing Flag Sequence and allowing two octets for
Frame Check Sequence field. The default maximum length of
Information field is 1500 octets. By prior agreement,
PPP implementations may use other values for the
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
from real information

Frame Check Sequence (FCS)

The Frame Check Sequence field is normally 16 bits (two octets).
By prior agreement, consenting PPP implementations may use a 32-

Perkins [Page 7]

RFC 1171 Point-to-Point Protocol July 1990

bit (four-octet) FCS for improved error detection

The FCS field is calculated over all bits of the Address, Control
Protocol and Information fields not including any start and
bits (asynchronous) and any bits (synchronous) or
(asynchronous) inserted for transparency. This does not
the Flag Sequences or FCS field. The FCS is transmitted with
coefficient of the highest term first

For more information on the specification of the FCS, see ISO 3309
or CCITT X.25.

Note: A fast, table-driven implementation of the 16-bit
algorithm is shown in Appendix B. This implementation is
on [7], [8], and [9].

Modifications to the Basic Frame

The Link Control Protocol can negotiate modifications to
standard PPP frame structure. However, modified frames
always be clearly distinguishable from standard frames

Perkins [Page 8]

RFC 1171 Point-to-Point Protocol July 1990

4. The PPP Link Control Protocol (LCP

The Link Control Protocol (LCP) provides a method of establishing
configuring, maintaining and terminating the point-to-
connection. LCP goes through four distinct phases

Phase 1: Link Establishment and Configuration

Before any network-layer datagrams (e.g., IP) may be exchanged
LCP must first open the connection through an exchange
Configure packets. This exchange is complete, and the Open
entered, once a Configure-Ack packet (described below) has
both sent and received. Any non-LCP packets received before
exchange is complete are silently discarded

It is important to note that LCP handles configuration only of
link; LCP does not handle configuration of individual network
layer protocols. In particular, all Configuration
which are independent of particular network-layer protocols
configured by LCP. All Configuration Options are assumed to be
default values unless altered by the configuration exchange

Phase 2: Link Quality

LCP allows an optional Link Quality Determination phase
transition to the LCP Open state. In this phase, the link
tested to determine if the link quality is sufficient to bring
network-layer protocols. This phase is completely optional.
may delay transmission of network-layer protocol information
this phase is completed

The procedure for Link Quality Determination is unspecified
may vary from implementation to implementation, or because
user-configured parameters, but only so long as the
doesn't violate other aspects of LCP. One suggested method is
use LCP Echo-Request and Echo-Reply packets

What is important is that this phase may persist for any length
time. Therefore, implementations should avoid fixed timeouts
waiting for their peers to advance to phase 3.

Phase 3: Network-Layer Protocol Configuration

Once LCP has finished the Link Quality Determination phase
network-layer protocols may be separately configured by
appropriate Network Control Protocols (NCP), and may be brought
and taken down at any time. If LCP closes the link, it
the network-layer protocols so that they may take

Perkins [Page 9]

RFC 1171 Point-to-Point Protocol July 1990

action

Phase 4: Link

LCP may terminate the link at any time. This will usually be
at the request of a human user, but may happen because of
physical event such as the loss of carrier, or the expiration
an idle-period timer

Perkins [Page 10]

RFC 1171 Point-to-Point Protocol July 1990

4.1. The LCP

4.1.1.

LCP is specified by a number of packet formats and a finite-
automaton. This section presents an overview of the LCP automaton
followed by a representation of it as both a state diagram and
state transition table

There are three classes of LCP packets

1. Link Establishment packets used to establish and configure
link, (e.g., Configure-Request, Configure-Ack, Configure-
and Configure-Reject

2. Link Termination packets used to terminate a link, (e.g.,
Terminate-Request and Terminate-Ack

3. Link Maintenance packets used to manage and debug a link
(e.g., Code-Reject, Protocol-Reject, Echo-Request, Echo-
and Discard-Request

The finite-state automaton is defined by events, state
and actions. Events include receipt of external commands such
Open and Close, expiration of the Restart timer, and receipt
packets from a LCP peer. Actions include the starting of the
timer and transmission of packets

4.1.2. State

The state diagram which follows describes the sequence of events
reaching agreement on Configuration Options (opening the
connection) and for later closing of the connection. The
machine is initially in the Closed state (1). Once the Open
(6) has been reached, both ends of the link have met the
of having both sent and received a Configure-Ack packet

In the state diagram, events are shown above horizontal lines
Actions are shown below horizontal lines. Two types of LCP packets -
Configure-Naks and Configure-Rejects - are not differentiated in
state diagram. As will be described later, these packets do
serve different, though similar, functions. However, at the level
detail of this state diagram, they always cause the same transition

Since a more detailed specification of the LCP automaton is given
a state transition table in the following section,
should be done by consulting it rather than this state diagram

Perkins [Page 11]

RFC 1171 Point-to-Point Protocol July 1990

+------------------------------+
| |
V |
+---2---+ PO +---1---+ RTA +---7---+ |
| |<-------------| |<-----------| | |
|Listen | |Closed | |Closing| |
RCR | | C | | PLD | | |
+----| |----->+------>| |<---Any | |<--+ |
|scr +-------+ ^ +-------+ State +-------+ | |
| | AO | ^ | TO | |
| +-----------+ --- | | +---->+ |
| | SCR | | str ^ |
| C | RCN/TO | | C | |
| --- | +-------->+<--------+ | --- | |
| | | scr | | | |
| +---3---+ V TO +---4---+ +-------+ | |
| | |<-----+<------| |<-----------| | | |
| | Req- | scr | Ack- | scn | Good | | |
| | Sent | RCA | Rcvd | RCR | Req? | | |
| | |------------->| |----------->| | | |
| +-------+ +-------+ +-------+ | |
| | ^ | | |
| RCR | +<--------+ | | |
| --- | | | TO RCN --- | | |
| | | --- +---------+ +-----+ sca | | |
| V | scn scr | | scr | V | |
| +-------+ +---5---+ | +---6---+ C | |
+--->| |------------->| |<--+ | |---+ |
| Good | sca | Ack- | | Open | str |
| Req? | RCR | Sent | RCA | | |
| |<-------------| |----------->| | |
+-------+ +-------+ +-------+ |
^ | | |
| RCR | | RTR |
+---------------------------------------+ +--------+
scr

Events

RCR - Receive-Configure-Request scr - Send Configure-
RCA - Receive-Configure-Ack sca - Send Configure-
RCN - Receive-Configure-Nak or Reject scn - Send Configure-
RTR - Receive-Terminate-Req or
RTA - Receive-Terminate-Ack str - Send Terminate-
AO - Active-Open sta - Sent Terminate-
PO - Passive-
C -
TO -

Perkins [Page 12]

RFC 1171 Point-to-Point Protocol July 1990

PLD - Physical-Layer-

4.1.3. 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. Two
caused by the same event are represented as action1&action2.

|
| 1 2 3 4 5 6 7
Events| Closed Listen Req-Sent Ack-Rcvd Ack-Sent Open
------+-------------------------------------------------------------
AO | scr/3 scr/3 3 4 5 6 scr/3
PO | 2 2 2* 4 5 6 sta/3*
C | 1 1 1* 1 str/7 str/7 7
TO | 1 2 scr/3 scr/3 scr/3 6 str/7*
PLD | 1 1 1 1 1 1 1
RCR+ | sta/1 scr&sca/5 sca/5 sca/6 sca/5 scr&sca/5 7
RCR- | sta/1 scr&scn/3 scn/3 scn/4 scn/3 scr&scn/3 7
RCA | sta/1 sta/2 4 scr/3 6 scr/3 7
RCN | sta/1 sta/2 scr/3 scr/3 scr/5 scr/3 7
RTR | sta/1 sta/2 sta/3 sta/3 sta/3 sta/1 sta/7
RTA | 1 2 3 3 3 1 1
RCJ | 1 2 1 1 1 1 1
RUC | scj/1 scj/2 scj/1 scj/1 scj/1 scj/1 1 scj/7
RER | sta/1 sta/2 3 4 5 ser/6 7

Notes
RCR+ - Receive-Configure-Request (Good
RCR- - Receive-Configure-Request (Bad
RCJ - Receive-Code-
RUC - Receive-Unknown-
RER - Receive-Echo-
scj - Send-Code-
ser - Send-Echo-
* - Special attention necessary, see detailed

4.1.4.

Transitions and actions in the LCP state machine are caused
events. Some events are caused by commands executed at the local
(e.g., Active-Open, Passive-Open, and Close), others are caused
the receipt of packets from the remote end (e.g., Receive
Configure-Request, Receive-Configure-Ack, Receive-Configure-Nak
Receive- Terminate-Request and Receive-Terminate-Ack), and
others are caused by the expiration of the Restart timer started

Perkins [Page 13]

RFC 1171 Point-to-Point Protocol July 1990

the result of other events (e.g., Timeout).

Following is a list of LCP events

Active-Open (AO

The Active-Open event indicates the local execution of an Active
Open command by the network administrator (human or program).
When this event occurs, LCP should immediately attempt to open
connection by exchanging configuration packets with the LCP peer

Passive-Open (PO

The Passive-Open event is similar to the Active-Open event
However, instead of immediately exchanging configuration packets
LCP should wait for the peer to send the first packet. This
only happen after an Active-Open event in the LCP peer

Close (C

The Close event indicates the local execution of a Close command
When this event occurs, LCP should immediately attempt to
the connection

Timeout (TO

The Timeout event indicates the expiration of the LCP
timer. The LCP Restart timer is started as the result of
LCP events

The Restart timer is used to time out transmissions of Configure
Request and Terminate-Request packets. Expiration of the
timer causes a Timeout event, which triggers the
Configure-Request or Terminate-Request packet to be retransmitted
The Restart timer MUST be configurable, but should default
three (3) seconds

Receive-Configure-Request (RCR

The Receive-Configure-Request event occurs when a Configure
Request packet is received from the LCP peer. The Configure
Request packet indicates the desire to open a LCP connection
may specify Configuration Options. The Configure-Request
is more fully described in a later section

Receive-Configure-Ack (RCA

The Receive-Configure-Ack event occurs when a valid Configure-

Perkins [Page 14]

RFC 1171 Point-to-Point Protocol July 1990

packet is received from the LCP peer. The Configure-Ack packet
a positive response to a Configure-Request packet

Receive-Configure-Nak (RCN

The Receive-Configure-Nak event occurs when a valid Configure-
or Configure-Reject packet is received from the LCP peer.
Configure-Nak and Configure-Reject packets are negative
to a Configure-Request packet

Receive-Terminate-Request (RTR

The Receive-Terminate-Request event occurs when a Terminate
Request packet is received from the LCP peer. The Terminate
Request packet indicates the desire to close the LCP connection

Receive-Terminate-Ack (RTA

The Receive-Terminate-Ack event occurs when a Terminate-Ack
is received from the LCP peer. The Terminate-Ack packet is
response to a Terminate-Request packet

Receive-Code-Reject (RCJ

The Receive-Code-Reject event occurs when a Code-Reject packet
received from the LCP peer. The Code-Reject packet
an error that immediately closes the connection

Receive-Unknown-Code (RUC

The Receive-Unknown-Code event occurs when an un-
packet is received from the LCP peer. The Code-Reject packet is
response to an unknown packet

Receive-Echo-Request (RER

The Receive-Echo-Request event occurs when a Echo-Request, Echo
Reply, or Discard-Request packet is received from the LCP peer
The Echo-Reply packet is a response to a Echo-Request packet
There is no reply to a Discard-Request

Physical-Layer-Down (PLD

The Physical-Layer-Down event occurs when the Physical
indicates that it is down

Perkins [Page 15]

RFC 1171 Point-to-Point Protocol July 1990

4.1.5.

Actions in the LCP state machine are caused by events and
indicate the transmission of packets and/or the starting or
of the Restart timer. Following is a list of LCP actions

Send-Configure-Request (scr

The Send-Configure-Request action transmits a Configure-
packet. This indicates the desire to open a LCP connection with
specified set of Configuration Options. The Restart timer
started after the Configure-Request packet is transmitted,
guard against packet loss

Send-Configure-Ack (sca

The Send-Configure-Ack action transmits a Configure-Ack packet
This acknowledges the receipt of a Configure-Request packet
an acceptable set of Configuration Options

Send-Configure-Nak (scn

The Send-Configure-Nak action transmits a Configure-Nak
Configure-Reject packet, as appropriate. This negative
reports the receipt 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 vs. Configure-Reject is more fully described in
section on LCP Packet Formats

Send-Terminate-Req (str

The Send-Terminate-Request action transmits a Terminate-
packet. This indicates the desire to close a LCP connection.
Restart timer is started after the Terminate-Request packet
transmitted, to guard against packet loss

Send-Terminate-Ack (sta

The Send-Terminate-Request action transmits a Terminate-
packet. This acknowledges the receipt of a Terminate-
packet or otherwise confirms the belief that a LCP connection
Closed

Perkins [Page 16]

RFC 1171 Point-to-Point Protocol July 1990

Send-Code-Reject (scj

The Send-Code-Reject action transmits a Code-Reject packet.
indicates the receipt of an unknown type of packet. This is
unrecoverable error which causes immediate transitions to
Closed state on both ends of the link

Send-Echo-Reply (ser

The Send-Echo-Reply action transmits an Echo-Reply packet.
acknowledges the receipt of an Echo-Request packet

4.1.6.

Following is a more detailed description of each LCP state

Closed (1)

The initial and final state is the Closed state. In the
state the connection is down and there is no attempt to open it
all connection requests from peers are rejected. Physical-Layer
Down events always cause an immediate transition to the
state

There are two events which cause a transition out of the
state, Active-Open and Passive-Open. Upon an Active-Open event,
Configure-Request is transmitted, the Restart timer is started
and the Request-Sent state is entered. Upon a Passive-Open event
the Listen state is entered immediately. Upon receipt of
packet, with the exception of a Terminate-Ack, a Terminate-Ack
sent. Terminate-Acks are silently discarded to avoid creating
loop

The Restart timer is not running in the Closed state

The Physical Layer connection may be disconnected at any time
in the LCP Closed state

Listen (2)

The Listen state is similar to the Closed state in that
connection is down and there is no attempt to open it. However
peer connection requests are no longer rejected

Upon receipt of a Configure-Request, a Configure-Request
immediately transmitted and the Restart timer is started.
received Configuration Options are examined and the
response is sent. If a Configure-Ack is sent, the Ack-Sent

Perkins [Page 17]

RFC 1171 Point-to-Point Protocol July 1990

is entered. Otherwise, if a Configure-Nak or Configure-Reject
sent, the Request-Sent state is entered. In either case,
exits its passive state, and begins to actively open
connection. Terminate-Ack packets are sent in response to
Configure-Ack or Configure-Nak packets

The Restart timer is not running in the Listen state

Request-Sent (3)

In the Request-Sent state an active attempt is made to open
connection. A Configure-Request has been sent and the
timer is running, but a Configure-Ack has not yet been
nor has one been sent

Upon receipt of a Configure-Ack, the Ack-Received state
immediately entered. Upon receipt of a Configure-Nak
Configure-Reject, the Configure-Request Configuration Options
adjusted appropriately, a new Configure-Request is transmitted
and the Restart timer is restarted. Similarly, upon
expiration of the Restart timer, a new Configure-Request
transmitted and the Restart timer is restarted. Upon receipt of
Configure-Request, the Configuration Options are examined and
acceptable, a Configure-Ack is sent and the Ack-Sent state
entered. If the Configuration Options are unacceptable,
Configure-Nak or Configure-Reject is sent as appropriate

Since there is an outstanding Configure-Request in the Request
Sent state, special care must be taken to implement the Passive
Open and Close events; otherwise, it is possible for the LCP
to think the connection is open. Processing of either
should be postponed until there is reasonable assurance that
peer is not open. In particular, the Restart timer should
allowed to expire

Ack-Received (4)

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 transmitted

Upon receipt of a Configure-Request with acceptable
Options, a Configure-Ack is transmitted, the Restart timer
stopped and the Open state is entered. If the
Options are unacceptable, a Configure-Nak or Configure-Reject
sent as appropriate. Upon the expiration of the Restart timer,
new Configure-Request is transmitted, the Restart timer
restarted, and the state machine returns to the Request-

Perkins [Page 18]

RFC 1171 Point-to-Point Protocol July 1990

state

Ack-Sent (5)

In the Ack-Sent state, a Configure-Ack and a Configure-
have been sent but a Configure-Ack has not yet been received.
Restart timer is always running in the Ack-Sent state

Upon receipt of a Configure-Ack, the Restart timer is stopped
the Open state is entered. Upon receipt of a Configure-Nak
Configure-Reject, the Configure-Request Configuration Options
adjusted appropriately, a new Configure-Request is transmitted
and the Restart timer is restarted. Upon the expiration of
Restart timer, a new Configure-Request is transmitted, the
timer is restarted, and the state machine returns to the Request
Sent state

Open (6)

In the Open state, a connection exists and data may
communicated over the link. The Restart timer is not running
the Open state

In normal operation, only two events cause transitions out of
Open state. Upon receipt of a Close command, a Terminate-
is transmitted, the Restart timer is started, and the
state is entered. Upon receipt of a Terminate-Request,
Terminate-Ack is transmitted and the Closed state is entered
Upon receipt of an Echo-Request, an Echo-Reply is transmitted
Similarly, Echo-Reply and Discard-Request packets are
discarded or processed as expected. All other events
immediate transitions out of the Open state and should be
as if the state machine were in the Listen state

Closing (7)

In the Closing state, an active attempt is made to close
connection. A Terminate-Request has been sent and the
timer is running, but a Terminate-Ack has not yet been received

Upon receipt of a Terminate-Ack, the Closed state is
entered. Upon the expiration of the Restart timer, a
Terminate-Request is transmitted and the Restart timer
restarted. After the Restart timer has expired Max-Restart times
this action may be skipped, and the Closed state may be entered
Max-Restart MUST be a configurable parameter

Since there is an outstanding Terminate-Request in the

Perkins [Page 19]

RFC 1171 Point-to-Point Protocol July 1990

state, special care must be taken to implement the Passive-
event; otherwise, it is possible for the LCP peer to think
connection is open. Processing of the Passive-Open event
be postponed until there is reasonable assurance that the peer
not open. In particular, the implementation should wait until
state machine would normally transition to the Closed
because of a Receive-Terminate-Ack event or Max-Restart
events

4.2. Loop

Note that the protocol makes a reasonable attempt at
Configuration Option negotiation loops. However, the protocol
NOT guarantee that loops will not happen. As with any negotiation
it is possible to configure two PPP implementations with
policies that will never converge. It is also possible to
policies which do converge, but which take significant time to do so
Implementors should keep this in mind and should implement
detection mechanisms or higher level timeouts. If a timeout
implemented, it MUST be configurable

4.3. Timers and

There is one special timer used by LCP, the Restart timer.
Restart timer is used to time out transmissions of Configure-
and Terminate-Request packets. Expiration of the Restart
causes a Timeout event, and the corresponding Configure-Request
Terminate-Request packet retransmission. The Restart timer MUST
configurable, but should default to three (3) seconds

There is one additional restart parameter, Max-Restarts. Max
Restarts indicates the number of packet retransmissions that
required before there is reasonable assurance that the link closed
Max-Restarts MUST also be configurable, but should default to
(10) retransmissions

Perkins [Page 20]

RFC 1171 Point-to-Point Protocol July 1990

4.4. Packet

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 ...
+-+-+-+-+

The Code field is one octet and identifies the kind of LCP packet
LCP Codes are 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-

The Identifier field is one octet and aids in matching
and replies

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

Perkins [Page 21]

RFC 1171 Point-to-Point Protocol July 1990

The Data field is zero or more octets as indicated by the
field. The format of the Data field is determined by the
field

Regardless of which Configuration Options are enabled, all
packets 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

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
be 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

Perkins [Page 22]

RFC 1171 Point-to-Point Protocol July 1990

4.4.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

Perkins [Page 23]

RFC 1171 Point-to-Point Protocol July 1990

4.4.2. Configure-

If every Configuration Option received in a Configure-Request
both recognizable and acceptable, then a LCP implementation
transmit a LCP packet with the Code field set to 2 (Configure
Ack), the Identifier field copied from the received Configure
Request, and the Options field copied from the
Configure-Request. The acknowledged Configuration Options
NOT be reordered or modified in any way

On reception of a Configure-Ack, the Identifier field must
that of the last transmitted Configure-Request, or the packet
invalid. Additionally, the Configuration Options in a Configure
Ack must match those of the last transmitted Configure-Request,
the packet is invalid. Invalid packets should be
discarded

Reception of a valid Configure-Ack indicates that
Configuration Options sent in the last Configure-Request
acceptable

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

Perkins [Page 24]

RFC 1171 Point-to-Point Protocol July 1990

acknowledging. All Configuration Options are always
simultaneously

4.4.3. Configure-

If every element of the received Configuration Options
recognizable but some are not acceptable, then a
implementation should transmit a LCP packet with the Code
set to 3 (Configure-Nak), the Identifier field copied from
received Configure-Request, and the Options field filled with
the unacceptable Configuration Options from the Configure-Request
All acceptable Configuration Options should be filtered out of
Configure-Nak, but otherwise the Configuration Options from
Configure-Request MUST NOT be reordered. Each of the nak'
Configuration Options MUST be modified to a value acceptable
the Configure-Nak sender. Finally, an implementation may
configured to require the negotiation of a specific option.
that option is not listed, then that option may be appended to
list of nak'd Configuration Options in order to request the
end to list that option in its next Configure-Request packet.
appended option must include a value acceptable to the Configure
Nak sender

On reception of a Configure-Nak, the Identifier field must
that of the last transmitted Configure-Request, or the packet
invalid and should be silently discarded

Reception of a valid Configure-Nak indicates that a
Configure-Request should be sent with the Configuration
modified as specified in the Configure-Nak

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

Perkins [Page 25]

RFC 1171 Point-to-Point Protocol July 1990

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

Perkins [Page 26]

RFC 1171 Point-to-Point Protocol July 1990

4.4.4. Configure-

If some Configuration Options received in a Configure-Request
not recognizable or are not acceptable for negotiation (
configured by a network manager), then a LCP implementation
transmit a LCP packet with the Code field set to 4 (Configure
Reject), the Identifier field copied from the received Configure
Request, and the Options field filled with only the
Configuration Options from the Configure-Request.
recognizable and negotiable Configuration Options must be
out of the Configure-Reject, but otherwise the
Options MUST not be reordered

On reception of a Configure-Reject, the Identifier field
match that of the last transmitted Configure-Request, or
packet is invalid. Additionally, the Configuration Options in
Configure-Reject must be a proper subset of those in the
transmitted Configure-Request, or the packet is invalid.
packets should be silently discarded

Reception of a Configure-Reject indicates that a new Configure
Request should be sent which does 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

Perkins [Page 27]

RFC 1171 Point-to-Point Protocol July 1990

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

Perkins [Page 28]

RFC 1171 Point-to-Point Protocol July 1990

4.4.5. Terminate-Request and Terminate-

LCP includes Terminate-Request and Terminate-Ack Codes in order
provide a mechanism for closing a connection

A LCP implementation wishing to close a connection should
a LCP packet with the Code field set to 5 (Terminate-Request)
the Data field filled with any desired data. Terminate-
packets should continue to be sent until Terminate-Ack
received, the Physical Layer indicates that it has gone down, or
sufficiently large number have been transmitted such that
remote end is down with reasonable certainty

Upon reception of a Terminate-Request, a LCP packet MUST
transmitted with the Code field set to 6 (Terminate-Ack),
Identifier field copied from the Terminate-Request packet, and
Data field filled with any desired data

Reception of an unelicited Terminate-Ack indicates that
connection has been closed

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

The Identifier field is one octet and aids in matching
and replies

Perkins [Page 29]

RFC 1171 Point-to-Point Protocol July 1990

The Data field is zero or more octets and contains
data for use by the sender. The data may consist of any
value and may be of any length from zero to the
maximum Information field length minus four

Perkins [Page 30]

RFC 1171 Point-to-Point Protocol July 1990

4.4.6. Code-

Reception of a LCP packet with an unknown Code indicates that
of the communicating LCP implementations is faulty or incomplete
This error MUST be reported back to the sender of the unknown
by transmitting a LCP packet with the Code field set to 7 (Code
Reject), and the inducing packet copied to the Rejected-
field

Upon reception of a Code-Reject, a LCP implementation should
an immediate transition to the Closed state, and should report
error, since it is unlikely that the situation can be
automatically

A summary of the Code-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rejected-Packet ...
+-+-+-+-+-+-+-+-+

7 for Code-Reject

The Identifier field is one octet and is for use by
transmitter

Rejected-

The Rejected-Packet field contains a copy of the LCP packet
is being rejected. It begins with the rejected Code field;
does not include any PPP Data Link Layer headers. The Rejected
Packet should be truncated to comply with the established
Information field length

Perkins [Page 31]

RFC 1171 Point-to-Point Protocol July 1990

4.4.7. Protocol-

Reception of a PPP frame with an unknown Data Link Layer
indicates that the remote end is attempting to use a
which is unsupported at the local end. This typically occurs
the remote end attempts to configure a new, but
protocol. If the LCP state machine is in the Open state,
this error MUST be reported back to the sender of the
protocol by transmitting a LCP packet with the Code field set to 8
(Protocol-Reject), the Rejected-Protocol field set to the
Protocol, and the Data field filled with any desired data

Upon reception of a Protocol-Reject, a LCP implementation
stop transmitting frames of the indicated protocol

Protocol-Reject packets may only be sent in the LCP Open state
Protocol-Reject packets received in any state other than the
Open state should be discarded and no further action should
taken

A summary of the Protocol-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rejected-Protocol | Rejected-Information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8 for Protocol-Reject

The Identifier field is one octet and is for use by
transmitter

Rejected-

The Rejected-Protocol field is two octets and contains
Protocol of the Data Link Layer frame which is being rejected

Perkins [Page 32]

RFC 1171 Point-to-Point Protocol July 1990

Rejected-

The Rejected-Information field contains a copy from the
which is being rejected. It begins with the Information field
and does not include any PPP Data Link Layer headers or the FCS
The Rejected-Information field should be truncated to comply
the established maximum Information field length

Perkins [Page 33]

RFC 1171 Point-to-Point Protocol July 1990

4.4.8. Echo-Request and Echo-

LCP includes Echo-Request and Echo-Reply Codes in order to
a Data Link Layer loopback mechanism for use in exercising
directions of the link. This is useful as an aid in debugging
link quality determination, performance testing, and for
other functions

An Echo-Request sender transmits a LCP packet with the Code
set to 9 (Echo-Request) and the Data field filled with any
data, up to but not exceeding the receiver's established
Information field length minus eight

Upon reception of an Echo-Request, a LCP packet MUST
transmitted with the Code field set to 10 (Echo-Reply),
Identifier field copied from the received Echo-Request, and
Data field copied from the Echo-Request, truncating as
to avoid exceeding the peer's established maximum
field length

Echo-Request and Echo-Reply packets may only be sent in the
Open state. Echo-Request and Echo-Reply packets received in
state other than the LCP Open state should be discarded and
further action should be taken

A summary of the Echo-Request and Echo-Reply packet formats is
below. The fields are transmitted from left to right

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+

9 for Echo-Request

10 for Echo-Reply

Perkins [Page 34]

RFC 1171 Point-to-Point Protocol July 1990

The Identifier field is one octet and aids in matching Echo
Requests and Echo-Replies

Magic-

The Magic-Number field is four octets and aids in
loopbacked links. Unless modified by a Configuration Option,
Magic-Number MUST always be transmitted as zero and MUST always
ignored on reception. Further use of the Magic-Number is
the scope of this discussion

The Data field is zero or more octets and contains
data for use by the sender. The data may consist of any
value and may be of any length from zero to the
maximum Information field length minus eight

Perkins [Page 35]

RFC 1171 Point-to-Point Protocol July 1990

4.4.9. Discard-

LCP includes a Discard-Request Code in order to provide a
Link Layer data sink mechanism for use in exercising the local
remote direction of the link. This is useful as an aid
debugging