Network Working Group J. Arkko
Request for Comments: 5237 Ericsson
BCP: 37 S. Bradner
Updates: 2780 Harvard University
Category: Best Current Practice February 2008
Network Working Group J. Arkko
Request for Comments: 5237 Ericsson
BCP: 37 S. Bradner
Updates: 2780 Harvard University
Category: Best Current Practice February 2008
IANA Allocation Guidelines for the Protocol Field
协议字段的IANA分配指南
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.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
This document revises the IANA guidelines for allocating new Protocol field values in IPv4 header. It modifies the rules specified in RFC 2780 by removing the Expert Review option. The change will also affect the allocation of Next Header field values in IPv6.
本文档修订了IANA关于在IPv4标头中分配新协议字段值的指南。它通过删除专家评审选项来修改RFC 2780中规定的规则。此更改还将影响IPv6中下一个标头字段值的分配。
This document revises the IANA guidelines [RFC2780] for allocating new Protocol field values in IPv4 header [RFC0791]. The change will also be applicable for IPv6, as the IANA guidelines for IPv6 Next Header values [RFC2460] allocation refer to the IPv4 guidelines.
本文档修订了IANA指南[RFC2780]，用于在IPv4标头[RFC0791]中分配新协议字段值。此更改也将适用于IPv6，因为IANA关于IPv6下一报头值[RFC2460]分配的指南参考了IPv4指南。
Previously, RFC 2780 allowed such allocations to happen through IESG Approval, Standards action, or Expert Review processes [RFC2780][RFC2434]. The Expert Review process was specified to be used only in the case where a non-disclosure agreement was involved:
此前，RFC 2780允许通过IESG批准、标准行动或专家审查流程进行此类分配[RFC2780][RFC2434]。专家审查程序规定仅在涉及保密协议的情况下使用：
IANA allocates values from the IPv4 Protocol name space following an Expert Review, IESG Approval or Standards Action process. The Expert Review process should only be used in those special cases where non-disclosure information is involved. In these cases the expert(s) should be designated by the IESG.
IANA在专家评审、IESG批准或标准行动流程之后从IPv4协议名称空间分配值。专家审查程序只应在涉及保密信息的特殊情况下使用。在这些情况下，专家应由IESG指定。
The need for the Standards Action rule is obvious as the IETF keeps developing new protocols. It is equally obvious that there is a need to allow experimental allocations in this space; see RFC 4727 [RFC4727] for an example. Similarly, there are cases when it makes sense to allocate values out of this space for other non-Standards Track or non-IETF uses. However, the size of the field is 256 values, and 55% of these were in use at the time this document was written. As a result, a sanity check is needed to ensure that
随着IETF不断开发新协议，对标准行动规则的需求是显而易见的。同样明显的是，有必要允许在这一领域进行实验性分配；有关示例，请参见RFC 4727[RFC4727]。类似地，在某些情况下，将该空间中的值分配给其他非标准轨道或非IETF使用是有意义的。但是，字段的大小是256个值，其中55%在编写本文档时正在使用。因此，需要进行健全性检查，以确保
allocations are not made needlessly. RFC 2780 specifies the IESG Approval rule to take care of these sanity checks for the non-Standards Track cases. The judgment call can take into account the existence of a stable protocol specification, constituency that wants to use it, need to avoid duplicated allocations for the same purpose, whether protocol number allocation is the right solution for this problem as opposed to, say, a TCP port, and so on.
分配不是不必要的。RFC 2780规定了IESG批准规则，以对非标准跟踪案例进行这些健全性检查。判断调用可以考虑是否存在稳定的协议规范、希望使用它的用户群、是否需要为相同目的避免重复分配、协议号分配是否是解决此问题的正确方法（例如TCP端口）等等。
However, we now believe that the non-disclosure agreement option is not appropriate for allocations in this space. Traditionally, non-disclosure agreements have been used by the IANA when a company was developing a proprietary protocol and did not want to disclose new areas of research or future products. The protocol space is limited enough that we no longer believe that it is reasonable to use the resource for such proprietary protocols. Thus, we believe that allocations should only be made using the IESG Approval or Standards Action processes when there are public specifications that can be reviewed.
然而，我们现在认为，保密协议选项不适用于该领域的分配。传统上，IANA在公司开发专有协议时使用保密协议，不想披露新的研究领域或未来产品。协议空间有限，我们不再认为将资源用于此类专有协议是合理的。因此，我们认为，只有在存在可审查的公共规范时，才应使用IESG批准或标准行动流程进行分配。
As a result, this document revises the RFC 2780 rules by removing the option for Expert Review for the IPv4 Protocol and IPv6 Next Header fields. This document takes no position on the allocation of other parameters with non-disclosure agreements, as those parameters may require different policies.
因此，本文档修改了RFC 2780规则，删除了IPv4协议和IPv6下一个标头字段的专家评审选项。本文件对保密协议中其他参数的分配不采取任何立场，因为这些参数可能需要不同的政策。
This document replaces the RFC 2780 Section 4.3 rule [RFC2780] with the following:
本文件将RFC 2780第4.3节规则[RFC2780]替换为以下内容：
IANA allocates values from the IPv4 Protocol name space following an IESG Approval or Standards Action process.
IANA根据IESG批准或标准操作流程从IPv4协议名称空间分配值。
This document also makes an implicit change to the rule for the IPv6 Next Header field in Section 5.3 of RFC 2780. That rule refers to the rule in Section 4.3 of the same RFC. From now on, this reference should be understood to refer to the rule revised here, i.e., without the Expert Review option.
本文档还对RFC 2780第5.3节中IPv6下一个标头字段的规则进行了隐式更改。该规则引用同一RFC第4.3节中的规则。从现在起，此参考应理解为参考此处修订的规则，即没有专家审查选项。
This specification does not change the security properties of the affected protocols.
此规范不会更改受影响协议的安全属性。
Issues with the original RFC 2780 rules were uncovered in discussions of the IETF-IANA team. The team also provided background information on the practical difficulties encountered with non-disclosure agreements. The authors would like to thank Thomas Narten, Bill Fenner, and Michelle Cotton in particular.
在IETF-IANA团队的讨论中，发现了原始RFC 2780规则的问题。该小组还提供了关于保密协议遇到的实际困难的背景资料。作者要特别感谢托马斯·纳顿、比尔·芬纳和米歇尔·科顿。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[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月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[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月。
[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月。
Section 4.3 from RFC 2780 has been changed from:
RFC 2780第4.3节已由以下内容更改：
IANA allocates values from the IPv4 Protocol name space following an Expert Review, IESG Approval or Standards Action process. The Expert Review process should only be used in those special cases where non-disclosure information is involved. In these cases the expert(s) should be designated by the IESG.
IANA在专家评审、IESG批准或标准行动流程之后从IPv4协议名称空间分配值。专家审查程序只应在涉及保密信息的特殊情况下使用。在这些情况下，专家应由IESG指定。
to:
致：
IANA allocates values from the IPv4 Protocol name space following an IESG Approval or Standards Action process.
IANA根据IESG批准或标准操作流程从IPv4协议名称空间分配值。
In addition, RFC 2780 Section 5.3 reference to IPv4 rules should be understood to refer to the rule revised here, i.e., without the Expert Review option.
此外，RFC 2780第5.3节对IPv4规则的引用应理解为指此处修订的规则，即没有专家审查选项。
Authors' Addresses
作者地址
Jari Arkko Ericsson Jorvas 02420 Finland
雅丽爱立信芬兰公司02420
EMail: jari.arkko@piuha.net
EMail: jari.arkko@piuha.net
Scott Bradner Harvard University Cambridge, MA 02138 US
斯科特·布拉德纳哈佛大学剑桥，马萨诸塞州02138美国
Phone: +1 617 495 3864
EMail: sob@harvard.edu
Phone: +1 617 495 3864
EMail: sob@harvard.edu
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.