Subject: [Int-area] draft-bonica-internet-icmp-02

From: Ron Bonica <[email-masked]>
Date: Thu, 16 Mar 2006 09:56:57 -0500

Folks,

An updated version of draft-bonica-internet-icmp is attached. I
apologize for not getting it out sooner.

I believe that this version addresses the issues that Joe raised on the
mailing list earlier.

                                 Ron

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

 Redefining Selected ICMP Messages To Include a Length Attribute and an
                          Extension Structure
                     draft-bonica-internet-icmp-02

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 September 17, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document redefines selected ICMPv4 messages to include an
   extension structure.  The extension structure is situated at the end

Bonica, et al.         Expires September 17, 2006               [Page 1]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

   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 a subset of those ICMP messages by
   specifying a length attribute.  Many of the ICMP messages to which an
   extension structure can be appended include and "original datagram"
   field.  The "original datagram" field contains the initial octets of
   the datagram to which the ICMP message is a response.  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 draft allocates eight previously
   reserved bits to reflect the length of the "original datagram" field.

   Finally, this document addresses backwards compatibility issues.

Table of Contents

   1.  Conventions Used In This Document  . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  ICMP Extensibility . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Destination Unreachable  . . . . . . . . . . . . . . . . .  6
     3.2.  Source Quench  . . . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Time Exceeded  . . . . . . . . . . . . . . . . . . . . . .  7
     3.4.  Parameter Problem  . . . . . . . . . . . . . . . . . . . .  8
     3.5.  ICMP Messages That Cannot Be Extended  . . . . . . . . . .  8
   4.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . .  9
     4.1.  Classic Application Receives ICMP Message With
           Extensions . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.2.  Partially Compliant Application Receives ICMP Message
           With No Extensions . . . . . . . . . . . . . . . . . . . . 11
     4.3.  Partially Compliant Application Receives ICMP Message
           With Fully Compliant Extensions  . . . . . . . . . . . . . 11
     4.4.  Fully Compliant Application Receives ICMP Message with
           No Extensions  . . . . . . . . . . . . . . . . . . . . . . 12
     4.5.  Fully Compliant Application Receives ICMP Message with
           Partially Compliant Extensions . . . . . . . . . . . . . . 12
   5.  The ICMP Extension Structure . . . . . . . . . . . . . . . . . 12
   6.  ICMP Extension Objects . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17

Bonica, et al.         Expires September 17, 2006               [Page 2]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

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 redefines selected ICMPv4 [2] messages to include an
   extension structure and a length attribute.  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 of this memo.

   This document addresses a fundamental problem in ICMP extensibility.
   Many of the ICMP messages addressed by this memo include an "original
   datagram" field.  The "original datagram" field contains the initial
   octets of the datagram to which the ICMP message is a response.
   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 draft addresses backwards
   compatibility with certain, widely deployed, MPLS-aware ICMP
   implementations that send the extensions defined herein without
   adding the required length attribute.

   The current memo does not define any ICMP extension objects.  It

Bonica, et al.         Expires September 17, 2006               [Page 3]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

   defines only the extension header and a common header that all
   objects share.

3.  ICMP Extensibility

   RFC 792 defines the following ICMP message types:

      - Destination Unreachable

      - Time Exceeded

      - Parameter Problem

      - Source Quench

      - Redirect

      - Echo Request/Reply

      - Timestamp/Timestamp Reply

      - Information Request/Information Reply

   RFC 1191 [3] adds a "Next-Hop MTU" field to the Destination
   Unreachable message.  Subsequent RFCs define the following messages:

      - Address Mask Request/Reply [5]

      - Router Solicitation/Advertisement [6]

      - Traceroute [7]

      - Domain Name Request/Reply [8]

      - Security Failure [9]

      - Experimental Mobility [10]

   Many 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:

Bonica, et al.         Expires September 17, 2006               [Page 4]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

      - Destination Unreachable

      - Source Quench

      - Time Exceeded

      - Parameter Problem

      - Redirect

      - Echo Request

      - Echo Reply

      - Domain Name Reply

   These ICMP messages contain an "original datagram" 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 the next eight octets of the original datagram.
   RFC 1812 [4] extends this field to contain as many octets as
   possible, without exceeding a limit of 576 octets for the entire ICMP
   message.

   Unfortunately, the "original datagram" 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 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.

   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 also
   MUST be specified when the original datagram field includes 128
   octets or more.  It MAY be specified in any other cases.

