Network Working GroupInternet Engineering Task Force (IETF) F. GontInternet-DraftRequest for Comments: 6918 UTN-FRH / SI6 Networks Obsoletes: 1788(if approved)C. Pignataro Updates: 792, 950(if approved)Cisco SystemsIntended status:Category: Standards TrackJanuary 16, 2013 Expires: July 20,April 2013 ISSN: 2070-1721 Formally Deprecating Some ICMPv4 Message Typesdraft-gp-obsolete-icmp-types-iana-01Abstract A number of ICMPv4 message types have become obsolete in practice, but have never been formally deprecated. This document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry. Additionally, it updatesRFC792RFC 792 andRFC950,RFC 950, obsoletesRFC1788,RFC 1788, and requests the RFC Editor to change the status ofRFC1788RFC 1788 to"Historic".Historic. Status ofthisThis Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany 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 July 20, 2013.http://www.rfc-editor.org/info/rfc6918. 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 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 . . . . . . . . . . . . . . . . . . . . . . . . .32 2. Discussion of Deprecated ICMPv4 Message Types . . . . . . . . . 3 2.1. Alternate Host Address (Type 6) . . . . . . . . . . . . . . 3 2.2. Information Request (Type 15) . . . . . . . . . . . . . . . 3 2.3. Information Reply (Type 16) . . . . . . . . . . . . . . . . 3 2.4. Address Mask Request (Type 17) . . . . . . . . . . . . . . 3 2.5. Address Mask Reply (Type 18) . . . . . . . . . . . . . . .43 2.6. Traceroute (Type 30) . . . . . . . . . . . . . . . . . . .43 2.7. Datagram Conversion Error (Type 31) . . . . . . . . . . . . 4 2.8. Mobile Host Redirect (Type 32) . . . . . . . . . . . . . . 4 2.9. IPv6 Where-Are-You (Type 33) . . . . . . . . . . . . . . . 4 2.10. IPv6 I-Am-Here (Type 34) . . . . . . . . . . . . . . . . . 4 2.11. Mobile Registration Request (Type 35) . . . . . . . . . . . 4 2.12. Mobile Registration Reply (Type 36) . . . . . . . . . . . .54 2.13. Domain Name Request (Type 37) . . . . . . . . . . . . . . .54 2.14. Domain Name Reply (Type 38) . . . . . . . . . . . . . . . . 5 2.15. SKIP (Type 39) . . . . . . . . . . . . . . . . . . . . . . 5 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 4. Changing thestatusStatus ofRFC1788RFC 1788 to Historic . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . .76 7.1. Normative References . . . . . . . . . . . . . . . . . . .76 7.2. Informative References . . . . . . . . . . . . . . . . . .7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 86 1. Introduction A number of ICMPv4 [RFC0792] message types have been specified over the years. A number of these message types have become obsolete in practice, but have never been formally deprecated. This document deprecates such ICMPv4 message types, "cleaning up" the corresponding IANA registry. Additionally, it updatesRFC792RFC 792 andRFC950,RFC 950, obsoletesRFC1788,RFC 1788, and requests the RFC Editor to change the status ofRFC1788RFC 1788 to"Historic".Historic. Section 2 discusses each of the obsoleted ICMPv4 messages. Section 4 requests the RFC Editor to change the status ofRFC1788RFC 1788 to"Historic".Historic. 2. Discussion of Deprecated ICMPv4 Message Types The following subsections discuss the details of those ICMPv4 message types being deprecated, based on publicly available information and/or information provided by the requester of the corresponding assignment. 2.1. Alternate Host Address (Type 6) There is nopublicly-availablepublicly available information about this message type. 2.2. Information Request (Type 15) This message type is specified in [RFC0792]. However, other mechanisms (such as DHCP [RFC2131]) have superseded this message type for the purpose of host configuration. 2.3. Information Reply (Type 16) This message type is specified in [RFC0792]. However, other mechanisms (such as DHCP [RFC2131]) have superseded this message type for the purpose of host configuration. 2.4. Address Mask Request (Type 17) This message type is specified in[RFC0950],[RFC0950] and was meant to provide a means to obtain the subnet mask. However, other mechanisms (such as DHCP [RFC2131]) have superseded this message type for the purpose of host configuration. 2.5. Address Mask Reply (Type 18) This message type is specified in[RFC0950],[RFC0950] and was meant to provide a means to obtain the subnet mask. However, other mechanisms (such as DHCP [RFC2131]) have superseded this message type for the purpose of host configuration. 2.6. Traceroute (Type 30) This message type is specified in[RFC1393],[RFC1393] and was meant to provide an alternative means to discover the path to a destination system. This message type has never been widelydeployed, and thedeployed. The status of [RFC1393] has been changed to"Historic"Historic by[RFC6814][RFC6814], and the corresponding option this message type relies on (Traceroute, Type 82) has been formally obsoleted by [RFC6814]. 2.7. Datagram Conversion Error (Type 31) This message type was originallymeanmeant to report conversion errors in the TP/IX [RFC1475] protocol. However, TP/IX was never widely implemented or deployed, and the status of [RFC1475] is"Historic".Historic. 2.8. Mobile Host Redirect (Type 32) This message type was originally specified as part of an experimental protocol for IP Mobile Hosts[cmu-mobile].[CMU-MOBILE]. However, it was never widely implemented or deployed. 2.9. IPv6 Where-Are-You (Type 33) This message type was originally specified in[draft-simpson-ipv6-discov-formats][SIMPSON-DISCOV] for the purpose of identification of adjacent IPv6 nodes. It was never widely deployed or implemented. 2.10. IPv6 I-Am-Here (Type 34) This message type was originally specified in[draft-simpson-ipv6-discov-formats][SIMPSON-DISCOV] for the purpose of identification of adjacent IPv6 nodes. It was never widely deployed or implemented. 2.11. Mobile Registration Request (Type 35) This message type was originally meant for transparent routing of IPv6 datagrams to Mobile Nodes[draft-simpson-ipv6-mobility].[SIMPSON-MOBILITY]. It was never widely deployed or implemented. 2.12. Mobile Registration Reply (Type 36) This message type was originally meant for transparent routing of IPv6 datagrams to Mobile Nodes[draft-simpson-ipv6-mobility].[SIMPSON-MOBILITY]. It was never widely deployed or implemented. 2.13. Domain Name Request (Type 37) This message type was originally specified in [RFC1788] for the purpose of learning the Fully Qualified Domain Name associated with an IP address. This message type was never widely deployed or implemented. 2.14. Domain Name Reply (Type 38) This message type was originally specified in [RFC1788] for the purpose of learning the Fully Qualified Domain Name associated with an IP address. This message type was never widely deployed or implemented. 2.15. SKIP (Type 39) This message type was originally specified in[draft-ietf-ipsec-skip-adp][SKIP-ADP] for informing supported capabilities in the SKIP[draft-ietf-ipsec-skip][SKIP] protocol. This message type was never widely deployed or implemented. 3. IANA Considerations The "Internet Control Message Protocol (ICMP) Parameters" registry [IANA-ICMP] contains the list of the currently assigned ICMP message Types. This document formally deprecates the following ICMP messageTypes,Types and requests IANA to mark them as such in the corresponding registry [IANA-ICMP]: o Alternate Host Address (Type 6) o Information Request (Type 15) o Information Reply (Type 16) o Address Mask Request (Type 17) o Address Mask Reply (Type 18) o Traceroute (Type 30) o Datagram Conversion Error (Type 31) o Mobile Host Redirect (Type 32) o IPv6 Where-Are-You (Type 33) o IPv6 I-Am-Here (Type 34) o Mobile Registration Request (Type 35) o Mobile Registration Reply (Type 36) o Domain Name Request (Type 37) o Domain Name Reply (Type 38) o SKIP (Type 39) The ICMPv4 Source Quench Message (Type 4) has already been deprecated by [RFC6633]. 4. Changing thestatusStatus ofRFC1788RFC 1788 to Historic This document requests the RFC Editor to change the status of [RFC1788] to"Historic". The status ofHistoric. Both [RFC1385] and [RFC1393]isalready"Historic".have a status of Historic. The status of other RFCs (such as [RFC0792] and[RFC0950][RFC0950]) is not changed since other parts of these documents are still current. 5. Security Considerations This document does not modify the security properties of the ICMPv4 message types being deprecated. However, formally deprecating these message types serves as a basisfor e.g.for, e.g., filtering these packets. 6. Acknowledgments The authors would like to thank Ron Bonica and Joel Halpern for their guidance. 7. References 7.1. Normative References [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4 Options", RFC 6814, November 2012. 7.2. Informative References [CMU-MOBILE] Johnson, D., "Transparent Internet Routing for IP Mobile Hosts", Work in Progress, July 1993. [IANA-ICMP] Internet Assigned Numbers Authority, "Internet Control Message Protocol (ICMP) Parameters", September 2012, <http://www.iana.org/assignments/icmp-parameters>. [RFC0950] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985. [RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385, November 1992. [RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993. [RFC1475] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, June 1993. [RFC1788] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", RFC 6633, May 2012.[cmu-mobile] Johnson, D., "Transparent Internet Routing for IP Mobile Hosts", IETF Internet Draft, work[SIMPSON-DISCOV] Simpson, W., "IPv6 Neighbor Discovery -- ICMP Message Formats", Work inprogress, July 1993, <http://www.monarch.cs.rice.edu/internet-drafts/ cmu-mobile.txt>. [draft-ietf-ipsec-skip]Progress, January 1995. [SIMPSON-MOBILITY] Simpson, W., "IPv6 Mobility Support", Work in Progress, November 1994. [SKIP] Aziz, A., Markson, T., and H. Prafullchandra, "SimpleKey- ManagementKey-Management For Internet Protocols (SKIP)",IETF Internet Draft, draft-ietf-ipsec-skip, workWork inprogress,Progress, December 1995.[draft-ietf-ipsec-skip-adp][SKIP-ADP] Aziz, A., Markson, T., and H. Prafullchandra, "SKIP Algorithm Discovery Protocol",IETF Internet Draft, draft-ietf-ipsec-skip-adp, workWork inprogress,Progress, December 1995.[draft-simpson-ipv6-discov-formats] Simpson, W., "IPv6 Neighbor Discovery -- ICMP Message Formats", IETF Internet Draft, draft-simpson-ipv6-discov-formats, work in progress, January 1995. [draft-simpson-ipv6-mobility] Simpson, W., "IPv6 Mobility Support", IETF Internet Draft, draft-simpson-ipv6-mobility, work in progress, November 1994.Authors' Addresses Fernando Gont UTN-FRH / SI6 Networks Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: +54 11 4650 8472Email:EMail: fgont@si6networks.com URI: http://www.si6networks.com Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 USEmail:EMail: cpignata@cisco.com