RFC 7279

An Acceptable Use Policy for New ICMP Types and Codes

📅 published May 2014, from ietf

RFC 7279: An Acceptable Use Policy for New ICMP Types and Codes 🎀

Okay bestie, let's get into this one 💖 Here's the title block so you know who wrote it and what it's about:

  • Series: Internet Engineering Task Force (IETF) 🌸
  • Number: RFC 7279
  • BCP: 189
  • Title: An Acceptable Use Policy for New ICMP Types and Codes
  • Authors: M. Shore (No Mountain Software) and C. Pignataro (Cisco Systems, Inc.) 👑
  • Category: Best Current Practice
  • ISSN: 2070-1721
  • Date: May 2014
  • Obsoletes / Updates: none listed in the title block

Abstract ✨

So this doc gives a basic rundown of ICMP's role in the IP stack and some guidelines for using it in the future 🦋

It's here because people were confused about when to add new ICMP types and/or codes. The concerns got loud enough that the authors wanted to spell out when adding features to ICMP is desirable and when it's really not 💅

Status of This Memo 🌈

This memo is an Internet Best Current Practice, so it's basically the community's official "this is how we do it" 💜

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on BCPs, check out Section 2 of RFC 5741.

For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7279 🧚

Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License. 🫶

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Acceptable Use Policy . . . . . . . . . . . . . . . . . . . .   2
  2.1.  Classification of Existing Message Types  . . . . . . . .   3
    2.1.1.  ICMP Use as a Routing Protocol  . . . . . . . . . . .   6
    2.1.2.  A Few Notes on RPL  . . . . . . . . . . . . . . . . .   6
  2.2.  Applications Using ICMP . . . . . . . . . . . . . . . . .   7
  2.3.  Extending ICMP  . . . . . . . . . . . . . . . . . . . . .   7
  2.4.  ICMPv4 vs. ICMPv6 . . . . . . . . . . . . . . . . . . . .   7
3.  ICMP's Role in the Internet . . . . . . . . . . . . . . . . .   7
4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
  6.1.  Normative references  . . . . . . . . . . . . . . . . . .   8
  6.2.  Informative references  . . . . . . . . . . . . . . . . .   9

1. Introduction ✨

There's been some recent concern about a lack of clarity around when new message types and codes should be added to ICMP. That includes ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. So this document lays out a policy about when (and when not) to move functionality into ICMP 🦋

This document came out of discussions among ICMP experts in the IP Diagnostics Technical Interest Group [DIAGNOSTICS], which sits within the Operations and Management (OPS) area. It also responds to concerns raised by the OPS area leadership 💜

Quick note: this document does not supercede the "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers" [RFC2780]. That one covers best practices and processes for allocating values in the IANA registries, but it doesn't describe the policies that should be applied in the standards process 📚

Okay, 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] 🎀

2. Acceptable Use Policy 🌸

In this doc, we describe an acceptable use policy for new ICMP message types and codes, plus some background on that policy 💅

The short version: any future message types added to ICMP should be limited to two broad categories:

  1. to inform a datagram's originator that a forwarding plane anomaly has been encountered downstream. The datagram originator must be able to determine whether or not the datagram was discarded by examining the ICMP message.
  2. to discover and convey dynamic information about a node (other than information usually carried in routing protocols), to discover and convey network-specific parameters, and to discover on-link routers and hosts.

Normally, ICMP SHOULD NOT be used to implement a general-purpose routing or network management protocol. Still, ICMP does have a role to play in conveying dynamic information about a network, and that would belong in category 2 above 🧚

2.1. Classification of Existing Message Types 🦋

This section gives a rough breakdown of existing message types, sorted using the taxonomy from Section 2 as it stood at the time of publication 📋

IPv4 forwarding plane anomaly reporting:

   3:   Destination Unreachable

   4:   Source Quench (Deprecated)

   6:   Alternate Host Address (Deprecated)

   11:  Time Exceeded

   12:  Parameter Problem

   31:  Datagram Conversion Error (Deprecated)
