Header comparison between IPV4 and IPV6

  An IP packet consists of two parts: header and payload/data. The header is the additional information necessary to implement IP communication, and the data is the information to be transmitted by IP communication.

Yellow area (area with the same name)

We can see that the three yellow areas span IPv4 and IPv6. Version (4 bits) is used to indicate the IP protocol version, whether it is IPv4 or IPv6 (IPv4, Version=0100; IPv6, Version=0110). Source Adrresss and Destination Address are the IP addresses of the source and destination respectively.

Blue area (area where the name has changed)

Time to Live (Hop Limit in IPv6). Time to Live originally indicated the maximum survival time of an IP packet: if the IP packet exceeds the Time to Live during transmission, the IP packet will be invalidated. Later, this area of ​​IPv4 recorded an integer (such as 30), indicating that the IP packet will pass through a maximum of 30 routing relays during the relay process. If it exceeds 30 routing relays, the IP packet will be invalidated. Every time an IP packet passes through a router, the router will reduce the Time to Live by one. When a router finds that the Time to Live is 0, it will no longer send the IP packet. The Hop Limit area in IPv6 also records the maximum number of routing relays, which is the same as the function of IPv4. Time to Live/Hop Limit prevents IP packets from being infinitely relayed on the Internet.

Type of Service Service Type (Traffic Class in IPv6). Type of Service was originally used to prioritize IP packets. For example, voice calls require real-time performance, so its IP packets should have higher priority than those of Web services. However, this initially good idea was not adopted by Microsoft. All IP packets generated under Windows have the same highest priority, so at that time, in a mixed Linux and Windows network, Linux IP transmission would be slower than Windows (simply because Linux is more disciplined!). Later, Type of Service was actually divided into two parts: Differentiated Service Field (DS, the first 6 bits) and Explicit Congestion Notification (ECN, the last 2 bits). The former is still used to distinguish service types, while the latter is used to indicate the traffic conditions of the IP packet through the route. Traffic Class of IPv6 is also divided into two parts in this way. The idea of ​​providing different services through IP packets and optimizing them differently has been around for a long time, but the specific approach has not formed a recognized protocol. For example, the ECN area is used to indicate the traffic conditions of the path through which the IP packet passes. If the ECN area received by the receiver shows that the path is very congested, then the receiver should make adjustments. But in practice, many receivers ignore the information contained in ECN. Traffic control is often implemented by higher-level protocols such as TCP.

Protocol (Next Header in IPv6). Protocol is used to describe the protocol followed by the IP packet payload, that is, what is the protocol above the IP packet. It describes what kind of high-level protocol packet (TCP? UDP?) is encapsulated in the IP packet.

Red Zone (zone deleted in IPv6)

Let's take a look at the length information of IPv4 and IPv6. The length of the IPv4 header. At the end of the header, there are options. Each option has 32 bits and is an optional area. An IPv4 header can have no options area at all. If options are not considered, the entire IPv4 header has 20 bytes (each line above is 4 bytes). But due to the existence of options, the total length of the entire header is variable. We use IHL (Internet Header Length) to record the total length of the header, and use Total Length to record the length of the entire IP packet. IPv6 does not have options, and its header is a fixed length of 40 bytes, so IPv6 does not need an IHL area. Payload Length is used to indicate the length of the data part of IPv6. The entire IP packet is 40 bytes + Payload Length.

There is also a Header Checksum area in IPv4. This checksum is used to verify the header information of the IP packet. Checksum is different from the CRC algorithm mentioned earlier in the small speaker. IPv6 does not have a checksum area. The verification of IPv6 packets depends on the high-level protocol. The advantage of this is that it eliminates the time required to perform checksum verification and reduces network latency.

Identification, flags and fragment offset, these three packets are all for fragmentation. Fragmentation means that a router splits the received IP packet into multiple IP packets for transmission, and the router or host that receives these "fragments" needs to reassemble the "fragments" into an IP packet. Different LANs support different Maximum Transportation Units (MTU). If the size of an IP packet exceeds the MTU supported by the LAN, it needs to be fragmented when entering the LAN (just like a pancake is too big and must be broken into pieces before it can be put into a bowl). Fragmentation will bring a great burden to the router and the network. It is best to detect the minimum MTU on the entire path before sending the IP packet. The size of the IP packet does not exceed the minimum MTU to avoid fragmentation. IPv6 is designed to avoid fragmentation. The MTU of each IPv6 LAN must be greater than or equal to 1280 bytes. The default size of IPv6 sent IP packets is 1280 bytes.

