Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

Authentication Phase

In many cases, a device may require authentication before it will permit connection of

another device. (This is certainly usually the case when PPP is used for dial-up.) Authenti-

cation is not considered mandatory in PPP, however. When it is used, the appropriate

authentication protocol (CHAP or PAP) is employed.

After successful authentication, the link proceeds to the Network-Layer Protocol phase. If

authentication is not successful, the link fails and transitions to the Link Termination phase.

Figure 25: PPP Phases

The PPP connection between the two devices begins in the Link Dead state and proceeds through three inter-

mediate phases until the link is fully opened, as shown in the flow chart on the left. It remains in the stable Link

Open phase until terminated. The purple boxes show the corresponding change in the status of the PPP link

as transitions are made between phases.

Link De ad

Link

Establishment

Authentication

Network-Layer

Protocol

Link Ope n

Link Termination

No links

between devices

Physical link

LCP link

Authenticated

LCP link

Authenticated LCP link

and NCP links

Successful NCP

Configuration Negotiation

Successful Authentication,

or No Authentication Required

Successful LCP

Configuration Negotiation

Physical Layer

Connection Established

Unsuccessful LCP

Configuration Negotiation

LCP Link Termination

Completed

Link Failure or

Close Request

Unsuccessful

Authentication

Network-Layer Protocol Phase

Once the basic link has been configured and authentication completed, the general setup of

the LCP link is complete. Now, the specific configuration of the appropriate network layer

protocol is performed by invoking the appropriate NCP, such as IPCP, IPXCP and so forth.

Each particular network layer protocol whose NCP is successfully configured is considered

to be open on the LCP link. More than one NCP can be open on a particular PPP link, and

each can be closed independently when it is no longer needed. After all necessary NCPs

have been invoked, the link proceeds to the Link Open state, even if none were success-

fully opened.

Note: Some PPP features require the negotiation of additional options between

the two devices just as the various network layer protocols do. These may perform

their own link establishment process during the Network-Layer Protocol phase.

For example, the PPP Compression Control Protocol (CCP) sets up data compression in

this manner.

Link Open Phase

In this state, the LCP link and one or more NCP links are open and operational. Data can be

passed for each NCP that has been successfully set up.

The link can be terminated at any time by either device for a variety of reasons. These may

include user request (you hit the “disconnect” button when you want to log off your dial-up

session); link quality problems (the modem hangs up on you due to line noise); or some

other cause (you spend too much time in the bathroom and your ISP's idle timer logs you

out ☺). When any of these occur the LCP link is broken and the link transitions to the Link

Termination phase.

Link Termination Phase

The device terminating the link sends a special LCP termination frame, and the other

device acknowledges it. The link then goes back to the Link Dead phase. In the case where

the termination was by request and the physical layer connection is still active, the PPP

implementation is supposed to specifically signal the physical layer to terminate the layer

one connection.

Differentiating LCP and NCP Links

Remember that the basic link is established by LCP, and NCP links are set up within the

LCP link. Closing an NCP link does not cause the LCP link to be closed. Even if all NCPs

are closed, the LCP link remains open. (Of course, no data can be passed until an appro-

priate NCP link is re-established; a device is required to discard frames received containing

any layer three protocol that does not have an opened NCP.) To terminate a PPP

connection, only the LCP link needs to be terminated in the Link Termination phase; the

NCPs do not need to be explicitly closed.

PPP Link Setup and Phase Summary

A summary of PPP phases can be found in Table 25. In the table, the LCP Link Status and

NCP Link Status columns show the status of the link as the phase starts.

PPP Standards

PPP is not a single protocol but rather a suite of many. The basic architecture of PPP was

also designed to allow it to be easily extended through the addition of protocols to the suite.

For both of these reasons, it makes sense that PPP's operation is defined not in a single

standard but in many different standards. Like all TCP/IP standards, the PPP protocols are

described in a series of RFCs. These are regularly updated as changes are needed to the

different components of PPP, and as new technologies are added to it.

Table 25: PPP Phases

Phase/

State

Phase Summary

LCP Link

Status Upon

Entry To

Phase

NCP Link

Status Upon

Entry To

Phase

Transition

Requirement

Transition

To Phase

Link Dead

Default state; physical

layer not connected.

Closed Closed

Successful

