Charles M. Kozierok The TCP-IP Guide

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

This entire structure becomes the payload of a PPP frame, meaning that it fits into the Infor-

mation field of a PPP frame, as shown in Figure 34. Thus, the Length field is equal in size to

that of the Information field in the PPP frame. The Protocol field of a control frame is set to

match the protocol that generated the control frame. For example, it would be 0xC021 for

an LCP frame.

PPP Control Messages and Code Values

The Code field indicates the type of control frame within the particular control protocol.

Some protocols have a unique set of codes used only by that particular protocol; examples

include the authentication protocols (PAP and CHAP) and the Bandwidth Allocation

Protocol (BAP). Since the NCPs and many of the feature control protocols like CCP and

Length 2

Length: Specifies the length of the control frame; this is needed because

the Data field is variable in length. The Length field is specified in bytes and

includes all the fields in the control frame including the Code, Identifier,

Length and Data fields.

Data Variable

Data: Contains information specific to the message type. See below for

more.

Figure 34: PPP Control Message Format

The four fields of the PPP control message format fit within the Information field of the PPP general frame

format. The Data field is subsequently filled in with data specific to the control message type.

Table 36: PPP Control Message Format (Page 2 of 2)

Field Name

Size

(bytes)

Description

Flag

(binary 01111110)

Address

(binary 11111111)

Control

(binary 00000011)

Protocol

(first byte)

Protocol

(second byte)

Code (Type) Identifier

Length

(first byte)

Length

(second byte)

Frame Check Sequence (FCS)

(may also be 4 bytes)

Flag

(binary 01111110)

4 8 12 16 20 24 28 320

Padding

Data

ECP are based on LCP, they use a common set of message codes and types. Table 37

shows these common message codes, as well as a cross-reference table indicating which

control protocols use them:

Note: I describe the specific ways these frame types are used in the individual

topics on LCP, the NCPs, CCP and ECP.

The contents of the Data field depends entirely on the type of control message. In some

cases, no extra data needs to be sent at all, in which case the Data field may be omitted. In

other control messages it carries information relevant to the message type. For example, a

Code-Reject message carries in the Data field a copy of the frame that was rejected.

PPP Control Message Option Format

The various Configure- messages are used to negotiate configuration options in LCP and

the other control protocols. In their Data fields they carry one or more options that are,

again, specific to the protocol using them. For example, LCP uses one set of configuration

options for the link as a whole; CCP uses options to negotiate a compression algorithm, MP

Table 37: PPP Control Messages, Code Values and PPP Protocol Usage

Code Value Control Message LCP NCPs

CCP and

ECP

1 Configure-Request 333

2 Configure-Ack 3 3 3

3 Configure-Nak 333

4 Configure-Reject 3 3 3

5 Terminate-Request 333

6 Terminate-Ack 3 3 3

7 Code-Reject 333

8 Protocol-Reject 3

9 Echo-Request 3

10 Echo-Reply 3

11 Discard-Request 3

12 Identification 3

13 Time-Remaining 3

14 Reset-Request 3

15 Reset-Ack 3

uses it to set up multilink bundles and so on. Figure 35 shows how these options, which can

vary in length, are placed in the Data field of a PPP control message (which is in turn

nested inside the general PPP frame format).

Again, there is commonality here; while every option is different, they all use the same basic

format, as described in Table 38 and illustrated in Figure 36:

The configuration options are described briefly in the individual protocol topics. I am not

showing the specific contents of each option as there are just too many of them. These are

in the RFCs.

Figure 35: PPP Control Message Carrying Options

This diagram shows a sample PPP control message carrying options in its Data field. Any number of options

can be included, and/or mixed with other data, depending on the needs of the message.

Table 38: PPP Control Message Option Format

Field Name

Size

(bytes)

Description

Type 1

Type: A type value that indicates the option type. The set of Type values is

unique to each protocol. So, for example, LCP has one set of Type values

corresponding to its configuration options, each NCP has a different set,

CCP has its own set and so on.

Length 1 Length: Specifies the length of the option in bytes.

Data Variable Data: Contains the specific data for the configuration option.

Flag

(binary 01111110)

Address

(binary 11111111)

Control

(binary 00000011)

Protocol

(first byte)

Protocol

(second byte)

Code (Type) Identifier

Length

(first byte)

Length

(second byte)

Frame Check Sequence (FCS)

(may also be 4 bytes)

Flag

(binary 01111110)

4 8 12 16 20 24 28 320

Padding

Option #1

Option #2

Other Options or Data

Summary of PPP Control Message Formatting

Well now… My intention in this topic was to show you the general format used for the

different control protocols since they are so similar and I don't have the time or space to

describe each protocol's frames individually. I concede that this may have ended up being

more confusing than enlightening, since it may be difficult to see how PPP moves from the

general to the specific in its formatting. If it will help, here's a quick summary:

1. The PPP general frame format is used for all frames, including all control frames. Its

Information field contains the payload, which carries the entire control message within

it for control frames.

2. The control frame is structured using the general format I gave at the start of this topic.

