As first introduced in Chapter 2, “Wide Area Network (WAN) Technologies,” PPP is a
standard for using point-to-point network links that provides the following:
■ A Data Link Layer encapsulation method that supports multiple protocols simultaneously on the same link.
■ A protocol for negotiating the Data Link Layer characteristics of the point-to-point
connection named the Link Control Protocol (LCP).
■ A series of protocols for negotiating the Network Layer properties of Network Layer
protocols over the point-to-point connection named Network Control Protocols (NCPs).
For example, RFCs 1332 and 1877 describe the Internet Protocol Control Protocol
(IPCP), the NCP for IP. IPCP is used to negotiate an IP address, the addresses of name
servers, and the use of the Van Jacobsen TCP compression protocol.
PPP Connection Process
 There are four phases to a PPP connection, all of which





must be completed before data can be
sent on the connection. The four phases are the
following
1. PPP configuration using LCP
2. Authentication using a PPP authentication
protocol (optional
3. Callback
4. Protocol configuration using NCPs
Phase 1: PPP Configuration Using LCP
 In the first phase of the PPP connection process, PPP connection parameters are
configured
 using LCP. With LCP, the PPP peers negotiate a common set of parameters that are used
for all
 subsequent phases of the PPP connection and for sending data. Some of the
communication
 parameters that are negotiated are the following:
 ■ The maximum receive unit (MRU), the largest PPP frame that can be sent on the
 connection
 ■ Whether the Address and Control fields in the PPP header are used (for links that use
 the High-Level Data Link Control [HDLC] encapsulation that is described in RFC 1662)
 ■ Whether the Protocol field in the PPP header can be compressed from 2 bytes to 1 byte
 ■ The PPP authentication protocol to be used during the authentication phase
 ■ Whether Multilink PPP (MP) is used
 For more information, see the section titled “Link Control Protocol,” later in this chapter.
Phase 2: Authentication
 After LCP negotiation, the authentication process
using the PPP authentication protocol nego tiated during phase 1 is performed. This process is
specific to the PPP authentication protocol
 used. For more information, see the section titled “PPP
Authentication Protocols” later in
 this chapter
Phase 3: Callback
 If the authentication process succeeds and callback





behavior is configured, the answering PPP
peer terminates the connection and initiates a connection
to the original calling PPP peer, a
feature of PPP implementations known as callback. The
PPP implementation in Windows
Server 2008 and Windows Vista uses the Callback Control
Protocol (CBCP) to complete the
callback phase. For more information, see the section titled
“Callback and the Callback
Control Protocol,” later in this chapter.
Phase 4: Protocol Configuration Using NCPs
 After PPP is configured, the original initiating PPP
peer is authenticated, and callback is done
 (optional and only if configured), individual data
protocols and ancillary PPP services such
 as encryption and compression are configured using
NCPs. For more information, see the
 section titled “Network Control Protocols,” later in this
chapter.
PPP Connection Termination
 After a PPP connection is established, it can be




terminated at any time by either the connection-initiating or connection-receiving PPP peer. PPP
connections can be terminated by user
action, connection policy action (such as terminating
the connection after a specific amount
of idle time), or link failure. When the PPP connection
terminates, PPP informs the data protocols that were operating over it that the point-topoint interface is no longer available.
Link Control Protocol
 LCP, described in RFC 1661, is a simple protocol to configure a







common set of PPP connection parameters (for phase 1 of the PPP connection). It is also
used by NCPs to configure
specific data protocol configuration parameters (for phase 2 of
the PPP connection). LCP
uses the PPP Protocol ID 0xC0-21. Figure 4-1 shows an LCP f
■ Code A 1-byte field that identifies the type of LCP message
■ Identifier A 1-byte field that identifies a specific pair of LCP
messages: the request and
■ Length A 2-byte length field that indicates the size of the LCP
message in bytes
■ Data A variable-sized field that contains the LCP frame typespecific data
LCP Options
 The data portion of an LCP message consists of one or





more LCP options for the ConfigureRequest, Configure-Ack, Configure-Nak, and ConfigureReject LCP frames. An LCP option
is formatted in type-length-value (TLV) format. A 1-byte
Type field indicates the option type,
a 1-byte Length field indicates the length in bytes of the
entire option, and the Option
Data field contains the data of the option. Figure 4-2 shows
an LCP message that contains
LCP options.
LCP Negotiation Process














LCP is used to negotiate the parameters of PPP when sending data in a single direction on the
PPP connection. Different PPP parameters could be negotiated in the two different directions
of data travel on a PPP connection. Therefore, each PPP peer must perform a separate LCP
negotiation. An LCP negotiation is used by a PPP peer to establish how the other PPP peer
should send data to it. Each LCP negotiation is a series of LCP frames to negotiate the use of
a common set of parameters for data sent by the PPP peer on the other side of the PPP connection from the LCP negotiation initiator. For two PPP peers, Peer A and Peer B, Peer A initiates an LCP negotiation for the data to be sent by Peer B and Peer B initiates a separate LCP
negotiation for the data to be sent by Peer A.
An individual LCP negotiation consists of an initial set of LCP options using the LCP Configure-Request message. The specific set of LCP options is negotiated using Configure-Nak and
Configure-Reject messages and finally confirmed with a Configure-Ack message. Both negotiations occur simultaneously, making it more difficult to read the captures of PPP connection
establishments.
PPP Authentication Protocols
 After LCP negotiation is complete, the authentication protocol agreed on
during LCP negotia tion using LCP option 3 is used to establish the identity and credentials of the
PPP peer that is
 requesting the PPP connection, typically a remote access client (for remote
access dial-up or vir tual private network [VPN] connections) or a calling router (for router-torouter dial-up or VPN
 connections). The authentication process is phase 2 of the PPP connection
establishment.
 Windows Server 2008 and Windows Vista support the following PPP
authentication protocols:
 ■ Password Authentication Protocol (PAP)
 ■ Challenge Handshake Authentication Protocol (CHAP)
 ■ Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAP v2)
 ■ Extensible Authentication Protocol (EAP)