Bonica, et al.         Expires September 17, 2006               [Page 5]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

   The length attribute represents the length of the "original datagram"
   field, measured in 32-bit words.  When the length attribute is
   specified, the "original datagram" field MUST be zero padded to the
   nearest 32-bit boundary.  Space for the length attribute is claimed
   from reserved octets, whose value was previously required to be zero.

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

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

3.1.  Destination Unreachable

   Figure 1 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     |         Next-Hop MTU          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Internet Header + leading octets of original datagram    |
      |                                                               |
      |                           //                                  |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1: Destination Unreachable

   The syntax and semantics of all fields are unchanged from RFC 792 and
   RFC 1191.  However, a length attribute is added to the second word.
   The length attribute represents length of the padded "original
   datagram" field, measured in 32-bit words.

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

Bonica, et al.         Expires September 17, 2006               [Page 6]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

3.2.  Source Quench

   Figure 2 depicts the Source Quench 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     |         unused                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Internet Header + leading octets of original datagram    |
      |                                                               |
      |                           //                                  |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: Source Quench

   The syntax and semantics of all fields are unchanged from RFC 792,
   except for a length attribute which is added to the second word.  The
   length attribute represents length of the padded "original datagram"
   field, measured in 32-bit words.

3.3.  Time Exceeded

   Figure 3 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     |          unused               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Internet Header + leading octets of original datagram    |
      |                                                               |
      |                           //                                  |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3: Time Exceeded

   The syntax and semantics of all fields are unchanged from RFC 792,

Bonica, et al.         Expires September 17, 2006               [Page 7]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

   except for a length attribute which is added to the second word.  The
   length attribute represents length of the padded "original datagram"
   field, measured in 32-bit words.

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

3.4.  Parameter Problem

   Figure 4 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    |    Length     |          unused               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Internet Header + leading octets of original datagram    |
      |                                                               |
      |                           //                                  |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 4: Parameter Problem

   The syntax and semantics of all fields are unchanged from RFC 792,
   except for a length attribute which is added to the second word.  The
   length attribute represents length of the padded "original datagram"
   field, measured in 32-bit words.

3.5.  ICMP Messages That Cannot Be Extended

   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

Bonica, et al.         Expires September 17, 2006               [Page 8]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

      - Domain Name Reply

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

4.  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.
   However, they do not specify a length attribute to be associated with
   the "original datagram" field.

   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.
   They are insensitive to the length attribute that is associated with
   the "original datagram" field.

   Partially compliant implementations parse the extensions defined in
   this memo, but only in conjunction with the Time Expired and

Bonica, et al.         Expires September 17, 2006               [Page 9]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

   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 the "original datagram"
   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 category would parse each category of
   ICMP message.

   +----------------+----------------+----------------+----------------+
   |                |  No Extensions |    Partially   |      Fully     |
   |                |                |    Compliant   |    Compliant   |
   |                |                |   Extensions   |   Extensions   |
   +----------------+----------------+----------------+----------------+
   | Classic        |        -       |   Section 4.1  |   Section 4.1  |
   | Application    |                |                |                |
   |                |                |                |                |
   | Partially      |   Section 4.2  |        -       |   Section 4.3  |
   | Compliant      |                |                |                |
   | Application    |                |                |                |
   |                |                |                |                |
   | Fully          |   Section 4.4  |   Section 4.5  |        -       |
   | Compliant      |                |                |                |
   | Application    |                |                |                |
   +----------------+----------------+----------------+----------------+

                                  Table 1

   In the table above, cells that contain a dash represent the nominal
   case and require no explanation.  In the following sections, we
   assume that the ICMP message type is "Time Exceeded".

4.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 beginning 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.

Bonica, et al.         Expires September 17, 2006              [Page 10]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

4.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 the
   length of its IP header plus 144 octets, the application correctly
   determines that the message does not contain any extensions.

   The 144 octet sum is derived from 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 payload contains 144 octets or more, the application must
   examine the 137th 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 137th octet of the Time Exceeded message,
   after a 128 octet field representing the padded "original datagram"
   message.

   It is possible that a partially compliant application will parse an
   ICMP message incorrectly under the following conditions:

      - the message does not contain extensions

      - the original datagram field contains 144 octets or more

      - selected octets of the original datagram field represent the
      correct values for an extension header version number and checksum

   Although this is possible, it is very unlikely.

4.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 insensitive to the length attribute that is associated with the