The Code value indicates the type of control frame for each control protocol. The Data

field is variable in length, and contains data for that control frame, which in some cases

may include one or more configuration options.

3. For configuration control frames like Configure-Request and Configure-Ack, the Data

field contains an encapsulated set of options using the general structure in the second

table in this topic. Each option has its own Data subfield that contains data specific to

that option.

To help make this more clear, the next two topics provide more specific examples of frame

formats for LCP and the authentication protocols.

PPP Link Control Protocol (LCP) Frame Formats

The previous topic described the general format used by the various protocols in PPP that

exchange control messages. Of the many control protocols in PPP, the Link Control

Protocol (LCP) is the most important, as it is responsible for basic PPP link setup and

operation. It is also the protocol used as a “template” for many of the other control

protocols.

Since it is so central to PPP, and since many of the other protocols use a similar messaging

system, I want to make the general frame format seen in the previous page more “concrete”

by showing the specific frame formats used for each of the LCP control frames. There are

thirteen different ones, however, and since they have many fields in common, I didn't want

to put here thirteen tables all of which look almost the same.

Figure 36: PPP Control Message Option Format

Each option that appears in any of the many PPP control message types consists of this triplet of Type,

Length and Data.

4 8 12 16 20 24 28 320

Type Length

Option Data

To save space and show how the messages differ, I have put them into a single large

summary table instead of making thirteen smaller ones. Table 39 shows the contents and

meaning for each of the fields in the thirteen LCP frame types:

Table 39: PPP Link Control Protocol (LCP) Frame Types and Fields (Page 1 of 2)

Frame Type

Code

Field

Identifier Field

Length

Field

Data Field

Configure-

Request

New value generated

for each frame.

4 + Length of

all included

configuration

options.

Configuration options to be negotiated by

the two peers on a link. The previous topic

describes the general format of configu-

ration options.

Configure-

Ack

Copied from the

Identifier field of the

Configure-Request

frame for which this

Configure-Ack is a

reply.

4 + Length of

all included

configuration

options.

Configuration options being positively

acknowledged (accepted during negoti-

ation of the link).

Configure-

Nak

Copied from the

Identifier field of the

Configure-Request

frame for which this

Configure-Nak is a

reply.

4 + Length of

all included

configuration

options.

Configuration options being negatively

acknowledged (renegotiation requested).

Configure-

Reject

Copied from the

Identifier field of the

Configure-Request

frame for which this

Configure-Reject is a

reply.

4 + Length of

all included

configuration

options.

Configuration options being rejected

(since the device cannot negotiate them).

Terminate-

Request

New value generated

for each frame.

4 (or more if

extra data is

included).

Not required. See note below.

Terminate-

Ack

Copied from the

Identifier field of the

matching Terminate-

Request.

4 (or more if

extra data is

included).

Not required. See note below.

Code-Reject 7

New value generated

for each frame.

4 + Length of

rejected

frame.

A copy of the LCP frame that was

rejected. This is not the complete PPP

frame, just the LCP control portion from its

Information field.

Protocol-

Reject

New value generated

for each frame.

6 + Length of

rejected

frame.

The first two bytes contain the Protocol

value of the frame rejected. The rest

contains a copy of the Information field

from the frame rejected.

Echo-

Request

New value generated

for each frame.

8 (or more if

extra data is

included).

Contains a 4-byte “magic number” used to

detect looped-back links, if the appro-

priate configuration option has been

negotiated; otherwise, set to zero.

May also contain additional “uninterpreted

data”; see note below.

Echo-Reply 10

Copied from the

Identifier field of the

matching Echo-

Request.

8 (or more if

extra data is

included).

Contains a 4-byte “magic number” used to

detect looped-back links, if the appro-

priate configuration option has been

negotiated; otherwise, set to zero.

May also contain additional “uninterpreted

data”; see note below.

Discard-

Request

New value generated

for each frame.

8 (or more if

extra data is

included).

Contains a 4-byte “magic number” used to

detect looped-back links, if the appro-

priate configuration option has been

negotiated; otherwise, set to zero.

May also contain additional “uninterpreted

data”; see note below.

Identification 12

New value generated

for each frame.

8 (or more if

extra data is

included).

Contains a 4-byte “magic number” used to

detect looped-back links, if the appro-

priate configuration option has been

negotiated; otherwise, set to zero.

May also contain additional “uninterpreted

data”; see note below.

Time-

Remaining

New value generated

for each frame.

12 (or more if

extra data is

included).

Contains a 4-byte “magic number” used to

detect looped-back links, if the appro-

priate configuration option has been

negotiated; otherwise, set to zero.

Also contains a 4-byte value indicating the

number of seconds remaining in the

current session. A value of all ones in this

field is interpreted as “forever”, meaning

the session will not expire.

May also contain additional “uninterpreted

data”; see note below.

Table 39: PPP Link Control Protocol (LCP) Frame Types and Fields (Page 2 of 2)

Frame Type

Code

Field

Identifier Field

Length

Field

Data Field

Note: LCP frame types 5, 6, 9, 10, 11, 12 and 13 allow an additional amount of

