Lecture 8 on basic network knowledge: a preliminary understanding of the IP protocol

This article describes the IP protocol required to understand routing issues. Most things on the internet use the IP protocol. Different from Ethernet, understanding this protocol is very important for understanding network applications in a wider range. In a later article, this lecture will introduce TCP and UDP protocols, routing theory, and further study specific routing protocols.
The IP protocol is directly located on the layer-2 data link layer and is responsible for generating the data packets sent to the destination. The IP protocol was originally defined in RFC 791 and was subsequently modified and revised several times. However, the basic design concept of the IP protocol remains unchanged. The IP layer does not provide any type of traffic control or sorting. These functions are left to the upper layer. We will use the word "datagrams" to refer to a complete IP address information. The word "packets" refers to a single IP packet.
The IP protocol is used to receive and send specified IP address packets. However, the IP protocol does not guarantee the reliability of data transmission. There is no "retry" concept in the IP protocol layer. For various reasons, data packets may be lost, corrupted, duplicated, not transmitted in sequence, or delayed. The IP protocol is also responsible for handling IP options and providing feedback in the form of ICMP errors and control messages.
The IP data header is 20 bytes long, followed by a layer-2 header (because the IP protocol is a layer-4 protocol ). The IP data section contains a complete set of TCP or UDP data packets and other information, as shown in the following figure. It should also be noted that if the IP option is used, the IP data header can exceed 20 bytes.

Ethernet header

IPv4 Header

Data (TCP, etc)

