Point-to-Point Protocol

from Wikipedia, the free encyclopedia
PPP in the TCP / IP protocol stack :
application HTTP IMAP SMTP DNS ...
transport TCP UDP
Internet IP ( IPv4 , IPv6 )
Network access PPP
Serial connection modem ...

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.

Details

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

This paragraph shows PPP over HDLC as described in RFC 1662 . Other common uses of PPP are: PPP over Ethernet ( PPPoE (o = over)) or PPP over ATM ( PPPoA ).

Structure of a PPP frame

HDLC flag

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

HDLC address

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.

protocol

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:

Payload

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

Basic procedure

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)

example

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

Configuration request:

CBCP req.png

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.

Configuration Reject:

CBCP reject.png

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.

Configuration request:

CHAP MRU request.png

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:

CHAP MRU nak.png

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.

Configuration request:

The PoP now sends a configuration request which contains the new MRU and the CHAP.

Configuration Ack:

The client confirms this setting with a configuration acknowledge. This means that the configuration with the new MRU and CHAP has been accepted.

CHAP Challenge:

CHAP Challenge.png

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 .

CHAP Response:

CHAP Response.png

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).

CHAP Success

CHAP Success.png

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:

CCP MPPC request.png

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

Protocol Reject:

CCP MPPC reject.png

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.

Configuration request:

IPCP IPcomp DNS WINS IP.request.png

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.

Configuration reject:

WINS IPcomp reject.png

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.

Configuration request:

IPCP IP DNS request.png

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.

Configuration Nak:

IPCP IP DNS nak.png

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.

Configuration request:

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 ...

Configuration Ack:

... and confirms this to the client.

features

  • Error detection
  • dynamic IP address assignment
  • Authentication mechanisms
  • Negotiating data link layer parameters

See also

literature

Norms and standards

  • RFC 1661 - Point-to-Point Protocol (PPP) July 1994;
  • RFC 1662 - Point-to-Point Protocol in HDLC-like framing

Individual evidence

  1. Point-to-Point (PPP) Protocol Field Assignments. Retrieved October 31, 2019 .