Bonica, et al.         Expires September 17, 2006              [Page 11]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

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

   Therefore, when fully compliant ICMP implementations append
   extensions to the ICMP Destination Unreachable and Time Expired
   Messages, they SHOULD restrict the "original datagram" field to its
   minimum length, 128 octets.

4.4.  Fully Compliant Application Receives ICMP Message with No
      Extensions

   When a fully compliant application receives an ICMP message, it
   examines the length attribute that is associated with the "original
   datagram" field.  If the length attribute is not specified, the fully
   compliant application MUST determine that the message contains no
   extensions.

4.5.  Fully Compliant Application Receives ICMP Message with Partially
      Compliant Extensions

   When a fully compliant application receives an ICMP message, it
   examines the length attribute that is associated with the "original
   datagram" field.  If the length attribute is not specified, the fully
   compliant application MUST determine that the message contains no
   extensions.  In this case, that determination will be incorrect
   because the partially compliant ICMP message contains extensions but
   does not specify a length attribute.

   For this reason, vendors may choose to implement TRACEROUTE in a
   manner that is not fully compliant.  Specifically, when TRACEROUTE
   receives an ICMP message that contains 144 octets or more in its
   payload and does not specify a length attribute, it will parse for a
   valid extension header beginning at octet 137.  If the application
   detects a valid version and checksum, it will treat the following
   octets as an extension structure.

   Vendors should limit the practice of deploying non-compliant
   applications to TRACEROUTE.

5.  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
   in Section 3.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

Bonica, et al.         Expires September 17, 2006              [Page 12]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

   while ignoring others.  The presence of an unrecognized 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 5 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 5: 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.

      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 4
      details.

6.  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 6 depicts the Object Header and payload.

Bonica, et al.         Expires September 17, 2006              [Page 13]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

       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 6: 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.

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

   The ICMP Extension Object header contains two 8-bit fields: The
   Class-Num identifies the object class, and the C-Type identifies the
   class sub-type.  Sub-type values are defined relative to a specific
   object class value, and are defined per-class.

   IANA should establish a registry of ICMP extension objects classes
   and class sub-types.  There are no values assigned within this

Bonica, et al.         Expires September 17, 2006              [Page 14]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

   document to maintain.  Object classes 0xF7 - 0xFF are reserved for
   private use.  Object class values are assignable on a first-come-
   first-serve.  The policy for assigning sub-type values should be
   defined in the document defining new class values.

9.  Acknowledgments

   Thanks to Joe Touch for his comments regarding this draft.

10.  References

10.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]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
        November 1990.

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

10.2.  Informative References

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

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

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

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

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

   [10]  Kempf, J., "Instructions for Seamoby and Experimental Mobility
         Protocol IANA Allocations", RFC 4065, July 2005.

Bonica, et al.         Expires September 17, 2006              [Page 15]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

Authors' Addresses

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

   Email: [email-masked]

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

   Email: [email-masked]

   Pekka Nikander
   Ericsson Research Nomadic Lab
   JORVAS  FIN-02420
   Finland

   Email: [email-masked]

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

   Email: [email-masked]

   Carlos Pignataro
   Cisco Systems, Inc.
   7025 Kit Creek Road
   Research Triangle Park, N.C.  27709
   US

   Email: [email-masked]

Bonica, et al.         Expires September 17, 2006              [Page 16]

Internet-Draft      Redefining Selected ICMP Messages         March 2006

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
   [email-masked].

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 (2006).  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 September 17, 2006              [Page 17]


_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Mar 2006 12:38:13 -0800

> I believe that this version addresses the issues that Joe raised on the

Due to some spectacular scheduling of WG meetings for Dallas, I will not
be able to attend the INT area meeting

There are two drafts for which I had wanted to participate in
discussion, so I'll post my notes here in advance of the meeting. I hope
I am not preempting any of the discussion that might occur in the room,
but this seems more productive than commenting post-facto.  I'll be glad
to discuss this further on the mailing list (except in realtime during
the WG meeting). I may try to be on Jabber, but it's unlikely I will be
able to participate substantively there.

This note addresses draft-bonica-internet-icmp-02 (the recently posted
update).

I had reviewed a previous (00 and 01) versions of this document and
provided feedback to Ron. My general impression:

