Extended ICMP to Support Multi-Part Messages
RFC 4884
| Document | Type |
RFC - Proposed Standard
(April 2007; Errata)
Updated by RFC 8335
Was draft-bonica-internet-icmp (individual in int area)
|
|
|---|---|---|---|
| Authors | Ron Bonica , Der-Hwa Gan , Carlos Pignataro , Dan Tappan | ||
| Last updated | 2020-01-21 | ||
| Stream | Internent Engineering Task Force (IETF) | ||
| Formats | plain text html pdf htmlized (tools) htmlized with errata bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4884 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Jari Arkko | ||
| Send notices to | (None) | ||
Network Working Group R. Bonica
Request for Comments: 4884 Juniper Networks
Updates: 792, 4443 D. Gan
Category: Standards Track Consultant
D. Tappan
Consultant
C. Pignataro
Cisco Systems, Inc.
April 2007
Extended ICMP to Support Multi-Part Messages
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
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.
Bonica, et al. Standards Track [Page 1]
RFC 4884 Multi-Part ICMP Messages April 2007
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.
Table of Contents
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Summary of Changes to ICMP ......................................4
4. ICMP Extensibility ..............................................4
4.1. ICMPv4 Destination Unreachable .............................7
4.2. ICMPv4 Time Exceeded .......................................8
4.3. ICMPv4 Parameter Problem ...................................8
4.4. ICMPv6 Destination Unreachable .............................9
4.5. ICMPv6 Time Exceeded .......................................9
4.6. ICMP Messages That Can Be Extended ........................10
5. Backwards Compatibility ........................................10
5.1. Classic Application Receives ICMP Message with
Extensions ................................................12
5.2. Non-Compliant Application Receives ICMP Message
with No Extensions ........................................12
5.3. Non-Compliant Application Receives ICMP Message
with Compliant Extensions .................................13
5.4. Compliant Application Receives ICMP Message with
No Extensions .............................................14
5.5. Compliant Application Receives ICMP Message with
Non-Compliant Extensions ..................................14
6. Interaction with Network Address Translation ...................14
7. The ICMP Extension Structure ...................................15
8. ICMP Extension Objects .........................................16
9. Security Considerations ........................................16
10. IANA Considerations ...........................................17
11. Acknowledgments ...............................................17
12. References ....................................................17
12.1. Normative References .....................................17
12.2. Informative References ...................................17
Bonica, et al. Standards Track [Page 2]
Show full document text