Internet Engineering Task Force (IETF) J. Touch
Request for Comments: 6994 USC/ISI
Category: Standards Track August 2013
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Touch
Request for Comments: 6994 USC/ISI
Category: Standards Track August 2013
ISSN: 2070-1721
Shared Use of Experimental TCP Options
共享使用实验性TCP选项
Abstract
摘要
This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints.
本文档描述了实验TCP选项代码点如何使用新的IANA TCP实验标识符并发支持多个TCP扩展，即使在同一连接中也是如此。该方法对未注册的实验和未使用该共享机制的实验具有鲁棒性。建议所有使用这些代码点的新TCP选项使用此选项。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6994.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6994.
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 ....................................................2
2. Conventions Used in This Document ...............................3
3. TCP Experimental Option Structure ...............................4
3.1. Selecting an ExID ..........................................5
3.2. Impact on TCP Option Processing ............................6
4. Reducing the Impact of False Positives ..........................7
5. Migration to Assigned Options ...................................7
6. Rationale .......................................................8
7. Security Considerations .........................................9
8. IANA Considerations .............................................9
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
10. Acknowledgments ...............................................11
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. TCP Experimental Option Structure ...............................4
3.1. Selecting an ExID ..........................................5
3.2. Impact on TCP Option Processing ............................6
4. Reducing the Impact of False Positives ..........................7
5. Migration to Assigned Options ...................................7
6. Rationale .......................................................8
7. Security Considerations .........................................9
8. IANA Considerations .............................................9
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
10. Acknowledgments ...............................................11
TCP includes options to enable new protocol capabilities that can be activated only where needed and supported [RFC793]. The space for identifying such options is small -- 256 values, of which 30 are assigned at the time of this document's publication [IANA]. Two of these codepoints (253, 254) are allocated to support experiments [RFC4727]. These values are intended for testing purposes or for use when an assigned codepoint is either not warranted or available, e.g., based on the maturity status of the defined capability (i.e., Experimental or Informational, rather than Standards Track).
TCP包括启用新协议功能的选项，这些功能只能在需要和支持的情况下激活[RFC793]。识别此类选项的空间很小——256个值，其中30个在本文档发布[IANA]时分配。其中两个代码点（253254）被分配用于支持实验[RFC4727]。这些值用于测试目的，或在指定的代码点不保证或不可用时使用，例如，基于定义能力的成熟度状态（即实验性或信息性，而非标准跟踪）。
Here, the term "experimental TCP options" refers to options that use the TCP experimental option codepoints [RFC4727]. Such experiments can be described in an RFC of any status (e.g., Experimental, Informational, etc.) and are intended to be used in controlled environments and are allowed in public deployments (when not enabled as default [RFC3692]). Nothing prohibits the deployment of multiple experiments in the same environment -- controlled or public. Further, some protocols are specified in Experimental or Informational RFCs, which either include parameters or design choices not yet understood or which might not be widely deployed [RFC2026]. Typically, these TCP options are not eligible to receive assigned codepoints [RFC2780], so they need a way to share their use of the experimental codepoints.
这里，术语“实验TCP选项”是指使用TCP实验选项代码点的选项[RFC4727]。此类实验可以在任何状态的RFC中进行描述（例如，实验性、信息性等），旨在在受控环境中使用，并允许在公共部署中使用（默认情况下未启用[RFC3692]）。没有任何东西禁止在同一环境中部署多个实验——受控或公共。此外，一些协议在实验性或信息性RFC中指定，其中包括尚未理解的参数或设计选择，或者可能未广泛部署[RFC2026]。通常，这些TCP选项没有资格接收指定的代码点[RFC2780]，所以它们需要一种方法来共享它们对实验代码点的使用。
There is currently no mechanism to support shared use of the TCP experimental option codepoints, either by different experiments on different connections or for more than two experimental options in the same connection. Experimental options 253 and 254 are already deployed in operational code to support an early version of TCP
目前没有任何机制支持通过不同连接上的不同实验或同一连接中的两个以上实验选项共享使用TCP实验选项代码点。实验选项253和254已经部署在操作代码中，以支持早期版本的TCP
authentication. Option 253 is also documented for the experimental TCP Cookie Transaction option [RFC6013]. This shared use results in collisions in which a single codepoint can appear multiple times in a single TCP segment and for which each use is ambiguous.
认证。选项253还记录了实验性TCP Cookie事务选项[RFC6013]。这种共享使用会导致冲突，其中单个代码点可以在单个TCP段中多次出现，并且每次使用都不明确。
Other codepoints have been used without assignment (known as "squatting"), notably 31-32 (TCP cookie transactions, as originally distributed and in its API doc) and 76-78 (tcpcrypt) [Bi11] [Si11]. Commercial products reportedly also use unassigned options 33, 69-70, and 76-78. Even though these uses are unauthorized, they currently impact legitimate assignees.
其他代码点在未分配的情况下使用（称为“蹲式”），特别是31-32（TCP cookie事务，最初分发并在其API文档中），以及76-78（tcpcrypt）[Bi11][Si11]。据报道，商业产品还使用未分配的选项33、69-70和76-78。尽管这些使用是未经授权的，但它们目前影响到合法受让人。
Both such misuses (squatting on both experimental and assigned codepoints) are expected to continue, but there are several approaches that can alleviate the impact on cooperating protocol designers. One proposal relaxes the requirements for assignment of TCP options, allowing them to be assigned more readily for protocols that have not been standardized through the IETF process [RFC5226]. Another proposal assigns a larger pool to the TCP experiment option codepoints and manages their sharing through IANA coordination [Ed11].
这两种误用（蹲在实验性和指定的代码点上）都将继续，但有几种方法可以减轻对合作协议设计者的影响。一项提案放宽了TCP选项分配的要求，允许更容易地为尚未通过IETF过程标准化的协议分配TCP选项[RFC5226]。另一个建议是为TCP实验选项代码点分配一个更大的池，并通过IANA协调管理它们的共享[Ed11]。
The approach proposed in this document does not require additional TCP option codepoints and is robust to those who choose either not to support it or not to register their experiments. The solution adds a field to the structure of the experimental TCP option. This field is populated with an "experiment identifier" (ExID) defined as part of a specific option experiment. The ExID helps reduce the probability of a collision of independent experimental uses of the same option codepoint, both for those who follow this document (using registered ExIDs) and those who do not (squatters who either ignore this extension or do not register their ExIDs).
本文中提出的方法不需要额外的TCP选项代码点，并且对于那些选择不支持该方法或不注册其实验的人来说是健壮的。该解决方案在实验性TCP选项的结构中添加了一个字段。此字段填充了一个“实验标识符”（ExID），该标识符定义为特定选项实验的一部分。ExID有助于降低同一选项代码点的独立实验使用发生冲突的概率，无论是对于遵循本文档的人（使用已注册的ExID）还是对于未遵循本文档的人（忽略此扩展或未注册其ExID的擅自占用者）。
The solution proposed in this document is recommended for all new protocols that use TCP experimental option codepoints. The techniques described here may also enable shared use of other experimental codepoints, but that issue is out of scope for this document.
本文档中提出的解决方案建议用于所有使用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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
In this document, these words will appear with that interpretation only when in ALL CAPS. Lowercase uses of these words are not to be interpreted as carrying RFC 2119 significance.
在本文件中，只有在所有大写字母中，这些单词才会以该解释出现。这些词语的小写用法不得解释为具有RFC 2119的意义。
In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC.
在本文档中，缩进行前面的字符“>>”表示使用上述关键字的合规性要求声明。本公约有助于审查人员快速确定或找到本RFC的明确合规要求。
TCP options have the current common structure [RFC793], in which the first byte is the codepoint (Kind) and the second byte is the length of the option in bytes (Length):
TCP选项具有当前通用结构[RFC793]，其中第一个字节是代码点（种类），第二个字节是选项的长度（字节数）：
0 1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| Kind | Length | ... |
+--------+--------+--------+--------+
| ...
+--------
0 1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| Kind | Length | ... |
+--------+--------+--------+--------+
| ...
+--------
Figure 1. TCP Option Structure [RFC793]
图1。TCP选项结构[RFC793]
This document extends the option structure for experimental codepoints (253, 254) with an experiment identifier (ExID), which is either 2 or 4 bytes in length. The ExID is used to differentiate experiments and is the first field after Kind and Length, as follows:
本文档使用长度为2或4字节的实验标识符（ExID）扩展了实验代码点（253254）的选项结构。ExID用于区分实验，是种类和长度之后的第一个字段，如下所示：
0 1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| Kind | Length | ExID |
+--------+--------+--------+--------+
| option contents...
+--------+--------+--------+---
0 1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| Kind | Length | ExID |
+--------+--------+--------+--------+
| option contents...
+--------+--------+--------+---
Figure 2. TCP Experimental Option with a 16-bit ExID
图2。带有16位ExID的TCP实验选项
0 1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| Kind | Length | ExID |
+--------+--------+--------+--------+
| ExID (con't) | option contents...
+--------+--------+--------+---
0 1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| Kind | Length | ExID |
+--------+--------+--------+--------+
| ExID (con't) | option contents...
+--------+--------+--------+---
Figure 3. TCP Experimental Option with a 32-bit ExID
图3。带有32位ExID的TCP实验选项
This mechanism is encouraged for all TCP options that are not yet eligible for assigned codepoints:
对于所有尚未符合指定代码点条件的TCP选项，鼓励使用此机制：
>> Protocols requiring new TCP option codepoints that are not eligible for assigned values SHOULD use the existing TCP experimental option codepoints (253, 254) with ExIDs as described in this document.
>>需要新的TCP选项代码点但不符合指定值条件的协议应使用现有的TCP实验选项代码点（253254）和本文档中描述的ExID。
This mechanism is encouraged for all TCP options using the current experimental codepoints in controlled environments:
在受控环境中使用当前实验代码点的所有TCP选项都鼓励使用此机制：
>> All protocols using the TCP experimental option codepoints (253, 254), even those deployed in controlled environments, SHOULD use ExIDs as described in this document.
>>所有使用TCP实验选项代码点（253254）的协议，即使是部署在受控环境中的协议，都应该使用本文档中描述的ExID。
This mechanism is required for all TCP options using the current experimental codepoints that are publicly deployed, whether enabled by default or not:
使用当前公开部署的实验代码点的所有TCP选项都需要此机制，无论默认情况下是否启用：
>> All protocols using the TCP experimental option codepoints (253, 254) that are deployed outside controlled environments, such as in the public Internet, MUST use ExIDs as described in this document.
>>所有使用TCP实验选项代码点（253，254）的协议（部署在受控环境之外，如公共互联网中）必须使用本文档中所述的ExID。
Once a TCP option uses the mechanism in this document, registration of the ExID with IANA is required:
一旦TCP选项使用本文档中的机制，则需要向IANA注册ExID：
>> All protocols using ExIDs as described in this document MUST register those ExIDs with IANA.
>>本文档中描述的所有使用ExID的协议必须向IANA注册这些ExID。
Applicants register their desired ExID by contacting IANA [IANA].
申请人通过联系IANA[IANA]注册他们想要的ExID。
ExIDs are selected at design time, when the protocol designer first implements or specifies the experimental option. ExIDs can be either 16 bits or 32 bits. In both cases, the value is stored in the header in network-standard (big-endian) byte order. ExIDs combine properties of IANA registered codepoints with "magic numbers".
ExID是在设计时选择的，当协议设计器首次实现或指定实验选项时。EXID可以是16位或32位。在这两种情况下，值都以网络标准（big-endian）字节顺序存储在报头中。ExID将IANA注册码点的属性与“幻数”相结合。
>> All ExIDs MUST be either 16 bits or 32 bits long.
>>所有EXID的长度必须为16位或32位。
Use of the ExID, whether 16 bit or 32 bit, helps reduce the probability of a false positive collision with those who either do not register their experiment or who do not implement this mechanism.
使用ExID，无论是16位还是32位，都有助于降低与未注册实验或未实现此机制的人发生误报冲突的概率。
In order to conserve TCP option space, either for use within a specific option or to be available for other options:
为了节省TCP选项空间，可以在特定选项内使用，也可以用于其他选项：
>> Options implementing the mechanism of this document SHOULD use 16-bit ExIDs, except where explicitly motivating the need for 32-bit ExIDs, e.g., to avoid false positives or maintain alignment with an expected future assigned codepoint.
>>实现本文件机制的选项应使用16位EXID，除非明确要求使用32位EXID，例如，避免误报或与预期未来指定的码点保持一致。
ExIDs are registered with IANA using "first come, first served" (FCFS) priority based on the first two bytes. Those two bytes are thus sufficient to interpret which experimental option is contained in the option field.
EXID使用基于前两个字节的“先到先服务”（FCFS）优先级向IANA注册。因此，这两个字节足以解释选项字段中包含的实验选项。
>> All ExIDs MUST be unique based on their first 16 bits.
>>根据其前16位，所有EXID必须是唯一的。
The second two bytes serve as a "magic number". A magic number is a self-selected codepoint whose primary value is its unlikely collision with values selected by others. Magic numbers are used in other protocols, e.g., bootstrap protocol (BOOTP) [RFC951] and DHCP [RFC2131].
后两个字节用作“幻数”。幻数是一个自选的码点，其主要值是它不太可能与其他人选择的值发生冲突。幻数用于其他协议，例如引导协议（BOOTP）[RFC951]和DHCP[RFC2131]。
Using the additional magic number bytes helps the option contents have the same byte alignment in the TCP header as they would have if (or when) a conventional (non-experiment) TCP option codepoint is assigned. Use of the same alignment reduces the potential for implementation errors, especially in using the same word-alignment padding, if the same software is later modified to use a conventional codepoint. Use of the longer, 32-bit ExID further decreases the probability of such a false positive compared to those using shorter, 16-bit ExIDs.
使用额外的幻数字节有助于选项内容在TCP标头中具有与分配常规（非实验）TCP选项代码点时相同的字节对齐方式。如果相同的软件后来被修改为使用传统的码点，使用相同的对齐方式可以减少实现错误的可能性，特别是在使用相同的字对齐填充时。与使用较短的16位ExID相比，使用较长的32位ExID进一步降低了此类误报的概率。
Use of the ExID does consume TCP option space but enables concurrent use of the experimental codepoints and provides protection against false positives, leaving less space for other options (including other experiments). Use of the longer, 32-bit ExID consumes more space, but provides more protection against false positives.
ExID的使用确实消耗了TCP选项空间，但允许同时使用实验性代码点，并提供了防误报保护，为其他选项（包括其他实验）留下了更少的空间。使用较长的32位ExID占用更多空间，但提供了更多的防误报保护。
The ExID number is considered part of the TCP option, not the TCP option header. The presence of the ExID increases the effective option Length field by the size of the ExID. The presence of this ExID is thus transparent to implementations that do not support TCP options.
ExID编号被视为TCP选项的一部分，而不是TCP选项标头。ExID的存在将有效选项长度字段增加ExID的大小。因此，该ExID的存在对于不支持TCP选项的实现是透明的。
During TCP processing, ExIDs in experimental options are matched against the ExIDs for each implemented protocol. The remainder of the option is specified by the particular experimental protocol.
在TCP处理过程中，实验选项中的ExID与每个已实现协议的ExID匹配。该选项的其余部分由特定的实验协议指定。
>> Experimental options with ExIDs that do not match implemented protocols MUST be ignored.
>>必须忽略ExID与已实现协议不匹配的实验选项。
The ExID mechanism must be coordinated during connection establishment, just as with any TCP option.
ExID机制必须在连接建立期间进行协调，就像任何TCP选项一样。
>> TCP ExID, if used in any TCP segment of a connection, MUST be present in TCP SYN segments of that connection.
>>如果在连接的任何TCP段中使用TCP ExID，则该连接的TCP SYN段中必须存在TCP ExID。
>> TCP experimental option ExIDs, if used in any TCP segment of a connection, SHOULD be used in all TCP segments of that connection in which any experimental option is present.
>>如果在连接的任何TCP段中使用TCP实验选项EXID，则应在存在任何实验选项的该连接的所有TCP段中使用。
Use of an ExID uses additional space in the TCP header and requires additional protocol processing by experimental protocols. Because these are experiments, neither consideration is a substantial impediment; a finalized protocol can avoid both issues with the assignment of a dedicated option codepoint later.
使用ExID会在TCP报头中使用额外的空间，并且需要通过实验协议进行额外的协议处理。因为这些都是实验，考虑都不是实质性的障碍；最终确定的协议可以避免这两个问题，稍后分配专用选项代码点。
False positives occur where the registered ExID of an experiment matches the value of an option that does not use ExIDs. Such collisions can cause an option to be interpreted by the incorrect processing routine. Use of checksums or signatures may help an experiment use the shorter ExID while reducing the corresponding increased potential for false positives.
如果实验的注册ExID与不使用ExID的选项的值匹配，则会出现误报。此类冲突可能导致选项被不正确的处理例程解释。使用校验和或签名可以帮助实验使用较短的ExID，同时减少相应增加的误报可能性。
>> Experiments that are not robust to ExID false positives SHOULD implement other detection measures, such as checksums or minimal digital signatures over the experimental options they support.
>>对ExID误报不具有鲁棒性的实验应在其支持的实验选项上实施其他检测措施，如校验和或最小数字签名。
Some experiments may transition away from being experimental and become eligible for an assigned TCP option codepoint. This document does not recommend a specific migration plan to transition from use of the experimental TCP options/ExIDs to use of an assigned codepoint.
有些实验可能会从实验性转变为符合指定TCP选项代码点的条件。本文档不推荐从使用实验性TCP选项/ExID过渡到使用指定的代码点的特定迁移计划。
However, once an assigned codepoint is allocated, use of an ExID represents unnecessary overhead. As a result:
然而，一旦分配了指定的代码点，使用ExID就意味着不必要的开销。因此：
>> Once a TCP option codepoint is assigned to a protocol, that protocol SHOULD NOT continue to use an ExID as part of that assigned codepoint.
>>一旦TCP选项代码点分配给协议，该协议不应继续使用ExID作为分配的代码点的一部分。
This document does not recommend whether or how an implementation of an assigned codepoint can be backward compatible with use of the experimental codepoint/ExID.
本文档不建议指定代码点的实现是否或如何与实验性代码点/ExID的使用向后兼容。
However, some implementers may be tempted to include both the experimental and assigned codepoint in the same segment, e.g., in a SYN to support backward compatibility during connection establishment. This is a poor use of limited resources; so, to ensure conservation of the TCP option space:
然而，一些实现者可能试图在同一段（例如，在SYN中）中包括实验性和分配的代码点，以支持连接建立期间的向后兼容性。这是对有限资源的拙劣使用；因此，为了确保TCP选项空间的保护：
>> A TCP segment MUST NOT contain both an assigned TCP option codepoint and a TCP experimental option codepoint for the same protocol.
>>TCP段不得同时包含同一协议的指定TCP选项代码点和TCP实验选项代码点。
Instead, a TCP that intends backward compatibility might send multiple SYNs with alternates of the same option and discard all but the most desired successful connection. Although this approach may resolve more slowly or require additional effort at the endpoints, it is preferable to excessively consuming TCP option space.
相反，打算向后兼容的TCP可能会发送具有相同选项的多个SYN，并放弃除最需要的成功连接以外的所有连接。尽管这种方法可能会解决得更慢或需要在端点进行额外的工作，但它比过度消耗TCP选项空间更可取。
The ExIDs described in this document combine properties of IANA FCFS-registered values with magic numbers. Although IANA FCFS registries are common, so too are those who either fail to register or who 'squat' by deliberately using codepoints that are assigned to others. The approach in this document is intended to recognize this reality and be more robust to its consequences than would be a conventional IANA FCFS registry.
本文档中描述的ExID将IANA FCFS注册值的属性与幻数相结合。虽然IANA FCFS注册很常见，但那些未能注册或故意使用分配给其他人的代码点而“蹲”注册的人也很常见。本文件中的方法旨在认识到这一现实，并比传统的IANA FCFS登记册更稳健地应对其后果。
Existing ID spaces were considered as ExIDs in the development of this mechanism, including IEEE Organizationally Unique Identifier (OUI) and IANA Private Enterprise Numbers (PENs) [IEEE802] [OUI] [RFC1155].
在该机制的开发过程中，现有ID空间被视为ExID，包括IEEE组织唯一标识符（OUI）和IANA私有企业编号（PENs）[IEEE802][OUI][RFC1155]。
OUIs are 24-bit identifiers that are combined with 24 to 40 bits of privately assigned space to create identifiers that are commonly assigned to a unique piece of hardware. OUIs are already longer than the smaller ExID value, and obtaining an OUI is costly (currently $1,885.00 USD). An OUI could be obtained for each experiment, but this could be considered expensive. An OUI already assigned to an organization could be shared if extended (to support multiple experiments within an organization), but this would either require coordination within an organization or an IANA registry; the former is prohibitive, and the latter is more complicated than having IANA manage the entire space.
OUI是24位标识符，与24到40位的私有分配空间相结合，以创建通常分配给唯一硬件的标识符。OUI的长度已经超过较小的ExID值，获得OUI的成本很高（目前为1885.00美元）。每个实验都可以获得OUI，但这可能被认为是昂贵的。已经分配给组织的OUI可以在扩展时共享（以支持组织内的多个实验），但这需要组织内的协调或IANA注册表；前者是禁止性的，后者比让IANA管理整个空间更复杂。
PENs were originally used in the Simple Network Management Protocol (SNMP) [RFC1157]. PENs are identifiers that can be obtained without cost from IANA [PEN]. Despite the current registry, the size of the PEN assignment space is currently undefined and has only recently been proposed (as 32 bits) [IANA-PEN]. PENs are currently assigned to organizations, and there is no current process for assigning them to individuals. Finally, if the PENs are 32 bits as expected, they would be larger than needed in many cases.
PEN最初用于简单网络管理协议（SNMP）[RFC1157]。PEN是可以从IANA[PEN]免费获得的标识符。尽管有当前的注册表，但笔分配空间的大小目前尚未定义，只是最近才提出（作为32位）[IANA-PEN]。PEN目前分配给组织，目前没有将PEN分配给个人的流程。最后，如果笔是预期的32位，那么在许多情况下，笔会比需要的大。
The mechanism described in this document is not intended to enhance, nor does it weaken the existing state of security for TCP option processing.
本文档中描述的机制不是为了增强，也不是为了削弱TCP选项处理的现有安全状态。
IANA has created a "TCP Experimental Option Experiment Identifiers (TCP ExIDs)" registry. The registry records both 16-bit and 32-bit ExIDs, as well as a reference (description, document pointer, or assignee name and e-mail contact) for each entry. ExIDs are registered for use with both of the TCP experimental option codepoints, i.e., with TCP options with values of 253 and 254.
IANA已经创建了“TCP实验选项实验标识符（TCP ExIDs）”注册表。注册表记录16位和32位EXID，以及每个条目的引用（说明、文档指针或受让人姓名和电子邮件联系人）。ExID注册用于两个TCP实验选项代码点，即值为253和254的TCP选项。
Entries are assigned on a First Come, First Served (FCFS) basis [RFC5226]. The registry operates FCFS on the first two bytes of the ExID (in network-standard order) but records the entire ExID (in network-standard order). Some examples are:
参赛作品以先到先得（FCFS）的方式分配[RFC5226]。注册表对ExID的前两个字节（按网络标准顺序）执行FCFS操作，但记录整个ExID（按网络标准顺序）。例如：
o 0x12340000 collides with a previous registration of 0x1234abcd
o 0x12340000与先前的0x1234abcd注册冲突
o 0x5678 collides with a previous registration of 0x56780123
o 0x5678与先前的0x56780123注册冲突
o 0xabcd1234 collides with a previous registration of 0xabcd
o 0xabcd1234与先前的0xabcd注册冲突
IANA will advise applicants of duplicate entries to select an alternate value, as per typical FCFS processing.
IANA将根据典型的FCFS处理，建议重复条目的申请人选择替代值。
IANA will record known duplicate uses to assist the community in both debugging assigned uses as well as correcting unauthorized duplicate uses.
IANA将记录已知的重复使用，以协助社区调试分配的使用以及纠正未经授权的重复使用。
IANA should impose no requirements on making a registration other than indicating the desired codepoint and providing a point of contact. A short description or acronym for the use is desired but should not be required.
IANA不应对注册提出任何要求，但应指明所需的代码点并提供联系点。需要使用简短的说明或首字母缩略词，但不需要。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727]Fenner，B.，“IPv4、IPv6、ICMPv4、ICMPv6、UDP和TCP报头中的实验值”，RFC 4727，2006年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[Bi11] Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres, D., and Q. Slack, "Cryptographic protection of TCP Streams", Work in Progress, September 2012.
[Bi11]Bittau，A.，Boneh，D.，Hamburg，M.，Handley，M.，Mazieres，D.，和Q.Slack，“TCP流的加密保护”，正在进行的工作，2012年9月。
[Ed11] Eddy, W., "Additional TCP Experimental-Use Options", Work in Progress, August 2011.
[Eddy，W.，“其他TCP实验使用选项”，正在进行的工作，2011年8月。
[IANA] IANA, <http://www.iana.org/>.
[IANA]IANA<http://www.iana.org/>.
[IANA-PEN] Liang, P. and A. Melnikov, "Private Enterprise Number (PEN) Practices and Internet Assigned Numbers: Authority (IANA) Considerations for Registration Procedures", Work in Progress, June 2012.
[IANA-PEN]Liang，P.和A.Melnikov，“私营企业编号（PEN）实践和互联网分配编号：注册程序的机构（IANA）考虑”，正在进行的工作，2012年6月。
[IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE 802-2001, 8 March 2002.
[IEEE802]IEEE，“局域网和城域网的IEEE标准：概述和体系结构”，IEEE 802-2001，2002年3月8日。
[OUI] IEEE, "Organizationally Unique Identifier (OUI) or 'Company_ID'", <http://standards.ieee.org/develop/regauth/oui/>.
[OUI]IEEE，“组织唯一标识符（OUI）或“公司ID”<http://standards.ieee.org/develop/regauth/oui/>.
[PEN] IANA, "Private Enterprise Numbers", <http://www.iana.org/assignments/enterprise-numbers>.
[PEN]IANA，“私营企业编号”<http://www.iana.org/assignments/enterprise-numbers>.
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[RFC951]Croft，W.和J.Gilmore，“引导协议”，RFC9511985年9月。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-Based Internets", STD 16, RFC 1155, May 1990.
[RFC1155]Rose，M.和K.McCloghrie，“基于TCP/IP的互联网管理信息的结构和识别”，STD 16，RFC 1155，1990年5月。
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", RFC 1157, May 1990.
[RFC1157]Case，J.，Fedor，M.，Schoffstall，M.，和J.Davin，“简单网络管理协议（SNMP）”，RFC 1157，1990年5月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780]Bradner，S.和V.Paxson，“互联网协议和相关报头中值的IANA分配指南”，BCP 37，RFC 2780，2000年3月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013, January 2011.
[RFC6013]辛普森，W.“TCP Cookie事务（TCPCT）”，RFC6013，2011年1月。
[Si11] Simpson, W., "TCP Cookie Transactions (TCPCT) Sockets Application Program Interface (API)", Work in Progress, April 2011.
[Si11]Simpson，W.“TCP Cookie事务（TCPCT）套接字应用程序接口（API）”，正在进行的工作，2011年4月。
This document was motivated by discussions on the IETF TCPM mailing list and by Wes Eddy's proposal [Ed11]. Yoshifumi Nishida, Pasi Sarolathi, and Michael Scharf provided detailed feedback.
本文件的动机是关于IETF TCPM邮件列表的讨论和Wes Eddy的建议[Ed11]。西田义文、帕西·萨罗拉蒂和迈克尔·沙尔夫提供了详细的反馈。
This document was originally prepared using 2-Word-v2.0.template.dot.
本文件最初使用2-Word-v2.0.template.dot编制。
Author's Address
作者地址
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
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