Independent Submission S. Cheshire
Request for Comments: 6886 M. Krochmal
Category: Informational Apple Inc.
ISSN: 2070-1721 April 2013
Independent Submission S. Cheshire
Request for Comments: 6886 M. Krochmal
Category: Informational Apple Inc.
ISSN: 2070-1721 April 2013
NAT Port Mapping Protocol (NAT-PMP)
NAT端口映射协议（NAT-PMP）
Abstract
摘要
This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it. From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC "Port Control Protocol (PCP)", which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements.
本文档描述了一种用于自动创建网络地址转换（NAT）端口映射的协议。协议中包括一种用于检索NAT网关的外部IPv4地址的方法，从而允许客户端将其外部IPv4地址和端口告知可能希望与其通信的对等方。从2005年起，该协议已在苹果产品中实施，包括Mac OS X、Windows版的Bonjour和机场无线基站。2013年，NAT端口映射协议（NAT-PMP）被IETF标准跟踪RFC“端口控制协议（PCP）”取代，该协议建立在NAT-PMP的基础上，使用兼容的数据包格式，但增加了许多重要的增强功能。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc6886.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6886.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Transition to Port Control Protocol ........................4
2. Conventions and Terminology Used in This Document ...............5
3. Protocol and Packet Format ......................................5
3.1. Requests and Responses .....................................6
3.2. Determining the External Address ...........................7
3.3. Requesting a Mapping ......................................10
3.4. Destroying a Mapping ......................................13
3.5. Result Codes ..............................................14
3.6. Seconds Since Start of Epoch ..............................16
3.7. Recreating Mappings on NAT Gateway Reboot .................16
3.8. NAT Gateways with NAT Function Disabled ...................18
3.9. All Mappings Are Bidirectional ............................19
4. UNSAF Considerations ...........................................20
4.1. Scope .....................................................20
4.2. Transition Plan ...........................................20
4.3. Failure Cases .............................................21
4.4. Long-Term Solution ........................................23
4.5. Existing Deployed NATs ....................................23
5. Security Considerations ........................................23
6. IANA Considerations ............................................24
7. Acknowledgments ................................................24
8. Deployment History .............................................25
9. Noteworthy Features of NAT Port Mapping Protocol and PCP .......26
9.1. Simplicity ................................................27
9.2. Focused Scope .............................................27
9.3. Efficiency ................................................27
9.4. Atomic Allocation Operations ..............................29
9.5. Garbage Collection ........................................29
9.6. State Change Announcements ................................30
9.7. Soft State Recovery .......................................31
9.8. On-Path NAT Discovery .....................................31
10. References ....................................................32
10.1. Normative References .....................................32
10.2. Informative References ...................................32
1. Introduction ....................................................3
1.1. Transition to Port Control Protocol ........................4
2. Conventions and Terminology Used in This Document ...............5
3. Protocol and Packet Format ......................................5
3.1. Requests and Responses .....................................6
3.2. Determining the External Address ...........................7
3.3. Requesting a Mapping ......................................10
3.4. Destroying a Mapping ......................................13
3.5. Result Codes ..............................................14
3.6. Seconds Since Start of Epoch ..............................16
3.7. Recreating Mappings on NAT Gateway Reboot .................16
3.8. NAT Gateways with NAT Function Disabled ...................18
3.9. All Mappings Are Bidirectional ............................19
4. UNSAF Considerations ...........................................20
4.1. Scope .....................................................20
4.2. Transition Plan ...........................................20
4.3. Failure Cases .............................................21
4.4. Long-Term Solution ........................................23
4.5. Existing Deployed NATs ....................................23
5. Security Considerations ........................................23
6. IANA Considerations ............................................24
7. Acknowledgments ................................................24
8. Deployment History .............................................25
9. Noteworthy Features of NAT Port Mapping Protocol and PCP .......26
9.1. Simplicity ................................................27
9.2. Focused Scope .............................................27
9.3. Efficiency ................................................27
9.4. Atomic Allocation Operations ..............................29
9.5. Garbage Collection ........................................29
9.6. State Change Announcements ................................30
9.7. Soft State Recovery .......................................31
9.8. On-Path NAT Discovery .....................................31
10. References ....................................................32
10.1. Normative References .....................................32
10.2. Informative References ...................................32
Network Address Translation (NAT) is a method of sharing one public Internet address with a number of devices. This document is focused on devices that are formally classified as "NAPTs" (Network Address/Port Translators) [RFC2663]. A full description of NAT is beyond the scope of this document. The following brief overview will cover the aspects relevant to this port mapping protocol. For more information on NAT, see "Traditional IP Network Address Translator (Traditional NAT)" [RFC3022].
网络地址转换（NAT）是一种与多个设备共享一个公共Internet地址的方法。本文档主要关注正式分类为“NAPTs”（网络地址/端口转换器）[RFC2663]的设备。NAT的完整描述超出了本文档的范围。以下简要概述将涵盖与此端口映射协议相关的方面。有关NAT的更多信息，请参阅“传统IP网络地址转换器（传统NAT）”[RFC3022]。
NATs have one or more external IP addresses. A private network is set up behind the NAT. Client devices on that private network behind the NAT are assigned private addresses, and those client devices use the private address of the NAT device as their default gateway.
NAT有一个或多个外部IP地址。在NAT后面建立一个专用网络。NAT后面的专用网络上的客户端设备被分配了专用地址，这些客户端设备使用NAT设备的专用地址作为其默认网关。
When a packet from any device behind the NAT is sent to an address on the public Internet, the packet first passes through the NAT box. The NAT box looks at the source port and address. In some cases, a NAT will also keep track of the destination port and address. The NAT then creates a mapping from the internal address and internal port to an external address and external port if a mapping does not already exist.
当来自NAT后面的任何设备的数据包被发送到公共互联网上的地址时，该数据包首先通过NAT盒。NAT框查看源端口和地址。在某些情况下，NAT还将跟踪目标端口和地址。然后，如果映射不存在，NAT将创建从内部地址和内部端口到外部地址和外部端口的映射。
The NAT box replaces the internal address and port in the packet with the external entries from the mapping and sends the packet on to the next gateway.
NAT框用映射中的外部条目替换数据包中的内部地址和端口，并将数据包发送到下一个网关。
When a packet from any address on the Internet is received on the NAT's external side, the NAT will look up the destination address and port (external address and port) in the list of mappings. If an entry is found, it will contain the internal address and port to which the packet should be sent. The NAT gateway will then rewrite the destination address and port with those from the mapping. The packet will then be forwarded to the new destination addresses. If the packet did not match any mapping, the packet will most likely be dropped. Various NATs implement different strategies to handle this. The important thing to note is that if there is no mapping, the NAT does not know to which internal address the packet should be sent.
当NAT的外部接收到来自Internet上任何地址的数据包时，NAT将在映射列表中查找目标地址和端口（外部地址和端口）。如果找到条目，它将包含数据包应发送到的内部地址和端口。然后，NAT网关将使用映射中的地址和端口重写目标地址和端口。然后，数据包将被转发到新的目的地地址。如果数据包不匹配任何映射，则数据包很可能会被丢弃。不同的NAT实现不同的策略来处理这个问题。需要注意的重要一点是，如果没有映射，NAT就不知道数据包应该发送到哪个内部地址。
Mappings are usually created automatically as a result of observing outbound packets. There are a few exceptions. Some NATs may allow manually created permanent mappings that map an external port to a specific internal IP address and port. Such a mapping allows incoming connections to the device with that internal address. Some NATs also implement a default mapping where any inbound packet that
映射通常是通过观察出站数据包自动创建的。有几个例外。某些NAT可能允许手动创建永久映射，将外部端口映射到特定的内部IP地址和端口。这样的映射允许到具有该内部地址的设备的传入连接。一些NAT还实现了一个默认映射，其中任何入站数据包
does not match any other more specific mapping will be forwarded to a specified internal address. Both types of mappings are usually set up manually through some configuration tool. Such manual configuration of port mappings is unreasonably onerous for most residential NAT users.
不匹配的任何其他更具体的映射将转发到指定的内部地址。这两种类型的映射通常都是通过一些配置工具手动设置的。这种端口映射的手动配置对于大多数住宅NAT用户来说是不合理的繁重。
Without these manually created inbound port mappings, clients behind the NAT would be unable to receive inbound connections, which represents a loss of connectivity when compared to the original Internet architecture [ETEAISD]. For those who view this loss of connectivity as a bad thing, NAT-PMP allows clients to operate more like a host directly connected to the unrestricted public Internet, with an unrestricted public IPv4 address. NAT-PMP allows client hosts to communicate with the NAT gateway to request the creation of inbound mappings on demand. Having created a NAT mapping to allow inbound connections, the client can then record its external IPv4 address and external port in a public registry (e.g., the worldwide Domain Name System) or otherwise make it accessible to peers that wish to communicate with it.
如果没有这些手动创建的入站端口映射，NAT后面的客户端将无法接收入站连接，与原始Internet架构[ETEAID]相比，这表示连接丢失。对于那些认为这种连接丢失是一件坏事的人来说，NAT-PMP允许客户端像一台主机一样使用不受限制的公共IPv4地址直接连接到不受限制的公共互联网。NAT-PMP允许客户端主机与NAT网关通信，请求按需创建入站映射。创建NAT映射以允许入站连接后，客户端可以在公共注册表（例如，全球域名系统）中记录其外部IPv4地址和外部端口，或以其他方式使希望与其通信的对等方可以访问该地址和端口。
NAT-PMP enjoyed almost a decade of useful service, and operational experience with NAT-PMP informed the design of its IETF Standards Track successor, Port Control Protocol (PCP) [RFC6887]. PCP builds on NAT-PMP, using the same UDP ports 5350 and 5351, and a compatible packet format. PCP also adds significant enhancements, including IPv6 support, management of outbound mappings, management of firewall rules, full compatibility with large-scale NATs with a pool of external addresses, error lifetimes, and an extension mechanism to enable future enhancements.
NAT-PMP享受了近十年的有用服务，NAT-PMP的运行经验为其IETF标准跟踪后继协议——端口控制协议（PCP）[RFC6887]的设计提供了依据。PCP基于NAT-PMP构建，使用相同的UDP端口5350和5351以及兼容的数据包格式。PCP还增加了重要的增强功能，包括IPv6支持、出站映射管理、防火墙规则管理、与具有外部地址池的大规模NAT的完全兼容性、错误生存期，以及支持未来增强功能的扩展机制。
Because of the significant enhancements in PCP, all existing NAT-PMP implementations are encouraged to migrate to PCP. The version number in the packet header is 0 for NAT-PMP and 2 for PCP, so the packets are easily distinguished. (Version number 1 was used by a vendor that shipped products that use a protocol that is incompatible with the IETF Standard. PCP implementations MUST NOT use version number 1.)
由于PCP的显著增强，鼓励所有现有NAT-PMP实现迁移到PCP。对于NAT-PMP，数据包头中的版本号为0，对于PCP，版本号为2，因此数据包很容易区分。（版本号1由供应商使用，该供应商提供的产品使用与IETF标准不兼容的协议。PCP实施不得使用版本号1。）
For NAT-PMP servers, adding PCP support is simple. When packets are received, if the version number is 2, then the packet is interpreted as a PCP request, the request is handled, and replies and updates pertaining to that mapping are sent using PCP format. If the version number is 0, then the existing code handles the request exactly as it already does, and replies and updates pertaining to that mapping are
对于NAT-PMP服务器，添加PCP支持很简单。当接收到数据包时，如果版本号为2，则该数据包将被解释为PCP请求，处理该请求，并使用PCP格式发送与该映射相关的回复和更新。如果版本号为0，那么现有代码将完全按照它已经执行的方式处理请求，并且与该映射相关的回复和更新将被删除
sent using NAT-PMP format. If the version number is 1 or any other unsupported version, then result code 1 (Unsupported Version) is returned.
使用NAT-PMP格式发送。如果版本号为1或任何其他不支持的版本，则返回结果代码1（不支持的版本）。
NAT-PMP clients should add PCP support, and should default to sending requests using PCP format, which will cause clients to prefer the newer format when possible. If a PCP request is sent to an old NAT-PMP server that doesn't understand the new PCP format, then it will return result code 1 (Unsupported Version), and the client should then immediately retry the same request using NAT-PMP format. The presence of the Unsupported Version reply allows fast fail-over to NAT-PMP format, without waiting for timeouts, retransmissions, or other arbitrary delays. It is recommended that clients always try PCP first for every new request, retransmission, and renewal, and only try NAT-PMP in response to an "Unsupported Version" error. Clients SHOULD NOT record that a given server only speaks NAT-PMP and subsequently default to NAT-PMP for that server, since NAT firmware gets updated, and even a NAT gateway that speaks only NAT-PMP today, may be updated to speak PCP tomorrow.
NAT-PMP客户端应添加PCP支持，并应默认使用PCP格式发送请求，这将导致客户端在可能时更喜欢较新的格式。如果将PCP请求发送到不理解新PCP格式的旧NAT-PMP服务器，则它将返回结果代码1（不支持的版本），然后客户端应立即使用NAT-PMP格式重试相同的请求。存在不受支持的版本回复允许快速故障切换到NAT-PMP格式，而无需等待超时、重新传输或其他任意延迟。建议客户端总是在每次新请求、重新传输和续订时首先尝试PCP，并且仅在响应“不支持的版本”错误时尝试NAT-PMP。客户端不应记录给定服务器只会讲NAT-PMP，并且随后默认为该服务器的NAT-PMP，因为NAT固件会更新，甚至今天只会讲NAT-PMP的NAT网关明天也可能会更新为讲PCP。
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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照“RFC中用于指示需求水平的关键词”[RFC2119]中的描述进行解释。
The NAT Port Mapping Protocol runs over UDP. Every packet starts with an 8-bit version followed by an 8-bit operation code.
NAT端口映射协议通过UDP运行。每个数据包都以一个8位版本开始，后跟一个8位操作代码。
All numeric quantities in NAT-PMP larger than a single byte (e.g., error values, Seconds Since Start of Epoch, and mapping lifetime) are transmitted in the traditional IETF network byte order (i.e., most significant byte first).
NAT-PMP中大于单个字节的所有数字量（例如，错误值、自历元开始的秒数和映射生存期）都以传统的IETF网络字节顺序（即，最高有效字节优先）传输。
Non-numeric quantities in NAT-PMP larger than a single byte (e.g., the NAT gateway's external IP address) are transmitted in the natural byte order, with no byte swapping.
NAT-PMP中大于单个字节的非数字量（例如，NAT网关的外部IP地址）以自然字节顺序传输，不进行字节交换。
This document specifies version 0 of the protocol. Any NAT-PMP gateway implementing this version of the protocol, receiving a request with a version number other than 0, MUST return result code 1 (Unsupported Version), indicating the highest version number it does support (i.e., 0) in the version field of the response.
此文档指定协议的版本0。任何实现此版本协议的NAT-PMP网关，接收到版本号不是0的请求时，必须返回结果代码1（不支持的版本），在响应的版本字段中指示其支持的最高版本号（即0）。
Opcodes between 0 and 127 are client requests. Opcodes from 128 to 255 are corresponding server responses. Responses always contain a 16-bit result code in network byte order. A result code of zero indicates success. Responses also contain a 32-bit unsigned integer corresponding to the number of seconds since the NAT gateway was rebooted or since its port mapping state was otherwise reset.
介于0和127之间的操作码是客户端请求。128到255之间的操作码是对应的服务器响应。响应始终包含网络字节顺序的16位结果代码。结果代码为零表示成功。响应还包含一个32位无符号整数，对应于NAT网关重新启动或端口映射状态重置后的秒数。
This protocol SHOULD only be used when the client determines that its primary IPv4 address is in one of the private IPv4 address ranges defined in "Address Allocation for Private Internets" [RFC1918]. This includes the address ranges 10/8, 172.16/12, and 192.168/16.
仅当客户端确定其主IPv4地址位于“专用Internet地址分配”[RFC1918]中定义的专用IPv4地址范围之一时，才应使用此协议。这包括地址范围10/8、172.16/12和192.168/16。
Clients always send their NAT-PMP requests to their default gateway, as learned via DHCP [RFC2131], or similar means. This protocol is designed for small home networks, with a single logical link (subnet) where the client's default gateway is also the NAT for that network. For more complicated networks where the NAT is some device other than the client's default gateway, this protocol is not appropriate.
客户端总是将其NAT-PMP请求发送到其默认网关，这是通过DHCP[RFC2131]或类似方式了解到的。此协议设计用于小型家庭网络，具有单个逻辑链路（子网），其中客户端的默认网关也是该网络的NAT。对于NAT不是客户端默认网关的设备的更复杂的网络，此协议不适用。
NAT gateways are often low-cost devices, with limited memory and CPU speed. For this reason, to avoid making excessive demands on the NAT gateway, clients SHOULD NOT issue multiple concurrent requests. If a client needs to perform multiple requests (e.g., on boot, wake from sleep, network connection, etc.), it SHOULD queue them and issue them serially, one at a time. Once the NAT gateway responds to one request the client machine may issue the next. In the case of a fast NAT gateway, the client may be able to complete requests at a rate of hundreds per second. In the case of a slow NAT gateway that takes perhaps half a second to respond to a NAT-PMP request, the client SHOULD respect this and allow the NAT gateway to operate at the pace it can manage, and not overload it by issuing requests faster than the rate it's answering them.
NAT网关通常是低成本设备，内存和CPU速度有限。因此，为了避免对NAT网关提出过多的要求，客户端不应该发出多个并发请求。如果客户机需要执行多个请求（例如，启动时、从睡眠中唤醒、网络连接等），它应该对它们进行排队，并一次一个地串行发出它们。一旦NAT网关响应一个请求，客户机可能会发出下一个请求。在快速NAT网关的情况下，客户端可能能够以每秒数百次的速度完成请求。如果NAT网关速度较慢，响应NAT-PMP请求可能需要半秒的时间，客户机应尊重这一点，并允许NAT网关以其能够管理的速度运行，而不是通过发出请求的速度超过其响应速度而使其过载。
To determine the external IPv4 address, or to request a port mapping, a NAT-PMP client sends its request packet to port 5351 of its configured gateway address, and waits 250 ms for a response. If no NAT-PMP response is received from the gateway after 250 ms, the client retransmits its request and waits 500 ms. The client SHOULD repeat this process with the interval between attempts doubling each time. If, after sending its ninth attempt (and then waiting for 64 seconds), the client has still received no response, then it SHOULD conclude that this gateway does not support NAT Port Mapping Protocol and MAY log an error message indicating this fact. In addition, if the NAT-PMP client receives an "ICMP Port Unreachable" message from
为了确定外部IPv4地址或请求端口映射，NAT-PMP客户端将其请求数据包发送到其配置的网关地址的端口5351，并等待250毫秒以等待响应。如果250毫秒后没有从网关收到NAT-PMP响应，则客户端将重新传输其请求并等待500毫秒。客户端应重复此过程，每次尝试之间的间隔应加倍。如果在发送其第九次尝试（然后等待64秒）后，客户端仍然没有收到响应，那么它应该得出结论，该网关不支持NAT端口映射协议，并且可能会记录一条错误消息，指出这一事实。此外，如果NAT-PMP客户端从接收到“ICMP端口不可访问”消息
the gateway for port 5351, then it can skip any remaining retransmissions and conclude immediately that the gateway does not support NAT-PMP.
如果网关不支持端口5351，则它可以跳过任何剩余的重新传输，并立即断定网关不支持NAT-PMP。
As a performance optimization the client MAY record this information and use it to suppress further attempts to use NAT-PMP, but the client should not retain this information for too long. In particular, any event that may indicate a potential change of gateway or a change in gateway configuration (hardware link change indication, change of gateway MAC address, acquisition of new DHCP lease, receipt of NAT-PMP announcement packet from gateway, etc.) should cause the client to discard its previous information regarding the gateway's lack of NAT-PMP support, and send its next NAT-PMP request packet normally.
作为性能优化，客户端可以记录此信息并使用它来抑制进一步尝试使用NAT-PMP，但客户端不应将此信息保留太长时间。特别是，可能指示网关的潜在变化或网关配置变化的任何事件（硬件链路变化指示、网关MAC地址变化、获取新的DHCP租约、从网关接收NAT-PMP公告数据包等）应使客户端丢弃其先前关于网关缺少NAT-PMP支持的信息，并正常发送其下一个NAT-PMP请求数据包。
When deleting a port mapping, the client uses the same initial 250 ms timeout, doubling on each successive interval, except that clients may choose not to try the full nine times before giving up. This is because mapping deletion requests are in some sense advisory. They are useful for efficiency, but not required for correctness; it is always possible for client software to crash, or for power to fail, or for a client device to be physically unplugged from the network before it gets a chance to send its mapping deletion request(s), so NAT gateways already need to cope with this case. Because of this, it may be acceptable for a client to retry only once or twice before giving up on deleting its port mapping(s), but a client SHOULD always send at least one deletion request whenever possible, to reduce the amount of stale state that accumulates on NAT gateways.
删除端口映射时，客户端使用相同的初始250毫秒超时，每个连续间隔加倍，但客户端可能选择在放弃之前不尝试全部九次。这是因为映射删除请求在某种意义上是建议性的。它们对于效率是有用的，但对于正确性不是必需的；客户端软件总是有可能崩溃，或者断电，或者客户端设备在有机会发送其映射删除请求之前从网络上物理拔出，因此NAT网关已经需要处理这种情况。因此，客户机在放弃删除其端口映射之前只重试一次或两次是可以接受的，但客户机应始终尽可能发送至少一个删除请求，以减少NAT网关上累积的过时状态量。
A client need not continue trying to delete a port mapping after the time when that mapping would naturally have expired anyway.
客户端无需在端口映射自然过期后继续尝试删除该映射。
To determine the external address, the client behind the NAT sends the following UDP payload to port 5351 of the configured gateway address:
为了确定外部地址，NAT后面的客户端将以下UDP有效负载发送到所配置网关地址的端口5351：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A compatible NAT gateway MUST generate a response with the following format:
兼容NAT网关必须生成以下格式的响应：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 128 + 0 | Result Code (net byte order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Since Start of Epoch (in network byte order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External IPv4 Address (a.b.c.d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 128 + 0 | Result Code (net byte order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Since Start of Epoch (in network byte order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External IPv4 Address (a.b.c.d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This response indicates that the NAT gateway implements this version of the protocol, and returns the external IPv4 address of the NAT gateway. If the result code is non-zero, the value of the External IPv4 Address field is undefined (MUST be set to zero on transmission, and MUST be ignored on reception).
此响应表示NAT网关实现此版本的协议，并返回NAT网关的外部IPv4地址。如果结果代码非零，则外部IPv4地址字段的值未定义（传输时必须设置为零，接收时必须忽略）。
The NAT gateway MUST fill in the Seconds Since Start of Epoch field with the time elapsed since its port mapping table was initialized on startup, or reset for any other reason (see Section 3.6, "Seconds Since Start of Epoch").
NAT网关必须在“自历元开始的秒数”字段中填入自其端口映射表在启动时初始化或因任何其他原因重置以来经过的时间（请参阅第3.6节“自历元开始的秒数”）。
Upon receiving a response packet, the client MUST check the source IP address, and silently discard the packet if the address is not the address of the gateway to which the request was sent.
在接收到响应数据包后，客户端必须检查源IP地址，如果该地址不是请求发送到的网关的地址，则会自动丢弃该数据包。
Upon boot, acquisition of an external IPv4 address, subsequent change of the external IPv4 address, reboot, or any other event that may indicate possible loss or change of NAT mapping state, the NAT gateway MUST send a gratuitous response to the link-local multicast address 224.0.0.1, port 5350, with the packet format above, to notify clients of the external IPv4 address and Seconds Since Start of Epoch.
在引导、获取外部IPv4地址、随后更改外部IPv4地址、重新引导或可能指示NAT映射状态可能丢失或更改的任何其他事件时，NAT网关必须向链路本地多播地址224.0.0.1、端口5350发送具有上述包格式的无偿响应，通知客户端外部IPv4地址以及自新纪元开始后的秒数。
To accommodate packet loss, the NAT gateway SHOULD multicast 10 address notifications. The interval between the first two notifications SHOULD be 250 ms, and the interval between each subsequent notification SHOULD double. The Seconds Since Start of Epoch field in each transmission MUST be updated appropriately to reflect the passage of time, so as not to trigger unnecessary additional mapping renewals (see Section 3.7, "Recreating Mappings on NAT Gateway Reboot").
为了适应数据包丢失，NAT网关应该多播10个地址通知。前两次通知之间的间隔应为250毫秒，随后每次通知之间的间隔应加倍。每次传输中的“自历元开始算起的秒数”字段必须适当更新，以反映时间的推移，从而不会触发不必要的额外映射更新（请参阅第3.7节“在NAT网关重新启动时重新创建映射”）。
Upon receiving a gratuitous address announcement packet, the client MUST check the source IP address, and silently discard the packet if the address is not the address of the client's current configured gateway. This is to guard against inadvertent misconfigurations where there may be more than one NAT gateway active on the network.
在接收到免费的地址公告数据包后，客户端必须检查源IP地址，如果该地址不是客户端当前配置的网关的地址，则会自动丢弃该数据包。这是为了防止在网络上可能有多个NAT网关处于活动状态时出现意外错误配置。
If the source IP address is correct, then the Seconds Since Start of Epoch field is checked as described in Section 3.6, and if the value is outside the expected plausible range, indicating that a NAT gateway state loss has occurred, then the NAT-PMP client promptly recreates all its active port mapping leases, as described in Section 3.7, "Recreating Mappings on NAT Gateway Reboot".
如果源IP地址正确，则按照第3.6节所述检查“自历元开始算起的秒数”字段，如果该值超出了预期的合理范围，表明NAT网关状态丢失已发生，则NAT-PMP客户端会立即重新创建其所有活动端口映射租约，如第3.7节所述，“在NAT网关重新启动时重新创建映射”。
IMPLEMENTATION NOTE: Earlier implementations of NAT-PMP used UDP port 5351 as the destination both for client requests (address and port mapping) and for address announcements. NAT-PMP servers would listen on UDP 5351 for client requests, and NAT-PMP clients would listen on UDP 5351 for server announcements. However, implementers encountered difficulties when a single device is acting in both roles, for example, a home computer with Internet Sharing enabled. This computer is acting in the role of NAT-PMP server to its DHCP clients, yet, at the same time, it has to act in the role of NAT-PMP client in order to determine whether it is, itself, behind another NAT gateway. While in principle it might be possible on some operating systems for two processes to coordinate sharing of a single UDP port, on many platforms this is difficult or even impossible, so, for pragmatic engineering reasons, it is convenient to have clients listen on UDP 5350 and servers listen on UDP 5351.
实现说明：NAT-PMP的早期实现使用UDP端口5351作为客户端请求（地址和端口映射）和地址公告的目标。NAT-PMP服务器将在UDP 5351上侦听客户端请求，NAT-PMP客户端将在UDP 5351上侦听服务器公告。然而，当单个设备同时扮演两个角色时，实现者遇到了困难，例如，启用Internet共享的家庭计算机。这台计算机在DHCP客户端上扮演NAT-PMP服务器的角色，但同时，它必须扮演NAT-PMP客户端的角色，以确定它本身是否在另一个NAT网关后面。原则上，在某些操作系统上，两个进程可以协调单个UDP端口的共享，但在许多平台上，这很困难，甚至是不可能的，因此，出于实用的工程原因，让客户端监听UDP 5350，让服务器监听UDP 5351是很方便的。
IMPLEMENTATION NOTE: A given host may have more than one independent NAT-PMP client running at the same time, and address announcements need to be available to all of them. Clients should therefore set the SO_REUSEPORT option or equivalent in order to allow other processes to also listen on port 5350. Additionally, implementers have encountered issues when one or more processes on the same device listen to port 5350 on *all* addresses. Clients should therefore bind specifically to 224.0.0.1:5350, not to 0.0.0.0:5350.
实施说明：一个给定的主机可能有多个独立的NAT-PMP客户端同时运行，并且地址公告需要对所有主机都可用。因此，客户端应设置SO_REUSEPORT选项或等效选项，以便允许其他进程也在端口5350上侦听。此外，当同一设备上的一个或多个进程侦听*all*地址上的端口5350时，实现者遇到了问题。因此，客户端应该专门绑定到224.0.0.1:5350，而不是0.0.0.0:5350。
To create a mapping, the client sends a UDP packet to port 5351 of the gateway's internal IP address with the following format:
要创建映射，客户端将UDP数据包发送到网关内部IP地址的端口5351，格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = x | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Suggested External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Port Mapping Lifetime in Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = x | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Suggested External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Port Mapping Lifetime in Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Opcodes supported: 1 - Map UDP 2 - Map TCP
支持的操作码：1-映射UDP 2-映射TCP
The Reserved field MUST be set to zero on transmission and MUST be ignored on reception.
传输时必须将保留字段设置为零，接收时必须忽略保留字段。
The Ports and Lifetime are transmitted in the traditional network byte order (i.e., most significant byte first).
端口和生存期以传统的网络字节顺序传输（即，最高有效字节优先）。
The Internal Port is set to the local port on which the client is listening.
内部端口设置为客户端正在侦听的本地端口。
If the client would prefer to have a high-numbered "anonymous" external port assigned, then it should set the Suggested External Port to zero, which indicates to the gateway that it should allocate a high-numbered port of its choosing. If the client would prefer instead to have the mapped external port be the same as its local internal port if possible (e.g., a web server listening on port 80 that would ideally like to have external port 80), then it should set the Suggested External Port to the desired value. However, the gateway is not obliged to assign the port suggested, and may choose not to, either for policy reasons (e.g., port 80 is reserved and clients may not request it) or because that port has already been assigned to some other client. Because of this, some product developers have questioned the value of having the Suggested External Port field at all. The reason is for failure recovery. Most low-cost home NAT gateways do not record temporary port mappings in persistent storage, so if the gateway crashes or is rebooted, all the mappings are lost. A renewal packet is formatted identically to an initial mapping request packet, except that for renewals the client sets the Suggested External Port field to the port the gateway actually assigned, rather than the port the client originally wanted.
如果客户端希望分配一个高编号的“匿名”外部端口，那么它应该将建议的外部端口设置为零，这向网关指示它应该分配一个其选择的高编号端口。如果客户端希望映射的外部端口与其本地内部端口相同（如果可能）（例如，侦听端口80的web服务器理想情况下希望具有外部端口80），则应将建议的外部端口设置为所需值。然而，网关没有义务分配所建议的端口，并且可能出于策略原因（例如，端口80被保留，客户端可能不会请求）或者因为该端口已经分配给其他客户端，而选择不分配。因此，一些产品开发人员对使用建议的外部端口字段的价值提出了质疑。原因是故障恢复。大多数低成本家庭NAT网关不会在持久性存储中记录临时端口映射，因此如果网关崩溃或重新启动，所有映射都会丢失。续订数据包的格式与初始映射请求数据包相同，只是对于续订，客户端将建议的外部端口字段设置为网关实际分配的端口，而不是客户端最初想要的端口。
When a freshly rebooted NAT gateway receives a renewal packet from a client, it appears to the gateway just like an ordinary initial request for a port mapping, except that in this case the Suggested External Port is likely to be one that the NAT gateway *is* willing to allocate (it allocated it to this client right before the reboot, so it should presumably be willing to allocate it again). This improves the stability of external ports across NAT gateway restarts.
当新重新启动的NAT网关从客户端接收到更新数据包时，网关会觉得它与端口映射的普通初始请求一样，只是在这种情况下，建议的外部端口可能是NAT网关*愿意*分配的端口（它在重新启动之前就分配给了这个客户机，所以它应该愿意再次分配）。这提高了NAT网关重新启动时外部端口的稳定性。
The RECOMMENDED Port Mapping Lifetime is 7200 seconds (two hours).
建议的端口映射生存期为7200秒（两小时）。
After sending the port mapping request, the client then waits for the NAT gateway to respond. If after 250 ms the client hasn't received a response from the gateway, the client SHOULD reissue its request as described above in Section 3.1, "Requests and Responses".
在发送端口映射请求后，客户端然后等待NAT网关响应。如果在250毫秒之后，客户端没有收到来自网关的响应，则客户端应按照上文第3.1节“请求和响应”中所述重新发出其请求。
The NAT gateway responds with the following packet format:
NAT网关以以下数据包格式响应：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 128 + x | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Since Start of Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Mapped External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Mapping Lifetime in Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 128 + x | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Since Start of Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internal Port | Mapped External Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Mapping Lifetime in Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The epoch time, ports, and lifetime are transmitted in the traditional network byte order (i.e., most significant byte first).
历元时间、端口和生存期以传统的网络字节顺序传输（即，最高有效字节优先）。
The 'x' in the OP field MUST match what the client requested. Some NAT gateways are incapable of creating a UDP port mapping without also creating a corresponding TCP port mapping, and vice versa, and these gateways MUST NOT implement NAT Port Mapping Protocol until this deficiency is fixed. A NAT gateway that implements this protocol MUST be able to create TCP-only and UDP-only port mappings. If a NAT gateway silently creates a pair of mappings for a client that only requested one mapping, then it may expose that client to receiving inbound UDP packets or inbound TCP connection requests that it did not ask for and does not want.
OP字段中的“x”必须与客户端请求的匹配。某些NAT网关在不创建相应的TCP端口映射的情况下无法创建UDP端口映射，反之亦然，并且在修复此缺陷之前，这些网关不得实现NAT端口映射协议。实现此协议的NAT网关必须能够创建仅TCP和仅UDP端口映射。如果NAT网关以静默方式为仅请求一个映射的客户端创建一对映射，则它可能会使该客户端接收其未请求也不希望接收的入站UDP数据包或入站TCP连接请求。
While a NAT gateway MUST NOT automatically create mappings for TCP when the client requests UDP, and vice versa, the NAT gateway MUST reserve the companion port so the same client can choose to map it in the future. For example, if a client requests to map TCP port 80,
当客户端请求UDP时，NAT网关不能自动为TCP创建映射，反之亦然，但NAT网关必须保留配对端口，以便同一客户端将来可以选择映射它。例如，如果客户端请求映射TCP端口80，
as long as the client maintains the lease for that TCP port mapping, another client with a different internal IP address MUST NOT be able to successfully acquire the mapping for UDP port 80.
只要客户端维护该TCP端口映射的租约，另一个具有不同内部IP地址的客户端就不能成功获取UDP端口80的映射。
The client normally requests the external port matching the internal port. If that external port is not available, the NAT gateway MUST return an available external port if possible, or return an error code if no external ports are available.
客户端通常请求与内部端口匹配的外部端口。如果该外部端口不可用，NAT网关必须返回可用的外部端口（如果可能），或者如果没有可用的外部端口，则返回错误代码。
The source address of the packet MUST be used for the internal address in the mapping. This protocol is not intended to facilitate one device behind a NAT creating mappings for other devices. If there are legacy devices that require inbound mappings, permanent mappings can be created manually by the user through an administrative interface, just as they are today.
数据包的源地址必须用于映射中的内部地址。此协议的目的不是为了方便NAT后面的一个设备为其他设备创建映射。如果存在需要入站映射的旧设备，则用户可以通过管理界面手动创建永久映射，就像现在一样。
If a mapping already exists for a given internal address and port (whether that mapping was created explicitly using NAT-PMP, implicitly as a result of an outgoing TCP SYN packet, or manually by a human administrator) and that client requests another mapping for the same internal port (possibly requesting a different external port), then the mapping request should succeed, returning the already-assigned external port. This is necessary to handle the case where a client requests a mapping with suggested external port X, and is granted a mapping with actual external port Y, but the acknowledgment packet gets lost. When the client retransmits its mapping request, it should get back the same positive acknowledgment as was sent (and lost) the first time.
如果给定的内部地址和端口已经存在映射（该映射是使用NAT-PMP显式创建的，是由于传出TCP SYN数据包而隐式创建的，还是由人工管理员手动创建的），并且该客户端请求相同内部端口的另一映射（可能请求不同的外部端口），然后映射请求应该成功，返回已分配的外部端口。这对于处理客户端请求使用建议的外部端口X的映射，并被授予使用实际外部端口Y的映射，但确认数据包丢失的情况是必要的。当客户端重新传输其映射请求时，它应该返回与第一次发送（和丢失）相同的肯定确认。
The NAT gateway MUST NOT accept mapping requests destined to the NAT gateway's external IP address or received on its external network interface. Only packets received on the internal interface(s) with a destination address matching the internal address(es) of the NAT gateway should be allowed.
NAT网关不得接受发往NAT网关外部IP地址或在其外部网络接口上接收的映射请求。只允许在内部接口上接收到目标地址与NAT网关内部地址匹配的数据包。
The NAT gateway MUST fill in the Seconds Since Start of Epoch field with the time elapsed since its port mapping table was initialized on startup or reset for any other reason (see Section 3.6, "Seconds Since Start of Epoch").
NAT网关必须在“自历元开始后的秒数”字段中填入自其端口映射表在启动时初始化或因任何其他原因重置以来经过的时间（请参阅第3.6节“自历元开始后的秒数”）。
The Port Mapping Lifetime is an unsigned integer in seconds. The NAT gateway MAY reduce the lifetime from what the client requested. The NAT gateway SHOULD NOT offer a lease lifetime greater than that requested by the client.
端口映射生存期是以秒为单位的无符号整数。NAT网关可以减少客户端请求的生存期。NAT网关提供的租用寿命不应大于客户端请求的租用寿命。
Upon receiving the response packet, the client MUST check the source IP address, and silently discard the packet if the address is not the address of the gateway to which the request was sent.
在接收到响应数据包后，客户端必须检查源IP地址，如果该地址不是请求发送到的网关的地址，则会自动丢弃该数据包。
The client SHOULD begin trying to renew the mapping halfway to expiry time, like DHCP. The renewal packet should look exactly the same as a request packet, except that the client SHOULD set the Suggested External Port to what the NAT gateway previously mapped, not what the client originally suggested. As described above, this enables the gateway to automatically recover its mapping state after a crash or reboot.
客户端应该开始尝试在到期时间的一半更新映射，如DHCP。续订数据包看起来应该与请求数据包完全相同，只是客户端应该将建议的外部端口设置为NAT网关先前映射的端口，而不是客户端最初建议的端口。如上所述，这使网关能够在崩溃或重新启动后自动恢复其映射状态。
A mapping may be destroyed in a variety of ways. If a client fails to renew a mapping, then at the time its lifetime expires, the mapping MUST be automatically deleted. In the common case where the gateway device is a combined DHCP server and NAT gateway, when a client's DHCP address lease expires, the gateway device MAY automatically delete any mappings belonging to that client. Otherwise, a new client being assigned the same IP address could receive unexpected inbound UDP packets or inbound TCP connection requests that it did not ask for and does not want.
映射可能以多种方式被破坏。如果客户端未能续订映射，则在其生存期到期时，必须自动删除映射。在网关设备是DHCP服务器和NAT网关组合的常见情况下，当客户端的DHCP地址租约到期时，网关设备可以自动删除属于该客户端的任何映射。否则，被分配相同IP地址的新客户机可能会收到意外的入站UDP数据包或入站TCP连接请求，这些请求不是它要求的，也不是它想要的。
A client MAY also send an explicit packet to request deletion of a mapping that is no longer needed. A client requests explicit deletion of a mapping by sending a message to the NAT gateway requesting the mapping, with the Requested Lifetime in Seconds set to zero. The Suggested External Port MUST be set to zero by the client on sending, and MUST be ignored by the gateway on reception.
客户端还可以发送显式数据包以请求删除不再需要的映射。客户端通过向请求映射的NAT网关发送消息来请求显式删除映射，请求的生存期（秒）设置为零。客户端在发送时必须将建议的外部端口设置为零，网关在接收时必须忽略该端口。
When a mapping is destroyed successfully as a result of the client explicitly requesting the deletion, the NAT gateway MUST send a response packet that is formatted as defined in Section 3.3, "Requesting a Mapping". The response MUST contain a result code of 0, the internal port as indicated in the deletion request, an external port of 0, and a lifetime of 0. The NAT gateway MUST respond to a request to destroy a mapping that does not exist as if the request were successful. This is because of the case where the acknowledgment is lost, and the client retransmits its request to delete the mapping. In this case, the second request to delete the mapping MUST return the same response packet as the first request.
当客户端明确请求删除导致映射成功销毁时，NAT网关必须发送一个响应数据包，其格式如第3.3节“请求映射”中所定义。响应必须包含结果代码0、删除请求中指示的内部端口、外部端口0和生存期0。NAT网关必须响应请求以销毁不存在的映射，就像请求成功一样。这是因为确认丢失，客户端重新传输其删除映射的请求。在这种情况下，删除映射的第二个请求必须返回与第一个请求相同的响应数据包。
If the deletion request was unsuccessful, the response MUST contain a non-zero result code and the requested mapping; the lifetime is undefined (MUST be set to zero on transmission, and MUST be ignored on reception). If the client attempts to delete a port mapping that was manually assigned by some kind of configuration tool, the NAT gateway MUST respond with a "Not Authorized" error, result code 2.
如果删除请求不成功，则响应必须包含非零结果代码和请求的映射；寿命未定义（传输时必须设置为零，接收时必须忽略）。如果客户端试图删除由某种配置工具手动分配的端口映射，NAT网关必须以“未授权”错误响应，结果代码为2。
When a mapping is destroyed as a result of its lifetime expiring or for any other reason, if the NAT gateway's internal state indicates that there are still active TCP connections traversing that now-defunct mapping, then the NAT gateway SHOULD send appropriately constructed TCP RST (reset) packets both to the local client and to the remote peer on the Internet to terminate that TCP connection.
当映射因其生存期到期或任何其他原因而被破坏时，如果NAT网关的内部状态指示仍有活动TCP连接正在遍历该现已失效的映射，则NAT网关应发送适当构造的TCP RST（重置）将数据包发送到本地客户端和Internet上的远程对等方，以终止TCP连接。
A client can request the explicit deletion of all its UDP or TCP mappings by sending the same deletion request to the NAT gateway with the external port, internal port, and lifetime set to zero. A client MAY choose to do this when it first acquires a new IP address in order to protect itself from port mappings that were performed by a previous owner of the IP address. After receiving such a deletion request, the gateway MUST delete all its UDP or TCP port mappings (depending on the opcode). The gateway responds to such a deletion request with a response as described above, with the internal port set to zero. If the gateway is unable to delete a port mapping, for example, because the mapping was manually configured by the administrator, the gateway MUST still delete as many port mappings as possible, but respond with a non-zero result code. The exact result code to return depends on the cause of the failure. If the gateway is able to successfully delete all port mappings as requested, it MUST respond with a result code of zero.
客户端可以通过将相同的删除请求发送到NAT网关，并将外部端口、内部端口和生存期设置为零，请求显式删除其所有UDP或TCP映射。客户机可能会在首次获取新IP地址时选择这样做，以保护自己不受IP地址前所有者执行的端口映射的影响。收到此类删除请求后，网关必须删除其所有UDP或TCP端口映射（取决于操作码）。网关以如上所述的响应响应这种删除请求，内部端口设置为零。如果网关无法删除端口映射，例如，因为映射是由管理员手动配置的，则网关仍必须删除尽可能多的端口映射，但以非零结果代码响应。返回的确切结果代码取决于故障原因。如果网关能够根据请求成功删除所有端口映射，则其响应结果代码必须为零。
Currently defined result codes:
当前定义的结果代码：
0 - Success 1 - Unsupported Version 2 - Not Authorized/Refused (e.g., box supports mapping, but user has turned feature off) 3 - Network Failure (e.g., NAT box itself has not obtained a DHCP lease) 4 - Out of resources (NAT box cannot create any more mappings at this time) 5 - Unsupported opcode
0-成功1-不支持的版本2-未授权/拒绝（例如，box支持映射，但用户已关闭功能）3-网络故障（例如，NAT box本身未获得DHCP租约）4-资源不足（NAT box此时无法创建更多映射）5-不支持的操作码
If the version in the request is not zero, then the NAT-PMP server MUST return the following "Unsupported Version" error response to the client:
如果请求中的版本不是零，则NAT-PMP服务器必须向客户端返回以下“不支持的版本”错误响应：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 0 | Result Code = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Since Start of Epoch (in network byte order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 0 | Result Code = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Since Start of Epoch (in network byte order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the opcode in the request is 128 or greater, then this is not a request; it's a response, and the NAT-PMP server MUST silently ignore it. Otherwise, if the opcode in the request is less than 128, but is not a supported opcode (currently 0, 1, or 2), then the entire request MUST be returned to the sender, with the top bit of the opcode set (to indicate that this is a response) and the result code set to 5 (Unsupported opcode).
如果请求中的操作码为128或更大，则这不是请求；这是一个响应，NAT-PMP服务器必须默默地忽略它。否则，如果请求中的操作码小于128，但不是受支持的操作码（当前为0、1或2），则必须将整个请求返回给发送方，操作码的顶部位设置为（表示这是响应），结果代码设置为5（不支持的操作码）。
For version 0 and a supported opcode (0, 1, or 2), if the operation fails for some reason (Not Authorized, Network Failure, or Out of resources), then a valid response MUST be sent to the client, with the top bit of the opcode set (to indicate that this is a response) and the result code set appropriately. Other fields in the response MUST be set appropriately. Specifically:
对于版本0和支持的操作码（0、1或2），如果操作因某种原因（未授权、网络故障或资源不足）失败，则必须向客户端发送有效响应，并设置操作码的顶部位（以指示这是响应）和相应的结果码。必须适当设置响应中的其他字段。明确地：
o Seconds Since Start of Epoch MUST be set correctly
o 必须正确设置自历元开始的秒数
o The External IPv4 Address should be set to the correct address, or to 0.0.0.0, as appropriate.
o 外部IPv4地址应设置为正确的地址，或根据需要设置为0.0.0.0。
o The Internal Port MUST be set to the client's requested Internal Port. This is particularly important, because the client needs this information to identify which request suffered the failure.
o 内部端口必须设置为客户端请求的内部端口。这一点尤其重要，因为客户机需要这些信息来确定哪个请求遭到了失败。
o The Mapped External Port and Port Mapping Lifetime MUST be set appropriately -- i.e., zero if no successful port mapping was created.
o 必须适当设置映射的外部端口和端口映射生存期，即，如果未创建成功的端口映射，则为零。
Should future NAT-PMP opcodes be defined, their error responses MUST similarly be specified to include sufficient information to identify which request suffered the failure. By design, NAT-PMP messages do not contain any transaction identifiers. All NAT-PMP messages are idempotent and self-describing; therefore, the specifications of future NAT-PMP messages need to include enough information for their responses to be self-describing.
如果定义了未来的NAT-PMP操作码，则必须类似地指定它们的错误响应，以包括足够的信息来识别哪个请求遭受了故障。根据设计，NAT-PMP消息不包含任何事务标识符。所有NAT-PMP消息都是幂等的和自描述的；因此，未来NAT-PMP消息的规范需要包含足够的信息，以便其响应能够自我描述。
Clients MUST be able to properly handle result codes not defined in this document. Undefined results codes MUST be treated as fatal errors of the request.
客户必须能够正确处理本文档中未定义的结果代码。未定义的结果代码必须视为请求的致命错误。
Every packet sent by the NAT gateway includes a Seconds Since Start of Epoch (SSSoE) field. If the NAT gateway resets or loses the state of its port mapping table, due to reboot, power failure, or any other reason, it MUST reset its epoch time and begin counting SSSoE from zero again. Whenever a client receives any packet from the NAT gateway, either unsolicited or in response to a client request, the client computes its own conservative estimate of the expected SSSoE value by taking the SSSoE value in the last packet it received from the gateway and adding 7/8 (87.5%) of the time elapsed according to the client's local clock since that packet was received. If the SSSoE in the newly received packet is less than the client's conservative estimate by more than 2 seconds, then the client concludes that the NAT gateway has undergone a reboot or other loss of port mapping state, and the client MUST immediately renew all its active port mapping leases as described in Section 3.7, "Recreating Mappings on NAT Gateway Reboot".
NAT网关发送的每个数据包都包含一个自历元开始的秒（SSSoE）字段。如果由于重新启动、电源故障或任何其他原因，NAT网关重置或丢失其端口映射表的状态，则它必须重置其历元时间，并再次开始从零开始计算SSSoE。每当客户机收到来自NAT网关的任何数据包时，无论是未经请求的还是响应客户机请求的，客户机都会通过获取从网关收到的最后一个数据包中的SSSoE值并加上7/8（87.5%）来计算其对预期SSSoE值的保守估计自收到该数据包以来，根据客户端的本地时钟经过的时间。如果新接收的数据包中的SSSoE比客户端的保守估计值少2秒以上，则客户端认为NAT网关已重新启动或其他端口映射状态丢失，客户端必须立即更新其所有活动端口映射租约，如第3.7节所述，“在NAT网关重新启动时重新创建映射”。
The NAT gateway MAY store mappings in persistent storage so that, when it is powered off or rebooted, it remembers the port mapping state of the network.
NAT网关可以将映射存储在持久性存储器中，以便在关机或重新启动时记住网络的端口映射状态。
However, maintaining this state is not essential for correct operation. When the NAT gateway powers on or clears its port mapping state as the result of a configuration change, it MUST reset the epoch time and re-announce its IPv4 address as described in Section 3.2.1, "Announcing Address Changes". Reception of this packet where time has apparently gone backwards serves as a hint to clients on the network that they SHOULD immediately send renewal packets (to immediately recreate their mappings) instead of waiting until the originally scheduled time for those renewals. Clients who miss receiving those gateway announcement packets for any reason will still renew their mappings at the originally scheduled time and cause their mappings to be recreated; it will just take a little longer for these clients.
但是，保持此状态对于正确操作不是必需的。当NAT网关因配置更改而通电或清除其端口映射状态时，它必须重置历元时间，并按照第3.2.1节“宣布地址更改”中的说明重新宣布其IPv4地址。在时间明显倒转的情况下接收此数据包，可以向网络上的客户端发出提示，提示他们应该立即发送续订数据包（以立即重新创建其映射），而不是等到这些续订的原始计划时间。由于任何原因错过接收这些网关公告数据包的客户端仍将在最初计划的时间更新其映射，并导致重新创建其映射；对于这些客户来说，只需要稍微长一点。
A mapping renewal packet is formatted identically to an original mapping request; from the point of view of the client, it is a renewal of an existing mapping, but from the point of view of the freshly rebooted NAT gateway, it appears as a new mapping request.
映射更新包的格式与原始映射请求相同；从客户端的角度来看，它是对现有映射的更新，但从新重新启动的NAT网关的角度来看，它似乎是一个新的映射请求。
This self-healing property of the protocol is very important.
协议的这种自愈特性非常重要。
The remarkable reliability of the Internet as a whole derives in large part from the fact that important state is held in the endpoints, not in the network itself [ETEAISD]. Power-cycling an Ethernet switch results only in a brief interruption in the flow of packets; established TCP connections through that switch are not broken, merely delayed for a few seconds. Indeed, a failing Ethernet switch can even be replaced with a new one, and as long as the cables are transferred over reasonably quickly, after the upgrade all the TCP connections that were previously going through the old switch will be unbroken and now going through the new one. The same is true of IP routers, wireless base stations, etc. The one exception is NAT gateways. Because the port mapping state is required for the NAT gateway to know where to forward inbound packets, loss of that state breaks connectivity through the NAT gateway. By allowing clients to detect when this loss of NAT gateway state has occurred, and recreate it on demand, we turn hard state in the network into soft state, and allow it to be recovered automatically when needed.
互联网作为一个整体，其显著的可靠性在很大程度上源于这样一个事实，即重要状态存在于端点，而不是网络本身[ETEAID]。以太网交换机的电源循环只会导致数据包流的短暂中断；通过该交换机建立的TCP连接没有中断，只是延迟了几秒钟。事实上，一个出现故障的以太网交换机甚至可以用一个新的交换机替换，只要电缆传输速度合理，升级后，以前通过旧交换机的所有TCP连接都不会中断，现在通过新交换机。IP路由器、无线基站等也是如此。NAT网关是一个例外。由于NAT网关需要端口映射状态才能知道在何处转发入站数据包，因此该状态的丢失会中断通过NAT网关的连接。通过允许客户端检测何时发生NAT网关状态丢失，并按需重新创建，我们将网络中的硬状态转变为软状态，并允许在需要时自动恢复。
Without this automatic recreation of soft state in the NAT gateway, reliable long-term networking would not be achieved. As mentioned above, the reliability of the Internet does not come from trying to build a perfect network in which errors never happen, but from accepting that in any sufficiently large system there will always be some component somewhere that's failing, and designing mechanisms that can handle those failures and recover. To illustrate this point with an example, consider the following scenario: Imagine a network security camera that has a web interface and accepts incoming connections from web browser clients. Imagine this network security camera uses NAT-PMP or a similar protocol to set up an inbound port mapping in the NAT gateway so that it can receive incoming connections from clients on the other side of the NAT gateway. Now, this camera may well operate for weeks, months, or even years. During that time, it's possible that the NAT gateway could experience a power failure or be rebooted. The user could upgrade the NAT gateway's firmware, or even replace the entire NAT gateway device with a newer model. The general point is that if the camera operates for a long enough period of time, some kind of disruption to the NAT gateway becomes inevitable. The question is not whether the NAT gateway will lose its port mappings, but when, and how often. If the network camera and devices like it on the network can detect when the NAT gateway has lost its port mappings, and recreate them
如果NAT网关中没有这种软状态的自动再现，就无法实现可靠的长期联网。如上所述，互联网的可靠性并不是来自于试图建立一个完美的网络，在这个网络中，错误永远不会发生，而是来自于承认在任何足够大的系统中，总会有一些组件在某个地方出现故障，并设计出能够处理这些故障并进行恢复的机制。用一个例子来说明这一点，考虑下面的场景：想象一个网络安全摄像机，它有一个Web界面，并接受来自Web浏览器客户端的传入连接。假设此网络安全摄像头使用NAT-PMP或类似协议在NAT网关中设置入站端口映射，以便它可以接收来自NAT网关另一端客户端的传入连接。现在，这台相机可以正常工作数周、数月甚至数年。在此期间，NAT网关可能会出现电源故障或重新启动。用户可以升级NAT网关的固件，甚至用更新的型号替换整个NAT网关设备。一般的观点是，如果相机运行足够长的时间，NAT网关将不可避免地受到某种干扰。问题不在于NAT网关是否会丢失其端口映射，而在于何时以及多久丢失一次。如果网络摄像机和网络上类似的设备能够检测到NAT网关何时丢失其端口映射，并重新创建它们
automatically, then these disruptions are self-correcting and largely invisible to the end user. If, on the other hand, the disruptions are not self-correcting, and after a NAT gateway reboot the user has to manually reset or reboot all the other devices on the network too, then these disruptions are *very* visible to the end user. This aspect of the design is part of what makes the difference between a protocol that keeps on working indefinitely over a time scale of months or years, and a protocol that works in brief testing, but in the real world is continually failing and requiring manual intervention to get it going again.
自动地，那么这些中断是自我纠正的，并且对最终用户来说基本上是不可见的。另一方面，如果中断不是自纠正的，并且在NAT网关重新启动后，用户必须手动重置或重新启动网络上的所有其他设备，那么这些中断对最终用户来说*非常*可见。设计的这一方面是使协议在数月或数年的时间范围内无限期地工作的部分原因，而协议在短期测试中工作，但在现实世界中不断失败，需要手动干预才能重新运行。
When a client renews its port mappings as the result of receiving a packet where the Seconds Since Start of Epoch (SSSoE) field indicates that a reboot or similar loss of state has occurred, the client MUST first delay by a random amount of time selected with uniform random distribution in the range 0 to 5 seconds, and then send its first port mapping request. After that request is acknowledged by the gateway, the client may then send its second request, and so on, as rapidly as the gateway allows. The requests SHOULD be issued serially, one at a time; the client SHOULD NOT issue multiple concurrent requests.
当客户端由于接收到一个数据包而更新其端口映射时，其中自Epoch开始的秒数（SSSoE）字段指示已发生重新启动或类似的状态丢失，客户端必须首先延迟随机时间，该时间段以0到5秒的范围内均匀随机分布选择，然后发送其第一个端口映射请求。在网关确认该请求之后，客户机可以尽可能快地发送其第二个请求，依此类推。请求应连续发出，一次一个；客户端不应发出多个并发请求。
The discussion in this section focuses on recreating inbound port mappings after loss of NAT gateway state, because that is the more serious problem. Losing port mappings for outgoing connections destroys those currently active connections, but does not prevent clients from establishing new outgoing connections. In contrast, losing inbound port mappings not only destroys all existing inbound connections, but also prevents the reception of any new inbound connections until the port mapping is recreated. Accordingly, we consider recovery of inbound port mappings more important. However, clients that want outgoing connections to survive a NAT gateway reboot can also achieve that using NAT-PMP, in the common case of a residential NAT gateway with a single, relatively stable, external IP address. After initiating an outbound TCP connection (which will cause the NAT gateway to establish an implicit port mapping), the client should send the NAT gateway a port mapping request for the source port of its TCP connection, which will cause the NAT gateway to send a response giving the external port it allocated for that mapping. The client can then store this information, and use it later to recreate the mapping if it determines that the NAT gateway has lost its mapping state.
本节中的讨论重点是在NAT网关状态丢失后重新创建入站端口映射，因为这是一个更严重的问题。丢失传出连接的端口映射会破坏当前活动的连接，但不会阻止客户端建立新的传出连接。相反，丢失入站端口映射不仅会破坏所有现有的入站连接，还会阻止接收任何新的入站连接，直到重新创建端口映射为止。因此，我们认为入站端口映射的恢复更为重要。但是，如果客户机希望传出连接在NAT网关重新启动后仍能继续运行，则也可以使用NAT-PMP来实现这一点，在通常情况下，住宅NAT网关具有单个相对稳定的外部IP地址。启动出站TCP连接（这将导致NAT网关建立隐式端口映射）后，客户端应向NAT网关发送其TCP连接源端口的端口映射请求，这将导致NAT网关发送一个响应，给出为该映射分配的外部端口。然后，客户机可以存储该信息，并在确定NAT网关已丢失其映射状态时使用该信息重新创建映射。
Note that only devices that are *currently* acting in the role of NAT gateway should participate in NAT-PMP protocol exchanges with clients. A network device that is capable of NAT (and NAT-PMP) but
请注意，只有*当前*扮演NAT网关角色的设备才应参与与客户端的NAT-PMP协议交换。能够进行NAT（和NAT-PMP）但
is currently configured not to perform that function (e.g., it is acting as a traditional IP router, forwarding packets without modifying them) MUST NOT respond to NAT-PMP requests from clients nor send spontaneous NAT-PMP address-change announcements.
当前配置为不执行该功能（例如，它充当传统IP路由器，在不修改数据包的情况下转发数据包）不得响应来自客户端的NAT-PMP请求，也不得发送自发的NAT-PMP地址更改通知。
In particular, a network device not currently acting in the role of NAT gateway should not even respond to NAT-PMP requests by returning an error code such as 2, "Not Authorized/Refused", since to do so is misleading to clients -- it suggests that NAT port mapping is necessary on this network for the client to successfully receive inbound connections, but is not available because the administrator has chosen to disable that functionality.
特别是，当前未充当NAT网关角色的网络设备甚至不应通过返回错误代码（如2，“未授权/拒绝”）来响应NAT-PMP请求，因为这样做会误导客户机——这表明NAT端口映射在该网络上是客户机成功接收入站连接所必需的，但不可用，因为管理员已选择禁用该功能。
Clients should also be careful to avoid making unfounded assumptions, such as the assumption that if the client has an IPv4 address in one of the private IPv4 address ranges [RFC1918], then that means NAT necessarily must be in use. Net 10/8 has enough addresses to build a private network with millions of hosts and thousands of interconnected subnets, all without any use of NAT. Many organizations have built such private networks that benefit from using standard TCP/IP technology, but by choice do not connect to the public Internet. The purpose of NAT-PMP is to mitigate some of the damage caused by NAT. It would be an ironic and unwanted side effect of this protocol if it were to lead well-meaning but misguided developers to create products that refuse to work on a private network *unless* they can find a NAT gateway to talk to. Consequently, a client finding that NAT-PMP is not available on its network should not give up, but should proceed on the assumption that the network may be a traditional routed IP network, with no address translation being used. This assumption may not always be true, but it is better than the alternative of falsely assuming the worst and not even trying to use normal (non-NAT) IP networking.
客户机还应小心避免做出毫无根据的假设，例如，如果客户机的IPv4地址位于一个专用IPv4地址范围[RFC1918]中，则这意味着NAT必须在使用中。Net 10/8有足够的地址来构建一个拥有数百万台主机和数千个互连子网的专用网络，所有这些都不需要任何NAT。许多组织已经建立了这样的私有网络，它们受益于使用标准的TCP/IP技术，但选择不连接到公共互联网。NAT-PMP的目的是减轻NAT造成的一些损害。如果该协议导致善意但被误导的开发人员创建拒绝在专用网络上工作的产品，除非他们能找到NAT网关进行对话，那么这将是一个讽刺和不必要的副作用。因此，发现NAT-PMP在其网络上不可用的客户机不应放弃，而应假设该网络可能是传统路由IP网络，而不使用地址转换。这种假设可能并不总是正确的，但它比错误地假设最坏的情况，甚至不尝试使用正常（非NAT）IP网络要好。
If a network device not currently acting in the role of NAT gateway receives UDP packets addressed to port 5351, it SHOULD respond immediately with an "ICMP Port Unreachable" message to tell the client that it needn't continue with timeouts and retransmissions, and it should assume that NAT-PMP is not available and not needed on this network. Typically, this behavior can be achieved merely by not having an open socket listening on UDP port 5351.
如果当前未担任NAT网关角色的网络设备接收到发往端口5351的UDP数据包，则应立即响应“ICMP端口不可访问”消息，告知客户端不需要继续超时和重新传输，并且应假定NAT-PMP不可用且不需要在此网络上。通常，仅通过不让开放套接字侦听UDP端口5351即可实现此行为。
All NAT mappings, whether created implicitly by an outbound packet, created explicitly using NAT-PMP, or configured statically, are bidirectional. This means that when an outbound packet from a particular internal address and port is translated to an external
所有NAT映射，无论是由出站数据包隐式创建、使用NAT-PMP显式创建还是静态配置，都是双向的。这意味着当来自特定内部地址和端口的出站数据包被转换为外部数据包时
address and port, replies addressed to that external address and port need to be translated back to the corresponding internal address and port.
地址和端口，对该外部地址和端口的回复需要翻译回相应的内部地址和端口。
The converse is also true. When an inbound packet is received that is addressed to an external address and port that matches an existing mapping (implicit, explicit, or static), it is translated to the corresponding internal address and port and forwarded. Outbound replies from that internal address and port need to be translated to the correct external address and port so that they are correctly recognized by the remote peer.
反之亦然。当接收到寻址到与现有映射（隐式、显式或静态）匹配的外部地址和端口的入站数据包时，它将被转换为相应的内部地址和端口并转发。来自该内部地址和端口的出站应答需要转换为正确的外部地址和端口，以便远程对等方正确识别它们。
In particular, if an outbound UDP reply that matches an existing explicit or static mapping is instead treated like a "new" outbound UDP packet, and a new dynamic mapping is created (with a different external address and port), then at the time that packet arrives at the remote peer it will not be recognized as a valid reply. For TCP this bug is quickly spotted because all TCP implementations will ignore replies with the wrong apparent source address and port. For UDP this bug can more easily go unnoticed because some UDP clients neglect to check the source address and port of replies; thus, they will appear to work some of the time with NAT gateways that put the wrong source address and port in outbound packets. All NAT gateways MUST ensure that mappings, however created, are bidirectional.
特别是，如果匹配现有显式或静态映射的出站UDP应答被视为“新”出站UDP数据包，并且创建了一个新的动态映射（具有不同的外部地址和端口），则在该数据包到达远程对等方时，它将不会被识别为有效应答。对于TCP，这个错误很快就会被发现，因为所有TCP实现都会忽略带有错误源地址和端口的回复。对于UDP，这个错误更容易被忽略，因为一些UDP客户端忽略了检查源地址和回复端口；因此，在某些情况下，NAT网关会将错误的源地址和端口放入出站数据包中。所有NAT网关必须确保映射（无论如何创建）是双向的。
The document "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation (NAT)" [RFC3424] covers a number of issues when working with NATs. It outlines some requirements for any document that attempts to work around problems associated with NATs. This section addresses those requirements.
文件“跨网络地址转换（NAT）单边自地址固定（UNSAF）的IAB注意事项”[RFC3424]涵盖了使用NAT时的许多问题。它概述了任何试图解决与NAT相关问题的文档的一些要求。本节阐述了这些要求。
This protocol addresses the needs of TCP and UDP transport peers that are separated from the public Internet by exactly one IPv4 NAT. Such peers must have access to some form of directory server for registering the public IPv4 address and port at which they can be reached.
该协议解决了TCP和UDP传输对等点的需求，这些对等点与公共Internet仅由一个IPv4 NAT隔开。这些对等方必须能够访问某种形式的目录服务器，以便注册公共IPv4地址和可以访问它们的端口。
Any client making use of this protocol SHOULD implement IPv6 support. If a client supports IPv6 and is running on a device with a global IPv6 address, that IPv6 address SHOULD be preferred to the IPv4 external address learned via this NAT mapping protocol. In case other clients do not have IPv6 connectivity, both the IPv4 and IPv6
任何使用此协议的客户端都应实现IPv6支持。如果客户端支持IPv6并在具有全局IPv6地址的设备上运行，则该IPv6地址应优先于通过此NAT映射协议获取的IPv4外部地址。如果其他客户端没有IPv6连接，则IPv4和IPv6
addresses SHOULD be registered with whatever form of directory server is used. Preference SHOULD be given to IPv6 addresses when available. By implementing support for IPv6 and using this protocol for IPv4, vendors can ship products today that will work under both scenarios. As IPv6 becomes more widely deployed, clients of this protocol following these recommendations will transparently make use of IPv6.
无论使用何种形式的目录服务器，都应该注册地址。如果IPv6地址可用，则应优先考虑。通过实施对IPv6的支持并将此协议用于IPv4，供应商现在可以提供在这两种情况下都能工作的产品。随着IPv6的部署越来越广泛，遵循这些建议的此协议的客户端将透明地使用IPv6。
Aside from NATs that do not implement this protocol, there are a number of situations where this protocol may not work.
除了不实现此协议的NAT之外，还有许多情况下此协议可能不起作用。
Some people's primary IPv4 address, assigned by their ISP, may itself be a NAT address. In addition, some people may have an external IPv4 address, but may then double NAT themselves, perhaps by choice or perhaps by accident. Although it might be possible in principle for one NAT gateway to recursively request a mapping from the next one, this document does not advocate that and does not try to prescribe how it would be done.
有些人的主IPv4地址（由ISP分配）本身可能是NAT地址。此外，有些人可能有一个外部IPv4地址，但可能会自己加倍NAT，可能是出于选择，也可能是出于偶然。虽然原则上一个NAT网关可以递归地请求下一个NAT网关的映射，但本文档并不提倡这一点，也不试图规定如何执行。
It would be a lot of work to implement nested NAT port mapping correctly, and there are a number of reasons why the end result might not be as useful as we might hope. Consider the case of an ISP that offers each of its customers only a single NAT address. This ISP could instead have chosen to provide each customer with a single public IPv4 address, or, if the ISP insists on running NAT, it could have chosen to allow each customer a reasonable number of addresses, enough for each customer device to have its own NAT address directly from the ISP. If, instead, this ISP chooses to allow each customer just one and only one NAT address, forcing said customer to run nested NAT in order to use more than one device, it seems unlikely that such an ISP would be so obliging as to provide a NAT service that supports NAT-PMP. Supposing that such an ISP did wish to offer its customers NAT service with NAT-PMP so as to give them the ability to receive inbound connections, this ISP could easily choose to allow each client to request a reasonable number of DHCP addresses from that gateway. Remember that Net 10/8 [RFC1918] allows for over 16 million addresses, so NAT addresses are not in any way in short supply. A single NAT gateway with 16 million available addresses is likely to run out of packet forwarding capacity before it runs out of internal addresses to hand out. In this way, the ISP could offer single-level NAT with NAT-PMP, obviating the need to support nested NAT-PMP. In addition, an ISP that is motivated to provide their customers with unhindered access to the Internet by allowing incoming as well as outgoing connections has better ways to offer this
要正确地实现嵌套NAT端口映射需要做大量的工作，并且有很多原因说明最终结果可能没有我们希望的那么有用。考虑一个ISP的例子，它为每个客户只提供一个NAT地址。该ISP可以选择为每个客户提供一个单一的公共IPv4地址，或者，如果ISP坚持运行NAT，它可以选择为每个客户提供合理数量的地址，足以让每个客户设备直接从ISP获得自己的NAT地址。相反，如果该ISP选择只允许每个客户一个且只有一个NAT地址，迫使该客户运行嵌套NAT以使用多个设备，则该ISP似乎不太可能如此有义务提供支持NAT-PMP的NAT服务。假设这样的ISP确实希望向其客户提供NAT-PMP NAT服务，以便使他们能够接收入站连接，该ISP可以轻松地选择允许每个客户从该网关请求合理数量的DHCP地址。请记住，NET10/8[RFC1918]允许超过1600万个地址，因此NAT地址在任何方面都不会短缺。一个拥有1600万个可用地址的NAT网关很可能在内部地址用完之前就耗尽了数据包转发能力。通过这种方式，ISP可以提供带有NAT-PMP的单级NAT，从而无需支持嵌套NAT-PMP。此外，如果ISP希望通过允许输入和输出连接为其客户提供不受阻碍的互联网访问，那么它有更好的方法来提供这一点
service. Such an ISP could offer its customers real public IPv4 addresses instead of NAT addresses, or could choose to offer its customers full IPv6 connectivity, where no mapping or translation is required at all.
服务这样的ISP可以为客户提供真正的公共IPv4地址，而不是NAT地址，或者可以选择为客户提供完全的IPv6连接，而不需要任何映射或转换。
Note: In the nine years since NAT-PMP was designed, the pool of available IPv4 addresses has been exhausted, and many ISPs now offer translated IPv4 addresses out of necessity. Such ISPs have indicated a willingness to offer PCP service to their customers.
注：自NAT-PMP设计以来的九年中，可用IPv4地址池已经耗尽，许多ISP现在出于需要提供转换后的IPv4地址。此类ISP已表示愿意向其客户提供PCP服务。
If a NAT maps internal addresses to multiple external addresses, then it SHOULD pick one of those external addresses as the one it will support for inbound connections, and for the purposes of this protocol it SHOULD act as if that address were its only address.
如果NAT将内部地址映射到多个外部地址，那么它应该从这些外部地址中选择一个作为它将支持入站连接的地址，并且出于本协议的目的，它应该像该地址是它的唯一地址一样工作。
In some cases, a large network may be subnetted. Some sites may install a NAT gateway and subnet the private network. Such subnetting breaks this protocol because the router address is not necessarily the address of the device performing NAT.
在某些情况下，大型网络可能被划分为子网。有些站点可能会安装NAT网关，并在专用网络中设置子网。这样的子网破坏了这个协议，因为路由器地址不一定是执行NAT的设备的地址。
Addressing this problem is not a high priority. Any site with the resources to set up such a configuration should have the resources to add manual mappings or attain a range of globally unique addresses.
解决这一问题不是高度优先事项。任何有资源设置这种配置的站点都应该有资源添加手动映射或获得一系列全局唯一地址。
Not all NATs will support this protocol. In the case where a client is run behind a NAT that does not support this protocol, the software relying on the functionality of this protocol may be unusable.
并非所有NAT都支持此协议。如果客户端在不支持此协议的NAT后面运行，则依赖此协议功能的软件可能无法使用。
NAT gateways supporting NAT-PMP should also implement "hairpin translation". Hairpin translation means supporting communication between two local clients being served by the same NAT gateway.
支持NAT-PMP的NAT网关也应实现“发夹转换”。发夹翻译意味着支持由同一NAT网关服务的两个本地客户端之间的通信。
Suppose device A is listening on internal address and port 10.0.0.2:80 for incoming connections. Using NAT-PMP, device A has obtained a mapping to external address and port x.x.x.x:80, and has recorded this external address and port in a public directory of some kind. For example, it could have created a DNS SRV record containing this information, and recorded it, using DNS Dynamic Update [RFC3007], in a publicly accessible DNS server. Suppose then that device B, behind the same NAT gateway as device A, but unknowing or uncaring of this fact, retrieves device A's DNS SRV record and attempts to open a TCP connection to x.x.x.x:80. The outgoing
假设设备A正在侦听内部地址和端口10.0.0.2:80以获取传入连接。使用NAT-PMP，设备A已获得到外部地址和端口x.x.x.x:80的映射，并已将该外部地址和端口记录在某种公共目录中。例如，它可以创建一个包含此信息的DNS SRV记录，并使用DNS动态更新[RFC3007]将其记录在一个可公开访问的DNS服务器中。然后假设设备B位于与设备A相同的NAT网关后面，但不知道或不关心这一事实，检索设备A的DNS SRV记录并尝试打开到x.x.x.x:80的TCP连接。即将离任的
packets addressed to this public Internet address will be sent to the NAT gateway for translation and forwarding. Having translated the source address and port number on the outgoing packet, the NAT gateway needs to be smart enough to recognize that the destination address is in fact itself, and then feed this packet back into its packet reception engine, to perform the destination port mapping lookup to translate and forward this packet to device A at address and port 10.0.0.2:80.
发送到此公共Internet地址的数据包将被发送到NAT网关进行翻译和转发。NAT网关在转换了传出数据包上的源地址和端口号后，需要足够智能，以识别目标地址实际上就是它自己，然后将该数据包反馈回其数据包接收引擎，执行目标端口映射查找，将此数据包转换并转发到地址和端口10.0.0.2:80处的设备A。
Any communication over transport protocols other than TCP and UDP will not be served by this protocol. Examples are Generic Routing Encapsulation (GRE), Authentication Header (AH), and Encapsulating Security Payload (ESP).
除了TCP和UDP之外，任何通过传输协议进行的通信都不会由该协议提供服务。例如，通用路由封装（GRE）、身份验证头（AH）和封装安全负载（ESP）。
As IPv6 is deployed, clients of this protocol supporting IPv6 will be able to bypass this protocol and the NAT when communicating with other IPv6 devices. In order to ensure this transition, any client implementing this protocol SHOULD also implement IPv6 and use this solution only when IPv6 is not available to both peers.
部署IPv6时，支持IPv6的此协议的客户端将能够在与其他IPv6设备通信时绕过此协议和NAT。为了确保此转换，任何实现此协议的客户端也应实现IPv6，并且仅当两个对等方都无法使用IPv6时才使用此解决方案。
Existing deployed NATs will not support this protocol. This protocol will only work with NATs that are upgraded to support it.
现有部署的NAT将不支持此协议。此协议仅适用于已升级以支持它的NAT。
As discussed in Section 3.2, "Determining the External Address", only a client on the internal side of the NAT may create port mappings, and it may do so only on its own behalf. By using IP address spoofing, it's possible for one client to delete the port mappings of another client. It's also possible for one client to create port mappings on behalf of another client. In cases where this is a concern, it can be dealt with using IPsec [RFC4301].
如第3.2节“确定外部地址”所述，只有NAT内部的客户端可以创建端口映射，并且只能代表自己创建端口映射。通过使用IP地址欺骗，一个客户端可以删除另一个客户端的端口映射。一个客户端也可以代表另一个客户端创建端口映射。在这种情况下，可以使用IPsec[RFC4301]处理。
The multicast announcements described in Section 3.2.1, "Announcing Address Changes", could be spoofed, facilitating a denial-of-service attack. This makes NAT-PMP unsuitable for use on LANs with large numbers of hosts where one or more of the hosts may be untrustworthy.
第3.2.1节“公布地址更改”中描述的多播公告可能会被欺骗，从而导致拒绝服务攻击。这使得NAT-PMP不适合在具有大量主机的LAN上使用，其中一个或多个主机可能不可信。
Another concern is that rogue software running on a local host could create port mappings for unsuspecting hosts, thereby rendering them vulnerable to external attack. However, it's not clear how realistic this threat model is, since rogue software on a local host could
另一个问题是，在本地主机上运行的恶意软件可能会为不知情的主机创建端口映射，从而使它们容易受到外部攻击。然而，目前还不清楚这种威胁模型有多现实，因为本地主机上的恶意软件可能会
attack such unsuspecting hosts directly itself, without resorting to such a convoluted indirect technique. This concern is also a little misguided because it is based on the assumption that a NAT gateway and a firewall are the same thing, which they are not.
直接攻击这些毫无戒心的主机本身，而无需借助这种复杂的间接技术。这种担心也有点误导，因为它基于NAT网关和防火墙是同一件事的假设，而事实并非如此。
Some people view the property of NATs blocking inbound connections as a security benefit that is undermined by this protocol. The authors of this document have a different point of view. In the days before NAT became prevalent, all hosts had unique public IP addresses, and had unhindered ability to communicate with any other host on the Internet (a configuration that is still surprisingly common). Using NAT breaks this unhindered connectivity, relegating hosts to second-class status, unable to receive inbound connections. This protocol goes some way to partially reverse that damage. The purpose of a NAT gateway should be to allow several hosts to share a single address, not to simultaneously impede those host's ability to communicate freely. Security is most properly provided by end-to-end cryptographic security, and/or by explicit firewall functionality, as appropriate. Blocking of certain connections should occur only as a result of explicit and intentional firewall policy, not as an accidental side effect of some other technology.
有些人将NAT阻止入站连接的特性视为该协议破坏的安全优势。本文件的作者有不同的观点。在NAT流行之前的日子里，所有主机都有唯一的公共IP地址，并且能够不受阻碍地与Internet上的任何其他主机通信（这种配置仍然非常常见）。使用NAT会破坏这种不受阻碍的连接，使主机处于二级状态，无法接收入站连接。该协议在某种程度上可以部分扭转这种损害。NAT网关的目的应该是允许多个主机共享一个地址，而不是同时妨碍这些主机自由通信的能力。端到端加密安全性和/或明确的防火墙功能（视情况而定）最适合提供安全性。某些连接的阻塞只应作为明确和有意的防火墙策略的结果而发生，而不是作为某些其他技术的意外副作用。
However, since many users do have an expectation that their NAT gateways can function as a kind of firewall, any NAT gateway implementing this protocol SHOULD have an administrative mechanism to disable it, thereby restoring the pre-NAT-PMP behavior.
然而，由于许多用户确实期望他们的NAT网关可以作为一种防火墙，因此任何实现此协议的NAT网关都应该具有一种管理机制来禁用它，从而恢复NAT前的PMP行为。
UDP ports 5350 and 5351 have been assigned for use by NAT-PMP, and subsequently by its successor, Port Control Protocol [RFC6887].
UDP端口5350和5351已分配给NAT-PMP使用，随后由其后续端口控制协议[RFC6887]使用。
No further IANA services are required by this document.
本文件不需要进一步的IANA服务。
The concepts described in this document have been explored, developed, and implemented with help from Mark Baugher, Bob Bradley, Josh Graessley, Rory McGuire, Rob Newberry, Roger Pantos, John Saxton, Kiren Sekar, Jessica Vazquez, and James Woodyatt.
在马克·鲍格尔、鲍勃·布拉德利、乔什·格雷斯利、罗里·麦奎尔、罗伯·纽贝里、罗杰·潘托斯、约翰·萨克斯顿、基伦·塞卡尔、杰西卡·巴斯克斯和詹姆斯·伍迪亚特的帮助下，对本文件中描述的概念进行了探索、开发和实施。
Special credit goes to Mike Bell, the Apple Vice President who recognized the need for a clean, elegant, reliable Port Mapping Protocol, and made the decision early on that Apple's AirPort base stations would support NAT-PMP.
特别要归功于苹果公司副总裁迈克·贝尔，他认识到需要一个干净、优雅、可靠的端口映射协议，并很早就决定苹果公司的机场基站将支持NAT-PMP。
In August 2004, NAT-PMP client software first became available to the public through Apple's Darwin Open Source code. In April 2005, NAT-PMP implementations began shipping to end users with the launch of Mac OS X 10.4 Tiger and Bonjour for Windows 1.0, and in June 2005 the protocol was first publicly documented in the original draft version of this document.
2004年8月，NAT-PMP客户端软件首次通过苹果公司的达尔文开源代码向公众开放。2005年4月，随着Mac OS X 10.4 Tiger和Bonjour for Windows 1.0的发布，NAT-PMP实施开始向最终用户提供，2005年6月，该协议首次公开记录在本文档的原始草稿版本中。
The NAT-PMP client in Mac OS X 10.4 Tiger and Bonjour for Windows exists as part of the mDNSResponder/mdnsd system service. When a client advertises a service using Wide Area Bonjour [RFC6763], and the machine is behind a NAT-PMP-capable NAT gateway, and the machine is so configured, the mDNSResponder system service automatically uses NAT-PMP to set up an inbound port mapping, and then records the external IPv4 address and port in the global DNS. Existing client software using the Bonjour programming APIs [Bonjour] got this new NAT traversal functionality automatically. The logic behind this decision was that if client software publishes its information into the global DNS via Wide Area Bonjour service advertising, then it's reasonable to infer an expectation that this information should actually be usable by the peers retrieving it. Generally speaking, recording a private IPv4 address like 10.0.0.2 in the public DNS is likely to be pointless because that address is not reachable from clients on the other side of the NAT gateway. In the case of a home user with a single computer directly connected to their Cable or DSL modem, with a single global IPv4 address and no NAT gateway (a common configuration at that time), publishing the machine's global IPv4 address into the global DNS is useful, because that IPv4 address is globally reachable. In contrast, a home user using a NAT gateway to share a single global IPv4 address between several computers loses this ability to receive inbound connections. This breaks many peer-to-peer collaborative applications, like the multi-user text editor SubEthaEdit [SEE]. For many users, moving from one computer with a global IPv4 address, to two computers using NAT to share a single global IPv4 address, loss of inbound reachability was an unwanted side effect of using NAT for address sharing. Automatically creating the necessary inbound port mappings helped remedy this unwanted side effect of NAT.
Mac OS X 10.4 Tiger and Bonjour for Windows中的NAT-PMP客户端作为mDNSResponder/mdnsd系统服务的一部分存在。当客户端使用广域Bonjour[RFC6763]播发服务时，并且机器位于支持NAT PMP的NAT网关后面，并且机器是这样配置的，mDNSResponder系统服务会自动使用NAT-PMP设置入站端口映射，然后在全局DNS中记录外部IPv4地址和端口。使用Bonjour编程API的现有客户端软件[Bonjour]自动获得了这种新的NAT遍历功能。这一决定背后的逻辑是，如果客户端软件通过广域Bonjour服务广告将其信息发布到全局DNS中，那么可以合理地推断出这样一种期望，即检索该信息的对等方实际上应该可以使用该信息。一般来说，在公共DNS中记录私有IPv4地址（如10.0.0.2）可能毫无意义，因为NAT网关另一端的客户端无法访问该地址。如果家庭用户的一台计算机直接连接到其电缆或DSL调制解调器，并且只有一个全局IPv4地址而没有NAT网关（当时是一种常见的配置），则将机器的全局IPv4地址发布到全局DNS中是有用的，因为该IPv4地址是全局可访问的。相反，使用NAT网关在多台计算机之间共享单个全局IPv4地址的家庭用户将失去接收入站连接的能力。这打破了许多点对点协作应用程序，如多用户文本编辑器SubEthaEdit[参见]。对于许多用户来说，从一台具有全局IPv4地址的计算机移动到两台使用NAT共享单个全局IPv4地址的计算机，入站可达性的丧失是使用NAT进行地址共享的一个不必要的副作用。自动创建必要的入站端口映射有助于纠正NAT的这种不必要的副作用。
The server side of the NAT-PMP protocol is implemented in Apple's AirPort Extreme, AirPort Express, and Time Capsule wireless base stations, and in the Internet Sharing feature of Mac OS X 10.4 and later. Some third-party NAT vendors, such as Peplink, also offer NAT-PMP in their products.
NAT-PMP协议的服务器端在苹果的AirPort Extreme、AirPort Express和Time Capsule无线基站以及Mac OS X 10.4及更高版本的互联网共享功能中实现。一些第三方NAT供应商，如Peplink，也在其产品中提供NAT-PMP。
In Mac OS X 10.4 Tiger, the NAT-PMP client was invoked automatically as a side effect of clients requesting Wide Area Bonjour service registrations. Using NAT-PMP without an associated Wide Area Bonjour service registration required use of a third-party client library.
在Mac OS X 10.4 Tiger中，NAT-PMP客户端被自动调用，作为客户端请求广域Bonjour服务注册的副作用。使用NAT-PMP而不进行相关的广域Bonjour服务注册需要使用第三方客户端库。
In October 2007, Mac OS X 10.5 Leopard added the "DNSServiceNATPort-MappingCreate" API, which made NAT-PMP client functionality directly available, so software could use it with other directory and rendezvous mechanisms in addition to Wide Area Bonjour DNS Updates.
2007年10月，Mac OS X 10.5 Leopard添加了“DNSServiceNATPort MappingCreate”API，使NAT-PMP客户端功能直接可用，因此除了广域Bonjour DNS更新之外，软件还可以将其与其他目录和会合机制一起使用。
In 2013, NAT-PMP was superseded by the IETF Standards Track Port Control Protocol [RFC6887]. PCP builds on NAT-PMP and uses a compatible packet format, and adds a number of significant enhancements, including IPv6 support, management of outbound mappings, management of firewall rules, full compatibility with large-scale NATs with a pool of external addresses, error lifetimes, and an extension mechanism to enable future enhancements.
2013年，NAT-PMP被IETF标准跟踪端口控制协议[RFC6887]取代。PCP建立在NAT-PMP的基础上，使用兼容的数据包格式，并添加了许多重要的增强功能，包括IPv6支持、出站映射管理、防火墙规则管理、与具有外部地址池的大规模NAT的完全兼容、错误生存期，以及支持未来增强功能的扩展机制。
Some readers have asked how NAT-PMP and PCP compare to other similar solutions, particularly the UPnP Forum's Internet Gateway Device (IGD) Device Control Protocol [IGD].
一些读者询问NAT-PMP和PCP与其他类似解决方案相比如何，特别是UPnP论坛的互联网网关设备（IGD）设备控制协议[IGD]。
The answer is that although the Universal Plug and Play (UPnP) IGD protocol is often used as a way for client devices to create port mappings programmatically, it's not ideal for that task. Whereas NAT-PMP was explicitly designed to be used primarily by software entities managing their own port mappings, UPnP IGD is more tailored towards being used by humans configuring all the settings of their gateway using some GUI tool. This difference in emphasis leads to protocol differences. For example, while it is reasonable and sensible to require software entities to renew their mappings periodically to prove that they are still there (like a device renewing its DHCP address lease), it would be unreasonable to require the same thing of a human user. When a human user configures their gateway, they expect it to stay configured that way until they decide to change it. If they configure a port mapping, they expect it to stay configured until they decide to delete it.
答案是，尽管通用即插即用（UPnP）IGD协议经常被用作客户端设备以编程方式创建端口映射的一种方式，但它并不适合该任务。NAT-PMP被明确设计为主要由管理其自身端口映射的软件实体使用，而UPnP IGD则更适合由使用某种GUI工具配置其网关的所有设置的人员使用。这种强调的不同导致协议的不同。例如，虽然要求软件实体定期更新其映射以证明它们仍然存在（如设备更新其DHCP地址租约）是合理和明智的，但要求人类用户执行相同的操作是不合理的。当人类用户配置他们的网关时，他们希望它一直以这种方式配置，直到他们决定更改它为止。如果他们配置了端口映射，他们希望它保持配置状态，直到他们决定删除它。
Because of this focus on being a general administration protocol for all aspects of home gateway configuration, UPnP IGD is a large and complicated collection of protocols (360 pages of specification spread over 13 separate documents, not counting supporting protocol specifications like Simple Service Discovery Protocol (SSDP) and Extensible Markup Language (XML)). While it may be a fine way for
由于UPnP IGD是家庭网关配置所有方面的通用管理协议，因此UPnP IGD是一个庞大而复杂的协议集合（360页的规范分布在13个单独的文档中，不包括支持协议规范，如简单服务发现协议（SSDP）和可扩展标记语言（XML））。虽然这可能是一个很好的方法
human users to configure their home gateways, it is not especially suited to the task of programmatically creating dynamic port mappings.
为了让人类用户配置他们的家庭网关，它并不特别适合以编程方式创建动态端口映射的任务。
The requirements for a good port mapping protocol, requirements that are met by NAT-PMP, are outlined below.
下面概述了NAT-PMP满足的良好端口映射协议的要求。
Many home gateways, and many of the devices that connect to them, are small, low-cost devices, with limited RAM, flash memory, and CPU resources. Protocols they use should be considerate of this, supporting a small number of simple operations that can be implemented easily with a small amount of code. A quick comparison, based on page count of the respective documents alone, suggests that NAT-PMP is at least ten times simpler than UPnP IGD.
许多家庭网关以及连接它们的许多设备都是小型、低成本的设备，RAM、闪存和CPU资源有限。他们使用的协议应该考虑到这一点，支持少量的简单操作，这些操作可以用少量代码轻松实现。仅基于各文档的页数，快速比较表明NAT-PMP比UPnP IGD至少简单十倍。
The more things a protocol can do, the more chance there is that something it does could be exploited for malicious purposes. NAT-PMP is tightly focused on the specific task of creating port mappings. Were the protocol to be misused in some way, this helps limit the scope of what mischief could be performed using the protocol.
协议可以做的事情越多，它所做的事情就越有可能被恶意利用。NAT-PMP密切关注创建端口映射的特定任务。如果协议以某种方式被误用，这有助于限制使用该协议可能造成的危害的范围。
Because UPnP IGD allows control over all home gateway configuration settings, the potential for mischief is far greater. For example, a UPnP IGD home gateway allows messages that tell it to change the DNS server addresses that it sends to clients in its DHCP packets. Using this mechanism, a single item of malicious web content (e.g., a rogue Flash banner advert on a web page) can make a persistent change to the home gateway's configuration without the user's knowledge, such that all future DNS requests by all local clients will be sent to a rogue DNS server. This allows criminals to perform a variety of mischief, such as hijacking connections to bank web sites and redirecting them to the criminals' web servers instead [VU347812].
由于UPnP IGD允许对所有家庭网关配置设置进行控制，因此造成危害的可能性要大得多。例如，UPnP IGD家庭网关允许消息通知它更改DHCP数据包中发送给客户端的DNS服务器地址。使用此机制，单个恶意web内容项目（例如，网页上的恶意Flash横幅广告）可以在用户不知情的情况下对家庭网关的配置进行持续更改，以便所有本地客户端将来的所有DNS请求都将发送到恶意DNS服务器。这允许犯罪分子进行各种恶作剧，例如劫持银行网站的连接并将其重定向到犯罪分子的web服务器[VU347812]。
In addition to low-cost home gateways, many of the clients will also be similarly constrained low-cost devices with limited RAM resources.
除了低成本的家庭网关之外，许多客户机还将受到类似的限制，即RAM资源有限的低成本设备。
When implementing a NAT-PMP client on a constrained device, it's beneficial to have well-defined bounds on RAM requirements that are fixed and known in advance. For example, when requesting the gateway's external IPv4 address, a NAT-PMP client on Ethernet knows
当在受约束的设备上实现NAT-PMP客户机时，在RAM需求上有明确的界限是有益的，这些界限是固定的，并且是预先知道的。例如，当请求网关的外部IPv4地址时，以太网上的NAT-PMP客户端知道
that to receive the reply it will require 14 bytes for the Ethernet header, 20 bytes for the IPv4 header, 8 bytes for the UDP header, and 12 bytes for the NAT-PMP payload, making a total of 54 bytes.
要接收回复，以太网报头需要14个字节，IPv4报头需要20个字节，UDP报头需要8个字节，NAT-PMP有效负载需要12个字节，总共需要54个字节。
In contrast, UPnP IGD uses an XML reply of unbounded size. It is not uncommon for a UPnP IGD device to return an XML document 4000 to 8000 bytes in size to communicate its 4-byte external IPv4 address, and the protocol specification places no upper bound on how large the XML response may be, so there's nothing to stop the reply being even larger. This means that developers of UPnP client devices can only guess at how much memory they may need to receive the XML reply. Operational experience suggests that 10,000 bytes is usually enough for most UPnP IGD home gateways today, but that's no guarantee that some future UPnP IGD home gateway might not return a perfectly legal XML reply much larger than that.
相反，UPnP IGD使用大小不受限制的XML回复。UPnP IGD设备返回大小为4000到8000字节的XML文档来传输其4字节外部IPv4地址的情况并不少见，协议规范对XML响应的大小没有上限，因此没有什么可以阻止响应变得更大。这意味着UPnP客户端设备的开发人员只能猜测接收XML应答可能需要多少内存。运营经验表明，目前大多数UPnP IGD家庭网关的10000字节通常就足够了，但这并不能保证未来的一些UPnP IGD家庭网关可能不会返回比这大得多的完全合法的XML回复。
In addition, because the XML reply is too large to fit in a single UDP packet, UPnP IGD has to use a TCP connection, thereby adding the overhead of TCP connection setup and teardown.
此外，由于XML应答太大，无法容纳单个UDP数据包，UPnP IGD必须使用TCP连接，从而增加TCP连接设置和拆卸的开销。
The process of discovering a UPnP IGD home gateway's external IPv4 address consists of:
发现UPnP IGD家庭网关的外部IPv4地址的过程包括：
o SSDP transaction to discover the TCP port to use, and the "URL" of the XML document to fetch from the gateway. Following the SSDP specification, this is 3 multicast requests, eliciting 9 unicast responses.
o SSDP事务以发现要使用的TCP端口，以及要从网关获取的XML文档的“URL”。按照SSDP规范，这是3个多播请求，引发9个单播响应。
o HTTP "GET" request to get the device description. Typically, 16 packets: 3 for TCP connection setup, 9 packets of data exchange, and a 4-packet FIN-ACK-FIN-ACK sequence to close the connection.
o 获取设备描述的HTTP“GET”请求。通常，16个数据包：3个用于TCP连接设置，9个数据包交换，4个数据包FIN-ACK-FIN-ACK序列用于关闭连接。
o HTTP "POST" to request the external IPv4 address. Typically, 14 packets: 3 for TCP connection setup, 7 packets of data exchange, and a 4-packet FIN-ACK-FIN-ACK sequence to close the connection.
o HTTP“POST”请求外部IPv4地址。通常，14个数据包：3个用于TCP连接设置，7个数据包交换，4个数据包FIN-ACK-FIN-ACK序列用于关闭连接。
To retrieve the external IPv4 address NAT-PMP takes a 2-packet UDP exchange (44-byte request, 54-byte response); the same thing using UPnP IGD takes 42 packets and thousands of bytes.
为了检索外部IPv4地址，NAT-PMP采用2包UDP交换（44字节请求，54字节响应）；使用UPnP IGD需要42个数据包和数千字节。
Similarly, UPnP IGD's HTTP "POST" request for a port mapping is typically a 14-packet exchange, compared with NAT-PMP's 2-packet UDP exchange.
类似地，与NAT-PMP的2包UDP交换相比，UPnP IGD的HTTP“POST”端口映射请求通常是14包交换。
Some of the useful properties of NAT-PMP were inspired by DHCP, a reliable and successful protocol. For example, DHCP allows a client to request a desired IP address, but if that address is already in use the DHCP server will instead assign some other available address.
NAT-PMP的一些有用特性受到DHCP的启发，DHCP是一种可靠且成功的协议。例如，DHCP允许客户端请求所需的IP地址，但如果该地址已在使用中，DHCP服务器将改为分配其他可用地址。
Correspondingly, NAT-PMP allows a client to request a desired external port, and if that external port is already in use by some other client, the NAT-PMP server will instead assign some other available external port.
相应地，NAT-PMP允许客户端请求所需的外部端口，如果该外部端口已被其他客户端使用，则NAT-PMP服务器将分配其他可用的外部端口。
UPnP IGD does not do this. If a UPnP IGD client requests an external port that has already been allocated, then one of two things happens.
UPnP IGD不这样做。如果UPnP IGD客户端请求已分配的外部端口，则会发生以下两种情况之一。
Some UPnP IGD home gateways just silently overwrite the old mapping with the new one, causing the previous client to lose connectivity. If the previous client renews its port mapping, then it in turn overwrites the new mapping, and the two clients fight over the same external port indefinitely, neither achieving reliable connectivity.
一些UPnP IGD家庭网关只是默默地用新的映射覆盖旧的映射，导致以前的客户端失去连接。如果前一个客户端更新其端口映射，那么它会反过来覆盖新的映射，并且两个客户端会无限期地争夺同一个外部端口，这两个客户端都无法实现可靠的连接。
Other IGD home gateways return a "Conflict" error if the port is already in use, which does at least tell the client what happened, but doesn't tell the client what to do. Instead of the NAT gateway (which does know which ports are available) assigning one to the client, the NAT gateway makes the client (which doesn't know) keep guessing until it gets lucky. This problem remains mild as long as not many clients are using UPnP IGD, but gets progressively worse as the number of clients on the network requesting port mappings goes up. In addition, UPnP IGD works particularly badly in conjunction with the emerging policy of allocating pre-assigned port ranges to each client. If a client is assigned TCP port range 63488-64511, and the UPnP IGD client requests TCP port 80, trying successive incrementing ports until it succeeds, then the UPnP IGD client will have to issue 63,409 requests before it succeeds.
如果端口已在使用，其他IGD主网关将返回“冲突”错误，这至少会告诉客户端发生了什么，但不会告诉客户端该做什么。与NAT网关（它知道哪些端口可用）将一个端口分配给客户机不同，NAT网关让客户机（它不知道）不断猜测，直到运气好为止。只要没有多少客户端使用UPnP IGD，这个问题就不会太严重，但随着网络上请求端口映射的客户端数量的增加，问题会越来越严重。此外，UPnP IGD在为每个客户机分配预先分配的端口范围这一新兴政策的配合下尤其糟糕。如果为客户端分配了TCP端口范围63488-64511，并且UPnP IGD客户端请求TCP端口80，尝试连续递增端口直到成功，则UPnP IGD客户端必须在成功之前发出63409个请求。
In any system that operates for a long period of time (as a home gateway should), it is important that garbage data does not accumulate indefinitely until the system runs out of memory and fails.
在任何长时间运行的系统中（家庭网关应该这样做），重要的是在系统内存耗尽并出现故障之前，垃圾数据不会无限期累积。
Similar to how DHCP leases an IP address to a client for a finite length of time, NAT-PMP leases an external port to a client for a finite length of time. The NAT-PMP client must renew the port mapping before it expires, or, like an unrenewed DHCP address, it will be reclaimed. If a laptop computer is abruptly disconnected
与DHCP在有限时间内将IP地址租给客户端的方式类似，NAT-PMP在有限时间内将外部端口租给客户端。NAT-PMP客户端必须在端口映射过期之前续订端口映射，或者，与未更新的DHCP地址一样，它将被回收。如果笔记本电脑突然断开连接
from the network without the opportunity to delete its port mappings, the NAT gateway will reclaim those mappings when they are not renewed.
在没有机会删除其端口映射的情况下，NAT网关将从网络中回收这些映射（当这些映射未续订时）。
In principle, UPnP IGD should allow clients to specify a lifetime on port mappings. However, a Google search for "UPnP NewLeaseDuration" shows that in practice pretty much every client uses "<NewLeaseDuration>0</NewLeaseDuration>" to request an infinite lease, and the protocol has no way for the NAT gateway to decline that infinite lease request and require the client to renew it at reasonable intervals. Furthermore, anecdotal evidence is that if the client requests a lease other than zero, there are IGD home gateways that will ignore the request, fail in other ways, or even crash completely. As a client implementer then, you would be well advised not to attempt to request a lease other than zero, unless you want to suffer the support costs and bad publicity of lots of people complaining that your device brought down their entire network.
原则上，UPnP IGD应该允许客户端指定端口映射的生存期。然而，谷歌搜索“UPnP NewLeaseDuration”表明，实际上几乎每个客户端都使用“<NewLeaseDuration>0</NewLeaseDuration>”来请求无限租约，协议无法让NAT网关拒绝无限租约请求并要求客户端在合理的时间间隔内续订。此外，传闻证据表明，如果客户请求的租赁不是零，则IGD家庭网关将忽略该请求，以其他方式失败，甚至完全崩溃。作为一个客户机实现者，最好不要尝试请求零以外的租赁，除非你想承受很多人抱怨你的设备导致他们整个网络瘫痪的支持成本和负面宣传。
Because none of the early UPnP IGD clients requested port mapping leases, many UPnP IGD home gateway vendors never tested that functionality, and got away with shipping home gateways where that functionality was buggy or nonexistent. Because there are so many buggy UPnP IGD home gateways already deployed, client writers wisely stick to the well-trodden path of only requesting infinite leases. Because there are now few (if any) clients attempting to request non-zero leases, home gateway vendors have little incentive to expend resources implementing a feature no one uses.
因为早期的UPnP IGD客户机都没有请求端口映射租赁，所以许多UPnP IGD家庭网关供应商从未测试过该功能，并且在家庭网关出现故障或不存在该功能的情况下，可以顺利交付。因为已经部署了太多有缺陷的UPnP IGD家庭网关，所以客户端编写人员明智地坚持只请求无限租赁的老路。因为现在几乎没有（如果有的话）客户试图请求非零租赁，家庭网关供应商没有动力花费资源来实现无人使用的功能。
This unfortunate consequence of the way UPnP IGD was developed and deployed means that in practice it has no usable port mapping lease facility today, and therefore when run for a long period of time UPnP IGD home gateways have no good way to avoid accumulating an unbounded number of stale port mappings.
UPnP IGD的开发和部署方式带来的这一不幸后果意味着，实际上，它目前没有可用的端口映射租赁设施，因此，当UPnP IGD家庭网关长时间运行时，无法很好地避免累积无限数量的过时端口映射。
When using DHCP on the external interface, as is the norm for home gateways, there is no guarantee that a UPnP IGD home gateway's external IPv4 address will remain unchanged. Indeed, some ISPs change their customer's IPv4 address every 24 hours (possibly in an effort to make it harder for their customers to "run a server" at home). What this means is that if the home gateway's external IPv4 address changes, it needs to inform its clients, so that they can make any necessary updates to global directory information (e.g., performing a Dynamic DNS update to update their address record).
当在外部接口上使用DHCP时，就像家庭网关的规范一样，无法保证UPnP IGD家庭网关的外部IPv4地址保持不变。事实上，一些ISP每24小时更改一次客户的IPv4地址（可能是为了让客户更难在家“运行服务器”）。这意味着，如果家庭网关的外部IPv4地址发生更改，它需要通知其客户端，以便客户端可以对全局目录信息进行任何必要的更新（例如，执行动态DNS更新以更新其地址记录）。
When a NAT-PMP gateway's external IPv4 address changes, it broadcasts announcement packets to inform clients of this. UPnP IGD does not.
当NAT-PMP网关的外部IPv4地址发生更改时，它会广播公告数据包以通知客户端这一情况。UPnP IGD不支持。
When run for a long enough period of time, any network will have devices that fail, get rebooted, suffer power outages, or lose state for other reasons. A home gateway that runs for long enough is likely to suffer some such incident eventually. After losing state, it has no record of the port mappings it created, and clients suffer a consequent loss of connectivity.
如果运行足够长的时间，任何网络都会出现设备故障、重新启动、断电或因其他原因失去状态。一个运行足够长时间的家庭网关最终可能会遭遇这样的事件。在失去状态后，它没有创建端口映射的记录，客户端会因此失去连接。
To handle this case, NAT-PMP has the "Seconds Since Start of Epoch" mechanism. After a reboot or other loss of state, a NAT-PMP gateway broadcasts announcement packets giving its external IPv4 address, with the Seconds Since Start of Epoch field reset to begin counting from zero again. When a NAT-PMP client observes packets from its NAT-PMP gateway where the gateway's notion of time has apparently gone backwards compared to the client's, the client knows the gateway has probably lost state, and immediately recreates its mappings to restore connectivity.
为了处理这种情况，NAT-PMP具有“从历元开始的秒数”机制。在重新启动或其他状态丢失后，NAT-PMP网关广播给出其外部IPv4地址的公告数据包，从Epoch开始的秒字段重置开始再次从零开始计数。当NAT-PMP客户端观察来自其NAT-PMP网关的数据包时，该网关的时间概念明显比客户端的时间概念倒退，客户端知道网关可能已失去状态，并立即重新创建其映射以恢复连接。
UPnP IGD has no equivalent mechanism.
UPnP IGD没有等效的机制。
For any given host, it is only useful to request NAT port mappings in the NAT gateway through which that host's packets are flowing. A NAT port mapping is a request for packets to be translated in a certain way; the NAT gateway can only perform that translation if it's actually forwarding inbound and outbound packets for that host.
对于任何给定的主机，只有在该主机的数据包流经的NAT网关中请求NAT端口映射才有用。NAT端口映射是以某种方式转换数据包的请求；NAT网关只有在实际为该主机转发入站和出站数据包时才能执行该转换。
This is why NAT-PMP sends its requests to the host's default router, since this is the device that is forwarding (and possibly translating) inbound and outbound packets for that host. (In a larger network with multiple hops between a host and its NAT gateway, some other mechanism would need to be used to discover the correct on-path NAT for a host; this is possible, but outside the scope of this document.)
这就是NAT-PMP将其请求发送到主机的默认路由器的原因，因为这是为该主机转发（并可能转换）入站和出站数据包的设备。（在主机与其NAT网关之间具有多跳的大型网络中，需要使用其他一些机制来发现主机的正确NAT路径；这是可能的，但不在本文档的范围内。）
In contrast, UPnP IGD does not limit itself to using only on-path NATs. UPnP IGD uses a multicast SSDP query, and uses any device it finds on the local network claiming UPnP IGD capability, regardless of whether any inbound or outbound traffic is actually flowing through that device. Over the past few years this led to many bug reports being sent to Apple with the general form: "Port Mapping doesn't work on my Mac and that's a bug because everything else on my network says UPnP IGD is working fine." Upon investigation it always turned out that: (i) these people had NAT gateways that either didn't support port mapping requests, or had that capability disabled, and (ii) for some reason they also had some other old NAT device still
相比之下，UPnP IGD并不局限于仅使用路径NAT。UPnP IGD使用多播SSDP查询，并使用其在本地网络上找到的声称具有UPnP IGD功能的任何设备，而不管任何入站或出站流量是否实际流经该设备。在过去几年中，这导致许多错误报告以一般形式发送给苹果：“端口映射在我的Mac上不起作用，这是一个错误，因为我的网络上的其他一切都表明UPnP IGD工作正常。”经调查，结果总是证明：（i）这些人的NAT网关要么不支持端口映射请求，或者禁用了该功能，以及（ii）出于某种原因，他们还有其他一些旧的NAT设备
connected to their network, and those other NAT devices were advertising UPnP IGD capability, even though they were not the active NAT gateway for the network. This led to UPnP IGD clients falsely reporting that they were "working fine", and only the Mac correctly reporting that it was unable to make any useful port mappings. In many cases the people reporting this "bug" had devices like game consoles on their home network that for many years had been reporting that UPnP IGD was "working fine", yet during those years they had never once successfully received any inbound network packet or connection. The irony is that, for these people who were reporting bugs to Apple, UPnP IGD "working fine" had been indistinguishable from UPnP IGD doing nothing useful at all. It was only when Back to My Mac [RFC6281] started reporting that it was unable to make any functional port mappings that these people discovered they'd never had any working port mappings on their NAT gateway.
连接到他们的网络，并且那些其他NAT设备正在宣传UPnP IGD功能，即使它们不是网络的活动NAT网关。这导致UPnP IGD客户端错误地报告它们“工作正常”，只有Mac正确地报告它无法进行任何有用的端口映射。在许多情况下，报告这一“漏洞”的人的家庭网络上有类似游戏机的设备，多年来一直报告UPnP IGD“工作正常”，但在这些年中，他们从未成功接收过任何入站网络数据包或连接。具有讽刺意味的是，对于那些向苹果报告bug的人来说，UPnP IGD“工作正常”与UPnP IGD根本没有做任何有用的事情是无法区分的。直到回到我的Mac[RFC6281]开始报告它无法进行任何功能端口映射时，这些人才发现他们的NAT网关上从来没有任何工作端口映射。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[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月。
[Bonjour] Apple "Bonjour" <http://developer.apple.com/bonjour/>.
[你好]苹果“你好”<http://developer.apple.com/bonjour/>.
[ETEAISD] J. Saltzer, D. Reed and D. Clark: "End-to-end arguments in system design", ACM Trans. Comp. Sys., 2(4):277-88, November 1984.
[ETEAISD]J.Saltzer，D.Reed和D.Clark：“系统设计中的端到端参数”，ACM Trans。公司。《系统》，第2（4）：277-881984年11月。
[IGD] UPnP Standards "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0", November 2001, <http://www.upnp.org/standardizeddcps/igd.asp>.
[IGD]UPnP标准“互联网网关设备（IGD）标准化设备控制协议V 1.0”，2001年11月<http://www.upnp.org/standardizeddcps/igd.asp>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC3424] Daigle, L., Ed., and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424]Daigle，L.，Ed.，和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, June 2011.
[RFC6281]Cheshire，S.，Zhu，Z.，Wakikawa，R.，和L.Zhang，“理解苹果的回到我的Mac（BTMM）服务”，RFC 62812011年6月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 67632013年2月。
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[RFC6887]Wing，D.，Ed.，Cheshire，S.，Boucadair，M.，Penno，R.，和P.Selkirk，“港口控制协议（PCP）”，RFC 6887，2013年4月。
[SEE] SubEthaEdit, <http://www.codingmonkeys.de/subethaedit/>.
[见]SubEthaEdit<http://www.codingmonkeys.de/subethaedit/>.
[VU347812] United States Computer Emergency Readiness Team Vulnerability Note VU#347812, <http://www.kb.cert.org/vuls/id/347812>.
[VU347812]美国计算机应急准备小组漏洞说明VU#347812<http://www.kb.cert.org/vuls/id/347812>.
Authors' Addresses
作者地址
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
斯图尔特柴郡苹果公司，美国加利福尼亚州库比蒂诺市无限环路1号，邮编95014
EMail: cheshire@apple.com
EMail: cheshire@apple.com
Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Marc Krocmal Apple Inc.美国加利福尼亚州库珀蒂诺市无限环路1号，邮编95014
EMail: marc@apple.com
EMail: marc@apple.com