draft-shore-icmp-aup-03.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="no"?>

<!DOCTYPE rfc
  SYSTEM "rfc2629.dtd" [
          <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<rfc ipr='trust200902' docName='draft-shore-icmp-aup-03' category='bcp'>

<front>
  <title abbrev='ICMP AUP'>
    An Acceptable Use Policy for New ICMP Types and Codes
  </title>

  <author initials='M.' surname='Shore' fullname='Melinda Shore'>
    <organization>No Mountain Software</organization>
    <address>
      <postal>
        <street>PO Box 16271</street>
        <city>Two Rivers</city>
        <region>AK</region>
        <code>99716</code>
        <country>US</country>
      </postal>
      <phone>+1 907 322 9522</phone>
      <email>melinda.shore@nomountain.net</email>
    </address>
  </author>

  <author initials='C.' surname='Pignataro' fullname='Carlos Pignataro'>
    <organization>Cisco Systems, Inc.</organization>
    <address>
      <postal>
        <street>7200-12 Kit Creek Road</street>
        <city>Research Triangle Park</city>
        <region>NC</region>
        <code>27709</code>
        <country>US</country>
      </postal>
      <email>cpignata@cisco.com</email>
    </address>
  </author>

  <date month='March' year='2013' />

  <area>Operations</area>

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

<middle>
  <section title='Introduction'>
    <t>There has been some recent concern expressed about a
      lack of clarity around when to add new message types
      and codes to ICMP
      (including <xref target='RFC792'>ICMPv4</xref>
      and <xref target='RFC4443'>ICMPv6</xref>).  We attempt
      to lay out a description of when (and when not) to
      move functionality into ICMP.</t>

    <t>This document is the result of discussions among ICMP
      experts within the OPS area's
      <eref target='https://svn.tools.ietf.org/area/ops/trac/wiki/TIG_DIAGNOSTICS'>IP
        Diagnostics Technical Interest Group</eref> and concerns
      expressed by the OPS area leadership.</t>
  </section>

  <section title='Acceptable use policy' anchor='aup'>
    <t>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.</t>

    <t>In summary, we propose that any future message
      types added to ICMP should be limited to two broad
      categories:</t>

    <t><list style='numbers'>
        <t>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</t>
        <t>to discover on-link routers and hosts, and
          network-specific parameters</t>
    </list></t>
    <t>While we do not want ICMP to be a general-purpose
      network management protocol it does have a role to
      play in conveying dynamic information about a network.</t>

    <section title='Classification of existing message types'>

      <t>This section provides a rough breakdown of existing message
        types according to the taxonomy described in <xref target='aup' />.</t>

      <t><list>
          <t>IPV4 forwarding plane anomaly reporting</t>
          <t><list style='hanging'>
            <t hangText='3: '>Destination unreachable</t>
            <t hangText='4: '>Source quench (deprecated)</t>
            <t hangText='5: '>Redirect</t>
            <t hangText='6: '>Alternate host address</t>
            <t hangText='11 '>Time exceeded</t>
            <t hangText='12 '>Parameter problem</t>
            <t hangText='31: '>Datagram converson error</t>
            <t hangText='32: '>Mobile host redirect</t>
            <t hangText='41: '>ICMP messages utilized by experimental
              mobility protocols, such as Seamoby</t>
          </list></t>

          <t>IPv4 router or host discovery</t>
          <t><list style='hanging'>
            <t hangText='0: '>Echo reply</t>
            <t hangText='8: '>Echo</t>
            <t hangText='9: '>Router advertisement</t>
            <t hangText='10: '> Router solicitation</t>
            <t hangText='13: '> Timestamp</t>
            <t hangText='14: '> Timestamp reply</t>
            <t hangText='15: '> Information request</t>
            <t hangText='16: '> Information reply</t>
            <t hangText='17: '> Address mask request</t>
            <t hangText='18: '> Address mask reply</t>
            <t hangText='30: '> Traceroute</t>
            <t hangText='33: '> IPv6 Where-Are-You</t>
            <t hangText='34: '> IPv6 I-Am-Here</t>
            <t hangText='35: '> Mobile registration request</t>
            <t hangText='36: '> Mobile registration reply</t>
            <t hangText='37: '> Domain name request</t>
            <t hangText='38: '> Domain name reply</t>
            <t hangText='39: '> SKIP</t>
            <t hangText='40: '> Photuris</t>
            <t hangText='41: '> ICMP messages utilized by experimental
              mobility protocols, such as Seamoby</t>
          </list></t>

          <t>IPv6 forwarding plane anomaly reporting</t>
          <t><list style='hanging'>
              <t hangText='1: '>Destination unreachable</t>
              <t hangText='2: '>Packet too big</t>
              <t hangText='3: '>Time exceeded</t>
              <t hangText='4: '>Parameter problem</t>
              <t hangText='137: '>Redirect message</t>
              <t hangText='150: '>ICMP messages utilized by experimental
                mobility protocols, such as Seamoby</t>
          </list></t>

          <t>IPv6 router or host discovery</t>
          <t><list style='hanging'>
              <t hangText='128: '>Echo request</t>
              <t hangText='129: '>Echo reply</t>
              <t hangText='130: '>Multicast listener query</t>
              <t hangText='131: '>Multicast listener report</t>
              <t hangText='132: '>Multicast listener done</t>
              <t hangText='133: '>Router solicitation</t>
              <t hangText='134: '>Router advertisement</t>
              <t hangText='135: '>Neighbor solicitation</t>
              <t hangText='136: '>Neighbor advertisement</t>
              <t hangText='138: '>Router renumbering</t>
              <t hangText='139: '>ICMP node information query</t>
              <t hangText='140: '>ICMP node information response</t>
              <t hangText='141: '>Inverse neighbor discovery solicitation message</t>
              <t hangText='142: '>Inverse neighbor discovery advertisement message</t>
              <t hangText='143: '>Version 2 multicast listener report</t>
              <t hangText='144: '>Home agent address discovery request message</t>
              <t hangText='145: '>Home agent address discovery reply message</t>
              <t hangText='146: '>Mobile prefix solicitation</t>
              <t hangText='147: '>Mobile prefix advertisement </t>
              <t hangText='148: '>Certification path solicitation message</t>
              <t hangText='149: '>Certification path advertisement message</t>
              <t hangText='150: '>ICMP messages utilized by experimental
                mobility protocols, such as Seamoby</t>
              <t hangText='151: '>Multicast router advertisement</t>
              <t hangText='152: '>Multicast router solicitation</t>
              <t hangText='153: '>Multicast router termination</t>
              <t hangText='154: '>FMIPv6 messages</t>
              <t hangText='155: '>RPL control message</t>
          </list></t>

      </list></t>

      <section title="A few notes on RPL">
        <t>RPL, the IPv6 Routing protocol for low-power and
          lossy networks (see <xref target='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.</t>

        <t>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.</t>
      </section>
    </section> <!-- classification of existing message types -->

  </section> <!-- acceptable use policy -->

  <section title="ICMP's role in the internet">
    <t>ICMP was originally intended to be a mechanism for routers
      to report error conditions back to hosts <xref target='RFC792' />.
      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, it was and is not used as a
      routing protocol.</t>

    <t>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.</t>

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

  </section>

  <section title='Management vs. control'>
    <t>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.</t>

    <t>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.  </t>

    <t>"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.</t>

  </section> <!-- management vs control -->

    <t>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.</t>

    <t>At this time,
      <list style='symbols'>
        <t>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.</t>
        <t>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.</t>
      </list>
      and because of this we propose that any future message
      types added to ICMP must conform to the policy proposed in
      <xref target='aup' />.  ICMP should not be used as a routing
      or network management protocol.</t>
    
  <section title='Security considerations'>
    <t>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, specific security considerations
      are outside the scope of this paper.</t>
  </section> <!-- security considerations -->

  <section title='IANA considerations'>
    <t>There are no actions required by IANA.</t>
  </section>

  <section title='Acknowledgments'>
    <t>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.
    </t>
  </section> <!-- acknowledgements -->

</middle>

<back>
  <references title='Informative references'>
    <reference anchor="RFC792">
      <front>
        <title>INTERNET CONTROL MESSAGE PROTOCOL</title>
        <author initials="J" surname="Postel" fullname="J. Postel">
          <organization>ISI</organization>
        </author>
        <date month="September" year="1981" />
      </front>
      <seriesInfo name="RFC" value="792" />
    </reference>
    <?rfc include='reference.RFC.4443.xml'?>
    <?rfc include="reference.RFC.6550.xml"?>
  </references>
</back>
</rfc>