<BR>

<BR>

<A ID="E69E52" NAME="E69E52"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>A Datagram's Life</B></FONT></CENTER></H4>

<BR>

<P>To understand how IP and other TCP/IP layers work to package and send a datagram from one machine to another, I take a simplified look at a typical datagram's passage. When an application must send a datagram out on the network, it performs a few simple steps. First, it constructs the IP datagram within the legal lengths stipulated by the local IP implementation. The checksum is calculated for the data, and then the IP header is constructed. Next, the first hop (machine) of the route to the destination must be determined to route the datagram to the destination machine directly over the local network, or to a gateway if the internetwork is used. If routing is important, this information is added to the header using an option. Finally, the datagram is passed to the network for its manipulation of the datagram.

<BR>

<P>As a datagram passes along the internetwork, each gateway performs a series of tests. After the network layer has stripped off its own header, the gateway IP layer calculates the checksum and verifies the integrity of the datagram. If the checksums don't match, the datagram is discarded and an error message is returned to the sending device. Next, the TTL field is decremented and checked. If the datagram has expired, it is discarded and an error message is sent back to the sending machine. After determining the next hop of the route, either by analysis of the target address or from a specified routing instruction within the Options field of the IP header, the datagram is rebuilt with the new TTL value and new checksum.

<BR>

<P>If fragmentation is necessary because of an increase in the datagram's length or a limitation in the software, the datagram is divided, and new datagrams with the correct header information are assembled. If a routing or timestamp is required, it is added as well. Finally, the datagram is passed back to the network layer.

<BR>

<P>When the datagram is finally received at the destination device, the system performs a checksum calculation and&#151;assuming the two sums match&#151;checks to see if there are other fragments. If more datagrams are required to reassemble the entire message, the system waits, meanwhile running a timer to ensure that the datagrams arrive within a reasonable time. If all the parts of the larger message have arrived but the device can't reassemble them before the timer reaches 0, the datagram is discarded and an error message is returned to the sender. Finally, the IP header is stripped off, the original message is reconstructed if it was fragmented, and the message is passed up the layers to the upper layer application. If a reply was required, it is then generated and sent back to the sending device.

<BR>

<P>When extra information is added to the datagram for routing or timestamp recording, the length of the datagram can increase. Handling all these conditions is part of IP's forte, for which practically every problem has a resolution system.

<BR>

<BR>

<A ID="E68E29" NAME="E68E29"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>Internet Control Message Protocol (ICMP)</B></FONT></CENTER></H3>

<BR>

<P>As you have seen today and over the last two days, many problems can occur in routing a message from sender to receiver. The TTL timer might expire; fragmented datagrams might not arrive with all segments intact; a gateway might misroute a datagram, and so on. Letting the sending device know of a problem with a datagram is important, as is correctly handling error conditions within the network routing itself. The Internet Control Message Protocol (ICMP) was developed for this task.

<BR>

<P>ICMP is an error-reporting system. It is an integral part of IP and must be included in every IP implementation. This provides for consistent, understandable error messages and signals across the different versions of IP and different operating systems. It is useful to think of ICMP as one IP package designed specifically to talk to another IP package across the network: in other words, ICMP is the IP layer's communications system. Messages generated by ICMP are treated by the rest of the network as any other datagram, but they are interpreted differently by the IP layer software. ICMP messages have a header built in the same manner as any IP datagram, and ICMP datagrams are not differentiated at any point from normal data-carrying datagrams until a receiving machine's IP layer processes the datagram properly.

<BR>

<P>In almost all cases, error messages sent by ICMP are routed back to the original datagram's sending machine. This is because only the sender's and destination device's IP addresses are included in the header. Because the error doesn't mean anything to the destination device, the sender is the logical recipient of the error message. The sender can then determine from the ICMP message the type of error that occurred and establish how to best resend the failed datagram.

<BR>

<P>ICMP messages go through two encapsulations, as do all IP messages: incorporation into a regular IP datagram and then into the network frame. This is shown in Figure 3.3. ICMP headers have a different format than IP headers, though, and the format differs slightly depending on the type of message. However, all ICMP headers start with the same three fields: a message type, a code field, and a checksum for the ICMP message. Figure 3.4 shows the layout of the ICMP message.

<BR>

<P><B><A HREF="03tyt03.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/03tyt03.gif">Figure 3.3. Two-step encapsulation of an ICMP </B><B>message.</A></B>

<BR>

<P><B><A HREF="03tyt04.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/03tyt04.gif">Figure 3.4. The layout of an ICMP message.</A></B>

<BR>

<P>Usually, any ICMP message that is reporting a problem with delivery also includes the header and first 64 bits of the data field from the datagram for which the problem occurred. Including the 64 bits of the original datagram accomplishes two things. First, it enables the sending device to match the datagram fragment to the original datagram by comparison. Also, because most of the protocols involved are defined at the start of the datagram, the inclusion of the original datagram fragment allows for some diagnostics to be performed by the machine receiving the ICMP message.

