< draft-shore-icmp-aup-11.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: August 5, 2014 Cisco Systems, Inc.		Expires: August 7, 2014 Cisco Systems, Inc.
	February 1, 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-11		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 August 5, 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 23 ¶		skipping to change at page 2, line 29 ¶
	2.1. Classification of existing message types . . . . . . . . . 3		2.1. Classification of existing message types . . . . . . . . . 3
	2.1.1. ICMP Use as a Routing Protocol . . . . . . . . . . . . 5		2.1.1. ICMP Use as a Routing Protocol . . . . . . . . . . . . 5
	2.1.2. A few notes on RPL . . . . . . . . . . . . . . . . . . 6		2.1.2. A few notes on RPL . . . . . . . . . . . . . . . . . . 6
	2.2. Applications using ICMP . . . . . . . . . . . . . . . . . . 6		2.2. Applications using ICMP . . . . . . . . . . . . . . . . . . 6
	2.3. Extending ICMP . . . . . . . . . . . . . . . . . . . . . . 6		2.3. Extending ICMP . . . . . . . . . . . . . . . . . . . . . . 6
	2.4. ICMPv4 vs. ICMPv6 . . . . . . . . . . . . . . . . . . . . . 6		2.4. ICMPv4 vs. ICMPv6 . . . . . . . . . . . . . . . . . . . . . 6
	3. ICMP's role in the internet . . . . . . . . . . . . . . . . . . 7		3. ICMP's role in the internet . . . . . . . . . . . . . . . . . . 7
	4. Security considerations . . . . . . . . . . . . . . . . . . . . 7		4. Security considerations . . . . . . . . . . . . . . . . . . . . 7
	5. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 8		5. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 8
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
	7. Informative references . . . . . . . . . . . . . . . . . . . . 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
	skipping to change at page 5, line 43 ¶		skipping to change at page 5, line 43 ¶
	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. ICMP Use as a Routing Protocol		2.1.1. ICMP Use as a Routing Protocol
	As mentioned in Section 2, using ICMP as a general-purpose routing or		As mentioned in Section 2, using ICMP as a general-purpose routing or
	network management protocol is not advisable.		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.		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		This is not as a routing protocol, or as a transport protocol for
	other layers including routing information. From a more pragmatic		other layers including routing information. From a more pragmatic
	perspective, some of the key characteristics of ICMP do not support		perspective, some of the key characteristics of ICMP make it a less
	using it as a routing protocol. Those include that ICMP is		than ideal choice for a routing protocol. Those include that ICMP is
	frequently filtered, is not authenticated, is easily spoofed, and		frequently filtered, is not authenticated, is easily spoofed, and
	that specialist hardward processing of ICMP would disrupt the		that specialist hardward processing of ICMP would disrupt the
	deployment of an ICMP-based routing or management protocol..		deployment of an ICMP-based routing or management protocol.
	2.1.2. A few notes on RPL		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]) uses ICMP as a transport. It is an exception among the		[RFC6550]) uses ICMP as a transport. In this regard, it is an
	existing ICMP message types, as the expansion of its acronym appears		exception among the ICMP message types. Note that, although RPL is
	to be an actual general routing protocol.		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. That is, ICMP is not intended as a transport for		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		other protocols and SHOULD NOT be used in that way in future
	specifications. In particular, while it is adequate to use ICMP as a		specifications. In particular, while it is adequate to use ICMP as a
	discovery protocol, this does not extend to full routing		discovery protocol, this does not extend to full routing
	capabilities.		capabilities.
	2.2. Applications using ICMP		2.2. Applications using ICMP
	Some applications make use of ICMP error notifications, or even		Some applications make use of ICMP error notifications, or even
	deliberately create anomalous conditions in order to elicit ICMP		deliberately create anomalous conditions in order to elicit ICMP
	messages, to then use those ICMP messages to generate feedback to the		messages, to then use those ICMP messages to generate feedback to the
	higher layer. Some of these applications include most widespread		higher layer. Some of these applications include most widespread
	skipping to change at page 6, line 43 ¶		skipping to change at page 6, line 45 ¶
	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.4. 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
	skipping to change at page 8, line 19 ¶		skipping to change at page 8, line 19 ¶
	6. 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 the review, feedback, and comments from Ran Atkinson,		grateful for the review, feedback, and comments from Ran Atkinson,
	Tim Chown, Joe Clarke, Adrian Farrel, Ray Hunter, Hilarie Orman, Eric		Tim Chown, Joe Clarke, Adrian Farrel, Ray Hunter, Hilarie Orman, Eric
	Rosen, JINMEI Tatuya, and Wen Zhang, which resulted in a much		Rosen, JINMEI Tatuya, and Wen Zhang, which resulted in a much
	improved document.		improved document.
	7. 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.
	[RFC2521] Karn, P. and W. Simpson, "ICMP Security Failures		[RFC2521] Karn, P. and W. Simpson, "ICMP Security Failures
	Messages", RFC 2521, March 1999.		Messages", RFC 2521, March 1999.
	[CA-1998-01]		[CA-1998-01]
	CERT, "Smurf IP Denial-of-Service Attacks", CERT		CERT, "Smurf IP Denial-of-Service Attacks", CERT
	Advisory CA-1998-01, January 1998,		Advisory CA-1998-01, January 1998,
	<http://www.cert.org/advisories/CA-1998-01.html>.		<http://www.cert.org/advisories/CA-1998-01.html>.
			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. 17 change blocks.
	27 lines changed or deleted		46 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/