Charles M. Kozierok The TCP-IP Guide

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

☯ Break an IP datagram into bytes.

☯ Send the END character (value “192”) after the last byte of the datagram; in better

implementations, send the END character before the first byte as well.

☯ If any byte to be sent in the datagram is “192”, replace it with “219 220”.

☯ If any byte to be sent is “219”, replace it with “219 221”.

Figure 22 shows an example of how SLIP works, including the escaping of special

characters, using a mock IP datagram.

Problems and Limitations of SLIP

SLIP sounds great, right—nice and simple? Unfortunately, the cost of this simplicity is that

SLIP just doesn't provide many of the features and capabilities we really need on modern

serial links. Some of the most significant problems with SLIP include the fact that it is

deficient in all of the following areas:

Figure 22: Operation of the Serial Line Internet Protocol (SLIP)

IP datagrams are passed down to the SLIP software at layer two (a simplified one with only five bytes is

shown here). There, they are framed by surrounding them with END characters (hexadecimal value C0h,

shown in orange). Special characters with hexadecimal values DBh and C0h are replaced by two-byte

sequences. Note that the presence of the bracketing END characters forces the receiving device to see the

noise byte (03h, in red) as a separate IP datagram, rather than part of either of the real ones. It will be rejected

when passed up to the IP layer.

SLIP

Upper

Layers

Layer 1

SLIP Frame

IP Datagram

SLIP

Upper

Layers

01 DB 49 C0 15

01 DB 49 DB 15 C0DCDDC0

SLIP Fr...

C0 7703

...

Layer 1

IP Da...

...

☯ Standardized Datagram Size Specification: SLIP’s maximum datagram size

supported is not standardized and depends on the implementation. The usual default

is 1006 bytes, which becomes the maximum transmission unit (MTU) for the link. If a

different size is used this must be programmed into the IP layer.

☯ Error Detection/Correction Mechanism: SLIP doesn't provide any way of detecting

or correcting errors in transmissions. While such protection is provided at higher layers

through IP header checksums and other mechanisms, it is a job “traditionally” also

done at layer two. The reason is that relying on those higher layers means that errors

are only detected after an entire datagram has been sent and passed back up the

stack at the recipient. Error correction can only come in the form of re-sending any

datagrams that were corrupted. This is inefficient, especially considering that serial

links are generally much slower than normal LAN links.

☯ Control Messaging: SLIP provides no way for the two devices to communicate

control information between them to manage the link.

☯ Type Identification: Since SLIP includes no headers of its own, it is not possible to

identify the protocol it is sending. While developed for IP, you can see that there is no

reason other layer three protocols could not be sent using SLIP. However, without type

identification there is no way to mix datagrams from two or more layer three protocols

on the same link.

☯ Address Discovery Method: Addressing isn't needed at layer two due to the point-to-

point nature of the connection—there are only two devices so the intended recipient of

each message is obvious. However, devices do need some way of learning each

other's IP addresses for routing at layer three. SLIP provides no method for this.

☯ Support For Compression: Compression would improve performance over serial

lines that are, again, slow compared to other technologies. SLIP provides no

compression features. Note, however, that modems usually do support compression

at layer one, for serial connections that use them. There was also a variant on SLIP

called Compressed SLIP or CSLIP that was created in the late 1980s, but it was not as

widely deployed as regular SLIP.

☯ Security Features: SLIP provides no methods for authentication of connections or

encryption of data, which means even the basics of security are not provided.

Sounds pretty bad, doesn't it? The many shortcomings of SLIP have led most implementa-

tions to move from SLIP over to the newer Point-to-Point Protocol (PPP), which is a much

richer data link protocol for direct connections that resolves the problems listed above. SLIP

is now outdated, and some even consider it a historical protocol. Despite that, SLIP is still

used in many places. Simplicity is attractive, and computer people are famous for their

inertia: if something is implemented and is working well, many will refuse to change unless

they are forced to do so.

