Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 6967 France Telecom
Category: Informational J. Touch
ISSN: 2070-1721 USC/ISI
P. Levis
France Telecom
R. Penno
Cisco
June 2013
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 6967 France Telecom
Category: Informational J. Touch
ISSN: 2070-1721 USC/ISI
P. Levis
France Telecom
R. Penno
Cisco
June 2013
Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments
分析在共享地址部署中显示主机标识符（主机ID）的潜在解决方案
Abstract
摘要
This document is a collection of potential solutions for revealing a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort packets according to the sending host. The host identifier must be unique to each host under the same shared IP address.
本文档是一个潜在解决方案的集合，用于在路径中涉及运营商级NAT（CGN）或应用程序代理时显示主机标识符（表示为主机ID）。远程服务器可以使用此主机标识符根据发送主机对数据包进行排序。主机标识符对于同一共享IP地址下的每个主机都必须是唯一的。
This document analyzes a set of potential solutions for revealing a host identifier and does not recommend a particular solution, although it does highlight the hazards of some approaches.
本文档分析了一组用于显示主机标识符的潜在解决方案，并不推荐特定的解决方案，尽管它确实强调了某些方法的危害。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6967.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6967.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. On HOST_ID . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. HOST_ID and Privacy . . . . . . . . . . . . . . . . . . . . . 6
4. Detailed Solutions Analysis . . . . . . . . . . . . . . . . . 8
4.1. Use the Identification Field of the IPv4 Header (IP-ID) . 8
4.1.1. Description . . . . . . . . . . . . . . . . . . . . . 8
4.1.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Define an IP Option . . . . . . . . . . . . . . . . . . . 9
4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Define a TCP Option . . . . . . . . . . . . . . . . . . . 9
4.3.1. Description . . . . . . . . . . . . . . . . . . . . . 9
4.3.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Inject Application Protocol Message Headers . . . . . . . 11
4.4.1. Description . . . . . . . . . . . . . . . . . . . . . 11
4.4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 12
4.5. PROXY Protocol . . . . . . . . . . . . . . . . . . . . . 13
4.5.1. Description . . . . . . . . . . . . . . . . . . . . . 13
4.5.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 13
4.6. Assign Port Sets . . . . . . . . . . . . . . . . . . . . 14
4.6.1. Description . . . . . . . . . . . . . . . . . . . . . 14
4.6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Host Identity Protocol (HIP) . . . . . . . . . . . . . . 14
4.7.1. Description . . . . . . . . . . . . . . . . . . . . . 14
4.7.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 14
4.8. Use of a Notification Channel (e.g., ICMP) . . . . . . . 15
4.8.1. Description . . . . . . . . . . . . . . . . . . . . . 15
4.8.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 15
4.9. Use Out-of-Band Mechanisms (e.g., Ident) . . . . . . . . 16
4.9.1. Description . . . . . . . . . . . . . . . . . . . . . 16
4.9.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 17
5. Solutions Analysis: Synthesis . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. On HOST_ID . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. HOST_ID and Privacy . . . . . . . . . . . . . . . . . . . . . 6
4. Detailed Solutions Analysis . . . . . . . . . . . . . . . . . 8
4.1. Use the Identification Field of the IPv4 Header (IP-ID) . 8
4.1.1. Description . . . . . . . . . . . . . . . . . . . . . 8
4.1.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Define an IP Option . . . . . . . . . . . . . . . . . . . 9
4.2.1. Description . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Define a TCP Option . . . . . . . . . . . . . . . . . . . 9
4.3.1. Description . . . . . . . . . . . . . . . . . . . . . 9
4.3.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 10
4.4. Inject Application Protocol Message Headers . . . . . . . 11
4.4.1. Description . . . . . . . . . . . . . . . . . . . . . 11
4.4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 12
4.5. PROXY Protocol . . . . . . . . . . . . . . . . . . . . . 13
4.5.1. Description . . . . . . . . . . . . . . . . . . . . . 13
4.5.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 13
4.6. Assign Port Sets . . . . . . . . . . . . . . . . . . . . 14
4.6.1. Description . . . . . . . . . . . . . . . . . . . . . 14
4.6.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Host Identity Protocol (HIP) . . . . . . . . . . . . . . 14
4.7.1. Description . . . . . . . . . . . . . . . . . . . . . 14
4.7.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 14
4.8. Use of a Notification Channel (e.g., ICMP) . . . . . . . 15
4.8.1. Description . . . . . . . . . . . . . . . . . . . . . 15
4.8.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 15
4.9. Use Out-of-Band Mechanisms (e.g., Ident) . . . . . . . . 16
4.9.1. Description . . . . . . . . . . . . . . . . . . . . . 16
4.9.2. Analysis . . . . . . . . . . . . . . . . . . . . . . 17
5. Solutions Analysis: Synthesis . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21
As reported in [RFC6269], several issues are encountered when an IP address is shared among several subscribers. These issues are encountered in various deployment contexts, e.g., Carrier-Grade NAT (CGN), application proxies, or Address plus Port (A+P) [RFC6346]. Examples of such issues are: implicit identification (Section 13.2 of [RFC6269]), spam (Section 13.3 of [RFC6269]), blacklisting a misbehaving host (Section 13.1 of [RFC6269]), or redirecting users with infected machines to a dedicated portal (Section 5.1 of [RFC6269]).
如[RFC6269]中所述，在多个订户之间共享IP地址时会遇到几个问题。这些问题在各种部署环境中都会遇到，例如，运营商级NAT（CGN）、应用程序代理或地址加端口（A+P）[RFC6346]。此类问题的示例包括：隐式识别（RFC6269第13.2节）、垃圾邮件（RFC6269第13.3节）、将行为不端的主机列入黑名单（RFC6269第13.1节）或将受感染计算机的用户重定向到专用门户（RFC6269第5.1节）。
In particular, some servers use the source IPv4 address as an identifier to treat some incoming connections differently. Due to the deployment of CGNs (e.g., NAT44 [RFC3022], NAT64 [RFC6146]), that address will be shared. In particular, when a server receives packets from the same source address, because this address is shared, the server does not know which host is the sending host [RFC6269]. The sole use of the IPv4 address is not sufficient to uniquely distinguish a host. As a mitigation, it is tempting to investigate ways that would disclose information to be used by the remote server as a means of uniquely disambiguating packets sent from hosts using the same IPv4 address.
特别是，一些服务器使用源IPv4地址作为标识符，以区别对待一些传入连接。由于CGN的部署（例如NAT44[RFC3022]，NAT64[RFC6146]），该地址将被共享。特别是，当服务器从同一源地址接收数据包时，由于该地址是共享的，因此服务器不知道哪个主机是发送主机[RFC6269]。仅使用IPv4地址不足以唯一区分主机。作为一种缓解措施，很有可能会研究一些方法，这些方法会公开远程服务器将要使用的信息，作为唯一消除来自使用相同IPv4地址的主机发送的数据包歧义的方法。
The risk of not mitigating these issues include: OPEX (Operational Expenditure) increase for IP connectivity service providers (costs induced by calls to a hotline), revenue loss for content providers (loss of users' audience), and customers' dissatisfaction (low quality of experience, service segregation, etc.).
无法缓解这些问题的风险包括：IP连接服务提供商的运营支出（OPEX）增加（拨打热线导致的成本）、内容提供商的收入损失（用户观众损失）以及客户的不满（体验质量低、服务分离等）。
The purpose of this document is to analyze a set of alternative channels to convey a host identifier and to assess to what extent the alternatives solve the problem described in Section 2. The evaluation is intended to be comprehensive, regardless of the maturity or validity of any currently known or proposed solution. The alternatives analyzed in the document are listed below:
本文件的目的是分析一组备选信道，以传递主机标识符，并评估备选信道在多大程度上解决了第2节中描述的问题。无论当前已知或提议的解决方案是否成熟或有效，评估都是全面的。文件中分析的备选方案如下所示：
o Use the Identification field of the IP header (denoted as IP-ID, Section 4.1). o Define a new IP option (Section 4.2). o Define a new TCP option (Section 4.3). o Inject application headers (Section 4.4). o Enable Proxy Protocol (Section 4.5). o Assign port sets (Section 4.6). o Activate HIP (Host Identity Protocol) (Section 4.7). o Use a notification channel (Section 4.8). o Use an out-of-band mechanism (Section 4.9).
o 使用IP报头的标识字段（表示为IP-ID，第4.1节）。o定义新的IP选项（第4.2节）。o定义新的TCP选项（第4.3节）。o注入应用程序头（第4.4节）。o启用代理协议（第4.5节）。o分配端口集（第4.6节）。o激活HIP（主机身份协议）（第4.7节）。o使用通知渠道（第4.8节）。o使用带外机构（第4.9节）。
A synthesis is provided in Section 5, while the detailed analysis is elaborated in Section 4.
第5节提供了综合，而第4节详细阐述了详细分析。
Section 3 discusses privacy issues common to all proposed solutions. It is out of scope of this document to elaborate on privacy issues specific to each solution.
第3节讨论了所有拟议解决方案的共同隐私问题。详细阐述每个解决方案的隐私问题超出了本文档的范围。
This document does not include any recommendations because the working group felt that it was too premature to include one.
本文件未列入任何建议，因为工作组认为列入一项建议为时过早。
Policies that rely on source IP addresses and that are enforced by some servers will be applied to all hosts sharing the same IP address. For example, blacklisting the IP address of a spammer host will result in all other hosts that share that address having their access to the requested service restricted. [RFC6269] describes the issues in detail. Therefore, due to address sharing, servers need extra information beyond the source IP address to differentiate the sending host. We call this information the HOST_ID.
依赖于源IP地址并由某些服务器强制执行的策略将应用于共享相同IP地址的所有主机。例如，将垃圾邮件发送者主机的IP地址列入黑名单将导致共享该地址的所有其他主机对请求的服务的访问受到限制。[RFC6269]详细描述了这些问题。因此，由于地址共享，服务器需要源IP地址之外的额外信息来区分发送主机。我们将此信息称为主机ID。
The HOST_ID identifies a host under a shared IP address. Privacy-related considerations are discussed in Section 3.
主机ID标识共享IP地址下的主机。第3节讨论了与隐私相关的注意事项。
Within this document, a host can be any computer located behind a Home Gateway or directly connected to an address-sharing function located in the network provider's domain (typically this would be the Home Gateway itself).
在本文档中，主机可以是位于家庭网关后面的任何计算机，也可以直接连接到位于网络提供商域中的地址共享功能（通常是家庭网关本身）。
Because the HOST_ID is used by a remote server to sort out the packets by sending host, the HOST_ID must be unique to each host under the same shared IP address, where possible. In the case where only the Home Gateway is revealed to the operator side of the translation function, the HOST_ID need only be unique to the Home Gateway. The HOST_ID does not need to be globally unique. Of course, the combination of the (public) IP source address and the identifier (i.e., HOST_ID) ends up being unique.
由于远程服务器使用主机ID通过发送主机对数据包进行排序，因此在可能的情况下，主机ID对于相同共享IP地址下的每个主机都必须是唯一的。在仅向翻译功能的操作员侧显示家庭网关的情况下，主机标识只需是家庭网关的唯一标识。主机ID不需要全局唯一。当然，（公共）IP源地址和标识符（即主机ID）的组合最终是唯一的。
If the HOST_ID is conveyed at the IP level, all packets will have to bear the identifier. If it is conveyed at a higher connection-oriented level, the identifier is only needed once in the session establishment phase (for instance, a TCP three-way handshake), then all packets received in this session will be attributed to the HOST_ID designated during the session opening.
如果主机ID是在IP级别传输的，则所有数据包都必须带有该标识符。如果在更高的面向连接的级别上传输，那么在会话建立阶段只需要一次标识符（例如，TCP三方握手），那么在该会话中接收的所有数据包都将归属于会话打开期间指定的主机ID。
Within this document, we assume the operator-side address-sharing function injects the HOST_ID. Another deployment option to avoid potential performance degradation is to let the host or Home Gateway
在本文中，我们假设操作员端地址共享功能注入主机ID。另一种避免潜在性能下降的部署选项是让主机或家庭网关
inject its HOST_ID, but the address-sharing function will check its content (just like an IP anti-spoofing function). For some proposals, the HOST_ID is retrieved using an out-of-band mechanism or signaled in a dedicated notification channel.
注入其主机ID，但地址共享功能将检查其内容（就像IP防欺骗功能一样）。对于某些方案，使用带外机制检索主机标识，或在专用通知通道中发送信号。
For A+P [RFC6346] and its variants, port set announcements may be needed as discussed in Section 4.6.
对于A+P[RFC6346]及其变体，可能需要在第4.6节中讨论的端口集公告。
Security considerations are common to all analyzed solutions (see Section 6). Privacy-related aspects are discussed in Section 3.
所有分析的解决方案都有共同的安全考虑（参见第6节）。第3节讨论了与隐私相关的方面。
The HOST_ID can be ambiguous for hosts with multiple interfaces or multiple addresses assigned to a single interface. HOST_IDs that are the same may be used to imply or infer the same end system, but HOST_IDs that are different should not be used to imply or infer whether the end systems are the same or different.
对于具有多个接口或分配给单个接口的多个地址的主机，主机ID可能不明确。相同的主机ID可用于暗示或推断相同的终端系统，但不同的主机ID不应用于暗示或推断终端系统是相同还是不同。
IP address sharing is motivated by a number of different factors. For years, many network operators have conserved public IPv4 addresses by making use of Customer Premises Equipment (CPE) that assigns a single public IPv4 address to all hosts within the customer's local area network and uses NAT [RFC3022] to translate between locally unique private IPv4 addresses and the CPE's public address. With the exhaustion of IPv4 address space, address sharing between customers on a much larger scale is likely to become much more prevalent. While many individual users are unaware of and uninvolved in decisions about whether their unique IPv4 addresses get revealed when they send data via IP, some users realize privacy benefits associated with IP address sharing, and some may even take steps to ensure that NAT functionality sits between them and the public Internet. IP address sharing makes the actions of all users behind the NAT function unattributable to any single host, creating room for abuse but also providing some identity protection for non-abusive users who wish to transmit data with reduced risk of being uniquely identified.
IP地址共享的动机有很多不同的因素。多年来，许多网络运营商通过使用客户场所设备（CPE）来保存公共IPv4地址，该设备将单个公共IPv4地址分配给客户局域网内的所有主机，并使用NAT[RFC3022]在本地唯一的专用IPv4地址和CPE的公共地址之间进行转换。随着IPv4地址空间的耗尽，客户之间更大规模的地址共享可能会变得更加普遍。虽然许多个人用户不知道，也不参与他们通过IP发送数据时是否会泄露其唯一IPv4地址的决策，但一些用户意识到与IP地址共享相关的隐私优势，有些用户甚至可能采取措施确保NAT功能位于他们和公共互联网之间。IP地址共享使得NAT功能背后的所有用户的行为都不受任何单个主机的影响，这为滥用创造了空间，但也为希望传输数据的非滥用用户提供了一些身份保护，从而降低了被唯一识别的风险。
The proposals considered in this document help differentiate between hosts that share a public IP address. The extent of that differentiation depends on what information is included in the HOST_ID.
本文档中考虑的方案有助于区分共享公共IP地址的主机。这种差异的程度取决于主机ID中包含的信息。
The volatility of the HOST_ID information is similar to that of the internal IP address: a distinct HOST_ID may be used by the address-sharing function when the host reboots or gets a new internal IP address. As with persistent IP addresses, persistent HOST_IDs facilitate user tracking over time.
主机ID信息的波动性与内部IP地址的波动性相似：当主机重新启动或获得新的内部IP地址时，地址共享功能可能会使用不同的主机ID。与持久性IP地址一样，持久性主机ID有助于随着时间的推移进行用户跟踪。
As a general matter, the HOST_ID proposals do not seek to make hosts any more identifiable than they would be if they were using a public, non-shared IP address. However, depending on the solution proposal, the addition of HOST_ID information may allow a device to be fingerprinted more easily than it otherwise would be. To prevent this, the following design considerations are to be taken into account:
一般来说，HOST_ID提案不寻求使主机比使用公共、非共享IP地址时更易于识别。然而，根据解决方案的不同，添加主机ID信息可能会比其他方式更容易对设备进行指纹识别。为防止出现这种情况，应考虑以下设计因素：
o It is recommended that HOST_IDs be limited to providing local uniqueness rather than global uniqueness.
o 建议将主机ID限制为提供本地唯一性，而不是全局唯一性。
o The address-sharing function should not use permanent HOST_ID values.
o 地址共享功能不应使用永久主机ID值。
Should multiple solutions be combined (e.g., TCP option and Forwarded header) that include different pieces of information in the HOST_ID, fingerprinting may become even easier. To prevent this, an address-sharing function that is able to inject HOST_IDs in several layers should reveal the same subsets of information at each layer. For example, if one layer references the lower 16 bits of an IPv4 address, the other layer should reference these 16 bits too.
如果将多个解决方案（例如，TCP选项和转发头）组合在一起，并在主机ID中包含不同的信息，则指纹识别可能会变得更加容易。为了防止这种情况，能够在多个层中注入主机ID的地址共享功能应该在每个层中显示相同的信息子集。例如，如果一层引用IPv4地址的较低16位，那么另一层也应该引用这16位。
A HOST_ID can be spoofed, as this is also the case for spoofing an IP address. Furthermore, users of network-based anonymity services (like Tor [TOR]) may be capable of stripping HOST_ID information before it reaches its destination.
可以欺骗主机ID，因为欺骗IP地址也是如此。此外，基于网络的匿名服务（如Tor[Tor]）的用户可以在主机ID信息到达目的地之前剥离主机ID信息。
In order to control the information revealed to external parties, an address-sharing function should be able to strip, rewrite, and add HOST_ID fields.
为了控制透露给外部各方的信息，地址共享功能应该能够剥离、重写和添加主机ID字段。
An address-sharing function may be configured to enforce different end-user preferences with regards to HOST_ID injection. For example, HOST_ID injection can be disabled for some users. This feature is policy based and deployment specific.
地址共享功能可被配置为针对主机ID注入强制实施不同的最终用户偏好。例如，可以为某些用户禁用主机ID注入。此功能基于策略且特定于部署。
HOST_ID specification document(s) should explain the privacy impact of the solutions they specify, including the extent of HOST_ID uniqueness and persistence, assumptions made about the lifetime of the HOST_ID, whether and how the HOST_ID can be obfuscated or recycled, whether location information can be exposed, and the impact of the use of the HOST_ID on device or implementation fingerprinting. [IAB-PRIVACY] provides further guidance.
HOST_ID规范文件应解释其指定的解决方案对隐私的影响，包括HOST_ID唯一性和持久性的程度、对HOST_ID的生命周期所做的假设、HOST_ID是否以及如何被混淆或回收、位置信息是否可以公开、，以及主机ID的使用对设备或实现指纹识别的影响。[IAB-PRIVACY]提供了进一步的指导。
For more discussion about privacy, refer to [RFC6462].
有关隐私的更多讨论，请参阅[RFC6462]。
The IPv4 ID (Identification field of IP header, i.e., IP-ID) can be used to insert information that uniquely distinguishes a host among those sharing the same IPv4 address. Use of the IP-ID as a channel to convey the HOST_ID is a theoretical construct (i.e., it is an undocumented proposal).
IPv4 ID（IP头的标识字段，即IP-ID）可用于插入在共享相同IPv4地址的主机之间唯一区分主机的信息。使用IP-ID作为传输主机ID的通道是一种理论构造（即，它是一个未记录的提案）。
An address-sharing function can rewrite the IP-ID field to insert a value that is unique to the host (16 bits are sufficient to uniquely disambiguate hosts sharing the same IP address). The address-sharing function injecting the HOST_ID must follow the rules defined in [RFC6864]; in particular, the same HOST_ID is not reassigned to another host sharing the same IP address during a given time interval.
地址共享函数可以重写IP-ID字段，以插入主机唯一的值（16位足以唯一地消除共享相同IP地址的主机的歧义）。注入主机标识的地址共享函数必须遵循[RFC6864]中定义的规则；特别是，在给定的时间间隔内，不会将相同的主机ID重新分配给共享相同IP地址的另一个主机。
A variant of this approach relies upon the format of certain packets, such as TCP SYN, where the IP-ID can be modified to contain a 16-bit HOST_ID.
这种方法的一种变体依赖于某些数据包的格式，例如TCP SYN，其中IP-ID可以修改为包含16位主机ID。
Address-sharing devices using this solution would be required to indicate that they do so, possibly using a special DNS record.
使用此解决方案的地址共享设备需要指示它们这样做，可能需要使用特殊的DNS记录。
This usage is not consistent with the fragment reassembly use of the Identification field [RFC0791] or the updated handling rules for the Identification field [RFC6864].
此用法与标识字段[RFC0791]的碎片重组使用或标识字段[RFC6864]的更新处理规则不一致。
Complications may arise if the packet is fragmented before reaching the device that is injecting the HOST_ID. To appropriately handle those packet fragments, the address-sharing function will need to maintain a lot of state.
如果数据包在到达注入主机ID的设备之前被分割，则可能会出现复杂情况。要正确处理这些数据包碎片，地址共享功能将需要保持大量状态。
Another complication to be encountered is where translation is balanced among several NATs; setting the appropriate HOST_ID by a given NAT would alter the coordination between those NATs. Of course, one can argue that this coordinated NAT scenario is not a typical deployment scenario; regardless, using the IP-ID as a channel to convey a HOST_ID is ill-advised.
另一个要遇到的复杂问题是翻译在几个NAT之间是平衡的；通过给定NAT设置适当的主机ID将改变这些NAT之间的协调。当然，有人会说这种协调NAT场景不是典型的部署场景；无论如何，使用IP-ID作为传输主机ID的通道是不明智的。
An alternate way to convey the HOST_ID is to define an IP option [RFC0791]. A HOST_ID IP option can be inserted by the address-sharing function to uniquely distinguish a host among those sharing the same IP address. An example of such an option is documented in [REVEAL-IP]. This IP option allows the conveyance of an IPv4 address, an IPv6 prefix, a Generic Routing Encapsulation (GRE) key, an IPv6 Flow Label, etc.
传递主机ID的另一种方法是定义IP选项[RFC0791]。地址共享功能可以插入主机ID IP选项，以便在共享相同IP地址的主机中唯一区分主机。[REVEL-IP]中记录了此类选项的示例。此IP选项允许传输IPv4地址、IPv6前缀、通用路由封装（GRE）密钥、IPv6流标签等。
An IP option may also be used as described in Section 4.6 of [RFC3022].
IP选项也可按照[RFC3022]第4.6节所述使用。
This proposal can apply to any transport protocol. However, it is widely known that routers and other middleboxes filter IP options (e.g., drop IP packets with unknown IP options, strip unknown IP options, etc.).
此建议可适用于任何传输协议。然而，众所周知，路由器和其他中间盒过滤IP选项（例如，丢弃具有未知IP选项的IP数据包、剥离未知IP选项等）。
Injecting the HOST_ID IP option introduces some implementation complexity in the following cases:
在以下情况下，注入HOST_ID IP选项会带来一些实现复杂性：
o The packet is at or close to the MTU size.
o 数据包大小等于或接近MTU大小。
o The options space is exhausted.
o 选项空间已用尽。
Previous studies demonstrated that "IP Options are not an option" (refer to [Not_An_Option] and [Options]).
以前的研究表明，“IP选项不是选项”（参考[非选项]和[选项]）。
In conclusion, using an IP option to convey a HOST_ID is not viable.
总之，使用IP选项传送主机ID是不可行的。
The HOST_ID may be conveyed in a dedicated TCP option. An example is specified in [REVEAL-TCP]. This option encloses the TCP client's identifier (e.g., the lower 16 bits of its IPv4 address, its VLAN ID, VRF ID, or subscriber ID). The address-sharing device inserts this TCP option into the TCP SYN packet.
主机ID可以通过专用TCP选项传送。[REVEL-TCP]中规定了一个示例。此选项包含TCP客户端的标识符（例如，其IPv4地址的低16位、其VLAN ID、VRF ID或订户ID）。地址共享设备将此TCP选项插入到TCP SYN数据包中。
Using a new TCP option to convey the HOST_ID does not require any modification to the applications, but it is applicable only for TCP-based applications. Applications relying on other transport protocols are therefore left unsolved.
使用新的TCP选项传送主机ID不需要对应用程序进行任何修改，但它仅适用于基于TCP的应用程序。因此，依赖于其他传输协议的应用程序没有得到解决。
[REVEAL-TCP] discusses the interference with other TCP options.
[REVEAL-TCP]讨论与其他TCP选项的干扰。
The risk of session failure due to handling a new TCP option is low as measured in [Options]. [REVEAL-TCP-EXP] provides a detailed implementation and experimentation report of a HOST_ID TCP option. This document provides an in-depth investigation of the impact of implementing HOST_ID on the host, the address-sharing function, and the enforcement of policies at the server side. It also reports a failure ratio of 0.103% among the top 100,000 websites.
由于处理新的TCP选项而导致会话失败的风险较低，如[Options]中所述。[REVEAL-TCP-EXP]提供主机ID TCP选项的详细实施和实验报告。本文档深入研究了在主机上实现HOST_ID、地址共享功能以及服务器端策略实施的影响。它还报告说，在排名前10万的网站中，失败率为0.103%。
Some downsides have been identified with defining a TCP option to reveal a host identity:
通过定义TCP选项来显示主机标识，发现了一些缺点：
o Conveying an IP address in a TCP option may be seen as a violation of OSI layers, but since IP addresses are already used for the checksum computation, this is not seen as a blocking point. Moreover, the updated version of [REVEAL-TCP] no longer allows conveyance of a full IP address because the HOST_ID is encoded in 16 bits.
o 在TCP选项中传输IP地址可能被视为违反OSI层，但由于IP地址已用于校验和计算，因此这不被视为阻塞点。此外，更新版本的[REVEAL-TCP]不再允许传输完整的IP地址，因为主机ID以16位编码。
o TCP option space is limited and might be consumed by the TCP client. [REVEAL-TCP-EXP] discusses two approaches to sending the HOST_ID: sending the HOST_ID in the TCP SYN (which consumes more bytes in the TCP header of the TCP SYN) and sending the HOST_ID in a TCP ACK (which consumes only two bytes in the TCP SYN).
o TCP选项空间有限，可能会被TCP客户端占用。[REVEAL-TCP-EXP]讨论了两种发送主机ID的方法：在TCP SYN中发送主机ID（在TCP SYN的TCP头中消耗更多字节）和在TCP ACK中发送主机ID（在TCP SYN中仅消耗两个字节）。
o Content providers may find it more desirable to receive the HOST_ID in the TCP SYN, as that more closely preserves the HOST_ID received in the source IP address as per current practices. Moreover, sending the HOST_ID in the TCP SYN does not interfere with [FASTOPEN]. In the ACK mode, if the server is configured to deliver different data based on HOST_ID, then it would have to wait for the ACK before transmitting data.
o 内容提供商可能会发现更希望在TCP SYN中接收主机ID，因为根据当前实践，这将更紧密地保留在源IP地址中接收的主机ID。此外，在TCP SYN中发送主机ID不会干扰[FASTOPEN]。在ACK模式下，如果服务器被配置为根据主机ID传递不同的数据，那么它必须在传输数据之前等待ACK。
o HOST_ID mechanisms need to be aware of end-to-end (E2E) issues and avoid interfering with them. One example of such interference would be injecting or removing TCP options of transited packets; another such interference involves terminating and re-originating TCP connections not belonging to the transit device. The HOST_ID TCP option handled by the source node avoids this issue.
o 主机ID机制需要了解端到端（E2E）问题，并避免干扰它们。这种干扰的一个例子是注入或移除传输包的TCP选项；另一种此类干扰涉及终止和重新发起不属于传输设备的TCP连接。源节点处理的HOST_ID TCP选项可避免此问题。
o Injecting the HOST_ID TCP option introduces some implementation complexity if the options space is exhausted. Specification document(s) should specify the behavior of the address-sharing function in detail in such a case.
o 如果选项空间耗尽，则注入HOST_ID TCP选项会带来一些实现复杂性。在这种情况下，规范文档应详细说明地址共享功能的行为。
o It is more complicated to implement sending the HOST_ID in a TCP ACK, as it can introduce MTU issues if the ACK packet also contains TCP data or if a TCP segment is lost. Note that MTU complications can be experienced if user data is included in a SYN packet (e.g., [FASTOPEN]).
o 在TCP ACK中实现发送主机ID更为复杂，因为如果ACK数据包也包含TCP数据或TCP段丢失，则会导致MTU问题。请注意，如果用户数据包含在SYN数据包中（例如，[FASTOPEN]），则可能会出现MTU复杂性。
o When there are several NATs in the path, the original HOST_ID may be lost. The loss of the original HOST_ID may not be a problem, as the target usage is between proxies or between a CGN and server. Only the information leaked in the last communication leg (i.e., between the last address-sharing function and the server) is likely to be useful.
o 当路径中有多个NAT时，原始主机ID可能会丢失。丢失原始主机ID可能不是问题，因为目标使用在代理之间或CGN和服务器之间。只有在最后一个通信段（即，最后一个地址共享功能和服务器之间）泄漏的信息可能有用。
o Interference with usages such as a Forwarded HTTP header (see Section 4.4) should be elaborated to specify the behavior of servers when both options are used; in particular, specify which information to use: the content of the TCP option or what is conveyed in the application headers.
o 应详细说明对转发HTTP头（见第4.4节）等用法的干扰，以指定使用这两个选项时服务器的行为；特别是，指定要使用的信息：TCP选项的内容或在应用程序头中传递的内容。
o When load balancers or proxies are in the path, this option does not allow the preservation of the original source IP address and source port. Preserving such information is required for logging purposes (e.g., [RFC6302]). [REVEAL-TCP-EXP] defines a TCP option that allows various combinations of source information (e.g., source port, source port and source IP address, source IPv6 prefix, etc.) to be revealed.
o 当负载平衡器或代理位于路径中时，此选项不允许保留原始源IP地址和源端口。出于记录目的（例如，[RFC6302]）需要保存此类信息。[REVEAL-TCP-EXP]定义了一个TCP选项，该选项允许显示源信息的各种组合（例如，源端口、源端口和源IP地址、源IPv6前缀等）。
More discussion about issues raised when extending TCP can be found at [ExtendTCP].
有关扩展TCP时提出的问题的更多讨论，请访问[ExtendTCP]。
Another option is to not require any change within the transport or the IP levels but to convey the required information that will be used to disambiguate hosts at the application payload. The format of the conveyed information and the related semantics depend on its application (e.g., HTTP, SIP, SMTP, etc.).
另一种选择是不需要在传输或IP级别内进行任何更改，而是传递所需的信息，这些信息将用于在应用程序负载上消除主机的歧义。传输信息的格式和相关语义取决于其应用程序（例如HTTP、SIP、SMTP等）。
Related mechanisms could be developed for other application-layer protocols, but the discussion in this document is limited to HTTP and similar protocols.
可以为其他应用层协议开发相关机制，但本文中的讨论仅限于HTTP和类似协议。
For HTTP, the Forwarded header [HTTP-FRWD] can be used to display the original IP address when an address-sharing device is involved. Service providers operating address-sharing devices can enable the feature of injecting the Forwarded header, which will enclose the original IPv4 address or the IPv6 prefix part (see the example shown in Figure 1). The address-sharing device has to strip all included Forwarded headers before injecting its own. Servers may rely on the contents of this field to enforce some policies such as blacklisting misbehaving users.
对于HTTP，当涉及地址共享设备时，转发头[HTTP-FRWD]可用于显示原始IP地址。操作地址共享设备的服务提供商可以启用注入转发头的功能，转发头将包含原始IPv4地址或IPv6前缀部分（参见图1中所示的示例）。地址共享设备在注入自己的头文件之前，必须剥离所有包含的转发头文件。服务器可能依赖此字段的内容来实施某些策略，例如将行为不端的用户列入黑名单。
Note that [HTTP-FRWD] standardizes the Forwarded header field, to replace the de facto (and not standard) X-Forwarded-For (XFF) header.
请注意，[HTTP-FRWD]标准化了转发头字段，以替换事实上（而非标准）的X-Forwarded-For（XFF）头。
Forwarded: for=192.0.2.1,for=[2001:db8::1]
Forwarded: proto=https;by=192.0.2.15
Forwarded: for=192.0.2.1,for=[2001:db8::1]
Forwarded: proto=https;by=192.0.2.15
Figure 1: Example of Forwarded-For
图1:Forwarded For的示例
Not all applications impacted by address sharing can support the ability to disclose the original IP address. Only a subset of protocols (e.g., HTTP) can rely on this solution.
并非所有受地址共享影响的应用程序都支持公开原始IP地址。只有一部分协议（如HTTP）可以依赖此解决方案。
For the HTTP case, to prevent users from injecting invalid HOST_IDs, an initiative has been launched by Wikimedia to maintain a list of trusted ISPs (Internet Service Providers) using XFF (see the list available at [Trusted_ISPs]). If an address-sharing device is on the list of trusted XFF ISPs, users editing Wikimedia located behind the address-sharing device will appear to be editing from their "original" IP address and not from the NATed IP address. If an offending activity is detected, individual hosts can be blacklisted instead of blacklisting all hosts sharing the same IP address.
对于HTTP案例，为了防止用户注入无效的主机ID，Wikimedia启动了一项计划，使用XFF维护受信任的ISP（互联网服务提供商）列表（请参见[trusted_ISP]上的列表）。如果某个地址共享设备位于受信任的XFF ISP列表中，则编辑位于该地址共享设备后面的Wikimedia的用户似乎是从其“原始”IP地址进行编辑，而不是从该IP地址进行编辑。如果检测到违规活动，可以将单个主机列入黑名单，而不是将共享相同IP地址的所有主机列入黑名单。
XFF header injection is a common practice of load balancers. When a load balancer is in the path, the original content of any included XFF header should not be stripped. Otherwise, the information about the "origin" IP address will be lost.
XFF标头注入是负载平衡器的常见做法。当负载平衡器位于路径中时，任何包含的XFF头的原始内容都不应被剥离。否则，有关“源”IP地址的信息将丢失。
When several address-sharing devices are crossed, the Forwarded header can convey the list of IP addresses (e.g., Figure 1). The origin HOST_ID can be exposed to the target server.
当几个地址共享设备交叉时，转发的报头可以传送IP地址列表（例如，图1）。源主机ID可以公开给目标服务器。
Injecting the Forwarded header also introduces some implementation complexity if the HTTP message is at or close to the MTU size.
如果HTTP消息的大小等于或接近MTU大小，则注入转发头也会带来一些实现复杂性。
It has been reported that some HTTP proxy implementations may encounter parsing issues when injecting an XFF header.
据报道，一些HTTP代理实现在注入XFF头时可能会遇到解析问题。
Injecting the Forwarded header for all HTTPS traffic is infeasible. This may be problematic given the current HTTPS usage trends.
为所有HTTPS流量注入转发头是不可行的。鉴于当前HTTPS的使用趋势，这可能会有问题。
The solution, referred to as the Proxy Protocol [Proxy], does not require any application-specific knowledge. The proposed solution (Proxy Protocol Version 1) would insert identification data directly into the application-data stream prior to the actual protocol data being sent, regardless of the protocol. Every application protocol would begin with a textual string of "PROXY", followed by some textual identification data, and with a CRLF; only then would the application data be inserted. Figure 2 shows an example of a line of data used for this purpose, in this case, for a TCP-over-IPv4 connection received from 192.0.2.1:56324 and destined to 192.0.2.15:443.
该解决方案称为代理协议[Proxy]，不需要任何特定于应用程序的知识。建议的解决方案（代理协议版本1）将在发送实际协议数据之前直接将标识数据插入到应用程序数据流中，而不考虑协议。每个应用程序协议都以文本字符串“PROXY”开头，后跟一些文本标识数据和一个CRLF；只有这样才能插入应用程序数据。图2显示了用于此目的的数据线示例，在本例中，用于从192.0.2.1:56324接收并发送到192.0.2.15:443的TCP-over-IPv4连接。
PROXY TCP4 192.0.2.1 192.0.2.15 56324 443\r\n
代理TCP4 192.0.2.1 192.0.2.15 56324 443\r\n
Figure 2: Example of PROXY Connection Report
图2：代理连接报告示例
Upon receipt of a message conveying this line, the server removes the line from the incoming stream. The line is parsed to retrieve the transported protocol. The content of this line is recorded in logs and used to enforce policies.
在接收到传输此线路的消息后，服务器从传入流中删除该线路。解析该行以检索传输的协议。此行的内容记录在日志中，并用于强制执行策略。
Proxy Protocol Version 2 is designed to accommodate IPv4/IPv6 and also non-TCP protocols (see [Proxy] for more details).
代理协议版本2旨在适应IPv4/IPv6以及非TCP协议（有关更多详细信息，请参阅[Proxy]）。
This solution can be deployed in a controlled environment, but it cannot be deployed to all access services available in the Internet. If the remote server does not support the Proxy Protocol, the session will fail. Other complications will arise due to the presence of firewalls, for instance.
此解决方案可以部署在受控环境中，但不能部署到Internet上所有可用的访问服务。如果远程服务器不支持代理协议，会话将失败。例如，由于防火墙的存在，还会出现其他复杂情况。
As a consequence, this solution is infeasible and cannot be recommended.
因此，此解决方案不可行，无法推荐。
This solution does not require any action from the address-sharing function to disclose a host identifier. Instead of assuming that all transport ports are associated with one single host, each host under the same external IP address is assigned a restricted port set. These port sets are then advertised to remote servers using offline means. This announcement is not required for the delivery of internal services (i.e., offered by the service provider deploying the address-sharing function) relying on implicit identification.
此解决方案不需要地址共享功能的任何操作来公开主机标识符。与假设所有传输端口都与一台主机关联不同，相同外部IP地址下的每台主机都被分配一个受限端口集。然后使用脱机方式将这些端口集播发到远程服务器。依靠隐式标识提供内部服务（即，由部署地址共享功能的服务提供商提供）不需要本公告。
Port sets assigned to hosts may be static or dynamic.
分配给主机的端口集可以是静态的，也可以是动态的。
Port set announcements to remote servers are not required to reveal the identity of individual hosts; they are used to advertise the enforced policy to generate non-overlapping port sets (e.g., the transport space associated with an IP address is fragmented to contiguous blocks of 2048 port numbers).
远程服务器的端口集公告不需要显示单个主机的身份；它们用于公布强制策略以生成非重叠端口集（例如，与IP地址相关联的传输空间被分割为2048个端口号的连续块）。
Examples of such an approach are documented in [RFC6346] and [DETERMCGN].
[RFC6346]和[N]中记录了此类方法的示例。
The solution does not require defining new fields or options; it is policy based.
解决方案不需要定义新字段或选项；它是基于政策的。
The solution may contradict the port randomization [RFC6056] as identified in [RFC6269]. A mitigation would be to avoid assigning static port sets to individual hosts.
该解决方案可能与[RFC6269]中确定的端口随机化[RFC6056]相矛盾。缓解措施是避免将静态端口集分配给各个主机。
The method is convenient for the delivery of services offered by the service provider that is also offering the Internet access service.
该方法便于同时提供因特网接入服务的服务提供商提供的服务的交付。
[RFC5201] specifies an architecture that introduces a new namespace to convey identity information.
[RFC5201]指定一种引入新名称空间以传递身份信息的体系结构。
This solution requires both the client and the server to support HIP [RFC5201]. Additional architectural considerations are to be taken into account, such as the key exchanges.
此解决方案要求客户端和服务器都支持HIP[RFC5201]。还需要考虑其他架构方面的考虑，例如密钥交换。
An alternative deployment model that does not require the client to be HIP-enabled is having the address-sharing function behave as a UDP/TCP-HIP relay. This model is also not viable as it assumes all servers are HIP-enabled.
另一种不要求客户端启用HIP的部署模型是将地址共享功能用作UDP/TCP-HIP中继。此模型也不可行，因为它假定所有服务器都支持HIP。
This solution is a theoretical construct (i.e., the proposal is not documented).
该解决方案是一种理论结构（即，提案未记录在案）。
Another alternative is to convey the HOST_ID using a separate notification channel than the one the packets issued to invoke the service.
另一种选择是使用一个单独的通知通道来传递主机ID，而不是发送数据包以调用服务的通知通道。
This solution relies on a mechanism where the address-sharing function encapsulates the necessary host-identifying information into an ICMP Echo Request packet that it sends in parallel with the initial session creation (e.g., SYN). The information included in the ICMP Request Data portion describes the five-tuples as seen on both sides of the address-sharing function. An implementation example is defined in [REVEAL-ICMP].
该解决方案依赖于一种机制，其中地址共享功能将必要的主机标识信息封装到ICMP回显请求包中，该回显请求包与初始会话创建（例如，SYN）并行发送。ICMP请求数据部分中包含的信息描述了地址共享函数两侧的五个元组。[REVEL-ICMP]中定义了一个实现示例。
o This ICMP proposal is valid for any transport protocol that uses a port number. The address-sharing function may be configured with the transport protocols that will trigger issuing those ICMP messages.
o 此ICMP建议适用于使用端口号的任何传输协议。地址共享功能可以配置传输协议，该协议将触发发出这些ICMP消息。
o A hint should be provided to the ultimate server (or intermediate nodes) that the ICMP Echo Request conveys a HOST_ID. This may be implemented using magic numbers (a magic number is a self-selected codepoint whose primary value is its unlikely collision with values selected by others).
o 应向最终服务器（或中间节点）提供ICMP回显请求传递主机ID的提示。这可以使用幻数实现（幻数是一个自选码点，其主要值是其不太可能与其他人选择的值发生冲突）。
o Even if ICMP packets are blocked in the communication path, the user connection does not have to be impacted.
o 即使ICMP数据包在通信路径中被阻塞，用户连接也不必受到影响。
o Implementations requiring a session establishment to be delayed until receipt of the companion ICMP Echo Request may lead to some user-experience degradation.
o 要求会话建立延迟到接收到伴随的ICMP回显请求的实现可能会导致某些用户体验降低。
o Because of the presence of load balancers in the path, the ultimate server receiving the SYN packet may not be the one that receives the ICMP message conveying the HOST_ID.
o 由于路径中存在负载平衡器，接收SYN数据包的最终服务器可能不是接收传递主机ID的ICMP消息的服务器。
o Because of the presence of load balancers in the path, the port number assigned by address sharing may be lost. Therefore, the mapping information conveyed in the ICMP may not be sufficient to associate a SYN packet with a received ICMP.
o 由于路径中存在负载平衡器，由地址共享分配的端口号可能会丢失。因此，在ICMP中传送的映射信息可能不足以将SYN分组与接收到的ICMP相关联。
o The proposal is not compatible with the presence of cascaded NAT. The main reason is that each NAT in the path will generate an ICMP message to reveal the internal host identifier. Because these messages will be translated by the downstream address-sharing devices, the remote server will receive multiple ICMP messages and will need to decide which host identifier to use.
o 该方案与级联NAT的存在不兼容。主要原因是路径中的每个NAT将生成一条ICMP消息以显示内部主机标识符。因为这些消息将由下游地址共享设备翻译，所以远程服务器将接收多个ICMP消息，并且需要决定使用哪个主机标识符。
o The ICMP proposal will add traffic overhead for both the server and the address-sharing device.
o ICMP提案将增加服务器和地址共享设备的通信开销。
o The ICMP proposal is similar to other mechanisms (e.g., IPFIX [IPFIX-NAT] and Syslog [SYSLOG-NAT]) for reporting dynamic mappings to a mediation platform (mainly for legal traceability purposes). Performance degradation is likely to be experienced by address-sharing functions because ICMP messages are sent for each new instantiated mapping (even if the mapping exists).
o ICMP提案类似于其他机制（例如，IPFIX[IPFIX-NAT]和Syslog[Syslog-NAT]），用于向调解平台报告动态映射（主要用于法律跟踪目的）。地址共享功能可能会出现性能下降，因为每个新的实例化映射都会发送ICMP消息（即使映射存在）。
o In some scenarios (e.g., Section 3 of [REVEAL-PCP]), the HOST_ID should be interpreted by intermediate devices that embed Policy Enforcement Points (PEP) [RFC2753] responsible for granting access to some services. These PEPs need to inspect all received packets in order to find the companion (traffic) messages to be correlated with ICMP messages conveying HOST_IDs. This induces more complexity to these intermediate devices.
o 在某些情况下（例如，[REVEL-PCP]第3节），主机ID应由嵌入策略实施点（PEP）[RFC2753]的中间设备来解释，这些设备负责授予对某些服务的访问权。这些PEP需要检查所有接收到的数据包，以便找到与传输主机ID的ICMP消息相关的伴随（流量）消息。这导致这些中间设备更加复杂。
Another alternative is to retrieve the HOST_ID using a dedicated query channel.
另一种方法是使用专用查询通道检索主机ID。
An implementation example may rely on the Identification Protocol (Ident) [RFC1413]. This solution assumes that the address-sharing function implements the server part of IDENT, while remote servers implement the client part of the protocol. IDENT needs to be updated to be able to return a host identifier instead of the user-id as defined in [RFC1413]. The IDENT response syntax uses the same USERID field described in [RFC1413], but rather than returning a username, a host identifier (e.g., a 16-bit value) is returned. For any new incoming connection, the server contacts the IDENT server to retrieve the associated identifier. During that phase, the connection may be delayed.
实现示例可以依赖于标识协议（Ident）[RFC1413]。此解决方案假定地址共享功能实现IDENT的服务器部分，而远程服务器实现协议的客户端部分。需要更新IDENT，以便能够返回主机标识符，而不是[RFC1413]中定义的用户id。IDENT响应语法使用[RFC1413]中描述的相同USERID字段，但不返回用户名，而是返回主机标识符（例如，16位值）。对于任何新的传入连接，服务器都会与IDENT服务器联系以检索关联的标识符。在该阶段，连接可能会延迟。
o IDENT is specific to TCP. Alternative out-of-band mechanisms may be designed to cover other transport protocols such as UDP.
o IDENT是特定于TCP的。可设计替代带外机制以覆盖其他传输协议，如UDP。
o This solution requires the address-sharing function to embed an IDENT server.
o 此解决方案需要地址共享功能来嵌入IDENT服务器。
o A hint should be provided to the ultimate server (or intermediate nodes) that the address-sharing function implements the IDENT protocol, for example, publishing this capability using DNS (other solutions can be envisaged).
o 应该向最终服务器（或中间节点）提供一个提示，说明地址共享功能实现了IDENT协议，例如，使用DNS发布此功能（可以设想其他解决方案）。
o An out-of-band mechanism may require some administrative setup (e.g., contract agreement) between the entity managing the address-sharing function and the entity managing the remote server. Such a deployment is not feasible in the Internet at large because establishing and maintaining agreements between ISPs and all service actors is burdensome and not scalable.
o 带外机制可能需要在管理地址共享功能的实体和管理远程服务器的实体之间进行一些管理设置（例如，合同协议）。这种部署在整个互联网上是不可行的，因为在ISP和所有服务参与者之间建立和维护协议既繁重又不可扩展。
o Implementations requiring delay of the establishment of a session until receipt of the companion IDENT response may lead to some user-experience degradation.
o 需要延迟建立会话直到接收到伴随的IDENT响应的实现可能会导致某些用户体验降低。
o The IDENT proposal will add traffic overhead for both the server and the address-sharing device.
o IDENT方案将增加服务器和地址共享设备的通信开销。
o Performance degradation is likely to be experienced by address-sharing functions embedding the IDENT server. This is further exacerbated if the address-sharing function has to handle an IDENT query for each new instantiated mapping (even if the mapping exists).
o 嵌入IDENT服务器的地址共享功能可能会导致性能下降。如果地址共享函数必须为每个新的实例化映射（即使映射存在）处理一个IDENT查询，则情况会进一步恶化。
o In some scenarios (e.g., Section 3 of [REVEAL-PCP]), the HOST_ID should be interpreted by intermediate devices that embed Policy Enforcement Points (PEP) [RFC2753] responsible for granting access to some services. These PEPs need to inspect all received packets in order to generate the companion IDENT queries. This may induce more complexity to these intermediate devices.
o 在某些情况下（例如，[REVEL-PCP]第3节），主机ID应由嵌入策略实施点（PEP）[RFC2753]的中间设备来解释，这些设备负责授予对某些服务的访问权。这些PEP需要检查所有接收到的数据包，以便生成伴随的IDENT查询。这可能导致这些中间设备更加复杂。
o IDENT queries may be generated by illegitimate TCP servers. This would require the address-sharing function to enforce some policies (e.g., rate-limit queries, filter based on the source IP address, etc.).
o 识别查询可能由非法的TCP服务器生成。这将需要地址共享功能强制执行某些策略（例如，速率限制查询、基于源IP地址的过滤器等）。
Table 1 summarizes the approaches analyzed in this document.
表1总结了本文件中分析的方法。
+-----+------+------+------+-----+-----+-----+-----+-----+
|IP-ID| IP | TCP |HTTP |PROXY|Port | HIP |ICMP |IDENT|
| |Option|Option|Header| | Set | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
UDP | Yes | Yes | No | No | No | Yes | | Yes | No |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
TCP | Yes | Yes | Yes | No | Yes | Yes | | Yes | Yes |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
HTTP | Yes | Yes | Yes | Yes | Yes | Yes | | Yes | Yes |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Encrypted | Yes | Yes | Yes | No | Yes | Yes | | Yes | Yes |
Traffic | | | | | | | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Success | High| Low | High | High | Low | 100%|Low |High |High |
Ratio | | | | | | | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Possible | Low | High | Low | Med | High| No | N/A | High|High |
Perf | to | | to | to | | | | | |
Impact | Med | | Med | High | | | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
OS TCP/IP | Yes | Yes | Yes | No | No | No | | Yes | Yes |
Modif | | | | | | | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Deployable| Yes | Yes | Yes | Yes | No | Yes | No | Yes | Yes |
Today | | | | | | | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Notes | (1) | (8) | (8) | (2) | (8) | (1) | (4) | (6) | (1) |
| (7) | | | | | (3) | (7) | (8) | (6) |
| | | | | | | | | (8) |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
+-----+------+------+------+-----+-----+-----+-----+-----+
|IP-ID| IP | TCP |HTTP |PROXY|Port | HIP |ICMP |IDENT|
| |Option|Option|Header| | Set | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
UDP | Yes | Yes | No | No | No | Yes | | Yes | No |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
TCP | Yes | Yes | Yes | No | Yes | Yes | | Yes | Yes |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
HTTP | Yes | Yes | Yes | Yes | Yes | Yes | | Yes | Yes |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Encrypted | Yes | Yes | Yes | No | Yes | Yes | | Yes | Yes |
Traffic | | | | | | | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Success | High| Low | High | High | Low | 100%|Low |High |High |
Ratio | | | | | | | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Possible | Low | High | Low | Med | High| No | N/A | High|High |
Perf | to | | to | to | | | | | |
Impact | Med | | Med | High | | | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
OS TCP/IP | Yes | Yes | Yes | No | No | No | | Yes | Yes |
Modif | | | | | | | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Deployable| Yes | Yes | Yes | Yes | No | Yes | No | Yes | Yes |
Today | | | | | | | | | |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Notes | (1) | (8) | (8) | (2) | (8) | (1) | (4) | (6) | (1) |
| (7) | | | | | (3) | (7) | (8) | (6) |
| | | | | | | | | (8) |
----------+-----+------+------+------+-----+-----+-----+-----+-----+
Table 1: Summary of Analyzed Solutions
表1：分析的解决方案汇总
o "Encrypted Traffic" refers to TLS. The use of IPsec and its complications traversing NATs are discussed in Section 2.2 of [RFC6889]. Similar to what is suggested in Section 13.5 of [RFC6269], HOST_ID specification document(s) should analyze the compatibility of each IPsec mode in detail.
o “加密流量”指TLS。[RFC6889]第2.2节讨论了IPsec的使用及其穿越NAT的复杂性。与[RFC6269]第13.5节中的建议类似，主机ID规范文件应详细分析每个IPsec模式的兼容性。
o "Success ratio" indicates the ratio of successful communications with remote servers when the HOST_ID is injected using a proposed solution. More details are provided below to explain how the success ratio is computed for each proposed solution.
o “成功率”表示使用建议的解决方案注入主机ID时与远程服务器成功通信的比率。下文提供了更多详细信息，以解释如何计算每个拟议解决方案的成功率。
o "Possible Perf Impact" indicates the level of expected performance degradation. The indicated degradation is an estimate based on the need for processing at the IP layer.
o “可能的性能影响”表示预期性能下降的程度。指示的退化是基于IP层处理需求的估计。
o "OS TCP/IP Modif" indicates whether a modification of the OS TCP/IP stack is required at the server side.
o “OS TCP/IP Modif”表示是否需要在服务器端修改OS TCP/IP堆栈。
o "Deployable today" indicates if the solution can be generalized without any constraint on current architectures and practices.
o “今天可部署”表示该解决方案是否可以在不受当前体系结构和实践限制的情况下通用化。
Notes: (1) Requires mechanism to advertise that NAT is participating in this scheme (e.g., DNS PTR record). (2) This solution is widely deployed (e.g., HTTP severs, load balancers, etc.). (3) When the port set is not advertised, the solution is less efficient for third-party services. (4) Requires that the client and the server to be HIP-compliant and that HIP infrastructure be deployed. If the client and the server are HIP-enabled, the address-sharing function does not need to insert an identifier. If the client is not HIP-enabled, designing the device that performs address sharing to act as a UDP/TCP-HIP relay is not viable. (6) The solution is inefficient in some scenarios (see Section 5). (7) The solution is a theoretical construct (i.e., the solution is not documented). (8) The solution is a documented proposal.
注意：（1）需要公布NAT正在参与此方案的机制（例如，DNS PTR记录）。（2） 此解决方案被广泛部署（例如HTTP服务器、负载平衡器等）。（3） 如果未公布端口集，则解决方案对于第三方服务的效率较低。（4） 要求客户端和服务器与HIP兼容，并部署HIP基础架构。如果客户端和服务器已启用HIP，则地址共享功能不需要插入标识符。如果客户端未启用HIP，则设计执行地址共享的设备作为UDP/TCP-HIP中继是不可行的。（6） 在某些情况下，解决方案效率低下（参见第5节）。（7） 该解决方案是一种理论结构（即，该解决方案未记录在案）。（8） 该解决方案是一个记录在案的提案。
Provided success ratio figures for TCP and IP options are based on the results documented in [Options] and [REVEAL-TCP-EXP].
提供的TCP和IP选项的成功率数字基于[options]和[REVEAL-TCP-EXP]中记录的结果。
The provided success ratio for the IP-ID is theoretical; it assumes the address-sharing function follows the rules (see [RFC6864])to rewrite the IP Identification field.
为IP-ID提供的成功率是理论上的；它假设地址共享函数遵循规则（请参见[RFC6864]）重写IP标识字段。
Since PROXY and HIP are not widely deployed, the success ratio for establishing communication with remote servers using these protocols is low.
由于未广泛部署代理和HIP，因此使用这些协议与远程服务器建立通信的成功率较低。
The success ratio for the ICMP-based solution is implementation specific, but it is likely to be close to 100%. The success ratio depends on how efficiently the solution is implemented on the server side. A remote server that does not support the ICMP-based solution will ignore received companion ICMP messages. An upgraded server will need to delay the acceptance of a session until it receives the companion ICMP message.
基于ICMP的解决方案的成功率取决于具体实现，但可能接近100%。成功率取决于解决方案在服务器端实现的效率。不支持基于ICMP的解决方案的远程服务器将忽略收到的伴随ICMP消息。升级后的服务器需要延迟会话的接受，直到它收到伴随的ICMP消息。
The success ratio for the IDENT solution is implementation specific but it is likely to be close to 100%. The success ratio depends on how efficient the solution is implemented on the server side. A remote server that does not support IDENT will accept a session establishment request following its normal operation. An upgraded server will need to delay the acceptance of a session until it receives a response to the IDENT request it will send to the host.
IDENT解决方案的成功率取决于具体实现，但可能接近100%。成功率取决于解决方案在服务器端实现的效率。不支持IDENT的远程服务器将在正常操作后接受会话建立请求。升级后的服务器需要延迟会话的接受，直到它收到对它将发送给主机的标识请求的响应。
The provided success ratio for the Port Set and HTTP header solutions is 100% because no additional Layer 3 or Layer 4 field is needed to convey HOST_ID for these solutions.
为端口集和HTTP头解决方案提供的成功率为100%，因为不需要额外的第3层或第4层字段来传递这些解决方案的主机ID。
If the server trusts the content of the HOST_ID field, a third-party user can be impacted by a misbehaving user revealing a "faked" HOST_ID (e.g., original IP address). This same security concern applies for the injection of an IP option, TCP option, and application-related content (e.g., the Forwarded HTTP header) by the address-sharing device.
如果服务器信任HOST_ID字段的内容，第三方用户可能会受到行为不端的用户泄露“伪造”HOST_ID（例如，原始IP地址）的影响。同样的安全问题也适用于地址共享设备注入IP选项、TCP选项和与应用程序相关的内容（例如，转发的HTTP头）。
The HOST_ID may be used to leak information about the internal structure of a network behind an address-sharing function. If this behavior is undesired for the network administrator, the address-sharing function can be configured to strip any existing HOST_ID in received packets from internal hosts.
主机ID可用于泄漏地址共享功能背后的网络内部结构信息。如果网络管理员不希望出现这种行为，则可以将地址共享功能配置为剥离从内部主机接收的数据包中的任何现有主机ID。
HOST_ID specification documents should elaborate further on threats inherent to each individual solution used to convey the HOST_ID (e.g., use of the IP-ID field to count hosts behind a NAT [Count]).
HOST_ID规范文件应进一步阐述用于传输HOST_ID的每个单独解决方案固有的威胁（例如，使用IP-ID字段对NAT后面的主机进行计数）。
For more discussion of privacy issues related to the HOST_ID, see Section 3.
有关与主机ID相关的隐私问题的更多讨论，请参阅第3节。
Many thanks to D. Wing, C. Jacquenet, J. Halpern, B. Haberman, and P. Yee for their review, comments, and inputs.
非常感谢D.Wing、C.Jacquenet、J.Halpern、B.Haberman和P.Yee的审查、评论和投入。
Thanks also to P McCann, T. Tsou, Z. Dong, B. Briscoe, T. Taylor, M. Blanchet, D. Wing, and A. Yourtchenko for the discussions in Prague.
还感谢P.McCann、T.Tsou、Z.Dong、B.Briscoe、T.Taylor、M.Blanchet、D.Wing和A.Yourtchenko在布拉格的讨论。
Some of the issues related to defining a new TCP option have been raised by L. Eggert.
L.Eggert提出了一些与定义新TCP选项相关的问题。
The privacy text was provided by A. Cooper.
隐私文本由A.Cooper提供。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[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月。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.
[RFC6056]Larsen，M.和F.Gont，“传输协议端口随机化建议”，BCP 156，RFC 6056，2011年1月。
[Count] Belloven, S., "A Technique for Counting NATted Hosts", <http://www.cs.columbia.edu/~smb/papers/fnat.pdf>.
[Count]Belloven，S.，“计算NATED主机的技术”<http://www.cs.columbia.edu/~smb/papers/fnat.pdf>。
[DETERMCGN] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", Work in Progress, January 2013.
[DETERMCGN]Donley，C.，Grundemann，C.，Sarawat，V.，Sundaresan，K.，和O.Vautrin，“确定性地址映射以减少运营商级NAT部署中的日志记录”，正在进行的工作，2013年1月。
[ExtendTCP] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M. and H. Tokuda,, "Is It Still Possible to Extend TCP?", November 2011, <http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf>.
[ExtendeDTCP]本田，M.，西田，Y.，雷丘，C.，格林豪尔，A.，汉德利，M.和H.德田，，“是否仍有可能延长TCP？”，2011年11月<http://nrg.cs.ucl.ac.uk/mjh/tmp/mboxes.pdf>.
[FASTOPEN] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", Work in Progress, February 2013.
[FASTOPEN]Cheng，Y.，Chu，J.，Radhakrishnan，S.，和A.Jain，“TCP快速开放”，正在进行的工作，2013年2月。
[HTTP-FRWD] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", Work in Progress, October 2012.
[HTTP-FRWD]Peterson，A.和M.Nilsson，“转发的HTTP扩展”，正在进行的工作，2012年10月。
[IAB-PRIVACY] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", Work in Progress, July 2012.
[IAB-隐私]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，正在进行的工作，2012年7月。
[IPFIX-NAT] Sivakumar, S. and R. Penno, "IPFIX Information Elements for Logging NAT Events", Work in Progress, March 2013.
[IPFIX-NAT]Sivakumar，S.和R.Penno，“用于记录NAT事件的IPFIX信息元素”，正在进行的工作，2013年3月。
[Not_An_Option] R. Fonseca, G. Porter, R. Katz, S. Shenker, and I. Stoica,, "IP Options Are Not An Option", 2005, <http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/ EECS-2005-24.html>.
[Not_An_Option]R.Fonseca，G.Porter，R.Katz，S.Shenker和I.Stoica，“知识产权期权不是期权”，2005年<http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/ EECS-2005-24.html>。
[Options] Medina, A, Allman, M. and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", 2005, <http://conferences.sigcomm.org/imc/2004/papers/ p336-medina.pdf>.
[选项]Medina，A，Allman，M.和S.Floyd，“测量传输协议和中间盒之间的相互作用”，2005年<http://conferences.sigcomm.org/imc/2004/papers/ p336 medina.pdf>。
[Proxy] Tarreau, W., "The PROXY protocol", November 2010, <http://haproxy.1wt.eu/download/1.5/doc/ proxy-protocol.txt>.
[代理]Tarreau，W.，“代理协议”，2010年11月<http://haproxy.1wt.eu/download/1.5/doc/ proxy protocol.txt>。
[REVEAL-ICMP] Yourtchenko, A., "Revealing Hosts Sharing An IP Address Using ICMP Echo Request", Work in Progress, March 2012.
[REVEL-ICMP]Yourtchenko，A.，“使用ICMP回送请求显示共享IP地址的主机”，正在进行的工作，2012年3月。
[REVEAL-IP] Wu, Y., Ji, H., Chen, Q., and T. ZOU), "IPv4 Header Option For User Identification In CGN Scenario", Work in Progress, March 2011.
[REVEAL-IP]吴玉英、季、H、陈、Q和T.邹，“CGN场景中用于用户识别的IPv4报头选项”，正在进行的工作，2011年3月。
[REVEAL-PCP] Boucadair, M., Reddy, T., Patil, P., and D. Wing, "Using PCP to Reveal a Host behind NAT", Work in Progress, November 2012.
[REVEAL-PCP]Boucadair，M.，Reddy，T.，Patil，P.，和D.Wing，“使用PCP揭示NAT背后的主机”，正在进行的工作，2012年11月。
[REVEAL-TCP-EXP] Abdo, E., Boucadair, M., and J. Queiroz, "HOST_ID TCP Options: Implementation & Preliminary Test Results", Work in Progress, July 2012.
[REVEAL-TCP-EXP]Abdo，E.，Boucadair，M.和J.Queiroz，“主机ID TCP选项：实施和初步测试结果”，正在进行的工作，2012年7月。
[REVEAL-TCP] Yourtchenko, A. and D. Wing, "Revealing Hosts Sharing An IP Address Using TCP Option", Work in Progress, December 2011.
[REVEAL-TCP]Yourtchenko，A.和D.Wing，“使用TCP选项显示共享IP地址的主机”，正在进行的工作，2011年12月。
[RFC1413] St. Johns, M., "Identification Protocol", RFC 1413, February 1993.
[RFC1413]圣约翰，M.，“识别协议”，RFC14131993年2月。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753]Yavatkar，R.，Pendarakis，D.，和R.Guerin，“基于政策的准入控制框架”，RFC 2753，2000年1月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]福特，M.，布卡达尔，M.，杜兰德，A.，利维斯，P.，和P.罗伯茨，“IP地址共享问题”，RFC 6269，2011年6月。
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011.
[RFC6302]Durand，A.，Gashinsky，I.，Lee，D.，和S.Sheppard，“面向Internet服务器的日志记录建议”，BCP 162，RFC 6302，2011年6月。
[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, August 2011.
[RFC6346]Bush，R.，“IPv4地址短缺的地址加端口（A+P）方法”，RFC 6346，2011年8月。
[RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", RFC 6462, January 2012.
[RFC6462]Cooper，A.，“互联网隐私研讨会报告”，RFC 6462，2012年1月。
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", RFC 6864, February 2013.
[RFC6864]Touch，J.，“IPv4 ID字段的更新规范”，RFC 6864，2013年2月。
[RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, "Analysis of Stateful 64 Translation", RFC 6889, April 2013.
[RFC6889]Penno，R.，Saxena，T.，Boucadair，M.，和S.Sivakumar，“有状态64翻译的分析”，RFC 6889，2013年4月。
[SYSLOG-NAT] Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog Format for NAT Logging", Work in Progress, May 2013.
[SYSLOG-NAT]Chen，Z.，Zhou，C.，Tsou，T.，和T.Taylor，“NAT日志记录的SYSLOG格式”，正在进行的工作，2013年5月。
[TOR] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The secondgeneration onion router", In Proceedings of the 13th USENIX Security Symposium, August 2004.
[TOR]丁莱丁，R.，马修森，N.，和P.塞弗森，“TOR:第二代洋葱路由器”，第13届USENIX安全研讨会论文集，2004年8月。
[Trusted_ISPs] Wikimedia, "Trusted XFF List", May 2013, <http://meta.wikimedia.org/w/ index.php?title=XFF_project&oldid=5507690>.
[Trusted_ISP]Wikimedia，“Trusted XFF List”，2013年5月<http://meta.wikimedia.org/w/ index.php？title=XFF_project&oldid=5507690>。
Authors' Addresses
作者地址
Mohamed Boucadair France Telecom Rennes 35000 France
穆罕默德·布卡达尔法国电信雷恩35000法国
EMail: mohamed.boucadair@orange.com
EMail: mohamed.boucadair@orange.com
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 United States
Joe Touch USC/ISI 4676美国加利福尼亚州玛丽娜·德雷海军部路90292-6695号
Phone: +1 (310) 448-9151
EMail: touch@isi.edu
Phone: +1 (310) 448-9151
EMail: touch@isi.edu
Pierre Levis France Telecom Caen 14000 France
皮埃尔·列维斯法国电信卡昂14000法国
EMail: pierre.levis@orange.com
EMail: pierre.levis@orange.com
Reinaldo Penno Cisco United States
美国思科公司
EMail: repenno@cisco.com
EMail: repenno@cisco.com