[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 4884

Internet                                                       R. Bonica
Internet-Draft                                                    D. Gan
Expires: March 20, 2006                                 Juniper Networks
                                                             P. Nikander
                                           Ericsson Research Nomadic Lab
                                                               D. Tappan
                                                     Cisco Systems, Inc.
                                                      September 16, 2005


         Extending the Internet Control Message Protocol (ICMP)
                     draft-bonica-internet-icmp-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 20, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines a syntax that can be used to extend ICMPv4.
   The syntax is characterized by an extension structure that is
   appended to currently defined ICMP messages.  The extension structure
   contains an extension header followed by one or more objects.  Each



Bonica, et al.           Expires March 20, 2006                 [Page 1]

Internet-Draft               Extending ICMP               September 2005


   object contains an object header and a payload.  All object headers
   share a common format.


Table of Contents

   1.  Conventions Used In This Document  . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  The ICMP Extension Structure . . . . . . . . . . . . . . . . .  4
   4.  ICMP Extension Objects . . . . . . . . . . . . . . . . . . . .  5
   5.  ICMP Extensibility . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  Destination Unreachable  . . . . . . . . . . . . . . . . .  8
     5.2.  Source Quench  . . . . . . . . . . . . . . . . . . . . . .  8
     5.3.  Time Exceeded  . . . . . . . . . . . . . . . . . . . . . .  9
     5.4.  Parameter Problem  . . . . . . . . . . . . . . . . . . . . 10
   6.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . . 10
     6.1.  Classic Application Receives ICMP Message With
           Extensions . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.2.  Partially Compliant Application Receives ICMP Message
           With No Extensions . . . . . . . . . . . . . . . . . . . . 12
     6.3.  Partially Compliant Application Receives ICMP Message
           With Fully Compliant Extensions  . . . . . . . . . . . . . 12
     6.4.  Fully Compliant Application Receives ICMP Message With
           No Extensions  . . . . . . . . . . . . . . . . . . . . . . 13
     6.5.  Fully Compliant Application Receives ICMP Message With
           Partially Compliant Extensions . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16


















Bonica, et al.           Expires March 20, 2006                 [Page 2]

Internet-Draft               Extending ICMP               September 2005


1.   Conventions Used In This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [1].


2.  Introduction

   This document defines a syntax that can be used to extend ICMPv4 [2].
   In this document, the term ICMP refers exclusively to ICMPv4.  Unless
   explicitly noted, ICMPv6 is NOT discussed in this memo.

   The syntax defined in this document MUST NOT be used to extend
   ICMPv6.  This syntax was designed to be backwards compatible with
   currently deployed, MPLS-aware ICMPv4 implementations.  Consequently,
   the syntax is not as clean as would be desirable.  For ICMPv6, where
   there are no similarly deployed implementations, a better format
   should be created.  However, other than this note, ICMPv6 is beyond
   the scope if this memo.

   The syntax defined herein is characterized by an extension structure
   that is appended to currently defined ICMP messages.  The extension
   structure contains an extension header followed by one or more
   objects.  Each object contains an object header and a payload.  All
   object headers share a common format.

   This document also addresses a fundamental problem in ICMP
   extensibility.  Many ICMP messages, as currently defined, end with a
   variable-length field that lacks a length attribute.  Application
   software infers the length of this final field from the total length
   of the ICMP message.  If an extension structure were appended to
   these messages, without adding a length attribute for the variable-
   length field, application software would not be able to parse the
   ICMP message.  Specifically, application software would not be able
   to determine where the variable-length field ends and where the
   extension structure begins.

   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 draft addresses backwards
   compatibility with certain, widely deployed, MPLS-aware ICMP
   implementations that send the extensions defined herein without
   adding the required length attribute.

   However, the current memo does not define any ICMP extension objects.
   It defines only the extension header and a common header that all



Bonica, et al.           Expires March 20, 2006                 [Page 3]

Internet-Draft               Extending ICMP               September 2005


   objects will share.


3.  The ICMP Extension Structure

   This memo proposes an optional ICMP Extension Structure that can be
   appended to any ICMP message, except for those that are disqualified
   by Section 5 of this document.

   The Extension Structure contains exactly one Extension Header
   followed by one or more objects.  Having received an ICMP message
   with extensions, application software MAY process selected objects
   while ignoring others.  The presence of an unknown object does not
   imply that an ICMP message is malformed.

   As stated in RFC 792, the total length of the ICMP message, including
   extensions, MUST NOT exceed 576 octets.  Figure 1 depicts the ICMP
   Extension Header.



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version|      (Reserved)       |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1: ICMP Extension Header

   The fields of the ICMP Extension Header are as follows:

   Version: 4 bits

      ICMP extension version number.  This is version 2.

   Reserved: 12 bits

      Must be set to 0.

   Checksum: 16 bits

      The one's complement of the one's complement sum of the data
      structure, with the checksum field replaced by zero for the
      purpose of computing the checksum.  An all-zero value means that
      no checksum was transmitted.






Bonica, et al.           Expires March 20, 2006                 [Page 4]

Internet-Draft               Extending ICMP               September 2005


      If the checksum field contains a value other than described above,
      the ICMP message does not include the extensions described in this
      memo.  However, due to backwards compatibility, this does not
      imply that the ICMP message is malformed.  See for Section 6
      details.


4.  ICMP Extension Objects

   Each extension object contains one or more 32-bit words, representing
   an object header and payload.  All object headers share a common
   format.  Figure 2 depicts the Object Header and payload.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Length            |   Class-Num   |   C-Type      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                   // (Object payload) //                      |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: Object Header and Payload

   An object header has the following fields:

   Length: 16 bits

      Length of the object, measured in octets, including the object
      header and object payload.

   Class-Num: 8 bits

      Identifies object class.

   C-Type: 8 bits

      Identifies object sub-type.


5.  ICMP Extensibility

   RFC 792 defines the following ICMP message types:






Bonica, et al.           Expires March 20, 2006                 [Page 5]

Internet-Draft               Extending ICMP               September 2005


      - Destination Unreachable

      - Time Exceeded

      - Parameter Problem

      - Source Quench

      - Redirect

      - Echo Request/Reply

      - Timestamp/Timestamp Reply

      - Information Request/Information Reply

   Subsequent RFCs define the following messages:

      - Address Mask Request/Reply [4]

      - Router Solicitation/Advertisement [5]

      - Traceroute [6]

      - Domain Name Request/Reply [7]

      - Security Failure [8]

   Most ICMP messages are extensible as currently defined.  Protocol
   designers can extend ICMP messages by simply appending fields or data
   structures to them.

   The following ICMP messages are not extensible as currently defined:

      - Destination Unreachable

      - Source Quench

      - Time Exceeded

      - Parameter Problem

      - Redirect

      - Echo Request






Bonica, et al.           Expires March 20, 2006                 [Page 6]

Internet-Draft               Extending ICMP               September 2005


      - Echo Reply

      - Domain Name Reply

   These ICMP messages contain a field which represents a portion of the
   original datagram to which the ICMP messages is a response.  As
   originally defined, this field includes the IP header plus leading
   eight payload octets of the original datagram.  RFC 1812 [3] extends
   this field to contain as many payload octets as possible, without
   exceeding a limit of 576 octets for the entire ICMP message.

   Unfortunately, the above mentioned field lacks a length attribute.
   Application software infers the length of this field from the total
   length of the ICMP message.  If an extension structure were appended
   to the ICMP message, without adding a length attribute for the
   variable-length field, application software would not be able to
   parse the ICMP message.  Specifically, application software would not
   be able to determine where the variable-length field ends and where
   the extension structure begins.

   In order to solve this problem, this memo introduces an 8-bit length
   attribute to the following ICMP messages.

      - Destination Unreachable

      - Source Quench

      - Time Exceeded

      - Parameter Problem

   The length attribute MUST be specified when the ICMP Extension
   Structure is appended to the above mentioned ICMP messages.  It
   SHOULD be specified when the ICMP Extension Structure is not appended
   to the above mentioned ICMP messages.

   The length attribute represents the size of the associated variable-
   length field, measured in octets.  Space for this field is claimed
   from reserved octets, whose value was previously required to be zero.
   When this length attribute is specified, its value MUST be a multiple
   of four.

   In order the achieve backwards compatibility, when the ICMP Extension
   Structure is appended to the Time Exceeded or Destination Unreachable
   messages, the variable length field MUST contain at least 128 octets.
   If the orignal datagram that the variable length field represents did
   not contain 128 octets, the variable length field MUST be zero
   padded.  (See Section 6 for rationale.)



Bonica, et al.           Expires March 20, 2006                 [Page 7]

Internet-Draft               Extending ICMP               September 2005


   Due to a lack of reserved octets from which to allocate space, a
   length attribute could not be added to the following ICMP messages:

      - Redirect

      - Echo Request

      - Echo Reply

      - Domain Name Reply

   Therefore, the ICMP Extension Structure described in this memo cannot
   be used in conjunction with the above mentioned ICMP messages.

   The following sub-sections depict length attribute as it has been
   introduced to selected ICMP messages.

5.1.  Destination Unreachable

   Figure 3 depicts the Destination Unreachable Message.



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      unused                   |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Internet Header + leading octets of original datagram    |
      |                                                               |
      |                           //                                  |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3: Destination Unreachable

   The syntax and semantics of all fields are unchanged from RFC 792,
   except for a length attribute which is added to the end of the second
   word.

   When the ICMP Extension Structure is appended to this message, the
   "original datagram" field MUST contain at least 128 octets.

5.2.  Source Quench

   Figure 4 depicts the Source Quench Message.



Bonica, et al.           Expires March 20, 2006                 [Page 8]

Internet-Draft               Extending ICMP               September 2005


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      unused                   |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Internet Header + leading octets of original datagram    |
      |                                                               |
      |                           //                                  |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 4: Source Quench

   The syntax and semantics of all fields are unchanged from RFC 792,
   except for a length attribute which is added to the end of the second
   word.

5.3.  Time Exceeded

   Figure 5 depicts the Time Exceeded Message.



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      unused                   |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Internet Header + leading octets of original datagram    |
      |                                                               |
      |                           //                                  |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 5: Source Time Exceeded

   The syntax and semantics of all fields are unchanged from RFC 792,
   except for a length attribute which is added to the end of the second
   word.

   When the ICMP Extension Structure is appended to this message, the
   "original datagram" field MUST contain at least 128 octets.





Bonica, et al.           Expires March 20, 2006                 [Page 9]

Internet-Draft               Extending ICMP               September 2005


5.4.  Parameter Problem

   Figure 6 depicts the Parameter Problem Message.



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Pointer    |            unused             |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Internet Header + leading octets of original datagram    |
      |                                                               |
      |                           //                                  |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 6: Parameter Problem

   The syntax and semantics of all fields are unchanged from RFC 792,
   except for a length attribute which is added to the end of the second
   word.


6.  Backwards Compatibility

   ICMP messages can be categorized as follows:

      - Messages that do not include any ICMP extensions

      - Messages that include partially compliant ICMP extensions

      - Messages that includes fully compliant ICMP extensions

   Any ICMP implementation can send a message that does not include
   extensions.  ICMP implementations produced prior to 1999 never send
   ICMP extensions.

   Some ICMP implementations, produced between 1999 and the present, may
   send a partially compliant version of ICMP extensions described in
   this memo.  Specifically, these implementations may append the ICMP
   Extension Structure to the Time Exceeded and Destination Unreachable
   messages.  When they do this, they send exactly 128 octets
   representing the original datagram, zero padding if required.  They
   do not specify a length attribute to be associated with the "original
   datagram" field.



Bonica, et al.           Expires March 20, 2006                [Page 10]

Internet-Draft               Extending ICMP               September 2005


   It is assumed that ICMP implementations produced in the future will
   send ICMP extensions that are fully compliant with this
   specification.

   Likewise, applications that consume ICMP messages can be categorized
   as follows:

      - Classic applications

      - Partially compliant applications

      - Fully compliant applications

   Classic applications do not parse extensions defined in this memo.
   Partially compliant implementations parse the extensions defined in
   this memo, but only in conjuntion with the Time Expired and
   Destination Unreachable messages.  They require the "original
   datagram" field to contain exactly 128 octets and are insensitive to
   the length attribute that is associated with that field.  Partially
   compliant applications were produced between 1999 and the present.

   Fully compliant applications comply fully with the specifications of
   this document.

   In order to demonstrate backwards compatibility, Table 1 describes
   how members of each application catagory would parse each category of
   ICMP message.

   +-------------------+-------------+------------------+----------------+
   |                   |      No     |     Partially    |      Fully     |
   |                   |  Extentions |     Compliant    |    Compliant   |
   |                   |             |    Extensions    |   Extensions   |
   +-------------------+-------------+------------------+----------------+
   | Classic           |             |    Section 6.1   |   Section 6.1  |
   | Application       |             |                  |                |
   | .                 |             |                  |                |
   | Partially         | Section 6.2 |                  |   Section 6.3  |
   | Compliant         |             |                  |                |
   | Application       |             |                  |                |
   | .                 |             |                  |                |
   | Fully Compliant   | Section 6.4 |    Section 6.5   |                |
   | Application       |             |                  |                |
   +-------------------+-------------+------------------+----------------+

                                  Table 1

   In the table above, cells that are left blank represent the nominal
   case and require no explanation.  In the following sections, we



Bonica, et al.           Expires March 20, 2006                [Page 11]

Internet-Draft               Extending ICMP               September 2005


   assume that the ICMP message type is "Time Expired".

6.1.  Classic Application Receives ICMP Message With Extensions

   When a classic application receives an ICMP message that includes
   extensions, it will incorrectly interpret those extensions as being
   part of the "original datagram" field.  Fortunately, the extensions
   are guaranteed to begin at least 128 octets beyond the begining of
   the "original datagram" field.  So, only those ICMP applications that
   process the 129th octet of the "original datagram" field will be
   adversely effected.  To date, no such applications have been
   identified.

6.2.  Partially Compliant Application Receives ICMP Message With No
      Extensions

   When a partially compliant application receives a message that
   contains no extensions, the application examines the total length of
   the ICMP message.  If the total ICMP message length is less than 164
   octets, the application can correctly determine that the message does
   not contain any extensions.

   The 164 octet sum is derived from 20 octets for an IP header, 8
   octets for the first two words of the ICMP Time Exceeded message, 128
   octets for the "original datagram" field, 4 octets for the ICMP
   Extension Header and 4 octets for a single ICMP Object header.  All
   of these octets would be required if extensions were present.

   If the ICMP message contains 164 octets or more, the application must
   examine the 157th octet to determine whether it represents a valid
   ICMP Extension Header.  In order to represent a valid Extension
   Header, it must contain a valid version number and checksum.  If it
   does not contain a valid version number and checksum, the application
   correctly determines that the message does not contain any
   extensions.

   Partially compliant applications assume that the ICMP Extension
   Structure begins on the 157th octet of the Time Exceeded message,
   after a 128 octet field representing the "original datagram" message.

6.3.  Partially Compliant Application Receives ICMP Message With Fully
      Compliant Extensions

   When a partially compliant application receives a message that
   contains fully compliant ICMP extensions, it will parse those
   extensions correctly only if the "original datagram" field contains
   exactly 128 octets.  This is because partially compliant applications
   are insensative to the length attribute that is associated with the



Bonica, et al.           Expires March 20, 2006                [Page 12]

Internet-Draft               Extending ICMP               September 2005


   "original datagram" field.  (They assume its value to be 128.)

   Therefore, fully compliant ICMP implementations SHOULD restrict the
   "original datagram" field to its minimum length, 128 octets, for the
   forseeable future, until partially compliant applications have been
   removed from service.

6.4.  Fully Compliant Application Receives ICMP Message With No
      Extensions

   When a fully compliant application receives a message that contains
   no extensions, it first examines the length attribute that is
   associated with the "original datagram" field.  If that length
   attribute is not specified, the application examines the total length
   of the ICMP message.  If the total ICMP message length is less than
   164 octets, the application can correctly determine that the message
   does not contain any extensions.

   The 164 octet sum is derived from 20 octets for an IP header, 8
   octets for the first two words of the ICMP Time Exceeded message, 128
   octets for the "original datagram" field, 4 octets for the ICMP
   Extension Header and 4 octets for a single ICMP Object header.  All
   of these octets would be required if extensions were present.

   If the ICMP message contains 164 octets or more, the application must
   examine the 157th octet to determine whether it represents a valid
   ICMP Extension Header.  In order to represent a valid Extension
   Header, it must contain a valid version number and checksum.  If it
   does not contain a valid version number and checksum, the application
   correctly determines that the message does not contain any
   extensions.

6.5.  Fully Compliant Application Receives ICMP Message With Partially
      Compliant Extensions

   When a fully compliant application receives a message that contains
   partially compliant extensions, it first examines the length
   attribute that is associated with the "original datagram" field.
   Because length attribute is not specified, it examines the total
   length of the ICMP message.

   Because the ICMP message contains 164 octets or more, the application
   must examine the 157th octet to determine whether it represents a
   valid ICMP Extension Header.  In order to represent a valid Extension
   Header, it must contain a valid version number and checksum.  If it
   does not contain a valid version number and checksum, the application
   correctly determines that the message does not contain any
   extensions.



Bonica, et al.           Expires March 20, 2006                [Page 13]

Internet-Draft               Extending ICMP               September 2005


7.  Security Considerations

   Upon receipt of an ICMP message, application software must check it
   for syntactic correctness.  Improperly specified length attributes
   and other syntax problems may result in buffer overruns.

   This memo does not define the conditions under which a router sends
   an ICMP message.  Therefore, it does not expose routers to any new
   denial of service attacks.


8.  IANA Considerations

   IANA should establish a registry of ICMP extention classes and class-
   sub-types.


9.  References

9.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
        September 1981.

   [3]  Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
        June 1995.

9.2.  Informative References

   [4]  Mogul, J. and J. Postel, "Internet Standard Subnetting
        Procedure", STD 5, RFC 950, August 1985.

   [5]  Deering, S., "ICMP Router Discovery Messages", RFC 1256,
        September 1991.

   [6]  Malkin, G., "Traceroute Using an IP Option", RFC 1393,
        January 1993.

   [7]  Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995.

   [8]  Karn, P. and W. Simpson, "ICMP Security Failures Messages",
        RFC 2521, March 1999.






Bonica, et al.           Expires March 20, 2006                [Page 14]

Internet-Draft               Extending ICMP               September 2005


Authors' Addresses

   Ronald P. Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, VA  20171
   US

   Email: rbonica@juniper.net


   Der-Hwa Gan
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   Email: dhg@juniper.net


   Pekka Nikander
   Ericsson Research Nomadic Lab
   JORVAS  FIN-02420
   Finland

   Email: pekka.nikander@nomadiclab.com


   Daniel C. Tappan
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA  01824
   US

   Email: tappan@cisco.com
















Bonica, et al.           Expires March 20, 2006                [Page 15]

Internet-Draft               Extending ICMP               September 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Bonica, et al.           Expires March 20, 2006                [Page 16]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/