View source for IP fragmentation

{{Short description|Process that breaks IP packets into smaller pieces}}
{{Distinguish|IPv4 address exhaustion#Markets in IP addresses{{!}}fragmentation of the IPv4 address space}}
[[file:PDU Fragmentation-en.png|thumb|400px|An example of the fragmentation of a protocol data unit in a given layer into smaller fragments.]]

'''IP fragmentation''' is an [[Internet Protocol]] (IP) process that breaks [[network packet|packets]] into smaller pieces (fragments), so that the resulting pieces can pass through a link with a smaller [[maximum transmission unit]] (MTU) than the original packet size. The fragments are reassembled by the receiving [[Host (network)|host]].

The details of the fragmentation mechanism, as well as the overall architectural approach to fragmentation, are different between [[IPv4]] and [[IPv6]].

==Process==
{{IETF RFC|791}} describes the procedure for IP fragmentation, and transmission and reassembly of IP packets.<ref name=RFC791>{{citation |rfc=791 |title=Internet Protocol |publisher=Information Sciences Institute |date=September 1981}}</ref> RFC 815 describes a simplified reassembly algorithm.<ref name=RFC815>{{citation |rfc=815 |title=IP Datagram Reassembly Algorithms |author=David D. Clark |date=July 1982}}</ref> The ''Identification'' field along with the ''foreign'' and ''local internet address'' and the ''protocol ID'', and ''Fragment'' offset field along with ''Don't Fragment'' and ''More Fragments'' flags in the [[IP header]] are used for fragmentation and reassembly of IP packets.<ref name=RFC791/>{{rp|24}}<ref name=RFC815/>{{rp|9}}

If a receiving host receives a fragmented IP packet, it has to reassemble the packet and pass it to the higher protocol layer. Reassembly is intended to happen in the receiving host but in practice, it may be done by an intermediate router, for example, [[network address translation]] (NAT) ''may'' need to reassemble fragments in order to translate data streams.<ref>{{citation |rfc=2993 |title=Architectural Implications of NAT |date=November 2000 |last1=Hain |first1=Tony L. }}</ref>

==IPv4 and IPv6 differences==
[[File:IPv4 Fragmentation Algorithm-en.png|thumb|400px|The fragmentation algorithm in IPv4.]]
[[File:IPv4 Fragmentation example -en.svg|thumb|400px|An example of IPv4 multiple fragmentation. The fragmentation takes place on two levels: in the first one the maximum transmission unit is 4000 bytes, and in the second it is 2500 bytes.]]

Under IPv4, a [[router (computing)|router]] that receives a [[network packet]] larger than the next hop's MTU has two options: drop the packet if the ''Don't Fragment'' (DF) flag bit is set in the packet's header and send an [[Internet Control Message Protocol]] (ICMP) message which indicates the condition ''Fragmentation Needed'' (Type 3, Code 4), or fragment the packet and send it over the link with a smaller MTU. Although originators may produce fragmented packets, IPv6 routers do not have the option to fragment further. Instead, network equipment is required to deliver any IPv6 packets or packet fragments smaller than or equal to 1280 bytes and IPv6 hosts are required to determine the optimal MTU through [[Path MTU Discovery]] before sending packets.

Though the header formats are different for IPv4 and IPv6, analogous fields are used for fragmentation, so the same algorithm can be reused for IPv4 and IPv6 fragmentation and reassembly.

In IPv4, hosts must make a best-effort attempt to reassemble fragmented IP packets with a total reassembled size of up to 576 bytes.  They may also attempt to reassemble fragmented IP packets larger than 576 bytes, but they are also permitted to silently discard such larger packets.  Applications are recommended to refrain from sending packets larger than 576 bytes unless they have prior knowledge that the remote host is capable of accepting or reassembling them.<ref name=RFC791/>{{rp|12}}

In IPv6, hosts must make a best-effort attempt to reassemble fragmented packets with a total reassembled size of up to 1500 bytes, larger than IPv6's minimum MTU of 1280 bytes.<ref name=rfc2460>{{citation |rfc=2460 |title=Internet Protocol, Version 6 (IPv6) Specification |authorlink=Steve Deering |author=S. Deering |author2=R. Hinden |date=December 1998}}</ref>  Fragmented packets with a total reassembled size larger than 1500 bytes may optionally be silently discarded.  Applications relying upon IPv6 fragmentation to overcome a path MTU limitation must explicitly fragment the packet at the point of origin; however, they should not attempt to send fragmented packets with a total size larger than 1500 bytes unless they know in advance that the remote host is capable of reassembly.

== Impact on network forwarding ==
When a network has multiple parallel paths, technologies like [[Link aggregation|LAG]] and [[Cisco Express Forwarding|CEF]] split traffic across the paths according to a [[Hash function|hash algorithm]]. One goal of the algorithm is to ensure all packets of the same [[Traffic flow (computer networking)|flow]] are sent out the same path to minimize unnecessary [[Out-of-order delivery|packet reordering]].

IP fragmentation can cause excessive retransmissions when fragments encounter [[packet loss]] and reliable protocols such as TCP must retransmit all of the fragments in order to recover from the loss of a single fragment.<ref>{{cite web|author=Christopher A. Kent, Jeffrey C. Mogul|url=http://www.cs.binghamton.edu/~nael/classes/cs528/fragment.pdf|title=Fragmentation Considered Harmful}}</ref> Thus, senders typically use two approaches to decide the size of IP packets to send over the network. The first is for the sending host to send an IP packet of size equal to the MTU of the first hop of the source-destination pair. The second is to run the Path MTU Discovery algorithm<ref>{{citation |rfc=1191 |title=Path MTU Discovery |date=November 1990 |last1=Deering |first1=Steve E. |last2=Mogul |first2=Jeffrey }}</ref> to determine the path MTU between two IP hosts so that IP fragmentation can be avoided.

{{as of|2020}}, IP fragmentation is considered fragile and often undesired due to its security impact.<ref>{{cite IETF |rfc=8900 |title=IP Fragmentation Considered Fragile |date=September 2020}}</ref>

==See also==
* {{section link|IPv4|Fragmentation and reassembly}}
* {{section link|IPv6 packet|Fragmentation}}
* [[IP fragmentation attack]]
* [[Protocol data unit]] and [[Service data unit]]
* {{anl|Segmentation and reassembly}}

==References==
{{reflist}}

==External links==
* [http://www.tech-faq.com/packet-fragmentation.shtml What is packet fragmentation?]
* [http://learning.nil.com/tips-and-tricks/technical-articles/show/the-never-ending-story-of-ip-fragmentation/ The Never-Ending Story of IP Fragmentation]

{{DEFAULTSORT:Ip Fragmentation}}
[[Category:Internet Protocol]]