< draft-shore-icmp-aup-09.txt   draft-shore-icmp-aup-12.txt >
Network Working Group M. Shore Network Working Group M. Shore
Internet-Draft No Mountain Software Internet-Draft No Mountain Software
Intended status: BCP C. Pignataro Intended status: BCP C. Pignataro
Expires: July 7, 2014 Cisco Systems, Inc. Expires: August 7, 2014 Cisco Systems, Inc.
January 3, 2014 February 3, 2014
An Acceptable Use Policy for New ICMP Types and Codes An Acceptable Use Policy for New ICMP Types and Codes
draft-shore-icmp-aup-09 draft-shore-icmp-aup-12
Abstract Abstract
In this document we provide a basic description of ICMP's role in the In this document we provide a basic description of ICMP's role in the
IP stack and some guidelines for future use. IP stack and some guidelines for future use.
This document is motivated by concerns about lack of clarity This document is motivated by concerns about lack of clarity
concerning when to add new Internet Control Message Protocol (ICMP) concerning when to add new Internet Control Message Protocol (ICMP)
types and/or codes. These concerns have highlighted a need to types and/or codes. These concerns have highlighted a need to
describe policies for when adding new features to ICMP is desirable describe policies for when adding new features to ICMP is desirable
and when it is not. and when it is not.
Requirements Language
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].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 7, 2014. This Internet-Draft will expire on August 7, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Acceptable use policy . . . . . . . . . . . . . . . . . . . . . 3 2. Acceptable use policy . . . . . . . . . . . . . . . . . . . . . 3
2.1. Classification of existing message types . . . . . . . . . 3 2.1. Classification of existing message types . . . . . . . . . 3
2.1.1. A few notes on RPL . . . . . . . . . . . . . . . . . . 5 2.1.1. ICMP Use as a Routing Protocol . . . . . . . . . . . . 5
2.2. Extending ICMP . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. A few notes on RPL . . . . . . . . . . . . . . . . . . 6
2.3. ICMPv4 vs. ICMPv6 . . . . . . . . . . . . . . . . . . . . . 6 2.2. Applications using ICMP . . . . . . . . . . . . . . . . . . 6
3. ICMP's role in the internet . . . . . . . . . . . . . . . . . . 6 2.3. Extending ICMP . . . . . . . . . . . . . . . . . . . . . . 6
4. Management vs. control . . . . . . . . . . . . . . . . . . . . 7 2.4. ICMPv4 vs. ICMPv6 . . . . . . . . . . . . . . . . . . . . . 6
5. Security considerations . . . . . . . . . . . . . . . . . . . . 8 3. ICMP's role in the internet . . . . . . . . . . . . . . . . . . 7
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 8 4. Security considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Informative references . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative references . . . . . . . . . . . . . . . . . . . 8
7.2. Informative references . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
There has been some recent concern expressed about a lack of clarity There has been some recent concern expressed about a lack of clarity
around when to add new message types and codes to ICMP (including around when to add new message types and codes to ICMP (including
ICMPv4 [RFC0792] and ICMPv6 [RFC4443]). We lay out a description of ICMPv4 [RFC0792] and ICMPv6 [RFC4443]). We lay out a description of
when (and when not) to move functionality into ICMP. when (and when not) to move functionality into ICMP.
This document is the result of discussions among ICMP experts within This document is the result of discussions among ICMP experts within
skipping to change at page 3, line 40 skipping to change at page 3, line 40
1. to inform a datagram's originator that a forwarding plane anomaly 1. to inform a datagram's originator that a forwarding plane anomaly
has been encountered downstream. The datagram originator must be has been encountered downstream. The datagram originator must be
able to determine whether or not the datagram was discarded by able to determine whether or not the datagram was discarded by
examining the ICMP message examining the ICMP message
2. to discover and convey dynamic information about a node (other 2. to discover and convey dynamic information about a node (other
than information usually carried in routing protocols), to than information usually carried in routing protocols), to
discover and convey network-specific parameters, and to discover discover and convey network-specific parameters, and to discover
on-link routers and hosts. on-link routers and hosts.
Normally, other uses such as implementing a general-purpose routing Normally, ICMP SHOULD NOT be used to implement a general-purpose
or network management protocol are not advisable. However, ICMP does routing or network management protocol. However, ICMP does have a
have a role to play in conveying dynamic information about a network, role to play in conveying dynamic information about a network, which
which would belong in category 2 above. would belong in category 2 above.
2.1. Classification of existing message types 2.1. Classification of existing message types
This section provides a rough breakdown 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 according to the taxonomy described in Section 2 at the time of
publication. publication.
IPv4 forwarding plane anomaly reporting: IPv4 forwarding plane anomaly reporting:
3: Destination unreachable 3: Destination unreachable
4: Source quench (deprecated) 4: Source quench (deprecated)
5: Redirect
6: Alternate host address (deprecated) 6: Alternate host address (deprecated)
11: Time exceeded 11: Time exceeded
12: Parameter problem 12: Parameter problem
31: Datagram conversion error (deprecated) 31: Datagram conversion error (deprecated)
32: Mobile host redirect (deprecated)
41: ICMP messages utilized by experimental mobility protocols, 41: ICMP messages utilized by experimental mobility protocols,
such as Seamoby such as Seamoby
IPv4 router or host discovery: IPv4 router or host discovery:
0: Echo reply 0: Echo reply
5: Redirect
8: Echo 8: Echo
9: Router advertisement 9: Router advertisement
10: Router solicitation 10: Router solicitation
13: Timestamp 13: Timestamp
14: Timestamp reply 14: Timestamp reply
15: Information request (deprecated) 15: Information request (deprecated)
16: Information reply (deprecated) 16: Information reply (deprecated)
17: Address mask request (deprecated) 17: Address mask request (deprecated)
18: Address mask reply (deprecated) 18: Address mask reply (deprecated)
30: Traceroute (deprecated) 30: Traceroute (deprecated)
32: Mobile host redirect (deprecated)
33: IPv6 Where-Are-You (deprecated) 33: IPv6 Where-Are-You (deprecated)
34: IPv6 I-Am-Here (deprecated) 34: IPv6 I-Am-Here (deprecated)
35: Mobile registration request (deprecated) 35: Mobile registration request (deprecated)
36: Mobile registration reply (deprecated) 36: Mobile registration reply (deprecated)
37: Domain name request (deprecated) 37: Domain name request (deprecated)
38: Domain name reply (deprecated) 38: Domain name reply (deprecated)
39: SKIP (deprecated) 39: SKIP (deprecated)
40: Photuris 40: Photuris
41: ICMP messages utilized by experimental mobility protocols, 41: ICMP messages utilized by experimental mobility protocols,
such as Seamoby such as Seamoby
Please note that some ICMP message types were formally deprecated by Please note that some ICMP message types were formally deprecated by
[RFC6918]. [RFC6918].
IPv6 forwarding plane anomaly reporting: IPv6 forwarding plane anomaly reporting:
1: Destination unreachable 1: Destination unreachable
2: Packet too big 2: Packet too big
3: Time exceeded 3: Time exceeded
4: Parameter problem 4: Parameter problem
137: Redirect message
150: ICMP messages utilized by experimental mobility protocols, 150: ICMP messages utilized by experimental mobility protocols,
such as Seamoby such as Seamoby
IPv6 router or host discovery: IPv6 router or host discovery:
128: Echo request 128: Echo request
129: Echo reply 129: Echo reply
130: Multicast listener query 130: Multicast listener query
131: Multicast listener report 131: Multicast listener report
132: Multicast listener done 132: Multicast listener done
133: Router solicitation 133: Router solicitation
134: Router advertisement 134: Router advertisement
135: Neighbor solicitation 135: Neighbor solicitation
136: Neighbor advertisement 136: Neighbor advertisement
137: Redirect message
138: Router renumbering 138: Router renumbering
139: ICMP node information query 139: ICMP node information query
140: ICMP node information response 140: ICMP node information response
141: Inverse neighbor discovery solicitation message 141: Inverse neighbor discovery solicitation message
142: Inverse neighbor discovery advertisement message 142: Inverse neighbor discovery advertisement message
143: Version 2 multicast listener report 143: Version 2 multicast listener report
144: Home agent address discovery request message 144: Home agent address discovery request message
145: Home agent address discovery reply message 145: Home agent address discovery reply message
146: Mobile prefix solicitation 146: Mobile prefix solicitation
147: Mobile prefix advertisement 147: Mobile prefix advertisement
148: Certification path solicitation message 148: Certification path solicitation message
149: Certification path advertisement message 149: Certification path advertisement message
150: ICMP messages utilized by experimental mobility protocols, 150: ICMP messages utilized by experimental mobility protocols,
such as Seamoby such as Seamoby
151: Multicast router advertisement 151: Multicast router advertisement
152: Multicast router solicitation 152: Multicast router solicitation
153: Multicast router termination 153: Multicast router termination
154: FMIPv6 messages 154: FMIPv6 messages
155: RPL control message 155: RPL control message
2.1.1. A few notes on RPL 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.
This 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. Those include that ICMP is
frequently filtered, is not authenticated, is easily spoofed, and
that specialist hardward 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 RPL, the IPv6 Routing protocol for low-power and lossy networks (see
[RFC6550]) appears to be something of an outlier among the existing [RFC6550]) uses ICMP as a transport. In this regard, it is an
ICMP message types, as the expansion of its acronym appears to be an exception among the ICMP message types. Note that, although RPL is
actual routing protocol using ICMP for transport. an IP routing protocol, it is not deployed on the general Internet,
but is limited to specific, contained networks.
This should be considered anomalous and is not a model for future This should be considered anomalous and is not a model for future
ICMP message types. Our understanding is that the working group ICMP message types. That is, ICMP is not intended as a transport for
initially defined a discovery protocol extending existing ICMPv6 other protocols and SHOULD NOT be used in that way in future
Neighbor Discovery messages before moving to its own native ICMP specifications. In particular, while it is adequate to use ICMP as a
type. discovery protocol, this does not extend to full routing
capabilities.
It is typically the case that routing protocols have transport 2.2. Applications using ICMP
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 Some applications make use of ICMP error notifications, or even
deliberately create anomalous conditions in order to elicit ICMP
messages, to then use those ICMP messages to generate feedback to the
higher layer. Some of these applications include most widespread
examples such as PING, TRACEROUTE and Path MTU Discovery (PMTUD).
These uses are considered acceptable as 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 ICMP multi-part messages are specified in [RFC4884] by defining an
extension mechanism for selected ICMP messages. This mechanism extension mechanism for selected ICMP messages. This mechanism
addresses a fundamental problem in ICMP extensibility. An ICMP addresses a fundamental problem in ICMP extensibility. An ICMP
multi-part message carries all of the information that ICMP messages multi-part message carries all of the information that ICMP messages
carried previously, as well as additional information that carried previously, as well as additional information that
applications may require. applications may require.
Some currently defined ICMP extensions include ICMP extensions for Some currently defined ICMP extensions include ICMP extensions for
Multiprotocol Label Switching [RFC4950] and ICMP extensions for Multiprotocol Label Switching [RFC4950] and ICMP extensions for
interface and next-hop identification [RFC5837]. interface and next-hop identification [RFC5837].
Extensions to ICMP should follow [RFC4884]. Extensions to ICMP SHOULD follow [RFC4884].
2.3. ICMPv4 vs. ICMPv6 2.4. ICMPv4 vs. ICMPv6
Because ICMPv6 is used for IPv6 Neighbor Discovery, deployed IPv6 Because ICMPv6 is used for IPv6 Neighbor Discovery, deployed IPv6
routers, IPv6-capable security gateways, and IPv6-capable firewalls routers, IPv6-capable security gateways, and IPv6-capable firewalls
normally support administrator configuration of how specific ICMPv6 normally support administrator configuration of how specific ICMPv6
message types are handled. By contrast, deployed IPv4 routers, IPv4- message types are handled. By contrast, deployed IPv4 routers, IPv4-
capable security gateways, and IPv4-capable firewalls are less likely capable security gateways, and IPv4-capable firewalls are less likely
to allow an administrator to configure how specific ICMPv4 message to allow an administrator to configure how specific ICMPv4 message
types are handled. So, at present, ICMPv6 messages usually have a types are handled. So, at present, ICMPv6 messages usually have a
higher probability of travelling end-to-end than ICMPv4 messages. higher probability of travelling end-to-end than ICMPv4 messages.
3. ICMP's role in the internet 3. ICMP's role in the internet
ICMP was originally intended to be a mechanism for routers to report ICMP was originally intended to be a mechanism for gateways or
error conditions back to hosts in ICMPv4 [RFC0792], and ICMPv6 destination hosts to report error conditions back to source hosts in
[RFC4443] is modeled after it. The word "control" in the protocol ICMPv4 [RFC0792], and ICMPv6 [RFC4443] is modeled after it. ICMP is
name did not describe ICMP's function (i.e. it did not "control" the also used to perform IP-layer functions, such as diagnostics (e.g.,
internet), but rather that it was used to communicate about the "PING").
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.
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 the following section 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 the terminology of "management and
control planes" 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 management
and control plane 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.
"Management plane" is described in [I-D.ietf-opsawg-oam-overview],
and "control plane" is defined in [RFC6192].
It is particularly important, in the context of this discussion, to
understand that "control plane" in telecommunications 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
other similar artifacts.
"Management," on the other hand, involves an exchange between a
management application and managed entities such as network nodes,
and includes "inline management" and "management" per se. Typical
"inline management" functions include fault management and
performance monitoring (Service Level Agreement (SLA) compliance),
discovery, and typical "management" include protocols such as SNMP
and NETCONF.
The correct answer to the question of where ICMP fits into the ICMP is defined to be an integral part of IP, and must be implemented
management/control/data taxonomy is that it doesn't, at least not by every IP module. This is true for ICMPv4 as an integral part of
neatly. While some of the message types are unambiguously management IPv4 (see the Introduction of [RFC0792]), and for ICMPv6 as an
messages, at least within the narrow confines of a management/control integral part of IPv6 (see Section 2 of [RFC4443]). When first
dichotomy (ICMP type 3, or "unreachable" messages), others are less defined, ICMP messages were thought of as IP messages that didn't
clearly identifiable. For example, the "redirect" (ICMP type 5) carry any higher layer data. It could be conjectured that the term
message can be construed to contain control (in this case, routing) "control" was used given that ICMP messages were not "data" messages.
information, even though it is in some very real sense an error
message.
At this time, The word "control" in the protocol name did not describe ICMP's
o there are plethora of other protocols that can be (and are) used function (i.e. it did not "control" the internet), but rather that it
for control traffic, whether they're routing protocols, telephony was used to communicate about the control functions in the internet.
signaling protocols, QoS protocols, middlebox protocols, AAA For example, even though ICMP included a redirect message type that
protocols, etc. affects routing behavior in the context of a LAN segment, it was and
o the transport characteristics needed by control traffic can be is not used as a generic routing protocol.
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 any future message types added to ICMP should
conform to the policy in Section 2. ICMP should not be used as a
routing or network management protocol.
5. Security considerations 4. Security considerations
This document describes a high-level policy for adding ICMP types and This document describes a high-level policy for adding ICMP types and
codes. While special attention must be paid to the security codes. While special attention must be paid to the security
implications of any particular new ICMP type or code, this implications of any particular new ICMP type or code, this
recommendation presents no new security considerations. recommendation presents no new security considerations.
From a security perspective, ICMP plays a part in the Photuris From a security perspective, ICMP plays a part in the Photuris
protocol. But more generally, ICMP is not a secure protocol, and [RFC2521] protocol. But more generally, ICMP is not a secure
does not include features to be used to discover network security protocol, and does not include features to be used to discover
parameters or to report on network security anomalies in the network security parameters or to report on network security
forwarding plane. anomalies in the forwarding plane.
6. IANA considerations Additionally, new ICMP functionality (e.g., ICMP extensions, or new
ICMP types or codes) needs to consider potential ways of how ICMP can
be abused (e.g., Smurf IP DoS [CA-1998-01]).
5. IANA considerations
There are no actions required by IANA. There are no actions required by IANA.
7. Acknowledgments 6. Acknowledgments
This document was originally proposed by, and received substantial This document was originally proposed by, and received substantial
review and suggestions from, Ron Bonica. Discussions with Pascal review and suggestions from, Ron Bonica. Discussions with Pascal
Thubert helped clarify the history of RPL's use of ICMP. We are very Thubert helped clarify the history of RPL's use of ICMP. We are very
grateful for feedback and comments from Ran Atkinson, Joe Clarke, Ray grateful for the review, feedback, and comments from Ran Atkinson,
Hunter, JINMEI Tatuya, and Wen Zhang, which resulted in a much Tim Chown, Joe Clarke, Adrian Farrel, Ray Hunter, Hilarie Orman, Eric
Rosen, JINMEI Tatuya, and Wen Zhang, which resulted in a much
improved document. improved document.
8. Informative references 7. References
7.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, September 1981.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, March 2000.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. 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.
7.2. Informative references
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, March 2000.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012. Lossy Networks", RFC 6550, March 2012.
[RFC6918] Gont, F. and C. Pignataro, "Formally Deprecating Some [RFC6918] Gont, F. and C. Pignataro, "Formally Deprecating Some
ICMPv4 Message Types", RFC 6918, April 2013. 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 [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP
Extensions for Multiprotocol Label Switching", RFC 4950, Extensions for Multiprotocol Label Switching", RFC 4950,
August 2007. August 2007.
[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR.
Rivers, "Extending ICMP for Interface and Next-Hop Rivers, "Extending ICMP for Interface and Next-Hop
Identification", RFC 5837, April 2010. Identification", RFC 5837, April 2010.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the [RFC2521] Karn, P. and W. Simpson, "ICMP Security Failures
Router Control Plane", RFC 6192, March 2011. Messages", RFC 2521, March 1999.
[I-D.ietf-opsawg-oam-overview] [CA-1998-01]
Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. CERT, "Smurf IP Denial-of-Service Attacks", CERT
Weingarten, "An Overview of Operations, Administration, Advisory CA-1998-01, January 1998,
and Maintenance (OAM) Data Plane Tools", <http://www.cert.org/advisories/CA-1998-01.html>.
draft-ietf-opsawg-oam-overview-10 (work in progress),
October 2013. URIs
[1] <https://svn.tools.ietf.org/area/ops/trac/wiki/TIG_DIAGNOSTICS> [1] <https://svn.tools.ietf.org/area/ops/trac/wiki/TIG_DIAGNOSTICS>
Authors' Addresses Authors' Addresses
Melinda Shore Melinda Shore
No Mountain Software No Mountain Software
PO Box 16271 PO Box 16271
Two Rivers, AK 99716 Two Rivers, AK 99716
US US
 End of changes. 33 change blocks. 
138 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/