Search RFCs

RFC Editor

File formats:

Status:

PROPOSED STANDARD

Updates:

RFC 792,RFC 4443

Updated by:

RFC 8335

Authors:

R. Bonica
D. Gan
D. Tappan
C. Pignataro

Stream:

IETF

Source:

NON WORKING GROUP

Cite this RFC:TXT  | XML  |  BibTeX

DOI:  https://doi.org/10.17487/RFC4884

Discuss this RFC: Send questions or comments to the mailing listiesg@ietf.org

Other actions:View Errata  | Submit Errata  | Find IPR Disclosures from the IETF  | View History of RFC 4884

Abstract

This document redefines selected ICMP messages to support multi-partoperation. A multi-part ICMP message carries all of the informationthat ICMP messages carried previously, as well as additionalinformation 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 extensionobjects. Each extension object contains an object header and objectpayload. All object headers share a common format.

This document further redefines the above mentioned ICMP messages byspecifying a length attribute. All of the currently defined ICMPmessages to which an extension structure can be appended include an"original datagram" field. The "original datagram" field containsthe initial octets of the datagram that elicited the ICMP errormessage. 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 documentallocates eight previously reserved bits to reflect the length of the"original datagram" field.

The proposed modifications change the requirements for ICMPcompliance. The impact of these changes on compliant implementationsis discussed, and new requirements for future implementations arepresented.

This memo updates RFC 792 and RFC 4443. [STANDARDS-TRACK]

For the definition ofStatus,seeRFC 2026.

For the definition ofStream, seeRFC 8729.