IPv4 Reassembly Errors at High Data Rates
RFC 4963

Network Working Group                                         J. Heffner
Request for Comments: 4963                                     M. Mathis
Category: Informational                                      B. Chandler
                                                                     PSC
                                                               July 2007

               IPv4 Reassembly Errors at High Data Rates

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   IPv4 fragmentation is not sufficiently robust for use under some
   conditions in today's Internet.  At high data rates, the 16-bit IP
   identification field is not large enough to prevent frequent
   incorrectly assembled IP fragments, and the TCP and UDP checksums are
   insufficient to prevent the resulting corrupted datagrams from being
   delivered to higher protocol layers.  This note describes some easily
   reproduced experiments demonstrating the problem, and discusses some
   of the operational implications of these observations.

Heffner, et al.              Informational                      [Page 1]
RFC 4963       IPv4 Reassembly Errors at High Data Rates       July 2007

1.  Introduction

   The IPv4 header was designed at a time when data rates were several
   orders of magnitude lower than those achievable today.  This document
   describes a consequent scale-related failure in the IP identification
   (ID) field, where fragments may be incorrectly assembled at a rate
   high enough that it is likely to invalidate assumptions about data
   integrity failure rates.

   That IP fragmentation results in inefficient use of the network has
   been well documented [Kent87].  This note presents a different kind
   of problem, which can result not only in significant performance
   degradation, but also frequent data corruption.  This is especially
   pertinent due to the recent proliferation of UDP bulk transport tools
   that sometimes fragment every datagram.

   Additionally, there is some network equipment that ignores the Don't
   Fragment (DF) bit in the IP header to work around MTU discovery
   problems [RFC2923].  This equipment indirectly exposes properly
   implemented protocols and applications to corrupt data.

2.  Wrapping the IP ID Field

   The Internet Protocol standard [RFC0791] specifies:

      "The choice of the Identifier for a datagram is based on the need
      to provide a way to uniquely identify the fragments of a
      particular datagram.  The protocol module assembling fragments
      judges fragments to belong to the same datagram if they have the
      same source, destination, protocol, and Identifier.  Thus, the
      sender must choose the Identifier to be unique for this source,
      destination pair and protocol for the time the datagram (or any
      fragment of it) could be alive in the Internet."

   Strict conformance to this standard limits transmissions in one
   direction between any address pair to no more than 65536 packets per
   protocol (e.g., TCP, UDP, or ICMP) per maximum packet lifetime.

   Clearly, not all hosts follow this standard because it implies an
   unreasonably low maximum data rate.  For example, a host sending
   1500-byte packets with a 30-second maximum packet lifetime could send
   at only about 26 Mbps before exceeding 65535 packets per packet
   lifetime.  Or, filling a 1 Gbps interface with 1500-byte packets
   requires sending 65536 packets in less than 1 second, an unreasonably
   short maximum packet lifetime, being less than the round-trip time on
   some paths.  This requirement is widely ignored.

Heffner, et al.              Informational                      [Page 2]
RFC 4963       IPv4 Reassembly Errors at High Data Rates       July 2007

   Additionally, it is worth noting that reusing values in the IP ID
   field once per 65536 datagrams is the best case.  Some
   implementations randomize the IP ID to prevent leaking information
   out of the kernel [Bellovin02], which causes reuse of the IP ID field
   to occur probabilistically at all sending rates.

   IP receivers store fragments in a reassembly buffer until all
   fragments in a datagram arrive, or until the reassembly timeout
   expires (15 seconds is suggested in [RFC0791]).  Fragments in a
   datagram are associated with each other by their protocol number, the
   value in their ID field, and by the source/destination address pair.
   If a sender wraps the ID field in less than the reassembly timeout,
   it becomes possible for fragments from different datagrams to be