physical layer

connection

Link

Establishment

Link

Estab-

lishment

Physical layer

connected, basic

configuration of link

performed by LCP.

Closed Closed

Successful

negotiation

Authentication

Unsuccessful

negotiation

Link Dead

Authenti-

cation

Basic link is now

opened, and optional

authentication of

device is performed.

Open Closed

Successful

authentication or

no authenti-

cation required

Network-

Layer

Protocol

Unsuccessful

authentication

Link

Termination

Network-

Layer

Protocol

One or more NCPs

open an NCP link

within the LCP link.

Open Closed All NCPs opened Link Open

Link Open

Link is open and

operating normally.

Open Open

Link failure or

close request

Link

Termination

Link

Termination

LCP link is shut down. Open Open Link Dead

While it makes sense to have different parts of PPP covered in different standards, this

does make it much harder to learn about how PPP works than if everything were in one

specification. Worse, there aren't just a few PPP standards; there are literally dozens of

RFCs that cover PPP's main operation, its various protocols and other issues related to it.

You can find most of them by consulting a master list of RFCs and searching for the string

“PPP”, but this way you will find them in numerical (RFC number) order, which isn't very

meaningful in terms of how the protocols are used. You also have to differentiate between

ones that are current and those that have been obsoleted.

Below I have described the most important and/or interesting of the RFCs that are related to

PPP. To make it easier to see what the RFCs are about, I have organized them into groups.

These groups roughly correspond to the component groups I discussed in the general

operation topic. Within each group the RFCs are listed in numerical order, which is also

date order. Only the most recent RFC is listed, not earlier ones that were obsoleted (with

the exception of RFC 1334; see the note below in that entry).

Despite the collective size of these tables, I haven't even come close to listing all the

standards defined that relate to PPP. Incidentally, to keep it from being even larger (and

more confusing) I didn't list the individual compression and encryption algorithms here; you

can find them in the topics on compression and encryption.

You can find more information on most of the protocols in the preceding table in the next

two sections.

Base PPP Standards

Table 26 shows the “main” documents that describe PPP in general terms. They cover the

basic operation of PPP including the PPP Link Control Protocol (LCP) and encapsulation of

datagrams.

Table 26: PPP Base Standards

RFC

Number

Standard Name Description

1570 PPP LCP Extensions

Defines two new features for LCP that allow devices to

identify each other to the other device and also tell the other

device how much time remains in the current session.

1661

The Point-to-Point Protocol

(PPP)

Base standard for the Point-to-Point protocol. Describes PPP

architecture, general operation (including the process of link

establishment, maintenance and termination) and details of

the LCP protocol.

1662 PPP in HDLC-like Framing

Defines the specific framing method for PPP frames, based

on that used in HDLC. This standard can be considered a

“companion” to the main PPP standard, RFC 1661.

LCP Support Protocols

These protocols, shown in Table 27, support the basic operation of LCP. At this time the

only protocols I put in this group are those that provide authentication services during link

startup.

Network Control Protocols (NCPs)

These are protocols that negotiate parameters specific to various layer three protocols

carried over PPP. They are described in Table 28.

Table 27: PPP LCP Support Protocol Standards

RFC

Number

Standard Name Description

1334 PPP Authentication Protocols

Defines the two PPP authentication protocols: Password

Authentication Protocol (PAP) and Challenge Handshake

Authentication Protocol (CHAP).

Note that RFC 1994 obsoletes RFC 1334, but does not

discuss the PAP protocol. This basically tells you what the

IETF thinks about PAP. ☺ See the topic on PAP and CHAP

for more on this.

1994

PPP Challenge Handshake

Authentication Protocol (CHAP)

Updates the information about CHAP provided in RFC 1334.

Table 28: PPP Network Control Protocol Standards

RFC

Number

Standard Name Description

1332

The PPP Internet Protocol

Control Protocol (IPCP)

The NCP for the Internet Protocol (IP).

1377

The PPP OSI Network Layer

Control Protocol (OSINLCP)

The NCP for OSI protocol suite network layer protocols, such

as CNLP, ES-IS, and IS-IS.

1378

The PPP AppleTalk Control

Protocol (ATCP)

The NCP for the AppleTalk protocol.

1552

The PPP Internetworking

Packet Exchange Control

