Internet Engineering Task Force (IETF) M. Shore
Request for Comments: 7279 No Mountain Software
BCP: 189 C. Pignataro
Category: Best Current Practice Cisco Systems, Inc.
ISSN: 2070-1721 May 2014
Internet Engineering Task Force (IETF) M. Shore
Request for Comments: 7279 No Mountain Software
BCP: 189 C. Pignataro
Category: Best Current Practice Cisco Systems, Inc.
ISSN: 2070-1721 May 2014
An Acceptable Use Policy for New ICMP Types and Codes
新ICMP类型和代码的可接受使用策略
Abstract
摘要
In this document we provide a basic description of ICMP's role in the IP stack and some guidelines for future use.
在本文档中，我们提供了ICMP在IP堆栈中的角色的基本描述，以及一些供将来使用的指南。
This document is motivated by concerns about lack of clarity concerning when to add new Internet Control Message Protocol (ICMP) types and/or codes. These concerns have highlighted a need to describe policies for when adding new features to ICMP is desirable and when it is not.
本文件的动机是对何时添加新的Internet控制消息协议（ICMP）类型和/或代码缺乏明确性的关注。这些问题突出表明，需要说明何时需要向ICMP添加新功能，何时不需要。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
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 BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见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/rfc7279.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7279.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Acceptable Use Policy . . . . . . . . . . . . . . . . . . . . 2
2.1. Classification of Existing Message Types . . . . . . . . 3
2.1.1. ICMP Use as a Routing Protocol . . . . . . . . . . . 6
2.1.2. A Few Notes on RPL . . . . . . . . . . . . . . . . . 6
2.2. Applications Using ICMP . . . . . . . . . . . . . . . . . 7
2.3. Extending ICMP . . . . . . . . . . . . . . . . . . . . . 7
2.4. ICMPv4 vs. ICMPv6 . . . . . . . . . . . . . . . . . . . . 7
3. ICMP's Role in the Internet . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative references . . . . . . . . . . . . . . . . . . 8
6.2. Informative references . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acceptable Use Policy . . . . . . . . . . . . . . . . . . . . 2
2.1. Classification of Existing Message Types . . . . . . . . 3
2.1.1. ICMP Use as a Routing Protocol . . . . . . . . . . . 6
2.1.2. A Few Notes on RPL . . . . . . . . . . . . . . . . . 6
2.2. Applications Using ICMP . . . . . . . . . . . . . . . . . 7
2.3. Extending ICMP . . . . . . . . . . . . . . . . . . . . . 7
2.4. ICMPv4 vs. ICMPv6 . . . . . . . . . . . . . . . . . . . . 7
3. ICMP's Role in the Internet . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative references . . . . . . . . . . . . . . . . . . 8
6.2. Informative references . . . . . . . . . . . . . . . . . 9
There has been some recent concern expressed about a lack of clarity around when new message types and codes should be added to ICMP (including ICMPv4 [RFC0792] and ICMPv6 [RFC4443]). We lay out a policy regarding when (and when not) to move functionality into ICMP.
最近有人对何时应向ICMP（包括ICMPv4[RFC0792]和ICMPv6[RFC4443]）添加新的消息类型和代码缺乏明确性表示担忧。我们制定了关于何时（何时不）将功能移入ICMP的政策。
This document is the result of discussions among ICMP experts within the Operations and Management (OPS) area's IP Diagnostics Technical Interest Group [DIAGNOSTICS] and concerns expressed by the OPS area leadership.
本文件是运行和管理（OPS）区域IP诊断技术利益小组[Diagnostics]内ICMP专家讨论的结果，以及OPS区域领导层表示的关注。
Note that this document does not supercede the "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers" [RFC2780], which specifies best practices and processes for the allocation of values in the IANA registries but does not describe the policies to be applied in the standards process.
请注意，本文件并未取代“互联网协议和相关标题中值的IANA分配指南”[RFC2780]，该指南规定了IANA注册中心中值分配的最佳实践和流程，但未说明标准流程中应用的策略。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In this document, we describe an acceptable use policy for new ICMP message types and codes, and provide some background about the policy.
在本文档中，我们描述了新ICMP消息类型和代码的可接受使用策略，并提供了有关该策略的一些背景信息。
In summary, any future message types added to ICMP should be limited to two broad categories:
总之，未来添加到ICMP的任何消息类型应限于两大类：
1. 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.
1. 通知数据报的发起人下游遇到转发平面异常。数据报发起人必须能够通过检查ICMP消息来确定数据报是否被丢弃。
2. to discover and convey dynamic information about a node (other than information usually carried in routing protocols), to discover and convey network-specific parameters, and to discover on-link routers and hosts.
2. 发现和传送节点的动态信息（路由协议中通常携带的信息除外），发现和传送网络特定参数，以及在链路路由器和主机上发现。
Normally, ICMP SHOULD NOT be used to implement a general-purpose routing or network management protocol. However, ICMP does have a role to play in conveying dynamic information about a network, which would belong in category 2 above.
通常，ICMP不应用于实现通用路由或网络管理协议。然而，ICMP在传递关于网络的动态信息方面确实可以发挥作用，这属于上述第2类。
This section provides a rough breakdown of existing message types according to the taxonomy described in Section 2 at the time of publication.
本节根据发布时第2节所述的分类法，提供现有消息类型的大致分类。
IPv4 forwarding plane anomaly reporting:
IPv4转发平面异常报告：
3: Destination Unreachable
3：无法到达目的地
4: Source Quench (Deprecated)
4：源淬火（已弃用）
6: Alternate Host Address (Deprecated)
6:备用主机地址（已弃用）
11: Time Exceeded
11：超出时间
12: Parameter Problem
12：参数问题
31: Datagram Conversion Error (Deprecated)
31:数据报转换错误（已弃用）
IPv4 router or host discovery:
IPv4路由器或主机发现：
0: Echo Reply
0：回音回复
5: Redirect
5：重定向
8: Echo
8：回声
9: Router Advertisement
9：路由器广告
10: Router Solicitation
10：路由器招标
13: Timestamp
13：时间戳
14: Timestamp Reply
14：时间戳回复
15: Information Request (Deprecated)
15：信息请求（已弃用）
16: Information Reply (Deprecated)
16：信息回复（已弃用）
17: Address Mask Request (Deprecated)
17:地址掩码请求（已弃用）
18: Address Mask Reply (Deprecated)
18：地址掩码回复（已弃用）
30: Traceroute (Deprecated)
30：跟踪路由（已弃用）
32: Mobile Host Redirect (Deprecated)
32:移动主机重定向（已弃用）
33: IPv6 Where-Are-You (Deprecated)
33:IPv6您在哪里（已弃用）
34: IPv6 I-Am-Here (Deprecated)
34:IPv6 I-Am-Here（已弃用）
35: Mobile Registration Request (Deprecated)
35:移动注册请求（已弃用）
36: Mobile Registration Reply (Deprecated)
36：手机注册回复（已弃用）
37: Domain Name Request (Deprecated)
37:域名请求（已弃用）
38: Domain Name Reply (Deprecated)
38:域名回复（已弃用）
39: SKIP (Deprecated)
39：跳过（已弃用）
40: Photuris
40:Photuris
41: ICMP messages utilized by experimental mobility protocols such as Seamoby
41：实验性移动协议（如Seamoby）使用的ICMP消息
Please note that some ICMP message types were formally deprecated by [RFC6918].
请注意，[RFC6918]正式反对某些ICMP消息类型。
IPv6 forwarding plane anomaly reporting:
IPv6转发平面异常报告：
1: Destination Unreachable
1：无法到达目的地
2: Packet Too Big
2:包太大了
3: Time Exceeded
3：超出时间
4: Parameter Problem
4：参数问题
150: ICMP messages utilized by experimental mobility protocols such as Seamoby
150：实验性移动协议（如Seamoby）使用的ICMP消息
IPv6 router or host discovery:
IPv6路由器或主机发现：
128: Echo Request
128：回显请求
129: Echo Reply
129：回音回复
130: Multicast Listener Query
130：多播侦听器查询
131: Multicast Listener Report
131:多播侦听器报告
132: Multicast Listener Done
132:多播侦听器已完成
133: Router Solicitation
133：路由器招标
134: Router Advertisement
134：路由器广告
135: Neighbor Solicitation
135：邻居邀请
136: Neighbor Advertisement
136：邻居广告
137: Redirect Message
137：重定向消息
138: Router Renumbering
138：路由器重新编号
139: ICMP Node Information Query
139:ICMP节点信息查询
140: ICMP Node Information Response
140:ICMP节点信息响应
141: Inverse Neighbor Discovery Solicitation Message
141：反向邻居发现请求消息
142: Inverse Neighbor Discovery Advertisement Message
142：反向邻居发现广告消息
143: Version 2 Multicast Listener Report
143:Version2多播侦听器报告
144: Home Agent Address Discovery Request Message
144：归属代理地址发现请求消息
145: Home Agent Address Discovery Reply Message
145：归属代理地址发现回复消息
146: Mobile Prefix Solicitation
146：移动前缀请求
147: Mobile Prefix Advertisement
147：移动前缀广告
148: Certification Path Solicitation Message
148：证书路径请求消息
149: Certification Path Advertisement Message
149：证书路径公告消息
150: ICMP messages utilized by experimental mobility protocols such as Seamoby
150：实验性移动协议（如Seamoby）使用的ICMP消息
151: Multicast Router Advertisement
151：多播路由器广告
152: Multicast Router Solicitation
152：多播路由器请求
153: Multicast Router Termination
153：多播路由器终止
154: FMIPv6 Messages
154:FMIPv6消息
155: RPL Control Message
155:RPL控制消息
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.
如第2节所述，使用ICMP作为通用路由或网络管理协议是不可取的，也不应以这种方式使用。
ICMP has a role in the Internet as an integral part of the IP layer; it 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. These key characteristics include that ICMP is frequently filtered, is not authenticated, and is easily spoofed. In addition, specialist hardware processing of ICMP would disrupt the deployment of an ICMP-based routing or management protocol.
ICMP作为IP层不可分割的一部分在互联网中发挥作用；它不是路由协议，也不是其他层（包括路由信息）的传输协议。从更实用的角度来看，ICMP的一些关键特性使得它不是路由协议的理想选择。这些关键特征包括ICMP经常被过滤、未经身份验证以及容易被欺骗。此外，ICMP的专业硬件处理将中断基于ICMP的路由或管理协议的部署。
RPL, the IPv6 routing protocol for low-power and lossy networks (see [RFC6550]) uses ICMP as a transport. In this regard, it is an exception among the ICMP message types. Note that, although RPL is an IP routing protocol, it is not deployed on the general Internet; it is limited to specific, contained networks.
RPL，低功耗和有损网络的IPv6路由协议（参见[RFC6550]）使用ICMP作为传输。在这方面，它是ICMP消息类型中的一个例外。注意，尽管RPL是一个IP路由协议，但它并没有部署在通用Internet上；它仅限于特定的、包含的网络。
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 other protocols and SHOULD NOT be used in that way in future specifications. In particular, while it is adequate to use ICMP as a discovery protocol, it does not extend to full routing capabilities.
这应该被认为是异常的，并且不是未来ICMP消息类型的模型。也就是说，ICMP不打算用作其他协议的传输，在未来的规范中也不应以这种方式使用。特别是，虽然使用ICMP作为发现协议已经足够，但它并没有扩展到完整的路由功能。
Some applications make use of ICMP error notifications, or even deliberately create anomalous conditions in order to elicit ICMP messages. These ICMP messages are then used to generate feedback to the higher layer. Some of these applications include some of the most widespread examples, such as PING, TRACEROUTE, and Path MTU Discovery (PMTUD). These uses are considered acceptable because they use existing ICMP message types and do not change ICMP functionality.
一些应用程序利用ICMP错误通知，甚至故意创建异常条件以获取ICMP消息。然后使用这些ICMP消息生成对高层的反馈。其中一些应用程序包括一些最广泛的示例，如PING、TRACEROUTE和路径MTU发现（PMTUD）。这些使用被认为是可接受的，因为它们使用现有的ICMP消息类型，并且不会更改ICMP功能。
ICMP multi-part messages are specified in [RFC4884] by defining an extension mechanism for selected ICMP messages. This mechanism addresses a fundamental problem in ICMP extensibility. An ICMP multi-part message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require.
[RFC4884]中通过为所选ICMP消息定义扩展机制来指定ICMP多部分消息。这种机制解决了ICMP可扩展性中的一个基本问题。ICMP多部分消息包含以前ICMP消息包含的所有信息，以及应用程序可能需要的附加信息。
Some currently defined ICMP extensions include ICMP extensions for Multiprotocol Label Switching [RFC4950] and ICMP extensions for interface and next-hop identification [RFC5837].
一些当前定义的ICMP扩展包括用于多协议标签交换的ICMP扩展[RFC4950]和用于接口和下一跳标识的ICMP扩展[RFC5837]。
Extensions to ICMP SHOULD follow the requirements provided in [RFC4884].
ICMP的扩展应遵循[RFC4884]中提供的要求。
Because ICMPv6 is used for IPv6 Neighbor Discovery, deployed IPv6 routers, IPv6-capable security gateways, and IPv6-capable firewalls normally support administrator configuration of how specific ICMPv6 message types are handled. By contrast, deployed IPv4 routers, IPv4-capable security gateways, and IPv4-capable firewalls are less likely to allow an administrator to configure how specific ICMPv4 message types are handled. So, at present, ICMPv6 messages usually have a higher probability of travelling end-to-end than ICMPv4 messages.
由于ICMPv6用于IPv6邻居发现，部署的IPv6路由器、支持IPv6的安全网关和支持IPv6的防火墙通常支持管理员配置特定ICMPv6消息类型的处理方式。相比之下，部署的IPv4路由器、支持IPv4的安全网关和支持IPv4的防火墙不太可能允许管理员配置特定ICMPv4消息类型的处理方式。因此，目前，ICMPv6消息通常比ICMPv4消息具有更高的端到端传输概率。
ICMP was originally intended to be a mechanism for gateways or destination hosts to report error conditions back to source hosts in ICMPv4 [RFC0792]; ICMPv6 [RFC4443] is modeled after it. ICMP is also used to perform IP-layer functions, such as diagnostics (e.g., PING).
ICMP最初旨在成为网关或目标主机向ICMPv4[RFC0792]中的源主机报告错误情况的机制；ICMPv6[RFC4443]就是根据它建模的。ICMP还用于执行IP层功能，如诊断（如PING）。
ICMP is defined to be an integral part of IP and must be implemented by every IP module. This is true for ICMPv4 as an integral part of IPv4 (see the Introduction of [RFC0792]), and for ICMPv6 as an
ICMP被定义为IP的一个组成部分，必须由每个IP模块实现。对于作为IPv4不可分割的一部分的ICMPv4（请参阅[RFC0792]的介绍），以及作为IPv4的一部分的ICMPv6，都是如此
integral part of IPv6 (see Section 2 of [RFC4443]). When first defined, ICMP messages were thought of as IP messages that didn't carry any higher-layer data. It could be conjectured that the term "control" was used because ICMP messages were not "data" messages.
IPv6的组成部分（见[RFC4443]第2节）。最初定义时，ICMP消息被认为是不携带任何更高层数据的IP消息。可以推测，之所以使用术语“控制”，是因为ICMP消息不是“数据”消息。
The word "control" in the protocol name did not describe ICMP's function (i.e., it did not "control" the Internet); rather, it was used to communicate about the 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 not and is not used as a generic routing protocol.
协议名称中的“控制”一词没有描述ICMP的功能（即，它没有“控制”互联网）；相反，它被用来在互联网上交流控制功能。例如，尽管ICMP包含影响LAN网段上下文中路由行为的重定向消息类型，但它没有也没有用作通用路由协议。
This document describes 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, this recommendation presents no new security considerations.
本文档描述了添加ICMP类型和代码的高级策略。虽然必须特别注意任何特定的新ICMP类型或代码的安全影响，但本建议没有提出新的安全注意事项。
From a security perspective, ICMP plays a part in the Photuris protocol [RFC2521]. But more generally, ICMP is not a secure protocol and does not include features to be used to discover network security parameters or to report on network security anomalies in the forwarding plane.
从安全角度来看，ICMP在Photuris协议[RFC2521]中发挥了作用。但更一般地说，ICMP不是一种安全协议，不包括用于发现网络安全参数或报告转发平面中的网络安全异常的功能。
Additionally, new ICMP functionality (e.g., ICMP extensions, or new ICMP types or codes) needs to consider potential ways that ICMP can be abused (e.g., Smurf IP DoS [CA-1998-01]).
此外，新的ICMP功能（例如，ICMP扩展，或新的ICMP类型或代码）需要考虑ICMP可以滥用的潜在方式（例如，蓝精灵IP DOS [CA-1998—01]）。
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 very grateful for the review, feedback, and comments from Ran Atkinson, Tim Chown, Joe Clarke, Adrian Farrel, Ray Hunter, Hilarie Orman, Eric Rosen, JINMEI Tatuya, and Wen Zhang, which resulted in a much improved document.
本文件最初由Ron Bonica提出，并收到Ron Bonica的实质性审查和建议。与Pascal Thubert的讨论有助于澄清RPL使用ICMP的历史。我们非常感谢Ran Atkinson、Tim Chown、Joe Clarke、Adrian Farrel、Ray Hunter、Hilarie Orman、Eric Rosen、JINMEI Tatuya和Wen Zhang的审查、反馈和评论，这些都大大改进了文档。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
[RFC4884]Bonica，R.，Gan，D.，Tappan，D.，和C.Pignataro，“支持多部分消息的扩展ICMP”，RFC 4884，2007年4月。
[CA-1998-01] CERT, "Smurf IP Denial-of-Service Attacks", CERT Advisory CA-1998-01, January 1998, <http://www.cert.org/advisories/CA-1998-01.html>.
[CA-1998-01]证书，“Smurf IP拒绝服务攻击”，证书咨询CA-1998-01，1998年1月<http://www.cert.org/advisories/CA-1998-01.html>.
[DIAGNOSTICS] "IP Diagnostics Technical Interest Group", , <https://svn.tools.ietf.org/area/ops/trac/wiki/ TIG_DIAGNOSTICS>.
[诊断]“IP诊断技术兴趣小组”<https://svn.tools.ietf.org/area/ops/trac/wiki/ TIG_诊断>。
[RFC2521] Karn, P. and W. Simpson, "ICMP Security Failures Messages", RFC 2521, March 1999.
[RFC2521]Karn，P.和W.Simpson，“ICMP安全故障消息”，RFC 25211999年3月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780]Bradner，S.和V.Paxson，“互联网协议和相关报头中值的IANA分配指南”，BCP 37，RFC 2780，2000年3月。
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for Multiprotocol Label Switching", RFC 4950, August 2007.
[RFC4950]Bonica，R.，Gan，D.，Tappan，D.，和C.Pignataro，“多协议标签交换的ICMP扩展”，RFC 49502007年8月。
[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010.
[RFC5837]Atlas，A.，Bonica，R.，Pignataro，C.，Shen，N.，和JR.Rivers，“为接口和下一跳识别扩展ICMP”，RFC 5837，2010年4月。
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012.
[RFC6550]温特，T.，苏伯特，P.，勃兰特，A.，许，J.，凯尔西，R.，列维斯，P.，皮斯特，K.，斯特鲁克，R.，瓦塞尔，JP.，和R.亚历山大，“RPL：低功耗和有损网络的IPv6路由协议”，RFC 65502012年3月。
[RFC6918] Gont, F. and C. Pignataro, "Formally Deprecating Some ICMPv4 Message Types", RFC 6918, April 2013.
[RFC6918]Gont，F.和C.Pignataro，“正式反对某些ICMPv4消息类型”，RFC 6918，2013年4月。
Authors' Addresses
作者地址
Melinda Shore No Mountain Software PO Box 16271 Two Rivers, AK 99716 US
梅林达海岸无山软件邮政信箱16271二河，AK 99716美国
Phone: +1 907 322 9522
EMail: melinda.shore@nomountain.net
Phone: +1 907 322 9522
EMail: melinda.shore@nomountain.net
Carlos Pignataro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US
卡洛斯·皮格纳塔罗思科系统公司，美国北卡罗来纳州基特克里克路研究三角公园7200-12号，邮编：27709
EMail: cpignata@cisco.com
EMail: cpignata@cisco.com