IPv4 router or host discovery:

   0:   Echo Reply

   5:   Redirect

   8:   Echo

   9:   Router Advertisement
   10:  Router Solicitation

   13:  Timestamp

   14:  Timestamp Reply

   15:  Information Request (Deprecated)

   16:  Information Reply (Deprecated)

   17:  Address Mask Request (Deprecated)

   18:  Address Mask Reply (Deprecated)

   30:  Traceroute (Deprecated)

   32:  Mobile Host Redirect (Deprecated)

   33:  IPv6 Where-Are-You (Deprecated)

   34:  IPv6 I-Am-Here (Deprecated)

   35:  Mobile Registration Request (Deprecated)

   36:  Mobile Registration Reply (Deprecated)

   37:  Domain Name Request (Deprecated)

   38:  Domain Name Reply (Deprecated)

   39:  SKIP (Deprecated)

   40:  Photuris

   41:  ICMP messages utilized by experimental mobility protocols
        such as Seamoby

Heads up, some ICMP message types were formally deprecated by [RFC6918] 🙈

IPv6 forwarding plane anomaly reporting:

   1:   Destination Unreachable

   2:   Packet Too Big
   3:   Time Exceeded

   4:   Parameter Problem

   150: ICMP messages utilized by experimental mobility protocols
        such as Seamoby
IPv6 router or host discovery:

   128: Echo Request

   129: Echo Reply

   130: Multicast Listener Query

   131: Multicast Listener Report

   132: Multicast Listener Done

   133: Router Solicitation

   134: Router Advertisement

   135: Neighbor Solicitation

   136: Neighbor Advertisement

   137: Redirect Message

   138: Router Renumbering

   139: ICMP Node Information Query

   140: ICMP Node Information Response

   141: Inverse Neighbor Discovery Solicitation Message

   142: Inverse Neighbor Discovery Advertisement Message

   143: Version 2 Multicast Listener Report

   144: Home Agent Address Discovery Request Message

   145: Home Agent Address Discovery Reply Message

   146: Mobile Prefix Solicitation
   147: Mobile Prefix Advertisement

   148: Certification Path Solicitation Message

   149: Certification Path Advertisement Message

   150: ICMP messages utilized by experimental mobility protocols
        such as Seamoby

   151: Multicast Router Advertisement

   152: Multicast Router Solicitation

   153: Multicast Router Termination

   154: FMIPv6 Messages

   155: RPL Control Message

2.1.1. ICMP Use as a Routing Protocol 🚫

As mentioned in Section 2, using ICMP as a general-purpose routing or network management protocol is not advisable, so it SHOULD NOT be used that way 🙅‍♀️

ICMP has a role in the Internet as an integral part of the IP layer. It is not meant to be a routing protocol, or a transport protocol for other layers (including routing information). Practically speaking, some of ICMP's key characteristics make it a less-than-ideal choice for a routing protocol. ICMP is frequently filtered, it is not authenticated, and it is easily spoofed. On top of that, specialist hardware processing of ICMP would get in the way of deploying an ICMP-based routing or management protocol 😭

2.1.2. A Few Notes on RPL 🌈

RPL, the IPv6 routing protocol for low-power and lossy networks (see [RFC6550]), uses ICMP as a transport. That makes it an exception among the ICMP message types. Although RPL is an IP routing protocol, it is not deployed on the general Internet. It's limited to specific, contained networks 🧚

This should be considered anomalous, and it is not a model for future ICMP message types. ICMP is not intended as a transport for other protocols, so it SHOULD NOT be used that way in future specifications. Using ICMP as a discovery protocol is fine, but it does not extend to full routing capabilities 💅

2.2. Applications Using ICMP 🦋

Some applications make use of ICMP error notifications, or even deliberately create anomalous conditions to make ICMP messages show up. Those messages then feed back up to the higher layer. Some of the most widespread examples are PING, TRACEROUTE, and Path MTU Discovery (PMTUD). These uses are considered acceptable because they use existing ICMP message types and don't change ICMP functionality ✨

2.3. Extending ICMP 🎀

ICMP multi-part messages are specified in [RFC4884], which defines an extension mechanism for selected ICMP messages. This mechanism fixes a fundamental problem with ICMP extensibility. An ICMP multi-part message carries all of the information that ICMP messages carried before, plus any additional information that applications may need 🫶

Some ICMP extensions that are currently defined include ICMP extensions for Multiprotocol Label Switching [RFC4950] and ICMP extensions for interface and next-hop identification [RFC5837] 🌸

Extensions to ICMP SHOULD follow the requirements in [RFC4884] 💜

