Point-to-Point Protocol

The Point - to-Point Protocol ( engl. "Point-to - Point Protocol " ), short- PPP, is in information technology, a network protocol for establishing a connection via dial-up lines. The protocol is based on HDLC and is the successor to SLIP, as well as a number of proprietary protocols of this type

Today, PPP is the standard protocol that Internet service provider for dialing the customer. With the help of PPP shall notify the provider to the client computer or router that is to be connected when dialing in to the Internet, with important data, such as its IP address or to use a DNS server. Earlier PPP was mostly used with modem or ISDN connections; However, nowadays it comes with newer connection types such as GPRS-/UMTS-Mobilfunkdatenverbindungen or ( typically referred to as PPPoE) for DSL connections are used.


The specification of PPP is not limited to IP connections but also allows various network protocols (such as IPX or AppleTalk ); it is standardized in RFC 1661. Rare PPP static links ( leased lines ) is used, for example, the authentication mechanisms (PAP, CHAP) for use. For this purpose, usually modified protocols such as PPPoE or PPTP are used.

Development of PPP

In this paragraph, PPP over HDLC is shown, as described in RFC 1662. Other common uses are PPP: PPP over Ethernet ( PPPoE) or PPP over ATM ( PPPoA ).

HDLC flag:

Identifies the frame boundary and corresponds to the HDLC standard. It always has the value 01111110b ( 0x7e ).

HDLC address:

This field has a default value of 11111111b ( 0xff ). This indicates that all stations are to accept the PPP frame. Thus, the allocation of link addresses is avoided.

HDLC controller ( Control):

The default value 00000011B ( 0x03) is an unnumbered frame. Thus, no secure communication is assured at particularly bad connections though. In particularly bad links, such as can occur in wireless networks, should be used numbered frames.

Since most of the default values ​​are used for the address and control fields, sets the Link Control Protocol (LCP ) functions are available that make it possible to omit these fields.

Protocol / Protocol: Specifies the code for the type of packet in the payload field. About LCP can also be agreed that the protocol field should be only 1 byte in size.

Here is a selection of the codes in hexadecimal:

User data:

The payload field has a variable length, which is agreed by the LCP. This field can be filled where necessary ( padding).

HDLC checksum (FCS):

The Frame Check Sequence is a checksum ( CRC) of the fields Address, Control, Protocol and Payload.

Preparation of a PPP connection

Basic Procedure

PPP, the communication over a point-to -point connection in four phases forth:


Here, the preparation of a PPP connection is explained using the example PPPoE. A similar procedure applies for modem and ISDN connections. Differences there are in particular in the data, and IP header compression, which is not possible with high speed.

First, a brief explanation about the pictures used: Marked red are here receiver (which is always right) and transmitter (which is always the left). Receiver and transmitter always have MAC addresses. Each package also has an ID ( marked in green). This ensures that for each request (request) is assigned to the correct answer, because the question and answer game runs mostly nested. As a client, here the computers of Internet users and as a POP ( " Point of Presence ") of the remote access server of the Internet service provider (ISP ) is called. PoP is in our example NortelNe_ * and * client is 3Com_. Is marked in blue the Options field of the PPP frame. There are data entered and options. This field is exclusively related.

LCP - Link Control Protocol

Configuration Request:

In this package, the client sends a CBCP request ( proposal ) to the PoP. The Microsoft Callback Control Protocol ( CBCP ) allows the recall of the PoP. This is especially true for ISDN connections. By the recall of the PoP phone costs can be saved.

Configuration Reject:

As this is not possible in our case (since DSL), answers the PoP with a Reject ( configuration not accepted). The configuration of the compound, which was rejected, is in the Options field. A Reject means that the PoP do not support this feature and therefore no further configuration negotiations are possible.

Configuration Request:

Next, the PoP proposes an LCP Configuration Request before the CHAP authentication protocol and a Maximum Receive Unit (MRU ) of 1492 bytes. MRU is smaller by the PPP header of 8 bytes as the maximum MTU of 1500 bytes.

Configuration Nak:

Configuration Nak ( Nak means 'Not acknowledged ') means, in contrast to reject as much as "I reject this configuration and ask for a new trial ." In the Dial-up Networking Windows an MTU is set to 1480 bytes. Therefore, the client rejects the proposal from the PoP and are simultaneously the set MTU / MRU.

Configuration Request:

Configuration Ack:

The client confirmed this setting with a ' Configuration Acknowledge '. This means that the configuration with the new MRU and the CHAP was adopted.

CHAP Challenge:

After the client CHAP adopted as the setting, the PoP sends a 128 -bit random number ( challenge). This can be seen in the image below as a hex value (color -coded). This Challenge is stored in the CHAP packet value field. From the password of the internet accounts and the Challenge of the client through the MD5 algorithm then calculates a hash value.

CHAP Response:

The client then sends the hash as a response (answer ) to the PoP. The hash can be seen in the image as a 128-bit number in Hexform below. The hash is back in the CHAP packet value field. Simultaneously, the client sends the login ( blackened ) to the PoP in the Name field. The PoP (or a RADIUS server) looks with the login in its database for the matching password. From the password and the Challenge ( the same as the client ), he calculated over a second MD5 hash value. Both hash values ​​( both the client and the value calculated by PoP ) are now compared. If the two hashes match, then the login is successful ( CHAP Success). If they are different, then the login is not successful ( CHAP Fail).

CHAP Success

It would match hash values ​​and you have proved that you have the correct password. Proved is because the password in contrast to PAP is not transmitted as plain text. Next, the data compression is now set.

Configuration Request - CCP:

About the Compression Control Protocol (CCP ) data compression for the connection is set. The client suggests that, in the Microsoft Point - to-Point Compression ( MPPC ).

Protocol Reject:

Since DSL at all and thus the PoP (DSL -AC) does not support data compression, the CCP will be rejected and not only the MPPC.

NCP - Network Control Protocol

The NCP sends the data that are needed by the network layer protocol, so this can be run. There are several implementations of the NCP: IPCP for the Internet Protocol, IPXCP for IPX and AppleTalk Control Protocol for AppleTalk.

The IPCP - IP Control Protocol

The IPCP is used for example for the IP assignment and for setting the IP header compression. The IP assignment relates to the IP address of the PoP and the dynamic IP that the ISP assigns a IP pool of the client. Furthermore, the two IP addresses of the DNS happen. The client may also propose IP addresses. Belongs to IPCP NCP protocol family.

Configuration Request:

The client sends a request to the PoP. This request includes the IP header VJ, WINS, DNS and the IP address for the client. The IP address field (s) later also includes the IP of the PoP. The PoP now selects the options that he wants to use, or support.

Configuration reject:

On the Internet, WINS is not used and does not support the IP header compression of DSL. Therefore, the PoP responds with a reject. Remain so for the configuration of only the DNA and the IP address.

Configuration Request:

Since only the IP addresses are left for the client and the two DNS servers to configure the client only sends this as a request. Here, for example, other addresses could drinstehen as "" as a suggestion. Could suggest one more than the first and second DNS server.

Configuration Nak:

Since "" as the DNS and IP address, of course, are false, the PoP sends a Configuration Nak, while his proposal.

Configuration Request:

The content (DNS, IP) of the preceding Configuration Nak - frame, the client sends again to confirm the request to the PoP. The PoP now knows that the client is satisfied with the configuration ...

Configuration Ack:

Confirmed this ... and the client.


  • Error detection
  • Dynamic IP address assignment
  • Authentication mechanisms
  • Negotiation of link layer parameters