The role of IP protocol
IP protocol is part of the Internet layer
of the TCP/IP protocol suite. It is one of the most important Internet protocols because it allows the development and transport of IP datagrams (data packets), without however ensuring their "delivery". In reality, IP protocol processes IP datagrams independently from each other by defining their representation, routing and forwarding.
IP protocol determines the recipient of the message using 3 fields:
- The IP address field: machine address
- The subnet mask field: a subnet mask enables the IP protocol to establish the part of the IP address which relates to the network
- The default gateway field: enables the Internet protocol to know
which machine to deliver a datagram to if ever the destination machine is not on the local area network.
Data circulates on the Internet in the form of datagrams (also known as packets). Datagrams are encapsulated data, i.e. data to which headers are added relating to information about their transport (such as the destination IP address).
The data contained within the datagram is analyzed (and possibly modified) by the routers allowing their transit.
Here is what a datagram looks like:
|Time to live
|Source IP address (32 bits)
|Destination IP address (32 bits)
Here are the meanings of the different fields:
- Version (4 bits): this is the version of IP protocol being used (currently version 4 IPv4 is being used) in order to verify the validity of the datagram. It is coded over 4 bits.
- Header length or IHL for Internet Header Length (4 bits): this is the number of 32 bit words making up the header (NB: the minimum value is 5). This field is coded over 4 bits.
- Service type (8 bits): indicates the way in which the datagram must be processed.
- Total length (16 bits): indicates the total size of the datagram in bytes. The size of this field being 2 bytes, the total size of the datagram cannot exceed 65536 bytes. Used jointly with the header size, this field makes it possible to determine where the data is located.
- Identification, flags and fragment offsetting are fields which enable datagram fragmentation, they are explained below.
- TTL or Time to Live (8 bits): this field specifies the maximum number of routers through which the datagram may pass. So this field is decremented with each passage through a router and when it reaches the critical value of 0, the router destroys the datagram. This prevents the network being overloaded with lost datagrams.
- Protocol (8 bits): this field, in decimal notation, makes it possible to find out which protocol the datagram comes from.
- ICMP: 1
- IGMP: 2
- TCP: 6
- UDP: 17
- Header checksum (16 bits): this field contains a value coded over 16 bits which enables the integrity of the header to be monitored in order to establish whether it has been altered during transmission. The checksum is the addition of one to all the 16 bit words of the header (checksum field excluded). This is done so that when the header fields are added together (inclusive checksum), a number with all the bits positioned at 1 is obtained.
- Source IP address (32 bits): This field represents the IP address of the originator machine, it enables the recipient to respond.
- Destination IP address (32 bits): IP address of the message recipient
Fragmentation of IP datagrams
As we have previously seen, the maximum size of a datagram is 65536 bytes. However, this value is never reached because networks do not have sufficient capacity to send such large packets. In addition, networks on the Internet use different technologies and the maximum size of a datagram varies depending on the network type.
The maximum size of a frame is called the MTU (Maximum Transfer Unit); it will lead to the fragmentation of the datagram if it is larger than the network's MTU.
||MTU (in bytes)
Datagram fragmentation takes place at router level, i.e. during transition from a network with a large MTU to a network with a smaller MTU. If the datagram is too large to pass onto the network, the router will fragment it, i.e. cut it into fragments smaller than the network's MTU in such a way that the size of the fragment is a multiple of 8 bytes.
The router will then send these fragments independently and re-encapsulate them (add a header to each fragment) in such a way as to take into account the new size of the fragment. In addition, the router adds information so that the recipient machine can reassemble the fragments in the right order. However, there is nothing to say that the fragments will arrive in the right order, considering that they are routed independently from each other.
To take into account fragmentation, each datagram has several fields permitting their reassembly:
- Fragment offset field (13 bits): field providing the position of the beginning of the fragment in the initial datagram. The unit of measure for this field is 8 bytes (the first fragment having a zero value).
- Identification field (16 bits): number allocated to each fragment in order to enable reassembly.
- Total length field (16 bits): this is recalculated for each fragment.
- Flag field (3 bits): this comprises of three bits:
- The first is not used.
- The second (called DF: Don't Fragment) indicates if the datagram can be fragmented or not. If a datagram has this bit positioned at one and the router cannot route it without fragmenting it, the datagram is rejected
with an error message.
- The second (called MF: More Fragments), indicates if the datagram is a fragment of data (1). If the indicator is at zero, this indicates that the fragment is the last (so the router must be in possession of all the previous fragments) or the datagram has not been subject to fragmentation.
IP routing is an integral part of the Internet layer of the TCP/IP suite. Routing consists of providing the routing for an IP datagram across a network by taking the shortest path. This role is conducted by machines called
routers, i.e. machines linked (linking) by at least two networks.
For more information on ICMP protocol, please refer to RFC 791 which explains the IP protocol in detail:
Latest update on October 16, 2008 at 09:43 AM by Jeff.