[[250244]]

Painful fragmentation

Green area (IPv6 new area)

Flow Label is a new field in IPv6. It is used to remind routers to reuse the previous relay path. In this way, IP packets can automatically maintain the order in which they depart. This is helpful for applications such as streaming media. Further use of Flow Label is still under development.

“I try my best”

When the IP protocol was created, it was a loose network, which was connected by local area networks of various universities and maintained by a group of geeks. Therefore, the IP protocol believed that its environment was unreliable: things like router failure, laboratory fire, and a PhD kicking out the cable could happen at any time.

[[250245]]

Unreliable network

In such a dangerous environment, the transmission provided by the IP protocol can only be "best effort". The so-called "best effort" implies that if things go wrong, don't blame me. I just promised to try my best, but I can't guarantee anything. Therefore, if an error occurs during the transmission of an IP packet (such as checksum mismatch, too much traffic, or Time to Live exceeded), according to the IP protocol, your IP packet will be directly discarded. Game Over, there will be no further efforts to correct the error. Best effort keeps the IP protocol very simple. More quality control is handled by high-level protocols, and the IP protocol is only responsible for efficient transmission.

(What an irresponsible postal system)

"Efficiency first" is also reflected in the order of IP packets. Even if the departure and destination remain unchanged, the IP protocol does not guarantee the order in which IP packets arrive. We already know that the IP relay determines the relay route based on the routing table. If the routing table is updated during the continuous IP packet sending process (for example, a new shortcut appears), then the later sent IP packet will choose a different relay route. If the new path is transmitted faster, then the later sent IP packet may arrive first. This is like a multi-lane highway, where each car is constantly changing lanes, and eventually all lanes are filled with cars. This maximizes highway utilization.

“Queue jumping”

Flow Label in IPv6 can suggest routers to keep some IP packets on the same relay path. But this is just a "suggestion" and the router may ignore it.

Header Checksum Algorithm

The Header Checksum field has 16 bits. It is obtained by taking the 0/1 sequence from the header except the checksum, for example:

9194 8073 0000 4000 4011 C0A8 0001 C0A8 00C7 (hexadecimal, this is a header designed to demonstrate the operation process)

Divide the entire sequence into sixteen digits (that is, 4 hex digits). Cumulatively add up the 4-digit hex digits after the division. If there is a carry over 16 digits, add the carry to the last digit of the last 16 digits:

 Binary Hex
 1001000110010100 9194
 +1000000001110011 8073
 ----------------  
 1 0001001000000111 11207
 + 1
 ----------------  
 0001001000001000 1208

The above calculation is called one's complement sum. To find the sum of all sixteen-digit numbers,

one's complement sum(4500, 0073, 0000, 4000, 4011, C0A8, 0001, C0A8, 00C7) = 1433

Then, invert each bit of 1433 (0->1, 1->0) to get the checksum: EBCC

So, our header is:

9194 8073 0000 4000 4011 EBCC C0A8 0001 C0A8 00C7

After receiving the IP packet, the receiver can calculate the one's complement sum of the above 16-bit numbers, and should get FFFF. If it is not FFFF, then the header is incorrect and the entire IP packet will be discarded.

(Again, the IP header used in the example is not a real header, it is just used to demonstrate the algorithm)

Summarize

The formation of each network protocol has its historical reasons. For example, the IP protocol was designed to connect various scattered laboratory networks. Since the network was very small at the time, the total number of IPv4 addresses (IPv4 was created in the 1970s) was 4 billion. Although it was considered a large number at the time, the digital wave soon brought about an address exhaustion crisis. The main purpose of IPv6 is to increase the address capacity of IPv4, but at the same time, it is improved based on the experience of IPv4 and the technological advances of the new era, such as avoiding fragmentation and canceling the checksum (due to the widespread use of the high-level protocol TCP). Network protocols are not technically complex, and more considerations are policy-oriented.

The IP protocol is a "Best Effort" protocol, and IP transmission is unreliable. However, this design makes the IP protocol efficient.