GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:bcp:bcp189

Internet Engineering Task Force (IETF) M. Shore Request for Comments: 7279 No Mountain Software BCP: 189 C. Pignataro Category: Best Current Practice Cisco Systems, Inc. ISSN: 2070-1721 May 2014

       An Acceptable Use Policy for New ICMP Types and Codes

Abstract

 In this document we provide a basic description of ICMP's role in the
 IP stack and some guidelines for future use.
 This document is motivated by concerns about lack of clarity
 concerning when to add new Internet Control Message Protocol (ICMP)
 types and/or codes.  These concerns have highlighted a need to
 describe policies for when adding new features to ICMP is desirable
 and when it is not.

Status of This Memo

 This memo documents an Internet Best Current Practice.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 BCPs is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7279.

Copyright Notice

 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, as 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 are provided without warranty as
 described in the Simplified BSD License.

Shore & Pignataro Best Current Practice [Page 1] RFC 7279 ICMP AUP May 2014

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 has been some recent concern expressed about a lack of clarity
 around when new message types and codes should be added to ICMP
 (including ICMPv4 [RFC0792] and ICMPv6 [RFC4443]).  We lay out a
 policy regarding when (and when not) to move functionality into ICMP.
 This document is the result of discussions among ICMP experts within
 the Operations and Management (OPS) area's IP Diagnostics Technical
 Interest Group [DIAGNOSTICS] and concerns expressed by the OPS area
 leadership.
 Note that this document does not supercede the "IANA Allocation
 Guidelines For Values In the Internet Protocol and Related Headers"
 [RFC2780], which specifies best practices and processes for the
 allocation of values in the IANA registries but does not describe the
 policies to be applied in the standards process.
 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 document, we describe an acceptable use policy for new ICMP
 message types and codes, and provide some background about the
 policy.

Shore & Pignataro Best Current Practice [Page 2] RFC 7279 ICMP AUP May 2014

 In summary, 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.  However, ICMP does have a
 role to play in conveying dynamic information about a network, which
 would belong in category 2 above.

2.1. Classification of Existing Message Types

 This section provides a rough breakdown of existing message types
 according to the taxonomy described in Section 2 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

Shore & Pignataro Best Current Practice [Page 3] RFC 7279 ICMP AUP May 2014

    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
 Please note that some ICMP message types were formally deprecated by
 [RFC6918].
 IPv6 forwarding plane anomaly reporting:
    1:   Destination Unreachable
    2:   Packet Too Big

Shore & Pignataro Best Current Practice [Page 4] RFC 7279 ICMP AUP May 2014

    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

Shore & Pignataro Best Current Practice [Page 5] RFC 7279 ICMP AUP May 2014

    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 and SHOULD NOT be used
 that way.
 ICMP has a role in the Internet as an integral part of the IP layer;
 it is not as a routing protocol or as a transport protocol for other
 layers including routing information.  From a more pragmatic
 perspective, some of the key characteristics of ICMP make it a less-
 than-ideal choice for a routing protocol.  These key characteristics
 include that ICMP is frequently filtered, is not authenticated, and
 is easily spoofed.  In addition, specialist hardware processing of
 ICMP would disrupt the deployment of 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.  In this regard, it is an
 exception among the ICMP message types.  Note that, although RPL is
 an IP routing protocol, it is not deployed on the general Internet;
 it is limited to specific, contained networks.
 This should be considered anomalous and is not a model for future
 ICMP message types.  That is, ICMP is not intended as a transport for
 other protocols and SHOULD NOT be used in that way in future
 specifications.  In particular, while it is adequate to use ICMP as a
 discovery protocol, it does not extend to full routing capabilities.

Shore & Pignataro Best Current Practice [Page 6] RFC 7279 ICMP AUP May 2014

2.2. Applications Using ICMP

 Some applications make use of ICMP error notifications, or even
 deliberately create anomalous conditions in order to elicit ICMP
 messages.  These ICMP messages are then used to generate feedback to
 the higher layer.  Some of these applications include some of the
 most widespread examples, such as PING, TRACEROUTE, and Path MTU
 Discovery (PMTUD).  These uses are considered acceptable because they
 use existing ICMP message types and do not change ICMP functionality.

2.3. Extending ICMP

 ICMP multi-part messages are specified in [RFC4884] by defining an
 extension mechanism for selected ICMP messages.  This mechanism
 addresses a fundamental problem in ICMP extensibility.  An ICMP
 multi-part message carries all of the information that ICMP messages
 carried previously, as well as additional information that
 applications may require.
 Some currently defined ICMP extensions 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 provided in
 [RFC4884].

2.4. ICMPv4 vs. ICMPv6

 Because ICMPv6 is used for IPv6 Neighbor Discovery, 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 allow an administrator to 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

 ICMP was originally intended to be a mechanism for gateways or
 destination hosts to report error conditions back to source hosts in
 ICMPv4 [RFC0792]; ICMPv6 [RFC4443] is modeled after it.  ICMP is also
 used to perform IP-layer functions, such as diagnostics (e.g., PING).
 ICMP is defined to be an integral part of IP and must be implemented
 by every IP module.  This is true for ICMPv4 as an integral part of
 IPv4 (see the Introduction of [RFC0792]), and for ICMPv6 as an

Shore & Pignataro Best Current Practice [Page 7] RFC 7279 ICMP AUP May 2014

 integral part of IPv6 (see Section 2 of [RFC4443]).  When first
 defined, ICMP messages were thought of as IP messages that didn't
 carry any higher-layer data.  It could be conjectured that the term
 "control" was used because ICMP messages were not "data" messages.
 The word "control" in the protocol name did not describe ICMP's
 function (i.e., it did not "control" the Internet); rather, it was
 used to communicate about the control functions in the Internet.  For
 example, even though ICMP included a redirect message type that
 affects routing behavior in the context of a LAN segment, it was not
 and is not used as a generic routing protocol.

4. Security Considerations

 This document describes a high-level policy for adding ICMP types and
 codes.  While special attention must be paid to the security
 implications of any particular new ICMP type or code, this
 recommendation presents no new security considerations.
 From a security perspective, ICMP plays a part in the Photuris
 protocol [RFC2521].  But more generally, ICMP is not a secure
 protocol and does not include features to be used to discover network
 security parameters or to report on network security anomalies in the
 forwarding plane.
 Additionally, new ICMP functionality (e.g., ICMP extensions, or new
 ICMP types or codes) needs to consider potential ways that ICMP can
 be abused (e.g., Smurf IP DoS [CA-1998-01]).

5. Acknowledgments

 This document was originally proposed by, and received substantial
 review and suggestions from, Ron Bonica.  Discussions with Pascal
 Thubert helped clarify the history of RPL's use of ICMP.  We are very
 grateful for the review, feedback, and comments from Ran Atkinson,
 Tim Chown, Joe Clarke, Adrian Farrel, Ray Hunter, Hilarie Orman, Eric
 Rosen, JINMEI Tatuya, and Wen Zhang, which resulted in a much
 improved document.

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.

Shore & Pignataro Best Current Practice [Page 8] RFC 7279 ICMP AUP May 2014

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

Shore & Pignataro Best Current Practice [Page 9] RFC 7279 ICMP AUP May 2014

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

Shore & Pignataro Best Current Practice [Page 10]

/data/webs/external/dokuwiki/data/pages/rfc/bcp/bcp189.txt · Last modified: 2014/05/30 21:42 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki