Network Working Group                                           M. Shore
Internet-Draft                                      No Mountain Software
Intended status: Best Current Practice                      C. Pignataro
Expires: March 12, 2014                              Cisco Systems, Inc.
                                                      September 08, 2013


         An Acceptable Use Policy for New ICMP Types and Codes
                        draft-shore-icmp-aup-04

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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 http://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 March 12, 2014.

Copyright Notice

   Copyright (c) 2013 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



Shore & Pignataro        Expires March 12, 2014                 [Page 1]


Internet-Draft                  ICMP AUP                  September 2013


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Acceptable use policy . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Classification of existing message types  . . . . . . . .   3
       2.1.1.  A few notes on RPL  . . . . . . . . . . . . . . . . .   6
     2.2.  Extending ICMP  . . . . . . . . . . . . . . . . . . . . .   6
   3.  ICMP's role in the internet . . . . . . . . . . . . . . . . .   6
   4.  Management vs. control  . . . . . . . . . . . . . . . . . . .   7
   5.  Security considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Informative references  . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   There has been some recent concern expressed about a lack of clarity
   around when to add new message types and codes to ICMP (including
   ICMPv4 [RFC0792] and ICMPv6 [RFC4443]).  We attempt to lay out a
   description of when (and when not) to move functionality into ICMP.

   This document is the result of discussions among ICMP experts within
   the OPS area's IP Diagnostics Technical Interest Group [1] and
   concerns expressed by the OPS area leadership.

2.  Acceptable use policy

   In this document we describe a proposed acceptable use policy for new
   ICMP message types and codes, and provide some background behind the
   proposed policy.

   In summary, we propose that 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 on-link routers and hosts, and network-specific
       parameters




Shore & Pignataro        Expires March 12, 2014                 [Page 2]


Internet-Draft                  ICMP AUP                  September 2013


   While ICMP's role is not to be a general-purpose network management
   protocol, it does have a role to play in conveying dynamic
   information about a network.

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.

      IPV4 forwarding plane anomaly reporting

      3:    Destination unreachable

      4:    Source quench (deprecated)

      5:    Redirect

      6:    Alternate host address (deprecated)

      11    Time exceeded

      12    Parameter problem

      31:   Datagram conversion error (deprecated)

      32:   Mobile host redirect (deprecated)

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

      IPv4 router or host discovery

      0:    Echo reply

      8:    Echo

      9:    Router advertisement

      10:   Router solicitation

      13:   Timestamp

      14:   Timestamp reply

      15:   Information request (deprecated)

      16:   Information reply (deprecated)




Shore & Pignataro        Expires March 12, 2014                 [Page 3]


Internet-Draft                  ICMP AUP                  September 2013


      17:   Address mask request (deprecated)

      18:   Address mask reply (deprecated)

      30:   Traceroute (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

      3:    Time exceeded

      4:    Parameter problem

      137:  Redirect message

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

      IPv6 router or host discovery

      128:  Echo request

      129:  Echo reply



Shore & Pignataro        Expires March 12, 2014                 [Page 4]


Internet-Draft                  ICMP AUP                  September 2013


      130:  Multicast listener query

      131:  Multicast listener report

      132:  Multicast listener done

      133:  Router solicitation

      134:  Router advertisement

      135:  Neighbor solicitation

      136:  Neighbor advertisement

      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



Shore & Pignataro        Expires March 12, 2014                 [Page 5]


Internet-Draft                  ICMP AUP                  September 2013


      155:  RPL control message

2.1.1.  A few notes on RPL

   RPL, the IPv6 Routing protocol for low-power and lossy networks (see
   [RFC6550]) appears to be something of an outlier among the existing
   ICMP message types, as the expansion of its acronym appears to be an
   actual routing protocol using ICMP for transport.

   This should be considered anomalous and is not a model for future
   ICMP message types.  Our understanding is that the working group
   initially defined a discovery protocol extending existing ICMPv6 ND
   messages before moving to its own native ICMP type.

   It is typically the case that routing protocols have transport
   requirements that are not met by ICMP.  For example, there will be
   reliability guarantees and security guarantees that are not provided
   by ICMP, forcing protocol developers to design their own mechanisms.
   Given the availability of other IETF standard transports for routing,
   this reinvention should be avoided.

2.2.  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 [RFC4884].

3.  ICMP's role in the internet

   ICMP was originally intended to be a mechanism for routers to report
   error conditions back to hosts in ICMPv4 [RFC0792], and ICMPv6
   [RFC4443] models after it.  The word "control" in the protocol name
   did not describe ICMP's function (i.e. it did not "control" the
   internet), but rather that 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 and is not used as a generic routing
   protocol.




