IP Fragmentation "Explanation & Examples"

IP Datagram Fragmentation with Examples:

=================================

·      Not all link-layer protocols can carry network-layer packets of the same size. Some protocols can carry big datagrams, whereas other protocols can carry only little packets.

·      For example, Ethernet frames can carry upto 1,500 bytes of data, whereas frames for some wide-area links can carry no more than 576 bytes.

·      The maximum amount of data that a link-layer frame can carry is called the maximum transmission unit (MTU). Because each IP datagram is encapsulated within the link-layer frame for transport from one router to the next router, the MTU of the link-layer protocol places a hard limit on the length of an IP datagram.

·      Having a hard limit on the size of an IP datagram is not much of a problem. What is a problem is that each of the links along the router between sender and destination can use different link-layer protocols, and each of these protocols can have different MTUs.

IP Datagram Fragmentation:

======================

To understand the forwarding issue better, imagine that you are a router that interconnects several links, each running different link-layer protocols with different MTUs.

Suppose you receive an IP datagram from one link. You check your forwarding table to determine the outgoing link, and this outgoing link has an MTU that is smaller than the length of the IP datagram. Time to panic – how are you going to squeeze this oversized IP datagram into the payload field of the link-layer frame?

The solution is to fragment the data in the IP datagram into two or more smaller IP datagrams, encapsulate each of these smaller IP datagrams in a separate link-layer frame; and send these frames over the outgoing link. Each of these smaller datagrams is referred to as a fragment.

Fragments need to be reassembled before they reach the transport layer at the destination.

Indeed, both TCP and UDP are expecting to receive complete, unfragmented segments from the network layer.

NOTE:

The designers of IPv4 felt that reassembling datagram in the routers would introduce significant complication into the protocol and put a damper on router performance. (if you were a router, would you want to be reassembling fragments on top of everything else you had to do?).

Sticking to the principle of keeping the network core simple, the designers of IPv4 decided to put the job of datagram reassembly in the end system rather than in network routers.

When a destination host receives a series of datagrams from the same source, it needs to determine whether any of these datagrams are fragments of some original larger datagram.

If some datagrams are fragments, it must further determine when it has received the last fragment and how the fragments it has received should he pieced back together to form the original datagram.

To allow the destination host to perform these reassembly tasks, the designers of IP (version 4) put identification flag, and fragmentation offset fields in the IP datagram header.

When a datagram is created, the sending host stamps the datagram with an identification number as well as source and destination address. Typically, the sending host increments the identification number for each datagram it sends. When a router needs to fragment a datagram, each resulting datagram (that is, fragment) is stamped with the source address, destination address, and identification number of the original datagram.

When the destination receives a series of datagrams from the same sending host, it can examine the identification numbers of the datagrams to determine which of the datagrams are actually fragments of the same larger datagram.

Because IP is an unreliable service, one or more of the fragments may never arrive at the destination. For this reason, in order for the destination host to be absolutely sure it has received the last fragment of the original datagram, the last fragment has a flag bit set to 0, whereas all the other fragments have flag bit set to 1. Also, in order for the destination host to determine whether a fragment is missing ( and also to be able to reassemble the fragments in their proper order), the offset field is used to specify where the fragment fits within the original IP datagram.

Fields Related to Fragmentation:

=========================

Identification:

The identification is 16 bits and is a value assigned by the sender of an IP datagram to aid in the reassembly of the fragments of a datagram.

Fragment offset:

The fragment offset is 13 bits and indicates where a fragment belongs in the original IP datagram. This value is a multiple of eight bytes.

DF, MF, other bit:

In the flags field of the IP header, there are three bits for control flags. It is important to note that the "don't fragment" (DF) bit plays a central role, because it determines whether or not a packet is allowed to be fragmented.

Bit 0 is reserved, and is always set to 0.

Bit 1 is the DF bit (0 = "may fragment," 1 = "do not fragment").

Bit 2 is the MF bit (0 = "last fragment," 1 = "more fragments").