Point-to-Point Protocol (PPP)

Even as SLIP was being documented as a “nonstandard” in RFC 1055, work was underway

for a newer protocol to provide full-featured IP transmission over direct links between pairs

of devices. The result is the Point-to-Point Protocol (PPP), which defines a complete

method for robust data link connectivity between units using serial lines or other physical

layers. It includes numerous capabilities and features, including error detection,

compression, authentication, encryption and much more.

Even though PPP is called a “protocol”, and even though it is considered part of TCP/IP—

depending on whom you ask—it is really more a protocol suite than a particular protocol.

The operation of PPP is based on procedures defined in many individual protocols, as we

will see in this section. Thus, PPP can be considered a “protocol suite within a protocol

suite”. Alternately, its components can be viewed as “subprotocols” within PPP.

In this section I provide a comprehensive look at the operation of the Point-to-Point

Protocol, in four subsections. The first describes the fundamentals of PPP, including its

history, standards and an overview of its general operation. The second explains the “core”

protocols that are responsible for setting up PPP links and basic operation. The third covers

the protocols used to implement various special features in PPP, such as compression and

encryption. The last subsection provides detailed information on the various frame formats

used by PPP protocols.

Note: The component protocols of PPP are normally just called “protocols” and

not “subprotocols”. This is confusing, so watch out for it in networking literature. I

try to be consistent in this section in referring to PPP as a suite, but remember that

it really is often just collectively called a “protocol”.

Note: As we will see in this section, PPP can be used to carry the frames of many

protocols operating at layers three and above. It is, however, best known for its

use with IP, and that is the assumption for the descriptions in this section, unless

otherwise specified.

Related Information: PPP is related to the High-Level Data Link Control (HDLC)

protocol, which is in turn part of the Synchronous Data Link Control (SDLC) family

of protocols. I have avoided reliance on the SDLC protocols in explaining PPP

since PPP is important and widely used enough that I think it warrants independent

description.

PPP Fundamentals and Operation

The problem with the Serial Line Internet Protocol was that it was too simple and didn't

include enough features. As the saying goes, “be careful what you wish for”, especially

when the complaint is too much simplicity. ☺ The Point-to-Point Protocol (PPP) corrects

the lack of features in SLIP, but you could figure out, without really trying, what the cost is:

significantly more complexity. Where the operation of SLIP can be explained in a few

paragraphs, PPP is much more involved, including a number of specific processes that

need to be explained.

Before discussing the individual protocols that comprise PPP, I want to take a high-level

look at the protocol suite. I start with an overview, history and discussion of the benefits of

PPP. I provide a high-level breakdown of the main components of the PPP suite, and a

general description of how PPP operates. I then describe the steps involved in setting up

and configuring a link, and the phases a PPP link passes through during its “lifetime”.

Finally, I categorize and list the standards that define different aspects of PPP's

functionality.

Note: I describe the operation of PPP before the standards that define it, which is

different than the order used in most other sections in this Guide. I felt that in this

case, the groupings used to list the standards would make more sense coming

after the description of the PPP suite components and its overall operation.

PPP Overview, History and Benefits

Albert Einstein is credited with the following quote: “Everything should be made as simple

as possible — but no simpler”. The Serial Line Internet Protocol (SLIP) is a good example

of this maxim. It provides basic layer two framing for IP, but it is just too simple for many

uses. Since all it does is frame the end of each datagram, it doesn't provide many of the

features that we really need for reliable, secure and high-performance operation over serial

links. This is especially true today when most serial connections are not short LAN cables

but dial-up WAN connections over relatively long distances.

PPP Development and Standardization

SLIP was basically a “hack” to fill a specific need: bridging the gap between IP at layer three

and a serial link at layer one. It “gets the job done” but doesn't provide any of the features

we really want in a robust protocol for direct links between devices. PPP was developed to

be a complete protocol suite that would enable fully-functional layer two connectivity to

