The above is an example of an IP Header. Rows 1 through 5 are commonly used, and when options are included in the header, then rows 1 through 6 or more depending upon how many 32-bit option words are used by special options. The payload contained is the encapsulated data from the upper layer. (For example, a TCP, or UDP packet from the Transport Layer may be coming down to the Network Layer to be included in an outgoing IP address.)

Version [Ver] (4 bits): This specifies what version of Internet Protocol is being used. Presently (1999), almost every standard implementation of IP uses version 4 of IP, otherwise called IPV4. There is a newer standard being developed/used by a few groups, but not widely in use, called IPV6. IPV6 has many advantages over IPV4, but are beyond the scope of this on-line document at present.
Header Length [HL] (4 bits): The header length is used to tell the machines which is decoding the IP packet where the IP header is supposed to end. This is very important, since, the header's end dictates the beginning of the payload or data. Each incremental value here refers to a 32-bit word. A decimal value of "5" here would be "0101" in binary and would refer to an IP packet that had only the first 5 rows (shown at the top of this document) used, and the 6th row would be where the data portion started.
Type Of Service [TOS] (8 bits): is used for special IP packet information which may be examined by routers passing along the packet, or by the interface receiving the packet. Originally, there were 3 initial bits that had a use, but I have not been able to locate their original use. The the 4th bit was set to "0" and the remaining 4 bits are still available for use today.
- Minimize delay for this packet
- Maximize throughput for this packet
- Maximize reliability for this packet
- Minimize monetary costs
Many Application Layer protocols often have recommended values for each of these based on the kind of service they are using. For example, NNTP (Net News Transfer Protocol) used for USENET posts and group synchronization sometimes between servers, and sometimes to a client from a server is not very time critical. If it takes a night to transfer the huge collection of data, so be it. It is not very time sensitive, so often the "minimize monetary costs" bit is set for a server synchronizing itself with another server. It is up to the router to determine the paths which are the cheapest and then route appropriately a packet based on the flags that are set. If a router has only two routes (one to and from the Internet, and the other to and from a Local Area Network (LAN)) then these 4 bits are often ignored since there are not multiple routes to a destination. Where these bits become useful are in cases where a router may have 4 routes to a distant network, but each route uses a media that has certain costs, bandwidth, reliability, or latency. One may be a cheap modem that uses an analog line but is slow, has heavy latency, and low throughput but is cheap. Another may be a wireless satellite system that bounces a signal which has heavy latency, but offers huge throughput, and moderate monetary cost, but an unreliable media. A third might be a LAN line OC-24 from the phone company using SONET at 622Mbps which has good reliability, heavy available throughput, small delay, but a HUGE cost. A fourth link might be through a VPN created through the Internet that offers large throughput, low cost, moderate reliability, but huge delay. With each of these links up at the router, an incoming packet may be routed through any of these paths. A properly configured router may be able to take advantage of how these bits are set in a packet by the sending computer.
Total Length [TL] (16 bits): This specifies the total length of the IP packet in 8 bit bytes. By subtracting the Header Length from the Total Length, you may determine how many bytes long the data portion of an IP packet should be. Since this is a 16 bit value, valid ranges (accounting for minimum size of IP header) could be from 20 to 65535 bytes. An IP packet with a length of only 20 bytes is unlikely however, since it assume no payload or data. Though this might happen if some things were broken, it is not normal procedure. usually a data payload includes an ICMP, TCP, or UDP packet. Very large IP packets are also uncommon, since they must be fragmented on some networks. Say for instance an IP packet of 3000 bytes passes from a specialized ATM network through a router to an Ethernet network. The Ethernet Frames max out at around 1500 bytes. The router with the incoming ATM based IP packet may need to fragment the IP packet on purpose so that the IP packet may be passed onto the EtherNet network and its intended to its recipient.
Identification [ID] (16 bits): This is used to distinguish on sent IP packet from another by having each sent IP packet use a value for an ID that is 1 higher than the previous IP packet sent.
Flags (3 bits):
Fragmentation Offset [FO] (13 bits):
Time To Live [TTL] (8 bits): This is a value that allows for a packet to limit the number of router through which a packet may travel before reaching its destination. The idea here is to help prevent an IP packet caught in a routing loop to continue to loop for ever. As the IP packet passes through each router, each router decrements this TTL by 1. Once TTL drops to zero it is discarded either by the server that has decremented it or the next server that receives it.
Protocol (8 bits): This is used to allow for the Networking layer to know what kind of Transport layer protocol is in the data segment of the IP packet.
- 1 = ICMP
- 2 = IGMP
- 6 = TCP
- 17= UDP
- (as a few examples)
Header Checksum (16 bits): This is used to create a checksum of the header data and store that checksum here. This allows a packet to offer verification data to ensure that IP header is valid. There is risk that a header checksum could be mangled as well as the header in such a way so as to make the head actually compute to match the mangled head, but this is very uncommon. This allows the receiving host the throw out bad packets that do not have the header checksum matching up after calculation to the header checksum recalculated by the recipient. If an IP packet is thrown out, then it is up to the above layers to deal with the lost data. TCP can deal with occasional lost IP packets, UDP cannot. TCP will re-send the packet. UDP will just keep going on sending packets to the recipient, and assume that if reliability is needed, it will be controlled at the Application layer.
Source IP Address (32 bits): This is just the IP address of the source machine sending the data out onto the network. It is commonly represented by 4 octets of decimal value separated by decimals (periods) like 172.19.34.56 for an example.
Destination IP Address (32 bits): This is just the IP address of the destination machine to which the packet is being routed for delivery. It is commonly represented by 4 octets of decimal value separated by decimals (periods) like 172.19.34.56 for an example.
Options (Variable bits if used): Seldom ever used.
Data (Variable bits): As you might expect, this is the payload, or data portion of an IP packet. The payload may be any number of protocols. The most common are TCP, UDP, and ICMP.

