Network Working Group L. Daigle, Ed.
Request for Comments: 3424 Internet Architecture Board
Category: Informational IAB
November 2002
Network Working Group L. Daigle, Ed.
Request for Comments: 3424 Internet Architecture Board
Category: Informational IAB
November 2002
IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation
跨网络地址转换单边自地址固定（UNSAF）的IAB注意事项
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
As a result of the nature of Network Address Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-Address Fixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections.
由于网络地址转换（NAT）中间件的性质，由一个或多个NAT分隔的通信端点不知道如何使用在其（当前和未来）对等方的寻址域中有效的地址来引用自己。对“单方面自行确定地址”（UNSAF）进程提出了各种建议。这些是一些始发端点尝试确定或修复另一个端点已知的地址（和端口）的过程，例如，能够在协议交换中使用地址数据，或播发将从中接收连接的公共地址。
This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal.
本文件概述了将这些提案充其量视为对具体问题的短期解决办法的理由，以及在制定UNSAF提案之前应仔细评估的具体问题。
As a result of the nature of Network Address (and port) Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers - the address translation is locked within the NAT box. For some purposes, endpoints need to know the addresses (and/or ports) by which they are known to their peers. There are two cases: 1) when the client initiates communication, starting the communication has the side effect of creating an address binding in the NAT device and
由于网络地址（和端口）转换（NAT）中间盒的性质，由一个或多个NAT分隔的通信端点不知道如何使用在其（当前和未来）对等方的寻址域中有效的地址来引用自己-地址转换被锁定在NAT盒内。出于某些目的，端点需要知道其对等方已知的地址（和/或端口）。有两种情况：1）当客户端启动通信时，启动通信会产生在NAT设备中创建地址绑定的副作用，以及
allocating an address in the realm that is external to the NAT box; and 2) a server will be accepting connections from outside, but because it does not initiate communication, no NAT binding is created. In such cases, a mechanism is needed to fix such a binding before communication can take place.
在NAT框外部的域中分配地址；2）服务器将接受来自外部的连接，但由于它不启动通信，因此不会创建NAT绑定。在这种情况下，需要一种机制来修复这种绑定，然后才能进行通信。
"UNilateral Self-Address Fixing (UNSAF)" is a process whereby some originating process attempts to determine or fix the address (and port) by which it is known - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections.
“单边自定址（UNSAF）”是一个过程，其中一些发起进程试图确定或固定已知地址（和端口）-例如，能够在协议交换中使用地址数据，或播发将接收连接的公共地址。
There are only heuristics and workarounds to attempt to achieve this effect; there is no 100% solution. Since NATs may also dynamically reclaim or readjust translations, "keep-alive" and periodic re-polling may be required. Use of these workarounds MUST be considered transitional in IETF protocols, and a better architectural solution is being sought. The explicit intention is to deprecate any such workarounds when sound technical approaches are available.
只有试探法和变通办法才能达到这种效果；没有100%的解决方案。由于NAT还可以动态回收或重新调整翻译，因此可能需要“保持活动”和定期重新轮询。在IETF协议中，必须考虑使用这些变通方法，并且正在寻求更好的体系结构解决方案。明确的意图是，当有可靠的技术方法可用时，反对任何此类解决方案。
Generally speaking, the proposed workarounds are for cases where a standard protocol communication is to take place between two endpoints, but in order for this to occur, a separate step of determining (or fixing) the perceived address of an endpoint in the other endpoint's addressing realm is required. Proposals require that an endpoint seeking to "fix" its address contact a participating service (in a different address realm) to determine (reflect) its address. Thus, there is an "UNSAF client" partnering with some form of "UNSAF service" that may or may not be associated with the target endpoint of the actual desired communication session. Throughout this memo, the terms "UNSAF server" and "UNSAF service" should be understood to generically refer to whatever process is participating in the UNSAF address determination for the originating process (the UNSAF client).
一般来说，建议的解决方法适用于两个端点之间进行标准协议通信的情况，但为了实现这一点，需要在另一个端点的寻址域中确定（或固定）端点的感知地址的单独步骤。提案要求寻求“修复”其地址的端点联系参与服务（在不同的地址域中）以确定（反映）其地址。因此，存在与某种形式的“UNSAF服务”合作的“UNSAF客户端”，该“UNSAF服务”可能与实际所需通信会话的目标端点相关联，也可能与实际所需通信会话的目标端点无关。在本备忘录中，“UNSAF服务器”和“UNSAF服务”这两个术语通常指的是参与发起进程（UNSAF客户端）的UNSAF地址确定的任何进程。
Any users of these workarounds should be aware that specific technical issues that impede the creation of a general solution include:
这些变通方法的任何用户都应该知道，阻碍创建通用解决方案的具体技术问题包括：
o there *is* no unique "outside" to a NAT - it may be impossible to tell where the target endpoint is with respect to the initiator; how does an UNSAF client find an appropriate UNSAF server to reflect its address? (See Appendix C).
o NAT没有唯一的“外部”——可能无法判断目标端点相对于启动器的位置；UNSAF客户端如何找到适当的UNSAF服务器以反映其地址？（见附录C）。
o specifically because it is impossible to tell where address realms are bounded ("inside" or "outside", "private" or "public", or several "private" realms routing traffic), an address can only be determined relative to one specific point in the network. If the UNSAF service that reflected an UNSAF client's address is in a different NAT-masqueraded subnet from some other service X that the client wishes to use, there is _no_ guarantee that the client's "perceived" address from the UNSAF partner would be the same as the address viewed from the perspective of X. (See Appendix C).
o 具体地说，因为不可能知道地址域的边界（“内部”或“外部”、“私有”或“公共”或几个“私有”域路由流量），所以只能相对于网络中的一个特定点确定地址。如果反映UNSAF客户地址的UNSAF服务与客户希望使用的其他服务X位于不同的NAT伪装子网中，则无法保证UNSAF合作伙伴提供的客户“感知”地址与从X角度查看的地址相同（见附录C）。
o absent "middlebox communication (midcom)", there is no usable way to let incoming communications make their way through a middlebox (NAT, firewall) under proper supervision. By circumventing the NAT, UNSAF mechanisms may also (inadvertently) circumvent security mechanisms. The particular danger is that internal machines are unwittingly exposed to all the malicious communications from the external side that the firewall is intended to block. This is particularly unacceptable if the UNSAF process is running on one machine which is acting on behalf of several.
o 如果没有“中间箱通信（midcom）”，就没有可用的方法让传入的通信在适当的监督下通过中间箱（NAT、防火墙）。通过绕过NAT，UNSAF机制也可能（无意中）绕过安全机制。特别危险的是，内部机器无意中暴露在防火墙打算阻止的所有外部恶意通信中。如果UNSAF进程运行在一台代表多台机器的机器上，这一点尤其不可接受。
o proposed workarounds include the use of "ping"-like address discovery requests sent from the UNSAF client (initiator) to the UNSAF server (listener), to which the listener responds with the transport address of the initiator - in the address realm of the listener. However, with connection-less transports, e.g. UDP, IPsec ESP, etc., an UNSAF process must take care to react to changes in NAT bindings for a given application flow, since it may change unpredictably.
o 建议的解决方法包括在侦听器的地址域中使用从UNSAF客户端（启动器）发送到UNSAF服务器（侦听器）的类似“ping”的地址发现请求，侦听器使用启动器的传输地址对其进行响应。但是，对于无连接传输，例如UDP、IPsec ESP等，UNSAF进程必须注意对给定应用程序流的NAT绑定的更改作出反应，因为它可能会发生不可预测的更改。
o if the UNSAF client uses periodic retries to refresh/reevaluate the address translation state, both the UNSAF client and the UNSAF server are required to maintain information about the presumed state of the communication in order to manage the address illusion.
o 如果UNSAF客户端使用定期重试刷新/重新评估地址转换状态，则UNSAF客户端和UNSAF服务器都需要维护有关假定通信状态的信息，以便管理地址转换。
o since the UNSAF server is not integrated with the middlebox, it can only operate on the assumption that past behavior is a predictor of future behavior. It has no special knowledge of the address translation heuristic or affecting factors.
o 由于UNSAF服务器未与中间盒集成，因此它只能在假设过去的行为是未来行为的预测因素的情况下运行。它没有地址转换启发或影响因素的专门知识。
o the communication exchange is made more "brittle" by the introduction of other servers (UNSAF servers) that need to be reachable in order for the communication to succeed - more boxes that are "fate sharing" in the communication.
o 通过引入其他服务器（UNSAF服务器），通信交换变得更加“脆弱”，为了通信成功，需要访问这些服务器——更多在通信中“命运共享”的盒子。
Workarounds may mitigate some of these problems through tight scoping of applicability and specific fixes. For example:
解决方法可以通过严格的适用性范围和特定修复来缓解其中一些问题。例如：
o rather than finding the address from "the" outside of the NAT, the applicability of the approach may be limited to finding the "self-address" from a specific service, for use exclusively with that service.
o 该方法的适用性可能仅限于从特定服务中查找专用于该服务的“自地址”，而不是从NAT外部的“自地址”中查找地址。
o limiting the scope to outbound requests for service (or service initiation) in order to prevent unacceptable security exposures.
o 将范围限制为服务（或服务启动）的出站请求，以防止不可接受的安全暴露。
From observations of deployed networks, it is clear that different NAT box implementations vary widely in terms of how they handle different traffic and addressing cases.
通过对已部署网络的观察，很明显，不同的NAT盒实现在处理不同流量和寻址情况方面存在很大差异。
Some of the specific types of observed behaviors have included:
观察到的某些特定行为类型包括：
o NATs may drop fragments in either direction: without complete TCP/UDP headers, the NAT may not make the address translation mapping, simply dropping the packet.
o NAT可以向任意方向丢弃片段：如果没有完整的TCP/UDP报头，NAT可能不会进行地址转换映射，而只是丢弃数据包。
o Shipping NATs often contain Application Layer Gateways (ALGs) which attempt to be context-sensitive, depending on the source or destination port number. The behavior of the ALGs can be hard to anticipate and these behaviors have not always been documented.
o 装运NAT通常包含应用层网关（ALG），这些网关试图区分上下文，具体取决于源或目标端口号。ALG的行为可能很难预测，并且这些行为并不总是被记录在案。
o Most NAT implementations with ALGs that attempt to translate TCP application protocols do not perform their functions correctly when the substrings they must translate span across multiple TCP segments; some of them are also known to fail on flows that use TCP option headers, e.g. timestamps.
o 当必须转换的子串跨越多个TCP段时，大多数使用ALG的NAT实现（尝试转换TCP应用程序协议）无法正确执行其功能；其中一些在使用TCP选项头（例如时间戳）的流上也会失败。
o NAT implementations differ markedly in their handling of packets. Quite a few only really work reliably with TCP packets, not UDP. Of the ones that do make any attempt to handle UDP packets, the timers aging out flows can vary widely making it challenging to predict behavior.
o NAT实现在处理数据包方面有着显著的不同。相当多的协议只在TCP数据包上可靠地工作，而不是UDP。在那些试图处理UDP数据包的人中，超时流的计时器可能变化很大，这使得预测行为具有挑战性。
o Variation in address and port assignments can be quite frequent - on NATs, port numbers always change, and change unpredictably; there may be multiple NATs in parallel for load-sharing, making IP address variations quite likely as well.
o 地址和端口分配的变化可能非常频繁-在NAT上，端口号总是变化，并且变化不可预测；可能有多个NAT并行用于负载共享，这使得IP地址也很可能发生变化。
By distinguishing these approaches as short term fixes, the IAB believes the following considerations must be explicitly addressed in any proposal:
通过将这些方法区分为短期解决方案，IAB认为任何提案中都必须明确考虑以下因素：
1. Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal. A short term fix should not be generalized to solve other problems. Such generalizations lead to the the prolonged dependence on and usage of the supposed short term fix -- meaning that it is no longer accurate to call it "short term".
1. 精确定义一个具体的、范围有限的问题，该问题将通过UNSAF提案解决。不应将短期修复推广到解决其他问题。这种泛化导致长期依赖和使用假定的短期修复方法——这意味着称之为“短期”不再准确。
2. Description of an exit strategy/transition plan. The better short term fixes are the ones that will naturally see less and less use as the appropriate technology is deployed.
2. 退出战略/过渡计划的说明。更好的短期修复方法是，随着适当技术的部署，自然会看到越来越少的使用。
3. Discussion of specific issues that may render systems more "brittle". For example, approaches that involve using data at multiple network layers create more dependencies, increase debugging challenges, and make it harder to transition.
3. 讨论可能使系统更“脆弱”的具体问题。例如，涉及在多个网络层使用数据的方法会产生更多的依赖性，增加调试挑战，并使转换更加困难。
4. Identify requirements for longer term, sound technical solutions; contribute to the process of finding the right longer term solution.
4. 确定长期、可靠的技术解决方案的要求；有助于找到正确的长期解决方案。
5. Discussion of the impact of the noted practical issues with existing deployed NATs and experience reports.
5. 与现有已部署NAT和经验报告讨论已注意到的实际问题的影响。
As a general class of workarounds, UNSAF proposals may introduce security holes because, in the absence of "middlebox communication (midcom)", there is no feasible way to let incoming communications make their way through a firewall under proper supervision: respecting the firewall policies as opposed to circumventing security mechanisms.
作为一种一般的解决办法，UNSAF的提案可能会引入安全漏洞，因为在没有“中间箱通信（midcom）”的情况下，没有可行的方法让传入通信在适当的监督下通过防火墙：尊重防火墙政策，而不是规避安全机制。
Appendix A. IAB Members at the time of this writing:
附录A.撰写本文时的IAB成员：
Harald Alvestrand Ran Atkinson Rob Austein Fred Baker Leslie Daigle Steve Deering Sally Floyd Ted Hardie Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Mike St. Johns
哈拉尔·阿尔维斯特兰德（Harald Alvestrand）经营的是阿特金森（Atkinson）、罗布·奥斯汀（Rob Austein）、弗雷德·贝克（Fred Baker）、莱斯利·戴格尔（Leslie Daigle）、史蒂夫·迪林（Steve Deering）、萨莉·弗洛伊德（Sally Floyd）、泰德·哈迪（Ted Hardie）、杰夫
This document has benefited greatly from detailed comments and suggestions from Thomas Narten, Bernard Aboba, Keith Moore, and James Woodyatt.
本文件从托马斯·纳顿、伯纳德·阿博巴、基思·摩尔和詹姆斯·伍迪亚特的详细评论和建议中获益匪浅。
This document was originally drafted when the following people were part of the IAB: Steve Bellovin, Brian Carpenter, Jon Crowcroft, John Klensin and Henning Schulzrinne; it has benefited considerably from their contributions and review.
本文件最初起草时，以下人员是IAB的一部分：Steve Bellovin、Brian Carpenter、Jon Crowcroft、John Klensin和Henning Schulzrinne；它从他们的贡献和审查中受益匪浅。
Here is one sample scenario wherein it is difficult to describe a single "outside" to a given address realm (bridged by NAPTs). This sort of configuration might arise in an enterprise environment where different divisions have their own subnets (each using the same private address space); the divisions are connected so that they can pass traffic on each others' networks, but to access the global Internet, each uses a different NAPT/firewall:
下面是一个示例场景，其中很难描述给定地址域（通过NAPTs桥接）的单个“外部”。这种配置可能出现在企业环境中，其中不同的部门有自己的子网（每个子网使用相同的专用地址空间）；各部门相互连接，以便在彼此的网络上传递流量，但为了访问全球互联网，每个部门使用不同的NAPT/防火墙：
+---------+
| Box C | (192.168.4.5)
+---+-----+
|
---------------------------------+-------
|
| 192.168.3.0/24
+----+----+
| NAT 2 |
+----+----+
| 10.1.0.0/32
|
-----+-------------------------+------------+----
| |
| +----+----+
| | Box B | (10.1.1.100)
| +---------+
|
+----+----+
| NAPT 1 | (10.1.2.27)
+----+----+
| 10.1.0.0/32
|
----+-----+--
|
|
+----+----+
| Box A | (10.1.1.100)
+---------+
+---------+
| Box C | (192.168.4.5)
+---+-----+
|
---------------------------------+-------
|
| 192.168.3.0/24
+----+----+
| NAT 2 |
+----+----+
| 10.1.0.0/32
|
-----+-------------------------+------------+----
| |
| +----+----+
| | Box B | (10.1.1.100)
| +---------+
|
+----+----+
| NAPT 1 | (10.1.2.27)
+----+----+
| 10.1.0.0/32
|
----+-----+--
|
|
+----+----+
| Box A | (10.1.1.100)
+---------+
From the perspective of Box B, Box A's address is (some port on) 10.1.2.27. From the perspective of Box C, however, Box A's address is some address in the space 192.168.3.0/24.
从方框B的角度来看，方框A的地址是（10.1.2.27上的某个端口）。然而，从方框C的角度来看，方框A的地址是192.168.3.0/24空间中的某个地址。
James Woodyatt provided the following scenario, based on current examples of home networking products:
James Woodyatt根据家庭网络产品的当前示例提供了以下场景：
o the customer has existing Internet service from some broadband service provider, using e.g. a DSL line connected to an appliance that integrates a DSL modem with a NAT router/firewall.
o 客户从某个宽带服务提供商处获得现有互联网服务，例如，使用DSL线路连接到将DSL调制解调器与NAT路由器/防火墙集成的设备。
o these devices are sometimes packaged with automated provisioning firmware, so the customer may view them as part of what their ISP provides them.
o 这些设备有时带有自动资源调配固件，因此客户可能会将其视为ISP提供的一部分。
o later, the customer wants to use a host with only a wireless LAN interface, so they install a wireless access point that ships in its default configuration with NAT and a DHCP server enabled.
o 稍后，客户希望使用仅具有无线LAN接口的主机，因此他们安装了一个无线接入点，该接入点以默认配置随附，并启用NAT和DHCP服务器。
o after this, the customer has a wired LAN in one private address realm and a wireless LAN in another private address realm.
o 在此之后，客户在一个专用地址域中拥有有线LAN，在另一个专用地址域中拥有无线LAN。
Furthermore, most customers probably have no idea what the phrase "address realm" means and shouldn't have to learn it. All they often know is that the printer server is inaccessible to the wireless laptop computer. (Why? Because the discovery protocol uses UDP multicast with TTL=1, but that's okay because any response would just be dropped by the NAT anyway, because there's no ALG.)
此外，大多数客户可能不知道“地址域”是什么意思，也不必学习它。他们通常只知道无线笔记本电脑无法访问打印机服务器。（为什么？因为发现协议使用TTL=1的UDP多播，但这没关系，因为任何响应都会被NAT丢弃，因为没有ALG。）
Authors' Addresses
作者地址
Leslie Daigle Editor
莱斯利·戴格尔编辑
Internet Architecture Board IAB EMail: iab@iab.org
互联网架构委员会IAB电子邮件：iab@iab.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。