2.4. ICMPv4 vs. ICMPv6 🌈

ICMPv6 is used for IPv6 Neighbor Discovery. Because of that, deployed IPv6 routers, IPv6-capable security gateways, and IPv6-capable firewalls normally support administrator configuration of how specific ICMPv6 message types are handled. By contrast, deployed IPv4 routers, IPv4-capable security gateways, and IPv4-capable firewalls are less likely to let an administrator configure how specific ICMPv4 message types are handled. So, at present, ICMPv6 messages usually have a higher probability of travelling end-to-end than ICMPv4 messages 🧚‍♀️👑

3. ICMP's Role in the Internet ✨

okay bestie, so ICMP was originally meant to be the way gateways or destination hosts tell source hosts "hey, something went wrong" 🙈 in ICMPv4 [RFC0792], and ICMPv6 [RFC4443] was modeled after it 💅. ICMP also does IP-layer jobs like diagnostics, which is where PING comes in 🏓

ICMP is literally defined as an integral part of IP, so every IP module MUST implement it 🔥. That's true for ICMPv4 as part of IPv4 (see the Introduction of [RFC0792]) and for ICMPv6 as part of IPv6 (see Section 2 of [RFC4443]) 🫶. When ICMP first showed up, its messages were basically IP messages that didn't carry any higher-layer data 🦋. People guess the word "control" got picked because ICMP messages weren't "data" messages 🤷‍♀️

Here's the tea 🍵: the word "control" in the name doesn't mean ICMP is in charge of the Internet 💀. It's really about communicating the control functions that keep the Internet running 🌸. For example, ICMP has a redirect message type that can change routing behavior on a LAN segment, but it was never meant to be a generic routing protocol, and it still isn't 🙅‍♀️✨

4. Security Considerations 🔐

okay this part is SO important, bestie 😭 This document describes a high-level policy for adding ICMP types and codes. Special attention MUST be paid to the security implications of any particular new ICMP type or code 🚨, but this recommendation itself presents no new security considerations 💜.

From a security angle, ICMP plays a part in the Photuris protocol [RFC2521]. More generally though, ICMP is NOT a secure protocol 💀. It doesn't include features to discover network security parameters or to report on network security anomalies in the forwarding plane 🙃.

⚠️ Also, any new ICMP functionality (like ICMP extensions, or new ICMP types or codes) MUST consider the potential ways ICMP can be abused. The classic example is the Smurf IP DoS attack [CA-1998-01] 😱🌪️

5. Acknowledgments 🎀

This document was originally proposed by Ron Bonica, who gave it substantial review and suggestions 👑. Discussions with Pascal Thubert helped clear up the history of RPL's use of ICMP 🧚. Huge thanks to Ran Atkinson, Tim Chown, Joe Clarke, Adrian Farrel, Ray Hunter, Hilarie Orman, Eric Rosen, JINMEI Tatuya, and Wen Zhang for their review, feedback, and comments, which made the document so much better 🥹💖

6. References 📚

6.1. Normative references

  • [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. 🌷
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🌷
  • [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. 🌷
  • [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007. 🌷

6.2. Informative references

  • [CA-1998-01] CERT, "Smurf IP Denial-of-Service Attacks", CERT Advisory CA-1998-01, January 1998, <http://www.cert.org/advisories/CA-1998-01.html>. 🍓
  • [DIAGNOSTICS] "IP Diagnostics Technical Interest Group", , <https://svn.tools.ietf.org/area/ops/trac/wiki/TIG_DIAGNOSTICS>. 🍓
  • [RFC2521] Karn, P. and W. Simpson, "ICMP Security Failures Messages", RFC 2521, March 1999. 🍓
  • [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. 🍓
  • [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007. 🍓
  • [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010. 🍓
  • [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. 🍓
  • [RFC6918] Gont, F. and C. Pignataro, "Formally Deprecating Some ICMPv4 Message Types", RFC 6918, April 2013. 🍓

Authors' Addresses 💌

Melinda Shore
No Mountain Software
PO Box 16271
Two Rivers, AK  99716
US

Phone: +1 907 322 9522
EMail: melinda.shore@nomountain.net


Carlos Pignataro
Cisco Systems, Inc.
7200-12 Kit Creek Road
Research Triangle Park, NC  27709
US

EMail: cpignata@cisco.com
📦 where this page comes from