What's in an IP header?

In IP, each packet is called a datagram. The structure of an IP datagram is given in Figure

1. Version(4bits): this field identifies the version of this protocol. The version in current use is 4 (0100). The reason for this field is that network layer protocols do undergo changes, although very infrequently, but it will be unimaginable if the entire internet has to be shutdown to have a network wise upgrade of protocol softwares. Because of this when changes do occur, the new version is reflected in this field, making coexistence of different versions possible during the transitional period.
2. Header length(4bits): the number of 32bit words in the header.
3. Type of Service(TOS, 8bits): normal service, minimize delay, maximize throughput, maximize reliability, minimize monetary cost. At any time, only of these options is turned on. TOS field is used by IP to support other higher layer services that demand different quality of service(QOS). TOS in IP only provide general performance guidelines, and does not provide exact guarantees in any specific QOS. For example, if the higher layer requests that the information must be delivered in 5, there is no way to convey this information in the TOS field. In general, and requires minimize delay because they are interactive applications that require timely response. On the other hands, data transfer requires maximize throughput.
4. Total length(16bits): total length of the IP datagram in bytes. Therefore, an IP datagram can be no more than bytes.
5. Identification(16bits), flags, fragmentation offsets: These are used in the fragmentation process, which will be explained in Section .
6. Time-to-live(TTL, 8bits): the upper limit on the number of routers through which a datagram can pass. Normally, the sender initialize it to some value, often 32 or 64, and it is decremented by one by every router that handles the datagram. Once it reaches 0, the datagram is thrown away and the sender is notified of the loss through the use of ICMP message.
7. Protocol (8bits): this is used to identify the upper layer protocol that is currently using this IP datagram. Common protocols include all those on top of IP: TCP, UDP, ICMP, IGMP.
8. Checksum (16bits): this is used to error detect the potential errors in IP header only. It use something simpler than the CRC scheme we discussed before and has no error correction capability. If error is found in the IP header, the datagram is thrown away. What happens if error occurs in the data portion itself? In this case, the IP layer does not do anything. Whoever sent the data to IP layer should have their own error checking done. This is another example of applying error checking in different layers independently. By adding error checking in each layer, error resistance is improved, but there will be more overhead.
9. Source and Destination IP addresses(32bits): Because IP provides connectionless service, complete destination address has to be provided as part of the IP datagram. This is in contrast to the virtual circuit concept for ATM. In ATM, the connection is set up before any cells are transmitted, once the connection is set up, each cell only needs to know which node, that has direct link to this node, to go to next, therefore, there is no need to have complete address information. But to send IP datagram accross the network, no prior call set up is done before the datagram leaves the station. The datagram has to find its own way towards the destination. Therefore, it needs the complete destination information. Section further discusses this issue.

   Why do we also need the source address in the header? The reason here is that if the datagram is lost, the originator of the IP datagram should be notified so. There is no other way to backtrack the path of IP datagram except to include the source address as part of the IP datagram.