In-depth understanding of IP protocol in practice

In-depth understanding of IP protocol in practice

The TCP/IP protocol stack actually does not only have two Protocols: TCP and IP. However, using these two protocols as the collective name of the protocol stack is sufficient to reflect its importance in the TCP/IP protocol stack, it is precisely because of the IP protocol that enables communication between different networks. Of course, to mention the IP protocol, we also need to analyze its related protocols, such as ICMP, IGMP, and ARP. The relationship between these protocols and the IP protocol can be as follows:

However, we only focus on the fields in the IP protocol. For more information about other protocols, see this topic.

Next we will combine the established network environment and use some means to thoroughly understand the specific meanings of fields in the IP protocol. I believe this will be much easier to understand than simply reading theoretical books.

The environment used this time is as follows:

Operating System: Ubuntu 15.10

Network Device simulator: GNS3

Packet capture software: Wireshark

The operating system used here is Ubuntu rather than Windows. It is just out of personal preferences. In fact, there is no problem in using Windows.

1. Establish a network environment

The analysis of the IP protocol does not require a complex network environment. We only need to establish the following network environment with two nodes:

In Linux, configure the IP address 192.168.1.1/24 correctly, and then configure the following on Cisco router 3600:

Router>enRouter#conftRouter(config)#intf0/0Router(config-if)#noshuRouter(config-if)#ipadd192.168.1.2255.255.255.0

Then the environment is set up. We can run ping on the Linux operating system to test the network accessibility:

xpleaf@leaf:~$ping192.168.1.2PING192.168.1.2(192.168.1.2)56(84)bytesofdata.64bytesfrom192.168.1.2:icmp_seq=1ttl=64time=2.39ms64bytesfrom192.168.1.2:icmp_seq=2ttl=64time=2.11ms64bytesfrom192.168.1.2:icmp_seq=3ttl=64time=1.65ms64bytesfrom192.168.1.2:icmp_seq=4ttl=64time=2.04ms^C---192.168.1.2pingstatistics---4packetstransmitted,4received,0%packetloss,time3004msrttmin/avg/max/mdev=1.658/2.052/2.398/0.267ms

OK. No problem. The network is normal!

Note that in this network environment, the Linux operating system is a real operating system, and the Cisco router is similar to the real one. This benefits the powerful functions of GNS3! If you have never used GNS3, please try again.

2. IP protocol message format

As follows:

In the message format, "Header" is the content we will discuss. In the practical analysis below, we will mainly discuss the following fields:

