"TCP/IP Specific Interpretation Volume 2: implementation" Note--IP: Internet Protocol

This chapter describes the structure of the IP packet and the main IP processing process, including input, forwarding, and output.

Shows the common organizational forms of the IP layer.

In the previous article. We see how the network interface puts the incoming IP packets into the IP input queue Ipintrq, and how to invoke a software interrupt, for example, as seen in:

Because hardware interrupts have a higher priority than software outages, they occur before a software outage occurs. Some groupings may be placed in the queue. In software interrupts, the IPINTR

The function continuously removes and processes the grouping from the IPINTRQ until the contest is empty. At the end of the destination, IP packets are re-loaded into packets, and the packets are passed directly through the function call

To the appropriate transport layer protocol. Assuming the packet does not reach the final destination, and assuming that the host is configured as a router, the IP transmits the packet to Ip_forward. Transmission

Protocols and ip_forward the packets to be output to ip_output. The IP header is completed by Ip_output, the output interface is selected, and the packet shards are partitioned if necessary. Finally the group

is passed to the appropriate network interface output function.

When errors occur, the IP discards the packet and, under certain conditions, sends a error message to the packet's source station. These messages are part of the ICMP.

1.IP Grouping

The data that we give to the IP for the Transport layer protocol is called a message. A typical message consists of a transport layer header and application data. The transport protocol that you see is UDP. IP in the newspaper

The first of the text is preceded by its own header to form a packet. Assume that you are in the selected network. The datagram length is too large. The IP splits the packet into several shards, each shard

Includes its own IP header and a piece of data from the original datagram.

Shows the structure of the IP header.

Includes the names of each member in the IP structure

watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqvve9erdkxmq==/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/ Dissolve/70/gravity/center ">

watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqvve9erdkxmq==/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/ Dissolve/70/gravity/center ">

The standard IP header length is 20 bytes, so the IP_HL must be greater than or equal to 5. Greater than 5 means the IP option is immediately after the standard header. If the maximum value of IP_HL is 15, agree to the maximum

40 options for each byte. The IP_HL is calculated in 4-byte units.

2. Input Processing: ipintr function

When the interface puts the packet on the IPINTRQ queue. A soft interrupt is invoked through SCHEDNETISR. When this soft interrupt occurs, it is assumed that the IP process has been SCHEDNETISR

Scheduling. The kernel calls IPINTR. Before calling Ipintr. The priority of the CPU is changed to Splnet.

IPINTR is a large function, mainly divided into 4 parts:

1. Group validation on arrival

2. Option handling and forwarding

3. Group Reload

4. Sub-use

When the options are processed and the split reload is more complex, it will be explained later as a separate chapter.

2.1. Verify that the packets are removed from the IPINTRQ to verify their contents. Corrupted and faulty groupings are voluntarily discarded by themselves. IP version number: Assuming that the network interface does not have an IP address assigned, you must discard all IP packets. Before IPINTR access to any IP header field, it must confirm that Ip_v is 4. IP header Check and: Ipintr the Ip_sum field that is computed by in_cksum and saved in the header.

A non-destructive header should have 0 tests and. If it is not 0, the group is voluntarily discarded by itself.

The following sections describe In_cksum in detail.

3. Byte order Ntohs macro converts the value of all 16bit in the IP header from the network byte order to the host byte order: packet Length (Ip_len), datagram Identifier (IP_ID), and Shard offset (ip_off). 4. The packet length assumes that the logical length of the grouping (Ip_len) is larger than the amount of data stored in MBUF (M_pkthdr.len). And some of the bytes were lost. You must discard the group, assuming that the mbuf is larger than the packet, then remove the extra bytes.

A common cause of missing bytes is that the device drops the bytes that arrive because the data arrives at a serial device that has no or only very few caches.

Extra bytes can occur, such as on an Ethernet device, when the size of an IP packet is less than the minimum length required for Ethernet. Sending this frame is a plus extra byte which is discarded here. 2.2. Option handling and forwarding

Next, call Ip_dooptions to handle the IP option, and then decide whether the grouping reaches its final destination.

Assuming that the grouping does not reach the final destination, NET/3 will

