6 ICMP: Internet Control Packet Agreement
6.1 Introduction ICMP is often considered an integral part of the IP layer. It transmits errors and other information you need to pay attention to. ICMP packets are typically used by IP layers or higher level protocols (TCP or UDP). Some ICMP messages return the error information to the user process. ICMP information is transmitted inside the IP datagram, as shown in 6.1.
Figure 6.1 ICMP package inside the IP diversity
The formal specification of ICMP See RFC 792 [POSTERL 1981B]. The format of the ICMP packet is shown in Figure 6.2. The first 4 bytes of all packets are the same, but the remaining other bytes are different from each other. Below we will introduce a variety of packet formats one by one. Type fields can have 15 different values to describe specific types of ICMP packets. Some ICMP messages also use the value of the code field to further describe different conditions. The inspection and fields overwrite the entire ICMP packet. The algorithm used is the same as the IP header inspection and algorithm we described in Section 3.2. ICMP inspection is required.
Figure 6.2 ICMP packet
In this chapter, we discuss the ICMP packets in this chapter and describe some of them: Address mask requests and answers, timestamp requests, and answers, and non-answer ports. We will detail the response requests used in Chapter 27 PING procedures and answers packets and ICMP packets to process IP routes.
6.2 Types of ICMP packets Various types of ICMP packets are shown in Figure 6.3, and different types of different types are determined by type fields and code fields in packets. The last two columns in the figure indicate that the ICMP packet is a query message or a erroneous message. Because it is sometimes necessary for ICMP error messages, we need to distinguish them. For example, another ICMP error message will never generate when responding to ICMP error messages. (If there is no such limit rule, we may encounter a case where another error is generated, and the error will generate an error, so there is no rescue loop.) When sending an ICMP error message, the packet always contains IP. The first 8 bytes of IP datagram generated by ICMP error messages. In this way, the module that receives ICMP error messages will associate it with a particular protocol (determined according to the protocol field in the IP Data ") and the user process (according to the TCP included in the first 8 bytes included in the IP Data) Or the TCP or UDP port number in the UDP packet is determined to be judged. We will explain the point in Section 6.5. Below, all situations will result in generating ICMP error messages: 1. ICMP error message. (However, ICMP query packets may generate ICMP error messages.) 2. The destination address is the IP datagram of the broadcast address (Figure 3.9) or a multicast address (Date Add), Figure 1.5). 3. Data reported as a link layer broadcast. 4. Not the first piece of IP fragment. (We will introduce fragmentation in Section 11.5.) 5. The source address is not a single host's datagram. That is to say, the source address cannot be zero addresses, loopback addresses, broadcast addresses, or multicast addresses.
(The following is the translation of Figure 6.3) Type code description query error 00 answer Election (ping answer, chapter 7) ·
3
The purpose is not reached:
0 Networks not arrived (9.3)
·
1 The host is not available (9.3)
·
2 protocols are not available
·
3 ports are not available (6.5)
·
4 need to perform shards but set up no slide bits (11.6)
·
5 Source Station Routing Failed (8.5)
·
6 destination network does not know
·
7 destination hosts don't know
·
8 source host is isolated (not used)
·
9 destination network is forced to prohibit
·
10 destination hosts are forced to ban ·
11 Because the service type TOS network is not reached (9.3)
·
12 Due to the service type TOS host is not available (9.3)
·
13 Because of filtering communication is forced to prohibit
·
14 hosting Yue
·
15 priority suspension effective
· 40 source is closed (basic stream control, 11.11)
· 5
Change the route (Section 9.5):
·
0 change route to the network
·
1 change the routing of the host
·
2 Pair of service types and network change routes
·
3 changes to service types and hosts
· 80 request returns (PING request, Chapter 7) ·
90 router announcement (9.6) ·
100 router request (9.6) ·
11
time out:
0 Survival time during transmission is 0 (Traceroute, Chapter 8)
·
1 The survival time is 0 (11.5) during the data newspaper assembly.
· 12
Parameter problem:
0 bad IP headers (including various errors)
·
1 missing required options
· 130 Time Stamp Request (6.4) ·
140 Time Poke Answer (6.4) ·
150 Information Answers (not used) ·
160 information answer (not used) ·
170 Address Mask Request (6.3) ·
180 address mask answer (6.3) ·
Figure 6.3 ICMP packet type
These rules are to prevent the inventory from allowing ICMP error messages to broadcast a broadcast storm that the broadcast packet response is allowed.
6.3 ICMP Address Mask Request and Answer ICMP Address Mask Request for diskless systems Get your own subnet mask (Section 3.5) during the boot process. The system broadcasts its ICMP request message. (This process is similar to the non-disk-free system in the boot process is similar.) Another way to obtain the subnet mask in disk is the bootp protocol, which will be introduced in Chapter 16. The format of the ICMP address mask request and answering message is shown in Figure 6.4.
Figure 6.4 ICMP address mask request and answering message
The identifier and serial number field in the ICMP packet are set by the sender, which will be returned in the answer. In this way, the sender can match the answer to the request. We can write a simple program (name ICMPADDRMASK), which sends a ICMP address mask request message and then prints all answered. Since it is generally sent to the broadcast address, here we do this. The destination address (140.252.13.63) is a broadcast address of the subnet 140.252.13.32 (Figure 3.12).
Sun% icmpaddrmask 140.252.13.33Received Mask = fffffe0, from 140.252.13.33 from this machine Received Mask = fffffe0, from 140.252.13.35 From BSDIRECEIVED MASK = fff0000, from 140.252.13.34 From SVR4
In the output we first noticed that the subnet mask returned from SVR4 is an error. Obviously, although the SVR4 interface has set the correct subnet mask, SVR4 returns a normal B address mask, as if the subnet does not exist.
SVR4% ifconfig EMD0EMD0: Flags = 23inet 140.252.13.34 Netmask fffffe0 Broadcast 140.252.13.63
The SVR4 processes an error in the ICMP address mask request process. We use the tcpdump command to view the situation on the host BSDI, and the output is shown in Figure 6.5. We use the -e parameter to view the hardware address. Figure 6.5 ICMP address mask request sent to broadcast address
Note that although what is not seen on the line, sending host Sun can also receive ICMP answered (output rows with from ouself). This is the general feature of broadcasting: sending hosts can also receive a broadcast document copy through some internal loopback mechanism. Since the term "broadcast" definition is to refer to all hosts on the local area, it must include a sending host. (See Figure 2.4, when the Ethernet driver identifies the destination address is a broadcast address, it sent the packet to the network, simultaneously passing a copy to the ring back interface.) Next, BSDI broadcast answers, and SVR4 is only Pass the answer to the requesting host. Typically, the answer address must be unicast addresses unless the source IP address of the requested end is 0.0.0.0, this example does not belong to this. Therefore, the reply is sent to the broadcast address is an internal error in the BSD / 386.
(Below is the translation of the original book P.731) RFC specifies that it cannot send an address mask answer unless the system is an authorized agent of the address mask, otherwise it cannot send an address mask answer. (In order to be a licensing agent, it must be special configured to send these answex. See Appendix E.) However, as we see from this example, most hosts send an answer when receiving the request, and even Some hosts also send an error to answer.
The last point can be explained by the following example. We send an address mask request to this machine IP address and loopback address, respectively:
Sun% icmpaddrmask sunreceived mask = ff000000, from 140.252.13.33
Sun% icmpaddrmask localhostreceived mask = ff000000, from 127.0.0.1
The address mask returned in both cases is a loopback address, that is, a class A address 127.0.0.1. Also, we can see from Figure 2.4 that the datagram (140.252.12.33) sent to the native IP address is actually sent to the loopback interface. The ICMP address mask answer must be a subnet mask for receiving the request interface (this is because each interface of the multi-interface host has a different subnet mask), so the address mask reception is from the loopback. interface.
6.4 ICMP Timestamp Request and Answer ICMP Timestamp Request Allows the system to query the current time to another system. The returned suggested value is the number of milliseconds that start calculated from midnight, coordinated universal time, UTC. (Early reference manuals believe that UTC is GMN.) The benefit of this ICMP packet is that it provides a resolution of milliseconds, and uses other methods from other hosts (such as RDATE commands provided by some UNIX systems) ) Can only provide the resolution of seconds. Since the return time is calculated from midnight, the caller must know the date at the time through other methods, which is a defect. The ICMP timestamp request and replied message format is shown in Figure 6.6.
Figure 6.6 ICMP timestamp request and answer message
The request end fills in the initiatory timestamp and then send a message. The answer system fills in the reception timestamp when you receive the request message, and fill in the send timestamp when sending answered. However, in fact, most implementations set the following two fields into the same value. (The reason for providing three fields is to allow the sender to calculate the time and time of sending a request, respectively.)
Example We can write a simple program (name icmptime), send an ICMP timestamp request for a host, and print the returned answer. It runs in our small interconnect online results as follows: (See the original book P.74 1)
The program prints three timestamps in ICMP packets: launch timestamp, receive timestamp (RECV), and send timestamps (XMIT). As we saw in this example and the following example, all hosts set the receiving timestamp and send timestamp to the same value. We can also calculate the round trip time (RTT), which is the time value when the answer is received, and the time value is time value when sending the request. The value of DIFCERENCE is that the receiving timestamp value subtracts the initiation timestamp value. The relationship between these values is shown in Figure 6 7. If we believe in the value of RTT and believe half of the RTT is used to request the transmission of the message, the other half is used to answer the transfer of the message, so in order to make the native clock with the clock of the query host, the native clock needs to be adjusted. The adjustment value is half of the Difference minus RTT. In the previous example, BSDI's clock is slower 7 ms and 8 ms than Sun's clock. Since the value of the timestamp is calculated in milliseconds in midnight, that is, UTC, therefore, their value is always less than 86,400,000 (24 × 60 × 60 × 1000). These examples are running prior to 4:00 pm and at a time zone than UTC, so their value is much more reasonable than 82,800,000 (2300 hours). If we repeat the program several times to host BSDI, we found that the last digit of the timestamp and the transmission timestamp is always 0. This is because the version of the software (version 0.9.4) can only provide a time resolution of 10 milliseconds. (See Appendix B.) If we run the program twice to host SVR4, we found that the last three digits of the SVR4 timestamp are always 0:
(See the original book P.75 1)
For some reason, SVR4 does not provide millisecond-level resolution in the ICMP timestamp. In this way, the time difference adjustment below the second will not work. If we run the program for other hosts on the subnet 140.252.1, the result indicates that the clock of one of the hosts is divided with Sun 3. The other host clock is nearly 75 seconds:
(See the original book P.75 2)
Another interested example is the router Gateway (a Cisco router). This shows that when the system returns a non-standard timestamp value (not the number of milliseconds calculated from midnight, it is expressed in the high position in the 32 BIT timestamp. Our procedure proves that the timestamp value of reception and transmission is printed in angle brackets (after turning off the high position). In addition, we cannot calculate the time difference between the initiation timestamp and the reception timestamp, because their unit is inconsistent.
(See the original book P.76 1)
If we run the program several times on this host, it will find that the timestamp value obviously has the resolution of milliseconds, and the number of milliseconds calculated from a start point, but the starting point is not midnight UTC. (For example, it may be a number of milliseconds that start counting from the router.) As the last example, let's compare the Sun host and another known to the exact system clock - a NTP Stratum 1 server. (We will discuss NTP, network time agreement more.)
(See the original book P.76 2)
If we minimize the value of Difference's value, the result indicates that the clock on the Sun host is 3.8.5 to 51.5 ms. Another method can also use another method to obtain time and date. 1. We describe the datetime service programs and time service programs in 1.12. The former returns the current time and date with people readable format, is a line ASCII character. We can use the Telnet command to verify this service:
(See the original book P.76 3)
On the other hand, the time service program returns a 32-Bit two-to-numerical value indicating that from UTC, the number of seconds at midnight on January 1, 1900. This program is the date and time provided in seconds. (The RDATE command we have ever mentioned in front uses the TCP Time Server.) 2. Strict Timer Using Network Time Protocol (NTP), the protocol gives a description in RFC 1305 [MILLS 1992]. This protocol uses advanced techniques to ensure that the clock error of a set of systems on the LAN or WAN is within milliseconds. Readers who are interested in computers should read this RFC document. 3. Open Software Foundation (OSF) Distributed Calculation Environment (DCE) Defines Distributed Time Services (DTS), which also provides clock synchronization between computers. Document [Rosenberg, Kenney and Fisher 1992] provides other details descriptions of the service. 4. Berkeley University's UNIX system provides daemon TIMED (8) to synchronize system clocks on the LAN. Unlike NTP and DTS, TIMED is not working within the wide area network.
6.5 ICMP ports are unreachable in the last two sections. Let's discuss ICMP query packets ---- address mask and timestamp query and answer. We now analyze an ICMP error message, that is, the port is not reachable message. It is one of the ICMP purposes that cannot be reached in the message. Take a look at the information attached in the ICMP error message. We use UDP (see Chapter 11) to view it. One of the rules of UDP is that if you receive a UDP datagram, the destination port does not match some of the process, then UDP returns an ICMP to not arrive. We can use TFTP to enforce generation of ports that cannot be reached. (TFTP will be described in Chapter 15.) For TFTP servers, UDP's common port number is 69. But most TFTP client allows us to specify a different port number with the connect command. Here, we use it for it to 8888:
(See the original book P.77 1)
The connect command first specifies the host name and its port number to connect, and then use the GET command to take the file. After taking the Get command, a UDP datagram is sent to the 8888 port on the host SVR4. The packet exchange results caused by the tcpdump command are shown in Figure 6.8. Before UDP data is sent to SVR4, you must first send an ARP request to determine its hardware address (line 1). Then return ARP answer (line 2), and then send UDP datagram (line 3). (We keep the ARP request and answer in tcpdump's output is to remind us that these packets may be necessary before the first IP datagram is sent from another host sent by a host. In the chapter after this book If these messages are not related to the discussion topics, then we will omit them.)
Figure 6.8 ICMP port generated by TFTP does not reach an error
An ICMP port is not reachable, and it is immediately returned (line 4). However, the TFTP client seems to have ignored this ICMP message, and another UDP datagram is sent after 5 seconds (line 5). I have retired three times before giving up. Note that the ICMP packet is exchanged between the host without having to use the destination port number, and each 20-byte UDP data report is sent from one specific port (2924) to another (8888). The number 20 followed by each UDP refers to the data length in the UDP datagram. In this example, 20 bytes include two bytes of TFTP, 9 bytes end name Temp.foo, and 9 bytes ending with 9 bytes Netascii. (For detailed format of TFTP packets, see Figure 15.1.) If you run the same example with the -e parameter, we can see that each returned ICMP port does not reach the full length of the message. The length here is 70 bytes, and each field assignment is shown in Figure 6.9. Figure 6.9 "UDP ports are not reachable" examples of ICMP messages
One rule of ICMP is that ICMP error packets (see Figure 6.3) must include generating the datagram ip header (including any options) generated, but must also include at least eight of the top 8 behind the IP header. byte. In our example, the first 8 bytes behind the IP head contain UDP's head (Figure 11.2). An important fact is included in the UDP header is the source port number and destination port number. It is because the destination port number (8888) has led to an error message that is not available to the ICMP port. A system that receives ICMP can be associated with a particular user process based on the source port number (2924) (in this example). The reason for the IP header in the datagram in the error is to be returned because the IP header contains the protocol field, so that ICMP can know how to explain 8 bytes behind (in this example is the UDP header). If we come to view the TCP header (Figure 17.2), you can find that the source port and destination port are included in the first 8 bytes of the TCP header. The general format of ICMP is not reachable message is shown in Figure 6.10.
Figure 6.10 ICMP does not reach a message
In Figure 6.3, we noticed that there are 16 different types of ICMPs that cannot be reached, and the code from 0 to 15 respectively. ICMP ports are not reachable or error code is 3. In addition, although FIG. 6.10 indicates that the second 32 bit word in the ICMP packet must be 0, but when the code is 4 ("requires a fragment but set up no slide bits"), the path MTU discovery mechanism (2.9 The section is allowed to fill in the MTU of the outgoing interface to the low 16 bit of this 32 bit word. We give an example of such an error in Section 11.6.
(Below is the original book P.791) Although the ICMP rule allows the system to return data in an error-generated IP datagram in 8 bytes, most of the systems derived from Berkeley returns 8 bytes. Solaris 2.2 IP_ICMP_RETURN_DATA_BYTES Options Returns the first 64 bytes (E.4) under default.
TCPDump Time Series In the later chapter of this book, we also give the output of the TCPDump command in the format of the time series, as shown in Figure 6.11.
Figure 6.11 Time series of TFTP requests sent to invalid ports
Time increases down, the time tag of the graph is the same as the output of the TCPDUMP command (Figure 6.8). The tag located on the top is the host name and port number of the communication between the communication. It should be pointed out that as the Y coordinate axis and the true time value downward are not proportional. When a meaningful period of time occurs, in this case, we will mark the two sides of the time series. When UDP or TCP data is being transmitted, we use the thick line of line. When ICMP packet returns, why do the TFTP client also continue to retransmit requests? This is due to one factor in network programming, that is, the BSD system notifies the user process without the UDP data in the ICMP packets received from the socket, unless the process has sent a connect command to the socket. Standard BSD TFTP client does not send a connect command, so it will never receive a notification of ICMP error messages. Another point you need to pay attention to is the uncommon timeout re-generating algorithm used by the TFTP client. It only assumes that 5 seconds are sufficient, so retransmit once every 5, and a total of 25 seconds will take a total of 25 seconds. Behind we will see that TCP has a better timeout resection algorithm. (The following is a translation of the original book P.81) The timeout retransbital algorithm used by the TFTP client has been disabled by the RFC. However, three systems on the author's online and Solaris 2.2 are still using it. AIX 3.2.2 uses an exponential retraction method to set the timeout value, resend packets at 0, 5, 15 and 35 seconds, which is the recommended method. We will discuss timeout problems in more detail on Chapter 21. Finally, it is necessary to point out that ICMP packets are returned after sending UDP datagrams 3.5 ms, which is similar to the round-trip time of the PING Answer we have seen in Chapter 7.
6.6 ICMP packet 4.4BSD Processing Since the range of ICMP coverage is wide, from fatal errors to information error, even in a given system implementation, the processing of each ICMP packet is different. The content of Figure 6.12 is the same as Figure 6.3, which shows a processing method for each possible ICMP packet for a 4.4BSD system. If the last column is indicated by "kernel", ICMP is handled by the core. If the last column is indicated as the "User Process", the message is transmitted to all user processes registered in the kernel to read the received ICMP packets. If there is no such user process, then the message is quietly discarded. (These user processes will also receive a copy of all other types of ICMP packets, although they should be processed by the kernel, of course, the user process can only receive these packets after kernel processing.) Some packets are completely ignored. Finally, if the last column indicates a string of characters in quotation, it is the corresponding UNIX error. Some of these errors, such as TCP to handle the sending end, etc., we will discuss them in later chapters.
(The following is the translation of Figure 6.12) Type code description processing method 00 echo answers user process 3
The purpose is not reached:
0 Networks can not reach "No routed reachable host"
1 The host is not available to "no way to reach the host"
2 The protocol cannot be reached "Connection is rejected"
3 ports are not reachant "connection is rejected"
4 Need to piece slice but set up the slide bits DF "packet too long"
5 Source Station Routing Selection Failure "No routed reaches the host"
6 destination network does not know "no route arrival host"
7 destination host does not know "no route reach the host"
8 Source hosts are isolated (notified) "No way to reach the host"
9 destination network is forced to "no route reach host"
10 destination hosts are forced to "no route reach host"
11 Because the service type TOS network is not available "No routed reaches the host"
12 Because the service type TOS host is not available to "no route arrival host"
13 Because of filtering communication is forced (ignoring)
14 hosting (ignore)
15 Priority Substation Effect - (ignore) 40 Source Station is suppressed (quench) TCP is handled by kernel, and UDP ignores 5 change routes.
0 Change the routing kernel update routing table
1 Change the routing kernel update routing table for the host
2 Type of service type and network change routing kernel update routing table
3 Types of service type and host change routing kernel update routing table 80 echo request
90 router advertisement user process 100 router request user process 11
time out:
0 Survival time during transmission is 0 user processes
1 During the data newspaper assembly, the survival time is 0 user process 12
Parameter problem:
0 bad IP headers (including various errors) "agreements are not available"
1 Missing option "protocol" 130 timestamp request kernel generation answer 140 time stamp answers user process 150 information request (ignore) 160 information answer (notified) User Process 170 address mask request kernel generation answer 180 Address Mask Answer User Process Figure 6.12 4.4BSD System Handling ICMP Packet
6.7 Summary This chapter discusses the Internet Control Packet Agreement that must be included in each system. Figure 6.3 lists all ICMP packet types, most of which we will discuss in later chapters. We discussed in detail the ICMP address mask request and answer and the timestamp request and answer. These are typical requests - answer messages. Both are identifiers and serial numbers in ICMP packets. The sender application stores a unique value within the identification field to distinguish between other processes. The serial number field allows the client program to match between answers and requests. We also discussed the ICMP ports that do not reach an error, a common ICMP error. We analyzed the return ICMP error information: 8 bytes of the first and sequencing of the IP datagram of errors. This information is necessary for ICMP error reception, which can more understand the cause of errors. This is because TCP and UDP are stored in the source port number and destination port number in the first 8 bytes of their head. Finally, we first gave the TCPDUMP output in time, and the output of this manifestation will be used in the chapter behind this book.
Exercise 6.1 At the end of 6.2, we list five special conditions that do not send ICMP error messages. If these conditions do not satisfy and we send a broadcast UDP datag report to an existing port number on the LAN, what happens? 6.2 Read RFC [BRADEN 1989A], pay attention to generating an ICMP port that does not reach the error is "must", "should" or "possible". What is the page and chapter of this information? 6.3 Read RFC 1349 [Almquist 1992] See how IP's service type field (Figure 3.2) is set by ICMP? 6.4 If your system provides the netstat command, use it to view the type of ICMP packets received and sent.
6-9
