IP HEADER

IP transmits and receives datagrams. Within the datagram is a header and the data portion of the datagram. The minimum size of the IP header is 20 bytes consisting of five 32-bit words. The first three words provide control information while the remaining two words provide address information. An optional field can follow the address information. The information in the header is as follows:

Version: A four-bit field identifies the IP version. A 4 identifies IPv4 while a 6 identifies IPv6.

Header Length: A four-bit field indicates how many four-byte words are in the header. The header length cannot exceed 60 bytes thereby allowing 40 bytes for options.

Type of Service: Of the eight-bit field only six bits are used. The Delay bit indicates the datagram should be processed with low delay by the router. The Throughput bit requests high throughput while the Reliability bit requests high reliability. There are three other bits to indicate precedence. These bits are set at higher layers of the protocol stack and are suggestions given the router. This looks like a nice feature for control networks since control networks require low delay and high reliability. However, it is not clear that routers even look at these bits. It appears that this was a feature with great promise but never really implemented. This is to be rectified in IPv6.

Total Length: The total length of the datagram including the header cannot exceed 65,535 bytes. This 16-bit field is for the datagram itself and not the packet length in the data link layer. If this datagram is larger than the maximum packet length that can be sent, the datagram will need to be fragmented into manageable successive packets. In this case the total length field will represent the length of the fragment sent and not the length of the original datagram.

Datagram Identification: A unique 16-bit identifier assigned by the host will accompany the datagram. This is necessary in order for the receiving host to reassemble fragmented datagrams. All fragments will contain the same datagram identifier.

Flags: Three bits are reserved for flags but only two are used. The Don't Fragment bit tells the router not to fragment the datagram. If this cannot be done an error message is returned. The More Fragments bit is used in the fragmentation process. A 1 means that the datagram being sent is actually a fragment of a larger datagram. A 0 means that either the datagram is not fragmented (first and only datagram) or it's the last fragment. Receiving hosts need this information in order to reassemble fragments.

Fragment Offset: Thirteen bits are used to indicate which fragment is being sent. Fragmentation is the process of breaking up large datagrams into manageable packets. Ideally you would like to restrict datagram size to packet size in order to avoid fragmentation. With Ethernet II the maximum packet size is 1500 bytes. This is called its Maximum Transmission Unit (MTU) and within a private or local network

Figure 5 — The IP datagram consisting of a header and data is inserted into the Ethernet data field.

the MTU is known and can be adhered to. The problem occurs between networks. Intermediate networks may have a lesser MTU requiring the router to fragment the original message even though it was originally sent unfragmented. The router does the fragmentation on his own (as long as the datagram was not marked as "do not fragment") and the fragments must be recombined at the destination host. Routers do not recombine fragments.

The default MTU is 576 bytes and all routers must be able to handle that size transmission. By restricting the datagram to 576 bytes, it will never need to be fragmented. Of course that puts an undue restriction on the Ethernet II network since packets can be as long as 1500 bytes. So for local networks set the maximum datagram size to the local network's MTU. If the datagram is to be sent beyond the local network set the maximum datagram size to 576 bytes. For control networks, fragmentation may never be an issue since control information packets are usually short not exceeding 256 or 512 bytes. Fragmentation should be avoided since it increases data latency and increases the chances of a corrupted datagram since multiple packets must be sent per datagram.

If fragments are to be sent it is necessary to load in the fragment offset. Notice that with every fragment the IP header is resent with just a slight modification. The fragment offset will change on every fragment and possibly along with one flag bit. Fragments must be sent in eight-byte multiples because there are only 13 bits available for identifying fragments and datagrams can be 64 KB in length. For example, if the first fragment is 1024 bytes long, the fragment offset of the next fragment will indicate that the accompanying fragment begins the 1025th byte of the original datagram. With knowledge of the datagram identifier, fragment offset, the source IP address and the fragments themselves, the complete datagram can be reassembled by the receiving host even if the fragments are received out of order. That is the true strength of the IP. Packets can take different routes to the intended destination and still be reassembled into the original datagram.