support not just IP but the transmission of other network layer protocols as well.

The history of PPP goes back to the late 1980s, when SLIP was the de facto standard for

serial IP implementations. The first formal IETF document related to PPP was RFC 1134,

published in 1989. This RFC is not the standard itself but a proposal for what would

eventually be defined as the first main PPP standard, RFC 1171, in 1990. This early

document has been revised several times and several other documents added that define

the various protocols that comprise the entire PPP suite. PPP standards are described later

in this section.

The IETF is always smart about not reinventing the wheel. Rather than try to develop PPP

from scratch, the decision was made to base it on the ISO High-Level Data Link Control

(HDLC) protocol, which was initially developed by IBM. HDLC is a derivative of the

Synchronous Data Link Control (SDLC) protocol. PPP's developers adapted its framing

structure and some of its general operation from the HDLC protocol.

PPP General Function and Architecture

PPP is a connection-oriented protocol that enables layer two links over a variety of different

physical layer connections. It is supported on both synchronous and asynchronous lines,

and can operate in half-duplex or full-duplex mode. It was designed to carry IP traffic but is

general enough to allow any type of network layer datagram to be sent over a PPP

connection. As its name implies, it is for point-to-point connections between exactly two

devices, and assumes that frames are sent and received in the same order.

PPP fits into the Network Interface layer (Link Layer) in the TCP/IP model, as shown in

Figure 23. The operation of PPP follows a specific sequence described in the general

operation topic, including a multi-step link establishment phase that may include optional

authentication.

PPP Advantages and Benefits

A list of PPP's strengths reads very much like a list of SLIP's weaknesses, which I

explained in detail in the topic on SLIP. Some of the specific benefits of PPP compared to

SLIP include:

☯ A more comprehensive framing mechanism, compared to the single END character in

SLIP.

☯ Specification of the encapsulated protocol, to allow multiple layer three protocols to be

multiplexed on a single link.

☯ Error detection for each transmitted frame through the use of a CRC code in each

frame header.

☯ A robust mechanism for negotiating link parameters, including the maximum frame

size permitted.

☯ A method for testing links before datagram transmission takes place, and monitoring

link quality.

☯ Support for authentication of the connection using multiple authentication protocols.

☯ Support for additional optional features, including compression, encryption and link

aggregation (allowing two devices to use multiple physical links as if they were a

single, higher-performance link).

The proliferation of serial links, especially for dial-up Internet access, has led to widespread

use of PPP. It is now one of the most popular layer two WAN technologies in the networking

world, and has replaced SLIP as the standard for serial connections on all but legacy imple-

mentations. While most often associated with dial-up modem use, PPP can run across any

similar type of physical layer link. For example, it is often used to provide layer two function-

ality on ISDN B channels.

Key Concept: PPP is a complete link layer protocol suite for devices using TCP/IP,

which provides framing, encapsulation, authentication, quality monitoring and other

features to enable robust operation of TCP/IP over a variety of physical layer

connections.

Figure 23: PPP Location in TCP/IP Architecture

PPP acts as the interface between the Internet Protocol and a physical link such as a serial line or dial-up

networking connection. This corresponds to layer two in the OSI Reference Model.

Upper Layer

Protocols

OSI and TCP/IP

Model Layers

PPP

Architecture

TCP / UDP

PPP

Physical Link

(Serial, Dial-Up,

ISDN, etc.)

Application

Transport

Internet3

Network

Interface

PPP’s Extensibility

A key advantage of PPP is that it is an extensible protocol suite. Over the years new

protocols have been added to the suite, to provide additional features or capabilities. For

example, PPP is designed not to use just a single authentication protocol, but to allow a

choice of which protocol is used for this purpose.

PPP's success has even led to the development of derivative protocols like PPP over

Ethernet (PPPoE) and PPP over ATM (PPPoA). These actually layer PPP over existing

data link layer technologies, which shows you how valued PPP's features are—even when

