Network Working Group P. Srisuresh
Request for Comments: 5508 Kazeon Systems
BCP: 148 B. Ford
Category: Best Current Practice MPI-SWS
S. Sivakumar
Cisco Systems
S. Guha
Cornell U.
April 2009
Network Working Group P. Srisuresh
Request for Comments: 5508 Kazeon Systems
BCP: 148 B. Ford
Category: Best Current Practice MPI-SWS
S. Sivakumar
Cisco Systems
S. Guha
Cornell U.
April 2009
NAT Behavioral Requirements for ICMP
ICMP的NAT行为要求
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the Internet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP, and other protocols.
本文件规定了网络地址转换器（NAT）设备与互联网控制消息协议（ICMP）相结合所需的行为属性。本备忘录的目的是使NAT设备更加可预测，并与穿越设备的各种应用程序协议兼容。附带文档提供了特定于TCP、UDP和其他协议的行为建议。
Table of Contents
目录
1. Introduction and Scope ..........................................3
2. Terminology .....................................................4
3. ICMP Query Handling .............................................6
3.1. ICMP Query Mapping .........................................6
3.2. ICMP Query Session Timeouts ................................7
4. ICMP Error Forwarding ...........................................8
4.1. ICMP Error Payload Validation ..............................8
4.2. ICMP Error Packet Translation .............................10
4.2.1. ICMP Error Packet Received from the External Realm .11
4.2.2. ICMP Error Packet Received from the Private Realm ..13
4.3. NAT Sessions Pertaining to ICMP Error Payload .............15
5. Hairpinning Support for ICMP Packets ...........................16
6. Rejection of Outbound Flows Disallowed by NAT ..................17
7. Conformance to RFC 1812 ........................................17
7.1. IP Packet Fragmentation ...................................19
7.1.1. Generating "Packet Too Big" ICMP Error Message ....19
7.1.2. Forwarding "Packet Too Big" ICMP Error Message ....20
7.2. Time Exceeded Message .....................................20
7.3. Source Route Options ......................................20
7.4. Address Mask Request/Reply Messages .......................20
7.5. Parameter Problem Message .................................21
7.6. Router Advertisement and Solicitations ....................21
7.7. DS Field Usage ............................................21
8. Non-QueryError ICMP Messages ...................................22
9. Summary of Requirements ........................................22
10. Security Considerations .......................................25
11. Acknowledgements ..............................................26
12. References ....................................................27
12.1. Normative References .....................................27
12.2. Informative References ...................................27
1. Introduction and Scope ..........................................3
2. Terminology .....................................................4
3. ICMP Query Handling .............................................6
3.1. ICMP Query Mapping .........................................6
3.2. ICMP Query Session Timeouts ................................7
4. ICMP Error Forwarding ...........................................8
4.1. ICMP Error Payload Validation ..............................8
4.2. ICMP Error Packet Translation .............................10
4.2.1. ICMP Error Packet Received from the External Realm .11
4.2.2. ICMP Error Packet Received from the Private Realm ..13
4.3. NAT Sessions Pertaining to ICMP Error Payload .............15
5. Hairpinning Support for ICMP Packets ...........................16
6. Rejection of Outbound Flows Disallowed by NAT ..................17
7. Conformance to RFC 1812 ........................................17
7.1. IP Packet Fragmentation ...................................19
7.1.1. Generating "Packet Too Big" ICMP Error Message ....19
7.1.2. Forwarding "Packet Too Big" ICMP Error Message ....20
7.2. Time Exceeded Message .....................................20
7.3. Source Route Options ......................................20
7.4. Address Mask Request/Reply Messages .......................20
7.5. Parameter Problem Message .................................21
7.6. Router Advertisement and Solicitations ....................21
7.7. DS Field Usage ............................................21
8. Non-QueryError ICMP Messages ...................................22
9. Summary of Requirements ........................................22
10. Security Considerations .......................................25
11. Acknowledgements ..............................................26
12. References ....................................................27
12.1. Normative References .....................................27
12.2. Informative References ...................................27
As pointed out in RFC 3424 [UNSAF], NAT implementations vary widely in terms of how they handle different traffic. The purpose of this document is to define a specific set of requirements for NAT behavior with regard to ICMP messages. The objective is to reduce the unpredictability and brittleness the NAT devices (NATs) introduce. This document is an adjunct to [BEH-UDP], [BEH-TCP], and other protocol-specific BEHAVE document(s) in the future that define requirements for NATs when handling protocol-specific traffic.
正如RFC3424[UNSAF]中指出的，NAT实现在如何处理不同流量方面存在很大差异。本文档的目的是定义有关ICMP消息的NAT行为的一组特定要求。目的是减少NAT设备（NAT）引入的不可预测性和脆性。本文档是[BEH-UDP]、[BEH-TCP]和未来其他协议特定行为文档的附件，这些文档定义了处理协议特定流量时NAT的要求。
The requirements of this specification apply to traditional NATs as described in [NAT-TRAD]. A traditional NAT has two variations, namely Basic NAT and Network Address Port Translator (NAPT). Of these, NAPT is by far the most commonly deployed NAT device. NAPT allows multiple private hosts to share a single public IP address simultaneously.
本规范的要求适用于[NAT-TRAD]中所述的传统NAT。传统的NAT有两种变体，即基本NAT和网络地址端口转换器（NAPT）。其中，NAPT是目前最常用的NAT设备。NAPT允许多个私有主机同时共享一个公共IP地址。
This document only covers the ICMP aspects of NAT traversal, specifically the traversal of ICMP Query messages and ICMP Error messages. Traditional NAT inherently mandates firewall-like filtering behavior [BEH-UDP]. However, firewall functionality in general or any other middlebox functionality is out of the scope of this document.
本文档仅涵盖NAT遍历的ICMP方面，特别是ICMP查询消息和ICMP错误消息的遍历。传统的NAT固有地要求类似防火墙的过滤行为[BEH-UDP]。但是，一般的防火墙功能或任何其他中间包功能不在本文档的范围内。
In some cases, ICMP message traversal behavior on a NAT device may be overridden by local administrative policies. Some administrators may choose to entirely prohibit forwarding of ICMP Error messages across a NAT device. Some others may choose to prohibit ICMP-Query-based applications across a NAT device. These are local policies and not within the scope of this document. For this reason, some of the ICMP requirements listed in the document are preceded with a constraint of local policy permitting.
在某些情况下，NAT设备上的ICMP消息遍历行为可能会被本地管理策略覆盖。一些管理员可能会选择完全禁止跨NAT设备转发ICMP错误消息。其他一些人可能会选择禁止跨NAT设备的基于ICMP查询的应用程序。这些是本地政策，不在本文件范围内。因此，文件中列出的一些ICMP要求之前有当地政策允许的限制。
This document focuses strictly on the behavior of the NAT device, and not on the behavior of applications that traverse NATs. Application designers may refer to [BEH-APP] and [ICE] for recommendations and guidelines on how to make applications work robustly over NATs that follow the requirements specified here and the adjunct protocol-specific BEHAVE documents.
本文档严格关注NAT设备的行为，而不是遍历NAT的应用程序的行为。应用程序设计人员可参考[BEH-APP]和[ICE]以了解有关如何使应用程序在NAT上稳健工作的建议和指南，NAT应遵循此处规定的要求和附加协议特定的行为文档。
Per [RFC1812], ICMP is a control protocol that is considered to be an integral part of IP, although it is architecturally layered upon IP -- it uses IP to carry its data end-to-end. As such, many of the ICMP behavioral requirements discussed in this document apply to all IP protocols.
根据[RFC1812]，ICMP是一种被认为是IP不可分割的一部分的控制协议，尽管它在体系结构上是基于IP的——它使用IP端到端地传输数据。因此，本文件中讨论的许多ICMP行为要求适用于所有IP协议。
In case a requirement in this document conflicts with protocol-specific BEHAVE requirement(s), protocol-specific BEHAVE documents will take precedence. The authors are not aware of any conflicts between this and any other IETF document at the time of this writing.
如果本文件中的要求与协议特定的行为要求冲突，则以协议特定的行为文件为准。在撰写本文时，作者不知道本文件与任何其他IETF文件之间存在任何冲突。
Section 2 describes the terminology used throughout the document. Section 3 is focused on requirements concerning ICMP-Query-based applications traversing a NAT device. Sections 4 and 5 describe requirements concerning ICMP Error messages traversing a NAT device. Sections 6 describes requirements concerning ICMP Error messages generated by a NAT device. Section 7 reviews RFC 1812 conformance requirements and applicability to NATs when handling ICMP messages. Section 8 reviews a requirement for ICMP messages that are neither ICMP Query nor ICMP Error kind. Section 9 summarizes all the requirements in one place. Section 10 has a discussion on security considerations.
第2节描述了本文件中使用的术语。第3节的重点是关于穿越NAT设备的基于ICMP查询的应用程序的需求。第4节和第5节描述了有关穿越NAT设备的ICMP错误消息的要求。第6节描述了有关NAT设备生成的ICMP错误消息的要求。第7节回顾了RFC1812的一致性要求以及在处理ICMP消息时对NAT的适用性。第8节审查了既不是ICMP查询也不是ICMP错误类型的ICMP消息的要求。第9节总结了一个地方的所有要求。第10节讨论了安全注意事项。
Definitions for the majority of the NAT terms used throughout the document may be found in [NAT-TERM] and [BEH-UDP].
本文件中使用的大多数NAT术语的定义见[NAT-TERM]和[BEH-UDP]。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The term "Realm" is adapted from [NAT-TERM] and is defined as follows. "Realm" is often interchanged for "network domain" or simply "network" throughout the document.
术语“领域”改编自[NAT-term]，定义如下。在整个文档中，“领域”通常被替换为“网络域”或简单的“网络”。
Address realm or Realm - An address realm is a network domain in which the network addresses are uniquely assigned to entities such that datagrams can be routed to them. Routing protocols used within the network domain are responsible for finding routes to entities given their network addresses. Note that this document is limited to describing NAT in the IPv4 environment and does not address the use of NAT in other types of environments (e.g., the IPV6 environment).
地址域或域-地址域是一个网络域，其中网络地址被唯一分配给实体，以便数据报可以路由到实体。网络域中使用的路由协议负责查找到给定网络地址的实体的路由。请注意，本文档仅限于描述IPv4环境中的NAT，而不涉及NAT在其他类型环境（例如IPV6环境）中的使用。
The term "NAT Session" is adapted from [NAT-MIB] and is defined as follows:
术语“NAT会话”改编自[NAT-MIB]，定义如下：
NAT Session - A NAT session is an association between a session as seen in the private realm and a session as seen in the public realm, by virtue of NAT translation. If a session in the private realm were to be represented as (PrivateSrcAddr, PrivateDstAddr, TransportProtocol, PrivateSrcPort, PrivateDstPort) and the same session in the public realm were to be represented as (PublicSrcAddr, PublicDstAddr, TransportProtocol, PublicSrcPort, PublicDstPort), the
NAT会话-NAT会话是通过NAT转换在私有领域中看到的会话和公共领域中看到的会话之间的关联。如果私有领域中的会话表示为（PrivateScAddr、PrivateStAddr、TransportProtocol、PrivateScPort、PrivateStPort），而公共领域中的同一会话表示为（PublicSrcAddr、PublicDsAddr、TransportProtocol、PublicSrcPort、PublicDsPort），则
NAT session would provide the translation glue between the two session representations. NAT sessions in the document are restricted to sessions based on TCP, UDP, and ICMP. In the future, NAT sessions may be extended to be based on other transport protocols such as Stream Control Transmission Protocol (SCTP), UDP-lite, and Datagram Congestion Control Protocol (DCCP).
NAT会话将在两个会话表示之间提供转换粘合剂。文档中的NAT会话仅限于基于TCP、UDP和ICMP的会话。将来，NAT会话可以扩展为基于其他传输协议，例如流控制传输协议（SCTP）、UDP-lite和数据报拥塞控制协议（DCCP）。
ICMP Message Classification - Section 3.2.2 of [RFC1122] and Section 4.3.1 of [RFC1812] broadly group ICMP messages into two main categories, namely "ICMP Query" messages and "ICMP Error" messages. All ICMP Error messages listed in RFC 1122 and RFC 1812 contain part of the Internet datagram that elicited the ICMP error. All the ICMP Query messages listed in RFC 1122 and RFC 1812 contain an "Identifier" field, which is referred to in this document as the "Query Identifier". There are however ICMP messages that do not fall into either of these two categories. We refer to them as "Non-QueryError ICMP Messages". All three ICMP message classes are described as follows:
ICMP报文分类——[RFC1122]第3.2.2节和[RFC1812]第4.3.1节将ICMP报文大致分为两大类，即“ICMP查询”报文和“ICMP错误”报文。RFC 1122和RFC 1812中列出的所有ICMP错误消息都包含引发ICMP错误的部分Internet数据报。RFC 1122和RFC 1812中列出的所有ICMP查询消息都包含一个“标识符”字段，在本文档中称为“查询标识符”。但是，有一些ICMP消息不属于这两类中的任何一类。我们将其称为“非查询错误ICMP消息”。所有三个ICMP消息类的描述如下：
o ICMP Query Messages - ICMP Query messages are characterized by an Identifier field in the ICMP header. The Identifier field used by the ICMP Query messages is also referred to as "Query Identifier" or "Query Id", for short throughout the document. A Query Id is used by Query senders and responders as the equivalent of a TCP/UDP port to identify an ICMP Query session. ICMP Query messages include ICMP messages defined after RFC 1122 or RFC 1812 (for example, Domain Name Request/Reply ICMP messages defined in RFC 1788), as they include request/response pairs and contain an "Identifier" field.
o ICMP查询消息-ICMP查询消息由ICMP标头中的标识符字段表示。ICMP查询消息使用的标识符字段在整个文档中也称为“查询标识符”或“查询Id”。查询发送方和响应方使用查询Id作为TCP/UDP端口的等效项来标识ICMP查询会话。ICMP查询消息包括RFC 1122或RFC 1812之后定义的ICMP消息（例如，RFC 1788中定义的域名请求/回复ICMP消息），因为它们包括请求/响应对并包含“标识符”字段。
o ICMP Error Messages - ICMP Error messages provide signaling for IP. All ICMP Error messages are characterized by the fact that they embed the original datagram that triggered the ICMP Error message. The original datagram embedded within the ICMP Error payload is also referred to as the "Embedded packet" throughout the document. Unlike ICMP Query messages, ICMP Error messages do not have a Query Id in the ICMP header.
o ICMP错误消息-ICMP错误消息为IP提供信令。所有ICMP错误消息的特点是嵌入触发ICMP错误消息的原始数据报。嵌入在ICMP错误有效载荷中的原始数据报在整个文档中也称为“嵌入数据包”。与ICMP查询消息不同，ICMP错误消息在ICMP标头中没有查询Id。
o Non-QueryError ICMP Messages - ICMP messages that do not fall under either of the above two classes are referred to as "Non-QueryError ICMP Messages" throughout the document. For example, Router Discovery ICMP messages [RFC1256] are "request/response" type ICMP messages. However, they are not characterized as ICMP Query messages in this document as they do not have an "Identifier" field within the messages. Likewise, there are other ICMP messages defined in [RFC4065] that do not fall in either of the ICMP Query or ICMP Error message categories, but will be referred to as Non-QueryError ICMP messages.
o 非查询错误ICMP消息-不属于上述两类的ICMP消息在整个文档中称为“非查询错误ICMP消息”。例如，路由器发现ICMP消息[RFC1256]是“请求/响应”类型的ICMP消息。但是，在本文档中，它们没有被描述为ICMP查询消息，因为它们在消息中没有“标识符”字段。同样，[RFC4065]中定义的其他ICMP消息不属于ICMP查询或ICMP错误消息类别，但将被称为非查询错误ICMP消息。
The reason for categorizing ICMP messages for NAT behavioral properties is that each category has different characteristics used for mapping (i.e., the Query Id and the Embedded datagram), which leaves the Non-QueryError ICMP messages in a separate, distinctive group.
根据NAT行为属性对ICMP消息进行分类的原因是，每个类别都具有用于映射的不同特征（即查询Id和嵌入的数据报），这使得非QueryError ICMP消息处于一个单独的、独特的组中。
This section lists the behavioral requirements for a NAT device when processing ICMP Query packets. The following subsections discuss requirements specific to ICMP Query handling in detail.
本节列出了NAT设备在处理ICMP查询数据包时的行为要求。以下小节详细讨论了特定于ICMP查询处理的要求。
Unless explicitly overridden by local policy, a NAT device MUST permit ICMP Queries and their associated responses, when the Query is initiated from a private host to the external hosts. ICMP Query mapping by NAT devices is necessary for current ICMP-Query-based applications to work. This entails a NAT device to transparently forward ICMP Query packets initiated from the nodes behind NAT, and the responses to these Query packets in the opposite direction. As specified in [NAT-TRAD], this requires translating the IP header. A NAPT device further translates the ICMP Query Id and the associated checksum in the ICMP header prior to forwarding.
除非本地策略明确覆盖，否则当从专用主机向外部主机发起查询时，NAT设备必须允许ICMP查询及其相关响应。NAT设备的ICMP查询映射是当前基于ICMP查询的应用程序工作所必需的。这需要NAT设备透明地转发从NAT后面的节点发起的ICMP查询数据包，以及以相反方向对这些查询数据包的响应。如[NAT-TRAD]中所述，这需要翻译IP头。NAPT设备在转发之前进一步转换ICMP查询Id和ICMP报头中的相关校验和。
NAT mapping of ICMP Query Identifiers SHOULD be external-host independent. Say, an internal host A sent an ICMP Query out to an external host B using Query Id X. And, say, the NAT assigned this an external mapping of Query Id X' on the NAT's public address. If host A reused the Query Id X to send ICMP Queries to the same or different external host, the NAT device SHOULD reuse the same Query Id mapping (i.e., map the private host's Query Id X to Query Id X' on NAT's public IP address) instead of assigning a different mapping. This is similar to the "endpoint independent mapping" requirement specified in the TCP and UDP requirement documents [BEH-UDP], [BEH-TCP].
ICMP查询标识符的NAT映射应独立于外部主机。例如，内部主机A使用查询Id X向外部主机B发送ICMP查询。并且，例如，NAT将查询Id X'的外部映射分配给NAT的公共地址。如果主机A重用查询Id X向相同或不同的外部主机发送ICMP查询，则NAT设备应重用相同的查询Id映射（即，将专用主机的查询Id X映射到NAT公共IP地址上的查询Id X’，而不是分配不同的映射。这类似于TCP和UDP需求文档[BEH-UDP]、[BEH-TCP]中指定的“端点独立映射”需求。
Below is justification for making the endpoint-independent mapping for ICMP Query Id a SHOULD [RFC2119] requirement. ICMP Ping [RFC1470] and ICMP traceroute [MS-TRCRT] are two most commonly known legacy applications built on top of ICMP Query messages. Neither of these applications require the ICMP Query Id to be retained across different sessions with external hosts. But, that may not be the case with future applications. In the future, when an end host application reuses the same Query Identifier in sessions with different target hosts, the end host application might require that the endpoint identity (i.e., the tuple of IP address and Query Identifier) appears the same across all its target hosts. In an IP network without NAT requirements, such a requirement will be valid.
下面是根据[RFC2119]要求为ICMP查询Id进行端点独立映射的理由。ICMP Ping[RFC1470]和ICMP traceroute[MS-TRCRT]是构建在ICMP查询消息之上的两个最常见的遗留应用程序。这两种应用程序都不要求在与外部主机的不同会话中保留ICMP查询Id。但是，未来的应用可能并非如此。将来，当终端主机应用程序在与不同目标主机的会话中重用相同的查询标识符时，终端主机应用程序可能要求端点标识（即IP地址和查询标识符的元组）在其所有目标主机上显示相同。在没有NAT要求的IP网络中，这样的要求是有效的。
In a world with NAT devices, the above assumption will be valid when NAT devices enforce endpoint mapping that is external-host independent. Given the dichotomy between legacy applications not requiring endpoint-independent mapping and future applications that might require it, the requirement level is kept at SHOULD [RFC2119].
在使用NAT设备的世界中，当NAT设备强制执行独立于外部主机的端点映射时，上述假设将是有效的。考虑到不需要端点独立映射的遗留应用程序和可能需要端点独立映射的未来应用程序之间的二分法，需求级别保持在SHOULD[RFC2119]。
REQ-1: Unless explicitly overridden by local policy, a NAT device MUST permit ICMP Queries and their associated responses, when the Query is initiated from a private host to the external hosts.
REQ-1：除非本地策略明确覆盖，否则当从专用主机向外部主机发起查询时，NAT设备必须允许ICMP查询及其相关响应。
a) NAT mapping of ICMP Query Identifiers SHOULD be external-host independent.
a) ICMP查询标识符的NAT映射应独立于外部主机。
NATs maintain a mapping timeout for the ICMP Queries that traverse them. The mapping timeout is the time a mapping will stay active without packets traversing the NAT. There is great variation in the values used by different NATs. The ICMP Query session timeout requirement is necessary for current ICMP Query applications to work. Query response times can vary. ICMP-Query-based applications are primarily request/response driven.
NAT为遍历它们的ICMP查询维护映射超时。映射超时是在数据包不通过NAT的情况下映射保持活动状态的时间。不同NAT使用的值差异很大。ICMP查询会话超时要求是当前ICMP查询应用程序工作所必需的。查询响应时间可能会有所不同。基于ICMP查询的应用程序主要由请求/响应驱动。
Ideally, the timeout should be set to Maximum Round Trip Time (Maximum RTT). For the purposes of constraining the maximum RTT, the Maximum Segment Lifetime (MSL), defined in [RFC793], could be considered a guideline to set packet lifetime. Per [RFC793], MSL is the maximum amount of time a TCP segment can exist in a network before being delivered to the intended recipient. This is the maximum duration an IP packet can be assumed to take to reach the intended destination node before declaring that the packet will no longer be delivered. For an application initiating an ICMP Query message and waiting for a response for the Query, the Maximum RTT could in practice be constrained to be the sum total of MSL for the Query message and MSL for the response message. In other words, Maximum RTT could be constrained to no more than 2x MSL. The recommended value for MSL in [RFC793] is 120 seconds, even though several implementations set this to 60 seconds or 30 seconds. When MSL is 120 seconds, the Maximum RTT (2x MSL) would be 240 seconds.
理想情况下，超时应设置为最大往返时间（最大RTT）。为了限制最大RTT，可将[RFC793]中定义的最大段生存期（MSL）视为设置数据包生存期的指南。根据[RFC793]，MSL是TCP段在交付给预期收件人之前可以存在于网络中的最长时间。这是一个IP数据包在声明该数据包将不再被传送之前，到达预定目的地节点所需的最长持续时间。对于启动ICMP查询消息并等待查询响应的应用程序，最大RTT实际上可以限制为查询消息的MSL和响应消息的MSL之和。换句话说，最大RTT可以限制为不超过2倍MSL。[RFC793]中MSL的建议值为120秒，即使有几个实现将其设置为60秒或30秒。当MSL为120秒时，最大RTT（2x MSL）为240秒。
In practice, ICMP Ping [RFC1470] and ICMP traceroute [MS-TRCRT], the two most commonly known legacy applications built on top of ICMP Query messages, take less than 10 seconds to complete a round trip when the target node is operational on the network.
实际上，当目标节点在网络上运行时，ICMP Ping[RFC1470]和ICMP traceroute[MS-TRCRT]这两个基于ICMP查询消息构建的最常见的传统应用程序只需不到10秒的时间即可完成一次往返。
Setting the ICMP NAT session timeout to a very large duration (say, 240 seconds) could potentially tie up precious NAT resources such as Query mappings and NAT Sessions for the whole duration. On the other hand, setting the timeout very low can result in premature freeing of NAT resources and applications failing to complete gracefully. The ICMP Query session timeout needs to be a balance between the two extremes. A 60-second timeout is a balance between the two extremes. An ICMP Query session timer MUST NOT expire in less than 60 seconds. It is RECOMMENDED that the ICMP Query session timer be made configurable.
将ICMP NAT会话超时设置为非常长的持续时间（例如240秒）可能会在整个持续时间内占用宝贵的NAT资源，如查询映射和NAT会话。另一方面，将超时设置得很低可能会导致过早释放NAT资源，并且应用程序无法正常完成。ICMP查询会话超时需要在两个极端之间保持平衡。60秒超时是两个极端之间的平衡。ICMP查询会话计时器不得在60秒内过期。建议配置ICMP查询会话计时器。
REQ-2: An ICMP Query session timer MUST NOT expire in less than 60 seconds.
REQ-2:ICMP查询会话计时器不得在60秒内过期。
a) It is RECOMMENDED that the ICMP Query session timer be made configurable.
a) 建议配置ICMP查询会话计时器。
Many applications make use of ICMP Error messages from end hosts and intermediate devices to shorten application timeouts. Some applications will not operate correctly without the receipt of ICMP Error messages. The following sub-sections discuss the requirements a NAT device must conform to in order to ensure reliable forwarding.
许多应用程序利用来自终端主机和中间设备的ICMP错误消息来缩短应用程序超时。如果未收到ICMP错误消息，某些应用程序将无法正常运行。以下小节讨论NAT设备必须符合的要求，以确保可靠的转发。
An ICMP Error message checksum covers the entire ICMP message, including the payload. When an ICMP Error packet is received, if the ICMP checksum fails to validate, the NAT SHOULD silently drop the ICMP Error packet. This is because NAT uses the embedded IP and transport headers for forwarding and translating the ICMP Error message (described in Section 4.2). When the ICMP checksum is invalid, the embedded IP and transport headers, which are covered by the ICMP checksum, are also suspect.
ICMP错误消息校验和覆盖整个ICMP消息，包括有效负载。当接收到ICMP错误数据包时，如果ICMP校验和未能验证，NAT应自动丢弃ICMP错误数据包。这是因为NAT使用嵌入式IP和传输头转发和转换ICMP错误消息（如第4.2节所述）。当ICMP校验和无效时，ICMP校验和覆盖的嵌入式IP和传输头也会受到怀疑。
[RFC1812] and [RFC1122] require a router or an end host that receives an IP packet with an invalid IP header checksum to silently drop the IP packet. As such, end hosts and routers do not generate an ICMP Error message in response to IP packets with invalid IP header checksums. For this reason, if the IP checksum of the embedded packet within an ICMP Error message fails to validate, the NAT SHOULD silently drop the Error packet.
[RFC1812]和[RFC1122]要求接收IP数据包的路由器或终端主机使用无效IP报头校验和以静默方式丢弃IP数据包。因此，终端主机和路由器不会生成ICMP错误消息来响应具有无效IP报头校验和的IP数据包。因此，如果ICMP错误消息中嵌入数据包的IP校验和无法验证，则NAT应自动丢弃错误数据包。
When the IP packet embedded within the ICMP Error message includes IP options, the NAT device must not assume that the transport header of the embedded packet is at a fixed offset (as would be the case when there are no IP options associated with the packet) from the start of
当嵌入在ICMP错误消息中的IP分组包括IP选项时，NAT设备不得假定嵌入分组的传输报头处于从开始到结束的固定偏移量（如没有与分组相关联的IP选项时的情况）
the embedded packet. Specifically, if the embedded packet includes IP options, the NAT device MUST traverse past the IP options to locate the start of transport header for the embedded packet.
嵌入的数据包。具体地说，如果嵌入式分组包括IP选项，则NAT设备必须穿过IP选项以定位嵌入式分组的传输开始报头。
It is possible to compute the transport checksum of the embedded packet within an ICMP Error message when the ICMP Error message contains the entire transport segment. However, ICMP Error messages do not contain the entire transport segment in many cases. This is because [ICMP] stipulates that an ICMP Error message should embed an IP header and only a minimum of 64 bits of the IP payload. Even though Section 4.3.2.3 of [RFC1812] recommends an ICMP Error originator include as much of the original packet as possible in the payload, the length of the resulting ICMP datagram cannot exceed 576 bytes. ICMP Error originators truncate IP packets that do not fit within the stipulations.
当ICMP错误消息包含整个传输段时，可以计算ICMP错误消息中嵌入数据包的传输校验和。但是，在许多情况下，ICMP错误消息并不包含整个传输段。这是因为[ICMP]规定ICMP错误消息应嵌入IP报头和至少64位的IP有效负载。尽管[RFC1812]第4.3.2.3节建议ICMP错误发起人在有效负载中尽可能多地包含原始数据包，但产生的ICMP数据报的长度不能超过576字节。ICMP错误发起人截断不符合规定的IP数据包。
A NAT device SHOULD NOT validate the transport checksum of the embedded packet within an ICMP Error message, even when it is possible to do so. This is because a NAT dropping an ICMP Error message due to an invalid transport checksum will make it harder for end hosts to receive error reporting for certain types of corruption. End-to-end validation of ICMP Error messages is best left to end hosts. Many newer revision end host TCP/IP stacks implement the improvements in [TCP-SOFT] and do not accept ICMP Error messages with a mismatched IP or TCP checksum in the embedded packet, if the embedded datagram contains a full IP packet and the TCP checksum can be calculated.
NAT设备不应验证ICMP错误消息中嵌入数据包的传输校验和，即使在可能的情况下也是如此。这是因为NAT由于无效的传输校验和而丢弃ICMP错误消息将使终端主机更难接收特定类型损坏的错误报告。ICMP错误消息的端到端验证最好由端主机进行。许多较新版本的终端主机TCP/IP堆栈实现了[TCP-SOFT]中的改进，如果嵌入式数据报包含完整的IP数据包并且可以计算TCP校验和，则不接受嵌入数据包中IP或TCP校验和不匹配的ICMP错误消息。
In the case that the ICMP Error payload includes ICMP extensions [ICMP-EXT], the NAT device MUST exclude the optional zero-padding and the ICMP extensions when evaluating transport checksum for the embedded packet. Readers are urged to refer to [ICMP-EXT] for information on identifying the presence of ICMP extensions in an ICMP message.
如果ICMP错误有效负载包括ICMP扩展[ICMP-EXT]，则NAT设备在评估嵌入式数据包的传输校验和时必须排除可选的零填充和ICMP扩展。请读者参考[ICMP-EXT]，了解有关识别ICMP消息中是否存在ICMP扩展的信息。
REQ-3: When an ICMP Error packet is received, if the ICMP checksum fails to validate, the NAT SHOULD silently drop the ICMP Error packet. If the ICMP checksum is valid, do the following:
REQ-3：当接收到ICMP错误数据包时，如果ICMP校验和无法验证，NAT应自动丢弃ICMP错误数据包。如果ICMP校验和有效，请执行以下操作：
a) If the IP checksum of the embedded packet fails to validate, the NAT SHOULD silently drop the Error packet; and
a) 如果嵌入数据包的IP校验和无法验证，NAT应静默丢弃错误数据包；和
b) If the embedded packet includes IP options, the NAT device MUST traverse past the IP options to locate the start of the transport header for the embedded packet; and
b) 如果嵌入式分组包括IP选项，则NAT设备必须穿过IP选项以定位嵌入式分组的传输报头的开始；和
c) The NAT device SHOULD NOT validate the transport checksum of the embedded packet within an ICMP Error message, even when it is possible to do so; and
c) NAT设备不应验证ICMP错误消息中嵌入数据包的传输校验和，即使在可能的情况下也是如此；和
d) If the ICMP Error payload contains ICMP extensions [ICMP-EXT], the NAT device MUST exclude the optional zero-padding and the ICMP extensions when evaluating transport checksum for the embedded packet.
d) 如果ICMP错误负载包含ICMP扩展[ICMP-EXT]，则NAT设备在评估嵌入式数据包的传输校验和时必须排除可选的零填充和ICMP扩展。
Section 4.3 of [NAT-TRAD] describes the fields of an ICMP Error message that a NAT device translates. In this section, we describe the requirements a NAT device must conform to while performing the translations. Requirements identified in this section are necessary for the current applications to work correctly.
[NAT-TRAD]的第4.3节描述了NAT设备翻译的ICMP错误消息的字段。在本节中，我们描述了NAT设备在执行翻译时必须遵守的要求。本节中确定的要求是当前应用程序正常工作所必需的。
Consider the following scenario in Figure 1. Say, NAT-xy is a NAT device connecting hosts in private and external networks. Router-x and Host-x are in the external network. Router-y and Host-y are in the private network. The subnets in the external network are routable from the private as well as the external domains. By contrast, the subnets in the private network are only routable within the private domain. When Host-y initiated a session to Host-x, let us say that the NAT device mapped the endpoint on Host-y into Host-y' in the external network. The following subsections describe the processing of ICMP Error messages on the NAT device(NAT-xy) when the NAT device receives an ICMP Error message in response to a packet pertaining to this session.
在图1中考虑下面的场景。比如说，NAT xy是一种NAT设备，用于连接专用网络和外部网络中的主机。路由器-x和主机-x位于外部网络中。路由器-y和主机-y位于专用网络中。外部网络中的子网可以从专用域和外部域进行路由。相比之下，专用网络中的子网只能在专用域内路由。当Host-y启动到Host-x的会话时，假设NAT设备将Host-y上的端点映射到外部网络中的Host-y’。以下小节描述了当NAT设备收到ICMP错误消息以响应与此会话相关的数据包时，NAT设备（NAT xy）上ICMP错误消息的处理。
Host-x
|
---------------+-------------------
|
+-------------+
| Router-x |
+-------------+
External Network |
--------------------+--------+-------------------
| ^
| | (Host-y', Host-x)
| |
+-------------+
| NAT-xy |
+-------------+
|
Private Network |
----------------+------------+----------------
|
+-------------+
| Router-y |
+-------------+
|
----------------+-------+--------
| ^
| | (Host-y, Host-x)
| |
Host-y
Host-x
|
---------------+-------------------
|
+-------------+
| Router-x |
+-------------+
External Network |
--------------------+--------+-------------------
| ^
| | (Host-y', Host-x)
| |
+-------------+
| NAT-xy |
+-------------+
|
Private Network |
----------------+------------+----------------
|
+-------------+
| Router-y |
+-------------+
|
----------------+-------+--------
| ^
| | (Host-y, Host-x)
| |
Host-y
Figure 1. A Session from a Private Host Traversing a NAT Device
图1。从私有主机穿越NAT设备的会话
Say, a packet from Host-y to Host-x triggered an ICMP Error message from one of Router-x or Host-x (both of which are in the external domain). Such an ICMP Error packet will have one of Router-x or Host-x as the source IP address and Host-y' as the destination IP address as described in Figure 2 below.
比如说，从主机y到主机x的数据包触发了来自路由器x或主机x之一（两者都在外域中）的ICMP错误消息。这种ICMP错误数据包将以路由器-x或主机-x中的一个作为源IP地址，主机-y'作为目标IP地址，如下图2所示。
Host-x
|
---------------+-------------------
|
+-------------+
| Router-x |
+-------------+
External Network |
--------------------+--------+-------------------
|
| | ICMP Error Packet to Host-y'
| v
+-------------+
| NAT-xy |
+-------------+
Private Network |
----------------+------------+----------------
|
+-------------+
| Router-y |
+-------------+
|
----------------+-------+--------
|
Host-y
Host-x
|
---------------+-------------------
|
+-------------+
| Router-x |
+-------------+
External Network |
--------------------+--------+-------------------
|
| | ICMP Error Packet to Host-y'
| v
+-------------+
| NAT-xy |
+-------------+
Private Network |
----------------+------------+----------------
|
+-------------+
| Router-y |
+-------------+
|
----------------+-------+--------
|
Host-y
Figure 2. ICMP Error Packet Received from External Network
图2。从外部网络接收到ICMP错误数据包
When the NAT device receives the ICMP Error packet, the NAT device uses the packet embedded within the ICMP Error message (i.e., the IP packet from Host-y' to Host-x) to look up the NAT Session to which the embedded packet belongs. If the NAT device does not have an active mapping for the embedded packet, the NAT SHOULD silently drop the ICMP Error packet. Otherwise, the NAT device MUST use the matching NAT Session to translate the embedded packet; that is, translate the source IP address of the embedded packet (e.g., Host-y' -> Host-y) and transport headers.
当NAT设备接收到ICMP错误包时，NAT设备使用嵌入在ICMP错误消息中的包（即，从主机-y'到主机-x的IP包）来查找嵌入包所属的NAT会话。如果NAT设备没有嵌入式数据包的活动映射，则NAT应静默地丢弃ICMP错误数据包。否则，NAT设备必须使用匹配的NAT会话来翻译嵌入的数据包；也就是说，转换嵌入数据包的源IP地址（例如，Host-y'->Host-y）和传输头。
The ICMP Error payload may contain ICMP extension objects [ICMP-EXT]. NATs are encouraged to support ICMP extension objects. At the time of this writing, the authors are not aware of any standard ICMP extension objects containing realm-specific information.
ICMP错误负载可能包含ICMP扩展对象[ICMP-EXT]。鼓励NAT支持ICMP扩展对象。在撰写本文时，作者还不知道有任何标准的ICMP扩展对象包含领域特定的信息。
The NAT device MUST also use the matching NAT Session to translate the destination IP address in the outer IP header. In the outer header, the source IP address will remain unchanged because the originator of the ICMP Error message (Host-x or Router-x) is in an external domain and is routable from the private domain.
NAT设备还必须使用匹配的NAT会话来转换外部IP报头中的目标IP地址。在外部报头中，源IP地址将保持不变，因为ICMP错误消息（Host-x或Router-x）的发起者位于外部域中，并且可以从私有域进行路由。
REQ-4: If a NAT device receives an ICMP Error packet from an external realm, and the NAT device does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP Error packet. If the NAT has active mapping for the embedded payload, then the NAT MUST do the following prior to forwarding the packet, unless explicitly overridden by local policy:
REQ-4：如果NAT设备从外部领域接收到ICMP错误数据包，并且NAT设备没有嵌入式有效负载的活动映射，则NAT应该静默地丢弃ICMP错误数据包。如果NAT具有嵌入式有效负载的活动映射，则NAT必须在转发数据包之前执行以下操作，除非本地策略明确覆盖：
a) Revert the IP and transport headers of the embedded IP packet to their original form, using the matching mapping; and
a) 使用匹配映射将嵌入式IP数据包的IP和传输头还原为其原始形式；和
b) Leave the ICMP Error type and code unchanged; and
b) 保持ICMP错误类型和代码不变；和
c) Modify the destination IP address of the outer IP header to be the same as the source IP address of the embedded packet after translation.
c) 将外部IP头的目标IP地址修改为与翻译后嵌入数据包的源IP地址相同。
Now, say, a packet from Host-x to Host-y triggered an ICMP Error message from one of Router-y or Host-y (both of which are in the private domain). Such an ICMP Error packet will have one of Router-y or Host-y as the source IP address and Host-x as the destination IP address as specified in Figure 3 below.
现在，比方说，从主机x到主机y的数据包触发了来自路由器y或主机y之一（两者都在私有域中）的ICMP错误消息。如下图3所示，这样的ICMP错误数据包将以Router-y或Host-y中的一个作为源IP地址，以Host-x作为目标IP地址。
Host-x
|
---------------+-------------------
|
+-------------+
| Router-x |
+-------------+
External Network |
--------------------+--------+-------------------
|
|
+-------------+
| NAT-xy |
+-------------+
| ^
| | ICMP Error Packet to Host-x
Private Network |
----------------+------------+----------------
|
+-------------+
| Router-y |
+-------------+
|
----------------+-------+--------
|
Host-y
Host-x
|
---------------+-------------------
|
+-------------+
| Router-x |
+-------------+
External Network |
--------------------+--------+-------------------
|
|
+-------------+
| NAT-xy |
+-------------+
| ^
| | ICMP Error Packet to Host-x
Private Network |
----------------+------------+----------------
|
+-------------+
| Router-y |
+-------------+
|
----------------+-------+--------
|
Host-y
Figure 3. ICMP Error Packet Received from Private Network
图3。从专用网络接收到ICMP错误数据包
When the NAT device receives the ICMP Error packet, the NAT device MUST use the packet embedded within the ICMP Error message (i.e., the IP packet from Host-x to Host-y) to look up the NAT Session to which the embedded packet belongs. If the NAT device does not have an active mapping for the embedded packet, the NAT SHOULD silently drop the ICMP Error packet. Otherwise, the NAT device MUST use the matching NAT Session to translate the embedded packet.
当NAT设备接收到ICMP错误数据包时，NAT设备必须使用嵌入ICMP错误消息中的数据包（即，从主机x到主机y的IP数据包）来查找嵌入数据包所属的NAT会话。如果NAT设备没有嵌入式数据包的活动映射，则NAT应静默地丢弃ICMP错误数据包。否则，NAT设备必须使用匹配的NAT会话来翻译嵌入的数据包。
The ICMP Error payload may contain ICMP extension objects [ICMP-EXT]. NATs are encouraged to support ICMP extension objects. At the time of this writing, the authors are not aware of any standard ICMP extension objects containing realm-specific information.
ICMP错误负载可能包含ICMP扩展对象[ICMP-EXT]。鼓励NAT支持ICMP扩展对象。在撰写本文时，作者还不知道有任何标准的ICMP扩展对象包含领域特定的信息。
In the outer header, the destination IP address will remain unchanged, as the IP address for Host-x is already in the external domain. If the ICMP Error message is generated by Host-y, the NAT device must simply use the NAT Session to translate the source IP address Host-y to Host-y'. If the ICMP Error message is originated by the intermediate node Router-y, translation of the source IP
在外部报头中，目标IP地址将保持不变，因为主机x的IP地址已在外部域中。如果ICMP错误消息是由Host-y生成的，则NAT设备必须简单地使用NAT会话将源IP地址Host-y转换为Host-y’。如果ICMP错误消息是由中间节点路由器-y发出的，则转换源IP
address varies depending on whether the Basic NAT or NAPT function [NAT-TRAD] is enforced by the NAT device. A NAT device enforcing the Basic NAT function has a pool of public IP addresses and enforces address mapping (which is different from the endpoint mapping enforced by NAPT) when a private node initiates an outgoing session via the NAT device. So, if the NAT device has active mapping for the IP address of the intermediate node Router-y, the NAT device MUST translate the source IP address of the ICMP Error packet with the public IP address in the mapping. In all other cases, the NAT device MUST simply use its own IP address in the external domain to translate the source IP address.
地址根据NAT设备是强制执行基本NAT还是NAPT功能[NAT-TRAD]而变化。实施基本NAT功能的NAT设备具有一个公共IP地址池，并在私有节点通过NAT设备发起传出会话时实施地址映射（与NAPT实施的端点映射不同）。因此，如果NAT设备具有中间节点路由器-y的IP地址的活动映射，则NAT设备必须将ICMP错误包的源IP地址转换为映射中的公共IP地址。在所有其他情况下，NAT设备必须在外部域中使用自己的IP地址来转换源IP地址。
REQ-5: If a NAT device receives an ICMP Error packet from the private realm, and the NAT does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP Error packet. If the NAT has active mapping for the embedded payload, then the NAT MUST do the following prior to forwarding the packet, unless explicitly overridden by local policy:
REQ-5：如果NAT设备从私有领域接收到ICMP错误数据包，并且NAT没有嵌入式有效负载的活动映射，则NAT应该静默地丢弃ICMP错误数据包。如果NAT具有嵌入式有效负载的活动映射，则NAT必须在转发数据包之前执行以下操作，除非本地策略明确覆盖：
a) Revert the IP and transport headers of the embedded IP packet to their original form, using the matching mapping; and
a) 使用匹配映射将嵌入式IP数据包的IP和传输头还原为其原始形式；和
b) Leave the ICMP Error type and code unchanged; and
b) 保持ICMP错误类型和代码不变；和
c) If the NAT enforces Basic NAT function ([NAT-TRAD]), and the NAT has active mapping for the IP address that sent the ICMP Error, translate the source IP address of the ICMP Error packet with the public IP address in the mapping. In all other cases, translate the source IP address of the ICMP Error packet with its own public IP address.
c) 如果NAT强制执行基本NAT功能（[NAT-TRAD]），并且NAT具有发送ICMP错误的IP地址的活动映射，则将ICMP错误数据包的源IP地址转换为映射中的公共IP地址。在所有其他情况下，将ICMP错误数据包的源IP地址转换为其自己的公共IP地址。
While processing an ICMP Error packet pertaining to an ICMP Query or Query response message, a NAT device MUST NOT refresh or delete the NAT Session that pertains to the embedded payload within the ICMP Error packet. This is in spite of the fact that the NAT device uses the NAT Session to translate the embedded payload. This ensures that the NAT Session will not be modified if someone is able to spoof ICMP Error messages for the session. [ICMP-ATK] lists a number of potential ICMP attacks that may be attempted by malicious users on the network. This requirement is necessary for current applications to work correctly.
在处理与ICMP查询或查询响应消息相关的ICMP错误数据包时，NAT设备不得刷新或删除与ICMP错误数据包中嵌入的有效负载相关的NAT会话。这是尽管NAT设备使用NAT会话来转换嵌入的有效负载的事实。这确保了如果有人能够伪造会话的ICMP错误消息，NAT会话将不会被修改。[ICMP-ATK]列出了网络上恶意用户可能尝试的一些潜在ICMP攻击。此要求是当前应用程序正常工作所必需的。
REQ-6: While processing an ICMP Error packet pertaining to an ICMP Query or Query response message, a NAT device MUST NOT refresh or delete the NAT Session that pertains to the embedded payload within the ICMP Error packet.
REQ-6：在处理与ICMP查询或查询响应消息相关的ICMP错误数据包时，NAT设备不得刷新或删除与ICMP错误数据包中嵌入的有效负载相关的NAT会话。
[BEH-UDP] and [BEH-TCP] mandate support for hairpinning for UDP and TCP sessions, respectively, on NAT devices. A NAT device needs to support hairpinning for ICMP Query sessions as well. Specifically, NAT devices enforcing Basic NAT [NAT-TRAD] MUST support the traversal of hairpinned ICMP Query sessions. Say, for example, individual private hosts register their NAT assigned external IP address with a rendezvous server. Other hosts that wish to initiate ICMP Query sessions to the registered hosts might do so using the public address registered with the rendezvous server. For this reason, Basic NAT devices are required to support the traversal of hairpinned ICMP Query sessions. This requirement is necessary for current applications to work correctly.
[BEH-UDP]和[BEH-TCP]分别强制支持NAT设备上UDP和TCP会话的发夹。NAT设备还需要支持ICMP查询会话的发夹。具体而言，实施基本NAT[NAT-TRAD]的NAT设备必须支持发夹式ICMP查询会话的遍历。例如，单个私有主机向集合服务器注册其NAT分配的外部IP地址。希望向注册主机发起ICMP查询会话的其他主机可以使用向集合服务器注册的公共地址来执行此操作。因此，需要基本NAT设备来支持发夹式ICMP查询会话的遍历。此要求是当前应用程序正常工作所必需的。
Packets belonging to any of the hairpinned sessions could, in turn, trigger ICMP Error messages directed to the source of hairpinned IP packets. Such hairpinned ICMP Error messages will traverse the NAT devices en route. All NAT devices (i.e., Basic NAT as well as NAPT devices) MUST support the traversal of hairpinned ICMP Error messages. Specifically, the NAT device must translate not only the embedded hairpinned packet, but also the outer IP header that is hairpinned. This requirement is necessary for current applications to work correctly.
属于任何发夹会话的数据包反过来可能触发指向发夹IP数据包源的ICMP错误消息。这种发夹式ICMP错误消息将在路由中遍历NAT设备。所有NAT设备（即，基本NAT和NAPT设备）必须支持遍历发夹式ICMP错误消息。具体地说，NAT设备不仅必须转换嵌入的发夹数据包，还必须转换发夹的外部IP报头。此要求是当前应用程序正常工作所必需的。
A hairpinned ICMP Error message is received from a node in a private network. As such, the ICMP Error processing requirement specified in Req-5 is applicable in its entirety in processing the ICMP Error message. In addition, the NAT device MUST translate the destination IP address of the outer IP header to be same as the source IP address of the embedded IP packet after the translation.
从专用网络中的节点接收发夹式ICMP错误消息。因此，Req-5中规定的ICMP错误处理要求完全适用于ICMP错误消息的处理。此外，NAT设备必须在转换后将外部IP报头的目标IP地址转换为与嵌入式IP包的源IP地址相同。
REQ-7: NAT devices enforcing Basic NAT [NAT-TRAD] MUST support the traversal of hairpinned ICMP Query sessions. All NAT devices (i.e., Basic NAT as well as NAPT devices) MUST support the traversal of hairpinned ICMP Error messages:
REQ-7：强制基本NAT[NAT-TRAD]的NAT设备必须支持发夹式ICMP查询会话的遍历。所有NAT设备（即基本NAT和NAPT设备）都必须支持遍历发夹式ICMP错误消息：
a) When forwarding a hairpinned ICMP Error message, the NAT device MUST translate the destination IP address of the outer IP header to be same as the source IP address of the embedded IP packet after the translation.
a) 转发发夹式ICMP错误消息时，NAT设备必须在转换后将外部IP报头的目标IP地址转换为与嵌入IP数据包的源IP地址相同。
A NAT device typically permits all outbound sessions. However, a NAT device may disallow some outbound sessions due to resource constraints or administration considerations. For example, a NAT device may not permit the first packet of a new outbound session if the NAT device is out of resources (out of addresses or TCP/UDP ports, or NAT Session resources) to set up a state for the session, or, if the specific session is administratively restricted by the NAT device.
NAT设备通常允许所有出站会话。但是，由于资源限制或管理考虑，NAT设备可能不允许某些出站会话。例如，如果NAT设备没有用于设置会话状态的资源（地址或TCP/UDP端口或NAT会话资源），或者如果特定会话受到NAT设备的管理限制，则NAT设备可能不允许新出站会话的第一个数据包。
When a NAT device is unable to establish a NAT Session for a new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource constraints or administrative restrictions, the NAT device SHOULD send an ICMP destination unreachable message, with a code of 13 (Communication administratively prohibited) to the sender, and drop the original packet. This requirement is meant primarily for future use. Current applications do not require this for them to work correctly. The justification for using ICMP code 13 in the ICMP Error message is as follows: Section 5.2.7.1 of [RFC1812] recommends routers use ICMP code 13 (Communication administratively prohibited) when they administratively filter packets. ICMP code 13 is a soft error and is on par with other soft error codes generated in response to transient events such as "network unreachable" (ICMP type=3, code=0).
当NAT设备由于资源限制或管理限制而无法为新传输层（TCP、UDP、ICMP等）流建立NAT会话时，NAT设备应向发送方发送代码为13（管理禁止通信）的ICMP目的地不可访问消息，并丢弃原始数据包。此要求主要用于将来使用。当前的应用程序不需要这样才能正常工作。在ICMP错误消息中使用ICMP代码13的理由如下：[RFC1812]第5.2.7.1节建议路由器在管理过滤数据包时使用ICMP代码13（通信管理禁止）。ICMP代码13是软错误，与响应于诸如“网络不可达”（ICMP类型＝3，代码＝0）的瞬态事件所产生的其他软错误码相一致。
Some NAT designers opt to never reject an outbound flow. When a NAT runs short of resources, they prefer to steal a resource from an existing NAT Session rather than reject the outbound flow. Such a design choice may appear conformant to REQ-8 below. However, the design choice is in violation of the spirit of both REQ-8 and REQ-2. Such a design choice is strongly discouraged.
一些NAT设计者选择从不拒绝出站流。当NAT资源不足时，他们更愿意从现有NAT会话中窃取资源，而不是拒绝出站流。这种设计选择可能符合下面的REQ-8。然而，设计选择违反了REQ-8和REQ-2的精神。强烈反对这样的设计选择。
REQ-8: When a NAT device is unable to establish a NAT Session for a new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource constraints or administrative restrictions, the NAT device SHOULD send an ICMP destination unreachable message, with a code of 13 (Communication administratively prohibited) to the sender, and drop the original packet.
REQ-8：当NAT设备由于资源限制或管理限制而无法为新传输层（TCP、UDP、ICMP等）流建立NAT会话时，NAT设备应向发送方发送一条ICMP目的地不可访问消息，代码为13（管理禁止通信），然后扔掉原来的包。
This document specifies NATs to have a behavior that is consistent with the way routers handle ICMP messages, as specified in Section 4.3 of [RFC1812]. However, since the publication of [RFC1812], some of its requirements are no longer best current practices. Thus, the following requirements are derived from [RFC1812] and apply to NATs compliant with this specification:
本文件规定NAT的行为与[RFC1812]第4.3节规定的路由器处理ICMP消息的方式一致。然而，自[RFC1812]发布以来，其某些要求不再是当前最佳实践。因此，以下要求源自[RFC1812]，适用于符合本规范的NAT：
REQ-9: A NAT device MAY implement a policy control that prevents ICMP messages being generated toward certain interface(s). Implementation of such a policy control overrides the MUSTs and SHOULDs in REQ-10.
REQ-9:NAT设备可实施策略控制，防止向特定接口生成ICMP消息。此类策略控制的实施将覆盖REQ-10中的必须和应该。
REQ-10: Unless overridden by REQ-9's policy, a NAT device needs to support ICMP messages as below, some conforming to Section 4.3 of [RFC1812] and some superseding the requirements of Section 4.3 of [RFC1812]:
REQ-10：除非被REQ-9的策略覆盖，否则NAT设备需要支持ICMP消息，如下所示，一些符合[RFC1812]第4.3节的要求，一些替代[RFC1812]第4.3节的要求：
a. MUST support:
a. 必须支持：
1. Destination Unreachable Message, as described in Section 7.1 of this document.
1. 目的地不可到达消息，如本文件第7.1节所述。
2. Time Exceeded Message, as described in Section 7.2 of this document.
2. 超出时间消息，如本文件第7.2节所述。
3. Echo Request/Reply Messages, as described in REQ-1.
3. 回送请求/回复消息，如REQ-1所述。
b. MAY support:
b. 可支持：
1. Redirect Message, as described in Section 4.3.3.2 of [RFC1812].
1. 重定向消息，如[RFC1812]第4.3.3.2节所述。
2. Timestamp and Timestamp Reply Messages, as described in Section 4.3.3.8 of [RFC1812].
2. 时间戳和时间戳回复消息，如[RFC1812]第4.3.3.8节所述。
3. Source Route Options, as described in Section 7.3 of this document.
3. 源路由选项，如本文件第7.3节所述。
4. Address Mask Request/Reply Message, as described in Section 7.4 of this document.
4. 地址掩码请求/回复消息，如本文件第7.4节所述。
5. Parameter Problem Message, as described in Section 7.5 of this document.
5. 参数问题消息，如本文件第7.5节所述。
6. Router Advertisement and Solicitations, as described in Section 7.6 of this document.
6. 路由器广告和招标，如本文件第7.6节所述。
c. SHOULD NOT support:
c. 不应支持：
1. Source Quench Message, as described in Section 4.3.3.3 of [RFC1812].
1. 源淬火信息，如[RFC1812]第4.3.3.3节所述。
2. Information Request/reply, as described in Section 4.3.3.7 of [RFC1812].
2. 信息请求/回复，如[RFC1812]第4.3.3.7节所述。
In addition, a NAT device is RECOMMENDED to conform to the following implementation considerations:
此外，建议NAT设备符合以下实施注意事项：
d. DS Field Usage, as described in Section 7.7 of this document.
d. DS字段使用，如本文件第7.7节所述。
e. When Not to Send ICMP Errors, as described in Section 4.3.2.7 of [RFC1812].
e. 不发送ICMP错误时，如[RFC1812]第4.3.2.7节所述。
f. Rate Limiting, as described in Section 4.3.2.8 of [RFC1812].
f. 速率限制，如[RFC1812]第4.3.2.8节所述。
Many networking applications (which include TCP- as well as UDP-based applications) depend on ICMP Error messages from the network to perform end-to-end path MTU discovery [PMTU]. Once the path MTU is discovered, an application that chooses to avoid fragmentation may do so by originating IP packets that fit within the path MTU en route and setting the DF (Don't Fragment) bit in the IP header, so the intermediate nodes en route do not fragment the IP packets. The following sub-sections discuss the need for NAT devices to honor the DF bit in the IP header and be able to generate "Packet Too Big" ICMP Error message when they cannot forward the IP packet without fragmentation. Also discussed is the need to seamlessly forward ICMP Error messages generated by other intermediate devices.
许多网络应用程序（包括TCP以及基于UDP的应用程序）依赖于来自网络的ICMP错误消息来执行端到端路径MTU发现[PMTU]。一旦发现路径MTU，选择避免分段的应用程序可以通过在路由中发起适合路径MTU的IP数据包并在IP报头中设置DF（不分段）位来避免分段，以便路由中的中间节点不分段IP数据包。以下小节讨论了NAT设备在IP报头中使用DF位的必要性，以及当它们无法转发IP数据包而没有碎片时，能够生成“数据包太大”ICMP错误消息的必要性。还讨论了无缝转发由其他中间设备生成的ICMP错误消息的必要性。
When a router is unable to forward a datagram because it exceeds the MTU of the next-hop network and its Don't Fragment (DF) bit is set, the router is required by [RFC1812] to return an ICMP Destination Unreachable message to the source of the datagram, with the code indicating "fragmentation needed and DF set". Further, [PMTU] states that the router MUST include the MTU of that next-hop network in the low-order 16 bits of the ICMP header field that is labeled "unused" in the ICMP specification [ICMP].
当路由器无法转发数据报，因为它超过了下一跳网络的MTU，并且设置了其不分段（DF）位时，[RFC1812]要求路由器将ICMP目的地不可到达消息返回到数据报源，代码指示“需要分段并设置DF”。此外，[PMTU]声明路由器必须在ICMP规范[ICMP]中标记为“未使用”的ICMP报头字段的低阶16位中包括该下一跳网络的MTU。
A NAT device MUST honor the DF bit in the IP header of the packets that transit the device. The NAT device may not be able to forward an IP packet without fragmentation if the MTU on the forwarding interface of the NAT device is not adequate for the IP packet. If the DF bit is set on a transit IP packet and the NAT device cannot forward the packet without fragmentation, the NAT device MUST send a "Packet Too Big" ICMP message (ICMP type 3, code 4) with the next-hop MTU back to the sender and drop the original IP packet. The sender will usually resend after taking the appropriate corrective action.
NAT设备必须在传输该设备的数据包的IP报头中使用DF位。如果NAT设备的转发接口上的MTU不足以转发IP分组，则NAT设备可能无法转发没有分段的IP分组。如果在传输IP数据包上设置了DF位，并且NAT设备无法在没有碎片的情况下转发该数据包，则NAT设备必须将带有下一跳MTU的“数据包太大”ICMP消息（ICMP类型3，代码4）发送回发送方，并丢弃原始IP数据包。发送方通常会在采取适当的纠正措施后重新发送。
If the DF bit is not set and the MTU on the forwarding interface of the NAT device mandates fragmentation, the NAT device MUST fragment the packet and forward the fragments [RFC1812].
如果未设置DF位，且NAT设备转发接口上的MTU要求分段，则NAT设备必须对数据包进行分段并转发分段[RFC1812]。
This is the flip side of the argument for the above section. By virtue of the address translation NAT performs, NAT may end up being the recipient of "Packet Too Big" messages.
这是上述部分论点的另一面。借助NAT执行的地址转换，NAT可能最终成为“数据包太大”消息的接收者。
When the NAT device is the recipient of a "Packet Too Big" ICMP message from the network, the NAT device MUST forward the ICMP message back to the intended recipient, pursuant to the previously stated requirements (REQ-3, REQ-4, and REQ-5).
当NAT设备是来自网络的“数据包太大”ICMP消息的接收者时，NAT设备必须根据先前规定的要求（REQ-3、REQ-4和REQ-5）将ICMP消息转发回预期接收者。
A NAT device MUST generate a "Time Exceeded" ICMP Error message when it discards a packet due to an expired Time to Live (TTL) field. A NAT device MAY have a per-interface option to disable origination of these messages on that interface, but that option MUST default to allowing the messages to be originated.
由于生存时间（TTL）字段过期而丢弃数据包时，NAT设备必须生成“超时”ICMP错误消息。NAT设备可能有一个“每个接口”选项来禁用该接口上这些消息的发起，但该选项必须默认为允许消息发起。
When a NAT device conforms to the above requirement, it ensures that legacy applications such as Traceroute [RFC1470], [MS-TRCRT], which depend upon the "Time Exceeded" ICMP Error message, will continue to operate even as NAT devices are en route.
当NAT设备符合上述要求时，它可确保传统应用程序（如Traceroute[RFC1470]、[MS-TRCRT]）（依赖于“超时”ICMP错误消息）将继续运行，即使NAT设备在途中。
A NAT device MAY support modifying IP addresses in the source route option so the IP addresses in the source route option are realm relevant. If a NAT device does not support forwarding packets with the source route option, the NAT device SHOULD NOT forward outbound ICMP messages that contain the source route option in the outer or inner IP header. This is because such messages could reveal private IP addresses to the external realm.
NAT设备可能支持修改源路由选项中的IP地址，以便源路由选项中的IP地址与领域相关。如果NAT设备不支持使用源路由选项转发数据包，则NAT设备不应转发在外部或内部IP报头中包含源路由选项的出站ICMP消息。这是因为这样的消息可能会向外部领域透露私有IP地址。
Section 4.3.3.9 of [RFC1812] says an IP router MUST implement support for receiving ICMP Address Mask Request messages and responding with ICMP Address Mask Reply messages. However, several years (more than 13 years at the time of this document) have elapsed since the text in RFC 1812 was written. In the intervening time, DHCP [DHCP] has replaced the use of address mask request/reply. At the current time,
[RFC1812]的第4.3.3.9节说，IP路由器必须实现对接收ICMP地址掩码请求消息和响应ICMP地址掩码回复消息的支持。然而，自RFC 1812中的文本编写以来，已经过去了几年（本文件编写时超过13年）。在此期间，DHCP[DHCP]已取代地址掩码请求/应答的使用。当前,，
there is rarely any host that does not meet host requirements [RFC1122] and needs a NAT device to support address mask request/reply.
很少有主机不满足主机要求[RFC1122]，需要NAT设备来支持地址掩码请求/应答。
For this reason, a NAT device is not required to support this ICMP message.
因此，不需要NAT设备来支持此ICMP消息。
A NAT device MAY support address mask request/reply messages.
NAT设备可以支持地址掩码请求/应答消息。
Section 4.3.3.5 of [RFC1812] says an IP router MUST generate a Parameter Problem message for any error not specifically covered by another ICMP message. However, this message is rarely used in practice in networks where IPv4 NATs are deployed.
[RFC1812]的第4.3.3.5节说，IP路由器必须为任何未被另一ICMP消息明确涵盖的错误生成参数问题消息。然而，在部署IPv4 NAT的网络中，实际上很少使用此消息。
For this reason, a NAT device is not required to support this ICMP message.
因此，不需要NAT设备来支持此ICMP消息。
A NAT device MAY support parameter problem messages.
NAT设备可能支持参数问题消息。
Section 4.3.3.10 of [RFC1812] says an IP router MUST support the router part of the ICMP Router Discovery Protocol on all connected networks on which the router supports either IP multicast or IP broadcast addressing. However, this message is rarely used in practice in networks where IPv4 NATs are deployed.
[RFC1812]第4.3.3.10节指出，IP路由器必须在所有连接的网络上支持ICMP路由器发现协议的路由器部分，路由器在这些网络上支持IP多播或IP广播寻址。然而，在部署IPv4 NAT的网络中，实际上很少使用此消息。
For this reason, a NAT device is not required to support this ICMP message.
因此，不需要NAT设备来支持此ICMP消息。
A NAT device MAY support Router Advertisement and Solicitations.
NAT设备可以支持路由器广告和请求。
[RFC1812] refers to the Type of Service (TOS) octet in the IP header, which contains the TOS and IP precedence fields. However, the TOS and IP precedence fields are no longer in use today. [RFC2474] renamed the TOS octet as the DS field and defined diffserv classes within the DS field.
[RFC1812]指IP标头中的服务类型（TOS）八位字节，其中包含TOS和IP优先级字段。但是，TOS和IP优先级字段今天不再使用。[RFC2474]将TOS八位字节重命名为DS字段，并在DS字段中定义了diffserv类。
When generating an ICMP message, a NAT device SHOULD copy the diffserv class of the message that causes the sending of the ICMP error message. A NAT device MAY allow configuration of the diffserv class to be used for the different types of ICMP messages.
生成ICMP消息时，NAT设备应复制导致发送ICMP错误消息的消息的diffserv类。NAT设备可允许将diffserv类的配置用于不同类型的ICMP消息。
In the preceding sections, ICMP requirements were identified for NAT devices, with a primary focus on ICMP Query and ICMP Error messages, as defined in the Terminology Section (see Section 2). This document provides no guidance on the handling of Non-QueryError ICMP messages by the NAT devices. A NAT MAY drop or appropriately handle Non-QueryError ICMP messages.
在前面的章节中，确定了NAT设备的ICMP要求，主要关注术语部分（见第2节）中定义的ICMP查询和ICMP错误消息。本文档未提供NAT设备处理非查询错误ICMP消息的指南。NAT可以删除或适当处理非QueryError ICMP消息。
REQ-11: A NAT MAY drop or appropriately handle Non-QueryError ICMP messages. The semantics of Non-QueryError ICMP messages is defined in Section 2.
REQ-11:NAT可以删除或适当处理非查询错误ICMP消息。第2节定义了非QueryError ICMP消息的语义。
Below is a summary of all the requirements.
以下是所有要求的摘要。
REQ-1: Unless explicitly overridden by local policy, a NAT device MUST permit ICMP Queries and their associated responses, when the Query is initiated from a private host to the external hosts.
REQ-1：除非本地策略明确覆盖，否则当从专用主机向外部主机发起查询时，NAT设备必须允许ICMP查询及其相关响应。
a) NAT mapping of ICMP Query Identifiers SHOULD be external host independent.
a) ICMP查询标识符的NAT映射应独立于外部主机。
REQ-2: An ICMP Query session timer MUST NOT expire in less than 60 seconds.
REQ-2:ICMP查询会话计时器不得在60秒内过期。
a) It is RECOMMENDED that the ICMP Query session timer be made configurable.
a) 建议配置ICMP查询会话计时器。
REQ-3: When an ICMP Error packet is received, if the ICMP checksum fails to validate, the NAT SHOULD silently drop the ICMP Error packet. If the ICMP checksum is valid, do the following:
REQ-3：当接收到ICMP错误数据包时，如果ICMP校验和无法验证，NAT应自动丢弃ICMP错误数据包。如果ICMP校验和有效，请执行以下操作：
a) If the IP checksum of the embedded packet fails to validate, the NAT SHOULD silently drop the Error packet; and
a) 如果嵌入数据包的IP校验和无法验证，NAT应静默丢弃错误数据包；和
b) If the embedded packet includes IP options, the NAT device MUST traverse past the IP options to locate the start of the transport header for the embedded packet; and
b) 如果嵌入式分组包括IP选项，则NAT设备必须穿过IP选项以定位嵌入式分组的传输报头的开始；和
c) The NAT device SHOULD NOT validate the transport checksum of the embedded packet within an ICMP Error message, even when it is possible to do so; and
c) NAT设备不应验证ICMP错误消息中嵌入数据包的传输校验和，即使在可能的情况下也是如此；和
d) If the ICMP Error payload contains ICMP extensions [ICMP-EXT], the NAT device MUST exclude the optional zero-padding and the ICMP extensions when evaluating transport checksum for the embedded packet.
d) 如果ICMP错误负载包含ICMP扩展[ICMP-EXT]，则NAT设备在评估嵌入式数据包的传输校验和时必须排除可选的零填充和ICMP扩展。
REQ-4: If a NAT device receives an ICMP Error packet from an external realm, and the NAT device does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP Error packet. If the NAT has active mapping for the embedded payload, then the NAT MUST do the following prior to forwarding the packet, unless explicitly overridden by local policy:
REQ-4：如果NAT设备从外部领域接收到ICMP错误数据包，并且NAT设备没有嵌入式有效负载的活动映射，则NAT应该静默地丢弃ICMP错误数据包。如果NAT具有嵌入式有效负载的活动映射，则NAT必须在转发数据包之前执行以下操作，除非本地策略明确覆盖：
a) Revert the IP and transport headers of the embedded IP packet to their original form, using the matching mapping; and
a) 使用匹配映射将嵌入式IP数据包的IP和传输头还原为其原始形式；和
b) Leave the ICMP Error type and code unchanged; and
b) 保持ICMP错误类型和代码不变；和
c) Modify the destination IP address of the outer IP header to be same as the source IP address of the embedded packet after translation.
c) 将外部IP头的目标IP地址修改为与翻译后嵌入数据包的源IP地址相同。
REQ-5: If a NAT device receives an ICMP Error packet from the private realm, and the NAT does not have an active mapping for the embedded payload, the NAT SHOULD silently drop the ICMP Error packet. If the NAT has active mapping for the embedded payload, then the NAT MUST do the following prior to forwarding the packet, unless explicitly overridden by local policy.
REQ-5：如果NAT设备从私有领域接收到ICMP错误数据包，并且NAT没有嵌入式有效负载的活动映射，则NAT应该静默地丢弃ICMP错误数据包。如果NAT具有嵌入式有效负载的活动映射，则NAT必须在转发数据包之前执行以下操作，除非本地策略显式覆盖。
a) Revert the IP and transport headers of the embedded IP packet to their original form, using the matching mapping; and
a) 使用匹配映射将嵌入式IP数据包的IP和传输头还原为其原始形式；和
b) Leave the ICMP Error type and code unchanged; and
b) 保持ICMP错误类型和代码不变；和
c) If the NAT enforces Basic NAT function [NAT-TRAD], and the NAT has active mapping for the IP address that sent the ICMP Error, translate the source IP address of the ICMP Error packet with the public IP address in the mapping. In all other cases, translate the source IP address of the ICMP Error packet with its own public IP address.
c) 如果NAT强制执行基本NAT功能[NAT-TRAD]，并且NAT具有发送ICMP错误的IP地址的活动映射，则将ICMP错误数据包的源IP地址转换为映射中的公共IP地址。在所有其他情况下，将ICMP错误数据包的源IP地址转换为其自己的公共IP地址。
REQ-6: While processing an ICMP Error packet pertaining to an ICMP Query or Query response message, a NAT device MUST NOT refresh or delete the NAT Session that pertains to the embedded payload within the ICMP Error packet.
REQ-6：在处理与ICMP查询或查询响应消息相关的ICMP错误数据包时，NAT设备不得刷新或删除与ICMP错误数据包中嵌入的有效负载相关的NAT会话。
REQ-7: NAT devices enforcing Basic NAT ([NAT-TRAD]) MUST support the traversal of hairpinned ICMP Query sessions. All NAT devices (i.e., Basic NAT as well as NAPT devices) MUST support the traversal of hairpinned ICMP Error messages.
REQ-7：强制基本NAT（[NAT-TRAD]）的NAT设备必须支持发夹式ICMP查询会话的遍历。所有NAT设备（即，基本NAT和NAPT设备）必须支持遍历发夹式ICMP错误消息。
a) When forwarding a hairpinned ICMP Error message, the NAT device MUST translate the destination IP address of the outer IP header to be same as the source IP address of the embedded IP packet after the translation.
a) 转发发夹式ICMP错误消息时，NAT设备必须在转换后将外部IP报头的目标IP地址转换为与嵌入IP数据包的源IP地址相同。
REQ-8: When a NAT device is unable to establish a NAT Session for a new transport-layer (TCP, UDP, ICMP, etc.) flow due to resource constraints or administrative restrictions, the NAT device SHOULD send an ICMP destination unreachable message, with a code of 13 (Communication administratively prohibited) to the sender, and drop the original packet.
REQ-8：当NAT设备由于资源限制或管理限制而无法为新传输层（TCP、UDP、ICMP等）流建立NAT会话时，NAT设备应向发送方发送一条ICMP目的地不可访问消息，代码为13（管理禁止通信），然后扔掉原来的包。
REQ-9: A NAT device MAY implement a policy control that prevents ICMP messages being generated toward certain interface(s). Implementation of such a policy control overrides the MUSTs and SHOULDs in REQ-10.
REQ-9:NAT设备可实施策略控制，防止向特定接口生成ICMP消息。此类策略控制的实施将覆盖REQ-10中的必须和应该。
REQ-10: Unless overridden by REQ-9's policy, a NAT device needs to support ICMP messages as below, some conforming to Section 4.3 of [RFC1812] and some superseding the requirements of Section 4.3 of [RFC1812]:
REQ-10：除非被REQ-9的策略覆盖，否则NAT设备需要支持ICMP消息，如下所示，一些符合[RFC1812]第4.3节的要求，一些替代[RFC1812]第4.3节的要求：
a. MUST support:
a. 必须支持：
1. Destination Unreachable Message, as described in Section 7.1 of this document.
1. 目的地不可到达消息，如本文件第7.1节所述。
2. Time Exceeded Message, as described in Section 7.2 of this document.
2. 超出时间消息，如本文件第7.2节所述。
3. Echo Request/Reply Messages, as described in REQ-1.
3. 回送请求/回复消息，如REQ-1所述。
b. MAY support:
b. 可支持：
1. Redirect Message, as described in Section 4.3.3.2 of [RFC1812].
1. 重定向消息，如[RFC1812]第4.3.3.2节所述。
2. Timestamp and Timestamp Reply Messages, as described in Section 4.3.3.8 of [RFC1812].
2. 时间戳和时间戳回复消息，如[RFC1812]第4.3.3.8节所述。
3. Source Route Options, as described in Section 7.3 of this document.
3. 源路由选项，如本文件第7.3节所述。
4. Address Mask Request/Reply Message, as described in Section 7.4 of this document.
4. 地址掩码请求/回复消息，如本文件第7.4节所述。
5. Parameter Problem Message, as described in Section 7.5 of this document.
5. 参数问题消息，如本文件第7.5节所述。
6. Router Advertisement and Solicitations, as described in Section 7.6 of this document.
6. 路由器广告和招标，如本文件第7.6节所述。
c. SHOULD NOT support:
c. 不应支持：
1. Source Quench Message, as described in Section 4.3.3.3 of [RFC1812].
1. 源淬火信息，如[RFC1812]第4.3.3.3节所述。
2. Information Request/reply, as described in Section 4.3.3.7 of [RFC1812].
2. 信息请求/回复，如[RFC1812]第4.3.3.7节所述。
In addition, a NAT device is RECOMMENDED to conform to the following implementation considerations:
此外，建议NAT设备符合以下实施注意事项：
d. DS Field Usage, as described in Section 7.7 of this document.
d. DS字段使用，如本文件第7.7节所述。
e. When Not to Send ICMP Errors, as described in Section 4.3.2.7 of [RFC1812].
e. 不发送ICMP错误时，如[RFC1812]第4.3.2.7节所述。
f. Rate Limiting, as described in Section 4.3.2.8 of [RFC1812].
f. 速率限制，如[RFC1812]第4.3.2.8节所述。
REQ-11: A NAT MAY drop or appropriately handle Non-QueryError ICMP messages. The semantics of Non-QueryError ICMP messages is defined in Section 2.
REQ-11:NAT可以删除或适当处理非查询错误ICMP消息。第2节定义了非QueryError ICMP消息的语义。
This document does not introduce any new security concerns related to ICMP message handling in the NAT devices. However, the requirements in the document do mitigate some security concerns known to exist with ICMP messages.
本文档没有介绍任何与NAT设备中ICMP消息处理相关的新安全问题。然而，本文件中的要求确实缓解了已知存在于ICMP消息中的一些安全问题。
[ICMP-ATK] lists a number of ICMP attacks that can be directed against end host TCP stacks. For example, a rogue entity could bombard the NAT device with a large number of ICMP Errors. If the NAT device did not validate the legitimacy of the ICMP Error packets, the ICMP Errors would be forwarded directly to the end nodes. End hosts not capable of defending themselves against such bogus ICMP Error attacks could be adversely impacted by such attacks. Req-3 recommends validating the ICMP checksum and the IP checksum of the
[ICMP-ATK]列出了许多可针对终端主机TCP堆栈的ICMP攻击。例如，流氓实体可能会用大量ICMP错误轰炸NAT设备。如果NAT设备没有验证ICMP错误数据包的合法性，ICMP错误将直接转发到终端节点。无法抵御此类伪造ICMP错误攻击的终端主机可能会受到此类攻击的不利影响。Req-3建议验证服务器的ICMP校验和和IP校验和
embedded payload prior to forwarding. These checksum validations by themselves do not protect end hosts from attacks. However, checksum validation mitigates end hosts from malformed ICMP Error attacks. Req-4 and Req-5 further mandate that when a NAT device does not find a mapping selection for the embedded payload, the NAT should drop the ICMP Error packets, without forwarding.
转发前的嵌入式有效负载。这些校验和验证本身并不能保护终端主机免受攻击。但是，校验和验证可以减轻终端主机受到格式错误的ICMP错误攻击的风险。Req-4和Req-5进一步规定，当NAT设备未找到嵌入式有效负载的映射选择时，NAT应丢弃ICMP错误数据包，而不进行转发。
A rogue source could also try to send bogus ICMP Error messages for the active NAT sessions, with intent to destroy the sessions. Req-6 averts such an attack by ensuring that an ICMP Error message does not affect the state of a session on the NAT device.
恶意源还可能试图为活动NAT会话发送虚假ICMP错误消息，意图破坏会话。Req-6通过确保ICMP错误消息不会影响NAT设备上会话的状态来避免此类攻击。
Req-8 recommends a NAT device sending an ICMP Error message when the NAT device is unable to create a NAT session due to lack of resources. Some administrators may choose not to have the NAT device send an ICMP Error message, as doing so could confirm to a malicious attacker that the attack has succeeded. For this reason, sending of the specific ICMP Error message stated in REQ-8 is left to the discretion of the NAT device administrator.
Req-8建议NAT设备在由于缺乏资源而无法创建NAT会话时发送ICMP错误消息。一些管理员可能选择不让NAT设备发送ICMP错误消息，因为这样做可能会向恶意攻击者确认攻击已成功。因此，发送REQ-8中规定的特定ICMP错误消息由NAT设备管理员自行决定。
Unfortunately, ICMP messages are sometimes blocked at network boundaries due to local security policy. Thus, some of the requirements in this document allow local policy to override the recommendations of this document. Blocking such ICMP messages is known to break some protocol features (most notably path MTU Discovery) and some applications (e.g., ping, traceroute), and such blocking is NOT RECOMMENDED.
不幸的是，由于本地安全策略，ICMP消息有时会在网络边界被阻止。因此，本文件中的一些要求允许当地政策凌驾于本文件的建议之上。已知阻止此类ICMP消息会破坏某些协议功能（最显著的是路径MTU发现）和某些应用程序（例如，ping、traceroute），不建议进行此类阻止。
The authors wish to thank Fernando Gont, Dan Wing, Carlos Pignataro, Philip Matthews, and members of the BEHAVE working group for doing a thorough review of early versions of the document and providing valuable input and offering generous amounts of their time in shaping the ICMP requirements. Their valuable feedback made this document a better read. Dan Wing and Fernando Gont were a steady source of encouragement. Fernando Gont spent many hours preparing slides and presenting the document in an IETF meeting on behalf of the authors. The authors wish to thank Carlos Pignataro and Dan Tappan, authors of the [ICMP-EXT] document, for their feedback concerning ICMP extensions. The authors wish to thank Philip Matthews for agreeing to be a technical reviewer for the document. Lastly, the authors highly appreciate the rigorous feedback from the IESG members.
作者谨感谢费尔南多·冈特、丹·荣格、卡洛斯·皮格纳塔罗、菲利普·马修斯和BEHAVE工作组的成员对文件的早期版本进行了彻底审查，并提供了宝贵的投入，为制定ICMP要求提供了大量的时间。他们的宝贵反馈使本文件更易于阅读。丹·温和费尔南多·冈特一直是鼓励的源泉。费尔南多·冈特（Fernando Gont）花了很多时间准备幻灯片，并代表作者在IETF会议上介绍了该文件。作者希望感谢[ICMP-EXT]文档的作者Carlos Pignataro和Dan Tappan，感谢他们对ICMP扩展的反馈。作者希望感谢Philip Matthews同意担任该文件的技术审查员。最后，作者高度赞赏IESG成员的严格反馈。
[BEH-UDP] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[BEH-UDP]Audet，F.，Ed.，和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[ICMP] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[ICMP]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[ICMP-EXT] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
[ICMP-EXT]Bonica，R.，Gan，D.，Tappan，D.，和C.Pignataro，“扩展ICMP以支持多部分消息”，RFC 4884，2007年4月。
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT-TRAD]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，Ed.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[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月。
[BEH-APP] Ford, B., Srisuresh, P., and D. Kegel, "Application Design Guidelines for Traversal through Network Address Translators", Work in Progress, March 2007.
[BEH-APP]Ford，B.，Srisuresh，P.，和D.Kegel，“通过网络地址转换器进行遍历的应用程序设计指南”，正在进行的工作，2007年3月。
[BEH-TCP] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[BEH-TCP]Guha，S.，Ed.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，2008年10月。
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[DHCP]Droms，R.，“动态主机配置协议”，RFC 21311997年3月。
[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.
[ICE]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，正在进行的工作，2007年10月。
[ICMP-ATK] Gont, F., "ICMP Attacks against TCP", Work in Progress, October 2008.
[ICMP-ATK]Gont，F.，“针对TCP的ICMP攻击”，正在进行的工作，2008年10月。
[MS-TRCRT] Microsoft Support, "How to use the Tracert command-line utility to troubleshoot TCP/IP problems in Windows", http://support.microsoft.com/kb/162326, October, 2006.
[MS-TRCRT]Microsoft支持，“如何使用Tracert命令行实用程序解决Windows中的TCP/IP问题”，http://support.microsoft.com/kb/162326，2006年10月。
[NAT-MIB] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and C. Wang, "Definitions of Managed Objects for Network Address Translators (NAT)", RFC 4008, March 2005.
[NAT-MIB]Rohit，R.，Srisuresh，P.，Raghunarayan，R.，Pai，N.，和C.Wang，“网络地址转换器（NAT）管理对象的定义”，RFC 4008，2005年3月。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-TERM]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[PMTU] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[PMTU]Mogul，J.和S.Deering，“MTU发现路径”，RFC191990年11月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，1989年10月。
[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256]迪林，S.，编辑，“ICMP路由器发现消息”，RFC1256，1991年9月。
[RFC1470] Enger, R. and J. Reynolds, "FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices", FYI 2, RFC 1470, June 1993.
[RFC1470]Enger，R.和J.Reynolds，“网络管理工具目录的FYI：监控和调试TCP/IP互联网和互连设备的工具”，FYI 2，RFC 1470，1993年6月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC4065] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
[RFC4065]Kempf，J.，“Seamoby和实验移动协议IANA分配说明”，RFC4065，2005年7月。
[TCP-SOFT] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
[TCP-SOFT]Gont，F.，“TCP对软错误的反应”，RFC 54612009年2月。
[UNSAF] Daigle, L., Ed., and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[UNSAF]Daigle，L.，Ed.，和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
Authors' Addresses
作者地址
Pyda Srisuresh Kazeon Systems, Inc. 1161 San Antonio Rd. Mountain View, CA 94043 U.S.A.
美国加利福尼亚州山景城圣安东尼奥路1161号Pyda Srisuresh Kazeon Systems，Inc.94043。
Phone: +1 408 836 4773
EMail: srisuresh@yahoo.com
Phone: +1 408 836 4773
EMail: srisuresh@yahoo.com
Bryan Ford Max Planck Institute for Software Systems Campus Building E1 4 D-66123 Saarbruecken Germany
布莱恩·福特·马克斯·普朗克软件系统研究所校园建筑E1 4 D-66123德国萨尔布鲁肯
Phone: +49-681-9325657
EMail: baford@mpi-sws.org
Phone: +49-681-9325657
EMail: baford@mpi-sws.org
Senthil Sivakumar Cisco Systems, Inc. 7100-8 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709-4987 U.S.A.
美国北卡罗来纳州三角研究园14987号吉特克里克路7100-8号邮政信箱Senthil Sivakumar Cisco Systems，Inc.邮编：27709-4987。
Phone: +1 919 392 5158
EMail: ssenthil@cisco.com
Phone: +1 919 392 5158
EMail: ssenthil@cisco.com
Saikat Guha Cornell University 331 Upson Hall Ithaca, NY 14853 U.S.A.
Saikat Guha Cornell大学331 Upson Hall Ithaca，NY 14853美国。
Phone: +1 607 255 1008
EMail: saikat@cs.cornell.edu
Phone: +1 607 255 1008
EMail: saikat@cs.cornell.edu