Internet DRAFT - draft-fenner-intarea-extended-icmp-hostid
draft-fenner-intarea-extended-icmp-hostid
Internet Area Working Group B. Fenner
Internet-Draft Arista Networks
Intended status: Standards Track 9 February 2024
Expires: 12 August 2024
Extending ICMP for System Identification
draft-fenner-intarea-extended-icmp-hostid-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 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-fenner-intarea-extended-
icmp-hostid.html. Status information for this document may be found
at https://datatracker.ietf.org/doc/draft-fenner-intarea-extended-
icmp-hostid/.
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 Expires 12 August 2024 [Page 1]
Internet-Draft ICMP System ID February 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 12 August 2024.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. Node Identification Object . . . . . . . . . . . . . . . . . 3
3.1. C-Type Meaning in a Node Identification Object . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . 5
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
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.
Fenner Expires 12 August 2024 [Page 2]
Internet-Draft ICMP System ID February 2024
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 TBD 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.
3.1. C-Type Meaning in a Node Identification Object
C-Type values in a Node Identification Object include:
* 1: Identifies Node by Name
If the Node Identification Object identifies the node by name, the
Object Payload contains the configured node name. It is presumed
that the operator configures a unique node name for each system that
is identified in this manner. If the Object Payload would not
otherwise terminate on a 32-bit boundary, it MUST be padded with
ASCII NULL characters.
* 2: Identifies Node by Address
Fenner Expires 12 August 2024 [Page 3]
Internet-Draft ICMP System ID February 2024
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 1.
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 1: 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.
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.
Fenner Expires 12 August 2024 [Page 4]
Internet-Draft ICMP System ID February 2024
5. IANA Considerations
This document will ask IANA to allocate an ICMP Extension Object
Class referred to as TBD above. But for now this document is just
for discussion.
6. Normative 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-00, 21
January 2024, <https://datatracker.ietf.org/doc/html/
draft-chroboczek-intarea-v4-via-v6-00>.
[IANA.address-family-numbers]
IANA, "Address Family Numbers",
<http://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>.
[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>.
[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>.
Acknowledgments
This document derives text heavily from [RFC5837], since the
underlying mechanism is identical, and only the content of the
messages differ.
Author's Address
Fenner Expires 12 August 2024 [Page 5]
Internet-Draft ICMP System ID February 2024
Bill Fenner
Arista Networks
5453 Great America Parkway
Santa Clara, California 95054
United States of America
Email: fenner@fenron.com
Fenner Expires 12 August 2024 [Page 6]
