|Internet||IP ( IPv4 , IPv6 )|
The Point-to-Point Protocol ( PPP ; English for point-to-point protocol ) is a network protocol in information technology for establishing connections via dial-up lines . The protocol is based on High-Level Data Link Control (HDLC) and is the successor to Serial Line Internet Protocol (SLIP) and a number of proprietary protocols of this type.
Today, PPP is the standard protocol that Internet providers use to dial in customers. With the help of PPP, the provider communicates important data to the customer computer or router, which is to be connected to the Internet when dialing in, e.g. B. its IP address or the DNS server to be used . In the past, PPP was mostly used over modem or ISDN connections; nowadays, however, it also occurs with newer connection types such as B. GPRS / UMTS cellular data connections or (typically as PPPoE ) for DSL connections.
The specification of PPP is not limited to IP connections, but enables various network protocols (e.g. IPX or AppleTalk ); it is standardized in RFC 1661 . PPP is used less frequently for static connections ( leased lines ), for example to use the authentication mechanisms ( PAP , CHAP ). Modified protocols such as PPPoE or PPTP are mostly used for this.
Structure of PPP
Identifies the frame limitation and corresponds to the HDLC standard. It always has the value 01111110b (0x7e).
This field has the default value 11111111b (0xff). This indicates that all stations should accept the PPP frame. This avoids the assignment of connection addresses.
HDLC control (Control)
The standard value 00000011b (0x03) stands for an unnumbered frame. However, this means that secure transmission is not guaranteed with particularly poor connections. Numbered frames should be used for particularly poor connections, as can occur with wireless networks.
Since the standard values are mostly used for the Address and Control fields, the Link Control Protocol (LCP) provides functions that make it possible to omit these fields.
Specifies the code for the package type in the Payload field. It can also be agreed via LCP that the Protocol field should only be 1 byte in size.
Here is a selection of the codes in hexadecimal:
0x0021- Internet Protocol Version 4 IPv4
0x0057- Internet Protocol Version 6 IPv6
0x80fd- Compression Control Protocol CCP
0x8021- IP Control Protocol IPCP
0x8057- IPv6 Control Protocol IPV6CP
0xc021- Link Control Protocol LCP
0xc023- Password Authentication Protocol PAP
0xc223- Challenge Handshake Authentication Protocol CHAP
The user data field has a variable length, which is agreed by LCP. This field can be filled in if necessary (padding).
HDLC checksum (FCS)
The Frame Check Sequence is a checksum ( CRC ) of the Address, Control, Protocol and Payload fields.
Establishing a PPP connection
PPP establishes communication via a point-to-point connection in four phases:
- Connection establishment and configuration negotiation
- A PPP output node sends LCP frames to configure and establish the data connection.
- Determination of the connection quality
- The connection is tested to determine whether their quality for calling network layer protocols ( OSI sufficient layer). (optional phase)
- Negotiation of the network layer protocol configuration
- The PPP egress node sends NCP frames for selection and configuration. The protocols such as IP , IPX and Appletalk are configured so that packets can be sent from any protocol.
- Connection termination
- The connection remains configured for communication until LCP or NCP frames terminate the connection or an external event occurs. (e.g. inactivity of the user)
The establishment of a PPP connection is explained here using PPPoE as an example. A similar process also applies to modem and ISDN connections. The main differences are in the data and IP header compression, which is not possible with DSL .
First, a brief explanation of the images used: The
receiver (always on the right) and transmitter (always on the left) are marked in red. Receiver and sender always have MAC addresses . Each package also has an ID (marked green). This ensures that the correct answer is assigned to each request, since the question-and-answer game is usually nested. The client is the computer of the internet user and the PoP (" Point of Presence ") is the remote access server of the internet service provider (ISP). In our example, PoP is NortelNe_ * and the client is 3Com_ *. The option field of the PPP frame is marked in blue. Data and options are entered there. This field is referred to exclusively.
LCP - Link Control Protocol
In this packet, the client sends a CBCP request (proposal) to the PoP. The Microsoft Call Back Control Protocol (CBCP) enables the PoP to be called back. This is especially true for ISDN connections. By calling the PoP back, telephone costs can be saved.
Since this is not possible in our case (because DSL), the PoP responds with a reject (configuration not accepted). The configuration of the connection that was rejected is in the option field. A reject means that the PoP does not support this feature at all and therefore no further configuration negotiations are possible.
Next, the PoP proposes the authentication protocol CHAP and a Maximum Receive Unit (MRU) of 1492 bytes via an LCP configuration request . Due to the PPP header, the MRU is 8 bytes smaller than the maximum possible MTU of 1500 bytes.
Configuration Nak (Nak means not acknowledged ), in contrast to Reject, means something like: “I reject this configuration and ask for a new negotiation.” An MTU of 1480 bytes is set in the Windows dial-up network. The client therefore rejects the PoP proposal and at the same time transfers the set MTU / MRU.
The PoP now sends a configuration request which contains the new MRU and the CHAP.
The client confirms this setting with a configuration acknowledge. This means that the configuration with the new MRU and CHAP has been accepted.
After the client has accepted CHAP as the setting, the PoP sends a 128-bit random number (challenge). This can be seen in the picture below as a hex value (highlighted in color). This challenge is stored in the value field of the CHAP package. The client uses the MD5 algorithm to calculate a hash value from the password of the Internet account and the challenge .
The client now sends the hash as a response to the PoP. The hash can be seen as a 128-bit number in hex form at the bottom of the picture. The hash is again in the value field of the CHAP packet. At the same time, the client sends the login (blackened) to the PoP in the name field. The PoP (or a RADIUS server ) looks at the login in its database for the appropriate password. From the password and the challenge (the same as for the client), it calculates a second hash value via MD5 . Both hash values (the one calculated by the client and the one calculated by the PoP) are now compared. If both hash values match, the login is successful (CHAP Success). If they are different, the login is not successful (CHAP Fail).
Both hash values match and you have thus proven that you have the correct password. Proven because, unlike PAP , the password is not transmitted as clear text. The next step is to set the data compression.
Configuration Request - CCP:
The data compression for the connection is set via the Compression Control Protocol (CCP). The client suggests Microsoft Point-to-Point Compression (MPPC).
Since DSL does not support any data compression at all and thus also PoP ( DSL-AC ), the CCP is rejected and not just the MPPC.
NCP - Network Control Protocol
The NCP transmits the data required by the network layer protocol so that it can run. There are several NCP implementations: IPCP for Internet Protocol , IPXCP for IPX, and AppleTalk Control Protocol for AppleTalk .
The IPCP - IP Control Protocol
The IPCP is used, for example, to assign IP and to set the IP header compression. The IP assignment concerns the IP address of the PoP and the dynamic IP of the client, which the ISP assigns from an IP pool. In addition, there are the two IP addresses of the DNS . The client can also suggest IP addresses. IPCP belongs to the NCP protocol family.
The client sends a request to the PoP. This request contains the IP header VJ compression, the WINS , DNS and the IP address for the client. The IP address (e) field will later also contain the PoP ID. The PoP now selects the options that it wants to use or supports.
WINS is not used on the Internet and DSL does not support IP header compression. Therefore the PoP responds with a reject. Only the DNS and the IP address remain for the configuration.
Since only the IP addresses for the client and the two DNS servers are left for configuration, the client only sends these as a request. For example, other addresses than "0.0.0.0" could be suggested here. The most that could be suggested is the first and second DNS server.
Since "0.0.0.0" as the DNS and IP address are of course wrong, the PoP sends a Configuration Nak and its proposal at the same time.
The client sends the content (DNS, IP) of the previous Configuration-Nak frame once again as a request to the PoP for confirmation. The PoP now knows that the client agrees with the configuration ...
... and confirms this to the client.
- Error detection
- dynamic IP address assignment
- Authentication mechanisms
- Negotiating data link layer parameters
- Pearson Studium, Andrew S. Tanenbaum , Computer Networks, p. 268ff (in 4th edition p. 238ff)
- All codes were determined with Wireshark
Norms and standards
- RFC 1661 - Point-to-Point Protocol (PPP) July 1994;
- RFC 1662 - Point-to-Point Protocol in HDLC-like framing
- Point-to-Point (PPP) Protocol Field Assignments. Retrieved October 31, 2019 .