PAP














PAP is a very simple, plain-text authentication protocol described in RFC 1334. The entire PAP
negotiation consists of the following messages:
1. The connection-initiating PPP peer (the calling peer) sends a PAP Authenticate-Request
message to the authenticating PPP peer (the answering peer), which contains the calling
peer’s user name and password in plain-text.
2. The answering peer validates the user name and password. If the user name and password are correct, the answering peer sends a PAP Authenticate-Ack message. If not, the
answering peer sends a PAP Authenticate-Nak message.
Obviously, PAP is not a secure authentication protocol. A malicious user that can capture the
PAP frames sent between the calling peer and answering peer can view the contents of the PAP
Authenticate-Request message to determine the user name and password of a valid user
account. The use of PAP is highly discouraged and is only included in Windows Server 2008
and Windows Vista for troubleshooting and compatibility with PPP peers that do not support
more secure authentication protocols.
CHAP
 CHAP is a more secure authentication protocol, described





in RFC 1994, which uses a
challenge–response exchange of messages to validate that
the calling peer has knowledge of
the user’s password. The password itself is never sent.
Although more secure than PAP, CHAP
does not provide mutual authentication. The calling peer
authenticates to the answering peer
but the answering peer does not authenticate to the calling
peer. Without mutual authentication, a calling peer is unable to determine whether it is
calling a valid answering peer.
MS-CHAP v2
 MS-CHAP v2 is a CHAP-based authentication protocol





described in RFC 2759 that, unlike
CHAP, provides mutual authentication. With MS-CHAP
v2, the answering peer receives
confirmation that the calling peer has knowledge of the
user account’s password and the calling peer receives confirmation that the answering peer has
knowledge of the user account’s
password. To provide for this mutual authentication, both
peers issue a challenge and must
receive a valid response or the connection is terminated
EAP
 EAP was designed as an extension to PPP to allow for more extensibility and
flexibility in the
 implementation of authentication methods for PPP connections. For PAP,
CHAP, and MS CHAP v2, the authentication process is a fixed exchange of messages. With
EAP, the authenti cation process can consist of an open-ended conversation, in which messages
are sent by
 either PPP peer on an as-needed basis. In addition, unlike the PPP
authentication protocols
 discussed so far in this chapter, EAP does not select a specific authentication
method during
 phase 1 of the connection. Rather, the selection of a specific EAP
authentication method,
 known as an EAP type, is done during phase 3 of the connection. EAP is
described in
 RFC 3748.
Callback and the Callback Control Protocol
 After the authentication phase of the PPP connection process,






CBCP negotiates the use of callback. If callback is negotiated, the answering PPP peer
terminates the PPP connection, and
then calls the original calling PPP peer at a specified phone
number. CBCP messages use the
PPP Protocol ID 0xC0-29 and have the same structure as LCP
messages. However, only the
first seven LCP message types are used, corresponding to LCP
Codes 1 through 3. For the
Callback-Request (Code set to 1), Callback-Response (Code set to
2), and Callback-Ack (Code
set to 3) messages, the data portion of the CBCP message
contains one or more CBCP options.
Network Control Protocols
 After the callback phase of the PPP connection
process, individual NCPs are used to negotiate
 the configuration of networking protocols, such as
TCP/IP, and the additional PPP facilities of
 compression and encryption.
IPCP
 PCP is used to automatically configure TCP/IP




configuration for a calling PPP peer. IPCP as
used by Windows-based PPP peers is described in
RFCs 1332 and 1877. RFC 1332 defines
the original set of IPCP options and RFC 1877 defines
an additional set of options to automatically configure the IP address of name servers such as
Domain Name System (DNS) and Windows Internet Name Service (WINS) servers.
Compression Control Protocol
 Compression Control Protocol (CCP), described in RFC






