Back
Point-to-Point Protocol
Introduction
This document summarizes information contained in
RFC 1661 about Point-to-Point Protocol (PPP).
PPP is a data-link layer protocol for transporting network-layer packets between two peers.
It is a popular solution for dial-up Internet connections, and is
designed to work with many different hosts, bridges, and routers.
PPP provides full-duplex operation, and assumes that packets arrive in the same order that they were sent.
There are three main components to PPP:
- A method for encapsulating multiple network-layer protocols.
- A protocol for initializing a connection.
- Protocols for managing the needs of specific network-layer protocols.
Encapsulation
PPP allows multiple network-layer protocols to be multiplexed over a single link. For example, IP and IPX traffic can operate simultaneously on the same PPP link. The following diagram summarizes the format of PPP encapsulation:
| Protocol Field |
Information Field |
| Packet Data |
Padding |
| one or two octets |
zero or more octets |
arbitrary |
The protocol field is one or two octets, and its value identifies the protocol of the packet being encapsulated. The information field is zero or more octets and contains the packet for the protocol specified in the protocol field. The maximum size of the information field, called the Maximum Receive Unit (MRU), is implementation dependent. The default value is 1500 octets. The information field may be padded with an arbitrary number of octets. The network-layer protocol is responsible for distinguishing packet data from padding.
Link Control Protocol (LCP)
The connection is established using the Link Control Protocol (LCP). Each end of the link must send LCP packets to configure and test the link. Only options that are independent of specific network-layer protocols are configured by the LCP. Any configuration options not altered during this exchange will assume the default values. This exchange is complete when configuration acknowledgments have been sent and received.
Authentication is optional under PPP by default. If an implementation desires that the peer authenticate, then it must indicate a specific authentication protocol when the link is being established. Authentication should occur after the link is established, but before the network-layer protocols are configured. Testing of the link may occur concurrently with authentication.
Network Control Protocols (NCPs)
Once the link is initialized, each network-layer protocol to be transmitted over the PPP link must be configured by the appropriate Network Control Protocol (NCP). NCP's for many protocols exist, including IP, IPX, Appletalk, and transparent Ethernet bridging. NCP's may be opened or closed at any time. After a NCP has been opened, the PPP link can transport the corresponding protocol packets.
A PPP link can be terminated at any time. To close the link, the LCP exchanges several terminate packets with the peer. The LCP also informs the network-layer protocols when the link is closing so that they may take any appropriate actions. The implementation may then signal the physical-layer to disconnect.
Option Negotiation Automaton
The LCP is used to establish the connection through an exchange of Configure packets.
This exchange of Configure packets is outlined in a finite-state automaton.
It is defined in terms of events,
states, and actions.
In the state transition table below, states are indicated
horizontally, and events are read vertically. State transitions and
actions are represented in the form action/new-state.
If there are multiple actions, they will be separated by commas.
Please note that this table and the information that follows
is taken almost directly from RFC 1661.
| State
| 0 1 2 3 4 5 6 7 8 9
Events| Initial Starting Closed Stopped Closing Stopping Req-Sent Ack-Rcvd Ack-Sent Opened
------+----------------------------------------------------------------------------------------------------
Up | 2 irc,scr/6 - - - - - - - -
Down | - - 0 tls/1 0 1 1 1 1 tld/1
Open | tls/1 1 irc,scr/6 3 5 5 6 7 8 9
Close| 0 tlf/0 2 2 4 4 irc,str/4 irc,str/4 irc,str/4 tld,irc,str/4
|
TO+ | - - - - str/4 str/5 scr/6 scr/6 scr/8 -
TO- | - - - - tlf/2 tlf/3 tlf/3 tlf/3 tlf/3 -
|
RCR+ | - - sta/2 irc,scr,sca/8 4 5 sca/8 sca,tlu/9 sca/8 tld,scr,sca/8
RCR- | - - sta/2 irc,scr,scn/6 4 5 scn/6 scn/7 scn/6 tld,scr,scn/6
RCA | - - sta/2 sta/3 4 5 irc/7 scr/6 irc,tlu/9 tld,scr/6
RCN | - - sta/2 sta/3 4 5 irc,scr/6 scr/6 irc,scr/8 tld,scr/6
|
RTR | - - sta/2 sta/3 sta/4 sta/5 sta/6 sta/6 sta/6 tld,zrc,sta/5
RTA | - - 2 3 tlf/2 tlf/3 scj/6 scj/7 scj/8 scj/9
|
RUC | - - scj/2 scj/3 scj/4 scj/5 6 6 8 tld,scr/6
RXJ+ | - - 2 3 4 5 6 6 8 9
RXJ- | - - tlf/2 tlf/3 tlf/2 tlf/3 tlf/3 tlf/3 tlf/3 tld,irc,str/5
|
RXR | - - 2 3 4 5 6 7 8 ser/9
States
The automaton states are described below.
These definitions are taken directly from
RFC 1661.
Initial
In the Initial state, the lower layer is unavailable (Down), and
no Open has occurred. The Restart timer is not running in the
Initial state.
Starting
The Starting state is the Open counterpart to the Initial state.
An administrative Open has been initiated, but the lower layer is
still unavailable (Down). The Restart timer is not running in the
Starting state.
When the lower layer becomes available (Up), a Configure-Request
is sent.
Closed
In the Closed state, the link is available (Up), but no Open has
occurred. The Restart timer is not running in the Closed state.
Upon reception of Configure-Request packets, a Terminate-Ack is
sent. Terminate-Acks are silently discarded to avoid creating a
loop.
Stopped
The Stopped state is the Open counterpart to the Closed state. It
is entered when the automaton is waiting for a Down event after
the This-Layer-Finished action, or after sending a Terminate-Ack.
The Restart timer is not running in the Stopped state.
Upon reception of Configure-Request packets, an appropriate
response is sent. Upon reception of other packets, a Terminate-
Ack is sent. Terminate-Acks are silently discarded to avoid
creating a loop.
The rationale behind the Stopped state is that it provides a
junction state for link termination,
link configuration failure, and other automaton failure modes.
These potentially separate states have been combined.
Closing
In the Closing state, an attempt is made to terminate the
connection. A Terminate-Request has been sent and the Restart
timer is running, but a Terminate-Ack has not yet been received.
Upon reception of a Terminate-Ack, the Closed state is entered.
Upon the expiration of the Restart timer, a new Terminate-Request
is transmitted, and the Restart timer is restarted. After the
Restart timer has expired Max-Terminate times, the Closed state is
entered.
Stopping
The Stopping state is the Open counterpart to the Closing state.
A Terminate-Request has been sent and the Restart timer is
running, but a Terminate-Ack has not yet been received.
The rationale for the
Stopping state is that it provides a well defined opportunity to
terminate a link before allowing new traffic. After the link
has terminated, a new configuration may occur from either the Stopped
or Starting states.
Request-Sent
In the Request-Sent state an attempt is made to configure the
connection. A Configure-Request has been sent and the Restart
timer is running, but a Configure-Ack has not yet been received
nor has one been sent.
Ack-Received
In the Ack-Received state, a Configure-Request has been sent and a
Configure-Ack has been received. The Restart timer is still
running, since a Configure-Ack has not yet been sent.
Ack-Sent
In the Ack-Sent state, a Configure-Request and a Configure-Ack
have both been sent, but a Configure-Ack has not yet been
received. The Restart timer is running, since a Configure-Ack has
not yet been received.
Opened
In the Opened state, a Configure-Ack has been both sent and
received. The Restart timer is not running.
When entering the Opened state, the implementation should signal
the upper layers that it is now Up. Conversely, when leaving the
Opened state, the implementation should signal the upper layers
that it is now Down.
Events
Transitions and actions in the automaton are caused by the events below.
Their definitions are taken from RFC 1661.
Up
This event occurs when a lower layer indicates that it is ready to
carry packets.
Typically, this event is used by a modem handling or calling
process, or by some other coupling of the PPP link to the physical
media, to signal LCP to establish the connection.
Down
This event occurs when a lower layer indicates that it is no
longer ready to carry packets.
Typically, this event is used by a modem handling or calling
process, or by some other coupling of the PPP link to the physical
media, to signal LCP that the link is returning to either
the Initial or Starting states.
Open
This event indicates that the link is administratively available
for traffic; that is, the network administrator (human or program)
has indicated that the link is allowed to be Opened. When this
event occurs, and the link is not in the Opened state, the
automaton attempts to send configuration packets to the peer.
Close
This event indicates that the link is not available for traffic;
that is, the network administrator (human or program) has
indicated that the link is not allowed to be Opened. When this
event occurs, and the link is not in the Closed state, the
automaton attempts to terminate the connection. Futher attempts
to re-configure the link are denied until a new Open event occurs.
Timeout (TO+,TO-)
This event indicates the expiration of the Restart timer. The
Restart timer is used to time responses to Configure-Request and
Terminate-Request packets.
The TO+ event indicates that the Restart counter continues to be
greater than zero, which triggers the corresponding Configure-
Request or Terminate-Request packet to be retransmitted.
The TO- event indicates that the Restart counter is not greater
than zero, and no more packets need to be retransmitted.
Receive-Configure-Request (RCR+,RCR-)
This event occurs when a Configure-Request packet is received from
the peer. The Configure-Request packet indicates the desire to
open a connection and may specify Configuration Options. The
Configure-Request packet is more fully described in a later
section.
The RCR+ event indicates that the Configure-Request was
acceptable, and triggers the transmission of a corresponding
Configure-Ack.
The RCR- event indicates that the Configure-Request was
unacceptable, and triggers the transmission of a corresponding
Configure-Nak or Configure-Reject.
Receive-Configure-Ack (RCA)
This event occurs when a valid Configure-Ack packet is received
from the peer. The Configure-Ack packet is a positive response to
a Configure-Request packet. An out of sequence or otherwise
invalid packet is silently discarded.
Receive-Configure-Nak/Rej (RCN)
This event occurs when a valid Configure-Nak or Configure-Reject
packet is received from the peer. The Configure-Nak and
Configure-Reject packets are negative responses to a Configure-
Request packet. An out of sequence or otherwise invalid packet is
silently discarded.
Receive-Terminate-Request (RTR)
This event occurs when a Terminate-Request packet is received.
The Terminate-Request packet indicates the desire of the peer to
close the connection.
This event is not identical to the Close event (see above), and
does not override the Open commands of the local network
administrator. The implementation must be prepared to receive
a new Configure-Request without network administrator
intervention.
Receive-Terminate-Ack (RTA)
This event occurs when a Terminate-Ack packet is received from the
peer. The Terminate-Ack packet is usually a response to a
Terminate-Request packet. The Terminate-Ack packet may also
indicate that the peer is in Closed or Stopped states, and serves
to re-synchronize the link configuration.
Receive-Unknown-Code (RUC)
This event occurs when an un-interpretable packet is received from
the peer. A Code-Reject packet is sent in response.
Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-)
This event occurs when a Code-Reject or a Protocol-Reject packet
is received from the peer.
The RXJ+ event arises when the rejected value is acceptable, such
as a Code-Reject of an extended code, or a Protocol-Reject of a
NCP. These are within the scope of normal operation. The
implementation must stop sending the offending packet type.
The RXJ- event arises when the rejected value is catastrophic,
such as a Code-Reject of Configure-Request, or a Protocol-Reject
of LCP! This event communicates an unrecoverable error that
terminates the connection.
Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request
(RXR)
This event occurs when an Echo-Request, Echo-Reply or Discard-
Request packet is received from the peer. The Echo-Reply packet
is a response to an Echo-Request packet. There is no reply to an
Echo-Reply or Discard-Request packet.
Actions
Actions in the automaton are caused by events. Typically they
indicate the transmission of packets and/or the starting or stopping of the
Restart timer.
Their descriptions come from RFC 1661.
Illegal-Event (-)
This indicates an event that cannot occur in a properly
implemented automaton. The implementation has an internal error,
which should be reported and logged. No transition is taken, and
the implementation should NOT reset or freeze.
This-Layer-Up (tlu)
This action indicates to the upper layers that the automaton is
entering the Opened state.
Typically, this action is used by the LCP to signal the Up event
to a NCP, Authentication Protocol, or Link Quality Protocol.
This-Layer-Down (tld)
This action indicates to the upper layers that the automaton is
leaving the Opened state.
Typically, this action is used by the LCP to signal the Down event
to a NCP, Authentication Protocol, or Link Quality Protocol.
This-Layer-Started (tls)
This action indicates to the lower layers that the automaton is
entering the Starting state, and the lower layer is needed for the
link. The lower layer should respond with an Up event when the
lower layer is available.
This results of this action are highly implementation dependent.
This-Layer-Finished (tlf)
This action indicates to the lower layers that the automaton is
entering the Initial, Closed or Stopped states, and the lower
layer is no longer needed for the link. The lower layer should
respond with a Down event when the lower layer has terminated.
Typically, this action MAY be used by the LCP to advance to the
Initial or Starting states, or MAY be used by a NCP to indicate to the LCP
that the link may terminate when there are no other NCPs open.
This results of this action are highly implementation dependent.
Initialize-Restart-Count (irc)
This action sets the Restart counter to the appropriate value
(Max-Terminate or Max-Configure). The counter is decremented for
each transmission, including the first.
In addition to setting the Restart counter, the implementation
must set the timeout period to the initial value when Restart
timer backoff is used.
Zero-Restart-Count (zrc)
This action sets the Restart counter to zero.
It enables the automaton to pause before proceeding to the
desired final state, allowing traffic to be processed by the
peer. In addition to zeroing the Restart counter, the
implementation must set the timeout period to an appropriate
value.
Send-Configure-Request (scr)
A Configure-Request packet is transmitted. This indicates the
desire to open a connection with a specified set of Configuration
Options. The Restart timer is started when the Configure-Request
packet is transmitted, to guard against packet loss. The Restart
counter is decremented each time a Configure-Request is sent.
Send-Configure-Ack (sca)
A Configure-Ack packet is transmitted. This acknowledges the
reception of a Configure-Request packet with an acceptable set of
Configuration Options.
Send-Configure-Nak (scn)
A Configure-Nak or Configure-Reject packet is transmitted, as
appropriate. This negative response reports the reception of a
Configure-Request packet with an unacceptable set of Configuration
Options.
Configure-Nak packets are used to refuse a Configuration Option
value, and to suggest a new, acceptable value. Configure-Reject
packets are used to refuse all negotiation about a Configuration
Option, typically because it is not recognized or implemented.
The use of Configure-Nak versus Configure-Reject is more fully
described in the chapter on LCP Packet Formats.
Send-Terminate-Request (str)
A Terminate-Request packet is transmitted. This indicates the
desire to close a connection. The Restart timer is started when
the Terminate-Request packet is transmitted, to guard against
packet loss. The Restart counter is decremented each time a
Terminate-Request is sent.
Send-Terminate-Ack (sta)
A Terminate-Ack packet is transmitted. This acknowledges the
reception of a Terminate-Request packet or otherwise serves to
synchronize the automatons.
Send-Code-Reject (scj)
A Code-Reject packet is transmitted. This indicates the reception
of an unknown type of packet.
Send-Echo-Reply (ser)
An Echo-Reply packet is transmitted. This acknowledges the
reception of an Echo-Request packet.
Restart Timer
There is one special timer used by the automaton. The Restart
timer is used to time transmissions of Configure-Request and
Terminate-Request packets. Expiration of the Restart timer causes
a Timeout event, and retransmission of the corresponding
Configure-Request or Terminate-Request packet.
Restart Counter
A restart counter is used for keep track of how many
Terminate-Request or Configure-Request packets have
been sent without a response.
The value Max-Terminate indicates the number of Terminate-Request packets
sent without receiving a Terminate-Ack before assuming that the
peer is unable to respond.
The value Max-Configure represents the number of Configure-Request packets sent
without receiving a valid Configure-Ack, Configure-Nak or
Configure-Reject before assuming that the peer is unable to
respond.
LCP Packets
The various kinds of LCP packets are described below.
These descriptions are from RFC 1661.
Configure-Request
An implementation wishing to open a connection must transmit a
Configure-Request. It is is filled with any desired
changes to the link defaults. Configuration Options should NOT be
included with default values.
Upon reception of a Configure-Request, an appropriate reply must
be transmitted.
Configure-Ack
If every Configuration Option received in a Configure-Request is
recognizable and all values are acceptable, then the
implementation must transmit a Configure-Ack.
Configure-Nak
If every instance of the received Configuration Options is
recognizable, but some values are not acceptable, then the
implementation must transmit a Configure-Nak. It will be filled
with only the unacceptable Configuration Options from
the Configure-Request.
Configure-Reject
If some Configuration Options received in a Configure-Request are
not recognizable or are not acceptable for negotiation (as
configured by a network administrator), then the implementation
must transmit a Configure-Reject. It will be filled
with only the unacceptable Configuration Options from the
Configure-Request. All recognizable and negotiable Configuration
Options are filtered out of the Configure-Reject.
Terminate-Request and Terminate-Ack
LCP includes Terminate-Request and Terminate-Ack Codes in order to
provide a mechanism for closing a connection.
An implementation wishing to close a connection should transmit a
Terminate-Request. Terminate-Request packets should continue to
be sent until Terminate-Ack is received, the lower layer indicates
that it has gone down, or a sufficiently large number have been
transmitted such that the peer is down with reasonable certainty.
Upon reception of a Terminate-Request, a Terminate-Ack must be
transmitted.
Code-Reject
Reception of a LCP packet with an unknown Code indicates that the
peer is operating with a different version. This must be reported
back to the sender of the unknown Code by transmitting a Code-
Reject.
Protocol-Reject
Reception of a PPP packet with an unknown Protocol field indicates
that the peer is attempting to use a protocol which is
unsupported. This usually occurs when the peer attempts to
configure a new protocol. If the LCP automaton is in the Opened
state, then this must be reported back to the peer by transmitting
a Protocol-Reject.
Echo-Request and Echo-Reply
LCP includes Echo-Request and Echo-Reply Codes in order to provide
a Data Link Layer loopback mechanism for use in exercising both
directions of the link. This is useful as an aid in debugging,
link quality determination, performance testing, and for numerous
other functions.
Upon reception of an Echo-Request in the LCP Opened state, an
Echo-Reply must be transmitted.
Discard-Request
LCP includes a Discard-Request Code in order to provide a Data
Link Layer sink mechanism for use in exercising the local to
remote direction of the link. This is useful as an aid in
debugging, performance testing, and for numerous other functions.
Prepared by Don Barnes <don@dbarnes.com>
For CS 555, Fall 1999