<BR>

<P>The 8-bit Message Type field in the ICMP header (shown in Figure 3.4) can have one of the values shown in Table 3.2.

<BR>

<BR>

<P ALIGN=CENTER>

<CENTER>

<FONT COLOR="#000080"><B>Table 3.2. Valid values for the ICMP Message Type field.</B></FONT></CENTER>

<BR>

<BR>

<CENTER><TABLE  BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 CELLPADDING=3 >

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P><B><I>Value</I></B>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P><B><I>Description</I></B>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>0

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Echo Reply

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>3

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Destination Not Reachable

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>4

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Source Quench

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>5

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Redirection Required

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>8

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Echo Request

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>11

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Time to Live Exceeded

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>12

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Parameter Problem

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>13

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Timestamp Request

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>14

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Timestamp Reply

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>15

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Information Request (now obsolete)

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>16

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Information Reply (now obsolete)

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>17

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Address Mask Request

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>18

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Address Mask Reply</FONT>

</TABLE></CENTER><BR>

<P>The Code field expands on the message type, providing a little more information for the receiving machine. The checksum in the ICMP header is calculated in the same manner as the normal IP header checksum.

<BR>

<P>The layout of the ICMP message is slightly different for each type of message. Figure 3.5 shows the layouts of each type of ICMP message header. The Destination Unreachable and Time Exceeded messages are self-explanatory, although they are used in other circumstances, too, such as when a datagram must be fragmented but the Don't Fragment flag is set. This results in a Destination Unreachable message being returned to the sending machine.

<BR>

<P><B><A HREF="03tyt05.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/03tyt05.gif">Figure 3.5. ICMP message header layouts.</A></B>

<BR>

<P>The Source Quench ICMP message is used to control the rate at which datagrams are transmitted, although this is a very rudimentary form of flow control. When a device receives a Source Quench message, it should reduce the transmittal rate over the network until the Source Quench messages cease. The messages are typically generated by a gateway or host that either has a full receiving buffer or has slowed processing of incoming datagrams because of other factors. If the buffer is full, the device is supposed to issue a Source Quench message for each datagram that is discarded. Some implementations issue Source Quench messages when the buffer exceeds a certain percentage to slow down reception of new datagrams and enable the device to clear the buffer.

<BR>

<P>Redirection messages are sent to a gateway in the path when a better route is available. For example, if a gateway has just received a datagram from another gateway but on checking its datafiles finds a better route, it sends the Redirection message back to that gateway with the IP address of the better route. When a Redirection message is sent, an integer is placed in the code field of the header to indicate the conditions for which the rerouting applies. A value of 0 means that datagrams for any device on the destination network should be redirected. A value of 1 indicates that only datagrams for the specific device should be rerouted. A value of 2 implies that only datagrams for the network with the same type of service (read from one of the IP header fields) should be rerouted. Finally, a value of 3 reroutes only for the same host with the same type of service.

<BR>

<P>The Parameter Problem message is used whenever a semantic or syntactic error has been encountered in the IP header. This can happen when options are used with incorrect arguments. When a Parameter Problem message is sent back to the sending device, the Parameter field in the ICMP error message contains a pointer to the byte in the IP header that caused the problem. (See Figure 3.5.)

<BR>

<P>Echo request or reply messages are commonly used for debugging purposes. When a request is sent, a device or gateway down the path sends a reply back to the specified device. These request/reply pairs are useful for identifying routing problems, failed gateways, or network cabling problems. The simple act of processing an ICMP message also acts as a check of the network, because each gateway or device along the path must correctly decode the headers and then pass the datagram along. Any failure along the way could be with the implementation of the IP software. A commonly used request/reply system is the ping command. The ping command sends a series of requests and waits for replies.

<BR>

<P>Timestamp requests and replies enable the timing of message passing along the network to be monitored. When combined with strict routing, this can be useful in identifying bottlenecks. Address mask requests and replies are used for testing within a specific network or subnetwork.

<BR>

<BR>

<A ID="E68E30" NAME="E68E30"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>IPng: IP Version 6</B></FONT></CENTER></H3>

<BR>

<P>When IP version 4 (the current release) was developed, the use of a 32-bit IP address seemed more than enough to handle the projected use of the Internet. With the incredible growth rate of the Internet over the last few years, however, the 32-bit IP address might become a problem. To counter this limit, IP Next Generation, usually called IP version 6 (IPv6), is under development.

<BR>

<P>Several proposals for IPng implementation are currently being studied, the most popular of which are TUBA (TCP and UDP with Bigger Addresses), CATNIP (Common Architecture for the Internet), and SIPP (Simple Internet Protocol Plus). None of the three meet all the proposed changes for version 6, but a compromise or modification based on one of these proposals is likely.

<BR>