1962, allows PPP peers to negotiate
the use of a data compression algorithm. CCP messages use
the PPP Protocol 0x80-FD and
have the same structure as LCP messages. However, only
the first seven LCP message types
are used, corresponding to LCP Codes 1 through 7. For the
Configure-Request (Code set
to 1), Configure-Ack (Code set to 2), Configure-Nak (Code
set to 3), and Configure-Reject
(Code set to 4) CCP messages, the data portion of the CCP
message contains one or more
CCP options. Table 4-6 lists these CCP options.
Encryption Control Protocol
 Encryption Control Protocol (ECP), described in RFC




1968, allows PPP peers to negotiate the
use of a data encryption algorithm. ECP messages use
the PPP Protocol IDs 0x80-53 or 0x8055 and have the same structure as LCP messages.
However, because Windows-based PPP
peers only support the use of MPPE for encryption of
PPP payloads, ECP is not supported or
used. For more information, see RFC 1968.
Network Monitor Example
 The following summary of Capture 04-01 in the \Captures folder







on the companion CD-ROM
is an example of a successful PPP connection using the MSCHAP v2 authentication protocol
In this example, the following frames show the four phases of the
PPP connection:
■ Frames 1 through 8 and frames 10 and 11 are for phase 1, the
LCP negotiation.
■ Frames 9, 12, and 13 are for phase 2, authentication.
■ Frames 14 through 16 are for phase 3, callback.
■ Frames 16, 19, 20, and 23 are for CCP negotiation (in phase 4).
■ Frames 18, 21, 22, and 24 through 28 are for IPCP negotiation
(in phase 4).
PPP over Ethernet
 PPP over Ethernet (PPPoE) is a method of encapsulating





PPP frames so that they can be sent
over an Ethernet network. PPPoE was created so that
Internet service providers (ISPs) that
deploy a broadband Internet access technology in a
bridged Ethernet topology, such as cable
modems or Digital Subscriber Line (DSL), can use the peruser authentication and connection identification facilities of PPP to identify individual
customer connections for accounting
and billing purposes. PPPoE is described in RFC 2516.
PPPoE Discovery Stage





















The PPPoE discovery process consists of the following four PPPoE frames
1. The PPPoE Active Discovery Initiation (PADI) frame is sent by the PPPoE client to the
Ethernet broadcast address (0xFF-FF-FF-FF-FF-FF). Within the Ethernet payload, the
Code field is set to 9, the Session ID is set to 0, and there is a single Service-Name PPPoE
tag, as well as other tags as needed. If the network connection in the Network Connections folder corresponding to the broadband Internet adapter has been configured with
a service name, that service name is sent. Otherwise, the PADI frame is sent with a null
service name.
2. The PPPoE Active Discovery Offer (PADO) frame is sent by the AC to the unicast MAC
address of the PPPoE client. Within the Ethernet payload, the Code field is set to 7, the
Session ID is set to 0, there are the AC-Name and Service-Name tags, and other tags as
needed. If the network connection in the Network Connections folder corresponding to
the broadband Internet adapter has not been configured with a service name, it is automatically set to the value of the Service-Name tag in the PADO frame.
3. The PPPoE Active Discovery Request (PADR) frame is sent by the PPPoE client to the
unicast MAC address of the AC. Within the Ethernet payload, the Code field is set to 25,
the Session ID is set to 0, and there is a Service-Name tag and other tags as needed.
4. The PPPoE Active Discovery Session-confirmation (PADS) frame is sent by the AC to the
unicast MAC address of the PPPoE client. Within the Ethernet payload, the Code field is
set to 101, the Session ID field is set to the session ID for the PPP session of the PPPoE
client, and there is a Service-Name tag, as well as other tags as needed.
PPPoE Session Stage
Summary













PPP is used for encapsulation, link negotiation, and network protocol negotiation for network
protocol packets that are sent over a point-to-point link. The PPP connection process has four
phases: link negotiation, authentication, callback negotiation, and network protocol negotiation.
During link negotiation, each PPP peer determines how it will send PPP frames. During
authentication, PPP authentication protocols such as MS-CHAP v2 or EAP-TLS are used to verify the credentials of the calling or answering PPP peer. During callback negotiation, the calling and answering PPP peers determine whether the answering PPP peer will call the calling
peer back and at which phone number. During network protocol negotiation, NCPs such as
IPCP, CCP, and ECP are used to determine the use and configuration of TCP/IP, compression,
and encryption.
PPPoE is a method of encapsulating PPP frames so that they can be sent over an Ethernet link.
A PPPoE connection consists of two phases: a PPPoE discovery phase and a PPPoE session
phase. After a PPPoE connection is negotiated during the discovery phase, PPP is used to
negotiate a connection and send network protocol frames during the PPPoE session phase.