Introduction to TCP/IP checksum Algorithms

 

1. Preface

Checksum calculation is the basic function of NAT and content modification. After performing these operations, you must modify the checksum in the Data header.

2. 16-bit checksum Calculation

2.1 Basic Principles

The IP, ICMP, IGMP, TCP, UDP, and other protocols have the same checksum algorithm. The data streams are regarded as 16-bit integer streams for repeated Superposition calculation. In order to calculate the test, set the test field to 0. Then, the binary inverse code summation is performed for each 16 bits in the valid data range. The result is included in the test and field. If the data length is an odd number, a byte of 0 is added. After receiving the data, the system also calculates the binary inverse code for each 16-digit number in the valid data range. Because the receiver contains a checksum in the sender's header during computing, if the header has no errors during transmission, therefore, the result calculated by the receiver should be 0 or 1 (actually, the essence is the same ). If the result is not all 0 or all 1, it indicates a data error.

2.2 Program Algorithm

2.2.1 C implementation

This is the C language program provided in rfc1071:

Unsigned short csum (unsigned char * ADDR, int count)
{
/* Compute Internet checksum for "count" bytes
* Beginning at location "ADDR ".
*/
Register long sum = 0;
 
While (count> 1 ){
/* This is the inner loop */
Sum + = * (unsigned short) ADDR ++;
Count-= 2;
}
 
/* Add left-over byte, if any */
If (count> 0)
Sum + = * (unsigned char *) ADDR;
 
/* Fold 32-bit sum to 16 bits */
While (sum> 16)
Sum = (sum & 0 xFFFF) + (sum> 16 );
 
Return ~ SUM;
}

Of course, the computing speed will be much faster if you use an assembly language. For different CPU Systems, you need to write different compilations. In the Linux kernel source code, there are IP address verification and source code for various CPU Systems.

2.2.2 incremental Modification

If only one byte is modified, for example, only the TTL in the IP header is modified, it is unnecessary to re-calculate and verify all data within the data range, an incremental algorithm is proposed in rfc1141:

~ C' = ~ (C + (-m) + m') = ~ C + (m-m') = ~ C + M ++ ~ M'
C' is the modified checksum, C is the pre-modified checksum, M is the pre-modified value, M' is the modified value ,~ Is the complement value.

C code implementation:

Updatettl (IPH, n)
Struct ip_hdr * ipptr;
Unsigned char N;
{
Unsigned long sum;
Unsigned short old;
 
Old = ntohs (* (unsigned short *) & ipptr-> TTL );
Ipptr-> TTL-= N;
Sum = old + (~ Ntohs (* (unsigned short *) & ipptr-> TTL) & 0 xFFFF );
Sum + = ntohs (ipptr-> checksum );
Sum = (sum & 0 xFFFF) + (sum> 16 );
Ipptr-> checksum = htons (sum + (sum> 16 ));
}

 

2.3 network applications

2.3.1 IPv4

The Checksum In the IPv4 layer only includes the IPv4 header, excluding the upper-layer protocol header and application layer data. The Checksum must be calculated.

2.3.2 IPv6

The IPv6 Header does not include the checksum field. It only depends on the checksum of the Upper-layer protocol.

2.3.3 ICMP/IGMP

The ICMP/IGMP checksum calculation range is from ICMP/IGMP to the end of data, excluding the IP header. The Checksum must be calculated.

2.3.4 TCP/UDP

The Checksum and calculation of TCP/UDP are a bit special. The calculated data range includes not only the beginning of the TCP/UDP header to the end of the data, but also an IP pseudo header section, the so-called pseudo header, only 12 bytes of data, including the source address (4 bytes), Destination Address (4 bytes), Protocol (2 bytes, the first byte supplements 0), and TCP/UDP packet length (2 bytes ). TCP checksum is required, while UDP checksum is optional. If the checksum field in UDP is 0, the verification is not performed, therefore, if you want to be lazy after modifying the UDP protocol data, set the checksum to 0.

 

3. 32-bit checksum

3.1 Ethernet frame

The ethereframe checksum uses the CRC checksum, which is 4-byte 32-bit. The algorithm is suitable for hardware implementation and its calculation and verification are completed at the underlying layer. You do not need to consider this when the IP stack is above, even if the upper layer directly constructs an Ethernet frame for sending, you only need to construct an Ethernet header. During sending, the bottom layer automatically adds the subsequent checksum.

3.2 sctp

In sctp (Protocol No.: 132) protocol, the checksum calculation is special, and the CRC32 algorithm (rfc3309) similar to the ethereum checksum algorithm is used ), the calculation result is 32 bits instead of 16 bits. The calculation range is from the sctp header to the end of the data, excluding the IP pseudo header.