IP Datagram Fragmentation Example1:

==============================
The figure below shows an IP datagram fragmentation example.

A datagram of 4,000 bytes (20 bytes of IP header plus 3,980 bytes of IP payload) arrives at a router and must be forwarded to a link with an MTU of 1,500 bytes.

This implies that the 3,980 data bytes in the original datagram must be allocated to three separate fragments (each of which is also an IP datagram).

Suppose that the original datagram is stamped with an identification number of 777.

The characteristics of three fragments are shown in the table below.

The values in the above table reflect the requirement that the amount of original payload data in all but the last fragment be a multiple of 8 bytes, and that the offset value be specified in units of 8-byte chunks.

At the destination, the payload of the datagram is passed to the transport layer only after the IP layer has fully reconstructed the IP datagram. If one or more of the fragments does not arrive at the destination, the incomplete datagram is discarded and not passed to the transport layer.

But, we know that if TCP is being used at the transport layer, then TCP will recover from this loss by having the source retransmit the data in the original datagram.

Question Related to above problem:

===========================

1. Why are we dividing 1480 by 8 to get the offset?

Ans:

The offset is the address or the locator from where the data starts with reference to the original data payload.

For IP the data payload comprises all the data that’s after the IP header and Options header. Thus, the system/router takes the payload and divides it into smaller parts and keeps the track of the offset with reference to the original packet so that reassembly can be done.

As given in the RFC Page 12.

"The fragment offset field tells the receiver the position of a fragment in the original datagram. The fragment offset and length determine the portion of the original datagram covered by this fragment. The more-fragments flag indicates (by being reset) the last fragment. These fields provide sufficient information to reassemble datagrams. "

The fragment offset is measured in Units of 8 bytes each. It has 13 bit field in the IP header. As said in the RFC page 17

"This field indicates where in the datagram this fragment belongs.The fragment offset is measured in units of 8 octets (64 bits). The first fragment has offset zero."

Thus, in the question where did this 8 come from, its the standard that’s been defined for IP protocol specification, where 8 octets are taken as one value. This also helps us to transmit large packets via this.

Page 28 of the RFC writes: *Fragments are counted in units of 8 octets. The fragmentation strategy is designed so than an unfragmented datagram has all zero fragmentation information (MF = 0, fragment offset = 0). If an internet datagram is fragmented, its data portion must be broken on 8 octet boundaries. This format allows 2**13 = 8192 fragments of 8 octets each for a total of 65,536 octets. Note that this is consistent with the the datagram total length field (of course, the header is counted in the total length and not in the fragments).*

IP Datagram Fragmentation Example2:
==============================

·      The first fragment has an offset of 0, the length of this fragment is 1500; this includes 20 bytes for the slightly modified original IP header.

·      The second fragment has an offset of 185 (185 x 8 = 1480), which means that the data portion of this fragment starts 1480 bytes into the original IP datagram. The length of this fragment is 1500; this includes the additional IP header created for this fragment.

·      The third fragment has an offset of 370 (370 x 8 = 2960), which means that the data portion of this fragment starts 2960 bytes into the original IP datagram. The length of this fragment is 1500; this includes the additional IP header created for this fragment.

·      The fourth fragment has an offset of 555 (555 x 8 = 4440), which means that the data portion of this fragment starts 4440 bytes into the original IP datagram. The length of this fragment is 700 bytes; this includes the additional IP header created for this fragment.

·      It is only when the last fragment is received that the size of the original IP datagram can be determined.

·      The fragment offset in the last fragment (555) gives a data offset of 4440 bytes into the original IP datagram. If you then add the data bytes from the last fragment (680 = 700 - 20), that gives you 5120 bytes, which is the data portion of the original IP datagram. Then, adding 20 bytes for an IP header equals the size of the original IP datagram (4440 + 680 + 20 = 5140).

For detailed explanation refer to the below link:

IP-Fragmentation-Cisco

Watch The below Videos, They have a good explanation.