IP V4 Header and protocol functions
IP V4 Header and protocol functions
Data transmitted over an internet using IP is carried in messages called IP datagrams. Like all network protocol messages, IP uses a specific format for its datagrams. The term ‘datagram’ or ‘packet’ is used to describe a chunk of IP data. Each IP datagram contains a specific set of fields in a specific order so that the reader knows how to decode and read the stream of data received. The IPv4 datagram is conceptually divided into two pieces: the header part and the text part (Data part). The header part contains addressing and control fields, while the text part (Data Part) carries the actual data to be sent over the internetwork. The header has a 20 bytes fixed part and a variable length optional part. Even though IP is a relatively simple, connectionless, “unreliable” protocol, the IPv4 header carries a fair bit of information, which makes it rather large. At a minimum, it is 20 bytes long, and with options can be significantly longer. The IPv4 packet header consists of 14 fields, of which 13 are required. The 14th field is optional. See the below figure.
Fields of header format describe below:· VERSION (4 bits)
The version field is set to the value ‘4’ in decimal or ‘0100’ in binary. The value indicates the version of IP (4 or 6, there is no version 5).
The Internet Header Length (IHL) describes how big the header is in 32-bit words. For instance, the minimum value is 5, as that is the minimum size of an IP header that contains all the correct fields is 160 bits, or 20 bytes(5*4=20 bytes/160 bits). This allows the receiver to know exactly where the payload data begins.
Type of service field designed to carry information to provide quality of service features, such as prioritized delay for IP datagrams. This allows the intermediate receiving stations (the routers) to have some notion of the quality of service desired. This allows the network to make adaptations for delay, throughput, or reliability.
This field specifies the total length of the IP datagram, in bytes. This informs the receiver of the datagram where the end of the data in this datagram is. This is the length of the entire datagram in octets, including the header. This is why an IP datagram can be up to 65,535 bytes long, as that is the maximum value of this 16-bit field.
· These values allow datagrams to be fragmented for transmission and reassembled at the destination. Sometimes, a device in the middle of the network path cannot handle the datagram at the size it was originally transmitted, and must break it into fragments. This field uniquely identifies the datagram, usually incremented by each time a datagram is sent. All fragments of a datagram contains the same identification value, This allows the destination host to determine which fragment belongs to which datagram.
First 1 bit flag is reserved not used. DF (1 bit) means do not fragment; it is request to routers not to fragment the datagram since the destination is incapable of putting the pieces back together. MF (1 bit) means more fragments to follow, when set to 0, indicates the last fragment in the message; when set to 1, indicates that more fragments are yet to come in The fragmented message. This field indicates whether the datagram is a fragment, whether it is permitted to be fragmented, and whether the datagram is the last fragment, or there are more fragments.
When a datagram is fragmented, it is necessary to reassemble the fragments in the correct order. The fragment offset numbers the fragments in such a way that they can be reassembled correctly.
This field determines how long a datagram will exist. At each hop along a networkpath, the datagram is opened and it’s time to live field is decremented by one (or more than one in some cases). When the time to live field reaches zero, the datagram is said to have ‘expired’ and is discarded. This prevents congestion on the network that is created when a datagram cannot be forwarded to it’s destination. Most applications set the time to live field to 30 or 32 by default.
This indicates what type of protocol is encapsulated within the IP datagram. Some of the common values seen in this field include:
|
Protocol
|
Number
(Decimal) |
|
ICMP
|
1
|
|
IGMP
|
2
|
|
TCP
|
6
|
|
UDP
|
17
|
This field verifies only header not data. This field is used to check, whether there is any error or problem in header of datagram. The checksum allows IP to detect datagrams with corrupted headers and discard them. Since the time to live field changes at each hop, the checksum must be re-calculated at each hop. In some cases, this is replaced with a cyclic redundancy check algorithm.
The 32-bit IP address of the originator of the datagram. This is the IP address of the sender of the IP datagram. This field must remain unchanged during the time the IP datagram travels from source host to destination host.
This is the IP address of the intended receiver(s) of the datagram. If the host portion of this address is set to all 1’s, the datagram is an ‘all hosts’ broadcast. This field must remain unchanged during the time the IP datagram travels from source host to destination host.
This is not a mandatory field. It’s optional. Various options can be included in the header by a particular vendor’s implementation of IP. There are some options like: record route, is used to record the route of total number routers visited by datagram. Time stamp, is used to record the time of datagram processing by router.
