ICMP Extensions for Environmental Information

IP devices use the Internet Control Message Protocol ICMPv4 and ICMPv6 to convey control information to source hosts. In particular, when an IP device receives a datagram that it cannot process, it may send an ICMP message to the datagram's originator or source. Network operators and higher-level protocols use these ICMP messages to detect and diagnose network issues. As the world transitions towards environmental sustainability in technology, and to use metrics to make networks more efficient, both from the environmental and technological standpoint, the focus is shifting not only on creating modern technologies infused with environmental information but also on bridging gaps in the tools that are already available, to enhance visibility, measurement, and quantification of their environmental impact. Consequently, tools which have been foundational for control and management for decades now encounter new requirements including enhancing them to cater to a significantly increasing demand for monitoring the sustainability and environmental impact. The IAB had held a workshop on "Environmental Impact of Internet Applications and Systems (eimpactws)" , in which the need for visibility into environmental sustainability information within traditional Internet tools such as traceroute was highlighted (see WebVTT cue identifiers 139 and 140 of .) This document serves that need by defining an ICMP extension object that appends environmental sustainability information to ICMP messages. Using ICMP as a medium to deliver environmental sustainability information is very apt as ICMP is one of the most used protocols for administration and troubleshooting and it works effectively not only in an automated setting, but also in an on-demand setting for different purposes and use cases. Using the extension defined herein, a device can explicitly append these environmental sustainability information for transmission across an administrative domain: Present and idle power (node level, component level) Throughput (node level, component level) Ecolabels and Environmentally Relevant Certifications (EERCs) Additional environmental sustainability information, such as the following, for example, may also be specified in the future: Electrical Energy Provider or Zone Geolocation

This document uses the following terms:
Generically referring to ICMPv4 and ICMPv6 messages.
Extended ICMP to support multi-part messages through an ICMP extension structure, as defined in .

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 when, and only when, they appear in all capitals, as shown here.

Motivations behind this proposing the extension defined here in this document are: Networking chips and devices increasingly measure and expose environmental information such as power draw, energy use, thermal data, and other pieces of metrics/information. Telemetry data has proven to be very important in making large scale network deployments efficient from the perspective of power consumption, cooling etc. Classic diagnostic tools such as ping and traceroute remain the most widely used and universally available command-line utilities for network troubleshooting, commonly serving as the first step in connectivity and reachability diagnosis. Thus, building extensions on top of these tools, could prove to be relatively easy to adapt and implement. We are making use of an already mature, extensible, and widely implemented foundation: RFC 4884 (Extended ICMP for Multi-Part Messages)

Environmental data already exists in inventories, the novelty is surfacing it along the path of live connectivity probes (e.g., ping, traceroute, PROBE ) for real-time, per-hop context. ICMP is universally implemented, stateless, and tool-agnostic enabling lightweight environmental telemetry without new protocols, APIs, or credentials. This facilitates path-level mapping of sustainability metrics, comparable to latency or loss, across heterogeneous equipment and administrative domains. Using ICMP as a “host” for carrying environmental information makes this retrieval method compatible with other approaches. It also complements, rather than replaces, existing methods.

To achieve the goal of transporting useful environmental information across the network, there are two key considerations. First, what information is useful to convey and in what format, and second, how to transport that environmental information. For the first task, it is critical to normalize and agree upon the information to convey and format, across potentially multiple transports. For the second task, there is a variety of options available depending on use cases. These can be categorized based on whether the approach is distributed (i.e., any endpoint or node can request and/or receive the environmental information) or centralized (i.e., a single 'controller' compiles and consolidates the information.) They can also be categorized based on the networking layer used (e.g., IP, like ICMP, or applications, like SNMP). Further, an existing protocol can be extended, or a brand new protocol can potentially be created for this purpose. This document builds upon a standardized, modular, backwards-compatible, and scale-proven ICMP extension . This does not preclude the definition of other methods to transport environmental information, more fitting to other use-cases.

