IP fragmentation

From Wikipedia, the free encyclopedia
Jump to: navigation, search

The Internet Protocol (IP) implements datagram fragmentation, breaking it into smaller pieces, so that packets may be formed that can pass through a link with a smaller maximum transmission unit (MTU) than the original datagram size.

RFC 791 describes the procedure for IP fragmentation, and transmission and reassembly of datagrams.[1] RFC 815 describes a simplified reassembly algorithm.[2]

The Identification field, and Fragment offset field along with Don't Fragment and More Fragment flags in the IP protocol header are used for fragmentation and reassembly of IP datagrams.

In a case where a router receives a protocol data unit (PDU) larger than the next hop's MTU, it has two options if the transport is IPv4: drop the PDU and send an Internet Control Message Protocol (ICMP) message which indicates the condition Packet too Big, or fragment the IP packet and send it over the link with a smaller MTU. IPv6 hosts are required to determine the optimal Path MTU before sending packets; however, it is guaranteed that any IPv6 packet smaller than or equal to 1280 bytes must be deliverable without the need to use IPv6 fragmentation.

If a receiving host receives a fragmented IP packet, it has to reassemble the datagram 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 re-assemble fragments in order to translate data streams, description provided in RFC 2993.[3]

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.[4] Thus, senders typically use two approaches to decide the size of IP datagrams to send over the network. The first is for the sending host to send an IP datagram 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,[5] described in RFC 1191, to determine the path MTU between two IP hosts, so that IP fragmentation can be avoided.

Impact of fragmentation on network forwarding[edit]

When a network has multiple parallel paths, technologies like LAG and CEF split traffic across the paths according to a hash algorithm. One goal of the algorithm is to ensure all packets of the same flow are sent out the same path to minimize unnecessary packet reordering. If the hash algorithm uses TCP/UDP port numbers, the packet fragments may be forwarded out different paths since only the first fragment has layer-4 information. This can lead to non-initial fragments arriving before the initial fragment, which some hosts and security devices treat as an error condition, and drop.[citation needed]

IPv4 and IPv6 differences[edit]

The details of the fragmentation mechanism, as well as the overall architectural approach to fragmentation, are different between IPv4, the first official version of the Internet Protocol, and IPv6, the newer version. In IPv4, routers perform fragmentation, whereas in IPv6, routers do not fragment, but drop the packets that are larger than the MTU. Though the header formats are different for IPv4 and IPv6, analogous fields are used for fragmentation, so the algorithm can be reused for fragmentation and reassembly.

In IPv4, hosts must make a best-effort attempt to reassemble fragmented IP datagrams with a total reassembled size of up to 576 bytes - equal to the minimum MTU for IPv4. They may also attempt to reassemble fragmented IP datagrams larger than 576 bytes, but they are also permitted to silently discard such larger datagrams. In IPv6, this minimum capability is increased to 1280 bytes,[6] larger than the minimum MTU for IPv4.

See also[edit]

References[edit]

  1. ^ RFC 791, Internet Protocol, Information Sciences Institute (September 1981)
  2. ^ RFC 815, IP Datagram Reassembly Algorithms, David D. Clark (July 1982)
  3. ^ RFC 2993, Architectural Implications of NAT (November 2000)
  4. ^ Christopher A. Kent, Jeffrey C. Mogul. "Fragmentation Considered Harmful". 
  5. ^ RFC 1191, Path MTU Discovery (November 1990)
  6. ^ RFC 2460, Internet Protocol, Version 6 (IPv6) Specification, S. Deering, R. Hinden (December 1998)

External links[edit]