Shore & Pignataro        Expires March 12, 2014                 [Page 6]


Internet-Draft                  ICMP AUP                  September 2013


   Most likely because of the presence of the word "control" in the
   protocol name, ICMP is often understood to be a control protocol,
   borrowing some terminology from circuit networks and the PSTN.  That
   is probably not correct - it might be more correct to describe it as
   being closer to a management plane protocol, given the data plane/
   control plane/ management plane taxonomy often used in describing
   telephony protocols.  However, layering in IP networks is not very
   clean and there's often some intermingling of function that can tend
   to lead to confusion about where to place new functions.

   In following sections we provide some background on the differences
   between control and management traffic.

4.  Management vs. control

   In this section we attempt to draw a distinction between management
   and control planes, acknowledging in advance that this may serve to
   muddle the differences even further.  Ultimately the difference may
   not matter that much for the purpose of creating a policy for adding
   new types to ICMP, but because that terminology has become
   ubiquitous, even in IETF discussions, and because it has come up in
   prior discussions of ICMP policies, it seems worthwhile to take a few
   paragraph to describe what they are and what they are not.

   The terms "management plane" and "control plane" came into use to
   describe one aspect of layering in telecommunications networks.  It
   is particularly important, in the context of this discussion, to
   understand that "control plane" in telecomm networks almost always
   refers to 'signaling,' or call control and network control
   information.  This includes "call" establishment and teardown, route
   establishment and teardown, requesting QoS or other parameters, and
   so on.

   "Management," on the other hand, tends to fall under the rubric
   "OAM," or "Operations, Administration, and Management." typical
   functions include fault management and performance monitoring
   (Service Level Agreement (SLA) compliance), discovery, etc.

   The correct answer to the question of where ICMP fits into the
   management/control/data taxonomy is that it doesn't, at least not
   neatly.  While some of the message types are unambiguously management
   message, at least within the narrow confines of a management/control
   dichotomy (ICMP type 3, or "unreachable" messages), others are less
   clearly identifiable.  For example, the "redirect" (ICMP type 5)
   message can be construed to contain control (in this case, routing)
   information, even though it is in some very real sense an error
   message.




Shore & Pignataro        Expires March 12, 2014                 [Page 7]


Internet-Draft                  ICMP AUP                  September 2013


   At this time,

   o  there are many, many other protocols that can be (and are) used
      for control traffic, whether they're routing protocols, telephony
      signaling protocols, QoS protocols, middlebox protocols, AAA
      protocols, etc.

   o  the transport characteristics needed by control traffic can be
      incompatible with the ICMP protocol standard -- for example, they
      may require reliable delivery, very large payloads, or have
      security requirements that cannot be met.

   and because of this we propose that any future message types added to
   ICMP should conform to the policy proposed in Section 2.  ICMP should
   not be used as a routing or network management protocol.

5.  Security considerations

   This document attempts to describe 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 security considerations.

6.  IANA considerations

   There are no actions required by IANA.

7.  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
   grateful for feedback from Joe Clarke and Wen Zhang.

8.  Informative references

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

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

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




Shore & Pignataro        Expires March 12, 2014                 [Page 8]


Internet-Draft                  ICMP AUP                  September 2013


   [RFC6918]  Gont, F. and C. Pignataro, "Formally Deprecating Some
              ICMPv4 Message Types", RFC 6918, April 2013.

   [RFC4884]  Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
              "Extended ICMP to Support Multi-Part Messages", RFC 4884,
              April 2007.

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

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        Expires March 12, 2014                 [Page 9]