IP fragmentation

The IP fragmentation is the splitting of an IP - packet to multiple data blocks if the total length of the data packet larger than the Maximum Transmission Unit of the network interface is.

background

In the simplest case, the entire IP datagram fits into one data block and thus achieves the highest efficiency. Basically the maximum size of an IP datagram is 64 kB. Nevertheless, the maximum possible packet size depends on the infrastructure components used, since different packet switching technologies allow different maximum packet sizes.

Goal setting

The aim of introducing fragmentation in the Internet Protocol (IP) was to hide the underlying network structure from the user ( OSI model ) and thus make the implementation of the network protocol hardware-independent.

Working method

As soon as the IP stack (see also OSI model or TCP / IP reference model ) contains a data packet to be sent, it checks whether the packet size requires a breakdown based on the MTU given for the network interface to be used . If this is necessary, it divides the existing data packet into several data packets. This process is known as fragmentation. This fragmentation can take place either at the original sender or on routers between the sender and receiver. If an IP datagram is fragmented, it is only reassembled at the recipient (exception: possibly interconnected firewalls that have been specially instructed to carry out a so-called reassembly before the data is forwarded). Should it be necessary, an already fragmented packet can be further fragmented (e.g. when changing the transmission technology).

Every IP datagram that has been fragmented receives a new header based on the original header and special updated fields. In the new IP headers of the fragments, the so-called offset indicates the position of the data sent in this packet in relation to the original packet . The fragment offset (13 bits in the IP header ) is specified in 8-byte blocks. If the first datagram contains 1000 bytes of user data , then the fragment offset of the second packet is 125 (= 1000 bytes / 8 bytes). This means that only the last fragment can have an amount of user data that is not a multiple of 8 bytes. It should also be noted that the fragment offset starts at 0 (the entry in the first fragment) and therefore the offset of the second packet in the example mentioned is 125 and not approximately 126. The more fragments flag is set for all fragments except the last one. The length of each fragment is entered in the length field of the IP header for all fragments, and the IP header checksum is calculated separately for each header, while the rest of the header corresponds to the original header before fragmentation.

The recipient now has the task of reassembling the original from the information contained in the packet headers by taking all fragments with the same IP header (with the exception of the separate information for each fragment) and putting them in the correct order based on their offset. Since each individual fragment is an independent package, it can also happen that these individual parts do not arrive in an orderly manner. It is also possible that individual fragments are lost or defective. It is then up to the recipient to discard the packet and request the data again, which can result in a higher network load.

By definition, the IP layer cannot provide any information about whether a packet is fragmented or not in the course of its transmission. The only exception: The sender can set the so-called Don't-Fragment flag, which instructs all communication systems involved (routers, gateways, etc.) not to perform any fragmentation. In the event that fragmentation would be necessary, the packet is discarded and an ICMP error message of type 3 (destination unreachable) with code 4 (fragmentation required but don't fragment bit set) is sent to the sender , stating that the destination for unfragmentable packets of this size is not accessible.

Effects

Although the objective is an implementation that is transparent for higher layers (e.g. TCP / UDP ), there are two points where this is not quite achieved:

• Fragmentation can have a major impact on data throughput and generally has a negative impact on it.
• If a fragmented package of the original package is lost, the entire original must be transmitted again. However, IP has no security or timeout mechanisms and is dependent on the security functions of higher layers such as those of TCP .

For the reasons mentioned, we try to avoid fragmentation as much as possible.

IPv6

With IPv6 , routers are no longer allowed to fragment packets. If there is a need for fragmentation, the sender is always informed with an ICMPv6 message of type 2 (Packet Too Big). The latter can then reduce its packet sizes by the communicating application generating smaller, unfragmented packets or by fragmenting them. In the second case, the sender begins to insert a Fragment Extension Header ( protocol 44 ) after the IPv6 header , which contains the parameters of the fragmentation, because these are no longer provided in the IPv6 header . When filtering packets, it should be noted that the Next Header field in the IPv6 header refers to protocol 44 for fragmented data traffic and no longer to the original protocol number, such as 17 for UDP, this is shifted to the Next Header field of the Fragment Extension Header .

Distribution on the Internet

According to surveys in Sweden from 2007, the “ don't fragment ” (DF) bit was set in around 91% of IPv4 packets sent on the Internet, and fragmented data traffic made up only 0.06% of all packets. Earlier results indicate fragmented IPv4 traffic of less than 1% measured in number of packets and less than 2% measured in data volume, but attention is also drawn to strong fluctuations in the measurements.

Individual evidence

1. ^ J. Postel: Internet Protocol. Retrieved July 5, 2018 . 
2. ^ J. Postel: Internet Protocol. Retrieved July 5, 2018 . 
3. ↑ Wolfgang John, Sven Tafvelin: Analysis of Internet Backbone Traffic and Header Anomalies observed ( Memento of the original from March 27, 2016 in the Internet Archive ) Info: The archive link was automatically inserted and not yet checked. Please check the original and archive link according to the instructions and then remove this notice. (English) 
4. ↑ Colleen Shannon, David Moore: Beyond Folklore: Observations on Fragmented Traffic (English; PDF; 300 kB)