IP fragmentation

IP fragmentation refers to the allocation of an IP data packet on a plurality of physical data blocks, if the total length of the data packet is larger than the maximum transmission unit of the network interface.

Background

In the simplest case, the entire IP datagram fits into a physical data block and thus achieving the highest efficiency. However, there is in principle no fixed standards regarding the packet size of IP packets. Nevertheless, the maximum packet size is dependent on the infrastructure components used, since different packet switching techniques allow different maximum packet sizes.

Objective

Objective of introducing the fragmentation in the Internet Protocol (IP) was the underlying network structure for the user to hide (OSI model), and thus the implementation of the network protocol of the hardware has to be isolated.

Operation

Once the IP stack ( see also the OSI model or TCP / IP reference model) contains a data packet to send, it shall examine whether the packet size makes a reference to the given allocation to be used for the network interface MTU necessary. If this is necessary, it shall communicate the existing data packet into multiple packets. This process is known as fragmentation. This fragmentation can take place either at the original sender or on routers that are between the transmitter and receiver. If an IP datagram is fragmented, it is only at the receiver re-assembled (with the exception, if necessary, intermediate firewalls, which have been specifically instructed to perform a so-called reassembly, before the data is transmitted ). Should it be necessary, an already fragmented packet can be fragmented (such as when changing the transmission technology ).

Each datagram that has been fragmented to obtain and contains instead of the datagram header of the original packet called a fragment header, which specifies among other things the so-called offset of messages sent in this packet data portion in relation to the original package. The fragment offset ( 13 bits in the IP header ) is thereby given in 8- byte blocks, so if the first data frame contains 1000 bytes of user data, the fragment offset of the second packet 125 ( = 1000 bytes / 8 bytes). Thus, only the last fragment having a payload size is not a multiple of 8 bytes. Furthermore, it is noted that the fragment offset begins at 0 ( the entry in the first fragment) and therefore the offset of the second packet in the example 125 and is not about 126. In all fragments except the last one, the fragment More flag is set. Ins of the IP header length field in all fragments, the length of each fragment is registered and for each header, the IP header checksum is calculated separately, while the rest of the header corresponds to the original headers before fragmentation.

The receiver now has the task, the original from the present in the packet headers information back together again by ( with the exception of separate for each fragment information ) perform such fragments with the same IP header and puts them in the correct order according to their offsets. Since each fragment is a stand-alone package, it can also happen that these items arrive not ordered. It is also possible that some fragments are lost or defective. It is then up to the receiver to discard the packet and request the data again, resulting in a higher network load can occur.

By definition, the IP layer can make any statements about whether a packet is fragmented in the course of its transmission or not. The only exception: The sender can set the so-called Do not Fragment flag, which all involved communication systems (routers, gateways, etc. ) instructs not to make any fragmentation. In the event that a fragmentation would be necessary but, the packet is discarded and the sender sends an ICMP error message of type 3 ( destination unreachable ) and Code 4 ( fragmentation required but do not fragment bit set), which states that the goal was unavailable for unfragmentierbare packages of this size.

Effects

Although the objective is a higher layer (eg, TCP / UDP) transparent implementation, there are two points where this is not quite achieved:

• Fragmentation can have a major impact on the data throughput and affects this generally negative.
• Lost a fragmented packet of the original package, so all of the original must be retransmitted. However, IP has no backup or timeout mechanisms and this is dependent on the security functions of higher layers such as TCP.

From above, it is always tries to avoid fragmentation as much as possible.

IPv6

For IPv6 routers it is not allowed to fragment packets. The sender is always notified of fragmentation needs with an ICMPv6 message type 2 ( Packet Too Big). This may then reduce its packet sizes the fact that the communicating application produces smaller unfragmented packets, or the fact that is fragmented. In the second case, the sender a fragment extension header (protocol 44) begins after the IPv6 header insert that contains the parameters of the fragmentation, because they are no longer provided in the IPv6 header. When filtering packets should be noted that the Next Header field in the IPv6 header for fragmented traffic refers to protocol 44 and not on the original protocol number, such as 17 for UDP, these shifts in the Next Header field of the fragment extension header.

Dissemination on the Internet

According to surveys carried out in Sweden in 2007, the " do not fragment " (DF ) bit set at about 91 % of messages sent on the Internet, IPv4 packets, the fragmented data traffic accounted only for 0.06 % of all packages. Previous results indicate that fragmented IPv4 traffic of less than 1 % measured in number of packets and less than 2% measured in volume of data, but it is also drawn attention to large variations in the measurements.