Protocol (IPXCP)

The NCP for the Novell Internetworking Packet Exchange

(IPX) protocol.

2043

The PPP SNA Control Protocol

(SNACP)

The NCP for IBM's Systems Network Architecture (SNA).

2097

The PPP NetBIOS Frames

Control Protocol (NBFCP)

The NCP for NetBIOS Frames (NBF, also commonly called

NetBEUI).

2472 IP Version 6 over PPP

Describes the NCP for IPv6: the IPv6 Control Protocol

(IPv6CP).

Feature Protocols

These protocols define optional features used with PPP, such as compression and

encryption (Table 29).

Applications and Miscellaneous

These protocols describe how PPP can be adapted to run over particular types of links, or

that don't really fit into any of the other groups above. They are shown in Table 30.

Table 29: PPP Feature Protocol Standards

RFC

Number

Standard Name Description

1962

The PPP Compression Control

Protocol (CCP)

Defines a mechanism for compressing data sent over PPP

links to improve performance. This standard describes how

compression is negotiated between two devices on a PPP

link. It is used in conjunction with several compression

algorithms that actually do the compression of data.

1968

The PPP Encryption Control

Protocol (ECP)

Defines a mechanism for encrypting data sent over PPP links

to improve performance. This standard describes how

encryption is negotiated between two devices. It is used with

several encryption algorithms.

1989 PPP Link Quality Monitoring

Defines a protocol that lets PPP devices generate reports to

each other about the quality of the link.

1990 The PPP Multilink Protocol (MP)

Defines a method for running PPP over a set of aggregated

links, allowing two devices to use multiple low-bandwidth

links as a single, high-bandwidth virtual link.

2125

The PPP Bandwidth Allocation

Protocol (BAP) / The PPP

Bandwidth Allocation Control

Protocol (BACP)

Defines two support protocols that manage the allocation of

bandwidth in links aggregated using the PPP Multilink

Protocol (MP).

Table 30: PPP Application and Miscellaneous Standards (Page 1 of 2)

RFC

Number

Standard Name Description

1618 PPP over ISDN

Describes application particulars for running PPP over ISDN

links.

1973 PPP in Frame Relay

Describes how PPP may be modified to run over Frame

Relay at layer two.

2290

Mobile-IPv4 Configuration

Option for PPP IPCP

Defines changes to the PPP Internet Protocol Control

Protocol (IPCP) to support Mobile IP.

2364 PPP Over AAL5

Defines a method for sending PPP frames over AAL5 (ATM);

commonly called PPPoA.

2516

A Method for Transmitting PPP

Over Ethernet (PPPoE)

Defines a technique for encapsulating PPP frames over

Ethernet (PPPoE).

2615 PPP over SONET/SDH

Discusses how to encapsulate PPP frames over SONET/

SDH links.

Table 30: PPP Application and Miscellaneous Standards (Page 2 of 2)

RFC

Number

Standard Name Description

PPP Core Protocols: Link Control, Network Control and Authentication

The PPP protocol suite consists of several dozen protocols that cover various aspects of its

operation. Of these, a few protocols can be considered the most important or “core” of the

suite. It's not that the others are not important, mind you. But this small group is responsible

for the basic operation of PPP. In particular, they work together to implement the relatively

complex link negotiation process, which is a big part of what PPP is all about.

In this section I describe the protocols that are responsible for PPP link setup and basic

operation. I begin with a description of the key Link Control Protocol (LCP). I then describe

the different Network Control Protocols (NCPs) used to configure PPP for different layer

three protocols. Finally, I discuss the two PPP authentication protocols, PAP and CHAP,

used to provide authentication during link setup.

Related Information: The frame formats for these protocols are detailed in the

separate section on PPP frames and frame formats.

PPP Link Control Protocol (LCP)

Of all the different PPP suite protocols, the single most important protocol is the PPP Link

Control Protocol (LCP). LCP is the “boss” of PPP; it is responsible for its overall successful

operation, and for “supervising” (in a way) the actions of other protocols.

PPP is about links, and LCP is about controlling those links. As I discussed in the PPP

fundamentals section, the operation of a PPP link can be thought of as proceeding through

various “life stages” just as a biological organism does. There are three main stages of “link

life” and LCP plays a key role in each one:

