IPv4 Reassembly Errors at High Data Rates
RFC 4963
| Document | Type |
RFC - Informational
(July 2007; No errata)
Was draft-heffner-frag-harmful (individual in tsv area)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4963 (Informational) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Lars Eggert | ||
| Send notices to | (None) | ||
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
Show full document text