RFC 4884: Extended ICMP to Support Multi-Part Messages
In plain English — editorial summary, not part of the RFC
This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require. Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format. This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the "original datagram" field. The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented. This memo updates RFC 792 and RFC 4443. [STANDARDS-TRACK]
Document record
- Document ID
- RFC4884
- Published
- April 2007
- Authors
- R. Bonica; D. Gan; D. Tappan; C. Pignataro
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- —
- Pages
- 19
- Also known as
- —
- Updated by:
- RFC 8335
Topics
Referenced by
One later RFC formally updates or obsoletes part of this document.
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 4950ICMP Extensions for Multiprotocol Label SwitchingCurrent
August 2007
- RFC 5461TCP's Reaction to Soft ErrorsCurrent
February 2009
- RFC 5837Extending ICMP for Interface and Next-Hop IdentificationCurrent
April 2010
- RFC 2765Stateless IP/ICMP Translation Algorithm (SIIT)Obsoleted
February 2000
- RFC 2463Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) SpecificationObsoleted
December 1998
- RFC 2521ICMP Security Failures MessagesCurrent
March 1999
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?