This section defines the Environmental Information Object, an ICMP extension object with a Class-Num (Object Class Value) of TBA that can be appended to the following messages, as per and : ICMPv4 Time Exceeded ICMPv4 Destination Unreachable ICMPv4 Parameter Problem ICMPv4 Extended Echo Reply ICMPv6 Time Exceeded ICMPv6 Destination Unreachable ICMPv6 Extended Echo Reply The ICMP extension defined in this document MAY be appended to any of the above listed messages based on policy and following security considerations. These extensions are preceded by an ICMP Extension Structure Header, and include an ICMP Object Header. Both are defined in . The same backward compatibility issues that apply to apply to this extension. A single ICMP message can contain zero, one, or multiple instances of Environmental Information Objects. The C-Type further identifies the information fields carried. A single instance of the Environmental Information Object can convey one of the information elements defined in from each reporting node in an administrative domain.

The ICMP Environmental Information Extension has the following format.

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 |(1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | Length | Class-Num | C-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+(2) ~ Object payload ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
2 .
0 .
The one's complement checksum of the ICMP extension .
Length of the Environmental Information object, including object header and object payload, in octets. If there is no object payload, the value of Length is 4. This is used to convey that the object is unavailable (e.g., because the requested information is not applicable for the type of component that is being queried.)
TBA (Environmental Information)
C-Type as explained in .
As defined by each C-Type. While there is a single ICMP Extension Header, there could be multiple Environmental Information Objects.

The 8-bit C-Type defined in the Section 8 of allows to carry different information elements within this Class-Num (TBA). The techniques herein defined can be used with any specific environmental sustainability metric in use, present or future.

The ICMP Environmental Information Extension Object header has the following format: 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=TBA | C-Type=1-255 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following C-Type values are currently defined. Node Power Draw Sub-Object

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Present Power (32-bit unsigned word) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Idle Power (32-bit unsigned word) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A Class-Num of TBA and a C-Type of 1 are specified. The Length is 12 if the object contains this payload. A Length value of 4 indicates that it is unavailable. The Present Power is the node-level power being presently drawn, which is a magnitude that may be directly displayed, and is expressed in Watts (W). A value of 0 indicates that the Present Power is not available. The Idle Power is the node-level power when the node is idle. A value of 0 indicates that the Idle Power is not available. Node Throughput Sub-Object

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Throughput (32-bit unsigned word 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Throughput (32-bit unsigned word 2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A Class-Num of TBA and a C-Type of 2 are specified. The Length is 12 if the object contains this payload. A Length value of 4 indicates that it is unavailable. The returned value is the node-level present throughput, which is a magnitude that may be directly displayed, and is expressed in bits-per-second (bps). This allows the recipient of the ICMP message to determine a relationship between power and traffic load. There's an in-depth discussion on why we have chosen a 64-bit object type in . Ecolabels and Environmentally Relevant Certification (EERC) Sub-Object

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EERC number |0 0 0 0| Year | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A Class-Num of TBA and a C-Type of 3 are specified. The Length is 8 if the object contains this payload. A Length value of 4 indicates that it is unavailable. The returned value references an Ecolabels and Environmentally Relevant Certification (EERC) number. The following EERC numbers are defined by the present specification: ISO 14001:2015 TCO Certified Energy-efficient ethernet The "Year" field must contain the year in which the certificate was issued, or 0 to indicate "unknown" or "not specified". Component-level Power Draw Sub-Object

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UUID 32-bit Word 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UUID 32-bit Word 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UUID 32-bit Word 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UUID 32-bit Word 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Present Component Power (32-bit unsigned word) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Idle Component Power (32-bit unsigned word) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A Class-Num of TBA and a C-Type of 4 are specified. The Length is 4 plus 24 times the number of elements included. A Length value of 4 indicates that this object is unavailable. The returned value is one or more instances of component-level power drawn metrics. Each instance is a set comprised by a UUID uniquely identifying the component, and the Present Component Power and Idle Component Power fields. The Present Component Power is the component-level power being presently drawn, which is a magnitude that may be directly displayed, and is expressed in Watts (W). A value of 0 indicates that the Present Component Power is not available. The Idle Component Power is the component-level power when the component is idle. A value of 0 indicates that the Idle Component Power is not available. Component-level Throughput Sub-Object

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UUID 32-bit Word 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UUID 32-bit Word 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UUID 32-bit Word 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UUID 32-bit Word 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Component Throughput (32-bit word 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Component Throughput (32-bit word 2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A Class-Num of TBA and a C-Type of 5 are specified. The Length is 4 plus 24 times the number of elements included. A Length value of 4 indicates that this object is unavailable. The returned value is one or more instances of component-level throughput. Each instance is a set comprised by a UUID uniquely identifying the component, and the actual throughput of said component in bits-per-second (bps). This allows the recipient of the ICMP message to determine a relationship between power and traffic load. There's an in-depth discussion on why we have chosen a 64-bit object type in .

As discussed in , we have chosen 64-bit sub-objects to accommodate the present trends of the industry with respect to high density ports/components and nodes. Organizations now have components/interfaces/line cards with 100/400/800Gbps throughput and nodes with a combined throughput exceeding 10Tbps. This cannot be represented in a field which is only 32-bit long. A 32-bit field can only represent a max throughput of 4Gbps (2 ^ 32 bps). To address this, we define a "wider" 64-bit Sub-Object format. We could have defined both the "wide" (64-bit) and "short" (32-bit) variants and leave it up to the device (node) to choose one over the other based on the size requirements of the data; this could make the final packet space efficient, but it would be harder to implement, as a node would have to make an extra check to decide what kind to choose from (wide or short). Hence, for the ease of implementation, we have decided to just define a 64-bit sub-object where we need one, and skip defining a 32-bit sub-object for information like throughput, etc.

The ICMP extension defined in this memo can be used to get environmental information, either via a "transactional" or a "scheduled automated" fashion, inside an administrative domain. This section presents a sample "transactional" use case of how these pieces of information could be displayed to a user. Since both traceroute and ping utilities are based on ICMP, we will use traceroute as an example. The flavor of traceroute that has been shown here supports the ICMP extensions and is capable of conveying to the end user the environmental information in the extensions, along with the nodes that the original datagram visited on its way to the destination. This traceroute is also backwards-compatible, i.e., it can also work well with those nodes which do not support these ICMP extensions. A user at a host with an IP address 198.51.100.27 executes a traceroute to 192.0.2.1 and the shows how the user can be presented with these different pieces of information:

> traceroute 192.0.2.1 Tracing route to 192.0.2.1 over a maximum of 30 hops 1 3 ms 1 ms 2 ms 203.0.113.118 Present Power(Node=160W,Fan=7W) Idle Power(Node=152W,Fan=7W,Chassis=10W) Throughput(53687091200bps) EERC(ISO 14001:2015, Energy-efficient ethernet) 2 12 ms 9 ms 9 ms 192.0.2.9 Present Power(Node=163W,Fan=8W,Chassis=11W) Throughput(55834574848bps) EERC(ISO 14001:2015) 3 12 ms 9 ms 9 ms 192.0.2.17 4 7 ms 4 ms 7 ms 192.0.2.122 Idle Power(Node=150W,Chassis=9W) Throughput(51539607552bps) EERC(ISO 14001:2015, Energy-efficient ethernet) 5 4 ms 3 ms 3 ms 192.0.2.1 Trace complete. Many use cases are possible on the basis of the ICMP extensions defined in this memo; it is up to the user to decide how frequently queries are issued, when and how these metrics are reported, or which policy will guide such decisions.

There is interest in the 'green networking community' to have a lightweight mechanism to provide environmental sustainability information. We are aware of a couple of implementations. William Hawkins III, from the University of Cincinnati, has led an implementation called "greenmatter", found at , that responds to ICMP Extended Echo Messages with Environmental Information. A second implementation, which is a Python-based sender and a receiver, led by Jainam Parikh, found at , that responds to ICMP Extended Echo Messages with Environmental Information, with an Extended Echo Reply.

Receiver (receiver.py) — waits for incoming data. Requires two arguments: (0 or 1)
--probeFlag: Tells the receiver to include the Interface Identification Object in the response or not
--greenFlag: Tells the receiver to include the Environmental Information Object (this document) in the response or not
Sender (sender.py) — connects to the receiver and sends data. Simply sends an ICMP Extended Echo Request to the receiver.py

The security considerations of and of apply to these extensions. Upon receipt of an ICMP message, application software must check it for syntactic correctness. The extension checksum MUST be verified. Care should be taken, as improperly specified length attributes and other syntax problems may result in buffer overruns. This document 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. Routers may need to limit the rate at which ICMP messages are sent. The extensions defined in this document allows a router to append environmental sustainability information to multi-part ICMP messages, and therefore can provide the user of the traceroute and ping applications with additional information. The intended field of use for the extensions defined in this document is administrative debugging and troubleshooting and operational facilities. The extensions herein defined supply additional information in ICMP responses. These mechanisms are not initially intended for other uses. Some of the additional information provided, as e.g., power draw information, have privacy considerations. For example, behavioral considerations of the devices, or estimating other node and network attributes from the power or energy data. Other things like identification of the node, deducing node usage patterns are some more privacy concerns that can be related to the information. Keeping these considerations in mind, we limited the scope of the transportation of the environmental information to a single administrative domain (AD). But, based on , limiting a protocol's functionality doesn't mean that it will be secure. So, this particular document, which defines "a modified ICMP message with environmental information", can be classified as a FAIL-OPEN protocol . That is, the interfaces of administrative domain border nodes, facing towards the open internet, can be configured such that they avoid leaking messages with extensions containing environmental information, out of the AD. To allow general ICMP messages, an administrator can configure those outward facing interfaces to not block/drop the entire message but only strip off the extension objects and only forward the ICMP message if it is destined to go out of the AD. When environmental information are limited to the same AD, it can be considered that they can be generated from a valid source and will have integrity. High-fidelity reporting of power draw for the targeted node's memory, cache, hardware security module, or other sensitive component could allow an attacker to perform a remote side-channel attack (i.e., using differential power analysis) during cryptographic operations. This attack would allow the adversary to extract the network node's secret key(s) or other sensitive data. There are a couple of ways of mitigating this type of attack; exclude power metrics for components that process sensitive data or provide countermeasures that introduce noise in the reported power metrics (e.g., software that demarcates sensitive data which signals the processing hardware to treat this data with algorithmic noise). The latter technique is an area of ongoing research at the time of this writing. Finally, this document does not specify an authentication mechanism for the extension that it defines. Application developers should be aware of various ICMP attacks .

IANA is requested to assign the following object Class-num in the ICMP Extension Object Classes and Class Sub-types registry : Class Value Class name Reference TBA Environmental Information Object This document IANA is requested to establish a registry for the corresponding class sub-type (C-Type) space, as follows: C-Type Value Description Reference 0 Reserved This document 1 Node Power Draw This document 2 Node Throughput This document 3 Ecolabels and Environmentally Relevant Certification (EERC) This document 4 Component-level Power Draw This document 5 Component-level Throughput This document 6-246 Unassigned 247-255 Reserved for Experimentation This document C-Type values are assignable on a first-come-first-serve (FCFS) basis. IANA is requested to establish a registry for Ecolabels and Environmentally Relevant Certification (EERC) numbers (C-Type 2), as follows: Number Name Reference 0 Reserved 1 ISO 14001:2015 This document 2 TCO Certified This document 3 Energy-efficient ethernet This document 4-65527 Unassigned 65528-65535 Reserved for Experimentation This document EERC numbers are assignable on a first-come-first-serve (FCFS) basis, and require a citation to the definition of the certification.

We are very grateful to Jari Arkko for his support, thorough review, and a useful set of comments and suggestions. We are also appreciative of the feedback, input, and interest from participants of the eimpact 2024 Interim meeting. Thank you to Shawn Emery for providing very useful feedback and suggestions, and to William Hawkins III for a thorough review and sharing some fixes, as well as for the first implementation of this Internet-Draft, adding environmental information to ICMP messages.