This ends the brief preview of an IP packet.

Comments and/or suggestions for this?: Email me at: dugan@passwall.com
Attempts have been made to make the tables appear as they should for LYNX users by forcing a common field width for fields being used by padding them with other printable characters. This is meant to allow for LYNX users to see the tables much like the Netscape and other web browser worlds might show them. However, from personal experience, some versions of LYNX still manage to munge the tables, making them use up several pages. It seems to be a problem with how earlier versions of LYNX dealt with tables, but the problem has not been entirely isolated.
Some have asked why this collection of on-line documents is so lacking of graphic content. To them I answer: faster downloads. Many of these pages are smaller than some pictures on many commercial web sites. You do not come here to look at my pictures. You come here to read content. Also, LYNX users benefit from this, and by using ALL text, people with ADA issues are able to use speech recognition software on the text to hear the words.
A Special License: No part of this document may be used for profit without the consent of the author Michael Egan in writing. Content may be duplicated for retransmission for non-profit purposes as long as the copyright and license remain included in their entirety. The content is provided "as-is" and I take no responsibility on the content's truthfulness or consistency. Errors may exist in these documents, but acting upon these errors is left up to the reader to verify by a third party that will take responsibility for fact verification. When notified of errors or inconsistencies, attempts will be made to rectify the errors.
In plan English this is meant to do many things: This copyright is meant to exist so that others may not profit from this work as published in paper form, or by duplicating the content to place advertisements over it and generate income. It is also meant to exist to prevent people from publishing this work as their own and receiving profit from this process on research they did not perform. It is not meant to stop a professor from running off copies to use in their classes for their students. It is also not meant to stop the student from printing up copies for their own education. How depressing it would be to find your work published in book form without your permission, or compensation. Another reason for this Copyright is to limit the effect of the mistakes I have made within this document before I was able to complete it. It would be even sadder to notice my mistakes in print and criticized before I could resolve them. Eventually, after I finish this work, I may retain copyright, but eliminate the license.