The goal of the IP protocol is simple: generate a data packet sent to the destination. Besides sending this data packet to the next hop router, you do not need to worry about anything. In fact, the IP protocol is very complex. Otherwise, the IP data header does not need so many fields. It is very important to study IP data headers carefully. The meaning of these fields starting from the first byte is:
• Version: the version of the IP protocol used. The IPv4 packet sets this field to "4 ".
• Header Length: Describes the length of a header in multiples of four bytes. Because the IP Option function is rarely used. Therefore, you may see that the value is "5", which means that the header length is 5 4 bytes, that is, 20 bytes.
• Service Type: this field is rarely used. However, theoretically, this field aims to provide the router with the priority order information of specific IP datagram in the forwarding queue. It is mainly used to improve service quality. The host can choose to set various options, such as low latency, high data throughput, and high reliability. Most routers ignore these options.
• Total Length: the total length of the entire IP packet, including the header, in bytes. Because this field has 16 bits, the IP packet length is limited to kb. This number defines the IP data packet of the field, rather than the length of the whole IP data packet.
• IP datagram ID: it is sometimes called a "segment identifier ". This identifier is used to determine which IP datagram belongs to a specific IP data packet. If the IP Protocol needs to combine multiple single IP data packets into one IP data packet, this field is necessary.
• Flag: the DF (not sharding) bit is used in this field to indicate that the router does not segment IP packets. Here, you can also use the MF (more multipart) identifier.
• Intra-segment offset: the segment offset of the original datagram, expressed in 64-bit blocks.
• TTL: the number of hops contained before IP packets are destroyed. The survival time is to avoid the endless flow of data packets on the Internet.
• Protocol Type: Specify the next protocol. That is, the header that will be encountered in the data section of the IP data packet.
• Header checksum: a header checksum instead of a Data checksum.
• IP Source: IP address of the host that sent the original data packet.
• IP destination: IP address of the IP packet destination host.
When the router receives an IP packet, the router first needs to check the destination of the packet. If the router has a route to the destination, the router will reduce the TTL of the data packet, re-calculate the checksum, and then send the data packet. If an error occurs, an ICMP error notification is sent, and the packet is discarded. The IP protocol works in this simplest way: it must repeat the preceding steps in every packet.
IP segmentation is very important for IP functions. It provides the true meaning of these header fields. Not every physical network that sends data packets can accept data packets of the same size. Various two-layer frame formats allow sending data of different sizes at the same time. The maximum MTU allowed is 65KB, and the minimum is 68 bytes. RFC 1122 requires that all hosts must be able to reassemble a maximum of 576 bytes of datagram, but in fact, they should be able to recombine the same type of datagram as the MTU of the system interface.
When an IP datagram is sent on the internet, you do not know what will happen to the MTU along every two-tier link. You may connect to your ISP over Ethernet. However, the remote site you are trying to access may be on an ISDN link. Therefore, your IP packet must be segmented before reaching the last hop point. Segmentation may need to be performed multiple times. If we want to send a 2000-byte packet to a remote site connected to ISDN, we may have segmented the packet to meet our 1500-byte link requirements. But it is larger than 576 bytes (isdn mtu ). Therefore, the last router must segment the data packet before arriving at the ISDN link.
We should know that IP is not a reliable protocol. Therefore, if any IP segment is lost in the transmission path, the entire datagram must be resent. There is no way for the IP address to obtain the specific part lost in the datagram. Therefore, when an error occurs, the result is to resend all the segments of the datagram. Sometimes, the blocked router has to discard some data packets. If the discarded data packet happens to be part of a 65KB datagram, the entire data packet must be resent. TCP or other upper-layer protocols generally know whether a complete datagram is completely lost and can be re-sent. However, the TCP protocol cannot tell you whether the part of a datagram is lost, because the IP address receives the datagram is incomplete and will never send the datagram to the TCP protocol of the upper layer. If the TCP protocol never receives this datagram, it will be resent. Apparently, the loss of a small part of a K packet does not help to ease a blocked link, but causes more serious blocking. Generally, the size of a UDP application cannot exceed 576 bytes. First, there are not many links with MTU smaller than 576 bytes. Therefore, this IP datagram will not be segmented. Second, remember that 576 is a special number for all the end point systems using the IP protocol: they must be able to recombine the datagram into this size. Devices with limited memory configuration may encounter difficulties in processing data larger than this specification. Therefore, this method is recommended.
Suppose we are a host, and we want to send a 1550-byte datagram (1530 bytes of data + 20 bytes of header ). However, our MTU is 1500 bytes. We must be divided into two data packets for sending. The IP header looks like this:
• Fragment 0, offset = 0, size = 1480, MF bit settings.
• Fragment 1, offset = 1480, size = 50
The ip id and IP address in the segment are always the same as those in the original IP datagram. However, the header's check value, deviation amount, and field length must change. When the other party receives the first packet and sees that the packet is a segment, the other party will wait for it to obtain other segments and re-combine these segments, and then send it to the upper-layer protocol.
After the datagram is sent, if DF bytes are not set in the IP mark, we will not hear any messages about the datagram. However, what happens if the MTU of a link is 400 bytes? Before a 1480-byte packet can be sent, the router in this link segments the packet. The MTU path in the previous tutorial can be used to solve the problem that the intermediate router is a packet segment. Segmentation takes time and valuable router resources. The main reason for avoiding excessive segmentation is that excessive segmentation will inevitably lead to communication latency.
The re-combination of data packets is always completed at the final destination. Therefore, the intermediate Router does not need to store IP datagram. This also means that IP data packets can be routed separately on different paths without confusion. This is an important concept to be understood. This will enable multiple use of the IP protocol. Regardless of the order in which the receiver receives the packet, the receiver can re-combine the data packets according to the segment offset field in the IP header.
Now we understand segmentation. We found that segmentation raised the following question: is the IP address really unrelated to the data link layer?
Summary
The IP protocol is unreliable. When IP data packets are lost, a higher-level protocol should be required to recognize the loss of data packets and send them again.
Each time an IP packet is sent, the router must re-calculate the IP header checksum.
IP segmentation can delay the router from sending one data packet or sending data packets on multiple links. The endpoint system can re-combine the entire IP datagram.

Lecture 7: understanding and using ICMP protocol
Lecture 6 on basic network knowledge: Implementing subnets, including IPv6)
Lecture 5: Learning Spanning Tree Protocol
Lecture 4: understanding the data link layer
Network basics Lecture 3: Understanding OSI network layering
Network basics Lecture 2: Understanding subnet and CIDR
One of the basic network knowledge lectures: understanding the meaning of IPv4 addresses