Understanding of IP packet header validation Fields

Understanding of the IP packet header validation field the IP packet format and the first field:
Www.2cto.com
The data items in the table above are not explained in detail. Here we focus on the following data items:

1. 4-bit Header Length: The length here refers to the number of 4-Bytes units. For example, if the "option" field does not exist, the header of the IP package is 20 Bytes, the header length field should be 5. In addition, the maximum length of the IP packet header is: (2 ^ 4-1) * 4 = 60 Bytes, which is not commonly used, to reduce overhead IP data packets, the header is generally 20 Bytes.

2. Total length of 16 bits: the length of the entire IP packet, in bytes, obviously, we can use the total length of the data packet minus the length of the first packet to get the length of the data content in the IP data packet. Likewise, we can know that the MAX_LENGTH of the IP data packet is 65535 Bytes, this field is required in the IP address header.

3. 16-bit header checksum:
Steve's book says this:
A. Set the checksum field to zero.
B. Perform binary inverse sum for every 16 bits in the header (the whole header is regarded as composed of 16 bits). The result is included in the checksum field.
C. After receiving an IP datagram, perform the binary inverse sum for each 16bit in the header (the High overflow is added to the low level, which is different from the high overflow directly discarded by the General complement operation ).
D. The receiver contains the header checksum in the sender's calculation process. Therefore, if the header has no errors during sending, therefore, the test result calculated by the receiver should be 1 (0 xFFFF). Otherwise, the packet is incorrectly received and the IP packet is discarded.
Note: The sum of the binary anticode here should be interpreted as the sum of each 16Bbit and then the inverse. The key is to add these 16bit units together, if there is no division of 16 (the size still has less than 16 bits), the remaining part should be added. This is the result that should exceed 16 bits, so it is the first step to get cksum by adding the 16-bit higher sum to the 16-bit lower. However, the first step of adding is likely to generate a carry again, so we need to move the carry to the lower 16 bits and add them to the final reverse code of cksum. This is to reverse the result.

The following describes the process through test source code:

Common verification functions:


Main function call:

Theoretically, if you re-verify the received IP packet's check value, the new check value should be 0 XFFFF (of course, the computer uses the complement code for computation, and the result may be 0). Other results indicate that the received data packet has an error. Therefore, cksum 2 should be 0, and cksum 3 should be the same as cksum 1.

Verified here:


The algorithm of the header validation field in the IP packet does not use the Cyclic Redundancy algorithm because the TTL field value of the IP packet changes frequently during transmission over the network. Therefore, the simple superposition method is used, you can avoid the intermediate router and re-calculate the verification value, simply add 1 operation, which can significantly improve the transmission efficiency.