<BR>

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

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Identification</B></FONT></CENTER></H5>

<BR>

<P>This field holds a number that is a unique identifier created by the sending node. This number is required when reassembling fragmented messages, ensuring that the fragments of one message are not intermixed with others. Each chunk of data received by the IP layer from a higher protocol layer is assigned one of these identification numbers when the data arrives. If a datagram is fragmented, each fragment has the same identification number.

<BR>

<BR>

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

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Flags</B></FONT></CENTER></H5>

<BR>

<P>The Flags field is a 3-bit field, the first bit of which is left unused (it is ignored by the protocol and usually has no value written to it). The remaining two bits are dedicated to flags called DF (Don't Fragment) and MF (More Fragments), which control the handling of the datagrams when fragmentation is desirable.

<BR>

<P>If the DF flag is set to 1, the datagram cannot be fragmented under any circumstances. If the current IP layer software cannot send the datagram on to another machine without fragmenting it, and this bit is set to 1, the datagram is discarded and an error message is sent back to the sending device.

<BR>

<P>If the MF flag is set to 1, the current datagram is followed by more packets (sometimes called <I>subpackets</I>), which must be reassembled to re-create the full message. The last fragment that is sent as part of a larger message has its MF flag set to 0 (off) so that the receiving device knows when to stop waiting for datagrams. Because the order of the fragments' arrival might not correspond to the order in which they were sent, the MF flag is used in conjunction with the Fragment Offset field (the next field in the IP header) to indicate to the receiving machine the full extent of the message.

<BR>

<BR>

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

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Fragment Offset</B></FONT></CENTER></H5>

<BR>

<P>If the MF (More Fragments) flag bit is set to 1 (indicating fragmentation of a larger datagram), the fragment offset contains the position in the complete message of the submessage contained within the current datagram. This enables IP to reassemble fragmented packets in the proper order.

<BR>

<P>Offsets are always given relative to the beginning of the message. This is a 13-bit field, so offsets are calculated in units of 8 bytes, corresponding to the maximum packet length of 65,535 bytes. Using the identification number to indicate which message a receiving datagram belongs to, the IP layer on a receiving machine can then use the fragment offset to reassemble the entire message.

<BR>

<BR>

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

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Time to Live (TTL)</B></FONT></CENTER></H5>

<BR>

<P>This field gives the amount of time in seconds that a datagram can remain on the network before it is discarded. This is set by the sending node when the datagram is assembled. Usually the TTL field is set to 15 or 30 seconds.

<BR>

<P>The TCP/IP standards stipulate that the TTL field must be decreased by at least one second for each node that processes the packet, even if the processing time is less than one second. Also, when a datagram is received by a gateway, the arrival time is tagged so that if the datagram must wait to be processed, that time counts against its TTL. Hence, if a gateway is particularly overloaded and can't get to the datagram in short order, the TTL timer can expire while awaiting processing, and the datagram is abandoned.

<BR>

<P>If the TTL field reaches 0, the datagram must be discarded by the current node, but a message is sent back to the sending machine when the packet is dropped. The sending machine can then resend the datagram. The rules governing the TTL field are designed to prevent IP packets from endlessly circulating through networks.

<BR>

<BR>

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

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Transport Protocol</B></FONT></CENTER></H5>

<BR>

<P>This field holds the identification number of the transport protocol to which the packet has been handed. The numbers are defined by the Network Information Center (NIC), which governs the Internet. There are currently about 50 protocols defined and assigned a transport protocol number. The two most important protocols are ICMP (detailed in the section titled &quot;Internet Control Message Protocol (ICMP)&quot; later today), which is number 1, and TCP, which is number 6. The full list of numbers is not necessary here because most of the protocols are never encountered by users. (If you really want this information, it&#146;s in several RFCs mentioned in the apendixes.)

<BR>

<BR>

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

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Header Checksum</B></FONT></CENTER></H5>

<BR>

<P>The number in this field of the IP header is a checksum for the protocol header field (but not the data fields) to enable faster processing. Because the Time to Live (TTL) field is decremented at each node, the checksum also changes with every machine the datagram passes through. The checksum algorithm takes the ones-complement of the 16-bit sum of all 16-bit words.

<BR>

<P>This is a fast, efficient algorithm, but it misses some unusual corruption circumstances such as the loss of an entire 16-bit word that contains only 0s. However, because the data checksums used by both TCP and UDP cover the entire packet, these types of errors usually can be caught as the frame is assembled for the network transport.

<BR>

<BR>

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

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Sending Address and Destination Address</B></FONT></CENTER></H5>

<BR>

<P>These fields contain the 32-bit IP addresses of the sending and destination devices. These fields are established when the datagram is created and are not altered during the routing.

<BR>

<BR>

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

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Options</B></FONT></CENTER></H5>

<BR>

<P>The Options field is optional, composed of several codes of variable length. If more than one option is used in the datagram, the options appear consecutively in the IP header. All the options are controlled by a byte that is usually divided into three fields: a 1-bit copy flag, a 2-bit option class, and a 5-bit option number. The copy flag is used to stipulate how the option is handled when fragmentation is necessary in a gateway. When the bit is set to 0, the option should be copied to the first datagram but not subsequent ones. If the bit is set to 1, the option is copied to all the datagrams.

<BR>

<P>The option class and option number indicate the type of option and its particular value. At present, there are only two option classes set. (With only 2 bits to work with in the field, a maximum of four options could be set.) When the value is 0, the option applies to datagram or network control. A value of 2 means the option is for debugging or administration purposes. Values of 1 and 3 are unused. Currently supported values for the option class and number are given in Table 3.1.

<BR>

<BR>

<P ALIGN=CENTER>

<CENTER>

<FONT COLOR="#000080"><B>Table 3.1. Valid option class and numbers for IP headers.</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>Option Class</I></B>

</FONT>

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

<P><B><I>Option </I></B><B><I>Number</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>0

<BR>

</FONT>

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

<P>Marks the end of the options list

<BR>

</FONT>

<TR>

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

<P>0

<BR>

</FONT>

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

<P>1

<BR>

</FONT>

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

<P>No option (used for padding)

<BR>

</FONT>

<TR>

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

<P>0

<BR>

</FONT>

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

<P>2

<BR>

</FONT>

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

<P>Security options (military purposes only)

<BR>

</FONT>

<TR>

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

<P>0

<BR>

</FONT>

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

<P>3

<BR>

</FONT>

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

<P>Loose source routing

<BR>

</FONT>

<TR>

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

<P>0

<BR>

</FONT>

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

<P>7

<BR>

</FONT>

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

<P>Activates routing record (adds fields)

<BR>

</FONT>

<TR>

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

<P>0

<BR>

</FONT>

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

<P>9

<BR>

</FONT>

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

<P>Strict source routing

<BR>

</FONT>

<TR>

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

<P>2

<BR>

</FONT>

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

<P>4

<BR>

</FONT>

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

<P>Timestamping active (adds fields)</FONT>

</TABLE></CENTER><BR>

<P>Of most interest to you are options that enable the routing and timestamps to be recorded. These are used to provide a record of a datagram's passage across the internetwork, which can be useful for diagnostic purposes. Both these options add information to a list contained within the datagram. (The timestamp has an interesting format: it is expressed in milliseconds since midnight, Universal Time. Unfortunately, because most systems have widely differing time settings&#151;even when corrected to Universal Time&#151;the timestamps should be treated with more than a little suspicion.)

<BR>

<P>There are two kinds of routing indicated within the Options field: loose and strict. <I>Loose routing</I> provides a series of IP addresses that the machine must pass through, but it enables any route to be used to get to each of these addresses (usually gateways). <I>Strict routing</I> enables no deviations from the specified route. If the route can't be followed, the datagram is abandoned. Strict routing is frequently used for testing routes but rarely for transmission of user datagrams because of the higher chances of the datagram being lost or abandoned.

<BR>

<BR>

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

<H5 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Padding</B></FONT></CENTER></H5>

<BR>

<P>The content of the padding area depends on the options selected. The padding is usually used to ensure that the datagram header is a round number of bytes.