• Version, header length, service differentiation, and total length

  Identifier, flag, and slice offset

  Survival time, protocol, header check, source address, Destination Address

  For the convenience of the experiment, we will divide the above three groups to describe the detailed meaning of each field and the actual data packet content. However, we can see that, the variable part is not mentioned here. The discussion below is based on the Fixed Header Length (20 bytes.

  3. Analyze the meaning of each field in the IP protocol in practice

  (1) version, header length, service differentiation, and total length

  We will capture a packet to analyze the content of these four fields and start Wireshark (in GNS3 software, Wireshark can be directly started on the link between the Linux operating system and the Cisco router, this is one of the functions of GNS3 software) to monitor the network interfaces of Linux operating systems:

  Then, run the following command on Linux:

  xpleaf@leaf:~$ping192.168.1.2PING192.168.1.2(192.168.1.2)56(84)bytesofdata.64bytesfrom192.168.1.2:icmp_seq=1ttl=64time=1.75ms^C---192.168.1.2pingstatistics---1packetstransmitted,1received,0%packetloss,time0msrttmin/avg/max/mdev=1.755/1.755/1.755/0.000ms

  We only sent an ICMP packet to the router. We can see the packet capture situation on Wireshark software:

  We can see that Wireshark caught two packages. Why? Data communication goes back. When we send an ICMP request packet, we also receive an ICMP response packet. As we can see above, one is request and the other is reply, for more information about ICMP, see other articles on this topic.

  Taking the package we sent as an example, we will analyze the meanings of the four fields in the IP protocol: version, header length, service differentiation, and total length, as follows:

  • Version

    4-digit IP protocol version. Currently, there are two types of IP protocol versions, IPv4 and IPv6, which are widely used. IPv6 is currently being deployed, however, it may take some time to popularize IPv6. Obviously, IPv4 is used in our network environment. You can view the captured packet content:

    As you can see, the Version number field is Version 4, which indicates that the IPv4 protocol is in use.

    • Header Length

      It can represent the maximum decimal value of 15, but it must be noted that the Unit is 4 bytes, that is, if the four digits are 0101 (decimal indicates 5 ), this means that the header length is 5*4 bytes = 20 bytes. Because the unit is 4 bytes, the header length should be an integer multiple of 4 bytes. Obviously, because the four digits indicate a maximum of 15 decimal characters, the header length can be 15*4 bytes = 60 bytes. Here we only discuss the Fixed Length of the header length (variable part is not used much), so the size must be 20 bytes. You can view the captured data packet content:

      • Differentiated Services

        It occupies 8 bits, but this field is generally not used. Just check the packet content:

        • Total Length

          It represents the length of the header and data, in bytes. Because 16-bit binary can represent a maximum of 65535 decimal digits, this also means that the maximum length of a datagram is 65535*1 byte = 65535 bytes. However, however, MTU (maximum transmission unit) is restricted on the data link layer (for example, for Ethernet, MTU is 1500 bytes, that is, the datagram length cannot exceed 1500 bytes ), therefore, slice will certainly be performed. However, normally there are few such large data packets.

          Tip: Despite the standard MTU settings, the MTU of a device can be set manually. MTU is set based on the interface. It can be modified on Windows or Linux, or on the Management router interface. (Selected from Wireshark packet analysis practice P107, but I have not tested it)

          Check the captured data packets:

          We can see that the total length is 84 bytes, minus the 20 bytes of the IP header, that is, the length of ICMP data is 64 bytes, and the prompt from the command we just executed:

          PING192.168.1.2(192.168.1.2)56(84)bytesofdata.64bytesfrom192.168.1.2:icmp_seq=1ttl=64time=1.75ms

          We can also know that the ICMP Data Length is indeed 64 bytes (56 bytes of actual data + 8 bytes of ICMP header), which further verifies our calculation results.

          OK. The analysis of version, header length, service differentiation, and total length is here. It is relatively simple, but the problem of sharding is troublesome, next we will analyze what the IP address header of the fragmented data packet is like.

          (2) logo, logo, and slice offset

          To observe and analyze the IP header with these features, We Need To resend the Large ICMP packet. However, before executing this command, first observe the fields in the preceding packet:

          Based on this, we will mention the functions of each field and then perform the sharding practice:

          • Identifier

            16. The IP software maintains a counter in the memory. Each time a datagram is generated, the counter is incremented by 1 and the value is assigned to the field, as shown in the above 47440. This means that the values of the Mark Fields of each generated datagram are different. What is the purpose of this field? Consider the need for sharding: When a datagram needs to be sharded, it means that a datagram needs to be split into multiple for sending, and each split datagram will have its own IP header, of course, there is an ID field, and their ID fields are the same as the original value (the number produced by the IP counter). The advantage is that, the split data shards with the same identification fields are reloaded to the original data at the destination. This will be well understood through subsequent practices.

             

            • Flag

              Only the minimum two (DF bit and MF bit) make sense, and Reserved has no practical significance. The data packet we captured above is obviously not sharded. Because it is relatively small, observe the Flags value, which is 0x02 (expressed in hexadecimal format, and the binary value is 10 ), this is because the MF bit is 0 (MF = 1 indicates that there are still fragments behind it, and MF = 0 indicates that this is the last of several datagram slices. Obviously, there is only one datagram because there is no sharding, therefore, the MF bit must be 0), while the DF bit is 1 (DF = 0 indicates the part), so the Flags value is 10.

               

              • Slice offset

                Takes 13 places. Here, we directly explain in the book "Computer Network". The Piece Offset points out that after a long group is split, a piece is in the relative position of the original group, that is, relative to the start point of the user data field, where does the film start. The part offset is in 8 bytes. That is to say, the length of each part must be an integer multiple of 8 bytes (64-bit.

                A classic example: Before practice, I have to say that in Xie xiiren's "Computer Network", P128 has a very classic example of data sharding. Although this is only given in the form of exercises, however, if you can take a look at this example before practical analysis, we believe that we will have a relatively clear understanding of the principles of sharding.

                OK. Based on the above basics, we will implement data sharding practices.

                Run the following command on Linux:

                xpleaf@leaf:~$ping192.168.1.2-s3800PING192.168.1.2(192.168.1.2)3800(3828)bytesofdata.3808bytesfrom192.168.1.2:icmp_seq=1ttl=64time=18.0ms^C---192.168.1.2pingstatistics---1packetstransmitted,1received,0%packetloss,time0msrttmin/avg/max/mdev=18.000/18.000/18.000/0.000ms

                Here, we specify the size of the sent data to 3800 bytes, plus 8 bytes of the ICMP header. In fact, the size of the Data Part sent from ICMP to the IP address is 3808 bytes (very important, you must first make it clear). In this way, you must perform the sharding. Based on the MTU = 1500 bytes, the number of shards should be 3.

                We can observe the captured data packets on Wireshark as follows:

                We can see that three packets are actually sent. After analyzing each data partition, we can predict the value of the total length field of the IP header in each partition:

                • 1st data shards: the total length should be 1500 bytes (MTU limit, Ethernet here), because 3800 can be at least two 1500 bytes, because the IP header itself has 20 bytes, therefore, the data sent from the top layer to the IP address should be 1480 bytes in length (precisely, it should be the data obtained from the split)

                  2nd data shards: the total length should be 1500 bytes (MTU limit, Ethernet here), because 3800 can be at least two 1500 bytes, because the IP header itself has 20 bytes, therefore, the data sent from the top layer to the IP address should be 1480 bytes in length (precisely, it should be the data obtained from the split)

                  3rd data shards: the total length should be 868 bytes, because after two 1480 bytes are subtracted, the ICMP data contains 848 bytes, because the IP header itself has 20 bytes, therefore, the total length is 848 bytes + 20 bytes = 868 bytes.

                  So is it true? Yes. Believe that our theory is correct! You can view the values of the total length fields in the three data shards respectively:

                  A. Part 1

                  B. Part 2

                  C. Part 3

                  We can see that this is exactly the same as our predictions! So there is no doubt that although there may be some differences between theory and practice, the current implementation of computer network communication is not based on the analysis of these theories, is it possible to implement? So the theory is also very important!

                  We have discussed the relationship between the total length and size after the split. The following describes the relationship and meaning between the three fields: ID, flag, and offset, we provide the data packet information for the three fields of the above three shards, and perform comparative analysis as follows:

                  Parts	Comparative Analysis
                  Part 1	Identifier Obviously, the identifiers of the three shards are the same, all of which are 0x9654, because they all come from the same data packet (before this data packet is not split) Flag The content of the 1st and 2nd shards is the same, that is, the Flags value is 0x01, because there are still parts of the datagram after them, that is, they are not the last data parts; for 3rd data shards, because it is already the last data Shard, we can see that its Flags value is 0x00. Slice offset For 1st parts, because it is the beginning, the part offset must be 0; for 2nd parts, because the ICMP data in the 1st shards is 1480 bytes (the reason has been analyzed previously), the slice offset of the second slice is 1480. Why not 1481? Because it starts from 0, that is, the offset of the first part starts from 0, not from 1. Similarly, the offset of the third part is 1480 + 1480 = 2960, which is easy to understand.
                  Part 2
                  Part 3

                  OK. In this way, the most difficult part of the IP protocol is handled. Yes, can I make the IP protocol clearer, it is important to check whether your understanding of data sharding is in place.

                  (3) survival time, protocol, head check, source address, and target address

                  For the purpose of not doing too many repetitive and meaningless things, we may wish to analyze the package we caught for the first time directly, as shown below:

                  The analysis is as follows:

                  1. Survival time

                     Used as TTL, which indicates the number of hops that data packets can pass during network transmission. It is undeniable that a data packet may be transmitted endlessly in the network, but the destination still cannot be found. This exists absolutely, and the routing loop is one of them. In this case, it would be a waste of time to keep this data packet continuously transmitted. In this case, you can add a TTL field to the IP header and set the initial value. The TTL value is reduced by 1 for each hop router, if the value of TTL is 0 and the destination is not found, the data packet will not be forwarded, that is, the data packet will be discarded. This will solve the problem mentioned above. In addition to this function, this field also plays a very important role, which is used for Route tracing. The tracert or traceroute command we often use is to use the TTL principle, if you are interested, you may wish to study it on your own.

                     Protocol

                     • Indicates the protocol used for the data carried by the datagram, that is, the IP layer should reload the data (if there is a shard) which process is handed over for processing (in fact, the so-called ICMP is actually to start a process, the communication in the computer network is essentially the communication between the process and the process ). For example, if the above Protocol field is 1, it indicates that the IP layer should hand over the ICMP process for processing after processing the data (removing the IP header, which is the data encapsulation process. Common protocol fields are as follows:

                       Protocol name	ICMP	IGMP	IP	TCP	EGP	IGP	UDP	IPv6	ESP
                       Protocol Field Value	1	2	4	6	8	9	17	41	50

                       The figure is as follows:

                       In addition, if you are confused about the IP protocol in the protocol name, we recommend you have time to study the IPSec VPN Principle, IPSec VPN is a tunneling technology that encapsulates private IP addresses by using public IP addresses to implement LAN communication between private networks across public networks.

                       In fact, the so-called protocol fields are not only included in the IP protocol. If you have checked the frame or data segment of the data link layer, you will find a similar field, we call this phenomenon data sharing, and we believe that our friends who have studied data encapsulation and encapsulation will be clear.

                     • Header Inspection

                       This field only checks the first part of the data packet, but does not include the data part. This is done to reduce the workload of the computing test and accelerate the speed of data packet forwarding. It should be noted that this test is only a simple test. It is not as complicated as the CRC check code used in the data link layer. For details about the calculation method, refer to Xie xiiren's "Computer Network" P130, I will not mention it here.

                        

                       • Source IP Address

                         32 bits. It is mentioned that the source IP address remains unchanged during data forwarding.

                         • Destination IP address

                           32 bits. It is mentioned that the destination IP address remains unchanged during data forwarding.

                           OK. All the fields are analyzed.

                           4. What to do next

                           In fact, the understanding of the IP Protocol cannot be simply understanding it, even if you understand the IP protocol, that is, the TCP/IP protocol stack is an integral whole that cannot be separated, when learning and analyzing network protocols, you must be aware of the concept that no protocol exists independently.

                           If you are interested, you may wish to analyze in detail a complete data forwarding process, which is actually a complete process of data encapsulation and encapsulation. If you are competent, practice the above content! If you really understand it, I believe that you don't need the environment above, and you can make exactly the same effect as me.