a layer two technology is already in use, applying PPP on top provides authentication and

management benefits for services like DSL.

PPP Components and General Operation

PPP stands for the Point-to-Point Protocol, but even the standard that defines PPP

immediately starts describing protocols that comprise it, which is why I consider it a protocol

suite. At the highest level, the functions of PPP can be broken down into several compo-

nents. Each of these encompasses a general class of PPP functionality, and is represented

by either one protocol in the suite or a set of protocols.

Main PPP Components

The PPP standard itself describes three “main” components of PPP:

☯ PPP Encapsulation Method: The primary job of PPP is to take higher-layer

messages such as IP datagrams and encapsulate them for transmission over the

underlying physical layer link. To this end, PPP defines a special frame format for

encapsulating data for transmission, based on the framing used in the HDLC protocol.

The PPP frame has been specially designed to be small in size and contain only

simple fields, to maximize bandwidth efficiency and speed in processing.

☯ Link Control Protocol (LCP): The PPP Link Control Protocol (LCP) is responsible for

setting up, maintaining and terminating the link between devices. It is a flexible, exten-

sible protocol that allows many configuration parameters to be exchanged to ensure

that both devices agree on how the link will be used.

☯ Network Control Protocols (NCPs): PPP supports the encapsulation of many

different layer three datagram types. Some of these require additional setup before the

link can be activated. After the general link setup is completed with LCP, control is

passed to the PPP Network Control Protocol (NCP) specific to the layer three protocol

being carried on the PPP link. For example, when IP is carried over PPP the NCP

used is the PPP Internet Protocol Control Protocol (IPCP). Other NCPs are defined for

supporting the IPX protocol, the NetBIOS Frames (NBF) protocol, and so forth.

The PPP encapsulation method and LCP are defined in the main PPP standard and some

support standards; the NCPs are described in separate standard documents, one per NCP.

Additional PPP Functional Groups

While the three components above do constitute much of the total package of PPP, I would

add to the list of components in the standard two additional functional groups. These

represent some of the many extra protocols that have been added over time to the suite to

support or enhance the basic operation of PPP:

☯ LCP Support Protocols: Several protocols are included in the PPP suite that are

used during the link negotiation process, either to manage it or to configure options.

Examples include the authentication protocols CHAP and PAP, which are used by LCP

during the optional authentication phase.

☯ LCP Optional Feature Protocols: A number of protocols have been added to the

basic PPP suite over the years to enhance its operation after a link has been set up

and datagrams are being passed between devices. For example, the PPP

Compression Control Protocol (CCP) allows compression of PPP data, the PPP

Encryption Control Protocol (ECP) enables datagrams to be encrypted for security,

and the PPP Multilink Protocol (PPP MP) allows a single PPP link to be operated over

multiple physical links. The use of these features often also requires additional setup

during link negotiation, so several define extensions (such as extra configuration

options) that are negotiated as part of LCP.

Each of these additional protocols is generally defined by a different standards document.

You can find a list of some of these in the topic on PPP standards.

PPP General Operation

The fact that the PPP suite includes literally dozens of protocols often makes it seem like it

must be a really complex technology. In fact, the general operation of PPP is really quite

straight-forward. The existence of all those PPP protocols allows PPP to be flexible and

extensible, supporting many higher layer datagram types and various features.

The bottom line, however, is that PPP operation involves just three basic steps. Beginning

in a state where there is no PPP link between the devices, these are the operations that

occur in PPP (also illustrated in Figure 24):

1. Link Setup and Configuration: Before the two devices can exchange information,

they must make contact and set up a link between them. During link setup, all the

parameters needed to manage the operation of the link are agreed upon by the two

devices. The LCP begins this process, and invokes the help of support protocols as

they are needed, for options like authentication. After the link is set up in general

terms, the appropriate NCP is called for whatever layer three technology is being

carried on the link to complete link setup.

2. Link Operation: The devices on the link use it to send datagrams. Each device

