ppp protocol function
First look at the "SLIP" protocol. The modified protocol can be understood as a simplified version of PPP, which is helpful for deepening the understanding of the PPP protocol.
In addition, by observing some shortcomings of the "SLIP" protocol, we can have a deeper understanding of the ingenious design of the PPP protocol and 
the defects of the simple SLIP encapsulation method:
because there is no negotiation process, many parameters (such as ip address) It needs to be implemented until
there is no domain to specify the upper-layer protocol, so only one protocol must be used here, and because there is no negotiation mechanism, dynamic decisions cannot be implemented
without checksums, and some errors cannot be detected in time. Instead, it needs to wait until the upper layer protocol is processed. Waste of system resources
Note that ppp has nothing to do with our commonly used Ethernet. Both belong to the data link layer. 
The address field (Add) and the control field of the data frame (Ctrl also have no practical significance.
Considering that the ppp protocol is a point-to-point protocol, the ppp protocol does not need any mac address of Ethernet.
The protocol field indicates the protocol that wraps the data in the data packet. The 
ip protocol does not Let’s talk about it, let’s focus on the above four protocols
LCP protocol 
code field: mark “sub-protocol” 
identification field: equivalent to the message ID.
Length field: length field content = total byte data (code field + flag field + length field + Data field). Bytes other than the number of bytes indicated by the length field will be regarded as padding bytes and
the classification of LCP data packets will be ignored
. 1. Link configuration packet, which is mainly used to establish and configure a link. .including Config-Request, Config-Ack, Config-Nak and Config-Reject 
where the type field contains 
some negotiation issues during the configuration process
When the receiving end of the Config-Request message can identify all the configuration parameter options sent and the content of all the configuration parameter options data fields, the receiving end will return a Config-Ack message to the opposite end and configure the request message The configuration parameter options in the
Config-Ack message are placed intact in the data field of the Config-Ack message (according to the provisions of the protocol, the order of the configuration parameter options cannot be changed). When the sender of the configuration request message receives the Config-Ack message, it will enter the next stage from the current stage.
When the receiving end of the Config-Request message can identify all the configuration parameter options sent by the sending end, but does not recognize the content in the data field of some configuration parameter options, the receiving end will respond to the opposite end with a Config-Nak message The message only carries unapproved configuration parameter
options , and the data content of these configuration parameter options is the value expected by the end. However, when the receiver receives the Config-Nak message, it will resend the Config-Request message. The difference between this Config-Request message and the last Config-Request message is that the configuration is not recognized by the peer end. The content of the parameter options is filled in the Config-Request message sent again after the negotiation (those configuration parameter options sent back by the Config-Nak message).
When the end receiving the Config-Request message cannot identify all the configuration parameter options sent by the sender, the receiving end will return a Config-Reject message to the peer end, and the data field in the message only carries those Unrecognized configuration parameter option (when the
type field of the configuration parameter option is not recognized). When the peer end receives the Config-Reject message, it will also send a Config-Request message again. The difference between this configuration request message and the last one sent is that the unrecognized configuration parameter options are deleted.
Link termination packets are mainly used to terminate a link. Includes Terminate-Request and Terminate-Reply
Link maintenance packets are mainly used to maintain and debug links. Except for the above two packet types, all the remaining packet types belong to the link maintenance packet
.
When the receiver finds that the code field of the LCP packet is an illegal value, it will respond to the sender A Code-Reject message with the content of the rejected message appended to the response message.
When the receiver finds that the protocol field of the received data frame is an illegal value, it will respond with a Protocol-Reject message to the sender, and the sender will stop sending this protocol type after receiving the rejection message. data message. The Protocol-Reject message can only be processed when the state machine of the LCP is in the Opened state, and the message will be discarded when it is received in other states. The protocol type and packet content of the rejected packet will be carried in the data field of the Protocol-Reject packet.
Echo-Request packets and Echo-Reply packets are mainly used to detect self-loop problems on bidirectional links. In addition, they can also perform some link quality tests and other functions. When the LCP state machine is in the Opened state, if an Echo-Request is received, an Echo-Reply message needs to be sent back to the peer. Otherwise, in other LCP states, the packets of this type will be discarded. The length field of this type of data message is not directly followed by the data field, but to insert a 4-byte Magic-Number (magic word), which is obtained during the negotiation of the configuration parameter options of the LCP Config-Request of.
NCP protocol
The NCP protocol mainly includes IPCP, IPXCP, etc., but we only encounter the IPCP protocol most often in practice.
Note: NCP is not a specific protocol, but a general term for protocols such as IPCP and IPXCP.
IPCP
The IPCP control protocol is mainly responsible for completing the option negotiation of the configuration parameters required by the IP network layer protocol communication. During the running process of IPCP, it is mainly to complete the dynamic negotiation of IP addresses between two ends of a point-to-point communication device.
Protocol packets are similar to lcp. The packet type is a subset of lcp, commonly used such as Config-Request, Config-Ack, Config-Nak and Config-Reject
static negotiation, that is, no negotiation. Both ends of a point-to-point communication device have already configured IP addresses before PPP negotiation, so there is no need to negotiate IP addresses at the network layer protocol stage, and the only thing the two sides have to do is to tell each other their own IP addresses. 
Both parties tell each other their ip and other optional information for
dynamic negotiation, that is, one end is configured to dynamically obtain an IP address, the other end is manually configured with an IP address, and an IP address is allowed to be assigned to the opposite end. This process actually It can be consistent with the process of narrowband dial-up Internet access. The 
sender first sets the ip domain to 0 to dynamically send an ip address to the receiver. The last four are statically negotiated.
The authentication protocol
PPP also provides optional authentication configuration parameter options. By default, both ends of point-to-point communication do not perform authentication. The Config-Request message of LCP cannot carry multiple authentication configuration options at one time, and must choose one of the two (PAP/CHAP).
Note that during the authentication process, PAP authentication is performed between lcp and ncp.
PAP 
authentication is a two-way handshake (one-way).
The user name and password are in plain text, and the security is poor.
CHAP
开始由验证方向被验证方发送一段随机的报文，并加上自己的主机名。当被验证方收到验证方的验证请求，从中提取出验证方所发送过来的主机名，然后根据 该主机名在被验证方设备的后台数据库中去查找相同的用户名的记录，当查找到后就使用该用户名所对应的密钥，然后根据这个密钥、报文ID和验证方发送的随机 报文用Md5加密算法生成应答，随后将应答和自己的主机名送回，同样验证方收到被验证方发送回应后，提取被验证方的用户名，然后去查找本方一致用户名后， 根据该用户名所对应的密钥、保留报文ID和随机报文用Md5加密算法生成结果，和刚刚被验证方所返回的应答进行比较，相同则返回Ack，否则返回Nak
出处：https://www.2cto.com/net/201310/250636.html