Attempts to forward the packet, assuming the packet arrives at the final destination, is delivered to the appropriate transport layer protocol.

1. Option handling

Ip_dooptions processing option, assuming that Ip_dooptions returns 0,IPINTR will continue to process the grouping, otherwise ip_dooptions by forwarding or discarding the packet is completed on the

The processing of the grouping. The IPINTR is able to process the next grouping in the input queue.

After the option is processed, the IPINTR is compared to the IP address of all the local interfaces configured by the IP_DST in the IP header. To decide whether the grouping has reached its final destination.

Ipintr

Several broadcast addresses related to the interface, one or more unicast addresses, and arbitrarily multiple multicast addresses must be considered.

2. Forwarding

Assuming that the IP_DST and all addresses do not match, the grouping has not reached its final destination.

If forwarding is not prepared, the grouping is discarded, otherwise. Ip_forward attempt to route the packet

To its last destination.

2.3. Group Reload and split

The IPINTR function finally groups the reorganization and grouping. The following chapters will be described in detail.

Finally, Ipintr invokes the Pr_input function in the selected PROTOSW structure to handle the transport messages included in the datagram, and when Pr_input returns, IPINTR continues to handle the

Next grouping.

3.IP Head test: in_cksum function IP Header Checksum calculation method: 1. Put the checksum word Chingqing zero.

2. Then the binary code for each 16 bits (2 bytes) is summed, the meaning of the inverse code summation is to sum each of the 16 bits, and then the resulting and converted to anti-code. Next, describe the steps of the inverse code summation: Look at the following code basic algorithm:

Short checksum (ushort* buffer, int size) {    unsigned long cksum = 0;    while (size>1)    {        cksum + = *buffer++;        Size-= sizeof (USHORT);    }    if (size)    {        Cksum + = * (uchar*) buffer;    }    Cksum = (cksum>>16) + (CKSUM&0XFFFF);     Cksum + = (cksum>>16);     Return (USHORT) (~cksum);}

The reference buffer is a pointer to a 16-bit integer that starts at the beginning of the IP header and the size of the IP header. The While loop is the addition of the contents of the IP header to 16-bit units. Suppose there is no divisible (that is, the size has the remaining less than 16 bits). Then add the remainder, and the cksum is the result of the addition. This result is often more than 16 bits.  Since the checksum is 16 bits, the high 16 bits and the computed cksum are processed again. Reprocessing the first step: Cksum = (cksum>>16) + (CKSUM&0XFFFF);  SUM>>16 is to shift the high 16 bits to 16 bits lower, SUM&0XFFFF is to remove the lower 16 bits and add the new cksum. Reprocessing Step Two: Cksum + = (cksum>>16);　　  When the first step is added, it is very likely that the carry is generated, so add the input displacement to the lower 16 bits again. This will be processed, and the next step is to take the reverse. and cast to 16 bits, which gives the last checksum.

Checksum calculation, the next is how to verify: the receiver to verify, but also for every 16 bits of binary inverse code summation.

The receiver calculates the checksum when the header is compared to the header when the sender calculates the checksum. More than one sender calculates the checksum.

Therefore, assume that the header does not have errors in the transmission process. Then the receiver calculates the result should be all one. Because the receiver calculates a portion other than the checksum, the resulting value is a checksum of the inverse code. The additional checksum is, of course, all in one.

Finally, a sample example of the above process: IP header: F5 6E 06 00 00 (check field) DE B7 5D, 222.183.69.93 C0 A 8 DC--192.168.0.220 calculation: 4500 + 0031 +89f5 + 0000 + 6e06+ 0000 + DEB7 + 455D + c0a8 + 00DC =3 22c4 00 22C4 = 22c7 ~22c7 = DD38 is the checksum that should be populated when an IP packet is received, the IP header is checked if the IP header is correct, as in the same way: calculated: 4500 + 0031 +89f5 + 0000 + 6e06+ DD38 + DEB7 + 455D + c0a8 + 00DC =3 fffc 0003 + FFFC = FFFF The results are all one. That's right.

TCP/IP Specific explanation Volume 2: Implementation Note--IP: Internet Protocol