- this document makes a change to ICMP processing that is NOT backward
compatible with the current standard; as a result, this document must
end up in the standards track or experimental with substantial warnings
(I'm not sure if that hum will come up)

- I generally agree with the changes being proposed, which allow a much
more flexible use of ICMP for the future

	There are exceptions. For example, I consider it inappropriate
	to issue either a std-track or even experimental change that
	endorses non-standard behavior, as per sec 4.5

- it might be useful to consider that the motivation for this document
is to find a way to attach MPLS headers with the corresponding IP
packets; while I again agree with the general notion of extensibility in
ICMP, I do NOT consider it appropriate to modify an Internet protocol
primarily to support a sub-IP layer. I would prefer it ICMP developed
its own signalling rather than to co-opt IP's.

I consider it especially NOT appropriate to design a modification to be
backward compatible with a non-std-compliant variant (as per sec 4.5).

These two last points are relevant if we NEED a motivation to extend
ICMP. Since ICMP is a core Internet protocol, I would hope we do. So
here's what I would suggest:

- this document should be adopted as an INTarea WG document to be
developed as an EXPERIMENTAL RFC

- support for non-std-compliant variants be removed
	in fact, the whole point ought to be to bring everyone
	into compliance, even if with the experimental version only

If someone can suggest an IP-layer motivation for extending ICMP this
way, then I would favor this as INTarea WG document for standards-track.
Such a motivation would exclude MPLS considerations, as I don't consider
them relevant to this decision at all, as per above.

More specific feedback has been posted to the author, with notable
excerpts only below. I hope this helps.

Joe

----

4.3 - this is the largest current problem area. it's bad enough to
extend ICMP in a non- standards-backward-compatible way, but it is NOT
appropriate to **limit** this design to accommodate backward
compatibility with non-standards-compliant mods. This REALLY makes the
case that MPLS versions should have their own message protocol, or at
least have their own ICMP message types.

I.e., THIS SECTION PROHIBITS USE OF THIS EXTENSION FOR DEST-UNREACHABLE
WITH MORE THAN 128-BYTE PAYLOADS. This is NOT a minor issue - this KILLS
THE UTILITY OF THIS MOD for new versions. Traceroute is a major issue -
and it may be the case that some future protocols will require full,
i.e., signed packets to be returned; this PREVENTS THIS POSSIBILITY -
even if the sender designed the packets to fit in the ICMP payload limit.

IMO, this section needs to be changed to require existing MPLS
traceroutes to play by the rules, rather than ignore them. If that's not
feasible, then - IMO - MPLS should get out of the ICMP pool ;-)

*****

4.5 end - The last sentence is not acceptable, as per above. It's a very
bad idea to endorse noncompliant operation without redefining it as
compliant, which is not what I get out of either this or sec 4.3 - esp.
since this limits other uses of ICMP traceroutes with longer payloads.

5 - explain the purpose of the checksum (to indicate the presence of the
option!). IMO, the checksum should be exactly the signal that the option
is there or not.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 19 Mar 2006 16:34:23 +0200 (EET)

Hi,

I reviewed -02 on the plane; mostly I agree with Joe's comments (see 
below).  It might be possible to convince me that the deployed base is 
so big (and there aren't going to be upgrades) that the existing 
implementations need to be considered.

I can send more detailed comments later if need be.

My own high level comment is that this doc needs to address ICMPv6 as 
well.  We're defining a generic extension mechanism, and except for 
the 128 byte rules for backward-compat, the mechanism seems to apply 
to both ICMPv4 and ICMPv6.

The FCFS IANA policy also seems a bit too open.

> (I'm not sure if that hum will come up)

Agreed.

> even if the sender designed the packets to fit in the ICMP payload limit.

Agreed; I didn't like this either.  Senders shouldn't need to restrict 
the response they send to 128 bytes.

Why not just require that Length must be present to even try to parse 
anything?

If there is no length field, some implementations may try to interpret 
the extensions in any case (especially if the checksum matches, so 
there's a high chance that it's valid), but I'm not sure how much we 
need to address this "transition" issue.

In any case, the receivers can break themselves and the data they 
receive as much as they want -- there's nothing the IETF can do to 
prevent vendors from interpreting parts of the payload in any way they 
want -- but don't put any additional restrictions on senders!

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 19 Mar 2006 08:52:53 -0600

Pekka and Joe,

[FWIW, I can't be at the INT area meeting, either.]

 From my very humble point of view, the draft tries to strike a  
balance between what should be done, or how to do it right, and how  
to handle the ugly situation out there.  Unless I have been lied to  
or completely misunderstood what I have heard, there *is* a  
substantial and growing installed base out there.  The presented  
solution is not nice, but is is often the case that compromises are  
not nice.  In theory, there are alternatives.  For example, one  
possibility would be to define new ICMP types for MPLS, as Joe  
suggest.  IIRC, I suggested the same when Ron initially contacted me  
about this issue.  The problem there in the IPv4 space would be that  
few people would have enough of incentive to upgrade their boxes or  
code.

In other words, in the IPv4 space where we are strongly constrained  
by the reality out there, I *think* it would be better to accept the  
reality and try to play nicely with it.

In the IPv6 space, the situation is considerably different.   
Basically, we have a clean slate.  Hence, I would appreciate people  
working a nice, beautiful, easily extensible solution for ICMPv6.   
So, if you Pekka for example are genuinely interested in doing this  
for IPv6, I would suggest teaming up with the current authors and  
write another draft.

I don't think it is a good idea to try to accommodate both IPv4 and  
IPv6 in a single document, basically because I believe that the IPv6  
solution should be considerably different in details from the one  
presented in the current draft.

--Pekka Nikander

---

From: Ron Bonica <[email-masked]>
Date: Sun, 19 Mar 2006 19:13:58 -0500

Folks,

It looks like Section 4.3 presents the biggest problem. So, let's take a
look at the text. Section 4.3 begins as follows:

"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
insensitive to the length attribute that is associated with the
"original datagram" field.  (They assume its value to be 128.)"

So far, we are probably in total agreement. This isn't a statement of
how things should be, but how they are.

The devil's text follows:

"Therefore, when fully compliant ICMP implementations append extensions
to the ICMP Destination Unreachable and Time Expired Messages, they
SHOULD restrict the "original datagram" field to its minimum length, 128
octets."

This paragraph is problematic because it makes a statement about how
thing should be. I would be willing to replace this text with the following:

"Provided that the entire ICMP messages does not exceed 576 octets,
there is no limitation upon the length of the "original datagram" field.
However, each vendor will decide how many octets to include. Currently,
many vendors include only the IP header and the first eight octets of
the IP payload. Some include exactly 128 octets. Those wishing to be
backward compatible with partially compliant TRACEROUTE implementations
will continue to include exactly 128 octets. Those not requiring
compatibility with partially compliant TRACEROUTE applications may
include more octets."

                                 Ron

---

From: Pekka Savola <[email-masked]>
Date: Mon, 20 Mar 2006 02:27:44 +0200 (EET)

On Sun, 19 Mar 2006, Pekka Nikander wrote:
> From my very humble point of view, the draft tries to strike a balance 
> between what should be done, or how to do it right, and how to handle the 
> ugly situation out there.  Unless I have been lied to or completely 
> misunderstood what I have heard, there *is* a substantial and growing 
> installed base out there.  The presented solution is not nice, but is is 
> often the case that compromises are not nice. [...]

True, but AFAICS, the change in the existing MPLS ICMP-originating 
implementations would be just 1 or 2 lines of code: calculate the 
Length field.  That's something that can be fixed in a bug fix update. 
Folks may not want to do major upgrades in their core networks, but 
they do have to do bugfix and security updates.

So, if the minimal change would actually be something very small like 
just adding a length field, I wouldn't be too concerned about how long 
it takes to replace the installed base's ICMP origination code.

In addition, the receiving applications may or may not include 
transition techniques which may or may not need to be specified in the 
doc.

---

From: Ron Bonica <[email-masked]>
Date: Mon, 20 Mar 2006 10:59:39 -0500

Pekka S,

You in two respects:

- the only application that would need to change is TRACEROUTE
- the change would touch only a few lines of code

However, it is impossible to know how long it would take to deploy this
change. Even if all of the major vendors were to release these changes
tomorrow, my guess would be that it would take several years to deploy,
globally.

                               Ron

Pekka Savola wrote:
>> between what should be done, or how to do it right, and how to handle
>> the ugly situation out there.  Unless I have been lied to or
>> completely misunderstood what I have heard, there *is* a substantial
>> and growing installed base out there.  The presented solution is not
>> nice, but is is often the case that compromises are not nice. [...]
> 
> 
> implementations would be just 1 or 2 lines of code: calculate the Length
> field.  That's something that can be fixed in a bug fix update. Folks
> may not want to do major upgrades in their core networks, but they do
> have to do bugfix and security updates.
> 
> transition techniques which may or may not need to be specified in the doc.
>