Extended ICMP to Support Multi-Part Messages
RFC 4884

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 16

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]