IPv4 service model and header format
The first thing to know about IP is that it is unreliable. It is fast and simple to build and maintain. It provides no guarantee. So packets can be dropped when necessary and can be corrupted. It is said that IP provides best effort and out-of-order delivery of datagrams. It is a connectionless protocol because there is no prior connection to communicate and IP does not retain the state of the communication.
IP is also called the “thin waist” because it is a requirement for communication on the internet. However, the upper layers and bottom layers provide a variety of choices.
To make a routing decision, routers need to learn the IP DA field of the datagram header. Datagrams are routed hop by hop.
Network engineers designed IP as a simple protocol because they believed it will allow the network to run fast on routers scattered worldwide.
IPv4 service model
- IP tries to limit packets stuck in a loop, with the TTL field
- provides a way to fragment long datagrams
- includes “header checksum” to verify header content integrity
- has two versions: IPv4 and IPv6
- allows new fields to be added to the header (in IPv6)
IPv4 fragmentation and MTU
IP fragmentation and MTU are two linked concepts. Link layer technologies have different packet sizes. Each layer 2 technology dictates a maximum size of an upper-layer PDU within the layer 2 frame. This maximum allowed size is called the Maximum Transmission Unit or MTU.
For example, if IP is to be encapsulated into an Ethernet frame, then MTU= 1500 bytes, which means “an Ethernet frame allows as much as 1500 bytes of IP stuff”. Frame Relay on the other hand, allows a variable MTU size that can go up to 16 KBytes.
This is a restriction for IP because IP datagrams are bigger than to fit into a 1500 bytes packet. So IP can not transmit the complete datagram in a single Ethernet frame; it has to fragment it into smaller datagrams. This is done at the outgoing interfaces of routers.
IPv4 packet header format
[box type=”note” align=”aligncenter” ]
Header, Overhead and Payload
First, let’s make the difference between header, overhead and payload. A packet -whether it is a datagram, a segment or a frame- is composed roughly of two parts: the header and the payload. The header is also called the overhead. We talk about “protocol overhead”, “datagram overhead”, “packet overhead” and even “header overhead” to mean almost the same thing. The header -or the overhead- is the information that is needed to transport the payload. The payload is the upper layer information that is encapsulated within the packet. It’s the PDU of the N+1 layer.[/box]
The minimum IP header overhead is 20 bytes. The way to represent that visually (on the IP header figure below) is by multiplying the minimum number of rows by the size of each row. The minimum number of rows is 5, because the Options field and the Data field are not mandatory.
Having the length of each row is 32 bits (from bit number 0 to bit number 31) or 4 bytes, you multiply 5*4 = 20 bytes.
- Header Length (aka Internet Header Length): is the number of 32-bit words in the IP header. For example, if Header Length = 0010, then we know that there are 2 words of 32 bits size each, in the IP header. Header Length is written in 4 bits. So we can have a maximum of (2^4) – 1 = 15 words of 32 bits. This means that the maximum size of an IP header is 15 * 32 = 480 bits = 60 bytes.
- Type of Service
- Packet Length: aka Total Length. Written in 16 bits, it measures the size of the IPv4 datagram in bytes, including the IP header. 16 bits mean that an IP datagram size can be as big as 2^16 – 1 = 65535 bytes. However, most Link layer protocols do not allow this size of IP datagrams to fit into a single layer 2 frame. In fact, IP is constrained to fragment its datagrams (remember that Ethernet frames can have a minimum size of 64 bytes, and Ethernet payload can be as small as 46 bytes).Knowing the Packet Length and the Header Length, it is possible to determine the size of the IP payload.
- version determines the IP version. In IPv4, the version field value =4
- Identifier: aka “Identification”, or “ident”; used to identify fragments that belong to the same packet
- Flags: written in three bits. Values can be:
- 0: reserved
- 1: DF: Don’t’ Fragment
- 2: MF: More Fragments
When a datagram is fragmented, all fragments have the MF flag set (MF bit = 1), except for the last fragment. The last segment does not have the MF set simply because there will be no more fragments.
If a datagram has DF flag set, and a router needs to fragment the datagram, then the datagram is dropped.
[box type=”note” align=”aligncenter” ] Most network hosts avoid IP fragmentation. It is possible, in instance, that TCP chooses to use segments whose sizes are less than the link layer MTU (less than 1518 bytes for example, in the case of Ethernet) [/box]
- Fragment Offset (aka Fragment ID) : written in 13 bits. It is the offset of the fragment relative to the original fragmented datagram, in multiples of 8 bytes (64 bits). So all fragments will have a size which is a multiple of 8, except for the last segment.
- TTL: written in one byte. TTL is decreased by 1 at each hop. When it reaches 0, the router discards the packet
- Upper layer protocol (aka Protocol ID) : defines the upper layer. For example, ID=6 means it’s a TCP segment. A complete list of protocol numbers is listed here.
- Header Checksum: determines if the header is intact. As the name dictates, it is important to remember that the Header Checksum is calculated based on the IP header only. When receiving a datagram, a router calculates the Header Checksum using a pre-known formula. If the value it finds differs from the Header Checksum value in the datagram, the datagram is dropped. Once the TTL is decreased, a new Header Checksum is calculated and written to the datagram before sending the datagram to the next hop.
- SA: Source Address
- DA : Destination Address
Another great IPv4 header format is layed in the following picture:
- Figure 1: Computer Networking: A Top Down Approach Featuring The Internet
- Figure 3: TCP/IP Illustrated, Volume 1: The Protocols, Fall and Stevens
- Figure 4: Ryusstory.com