1. Introduction

   This document redefines selected ICMPv4 [RFC0792] and ICMPv6
   [RFC4443] messages to include an extension structure and a length
   attribute.  The extension structure supports multi-part ICMP
   operation.  Protocol designers can make an ICMP message carry
   additional information by encoding that information in the extension
   structure.

   This document also addresses a fundamental problem in ICMP
   extensibility.  All of the ICMP messages addressed by this memo
   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.

   Application software infers the length of the "original datagram"
   field from the total length of the ICMP message.  If an extension
   structure were appended to the message without adding a length
   attribute for the "original datagram" field, the message would become
   unparsable.  Specifically, application software would not be able to
   determine where the "original datagram" field ends and where the
   extension structure begins.  Therefore, this document proposes a
   length attribute as well as an extension structure that is appended
   to the ICMP message.

   The current memo also addresses backwards compatibility with existing
   ICMP implementations that either do not implement the extensions
   defined herein or implement them without adding the required length
   attributes.  In particular, this document addresses backwards
   compatibility with certain, widely deployed, MPLS-aware ICMPv4
   implementations that send the extensions defined herein without
   adding the required length attribute.

   The current memo does not define any ICMP extension objects.  It
   defines only the extension header and a common header that all
   extension objects share.  [UNNUMBERED], [ROUTING-INST], and
   [MPLS-ICMP] provide sample applications of the ICMP Extension Object.

   The above mentioned memos share a common characteristic.  They all
   append information to the ICMP Time Expired message for consumption
   by TRACEROUTE.  In this case, as in many others, appending
   information to the existing ICMP Time Expired Message is preferable
   to defining a new message and emitting two messages whenever a packet
   is dropped due to TTL expiration.