First look at the "SLIP" protocol. Protocol change can be understood as a simplified version of PPP, which is helpful for deepening the understanding of PPP.
In addition, by observing the shortcomings of the "SLIP" protocol, we can gain a deeper understanding of the clever and targeted design of the PPP protocol.
SLIP defects in simple encapsulation:
Because there is no negotiation process, many parameters (such as IP addresses) need to be implemented
No domain is used to specify the upper-layer protocol. Therefore, only one protocol can be used here, and dynamic decisions cannot be implemented because the negotiation mechanism is not implemented.
Some errors cannot be detected in time without a Checksum. However, you need to wait for the upper-layer protocol to handle the problem. Waste of system resources
Note that ppp is not necessarily related to our commonly used Ethernet. All belong to the data link layer.
The address field (Add) and the control field of the data frame (Ctrl) have no practical significance.
Since the ppp protocol is a Point-to-Point Protocol, no mac address of the Ethernet is required for the ppp protocol.
Protocol used to mark data in packaged packets
I will not talk about the IP protocol. I will focus on the above four protocols.
LCP Protocol
Code field: indicates "sub-Protocol"
ID field: equivalent to the Message ID.
Length field: length field content = total bytes of data (code field + sign field + length field + data field ). Bytes other than the number of characters indicated by the length field will be ignored as the padding byte.
LCP Data Packet Classification
1. Link Configuration packets are mainly used to establish and configure a link. Including Config-Request, Config-Ack, Config-Nak, and Config-Reject
The Type field contains
Some negotiation issues during configuration
When one end of the received Config-Request message identifies all Configuration Parameter options sent and recognizes the content of all Configuration Parameter options data fields, the receiving end will return a Config-Ack packet to the peer end and place the Configuration Parameter options in the configuration request packet intact in
The data domain of the Config-Ack packet (according to the protocol, the order of Configuration Parameter options cannot be changed ). After receiving the Config-Ack packet, the sender of the configuration request enters the next stage from the current stage.
When one end of the received Config-Request message can identify all the Configuration Parameter options sent by the sender, but it does not recognize the content in the data field of some Configuration Parameter options, the acceptor will send a Config-Nak message to the peer. Only the unauthenticated configuration parameters are included in the message.
And the data content of these Configuration Parameter options is the expected value of the end. However, when the receiving end receives the Config-Nak message, it resends the Config-Request message, the difference between the Config-Request Message and the Config-Request Message sent last time is that the content of Configuration Parameter options that are not recognized by the peer is filled in the Config-Request Message sent again after the negotiation. -Request Message (Configuration Parameter options sent from Config-Nak messages ).
When one end of the received Config-Request message cannot identify all Configuration Parameter options sent by the sending end, the receiving end will return a Config-Reject message to the peer end, the data fields in the message only carry Unrecognized configuration parameter options (when the parameter option class is configured
When the domain is not recognized ). After receiving the Config-Reject message, the peer will send a Config-Request message again, the difference between this configuration request message and the previous sending is that the Configuration Parameter options that cannot be identified are deleted.
A link termination message is used to terminate a link. Including Terminate-Request and Terminate-Reply
Link maintenance packets are mainly used to maintain and debug links. Except for the preceding two packet types, all the remaining packet types belong to the link maintenance report.
Maintenance message generation
When the receiving end finds that the Code field of the LCP message is an invalid value, it will respond to the sending end with a Code-Reject message, in the response message, the content of the rejected message is appended.
When the receiving end finds that the Protocol domain of the received data frame is an invalid value, it will respond to the sending end with a Protocol-Reject packet, after receiving the reject message, the sender stops sending data packets of this protocol type. The Protocol-Reject message can only be processed when the LCP state machine is in the Opened State, and the received message will be discarded in other States. The Protocol type and content of the rejected message will be included in the data domain of the Protocol-Reject message.
Echo-Request messages and Echo-Reply messages are mainly used to detect self-loops on two-way links. In addition, some link quality tests and other functions can be provided. When the LCP state machine is in the Opened State, if the Echo-Request is received, an Echo-Reply packet must be sent back to the peer end. Otherwise, messages of this type will be discarded in other LCP states. The length domain of this type of data packet is not directly followed by the data domain, but is to insert four bytes of Magic-Number (Magic word ), this magic word is obtained when the Configuration Parameter options of Config-Request of LCP are negotiated.
NCP Protocol
The NCP protocol mainly includes IPCP and IPXCP. However, in practice, only IPCP is the most common protocol.
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 used to negotiate the configuration parameters required for IP Network Layer Protocol Communication. During the running process, IPCP mainly completes the dynamic negotiation of IP addresses at both ends of the point-to-point communication device.
The protocol message and lcp are similar. The package type is a subset of lcp and is commonly used, such as Config-Request, Config-Ack, Config-Nak, and Config-Reject.
Static negotiation, that is, non-negotiation. IP addresses have been configured at both ends of the point-to-point communication device before PPP negotiation. Therefore, you do not need to negotiate IP addresses at the network layer protocol stage. The only difference between the two parties is to tell the other party their own IP addresses.
Both parties separately tell the other party their ip addresses and other optional information.
Dynamic negotiation means that one end is configured to dynamically obtain the IP address, and the other end is configured to manually assign an IP address to the peer end. This process can be consistent with the process of narrowband dial-up access.
Sender first places the ip field 0 to dynamically send an ip address to the receiver. The last four are consistent with those of static negotiation.
Authentication Protocol
The PPP protocol also provides optional authentication configuration parameters. By default, the two ends of point-to-point communication are not authenticated. Multiple authentication configuration options cannot be carried at one time in the Config-Request message of LCP. Either of them is required (PAP/CHAP)
Note that the authentication process is performed between lcp and ncp.
PAP
PAP authentication is a two-way handshake (single direction ).
The user name and password are in plain text, which is less secure.
CHAP
Start to send a random packet to the verified party and add the host name. When the verified party receives the verification request, it extracts the host name sent by the verified party, search for records of the same user name in the background database of the verified device based on the host name. After finding the records, use the key corresponding to the user name, then, generate a response based on the key, Message ID, and random packet sent by the validators using the Md5 encryption algorithm, and then send the response back to your host name, after receiving a response from the verified party, the verified party extracts the User Name of the verified party and searches for the consistent user name of the party, generate the result based on the key corresponding to the user name, the retained Message ID, and the random message using the Md5 encryption algorithm. Compare the result with the response returned by the verified party. If it is the same, Ack is returned. Otherwise, Nak is returned.
