Network Working Group T. Narten
Request for Comments: 3692 IBM
BCP: 82 January 2004
Updates: 2434
Category: Best Current Practice
Network Working Group T. Narten
Request for Comments: 3692 IBM
BCP: 82 January 2004
Updates: 2434
Category: Best Current Practice
Assigning Experimental and Testing Numbers Considered Useful
分配被认为有用的实验和测试数字
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.
在试验或扩展协议时，通常需要使用某种协议编号或常量，以便实际测试或试验新功能，即使在封闭环境中进行测试时也是如此。例如，要测试新的DHCP选项，需要一个选项号来标识新功能。该文档建议，在编写IANA考虑部分时，作者应该考虑为实验目的分配一小部分的数字，实现者可以在测试协议扩展或其他新特征时使用。本文件为特定协议中的实验目的保留了一些数字范围，其中已确定需要支持实验。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Recommendation for Protocols . . . . . . . . . . . . . . 4
2. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 5
2.1. IP Protocol Field. . . . . . . . . . . . . . . . . . . . 5
2.2. Existing Name Spaces . . . . . . . . . . . . . . . . . . 5
3. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 6
6. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
7. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Recommendation for Protocols . . . . . . . . . . . . . . 4
2. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 5
2.1. IP Protocol Field. . . . . . . . . . . . . . . . . . . . 5
2.2. Existing Name Spaces . . . . . . . . . . . . . . . . . . 5
3. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 6
6. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
7. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
When experimenting with or extending protocols, it is often necessary to have a protocol number as part of the implementation [RFC2434]. For example, to develop a protocol that runs directly above IP, one needs an IP Protocol Number to place in the Protocol field of the IP header [RFC791]. In some cases, obtaining a new number is straightforward (e.g., a well-known TCP or UDP port) or not even necessary (e.g., TCP and UDP port numbers for testing purposes). In other cases, obtaining a number is more difficult. For example, the number of available and unassigned values in a name space may be small enough that there is concern that all available numbers will be used up if assigned carelessly. Even in cases where numbers are potentially plentiful, it may be undesirable to assign numbers unless the proposed usage has been adequately reviewed by the broader community. Consequently, some number spaces specify that IANA only make assignments in cases where there is strong community support for a proposed protocol. For example, values out of some name spaces are only assigned through an "IETF Standards Action" [RFC2434], which requires that the proposed use be in an IETF Standards Track RFC.
在试验或扩展协议时，通常需要将协议编号作为实现的一部分[RFC2434]。例如，要开发直接在IP之上运行的协议，需要在IP头[RFC791]的协议字段中输入IP协议编号。在某些情况下，获取一个新的号码很简单（例如，众所周知的TCP或UDP端口），甚至不需要（例如，出于测试目的的TCP和UDP端口号）。在其他情况下，获取数字更为困难。例如，名称空间中的可用值和未分配值的数量可能足够小，以至于担心如果不小心分配，所有可用的数字都会被用尽。即使在数字可能很多的情况下，分配数字也可能是不可取的，除非提议的使用已得到更广泛社区的充分审查。因此，一些数字空间规定IANA仅在社区强烈支持拟定协议的情况下进行分配。例如，某些名称空间中的值仅通过“IETF标准行动”[RFC2434]分配，这要求提议的使用在IETF标准跟踪RFC中。
In order to experiment with a new protocol, an experimental value may be needed that won't collide with an existing or future usage.
为了使用新协议进行实验，可能需要一个不会与现有或未来使用冲突的实验值。
One approach is to allow IANA to make temporary assignments for such purposes. The idea is that a protocol value can be assigned to allow experimentation, but after the experiment ends, the number would be returned to IANA. There are several drawbacks to this approach, however. First, experience has shown that it can be difficult to reclaim numbers once assigned. For example, contact information becomes outdated and it can become difficult to find out what the status of an experiment actually is. Second, should deployment with the temporarily assigned number take place (e.g., it is included as part of a product), it becomes very difficult to determine whether or not reuse of that number would lead to adverse impact with regards to deployed devices. Finally, it can be difficult to determine when an experiment has ended and whether the number needs to be returned.
一种方法是允许IANA为此目的进行临时分配。其思想是，可以指定一个协议值以允许进行实验，但在实验结束后，该数字将返回给IANA。然而，这种方法有几个缺点。首先，经验表明，一旦分配了号码，就很难收回号码。例如，联系信息变得过时，很难了解实验的实际状态。其次，如果使用临时分配的编号进行部署（例如，将其作为产品的一部分），则很难确定重新使用该编号是否会对部署的设备产生不利影响。最后，很难确定实验何时结束以及是否需要返回数字。
An alternate approach, and the one recommended in this document, is to assign a range of numbers specifically earmarked for testing and experimentation purposes. Mutually consenting devices could use these numbers for whatever purposes they desire, but under the understanding that they are reserved for generic testing purposes, and other implementations may use the same numbers for different experimental uses.
本文件中推荐的另一种方法是指定一系列专门用于测试和实验目的的数字。双方同意的设备可以将这些数字用于他们想要的任何目的，但前提是这些数字保留用于一般测试目的，其他实现可能会将相同的数字用于不同的实验用途。
Numbers in the experimentation range are similar to those called "Private Use" in RFC 2434 [IANA-CONSIDERATIONS]. They are not intended to be used in general deployments or be enabled by default in products or other general releases. In those cases where a product or release makes use of an experimental number, the end user must be required to explicitly enable the experimental feature and likewise have the ability to chose and assign which number from the experimental range will be used for a specific purpose (i.e., so the end user can ensure that use of a particular number doesn't conflict with other on-going uses). Shipping a product with a specific value pre-enabled would be inappropriate and can lead to interoperability problems when the chosen value collides with a different usage, as it someday surely will.
实验范围内的数字与RFC 2434[IANA-2]中称为“私人使用”的数字相似。它们不打算在常规部署中使用，也不打算在产品或其他常规版本中默认启用。在产品或版本使用实验编号的情况下，最终用户必须明确启用实验功能，并且同样能够从实验范围中选择和分配将用于特定目的的编号（即，最终用户可以确保特定数字的使用不会与其他正在进行的使用发生冲突）。装运预先启用特定值的产品是不合适的，并且当所选值与不同的使用发生冲突时，可能会导致互操作性问题，因为总有一天会发生这种情况。
From the above, it follows that it would be inappropriate for a group of vendors, a consortia, or another Standards Development Organization to agree among themselves to use a particular value for a specific purpose and then agree to deploy devices using those values. By definition, experimental numbers are not guaranteed to be unique in any environment other than one where the local system administrator has chosen to use a particular number for a particular purpose and can ensure that a particular value is not already in use for some other purpose.
综上所述，一组供应商、一个联盟或另一个标准开发组织之间同意将特定值用于特定目的，然后同意使用这些值部署设备是不合适的。根据定义，除了本地系统管理员选择将特定数字用于特定目的，并且可以确保特定值尚未用于其他目的的环境外，实验数字在任何环境中都不保证是唯一的。
Once an extension has been tested and shown to be useful, a permanent number could be obtained through the normal assignment procedures.
一旦扩展被测试并证明是有用的，就可以通过正常的分配程序获得一个永久号码。
Most implementations will not do anything special with numbers assigned for testing purposes. In particular, unless a packet or other Protocol Data Unit (PDU) is specifically directed at a device, that device will not even look at the field while processing the PDU. For example, IP routers do not need to examine or understand the Protocol Type field of IP datagrams in order to know how to correctly forward them. In those cases where a packet or PDU is directed at a device, and that device has not been configured to recognize the extension, the device will either ignore the PDU, discard it, or signal an error, depending on the protocol-specific rules that indicate how to process unknown options or features. In those cases where a protocol has different ways of handling unrecognized extensions (e.g., silently discard vs. signal an error), that protocol needs to reserve values for testing purposes from all the appropriate ranges. Only those implementations specifically enabled or configured to make use of an extension or feature that is being experimented with would process the data further.
大多数实现不会对分配用于测试目的的数字做任何特殊的处理。特别地，除非分组或其他协议数据单元（PDU）专门针对设备，否则该设备在处理PDU时甚至不会查看字段。例如，IP路由器不需要检查或理解IP数据报的协议类型字段，就可以知道如何正确地转发它们。在数据包或PDU指向设备的情况下，该设备尚未配置为识别扩展，设备将忽略PDU、丢弃PDU或发出错误信号，具体取决于指示如何处理未知选项或功能的协议特定规则。在协议处理未识别扩展的方式不同的情况下（例如，静默放弃与发出错误信号），该协议需要从所有适当的范围中保留用于测试目的的值。只有那些专门启用或配置为使用正在试验的扩展或功能的实现才会进一步处理数据。
To make it possible to experiment with protocol extensions safely, protocol documents should consider reserving a small set of protocol numbers for experimentation. Such reservations can be made through an explicit reservation in an IANA Considerations section.
为了使安全地实验协议扩展成为可能，协议文档应该考虑保留一小部分协议号来进行实验。此类保留可通过IANA注意事项部分中的明确保留进行。
The exact number of values to reserve for experimentation will depend on the specific protocol and factors specific to that protocol. For example, in cases where the values of a field are subdivided into ranges that are treated differently (e.g., "silently ignore" vs. "return an error" if the value is not understood), one or more values from each sub-range may need to be reserved.
为实验保留的确切数值将取决于特定协议和该协议特定的因素。例如，如果字段的值被细分为不同处理的范围（例如，“静默忽略”与“返回错误”（如果不理解该值），则可能需要保留每个子范围中的一个或多个值。
For protocols that return error codes, it may also be appropriate to reserve a small number of experimental error values that can be used in conjunction with possible experimental uses. For example, an experimental message might result (even under normal conditions) in an error, with a special error code (or sub-code) indicating the type of error condition.
对于返回错误代码的协议，保留少量可与可能的实验用途结合使用的实验错误值也是合适的。例如，一条实验性消息可能导致（即使在正常情况下）错误，并有一个特殊的错误代码（或子代码）指示错误情况的类型。
In many, if not most cases, reserving a single value for experimental use will suffice. While it may be tempting to reserve more in order to make it easy to test many things at once, reserving many may also increase the temptation for someone using a particular value to assume that a specific experimental value can be used for a given purpose exclusively. Values reserved for experimental use are never to be made permanent; permanent assignments should be obtained through standard processes. As described above, experimental numbers are intended for experimentation and testing and are not intended for wide or general deployments.
在许多情况下（如果不是大多数情况的话），保留一个值供实验使用就足够了。虽然为了方便同时测试许多东西而保留更多可能会很诱人，但保留许多也可能会增加使用特定值的人假设特定实验值可以专门用于给定目的的诱惑。保留供实验使用的数值不得永久化；永久性任务应通过标准流程获得。如上所述，实验数量用于实验和测试，不用于广泛或一般部署。
When protocols that use experimental numbers are included in products, the shipping versions of the products must disable recognition of protocol experimental numbers by default -- that is, the end user of the product must explicitly "turn on" the experimental protocol functionality. In most cases, a product implementation must require the end user to configure the value explicitly prior to enabling its usage. Should a product not have a user interface for such end user configuration, the product must require explicit re-programming (e.g., a special firmware download, or installation of a feature card) to configure the experimental number(s) of the protocol(s) implicitly.
当产品中包含使用实验编号的协议时，产品的装运版本默认情况下必须禁用对协议实验编号的识别——也就是说，产品的最终用户必须显式“打开”实验协议功能。在大多数情况下，产品实现必须要求最终用户在启用其使用之前明确配置该值。如果产品没有用于此类最终用户配置的用户界面，则该产品必须需要显式重新编程（例如，特殊固件下载或功能卡安装），以隐式配置协议的实验编号。
Assignment of new values for the IP Protocol field requires an IETF Standards Action per [RFC2780]. For the purposes of experimentation and testing, IANA has assigned the two values 253 and 254 for this purpose. These values have been allocated from the upper end of the available number space in order to make them easy to identify by having them stand out relative to the existing assignments that have been made.
为IP协议字段分配新值需要按照[RFC2780]执行IETF标准操作。为了进行实验和测试，IANA为此指定了两个值253和254。这些值是从可用数字空间的上端分配的，以便通过使其相对于已进行的现有分配突出而易于识别。
Numerous name spaces exist for which no values have been reserved for experimentation or testing purpose. Experimental values for such protocols can of course be assigned through the normal process of publishing an RFC that documents the details of such an allocation. To simplify the process in those cases where the publication of a documentation just for the purpose of assigning an experimental allocation seems overkill, experimental values can be made through IESG Approval [RFC2434].
存在许多名称空间，没有为其保留值以用于实验或测试目的。当然，这种协议的实验值可以通过发布RFC的正常过程来分配，RFC记录了这种分配的细节。为简化仅为分配实验分配而发布文件的过程，可通过IESG批准[RFC2434]得出实验值。
This document has no known security implications.
此文档没有已知的安全含义。
Improvements to this document came as a result of specific feedback from Steve Bellovin, Scott Bradner, Randy Bush, Bill Fenner, Steve Hanna, Paul Hoffman, Henrik Levkowetz, John Loughney, Allison Mankin, and Richard Woundy.
本文件的改进得益于史蒂夫·贝洛文、斯科特·布拉德纳、兰迪·布什、比尔·芬纳、史蒂夫·汉纳、保罗·霍夫曼、亨里克·列夫科维茨、约翰·洛尼、艾莉森·曼金和理查德·沃迪的具体反馈。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA
美国北卡罗来纳州三角研究园12195号邮政信箱托马斯·纳顿IBM公司，邮编：27709-2195
Phone: +1 919 254 7798
EMail: narten@us.ibm.com
Phone: +1 919 254 7798
EMail: narten@us.ibm.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。