transmits by taking layer three datagrams, encapsulating them and sending them

down to layer one to be transmitted. Each device receives by taking PPP frames sent

up from its own physical layer, stripping off the PPP header and passing the datagram

up to layer three. Where appropriate, optional feature protocols are used here, such as

CCP for compression.

3. Link Termination: When either device decides it no longer wants to communicate, it

terminates the link. The link can of course be re-established if desired.

Link setup is by far the most complicated of these general steps, as it involves several

substeps used to negotiate link parameters and options. The next topic describes the steps

in link setup, and discusses the phases that a link passes through as it is set up, used, and

eventually terminated.

PPP Link Setup and Phases

Before data can be exchanged on a PPP connection, a link must be set up between the two

devices. As part of this setup task, a configuration process is undertaken whereby the two

configure the link and agree on the parameters for how data should be passed between

them. Only after this is completed can frames actually pass over the link.

The PPP Link Configuration Protocol (LCP) is generally in charge of setting up and

maintaining PPP links. LCP may invoke an authentication protocol (PAP or CHAP) when

PPP is configured to use authentication. After an LCP link has been opened, PPP invokes

one or more Network Control Protocols (NCPs) for the layer three protocol being carried on

the link. These perform any network-layer-specific configuration needed before the link can

carry that particular network layer protocol.

The operation of a PPP link can be described as having a “life” of sort. Just as humans are

born, grow, have an adult life span and then die, a PPP link is established, configured, used

and eventually terminated. The process of setting up, using and closing a PPP link is

described in the PPP standard as a series of phases or states. This is a type of finite state

machine (FSM), a tool used to explain the operation of protocols.

Figure 24: Overview of PPP Operation

In simplest terms, PPP consists of only three basic steps: link setup, link operation and link termination.

No Link

Link Se tup

and Configuration

Link Operation

Link Termination

Unsuccessful LCP

Configuration Negotiation

Link Failure or

Close Request

Physical Layer

Connection Established

Successful LCP

Configuration Negotiation

LCP Link Termination

Completed

Background Information: The general concept behind an FSM is described in the

topic on the finite state machine of the Transmission Control Protocol (TCP).

PPP Link Phases

When we talk about a PPP link overall, we are talking about the status of the LCP

connection between the two devices; again, LCP governs the overall state of PPP as a

whole. Once an LCP link has been opened, each of the NCPs used on the link can be

opened or closed independently of the overall PPP (LCP) link. We'll see how this works

momentarily.

An excellent way of understanding how PPP works is to look at these phases, and the

process by which transition is made from one to the next during the lifetime of the link. For

purposes of clarity, this description is based on an example where device A is a PC

performing a dial-up networking connection to a remote host B (see Figure 25).

Link Dead Phase

By design, the PPP link always begins and ends in this phase. This phase represents the

situation where there is no physical layer link established between the two devices. It

remains here until the physical layer link is set up, at which point the link proceeds to the

Link Establishment phase.

In our example, when A is first turned on, there is no physical layer connection (modem

connection) between it and B. Once the connection is made, the link can proceed to phase

2. (Note that in a direct connection, such as a serial cable linking two PCs, the link may only

stay in the Link Dead phase for a fraction of a second, until the physical layer connection is

detected.)

Link Establishment Phase

The physical layer is now connected and LCP performs the basic setup of the link. Device A

sends an LCP configuration request message to device B over the physical link, specifying

the parameters it wishes to use. If Device B agrees, it replies with an acknowledgement. If

B doesn't agree, it sends back a negative acknowledgment or rejection, telling device A

what it won't accept. Device A can then try a different configuration request with new

parameters that device B will hopefully accept. This process is described in more detail in

the topic covering LCP.

Hopefully, A and B will eventually come to agreement. If so, the status of the link is

considered LCP open, and will proceed to the Authentication phase. If they cannot come to

an agreement, the physical link is terminated, and we go back to the Link Dead phase.