data to be included in the Data field whose use is not strictly described by the

protocol. The PPP standard says that this may be zero or more octets that

“contains uninterpreted data for use by the sender” and “may consist of any binary value”.

The inclusion of this “uninterpreted data” is left as an implementation-dependent option.

All LCP control frames are encapsulated into a PPP frame by placing the frame structure

into its Information field as discussed in the previous topic. The Protocol field is set to

0xC021 for LCP. For an explanation of how the frames are used, see the operational

description of LCP.

PPP Authentication Protocol (PAP, CHAP) Frame Formats

For links where security is important, PPP provides two optional authentication protocols.

These are used during initial link setup by the Link Control Protocol (LCP) to deny PPP

connections to unauthorized devices. The two authentication protocols are the Password

Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP).

PAP and CHAP are control protocols and thus use the same basic control protocol frame

format described earlier in this section. However, since they have a very different purpose

than LCP and many of the other control protocols, they use a distinct set of frames, with

their own unique set of Code values. I thought it might be useful to see how PAP and CHAP

frames are constructed. PAP uses three different control frame types, and CHAP uses four.

To save space and show how the frames compare to each other, I will show them in one

table for each protocol instead of seven tables.

PPP PAP Control Frame Formats

Let’s start with PAP. Its three control frames are constructed as shown in Table 40. The

Authenticate-Request uses one format, illustrated in Figure 37, while the other two frame

types use a different format, shown in Figure 38.

Table 40: PPP Password Authentication Protocol (PAP) Frame Formats

Frame Type

Code

Field

Identifier

Field

Length

Field

Data Field

Authenticate-

Request

New value

generated for

each frame.

6 + Length of

Peer-ID +

Length of

Password

Authenticate-

Ack

Copied from

the Identifier

field of the

Authenticate-

Request

frame for

which this is a

reply.

5 + Length of

included

Message.

Contains a one-byte Msg-Length subfield that

specifies the length of the Message subfield that

follows it. The Message subfield contains an

arbitrary string of data whose use is implemen-

tation dependent. It may be used to provide an

indication of authentication success or failure to

the user. If not used, the Msg-Length field is still

included, but its value is set to zero.

Authenticate-

Nak

“

user name

”

passwor

authentication. This is carried in four subfields

arranged as follows:

Subfield

Name

Size

(bytes)

Description

Peer-ID

Length

Peer-ID Length: Length of

the Peer-ID field, in bytes.

Peer-ID Variable

Peer-ID: The name of the

device to be authenticated;

equivalent in concept to a

“user name”.

Passwd-

Length

Password Length: Length

of the Password field, in

bytes.

Password Variable

Password: The password

corresponding to the name

being authenticated.

Figure 37: PPP PAP Authenticate-Request Frame Format

Figure 38: PPP PAP Authenticate-Ack and Authenticate-Nak Frame Format

Flag

(binary 01111110)

Address

(binary 11111111)

Control

(binary 00000011)

Protocol

(first byte)

Protocol

(second byte)

Code (Type) Identifier

Length

(first byte)

Length

(second byte)

Peer-ID Length

Frame Check Sequence (FCS)

(may also be 4 bytes)

Flag

(binary 01111110)

4 8 12 16 20 24 28 320

Padding

Peer-ID

Passwd-Length

Password

Flag

(binary 01111110)

Address

(binary 11111111)

Control

(binary 00000011)

Protocol

(first byte)

Protocol

(second byte)

Code (Type) Identifier

Length

(first byte)

Length

(second byte)

Msg-Length

Frame Check Sequence (FCS)

(may also be 4 bytes)

Flag

(binary 01111110)

4 8 12 16 20 24 28 320

Padding

Message

PPP CHAP Control Frame Formats

The four CHAP frame types are formatted as shown in Table 41. As you can see in that

table, the Challenge and Response frames use one message format, illustrated in Figure

39, while Success and Failure frames use a different one, shown in Figure 40.

Table 41: PPP Challenge Handshake Authentication Protocol (CHAP) Formats

Frame Type

Code

Field

Identifier

Field

Length

Field

Data Field

Challenge 1

New value

generated for

each frame.

5 + Length of

challenge text

+ Length of

name

Response 2

Copied from

the Identifier

field of the

Challenge

frame for

which this is a

reply.

5 + Length of

Value +

Length of

Name

Success 3 Copied from

the Identifier

field of the

Response

frame for

which this is a

reply.

4 (or more if

extra data is

included).

May contain an arbitrary, implementation-

dependent Message field to indicate to the user

whether authentication was successful or failed.

Failure 4

arr

e c

enge

or response

, an

system identifier. This information is carried in

three subfields:

Subfield

Name

Size

(bytes)

Description

Value-Size 1

Value-Size: Length of the

Value subfield that follows,

in bytes.

Value Variable

Value: For a Challenge

frame, contains the

challenge text used in the

initial “challenge”. For a

Response frame, the

encrypted challenge text

being returned to the

authenticator.

Name Variable

Name: One or more bytes

of text used to identify the

device that sent the frame.