☯ Link Configuration: The process of setting up and negotiating the parameters of a

link.

☯ Link Maintenance: The process of managing an opened link.

☯ Link Termination: The process of closing an existing link when it is no longer needed

(or when the underlying physical layer connection closes).

Each of these functions corresponds to one of the “life phases” of a PPP link. Link configu-

ration is performed during the initial Link Establishment phase of a link; link maintenance

occurs while the link is open, and of course, link termination happens in the Link Termi-

nation phase. Figure 26 represents a summary of the LCP link, showing the different

message exchanges performed by LCP during these different life phases of a PPP

connection.

LCP Frames

Devices use LCP to control the PPP link by sending special LCP messages across the

physical link between them. These messages are called both LCP packets and LCP

frames; while the standard uses "packet", the term "frame" is preferred because layer two

Figure 26: PPP Link Control Protocol (LCP) Message Exchanges

This diagram provides an overview of many of the message exchanges performed by LCP during different

phases of a PPP connection. Link Configuration is here shown as a simple exchange of a Configure-Request

and Configure-Ack. After subsequent exchanges using other PPP protocols to authenticate and configure one

or more NCPs, the link enters the Link Open phase. In this example, an Echo-Request and Echo-Reply

message are first used to test the link, followed by the sending and receiving of data by both devices. One

Data message is shown being rejected due to an invalid Code field. Finally, the link is terminated using

Terminate-Request and Terminate-Ack messages.

Initator

Configure-Request

Configure-Ack

Initiate LCP Configuration

Terminate-Request

Terminate-Ack

(Authentication and

NCP Configuration)

Echo-Request

Echo-Reply

Data

Data Data

Process LCP Configuration

Request

(Authentication and

NCP Configuration)

Finish LCP Configuration

Data

Code-Reject

...

Reply to Echo Test

...

Initiate Loopback Test

Confirm Link Operation

Receive Close Request,

Notify Other Device

Responder

Terminate Link

Send and

Receive Data

Send and

Receive Data

messages are normally called frames. There are eleven different LCP frame types defined

in the main PPP document, which are divided into three groups that correspond to the three

link “life stages” above. Four LCP frame types are used for link configuration, five for

maintenance and two for termination. The frame formats themselves are described in the

topic on LCP frames. Below I will discuss each of the three major functions of LCP and how

the frames are used in each.

Key Concept: The PPP Link Control Protocol (LCP) is the most important protocol in

the PPP suite. It is responsible for configuring, maintaining and terminating the

overall PPP link. The two devices using PPP employ a set of LCP frames to conduct

LCP operations.

LCP Link Configuration

Link configuration is arguably the most important job that LCP does in PPP. During the Link

Establishment phase, LCP frames are exchanged that enable the two physically-connected

devices to negotiate the conditions under which the link will operate. Figure 27 shows the

entire procedure, which we will now examine in detail.

The process starts with the initiating device (let's call it device A, yeah, isn't that original)

creating a Configure-Request frame that contains a variable number of configuration

options that it wants to see set up on the link. This is basically device A's “wish list” for how

it wants the link created.

The main PPP document (RFC 1661) defines a number of different configuration options

that the initiator can specify in this request. Any one of these can be included and if so, filled

in with the value corresponding to what device A wants for that option. If absent, this means

device A is neither requesting nor specifying that option. The six options are:

☯ Maximum-Receive-Unit (MRU): Lets device A specify the maximum size datagram it

wants the link to be able to carry.

☯ Authentication-Protocol: Device A can indicate the type of authentication protocol it

wishes to use (if any).

☯ Quality-Protocol: If device A wants to enable quality monitoring on the link, what

protocol to use (though there is only one currently defined: LQR).

☯ Magic-Number: Used to detect looped back links or other anomalies in the

connection.

☯ Protocol-Field-Compression: Allows device A to specify that it wants to use

“compressed” (8 bit) Protocol fields in PPP data frames instead of the normal 16 bit

Protocol field. This provides a small but free savings (one byte) on each PPP frame.

Note that this has nothing to do with the compression feature offered by CCP. See the

PPP general frame format topic for more on this feature.

☯ Address-and-Control-Field-Compression (ACFC): The same as the option just

above but used to compress the Address and Control fields, again for small bandwidth

savings. Again, see the PPP general frame format topic for more.