RFC 6864: Updated Specification of the IPv4 ID Field
In plain English — editorial summary, not part of the RFC
The IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps for typical datagram sizes. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFCs 791, 1122, and 2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. [STANDARDS-TRACK]
Document record
- Document ID
- RFC6864
- Published
- February 2013
- Authors
- J. Touch
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- int
- Pages
- 19
- Also known as
- —
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 6874Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource IdentifiersObsoleted
February 2013
- RFC 6853DHCPv6 Redundancy Deployment ConsiderationsCurrent
February 2013
- RFC 6842Client Identifier Option in DHCP Server RepliesCurrent
January 2013
- RFC 6887Port Control Protocol (PCP)Updated
April 2013
- RFC 6840Clarifications and Implementation Notes for DNS Security (DNSSEC)Updated
February 2013
- RFC 6891Extension Mechanisms for DNS (EDNS(0))Current
April 2013
- RFC 6895Domain Name System (DNS) IANA ConsiderationsCurrent
April 2013
- RFC 6908Deployment Considerations for Dual-Stack LiteCurrent
March 2013
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?