As per Relevance of the word identifier, we have this rfc below:
Network Working Group D.
Request for Comments: 1134
November 1989
The Point-to-Point Protocol: A Proposal for Multi-
Transmission of Datagrams Over Point-to-Point
Table of
Status of this Memo ................................... 2
Abstract .............................................. 2
1. Introduction ....................................... 2
1.1 Motivation ........................................ 2
1.2 Overview of PPP ................................... 3
1.3 Organization of the document ...................... 4
2. Physical Layer Requirements ........................ 4
3. The Data Link Layer ................................ 4
3.1 Frame Format ...................................... 5
4. The PPP Link Control Protocol (LCP) ................ 8
4.1 The LCP Automaton ................................. 9
4.1.1 Overview ........................................ 9
4.1.2 State Diagram ................................... 10
4.1.3 State Transition Table .......................... 12
4.1.4 Events .......................................... 12
4.1.5 Actions ......................................... 14
4.1.6 States .......................................... 16
4.2 Loop Avoidance .................................... 19
4.3 Packet Format ..................................... 19
4.3.1 Configure-Request ............................... 21
4.3.2 Configure-Ack ................................... 21
4.3.3 Configure-Nak ................................... 22
4.3.4 Configure-Reject ................................ 24
4.3.5 Terminate-Request and Terminate-Ack ............. 25
4.3.6 Code-Reject ..................................... 26
4.3.7 Protocol-Reject ................................. 27
4.3.8 Echo-Request and Echo-Reply ..................... 28
4.3.9 Discard-Request ................................. 29
4.4 Configuration Options ............................. 30
4.4.1 Format .......................................... 31
5. A PPP Network Control Protocol (NCP) for IP ........ 32
5.1 Sending IP Datagrams .............................. 33
APPENDICES ............................................ 33
A. Asynchronous HDLC .................................. 33
B. Fast Frame Check Sequence (FCS) Implementation ..... 35
B.1 FCS Computation Method ............................ 35
B.2 Fast FCS table generator .......................... 36
Perkins [Page 1]
RFC 1134 PPP November 1989
REFERENCES ............................................ 37
AUTHOR'S ADDRESS ...................................... 38
Status of this
This memo defines a proposed protocol for the Internet community
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 by January 15, 1990. Comments will be reviewed at
February 1990 IETF meeting, with the goal of advancing PPP to
standard status. 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
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
Perkins [Page 2]
RFC 1134 PPP November 1989
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 switched point-to
point circuits (e.g., dialups).
Some additional issues addressed by PPP include
(start/stop) and bit-oriented synchronous encapsulation,
protocol multiplexing, link configuration, link quality testing
error detection, and option negotiation for such capabilities
network-layer address negotiation and data 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
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
Perkins [Page 3]
RFC 1134 PPP November 1989
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
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 switched,
can operate in either an asynchronous (start/stop) or
bit-serial mode, transparent to PPP Data Link Layer frames. PPP
not impose any restrictions regarding transmission rate, other
those imposed by the particular DTE/DCE interface in 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
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
Perkins [Page 4]
RFC 1134 PPP November 1989
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
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 | 1111111 | 0000011 | 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
Perkins [Page 5]
RFC 1134 PPP November 1989
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.
with other Addresses should be silently discarded
Control
The Control field is a single octet and contains the
sequence 00000011 (hexadecimal 0x03), the Unnumbered
(UI) command with the P/F bit is 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 [11]. 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 1134 PPP November 1989
The Protocol field is initially assigned as follows
Value (in hex)
0001 to 001f reserved (transparency inefficient
0021 Internet
0023 * ISO
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 * ISO CLNP 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 1134 PPP November 1989
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] and [8].
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
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
Perkins [Page 8]
RFC 1134 PPP November 1989
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
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
4.1. The LCP
4.1.1.
LCP is specified by a number of packet formats and a finite-
automation. This section presents an overview of the LCP automation
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
Perkins [Page 9]
RFC 1134 PPP November 1989
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 automation 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 automation is given
a state transition table in the following section,
should be done by consulting it rather than this state diagram
Perkins [Page 10]
RFC 1134 PPP November 1989
+------------------------------+
| |
V |
+---2---+ PO +---1---+ RTA +---7---+ |
| |<-------------| |<-----------| | |
|Listen | |Closed | |Closing| |
RCR | | C | | PLD | | |
+----| |----->+------>| |<---Any | |<--+ |
|scr +-------+ ^ +-------+ State +-------+ | |
| | AO | ^ | TO | |
| +-----------+ --- | | +---->+ |
| | SCR | C | str ^ |
| C | RCN/TO | +----------------+ | |
| -- | +-------->+<--------+ | str | |
| | | 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-Nak
RTR - Receive-Terminate-Req
RTA - Receive-Terminate-Ack str - Send Terminate-
AO - Active-Open sta - Sent Terminate-
PO - Passive-
C -
TO -
PLD - Physical-Layer-
Perkins [Page 11]
RFC 1134 PPP November 1989
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/1 scj/1 scj/1 scj/1 scj/1 1 scj/1
RER | sta/1 sta/2 3 4 5 ser/1 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 still others
caused by the expiration of the Restart timer started as the
of other events (e.g., Timeout).
Following is a list of LCP events
Perkins [Page 12]
RFC 1134 PPP November 1989
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-
packet is received from the LCP peer. The Configure-Ack packet
a positive response to a Configure-Request packet
Perkins [Page 13]
RFC 1134 PPP November 1989
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
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
Perkins [Page 14]
RFC 1134 PPP November 1989
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
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
Perkins [Page 15]
RFC 1134 PPP November 1989
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
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
Perkins [Page 16]
RFC 1134 PPP November 1989
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-
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
Perkins [Page 17]
RFC 1134 PPP November 1989
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
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
Perkins [Page 18]
RFC 1134 PPP November 1989
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
For example, implementations could take care to avoid Configure
Request or Terminate-Request livelocks by using a Max-
counter. A Configure-Request livelock could occur when
originating PPP sends and re-sends a C-R without receiving a
(e.g., the receiving PPP entity may have died). A Terminate-
livelock could occur when the originating PPP sends and re-sends
T-R without receiving a Terminate-Ack (e.g., the T-A may have
lost, but the remote PPP may have already terminated). Max-
indicates the number of packet retransmissions that are
before there is reasonable assurance that a livelock
exists. Max-Retries MUST also be configurable, but should default
ten (10) retransmissions
4.3 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
Perkins [Page 19]
RFC 1134 PPP November 1989
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
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 20]
RFC 1134 PPP November 1989
4.3.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
4.3.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
Perkins [Page 21]
RFC 1134 PPP November 1989
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
acknowledging. All Configuration Options are always
simultaneously
4.3.3. Configure-
If every element of the received Configuration Options
Perkins [Page 22]
RFC 1134 PPP November 1989
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
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
Perkins [Page 23]
RFC 1134 PPP November 1989
zero or more Configuration Options that the sender is nak'ing
All Configuration Options are always nak'd simultaneously
4.3.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 24]
RFC 1134 PPP November 1989
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
4.3.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
Perkins [Page 25]
RFC 1134 PPP November 1989
The Identifier field is one octet and aids in matching
and replies
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 established
for the peer's MRU
4.3.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
Perkins [Page 26]
RFC 1134 PPP November 1989
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 value
the peer's MRU
4.3.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
Perkins [Page 27]
RFC 1134 PPP November 1989
transmitter
Rejected-
The Rejected-Protocol field is two octets and contains
Protocol of the Data Link Layer frame which is being rejected
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 value of the peer's MRU
4.3.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 receivers established MRU
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 MRU
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
Perkins [Page 28]
RFC 1134 PPP November 1989
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
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 established
for the peer's MRU
4.3.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, performance testing, and and for numerous
functions
A discard sender transmits a LCP packet with the Code field set
11 (Discard-Request) and the Data field filled with any
Perkins [Page 29]
RFC 1134 PPP November 1989
data, up to but not exceeding the receivers established MRU
A discard receiver MUST simply throw away an Discard-Request
it receives
Discard-Request packets may only be sent in the LCP Open state
A summary of the Discard-Request packet formats 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
11 for Discard-Request
The Identifier field is one octet and is for use by the Discard
Request transmitter
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 established
for the peer's MRU
4.4. Configuration
LCP Configuration Options allow modifications to the
characteristics of a point-to-point link to be negotiated
Perkins [Page 30]
RFC 1134 PPP November 1989
Negotiable modifications include such things as the maximum
unit, async control character mapping, the link
method, the link encryption method, etc.. The Configuration
themselves are described in separate documents. If a
Option is not included in a Configure-Request packet, the
value for that Configuration Option is assumed
The end of the list of Configuration Options is indicated by the
of the LCP packet
Unless otherwise specified, a specific Configuration Options
be listed no more than once in a Configuration Options list
Specific Configuration Options may override this general rule and
be listed more than once. The effect of this is Configuration
specific and is specified by each such Configuration Option
Also unless otherwise specified, all Configuration Options apply in
half-duplex fashion. When negotiated, they apply to only
direction of the link, typically in the receive direction
interpreted from the point of view of the Configure-Request sender
4.4.1.
A summary of the Configuration Option format is shown below.
fields are transmitted from left to right
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | D