Skip to main content

Extending ICMP for Node Identification
draft-ietf-intarea-extended-icmp-nodeid-00

Document Type Active Internet-Draft (intarea WG)
Authors Bill Fenner , Reji Thomas
Last updated 2024-10-01 (Latest revision 2024-09-30)
Replaces draft-fenner-intarea-extended-icmp-hostid, draft-intarea-extended-icmp-nodeid
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-intarea-extended-icmp-nodeid-00
Internet Area Working Group                                    B. Fenner
Internet-Draft                                                 R. Thomas
Intended status: Standards Track                         Arista Networks
Expires: 30 March 2025                                 26 September 2024

                 Extending ICMP for Node Identification
               draft-ietf-intarea-extended-icmp-nodeid-00

Abstract

   RFC5837 describes a mechanism for Extending ICMP for Interface and
   Next-Hop Identification, which allows providing additional
   information in an ICMP error that helps identify interfaces
   participating in the path.  This is especially useful in environments
   where each interface may not have a unique IP address to respond to,
   e.g., a traceroute.

   This document introduces a similar ICMP extension for Node
   Identification.  It allows providing a unique IP address and/or a
   textual name for the node, in the case where each node may not have a
   unique IP address (e.g., the IPv6 nexthop deployment case described
   in draft-chroboczek-intarea-v4-via-v6).

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://fenner.github.io/icmp-node-id/draft-ietf-intarea-extended-
   icmp-nodeid.html.  Status information for this document may be found
   at https://datatracker.ietf.org/doc/draft-ietf-intarea-extended-icmp-
   nodeid/.

   Discussion of this document takes place on the Internet Area Working
   Group Working Group mailing list (mailto:int-area@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/int-area/.
   Subscribe at https://www.ietf.org/mailman/listinfo/int-area/.

   Source for this draft and an issue tracker can be found at
   https://github.com/fenner/icmp-node-id.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Fenner & Thomas           Expires 30 March 2025                 [Page 1]
Internet-Draft                ICMP Node ID                September 2024

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on 30 March 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Node Identification Object  . . . . . . . . . . . . . . . . .   3
     3.1.  C-Type Meaning in a Node Identification Object  . . . . .   4
     3.2.  Node IP Address Sub-Object  . . . . . . . . . . . . . . .   5
     3.3.  Node Name Sub-Object  . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  Change history . . . . . . . . . . . . . . . . . . .   8
     A.1.  Changes since
           draft-fenner-intarea-extended-icmp-hostid-00  . . . . . .   8
     A.2.  Changes since
           draft-fenner-intarea-extended-icmp-hostid-01  . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

Fenner & Thomas           Expires 30 March 2025                 [Page 2]
Internet-Draft                ICMP Node ID                September 2024

1.  Introduction

   In addition to adding incoming interface information to a traceroute
   using the mechanisms described in [RFC5837], a network operator may
   be interested in adding information to identify nodes themselves.
   [I-D.chroboczek-intarea-v4-via-v6] describes a scenario in which
   individual nodes do not have unique IPv4 addresses to use to reply to
   an IPv4 traceroute, so additional information is needed.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Node Identification Object

   This section defines the Node Identification Object, an ICMP
   Extension Object with a Class-Num (Object Class Value) of 5 that can
   be appended to the following messages:

   *  ICMPv4 Time Exceeded

   *  ICMPv4 Destination Unreachable

   *  ICMPv4 Parameter Problem

   *  ICMPv6 Time Exceeded

   *  ICMPv6 Destination Unreachable

   For reasons described in [RFC4884], this extension cannot be appended
   to any of the currently defined ICMPv4 or ICMPv6 messages other than
   those listed above.

   The extension defined herein MAY be appended to any of the above
   listed messages and SHOULD be appended whenever required to identify
   the node and when local policy or security considerations do not
   supersede this requirement.

   Similarly to the Interface Identification Object defined in
   [RFC5837], there are two different pieces of information that can
   appear in a Node Information Object.

Fenner & Thomas           Expires 30 March 2025                 [Page 3]
Internet-Draft                ICMP Node ID                September 2024

   1.  An IP Address Sub-Object MAY be included, containing an address
       of sufficient scope to identify the node within the domain.  The
       IP Address Sub-Object is defined in Section 3.2 of this memo.

   2.  A Node Name Sub-Object MAY be included, as specified in
       Section 3.3, containing up to 63 octets of the yang sys:hostname
       or another appropriate name uniquely identifying the node.

3.1.  C-Type Meaning in a Node Identification Object

   The C-Type contains a bitmask describing what information is included
   in this Node Identification Object.

   Bit     0       1       2       3       4       5       6       7
       +-------+-------+-------+-------+-------+-------+-------+-------+
       |               Reserved                | IPAddr|  name | Rsvd2 |
       +-------+-------+-------+-------+-------+-------+-------+-------+

            Figure 1: C-Type for the Node Identification Object

   The following are bit-field definitions for C-Type:

   Reserved (bits 0-4): These bits are reserved for future use and MUST
   be set to 0 on transmit and ignored on receipt.

   IP Addr (bit 5) : When set, a Node IP Address Sub-Object is present.
   When clear, an IP Address Sub-Object is not present.  The Node IP
   Address Sub-Object is described in Section 3.2 of this memo.

   Node Name (bit 6): When set, a Node Name Sub-Object is included.
   When clear, it is not included.  The Node Name Sub-Object is
   described in Section 3.3 of this memo.

   Rsvd2 (bit 7): This bit is reserved for future use and MUST be set to
   0 on transmit and ignored on receipt.

   The information included does not self-identify, so this
   specification defines a specific ordering for sending the information
   that must be followed.

   If bit 5 (IP Address) is set, a Node IP Address Sub-Object MUST be
   sent first.  If bit 6 (Name) is set, a Node Name Sub-Object MUST be
   sent next.  The information order is thus: IP Address Sub-Object,
   Node Name Sub-Object.  Any or all pieces of information may be
   present or absent, as indicated by the C-Type.  Any data that follows
   these optional pieces of information MUST be ignored.

Fenner & Thomas           Expires 30 March 2025                 [Page 4]
Internet-Draft                ICMP Node ID                September 2024

   It is valid (though pointless until additional bits are assigned by
   IANA) to receive a Node Information Object where bits 5 and 6 are
   both 0; this MUST NOT generate a warning or error.

3.2.  Node IP Address Sub-Object

   If the Node Identification Object identifies the node by address, the
   Object Payload contains an address sufficient to identify the node
   within the appropriate scope - global or as otherwise configured - as
   depicted in Figure 2.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI              |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address...

          Figure 2: Node Identification Object - C-Type 2 Payload

   Payload fields are defined as follows:

   *  Address Family Identifier (AFI): This 16-bit field identifies the
      type of address represented by the Address field.  Values for this
      field represent a subset of values found in the IANA registry of
      Address Family Numbers (available from
      [IANA.address-family-numbers]).  Valid values are 1 (representing
      a 32-bit IPv4 address) and 2 (representing a 128-bit IPv6
      address).

   *  Reserved: This field MUST be set to 0 and ignored upon receipt.

   *  Address: This variable-length field represents an address of
      appropriate scope (global, if none other defined) that can be used
      to identify the node.

3.3.  Node Name Sub-Object

   Figure 3 depicts the Node Name Sub-Object:

    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    |                  Node Name...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 3: Node Identification Object Node Name Sub-Object

Fenner & Thomas           Expires 30 March 2025                 [Page 5]
Internet-Draft                ICMP Node ID                September 2024

   The Node Name Sub-Object MUST have a length that is a multiple of 4
   octets and MUST NOT exceed 64 octets.

   The Length field represents the length of the Node Name Sub- Object,
   including the length and the node name in octets.  The maximum valid
   length is 64 octets.  The length is constrained to ensure there is
   space for the start of the original packet and additional
   information.

   The second field contains the human-readable node name.  The node
   name SHOULD be the sys:hostname [RFC7317], if less than 64 octets, or
   the first 63 octets of the sys:hostname, if the sys:hostname is
   longer.  The node name MAY be some other human-meaningful name of the
   node.  The node name MUST be padded with ASCII NUL characters if the
   object would not otherwise terminate on a 4-octet boundary.

   The node name MUST be represented in the UTF-8 charset [RFC3629]
   using the Default Language [RFC2277].

4.  Security Considerations

   It may not be desirable to allow this information to be sent to an
   arbitrary receiver.  The addition of this information SHOULD be
   configurable, and MUST default to off.  An implementation SHOULD
   determine what objects may be appended to a given message based on
   the destination IP address of the ICMP message that will contain the
   objects.

   The intended field of use for the extensions defined in this document
   is administrative debugging and troubleshooting.  The extensions
   herein defined supply additional information in ICMP responses.
   These mechanisms are not intended to be used in non-debugging
   applications.

   This document does not specify an authentication mechanism for the
   extension that it defines.  Application developers should be aware
   that ICMP messages and their contents are easily spoofed.

5.  IANA Considerations

   This IANA has allocated the ICMP Extension Object Class value 5 to
   the extension described above.  The corresponding Class Sub-types
   Registry is as follows:

Fenner & Thomas           Expires 30 March 2025                 [Page 6]
Internet-Draft                ICMP Node ID                September 2024

        +================+===========================+===========+
        | C-Type (Value) | Description               | Reference |
        +================+===========================+===========+
        | 0-4            | Unallocated - allocatable | [This     |
        |                | with Standards Action     | document] |
        +----------------+---------------------------+-----------+
        | 5              | IP Address Sub-object     | [This     |
        |                | included                  | document] |
        +----------------+---------------------------+-----------+
        | 6              | Name Sub-object included  | [This     |
        |                |                           | document] |
        +----------------+---------------------------+-----------+
        | 7              | Unallocated - allocatable | [This     |
        |                | with Standards Action     | document] |
        +----------------+---------------------------+-----------+

                                 Table 1

6.  References

6.1.  Normative References

   [IANA.address-family-numbers]
              IANA, "Address Family Numbers",
              <https://www.iana.org/assignments/address-family-numbers>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
              Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
              January 1998, <https://www.rfc-editor.org/rfc/rfc2277>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/rfc/rfc3629>.

   [RFC4884]  Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
              "Extended ICMP to Support Multi-Part Messages", RFC 4884,
              DOI 10.17487/RFC4884, April 2007,
              <https://www.rfc-editor.org/rfc/rfc4884>.

   [RFC5837]  Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen,
              N., and JR. Rivers, "Extending ICMP for Interface and
              Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837,
              April 2010, <https://www.rfc-editor.org/rfc/rfc5837>.

Fenner & Thomas           Expires 30 March 2025                 [Page 7]
Internet-Draft                ICMP Node ID                September 2024

   [RFC7317]  Bierman, A. and M. Bjorklund, "A YANG Data Model for
              System Management", RFC 7317, DOI 10.17487/RFC7317, August
              2014, <https://www.rfc-editor.org/rfc/rfc7317>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

6.2.  Informative References

   [I-D.chroboczek-intarea-v4-via-v6]
              Chroboczek, J., Kumari, W. A., and T. Høiland-Jørgensen,
              "IPv4 routes with an IPv6 next hop", Work in Progress,
              Internet-Draft, draft-chroboczek-intarea-v4-via-v6-01, 8
              July 2024, <https://datatracker.ietf.org/doc/html/draft-
              chroboczek-intarea-v4-via-v6-01>.

Appendix A.  Change history

   This section is to be removed before publishing as an RFC.

A.1.  Changes since draft-fenner-intarea-extended-icmp-hostid-00

   *  Instead of having two different messages with the same Class Value
      and different CType values, we copy the bitmap implementation from
      [RFC5837].  The re-use of bit positions means that packet parsing
      and generation code can be largely reused from existing [RFC5837]
      code.

A.2.  Changes since draft-fenner-intarea-extended-icmp-hostid-01

   *  Fixed several copy-pasta errors that still referred to interface
      names instead of node name.

Acknowledgments

   This document derives text heavily from [RFC5837], since the
   underlying mechanism is identical, and only the semantics of the
   message differs.  Thanks are therefore due to that document's
   authors: Alia K.  Atlas, Ronald P.  Bonica, Carlos Pignataro, Naiming
   Shen and JR.  Rivers.

Authors' Addresses

Fenner & Thomas           Expires 30 March 2025                 [Page 8]
Internet-Draft                ICMP Node ID                September 2024

   Bill Fenner
   Arista Networks
   5453 Great America Parkway
   Santa Clara, California 95054
   United States of America
   Email: fenner@fenron.com

   Reji Thomas
   Arista Networks
   Global Tech Park
   Bangalore 560103
   Karnataka
   India
   Email: reji.thomas@arista.com

Fenner & Thomas           Expires 30 March 2025                 [Page 9]