Independent Submission B. Williams
Request for Comments: 7974 Akamai, Inc.
Category: Informational M. Boucadair
ISSN: 2070-1721 Orange
D. Wing
October 2016
Independent Submission B. Williams
Request for Comments: 7974 Akamai, Inc.
Category: Informational M. Boucadair
ISSN: 2070-1721 Orange
D. Wing
October 2016
An Experimental TCP Option for Host Identification
一种用于主机识别的实验性TCP选项
Abstract
摘要
Recent RFCs have discussed issues with host identification in IP address-sharing systems, such as address/prefix-sharing devices and application-layer proxies. Potential solutions for revealing a host identifier in shared address deployments have also been discussed. This memo describes the design, deployment, and privacy considerations for one such solution in operational use on the Internet today that uses a TCP option to transmit a host identifier.
最近的RFC讨论了IP地址共享系统中的主机标识问题，如地址/前缀共享设备和应用层代理。还讨论了在共享地址部署中显示主机标识符的潜在解决方案。本备忘录描述了目前在Internet上使用的一种此类解决方案的设计、部署和隐私注意事项，该解决方案使用TCP选项传输主机标识符。
Independent Submissions Editor Note
独立意见书编者注
This Informational document specifies an experimental TCP HOST_ID option that is already fairly widely deployed. It discusses that option's privacy considerations in considerable detail and highlights the care providers need to exercise in any actual deployment. The Independent Submissions Editor has chosen to publish this document in the Independent Stream so that potential deployers and implementors can understand all its details, so as to produce implementations that will interwork properly with other (existing) deployments.
此信息性文档指定了一个已经广泛部署的实验性TCP主机ID选项。它相当详细地讨论了该选项的隐私注意事项，并强调了护理提供者在任何实际部署中需要执行的操作。独立提交编辑器选择在独立流中发布此文档，以便潜在的部署人员和实现人员能够了解其所有详细信息，从而生成能够与其他（现有）部署正常交互的实现。
IESG Note
IESG注释
This proposal was previously proposed for adoption by the TCPM working group and rejected as being an undesirable technical design for both transport and privacy reasons. This document specifies a new TCP option that uses the shared experimental options format. The use of experimental TCP options is specified in [RFC6994] for TCP options "that are not yet eligible for assigned codepoints". As this proposal has been rejected by the IETF community, it is not eligible for the registration of a TCP option codepoint. It should be further noted that for experimental TCP options, it "is only appropriate to use these values in explicitly-configured experiments; they MUST NOT be shipped as defaults in implementations" [RFC4727]. The IESG also carried out a review as described in [RFC5742] and concluded that this proposal violates IETF principles expressed in [RFC7258] about pervasive monitoring as an attack and should therefore not be published without IETF review and IESG approval. (The process
该提案之前已被TCPM工作组提议采用，但由于运输和隐私原因，该提案被视为不可取的技术设计而予以拒绝。本文档指定了一个使用共享实验选项格式的新TCP选项。[RFC6994]中对“尚未符合指定代码点条件”的TCP选项规定了实验性TCP选项的使用。由于该提案已被IETF社区拒绝，因此不符合注册TCP选项代码点的资格。应该进一步注意的是，对于实验性TCP选项，“只适合在显式配置的实验中使用这些值；它们不能作为默认值在实现中提供”[RFC4727]。IESG还进行了[RFC5742]中所述的审查，并得出结论，该提案违反了[RFC7258]中所述的IETF原则，即普遍监控是一种攻击，因此未经IETF审查和IESG批准，不得发布。（a）过程
described in [RFC5742] nonetheless allows the Independent Submissions Editor to publish, as has been chosen in this case.) Deployments of this proprietary TCP option may be widely viewed as undermining privacy and are likely to encounter issues with reliability of transport.
尽管如此，[RFC5742]中所述允许独立提交编辑器发布（本例中已选择了该选项。）此专有TCP选项的部署可能被广泛视为破坏隐私，并可能遇到传输可靠性问题。
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 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第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/rfc7974.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7974.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 ....................................................4
1.1. Important Use Cases ........................................4
1.2. Document Goals .............................................6
2. Terminology .....................................................6
3. Option Format ...................................................7
4. Option Use ......................................................7
4.1. Option Values ..............................................7
4.2. Sending Host Requirements ..................................9
4.2.1. Alternative SYN Cookie Support ......................9
4.2.2. Persistent TCP Connections ..........................9
4.2.3. Packet Fragmentation ...............................10
4.3. Multiple In-Path HOST_ID Senders ..........................10
5. Option Interpretation ..........................................11
6. Interaction with Other TCP Options .............................12
6.1. Multipath TCP (MPTCP) .....................................12
6.2. Authentication Option (TCP-AO) ............................12
6.3. TCP Fast Open (TFO) .......................................13
7. Security Considerations ........................................13
8. Privacy Considerations .........................................14
9. Pervasive Monitoring (PM) Considerations .......................15
10. IANA Considerations ...........................................16
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................17
Acknowledgements ..................................................20
Authors' Addresses ................................................20
1. Introduction ....................................................4
1.1. Important Use Cases ........................................4
1.2. Document Goals .............................................6
2. Terminology .....................................................6
3. Option Format ...................................................7
4. Option Use ......................................................7
4.1. Option Values ..............................................7
4.2. Sending Host Requirements ..................................9
4.2.1. Alternative SYN Cookie Support ......................9
4.2.2. Persistent TCP Connections ..........................9
4.2.3. Packet Fragmentation ...............................10
4.3. Multiple In-Path HOST_ID Senders ..........................10
5. Option Interpretation ..........................................11
6. Interaction with Other TCP Options .............................12
6.1. Multipath TCP (MPTCP) .....................................12
6.2. Authentication Option (TCP-AO) ............................12
6.3. TCP Fast Open (TFO) .......................................13
7. Security Considerations ........................................13
8. Privacy Considerations .........................................14
9. Pervasive Monitoring (PM) Considerations .......................15
10. IANA Considerations ...........................................16
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................17
Acknowledgements ..................................................20
Authors' Addresses ................................................20
A broad range of issues associated with address sharing have been documented in [RFC6269] and [RFC7620]. In addition, [RFC6967] provides an analysis of various solutions to the problem of revealing the sending host's identifier (HOST_ID) information to the receiver, indicating that a solution using a TCP [RFC793] option for this purpose is among the possible approaches that could be applied with limited performance impact and a high success ratio. The purpose of this memo is to describe a TCP HOST_ID option that is currently deployed on the public Internet using the TCP experimental option codepoint, including discussion of related design, deployment, and privacy considerations.
[RFC6269]和[RFC7620]中记录了与地址共享相关的广泛问题。此外，[RFC6967]提供了对向接收器显示发送主机标识符（主机ID）信息问题的各种解决方案的分析，表明为此目的使用TCP[RFC793]选项的解决方案是可应用的性能影响有限且成功率高的可能方法之一。本备忘录旨在描述当前使用TCP实验选项代码点部署在公共互联网上的TCP主机ID选项，包括相关设计、部署和隐私注意事项的讨论。
Multiple documents have defined TCP options for the purpose of host identification: [REVEAL], [HOSTID], and [OVERLAYPATH]. Specification of multiple option formats to serve the purpose of host identification increases the burden for potential implementers and presents interoperability challenges as well, so the authors of those documents have worked together to define a common TCP option that supersedes the formats from those three documents. This memo describes a version of that common TCP option format that is currently in use on the public Internet.
多个文档定义了用于主机标识的TCP选项：[显示]、[HOSTID]和[OverlyPath]。指定多种选项格式以用于主机标识的目的增加了潜在实施者的负担，也带来了互操作性挑战，因此这些文档的作者共同定义了一个通用TCP选项，以取代这三个文档中的格式。此备忘录描述了公共Internet上当前使用的通用TCP选项格式的一个版本。
The option defined in this memo uses the TCP experimental option codepoint sharing mechanism defined in [RFC6994]. One of the earlier specifications, [OVERLAYPATH], is associated with unauthorized use of a TCP option kind number, and moving to the TCP experimental option codepoint has allowed the authors of that document to correct their error.
本备忘录中定义的选项使用[RFC6994]中定义的TCP实验选项代码点共享机制。早期的一个规范[OverlyPath]与未经授权使用TCP选项种类号有关，移动到TCP实验选项代码点允许该文档的作者更正其错误。
The authors' implementations have primarily focused on the following address-sharing use cases in which currently deployed systems insert the HOST_ID option:
作者的实现主要关注以下地址共享用例，其中当前部署的系统插入主机ID选项：
Carrier-Grade NAT (CGN): As defined in [RFC6888], [RFC6333], and other sources, a CGN allows multiple hosts connected to the public Internet to share a single Internet routable IPv4 address. One important characteristic of the CGN use case is that it modifies IP packets in-path, but does not serve as the endpoint for the associated TCP connections.
运营商级NAT（CGN）：如[RFC6888]、[RFC6333]和其他来源中所定义，CGN允许连接到公共互联网的多个主机共享一个互联网可路由IPv4地址。CGN用例的一个重要特征是它修改路径中的IP数据包，但不作为相关TCP连接的端点。
Application Proxy: As defined in [RFC1919], an application proxy splits a TCP connection into two segments, serving as an endpoint for each of the connections and relaying data flows between the connections.
应用程序代理：如[RFC1919]中所定义，应用程序代理将TCP连接分成两段，作为每个连接的端点，并在连接之间中继数据流。
Overlay Network: An overlay network is an Internet-based system providing security, optimization, or other services for data flows that transit the system. A network-layer overlay will sometimes act much like a CGN, in that packets transit the system with NAT being applied at the edge of the overlay. A transport-layer or application-layer overlay [RFC3135] will typically act much like an application proxy, in that the TCP connection will be segmented with the overlay network serving as an endpoint for each of the TCP connections.
覆盖网络：覆盖网络是基于Internet的系统，为传输系统的数据流提供安全、优化或其他服务。网络层覆盖有时与CGN非常相似，因为数据包通过覆盖边缘应用NAT的系统传输。传输层或应用层覆盖[RFC3135]通常与应用程序代理非常相似，因为TCP连接将被分割，覆盖网络用作每个TCP连接的端点。
In this set of sender use cases, the TCP option is applied to an individual TCP packet either at the connection endpoint (e.g., an application proxy or a transport-layer overlay network) or at an address-sharing middlebox (e.g., a CGN or a network-layer overlay network). See Section 4 for additional details about the types of devices that add the option to a TCP packet, as well as existing limitations on use of the option when it is inserted by an address-sharing middlebox, including issues related to packet fragmentation.
在这组发送方用例中，TCP选项应用于连接端点（例如，应用程序代理或传输层覆盖网络）或地址共享中间盒（例如，CGN或网络层覆盖网络）处的单个TCP数据包。有关将选项添加到TCP数据包的设备类型的更多详细信息，以及由地址共享中间盒插入时使用该选项的现有限制，包括与数据包碎片相关的问题，请参见第4节。
The existing receiver use cases considered by this memo include the following:
本备忘录考虑的现有接收器用例包括：
o Differentiating between attack and non-attack traffic when the source of the attack is sharing an address with non-attack traffic.
o 当攻击源与非攻击流量共享地址时，区分攻击流量和非攻击流量。
o Application of per-subscriber policies for resource utilization, etc., when multiple subscribers are sharing a common address.
o 当多个订户共享一个公共地址时，为资源利用等应用每订户策略。
o Improving server-side load-balancing decisions by allowing the load for multiple clients behind a shared address to be assigned to different servers, even when session affinity is required at the application layer.
o 通过允许将共享地址后面的多个客户端的负载分配给不同的服务器，改进服务器端负载平衡决策，即使在应用层需要会话关联时也是如此。
In all of the above cases, differentiation between address-sharing clients is performed by a network function that does not process the application-layer protocol (e.g., HTTP) or the security protocol (e.g., TLS), because the action needs to be performed prior to decryption or parsing the application layer. Due to this, a solution implemented within the application layer or security protocol was considered unable to fully meet the receiver-side requirements. At the same time, as noted in [RFC6967], use of an IP option for this purpose has a low success rate. For these reasons, using a TCP option to deliver the host identifier was deemed by the authors to be an effective way to satisfy these specific use cases. See Section 5 for details about receiver-side interpretation of the option.
在上述所有情况下，地址共享客户端之间的区别由不处理应用层协议（例如HTTP）或安全协议（例如TLS）的网络功能来执行，因为操作需要在解密或解析应用层之前执行。因此，在应用层或安全协议中实现的解决方案被认为无法完全满足接收方需求。同时，如[RFC6967]所述，为此目的使用IP选项的成功率较低。出于这些原因，作者认为使用TCP选项交付主机标识符是满足这些特定用例的有效方法。有关该选项的接收器端解释的详细信息，请参见第5节。
Publication of this memo is intended to serve multiple purposes.
本备忘录的发布有多种目的。
First and foremost, this document intends to inform readers about a mechanism that is in broad use on the public Internet. The authors are each affiliated with companies that have implemented, tested, and/or deployed systems that use the HOST_ID option on the public Internet. Other systems might encounter packets that contain this TCP option, and this document is intended to help others understand the nature of the TCP option when it is encountered so they can make informed decisions about how to handle it.
首先，本文件旨在向读者介绍一种在公共互联网上广泛使用的机制。作者均隶属于在公共互联网上实施、测试和/或部署使用HOST_ID选项的系统的公司。其他系统可能会遇到包含此TCP选项的数据包，本文档旨在帮助其他系统在遇到此TCP选项时了解其性质，以便他们能够就如何处理它做出明智的决定。
The testing effort documented in [HOSTID] indicated that a TCP option could be used for host identification purposes without significant disruption of TCP connectivity to legacy servers and networks that do not support the option. It also showed how mechanisms available in existing TCP implementations could make use of such a TCP option for diagnostics and/or packet filtering. The authors' use of the TCP option on the public Internet has confirmed that it can be used effectively for our use cases, but it has also uncovered some interoperability issues associated with the option's use on the public Internet, especially regarding interactions with other TCP options that support new transport capability being specified within the IETF. Section 6 discusses those interactions and limitations and explains how our systems handle associated issues.
[HOSTID]中记录的测试工作表明，TCP选项可用于主机识别目的，而不会严重中断与不支持该选项的传统服务器和网络的TCP连接。它还展示了现有TCP实现中可用的机制如何利用这种TCP选项进行诊断和/或数据包过滤。作者在公共互联网上使用TCP选项证实了它可以有效地用于我们的用例，但也发现了一些与公共互联网上使用该选项相关的互操作性问题，特别是与支持IETF中指定的新传输能力的其他TCP选项的交互。第6节讨论了这些交互和限制，并解释了我们的系统如何处理相关问题。
Discussions within the IETF have raised privacy concerns about the option's use, especially in regard to pervasive monitoring risks. Existing uses of the option limit the nature of the HOST_ID values that are used and the systems that insert them in order to mitigate pervasive monitoring risks. Sections 8 and 9 discuss the authors' assessments of the privacy and monitoring impact of this TCP option in its current uses and suggest behavior for some external systems when the option is encountered. Continued discussion following publication of this memo is expected to allow further refinement of requirements related to the values used to populate the option and how those values can be interpreted by the receiver. There is a trade-off between providing the expected functionality to the receiver and protecting the privacy of the sender, and continued assessment will be necessary in order to find the right balance.
IETF内部的讨论引发了对该选项使用的隐私问题，特别是在普遍监控风险方面。该选项的现有用途限制了所用主机ID值的性质以及插入这些值的系统，以减轻普遍的监控风险。第8节和第9节讨论了作者对该TCP选项在当前使用中的隐私和监控影响的评估，并提出了遇到该选项时某些外部系统的行为建议。本备忘录发布后的持续讨论有望进一步细化与用于填充选项的值相关的要求，以及接收者如何解释这些值。在向接收者提供预期功能和保护发送者隐私之间存在权衡，为了找到正确的平衡，需要继续进行评估。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
When used for host identification, the TCP experimental option uses the experiment identification mechanism described in [RFC6994] and has the following format and content.
当用于主机标识时，TCP实验选项使用[RFC6994]中描述的实验标识机制，并具有以下格式和内容。
0 1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| Kind | Length | ExID |
+--------+--------+--------+--------+
| HOST_ID ...
+--------+---
0 1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| Kind | Length | ExID |
+--------+--------+--------+--------+
| HOST_ID ...
+--------+---
Kind: The option kind value is 253.
种类：选项种类值为253。
Length: The length of the option is variable, based on the required size of the host identifier (e.g., a 2-octet HOST_ID will require a length of 6, while a 4-octet HOST_ID will require a length of 8).
长度：选项的长度是可变的，取决于主机标识符所需的大小（例如，2个八位字节的主机ID需要长度为6，而4个八位字节的主机ID需要长度为8）。
ExID: The experiment ID value is 0x0348 (840).
ExID：实验ID值为0x0348（840）。
HOST_ID: The host identifier is a value that can be used to differentiate among the various hosts sharing a common public IP address. See below for further discussion of this value.
主机标识：主机标识是一个值，可用于区分共享公共IP地址的各种主机。有关此值的进一步讨论，请参见下文。
This section describes requirements associated with the use of the option, including expected option values, which hosts are allowed to include the option, and segments that include the option.
本节描述与选项使用相关的要求，包括预期选项值、允许哪些主机包含该选项以及包含该选项的段。
The information conveyed in the HOST_ID option is intended to uniquely identify the sending host to the best capability of the machine that adds the option to the segment, while at the same time avoiding inclusion of information that does not assist this purpose. In addition, the option is not intended to be used to expose information about the sending host that could not be discovered by observing segments in transit on some portion of the Internet path between the sender and the receiver. Existing use cases have different requirements for receiver-side functionality, so this document attempts to provide a high degree of flexibility for the machine that adds the option to TCP segments.
HOST_ID选项中传达的信息旨在唯一地识别发送主机，使其达到将选项添加到段的机器的最佳性能，同时避免包含不利于此目的的信息。此外，该选项不打算用于公开关于发送主机的信息，这些信息无法通过观察在发送方和接收方之间的因特网路径的某些部分上传输的段来发现。现有用例对接收方功能有不同的要求，因此本文档试图为向TCP段添加选项的机器提供高度的灵活性。
The HOST_ID option value MUST correlate to IP addresses and/or TCP port numbers that were changed by the inserting host/device (i.e., some of the IP address and/or port number bits are used to generate the HOST_ID). Example values that satisfy this requirement include the following:
HOST_ID选项值必须与插入的主机/设备更改的IP地址和/或TCP端口号相关（即，一些IP地址和/或端口号位用于生成HOST_ID）。满足此要求的示例值包括：
Unique ID: An inserting host/device could maintain a pool of locally unique ID values that are dynamically mapped to the unique source IP address values in use behind the host/device as a result of address sharing. This ID value would be meaningful only within the context of a specific shared IP address due to the local uniqueness characteristic. Such an ID value could be smaller than an IP address (e.g., 16 bits) in order to conserve TCP option space. This option is preferred because it does not increase IP address visibility on the forward side of the address-sharing system, and it SHOULD be used in cases where receiver-side requirements can be met without direct inclusion of the original IP address (e.g., some load-balancing uses).
唯一ID：插入的主机/设备可以维护一个本地唯一ID值池，这些值动态映射到由于地址共享而在主机/设备后面使用的唯一源IP地址值。由于本地唯一性特征，此ID值仅在特定共享IP地址的上下文中才有意义。这样的ID值可以小于IP地址（例如，16位），以节省TCP选项空间。此选项是首选的，因为它不会增加地址共享系统前端的IP地址可见性，并且应在不直接包含原始IP地址（例如，某些负载平衡使用）的情况下满足接收方要求的情况下使用。
IP Address/Subnet: An inserting host/device could simply populate the option value with the IP address value in use behind the host/ device. In the case of IPv6 addresses, it could be difficult to include the full address due to TCP option space constraints, so the value would likely need to provide only a portion of the address (e.g., the first 64 bits).
IP地址/子网：插入主机/设备可以简单地用主机/设备后面正在使用的IP地址值填充选项值。在IPv6地址的情况下，由于TCP选项空间限制，可能很难包含完整地址，因此该值可能只需要提供地址的一部分（例如，前64位）。
IP Address and TCP Port: Some networks share public IP addresses among multiple subscribers with a portion of the TCP port number space being assigned to each subscriber [RFC6346]. When such a system is behind an address-sharing host/device, inclusion of both the IP address and the TCP port number will more uniquely identify the sending host than just the IP address on its own.
IP地址和TCP端口：一些网络在多个订户之间共享公共IP地址，TCP端口号空间的一部分分配给每个订户[RFC6346]。当这样的系统位于地址共享主机/设备后面时，包含IP地址和TCP端口号将比仅包含IP地址本身更能唯一地标识发送主机。
When multiple host identifiers are necessary (e.g., an IP address and a port number), the HOST_ID option is included multiple times within the packet, once for each identifier. While this approach significantly increases option space utilization when multiple identifiers are included, cases where only a single identifier is included are expected to be more common; thus, it is beneficial to optimize for those cases. Note that some middleboxes might reorder TCP options, so this method could be problematic if such a middlebox is in-path between the address-sharing system and the receiver. This has not proven to be a problem for existing use cases.
当需要多个主机标识符（例如，IP地址和端口号）时，在分组中多次包括主机ID选项，每个标识符一次。当包含多个标识符时，这种方法显著提高了选项空间的利用率，但仅包含单个标识符的情况预计会更常见；因此，针对这些情况进行优化是有益的。请注意，某些中间盒可能会重新排序TCP选项，因此如果这样的中间盒位于地址共享系统和接收器之间的路径中，则此方法可能会出现问题。对于现有用例来说，这并不是一个问题。
See Section 8 for discussion of privacy considerations related to selection of HOST_ID values.
有关选择主机ID值的隐私注意事项的讨论，请参见第8节。
The HOST_ID option MUST only be added by the sending host or any device involved in the forwarding path that changes IP addresses and/ or TCP port numbers (e.g., NAT44 [RFC3022], L2-Aware NAT, DS-Lite Address Family Transition Router (AFTR) [RFC6333], IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296], NAT64 [RFC6146], Dual-Stack Extra Lite [RFC6619], TCP Proxy, etc.). The HOST_ID option MUST NOT be added or modified en route by any device that does not modify IP addresses and/or TCP port numbers.
主机ID选项只能由发送主机或涉及更改IP地址和/或TCP端口号的转发路径的任何设备添加（例如，NAT44[RFC3022]，L2感知NAT，DS Lite地址系列转换路由器（AFTR）[RFC6333]，IPv6到IPv6网络前缀转换（NPTv6）[RFC6296]，NAT64[RFC6146]，双栈额外精简[RFC6619]，TCP代理等）。任何不修改IP地址和/或TCP端口号的设备不得在路由过程中添加或修改主机ID选项。
The sending host or intermediary device cannot determine whether the option value is used in a stateful manner by the receiver, nor can it determine whether SYN cookies are in use by the receiver. For this reason, the option MUST be included in all segments, both SYN and non-SYN segments, until return segments from the receiver positively indicate that the TCP connection is fully established on the receiver (e.g., the return segment either includes or acknowledges data).
发送主机或中间设备无法确定接收方是否以有状态方式使用选项值，也无法确定接收方是否正在使用SYN cookies。因此，该选项必须包含在所有段中，包括SYN段和非SYN段，直到来自接收器的返回段明确表示TCP连接已在接收器上完全建立（例如，返回段包含或确认数据）。
The authors have also considered an alternative approach to SYN cookie support in which the receiving host (i.e., the host that accepts the TCP connection) echoes the option back to the sender in the SYN/ACK segment when a SYN cookie is being sent. This would allow the host sending HOST_ID to determine whether further inclusion of the option is necessary. This approach would have the benefit of not requiring inclusion of the option in non-SYN segments if SYN cookies had not been used. Unfortunately, this approach fails if the responding host itself does not support the option, since an intermediate node would have no way to determine that SYN cookies had been used.
作者还考虑了SYN cookie支持的另一种方法，即接收主机（即接受TCP连接的主机）在发送SYN cookie时，将选项回显到SYN/ACK段中的发送方。这将允许发送主机ID的主机确定是否需要进一步包含该选项。如果没有使用SYN Cookie，这种方法的好处是不需要在非SYN段中包含该选项。不幸的是，如果响应主机本身不支持该选项，这种方法将失败，因为中间节点将无法确定是否使用了SYN cookies。
Some types of middleboxes (e.g., application proxy) open and maintain persistent TCP connections to regularly visited destinations in order to minimize the burden of connection establishment. Such middleboxes might use a single persistent TCP connection for multiple different client hosts over the life of the persistent connection.
某些类型的中间盒（例如，应用程序代理）打开并维护到定期访问的目的地的持久TCP连接，以便将建立连接的负担降至最低。在持久连接的生命周期内，此类中间盒可能会对多个不同的客户端主机使用一个持久TCP连接。
This specification does not attempt to support the use of persistent TCP connections for multiple client hosts due to the perceived complexity of providing such support. Instead, the HOST_ID option is only allowed to be used at connection initiation. An inserting host/ device that supports both the HOST_ID option and multi-client persistent TCP connections MUST NOT apply the HOST_ID option to TCP connections that could be used for multiple clients over the life of
由于提供这种支持的复杂性，本规范不试图支持对多个客户端主机使用持久TCP连接。相反，仅允许在连接启动时使用HOST_ID选项。同时支持host_ID选项和多客户端持久TCP连接的插入主机/设备不得将host_ID选项应用于在其生命周期内可用于多个客户端的TCP连接
the connection. If the HOST_ID option was sent during connection initiation, the inserting host/device MUST NOT reuse the connection for data flows originating from a client that would require a different HOST_ID value.
连接。如果HOST_ID选项是在连接启动期间发送的，则插入的主机/设备不得对源自需要不同HOST_ID值的客户端的数据流重新使用连接。
In order to avoid the overhead associated with in-path IP fragmentation, it is desirable for the inserting host/device to avoid including the HOST_ID option when IP fragmentation might be required. This is not a firm requirement though, because the HOST_ID option is only included in the first few packets of a TCP connection; thus, associated IP fragmentation will generally have minimal impact. The option SHOULD NOT be included in packets if the resulting packet would require local fragmentation.
为了避免与路径内IP分段相关联的开销，当可能需要IP分段时，插入主机/设备希望避免包括主机ID选项。但这不是一个严格的要求，因为HOST_ID选项只包含在TCP连接的前几个数据包中；因此，相关的IP碎片通常影响最小。如果生成的数据包需要本地碎片，则该选项不应包含在数据包中。
It can be difficult to determine whether local fragmentation would be required. For example, in cases where multiple interfaces with different MTUs are in use, a local routing decision has to be made before the MTU can be determined, and in some systems, this decision could be made after TCP option handling is complete. Additionally, it could be true that inclusion of the option causes the packet to violate the path's MTU but the path's MTU has not been learned yet on the sending host/device.
很难确定是否需要局部碎片化。例如，在使用具有不同MTU的多个接口的情况下，必须在确定MTU之前做出本地路由决策，并且在某些系统中，可以在TCP选项处理完成后做出此决策。此外，包含该选项可能会导致数据包违反路径的MTU，但发送主机/设备上尚未学习路径的MTU。
In existing deployed systems, the impact of IP fragmentation that results from use of the option has been minimal.
在现有部署的系统中，由于使用该选项而导致的IP碎片化的影响最小。
The possibility exists that there could be multiple in-path hosts/ devices configured to insert the HOST_ID option. For example, the client's TCP packets might first traverse a CGN device on their way to the edge of a public Internet overlay network. In order for the HOST_ID value to most uniquely identify the sender, it needs to represent both the identity observed by the CGN device (the subscriber's internal IP address, e.g., Shared Address Space [RFC6598]) and the identity observed by the overlay network (the shared address of the CGN device). The mechanism for handling the received HOST_ID value could vary depending upon the nature of the new HOST_ID value to be inserted, as described below.
可能存在多个配置为插入主机ID选项的路径内主机/设备。例如，客户机的TCP数据包可能首先在到达公共Internet覆盖网络边缘的途中穿过CGN设备。为了使HOST_ID值最唯一地标识发送方，它需要表示CGN设备观察到的身份（订户的内部IP地址，例如共享地址空间[RFC6598]）和覆盖网络观察到的身份（CGN设备的共享地址）。根据要插入的新主机ID值的性质，处理接收到的主机ID值的机制可能会有所不同，如下所述。
The problem of multiple in-path HOST_ID senders has not been observed in existing deployed systems. For this reason, existing implementations do not consistently support this scenario. Some systems do not propagate forward the received HOST_ID option value in any way, while other systems follow the guidance described below.
在现有部署的系统中未发现多个路径内主机ID发送者的问题。因此，现有的实现并不一致地支持这种场景。一些系统不会以任何方式转发接收到的主机ID选项值，而其他系统则遵循下面描述的指导。
An inserting host/device that uses the received packet's source IP address as the HOST_ID value (possibly along with the port) MUST propagate forward the HOST_ID value(s) from the received packet, since the source IP address and port only represent the previous in-path address-sharing device and do not represent the original sender. In the CGN-plus-overlay example, this means that the overlay will include both the CGN's HOST_ID value(s) and a HOST_ID with the source IP address received by the overlay.
使用接收到的数据包的源IP地址作为主机ID值（可能与端口一起）的插入主机/设备必须从接收到的数据包转发主机ID值，因为源IP地址和端口仅代表先前的路径内地址共享设备，而不代表原始发送方。在CGN plus覆盖示例中，这意味着覆盖将包括CGN的主机ID值和覆盖接收到的源IP地址的主机ID。
An inserting host/device that sends a unique ID (as described in Section 4.1) has two options for how to handle the HOST_ID value(s) from the received packet:
发送唯一ID（如第4.1节所述）的插入主机/设备有两个选项，用于处理来自接收数据包的主机ID值：
1. A host/device that sends a unique ID MAY strip the received HOST_ID option and insert its own option, provided that it uses the received HOST_ID value as a differentiator for selecting the unique ID. What this means in the CGN-plus-overlay example above is that the overlay is allowed to drop the HOST_ID value inserted by the CGN provided that the HOST_ID value selected by the overlay represents both the CGN itself and the HOST_ID value inserted by the CGN.
1. 发送唯一ID的主机/设备可以剥离接收到的主机ID选项并插入自己的选项，前提是它使用收到的主机ID值作为选择唯一ID的区分符。这在上面的CGN plus覆盖示例中意味着，如果覆盖选择的主机ID值表示CGN本身和插入的主机ID值，则允许覆盖删除CGN插入的主机ID值由CGN提供。
2. A host/device that sends a unique ID MAY instead select a unique ID that represents only the previous in-path address-sharing host/device and propagate forward the HOST_ID value inserted by the previous host/device. In the CGN-plus-overlay example, this means that the overlay would include both the CGN's HOST_ID value and a HOST_ID with a unique ID of its own that was selected to represent the CGN's shared address.
2. 发送唯一ID的主机/设备可以选择一个唯一ID，该ID仅表示前一个路径内地址共享主机/设备，并转发前一个主机/设备插入的主机ID值。在CGN plus覆盖示例中，这意味着覆盖将包括CGN的主机ID值和主机ID，主机ID具有自己的唯一ID，该ID被选择来表示CGN的共享地址。
An inserting host/device that sends a unique ID MUST use one of the above two mechanisms.
发送唯一ID的插入主机/设备必须使用上述两种机制之一。
Due to the variable nature of the option value, it is not possible for the receiving machine to reliably determine the value type from the option itself. For this reason, a receiving host/device SHOULD interpret the option value as an opaque identifier.
由于期权价值的可变性质，接收机器无法从期权本身可靠地确定价值类型。因此，接收主机/设备应将选项值解释为不透明标识符。
This specification allows the inserting host/device to provide multiple HOST_ID options. The order of appearance of TCP options could be modified by some middleboxes, so receivers SHOULD NOT rely on option order to provide additional meaning to the individual options. Instead, when multiple HOST_ID options are present, their values SHOULD be concatenated together in the order in which they appear in the packet and treated as a single large identifier.
此规范允许插入主机/设备提供多个主机ID选项。TCP选项的出现顺序可以通过一些中间盒进行修改，因此接收者不应依赖选项顺序为各个选项提供额外的含义。相反，当存在多个HOST_ID选项时，它们的值应该按照它们在数据包中出现的顺序连接在一起，并被视为单个大标识符。
For both of the receiver requirements discussed above, this specification uses SHOULD rather than MUST because reliable interpretation and ordering of options could be possible if the inserting host and the interpreting host are under common administrative control and integrity-protect communication between the inserting host and the interpreting host. Mechanisms for signaling the value type(s) and integrity protection are not provided by this specification, and in their absence, the receiving host/ device MUST interpret the option value(s) as a single opaque identifier.
对于上述两种接收器要求，本规范使用“应该”而非“必须”，因为如果插入主机和口译主机处于共同的管理控制之下，并且完整性保护插入主机和口译主机之间的通信，则可以对选项进行可靠的解释和排序。本规范未提供发送值类型和完整性保护信号的机制，如果没有这些机制，接收主机/设备必须将选项值解释为单个不透明标识符。
This section details how the HOST_ID option functions in conjunction with other TCP options.
本节详细介绍HOST_ID选项如何与其他TCP选项一起工作。
TCP provides for a maximum of 40 octets for TCP options. As discussed in Appendix A of MPTCP [RFC6824], a typical SYN from modern, popular operating systems contains several TCP options (MSS (Maximum Segment Size), window scale, SACK (selective acknowledgment) permitted, and timestamp), which consume 19-24 octets depending on word alignment of the options. The initial SYN from a multipath TCP client would consume an additional 16 octets.
TCP为TCP选项提供最多40个八位字节。如MPTCP[RFC6824]附录A所述，现代流行操作系统中的典型SYN包含多个TCP选项（MSS（最大段大小）、窗口比例、SACK（选择性确认）和时间戳），这些选项根据选项的字对齐情况消耗19-24个八位字节。来自多路径TCP客户端的初始SYN将额外消耗16个八位字节。
HOST_ID needs at least 6 octets to be useful, so 9-21 octets are sufficient for many scenarios that benefit from HOST_ID. However, 4 octets are not enough space for the HOST_ID option. Thus, a TCP SYN containing all the typical TCP options (MSS, window scale, SACK permitted, and timestamp) and also containing multipath capable or multipath join as well as being word-aligned has insufficient space to accommodate HOST_ID. This means something has to give. The choices are either to avoid word alignment in that case (freeing 5 octets) or avoid adding the HOST_ID option. Each of these approaches is used in existing implementations and has been deemed acceptable for the associated use case.
HOST_ID至少需要6个八位字节才有用，因此9-21个八位字节对于许多受益于HOST_ID的场景来说是足够的。但是，4个八位字节对于HOST_ID选项来说是不够的。因此，一个包含所有典型TCP选项（MSS、窗口比例、SACK许可和时间戳）并且还包含多路径连接或多路径连接以及字对齐的TCP SYN没有足够的空间容纳主机ID。这意味着必须给出一些信息。在这种情况下，可以选择避免单词对齐（释放5个八位字节）或避免添加主机ID选项。这些方法中的每一种都在现有的实现中使用，并且被认为对于相关的用例是可以接受的。
The TCP Authentication Option (TCP-AO) [RFC5925] is incompatible with address sharing due to the fact that it provides integrity protection of the source IP address. For this reason, the only use cases where it makes sense to combine TCP-AO and HOST_ID are those where the TCP-AO-NAT extension [RFC6978] is in use. Injecting a HOST_ID TCP option does not interfere with the use of TCP-AO-NAT because the TCP options are not included in the Message Authentication Code (MAC) calculation.
TCP身份验证选项（TCP-AO）[RFC5925]与地址共享不兼容，因为它提供源IP地址的完整性保护。因此，将TCP-AO和HOST_ID结合起来的唯一有意义的用例是那些使用TCP-AO-NAT扩展[RFC6978]的用例。注入主机ID TCP选项不会干扰TCP-AO-NAT的使用，因为TCP选项不包括在消息身份验证码（MAC）计算中。
The TFO option [RFC7413] uses a zero-length cookie (total option length is 2 bytes) to request a TFO cookie for use on future connections. The server-generated TFO cookie is required to be at least 4 bytes long and allowed to be as long as 16 bytes (total option length is 6 to 18 bytes). The cookie request form of the option leaves enough room available in a SYN packet with the most commonly used options to accommodate the HOST_ID option, but a valid TFO cookie length longer than 13 bytes would prevent even the minimal 6-byte HOST_ID option from being included in the header.
TFO选项[RFC7413]使用零长度cookie（选项总长度为2字节）请求TFO cookie，以便在将来的连接中使用。服务器生成的TFO cookie的长度要求至少为4个字节，并允许最长为16个字节（选项总长度为6到18个字节）。选项的cookie请求表单在SYN数据包中留下了足够的空间，其中包含最常用的选项，以容纳HOST_ID选项，但如果有效的TFO cookie长度超过13字节，则即使是最小的6字节HOST_ID选项也无法包含在标头中。
There are multiple possibilities for allowing TFO and HOST_ID to be supported for the same connection, including:
允许同一连接支持TFO和HOST_ID的可能性有多种，包括：
o If the TFO implementation allows the cookie size to be configurable, the configured cookie size can be specifically selected to leave enough option space available in a typical TFO SYN packet to allow inclusion of the HOST_ID option.
o 如果TFO实现允许cookie大小可配置，则可以专门选择已配置的cookie大小，以便在典型TFO SYN数据包中留下足够的可用选项空间，以允许包含主机ID选项。
o If the TFO implementation provides explicit support for the HOST_ID option, it can be designed to use a shorter cookie length when the HOST_ID option is present in the TFO cookie request SYN.
o 如果TFO实现提供了对HOST_ID选项的显式支持，则可以将其设计为在TFO cookie请求SYN中存在HOST_ID选项时使用较短的cookie长度。
Reducing the TFO cookie size in order to include the HOST_ID option could have unacceptable security implications, so existing deployed systems that use the HOST_ID option consider TFO and HOST_ID to be mutually exclusive and do not support the use of both options on the same TCP connection.
减少TFO cookie大小以包含HoSTyID选项可能具有不可接受的安全影响，因此现有的使用HooSoID ID的部署系统认为TFO和HoestyID是互斥的，并且不支持在同一TCP连接上使用这两个选项。
It should also be noted that the presence of data in a TFO SYN increases the likelihood that there will be no space available in the SYN packet to support inclusion of the HOST_ID option without IP fragmentation, even if there is enough room in the TCP option space. This is an additional reason that the existing system considers TFO and HOST_ID to be mutually exclusive.
还应注意，TFO SYN中数据的存在增加了SYN数据包中没有空间支持包含主机ID选项而无IP碎片的可能性，即使TCP选项空间中有足够的空间。这是现有系统认为TFO和HOST_ID相互排斥的另一个原因。
Security (including privacy) considerations common to all HOST_ID solutions are discussed in [RFC6967].
[RFC6967]中讨论了所有主机ID解决方案共有的安全（包括隐私）注意事项。
The content of the HOST_ID option SHOULD NOT be used for purposes that require a trust relationship between the sender and the receiver (e.g., billing and/or subscriber policy enforcement). This requirement uses SHOULD rather than MUST because reliable interpretation of options could be possible if the inserting host and the interpreting host are under common administrative control and
HOST_ID选项的内容不应用于要求发送方和接收方之间建立信任关系的目的（例如，计费和/或订户策略实施）。这一要求使用“应该”而不是“必须”，因为如果插入主机和口译主机处于共同的管理控制和管理之下，则可以对选项进行可靠的解释
integrity-protect communication between the inserting host and the interpreting host. Mechanisms for signaling the value type(s) and integrity protection are not provided by this specification, and in their absence, the receiving host/device MUST NOT use the HOST_ID value for purposes that require a trust relationship.
完整性保护插入主机和解释主机之间的通信。本规范未提供发送值类型和完整性保护信号的机制，如果没有这些机制，接收主机/设备不得将主机ID值用于需要信任关系的目的。
Note that the above trust requirement applies equally to HOST_ID option values propagated forward from a previous in-path host as described in Section 4.3. In other words, if the trust mechanism does not apply to all option values in the packet, then none of the HOST_ID values can be considered trusted, and the receiving host/ device MUST NOT use any of the HOST_ID values for purposes that require a trust relationship. An inserting host/device that has such a trust relationship MUST NOT propagate forward an untrusted HOST_ID in such a way as to allow it to be considered trusted.
注意，如第4.3节所述，上述信任要求同样适用于从先前路径内主机向前传播的主机ID选项值。换句话说，如果信任机制不适用于数据包中的所有选项值，则任何主机ID值都不能被认为是可信的，并且接收主机/设备不得将任何主机ID值用于需要信任关系的目的。具有此类信任关系的插入主机/设备不得以允许其被视为受信任的方式转发不受信任的主机ID。
When the receiving network uses the values provided by the option in a way that does not require trust (e.g., maintaining session affinity in a load-balancing system), then use of a mechanism to enforce the trust relationship is OPTIONAL.
当接收网络以不需要信任的方式使用该选项提供的值时（例如，在负载平衡系统中维护会话亲和力），则使用机制强制执行信任关系是可选的。
Sending a TCP SYN across the public Internet necessarily discloses the public IP address of the sending host. When an intermediate address-sharing device is deployed on the public Internet, anonymity of the hosts using the device will be increased, with hosts represented by multiple source IP addresses on the ingress side of the device using a single source IP address on the egress side. The HOST_ID TCP option removes that increased anonymity, taking information that was already visible in TCP packets on the public Internet on the ingress side of the address-sharing device and making it available on the egress side of the device as well. In some cases, an explicit purpose of the address-sharing device is anonymity, in which case use of the HOST_ID TCP option would be incompatible with the purpose of the device.
通过公共互联网发送TCP SYN必然会公开发送主机的公共IP地址。当在公共互联网上部署中间地址共享设备时，使用该设备的主机的匿名性将增加，主机由设备入口侧的多个源IP地址表示，出口侧使用单个源IP地址。HOST_ID TCP选项删除了增加的匿名性，在地址共享设备的入口端获取公共互联网上TCP数据包中已经可见的信息，并使其在设备的出口端也可用。在某些情况下，地址共享设备的明确目的是匿名，在这种情况下，使用HOST_ID TCP选项将与设备的目的不兼容。
A NAT device used to provide interoperability between a local area network (LAN) using private [RFC1918] IP addresses and the public Internet is sometimes specifically intended to provide anonymity for the LAN clients as described in the above paragraph. For this reason, address-sharing devices at the border between a private LAN and the public Internet MUST NOT insert the HOST_ID option.
用于提供使用专用[RFC1918]IP地址的局域网（LAN）与公共因特网之间的互操作性的NAT设备有时特别用于为LAN客户端提供匿名性，如上文所述。因此，位于专用LAN和公共Internet之间边界的地址共享设备不得插入主机ID选项。
The HOST_ID option MUST NOT be used to provide client geographic or network location information that was not publicly visible in IP packets for the TCP flows processed by the inserting host. For
HOST_ID选项不得用于提供客户端地理或网络位置信息，这些信息在插入主机处理的TCP流的IP数据包中不公开。对于
example, the client's IP address MAY be used as the HOST_ID option value, but any geographic or network location information derived from the client's IP address MUST NOT be used as the HOST_ID value.
例如，客户端的IP地址可以用作主机ID选项值，但从客户端IP地址派生的任何地理或网络位置信息不得用作主机ID值。
The HOST_ID option MAY provide differentiating information that is locally unique such that individual TCP flows processed by the inserting host can be reliably identified. The HOST_ID option MUST NOT provide client identification information that was not publicly visible in IP packets for the TCP flows processed by the inserting host, such as subscriber information linked to the IP address.
HOST_ID选项可以提供本地唯一的区别信息，以便能够可靠地识别插入主机处理的各个TCP流。HOST_ID选项不得提供在插入主机处理的TCP流的IP数据包中不公开的客户端标识信息，例如链接到IP地址的订户信息。
The HOST_ID value MUST be changed whenever the subscriber IP address changes. This requirement ensures that the HOST_ID option does not introduce a new globally unique identifier that persists across subscriber IP address changes.
每当订户IP地址更改时，必须更改主机ID值。此要求确保HOST_ID选项不会引入新的全局唯一标识符，该标识符会在订户IP地址更改中保持不变。
The HOST_ID option MUST be stripped from IP packets traversing middleboxes that provide network-based anonymity services.
必须从通过提供基于网络的匿名服务的中间盒的IP数据包中剥离HOST_ID选项。
[RFC7258] provides the following guidance: "Those developing IETF specifications need to be able to describe how they have considered PM, and, if the attack is relevant to the work to be published, be able to justify related design decisions." Legitimate concerns about host identification have been raised within the IETF. The authors of this memo have attempted to address those concerns by providing details about the nature of the HOST_ID values and the types of middleboxes that should and should not include the HOST_ID option in TCP headers, which describes limitations already imposed by existing deployed systems. This section is intended to highlight some particularly important aspects of this design and the related guidance/limitations that are relevant to the pervasive monitoring discussion.
[RFC7258]提供了以下指导：“制定IETF规范的人员需要能够描述他们是如何考虑PM的，并且，如果攻击与即将发布的工作相关，则能够证明相关设计决策的合理性。”IETF中提出了关于主机识别的合理担忧。本备忘录的作者试图通过提供有关主机ID值的性质以及应在TCP标头中包含主机ID选项和不应在TCP标头中包含主机ID选项的中间盒类型的详细信息来解决这些问题，其中描述了现有部署系统已经施加的限制。本节旨在强调本设计的一些特别重要的方面以及与普遍监控讨论相关的相关指导/限制。
When a generated identifier is used, this document prohibits the address-sharing device from using globally unique or permanent identifiers. Only locally unique identifiers are allowed. As with persistent IP addresses, persistent HOST_ID values could facilitate user tracking and are therefore prohibited. The specific requirements for permissible HOST_ID values are discussed in Sections 8 and 4.1.
使用生成的标识符时，本文档禁止地址共享设备使用全局唯一或永久标识符。仅允许本地唯一标识符。与持久性IP地址一样，持久性主机ID值可能有助于用户跟踪，因此被禁止。第8节和第4.1节讨论了允许主机ID值的具体要求。
This specification does not target exposing a host beyond what the original packet, issued from that host, would have already exposed on the public Internet without introduction of the option. The option is intended only to carry forward information that was conveyed to the address-sharing device in the original packet, and HOST_ID option
本规范的目标不在于在不引入该选项的情况下，公开一个主机，而该主机发出的原始数据包在公共Internet上已经公开了。该选项仅用于携带在原始数据包中传送到地址共享设备的信息，以及主机标识选项
values that do not match this description are prohibited by requirements discussed in Section 8. This design does not allow the HOST_ID option to carry personally identifiable information, geographic location identifiers, or any other information that is not available in the wire format of the associated TCP/IP headers.
第8节讨论的要求禁止使用与本说明不匹配的值。此设计不允许HOST_ID选项携带个人识别信息、地理位置标识符或相关TCP/IP报头的有线格式中不可用的任何其他信息。
This document's guidance on option values is followed in the existing deployed system. Thus, the volatility of the information conveyed in a HOST_ID option is similar to that of the public, subscriber IP address. A distinct HOST_ID is used by the address-sharing function when the host reboots or gets a new public IP address from the subscriber network.
现有部署的系统遵循本文件关于选项值的指导。因此，在主机ID选项中传送的信息的波动性与公共用户IP地址的波动性相似。当主机重新启动或从订户网络获取新的公共IP地址时，地址共享功能使用不同的主机ID。
The described TCP option allows network identification to a similar level as the first 64 bits of an IPv6 address. That is, the server can use the bits of the TCP option to help identify a host behind an address-sharing device, in much the same way the server would use the host's IPv6 network address if the client and server were using IPv6 end to end.
所述的TCP选项允许网络标识达到与IPv6地址的前64位类似的级别。也就是说，服务器可以使用TCP选项的位来帮助识别地址共享设备后面的主机，这与如果客户端和服务器使用IPv6端到端，服务器将使用主机的IPv6网络地址的方式大致相同。
Some address-sharing middleboxes on the public Internet have the express intention of providing originator anonymity. Publication of this document can help such middleboxes recognize the associated risk and take action to mitigate it (e.g., by stripping or modifying the option value).
公共互联网上的一些地址共享中间盒明确表示有意提供发起人匿名。本文件的发布有助于此类中间商识别相关风险，并采取措施减轻风险（例如，剥离或修改期权价值）。
This document specifies a new TCP option (HOST_ID) that uses the shared experimental options format [RFC6994], with ExID in network-standard byte order. IANA has registered HOST_ID (0x0348) in the "TCP Experimental Option Experiment Identifiers (TCP ExIDs)" registry.
本文档指定了一个新的TCP选项（主机ID），该选项使用共享实验选项格式[RFC6994]，ExID为网络标准字节顺序。IANA已在“TCP实验选项实验标识符（TCP ExIDs）”注册表中注册了主机ID（0x0348）。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<http://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, DOI 10.17487/RFC4727, November 2006, <http://www.rfc-editor.org/info/rfc4727>.
[RFC4727]Fenner，B.“IPv4、IPv6、ICMPv4、ICMPv6、UDP和TCP报头中的实验值”，RFC 4727，DOI 10.17487/RFC4727，2006年11月<http://www.rfc-editor.org/info/rfc4727>.
[RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for Handling of Independent and IRTF Stream Submissions", BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, <http://www.rfc-editor.org/info/rfc5742>.
[RFC5742]Alvestrand，H.和R.Housley，“IESG处理独立和IRTF流提交的程序”，BCP 92，RFC 5742，DOI 10.17487/RFC5742，2009年12月<http://www.rfc-editor.org/info/rfc5742>.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013, <http://www.rfc-editor.org/info/rfc6994>.
[RFC6994]Touch，J.，“实验TCP选项的共享使用”，RFC 6994，DOI 10.17487/RFC6994，2013年8月<http://www.rfc-editor.org/info/rfc6994>.
[HOSTID] Abdo, E., Boucadair, M., and J. Queiroz, "HOST_ID TCP Options: Implementation & Preliminary Test Results", Work in Progress, draft-abdo-hostid-tcpopt-implementation-03, July 2012.
[HOSTID]Abdo，E.，Boucadair，M.和J.Queiroz，“主机识别TCP选项：实施和初步测试结果”，正在进行的工作，草稿-Abdo-HOSTID-tcpopt-Implementation-032012年7月。
[OVERLAYPATH] Williams, B., "Overlay Path Option for IP and TCP", Work in Progress, draft-williams-overlaypath-ip-tcp-rfc-04, June 2013.
[OVERLAYPATH]Williams，B.，“IP和TCP的覆盖路径选项”，正在进行的工作，草稿-Williams-OVERLAYPATH-IP-TCP-rfc-042013年6月。
[REVEAL] Yourtchenko, A. and D. Wing, "Revealing hosts sharing an IP address using TCP option", Work in Progress, draft-wing-nat-reveal-option-03, December 2011.
[REVEAL]Yourtchenko，A.和D.Wing，“使用TCP选项显示共享IP地址的主机”，正在进行的工作，草稿-Wing-nat-REVEAL-option-032011年12月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，DOI 10.17487/RFC1918，1996年2月<http://www.rfc-editor.org/info/rfc1918>.
[RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", RFC 1919, DOI 10.17487/RFC1919, March 1996, <http://www.rfc-editor.org/info/rfc1919>.
[RFC1919]Chatel，M.，“经典与透明IP代理”，RFC 1919，DOI 10.17487/RFC1919，1996年3月<http://www.rfc-editor.org/info/rfc1919>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，DOI 10.17487/RFC3022，2001年1月<http://www.rfc-editor.org/info/rfc3022>.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, June 2001, <http://www.rfc-editor.org/info/rfc3135>.
[RFC3135]Border，J.，Kojo，M.，Griner，J.，黑山，G.，和Z.Shelby，“旨在缓解链路相关降级的性能增强代理”，RFC 3135，DOI 10.17487/RFC3135，2001年6月<http://www.rfc-editor.org/info/rfc3135>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 5925，DOI 10.17487/RFC5925，2010年6月<http://www.rfc-editor.org/info/rfc5925>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 6146，DOI 10.17487/RFC6146，2011年4月<http://www.rfc-editor.org/info/rfc6146>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <http://www.rfc-editor.org/info/rfc6269>.
[RFC6269]福特，M.，Ed.，Boucadair，M.，Durand，A.，Levis，P.，和P.Roberts，“IP地址共享问题”，RFC 6269，DOI 10.17487/RFC62692011年6月<http://www.rfc-editor.org/info/rfc6269>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 6296DOI 10.17487/RFC62962011年6月<http://www.rfc-editor.org/info/rfc6296>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 6333，DOI 10.17487/RFC6333，2011年8月<http://www.rfc-editor.org/info/rfc6333>.
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/RFC6346, August 2011, <http://www.rfc-editor.org/info/rfc6346>.
[RFC6346]Bush，R.，Ed.，“IPv4地址短缺的地址加端口（A+P）方法”，RFC 6346，DOI 10.17487/RFC6346，2011年8月<http://www.rfc-editor.org/info/rfc6346>.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, <http://www.rfc-editor.org/info/rfc6598>.
[RFC6598]Weil，J.，Kuarsingh，V.，Donley，C.，Liljenstolpe，C.，和M.Azinger，“IANA为共享地址空间保留IPv4前缀”，BCP 153，RFC 6598，DOI 10.17487/RFC6598，2012年4月<http://www.rfc-editor.org/info/rfc6598>.
[RFC6619] Arkko, J., Eggert, L., and M. Townsley, "Scalable Operation of Address Translators with Per-Interface Bindings", RFC 6619, DOI 10.17487/RFC6619, June 2012, <http://www.rfc-editor.org/info/rfc6619>.
[RFC6619]Arkko，J.，Eggert，L.，和M.Townsley，“具有每个接口绑定的地址转换器的可扩展操作”，RFC 6619，DOI 10.17487/RFC66192012年6月<http://www.rfc-editor.org/info/rfc6619>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, <http://www.rfc-editor.org/info/rfc6824>.
[RFC6824]Ford，A.，Raiciu，C.，Handley，M.，和O.Bonaventure，“多地址多路径操作的TCP扩展”，RFC 6824DOI 10.17487/RFC68242013年1月<http://www.rfc-editor.org/info/rfc6824>.
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, <http://www.rfc-editor.org/info/rfc6888>.
[RFC6888]Perreault，S.，Ed.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“载体级NAT（CGN）的通用要求”，BCP 127，RFC 6888，DOI 10.17487/RFC6888，2013年4月<http://www.rfc-editor.org/info/rfc6888>.
[RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments", RFC 6967, DOI 10.17487/RFC6967, June 2013, <http://www.rfc-editor.org/info/rfc6967>.
[RFC6967]Boucadair，M.，Touch，J.，Levis，P.，和R.Penno，“在共享地址部署中显示主机标识符（主机ID）的潜在解决方案分析”，RFC 6967，DOI 10.17487/RFC6967，2013年6月<http://www.rfc-editor.org/info/rfc6967>.
[RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT Traversal", RFC 6978, DOI 10.17487/RFC6978, July 2013, <http://www.rfc-editor.org/info/rfc6978>.
[RFC6978]Touch，J.，“NAT穿越的TCP认证选项扩展”，RFC 6978，DOI 10.17487/RFC6978，2013年7月<http://www.rfc-editor.org/info/rfc6978>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <http://www.rfc-editor.org/info/rfc7413>.
[RFC7413]Cheng，Y.，Chu，J.，Radhakrishnan，S.，和A.Jain，“TCP快速开放”，RFC 7413，DOI 10.17487/RFC74132014年12月<http://www.rfc-editor.org/info/rfc7413>.
[RFC7620] Boucadair, M., Ed., Chatras, B., Reddy, T., Williams, B., and B. Sarikaya, "Scenarios with Host Identification Complications", RFC 7620, DOI 10.17487/RFC7620, August 2015, <http://www.rfc-editor.org/info/rfc7620>.
[RFC7620]Boucadair，M.，Ed.，Chatras，B.，Reddy，T.，Williams，B.，和B.Sarikaya，“主机识别复杂情况”，RFC 7620，DOI 10.17487/RFC7620，2015年8月<http://www.rfc-editor.org/info/rfc7620>.
Acknowledgements
致谢
Many thanks to W. Eddy, Y. Nishida, T. Reddy, M. Scharf, J. Touch, A. Zimmermann, and A. Falk for their comments.
非常感谢W.Eddy、Y.Nishida、T.Reddy、M.Scharf、J.Touch、A.Zimmermann和A.Falk的评论。
Authors' Addresses
作者地址
Brandon Williams Akamai, Inc. 8 Cambridge Center Cambridge, MA 02142 United States of America
Brandon Williams Akamai，Inc.美国马萨诸塞州剑桥中心8号，邮编02142
Email: brandon.williams@akamai.com
Email: brandon.williams@akamai.com
Mohamed Boucadair Orange
穆罕默德·布卡达尔橙
Email: mohamed.boucadair@orange.com
Email: mohamed.boucadair@orange.com
Dan Wing
丹荣
Email: dwing-ietf@fuggles.com
Email: dwing-ietf@fuggles.com