Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6918 UTN-FRH / SI6 Networks
Obsoletes: 1788 C. Pignataro
Updates: 792, 950 Cisco Systems
Category: Standards Track April 2013
ISSN: 2070-1721
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 6918 UTN-FRH / SI6 Networks
Obsoletes: 1788 C. Pignataro
Updates: 792, 950 Cisco Systems
Category: Standards Track April 2013
ISSN: 2070-1721
Formally Deprecating Some ICMPv4 Message Types
正式弃用某些ICMPv4消息类型
Abstract
摘要
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 updates RFC 792 and RFC 950, obsoletes RFC 1788, and requests the RFC Editor to change the status of RFC 1788 to Historic.
许多ICMPv4消息类型在实践中已经过时，但从未正式弃用过。本文档不推荐此类ICMPv4消息类型，从而清理了相应的IANA注册表。此外，它更新RFC 792和RFC 950，淘汰RFC 1788，并请求RFC编辑器将RFC 1788的状态更改为历史。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6918.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
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) . . . . . . . . . . . . . . . 3
2.6. Traceroute (Type 30) . . . . . . . . . . . . . . . . . . . 3
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) . . . . . . . . . . . . 4
2.13. Domain Name Request (Type 37) . . . . . . . . . . . . . . . 4
2.14. Domain Name Reply (Type 38) . . . . . . . . . . . . . . . . 5
2.15. SKIP (Type 39) . . . . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4. Changing the Status of RFC 1788 to Historic . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
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) . . . . . . . . . . . . . . . 3
2.6. Traceroute (Type 30) . . . . . . . . . . . . . . . . . . . 3
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) . . . . . . . . . . . . 4
2.13. Domain Name Request (Type 37) . . . . . . . . . . . . . . . 4
2.14. Domain Name Reply (Type 38) . . . . . . . . . . . . . . . . 5
2.15. SKIP (Type 39) . . . . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4. Changing the Status of RFC 1788 to Historic . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
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 updates RFC 792 and RFC 950, obsoletes RFC 1788, and requests the RFC Editor to change the status of RFC 1788 to Historic.
多年来，已指定了许多ICMPv4[RFC0792]消息类型。许多这样的消息类型在实践中已经过时，但从未被正式弃用过。本文档不推荐此类ICMPv4消息类型，“清理”相应的IANA注册表。此外，它更新RFC 792和RFC 950，淘汰RFC 1788，并请求RFC编辑器将RFC 1788的状态更改为历史。
Section 2 discusses each of the obsoleted ICMPv4 messages. Section 4 requests the RFC Editor to change the status of RFC 1788 to Historic.
第2节讨论每一条废弃的ICMPv4消息。第4节要求RFC编辑器将RFC 1788的状态更改为历史状态。
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.
以下小节根据公开可用的信息和/或相应分配的请求者提供的信息，讨论不推荐使用的ICMPv4消息类型的详细信息。
There is no publicly available information about this message type.
没有关于此邮件类型的公开可用信息。
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.
此消息类型在[RFC0792]中指定。但是，出于主机配置的目的，其他机制（如DHCP[RFC2131]）已经取代了此消息类型。
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.
此消息类型在[RFC0792]中指定。但是，出于主机配置的目的，其他机制（如DHCP[RFC2131]）已经取代了此消息类型。
This message type is specified in [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.
此消息类型在[RFC0950]中指定，旨在提供获取子网掩码的方法。但是，出于主机配置的目的，其他机制（如DHCP[RFC2131]）已经取代了此消息类型。
This message type is specified in [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.
此消息类型在[RFC0950]中指定，旨在提供获取子网掩码的方法。但是，出于主机配置的目的，其他机制（如DHCP[RFC2131]）已经取代了此消息类型。
This message type is specified in [RFC1393] and was meant to provide an alternative means to discover the path to a destination system. This message type has never been widely deployed. The status of [RFC1393] has been changed to Historic by [RFC6814], and the corresponding option this message type relies on (Traceroute, Type 82) has been formally obsoleted by [RFC6814].
此消息类型在[RFC1393]中指定，旨在提供另一种方法来发现目标系统的路径。这种消息类型从未广泛部署。[RFC6814]已将[RFC1393]的状态更改为历史状态，并且[RFC6814]已正式废弃此消息类型所依赖的相应选项（跟踪路由，类型82）。
This message type was originally meant 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.
此消息类型最初用于报告TP/IX[RFC1475]协议中的转换错误。然而，TP/IX从未得到广泛实施或部署，[RFC1475]的状态是历史性的。
This message type was originally specified as part of an experimental protocol for IP Mobile Hosts [CMU-MOBILE]. However, it was never widely implemented or deployed.
此消息类型最初指定为IP移动主机[CMU-Mobile]实验协议的一部分。然而，它从未得到广泛实施或部署。
This message type was originally specified in [SIMPSON-DISCOV] for the purpose of identification of adjacent IPv6 nodes. It was never widely deployed or implemented.
此消息类型最初在[SIMPSON-DISCOV]中指定，用于识别相邻IPv6节点。它从未被广泛部署或实施。
This message type was originally specified in [SIMPSON-DISCOV] for the purpose of identification of adjacent IPv6 nodes. It was never widely deployed or implemented.
此消息类型最初在[SIMPSON-DISCOV]中指定，用于识别相邻IPv6节点。它从未被广泛部署或实施。
This message type was originally meant for transparent routing of IPv6 datagrams to Mobile Nodes [SIMPSON-MOBILITY]. It was never widely deployed or implemented.
此消息类型最初用于将IPv6数据报透明路由到移动节点[SIMPSON-MOBILITY]。它从未被广泛部署或实施。
This message type was originally meant for transparent routing of IPv6 datagrams to Mobile Nodes [SIMPSON-MOBILITY]. It was never widely deployed or implemented.
此消息类型最初用于将IPv6数据报透明路由到移动节点[SIMPSON-MOBILITY]。它从未被广泛部署或实施。
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.
此消息类型最初在[RFC1788]中指定，用于学习与IP地址关联的完全限定域名。这种消息类型从未广泛部署或实现。
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.
此消息类型最初在[RFC1788]中指定，用于学习与IP地址关联的完全限定域名。这种消息类型从未广泛部署或实现。
This message type was originally specified in [SKIP-ADP] for informing supported capabilities in the SKIP [SKIP] protocol. This message type was never widely deployed or implemented.
此消息类型最初在[SKIP-ADP]中指定，用于通知SKIP[SKIP]协议中支持的功能。这种消息类型从未广泛部署或实现。
The "Internet Control Message Protocol (ICMP) Parameters" registry [IANA-ICMP] contains the list of the currently assigned ICMP message Types.
“Internet控制消息协议（ICMP）参数”注册表[IANA-ICMP]包含当前分配的ICMP消息类型列表。
This document formally deprecates the following ICMP message Types and requests IANA to mark them as such in the corresponding registry [IANA-ICMP]:
本文档正式反对以下ICMP消息类型，并要求IANA在相应的注册表[IANA-ICMP]中标记它们：
o Alternate Host Address (Type 6)
o 备用主机地址（类型6）
o Information Request (Type 15)
o 信息请求（类型15）
o Information Reply (Type 16)
o 信息回复（第16类）
o Address Mask Request (Type 17)
o 地址掩码请求（类型17）
o Address Mask Reply (Type 18)
o 地址掩码应答（类型18）
o Traceroute (Type 30)
o 示踪路由（30型）
o Datagram Conversion Error (Type 31)
o 数据报转换错误（类型31）
o Mobile Host Redirect (Type 32)
o 移动主机重定向（类型32）
o IPv6 Where-Are-You (Type 33)
o IPv6您在哪里（类型33）
o IPv6 I-Am-Here (Type 34)
o IPv6 I-Am-Here（类型34）
o Mobile Registration Request (Type 35)
o 移动注册请求（类型35）
o Mobile Registration Reply (Type 36)
o 手机注册回复（第36类）
o Domain Name Request (Type 37)
o 域名请求（类型37）
o Domain Name Reply (Type 38)
o 域名回复（类型38）
o SKIP (Type 39)
o 箕斗（39型）
The ICMPv4 Source Quench Message (Type 4) has already been deprecated by [RFC6633].
[RFC6633]已弃用ICMPv4源猝灭消息（类型4）。
This document requests the RFC Editor to change the status of [RFC1788] to Historic.
本文档要求RFC编辑器将[RFC1788]的状态更改为历史状态。
Both [RFC1385] and [RFC1393] already have a status of Historic. The status of other RFCs (such as [RFC0792] and [RFC0950]) is not changed since other parts of these documents are still current.
[RFC1385]和[RFC1393]都已处于历史状态。其他RFC（如[RFC0792]和[RFC0950]）的状态没有改变，因为这些文件的其他部分仍然是最新的。
This document does not modify the security properties of the ICMPv4 message types being deprecated. However, formally deprecating these message types serves as a basis for, e.g., filtering these packets.
本文档不会修改不推荐使用的ICMPv4消息类型的安全属性。但是，正式弃用这些消息类型可作为过滤这些数据包的基础。
The authors would like to thank Ron Bonica and Joel Halpern for their guidance.
作者要感谢Ron Bonica和Joel Halpern的指导。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4 Options", RFC 6814, November 2012.
[RFC6814]Pignataro，C.和F.Gont，“正式反对某些IPv4选项”，RFC 6814，2012年11月。
[CMU-MOBILE] Johnson, D., "Transparent Internet Routing for IP Mobile Hosts", Work in Progress, July 1993.
[CMU-MOBILE]Johnson，D.，“IP移动主机的透明互联网路由”，正在进行的工作，1993年7月。
[IANA-ICMP] Internet Assigned Numbers Authority, "Internet Control Message Protocol (ICMP) Parameters", September 2012, <http://www.iana.org/assignments/icmp-parameters>.
[IANA-ICMP]互联网分配号码管理局，“互联网控制消息协议（ICMP）参数”，2012年9月<http://www.iana.org/assignments/icmp-parameters>.
[RFC0950] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985.
[RFC0950]Mogul，J.和J.Postel，“互联网标准子网程序”，STD 5，RFC 950，1985年8月。
[RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385, November 1992.
[RFC1385]Wang，Z.，“EIP：扩展互联网协议”，RFC1385，1992年11月。
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993.
[RFC1393]Malkin，G.“使用IP选项的跟踪路由”，RFC 1393，1993年1月。
[RFC1475] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, June 1993.
[RFC1475]Ullmann，R.，“TP/IX：下一个互联网”，RFC 14751993年6月。
[RFC1788] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995.
[RFC1788]辛普森，W.，“ICMP域名信息”，RFC17881995年4月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", RFC 6633, May 2012.
[RFC6633]Gont，F.，“ICMP源猝灭消息的弃用”，RFC 6633，2012年5月。
[SIMPSON-DISCOV] Simpson, W., "IPv6 Neighbor Discovery -- ICMP Message Formats", Work in Progress, January 1995.
辛普森，W.，“IPv6邻居发现——ICMP消息格式”，正在进行的工作，1995年1月。
[SIMPSON-MOBILITY] Simpson, W., "IPv6 Mobility Support", Work in Progress, November 1994.
[SIMPSON-MOBILITY]辛普森，W.，“IPv6移动支持”，正在进行的工作，1994年11月。
[SKIP] Aziz, A., Markson, T., and H. Prafullchandra, "Simple Key-Management For Internet Protocols (SKIP)", Work in Progress, December 1995.
[SKIP]Aziz，A.，Markson，T.，和H.Prafullchandra，“互联网协议的简单密钥管理（SKIP）”，正在进行的工作，1995年12月。
[SKIP-ADP] Aziz, A., Markson, T., and H. Prafullchandra, "SKIP Algorithm Discovery Protocol", Work in Progress, December 1995.
[SKIP-ADP]Aziz，A.，Markson，T.，和H.Prafullchandra，“SKIP算法发现协议”，正在进行的工作，1995年12月。
Authors' Addresses
作者地址
Fernando Gont UTN-FRH / SI6 Networks Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina
Fernando Gont UTN-FRH/SI6 Networks Evaristo Carriego 2644 Haedo，布宜诺斯艾利斯省1706阿根廷
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com
Phone: +54 11 4650 8472
EMail: fgont@si6networks.com
URI: http://www.si6networks.com
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
卡洛斯·皮格纳塔罗思科系统7200-12美国北卡罗来纳州基特克里克路研究三角公园，邮编27709
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com