Internet Architecture Board (IAB) B. Carpenter
Request for Comments: 6709 B. Aboba, Ed.
Category: Informational S. Cheshire
ISSN: 2070-1721 September 2012
Internet Architecture Board (IAB) B. Carpenter
Request for Comments: 6709 B. Aboba, Ed.
Category: Informational S. Cheshire
ISSN: 2070-1721 September 2012
Design Considerations for Protocol Extensions
协议扩展的设计考虑
Abstract
摘要
This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols.
本文档讨论与Internet协议的可扩展性相关的体系结构问题，重点讨论设计考虑事项。它旨在帮助基本协议和扩展的设计者。包括案例研究。配套文件RFC 4775（BCP 125）讨论了与IETF协议可扩展性相关的程序。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见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/rfc6709.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6709.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 ....................................................3
1.1. Requirements Language ......................................4
2. Routine and Major Extensions ....................................4
2.1. What Constitutes a Major Extension? ........................4
2.2. When is an Extension Routine? ..............................6
3. Architectural Principles ........................................7
3.1. Limited Extensibility ......................................7
3.2. Design for Global Interoperability .........................8
3.3. Architectural Compatibility ...............................12
3.4. Protocol Variations .......................................13
3.5. Testability ...............................................16
3.6. Protocol Parameter Registration ...........................16
3.7. Extensions to Critical Protocols ..........................17
4. Considerations for the Base Protocol ...........................18
4.1. Version Numbers ...........................................19
4.2. Reserved Fields ...........................................22
4.3. Encoding Formats ..........................................23
4.4. Parameter Space Design ....................................23
4.5. Cryptographic Agility .....................................26
4.6. Transport .................................................27
4.7. Handling of Unknown Extensions ............................28
5. Security Considerations ........................................29
6. References .....................................................30
6.1. Normative References ......................................30
6.2. Informative References ....................................30
7. Acknowledgments ................................................35
8. IAB Members at the Time of Approval ............................35
Appendix A. Examples .............................................36
A.1. Already-Documented Cases ..................................36
A.2. RADIUS Extensions .........................................36
A.3. TLS Extensions ............................................39
A.4. L2TP Extensions ...........................................41
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Routine and Major Extensions ....................................4
2.1. What Constitutes a Major Extension? ........................4
2.2. When is an Extension Routine? ..............................6
3. Architectural Principles ........................................7
3.1. Limited Extensibility ......................................7
3.2. Design for Global Interoperability .........................8
3.3. Architectural Compatibility ...............................12
3.4. Protocol Variations .......................................13
3.5. Testability ...............................................16
3.6. Protocol Parameter Registration ...........................16
3.7. Extensions to Critical Protocols ..........................17
4. Considerations for the Base Protocol ...........................18
4.1. Version Numbers ...........................................19
4.2. Reserved Fields ...........................................22
4.3. Encoding Formats ..........................................23
4.4. Parameter Space Design ....................................23
4.5. Cryptographic Agility .....................................26
4.6. Transport .................................................27
4.7. Handling of Unknown Extensions ............................28
5. Security Considerations ........................................29
6. References .....................................................30
6.1. Normative References ......................................30
6.2. Informative References ....................................30
7. Acknowledgments ................................................35
8. IAB Members at the Time of Approval ............................35
Appendix A. Examples .............................................36
A.1. Already-Documented Cases ..................................36
A.2. RADIUS Extensions .........................................36
A.3. TLS Extensions ............................................39
A.4. L2TP Extensions ...........................................41
When developing protocols, IETF Working Groups (WGs) often include mechanisms whereby these protocols can be extended in the future. It is often a good principle to design extensibility into protocols; as described in "What Makes for a Successful Protocol" [RFC5218], a "wildly successful" protocol is one that becomes widely used in ways not originally anticipated. Well-designed extensibility mechanisms facilitate the evolution of protocols and help make it easier to roll out incremental changes in an interoperable fashion. However, at the same time, experience has shown that extensions carry the risk of unintended consequences, such as interoperability issues, operational problems, or security vulnerabilities.
在开发协议时，IETF工作组（WG）通常包括将来可以扩展这些协议的机制。将可扩展性设计成协议通常是一个好的原则；正如“成功协议的要素”[RFC5218]中所述，“非常成功”的协议是以最初未预期的方式广泛使用的协议。设计良好的可扩展性机制有助于协议的发展，并有助于以可互操作的方式更轻松地推出增量更改。然而，与此同时，经验表明，扩展带来了意外后果的风险，例如互操作性问题、操作问题或安全漏洞。
The proliferation of extensions, even well-designed ones, can be costly. As noted in "Simple Mail Transfer Protocol" [RFC5321] Section 2.2.1:
扩展的扩散，即使是设计良好的扩展，也可能代价高昂。如“简单邮件传输协议”[RFC5321]第2.2.1节所述：
Experience with many protocols has shown that protocols with few options tend towards ubiquity, whereas protocols with many options tend towards obscurity.
许多协议的经验表明，选项少的协议趋向于普遍存在，而选项多的协议趋向于模糊。
Each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs.
每一个扩展，无论其好处如何，都必须仔细检查其实现、部署和互操作性成本。
This is hardly a recent concern. "TCP Extensions Considered Harmful" [RFC1263] was published in 1991. "Extend" or "extension" occurs in the title of more than 400 existing Request for Comments (RFC) documents. Yet, generic extension considerations have not been documented previously.
这并不是最近的问题。“TCP扩展被认为是有害的”[RFC1263]发表于1991年。“扩展”或“扩展”出现在400多个现有征求意见（RFC）文件的标题中。然而，以前还没有记录通用扩展注意事项。
The purpose of this document is to describe the architectural principles of sound extensibility design, in order to minimize such risks. Formal procedures for extending IETF protocols are discussed in "Procedures for Protocol Extensions and Variations" BCP 125 [RFC4775].
本文档的目的是描述声音可扩展性设计的架构原则，以便将此类风险降至最低。扩展IETF协议的正式程序在“协议扩展和变更程序”BCP 125[RFC4775]中讨论。
The rest of this document is organized as follows: Section 2 discusses routine and major extensions. Section 3 describes architectural principles for protocol extensibility. Section 4 explains how designers of base protocols can take steps to anticipate and facilitate the creation of such subsequent extensions in a safe and reliable manner. Section 5 discusses security considerations. Appendix A provides case studies.
本文档的其余部分组织如下：第2节讨论例程和主要扩展。第3节描述了协议扩展性的体系结构原则。第4节解释了基本协议的设计人员如何采取步骤，以安全可靠的方式预测并促进后续扩展的创建。第5节讨论了安全注意事项。附录A提供了案例研究。
Readers are advised to study the whole document, since the considerations are closely linked.
建议读者研究整个文件，因为考虑因素是紧密相连的。
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 "Key words for use in RFCs to Indicate Requirement Levels" BCP 14 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中“RFC中用于表示需求水平的关键词”中的描述进行解释。
The risk of unintended consequences from an extension is especially high if the extension is performed by a different team than the original designers, who may stray outside implicit design constraints or assumptions. As a result, it is highly desirable for the original designers to articulate the design constraints and assumptions, so as to enable extensions to be done carefully and with a full understanding of the base protocol, existing implementations, and current operational practice.
如果扩展由不同于原始设计师的团队执行，则扩展产生意外后果的风险尤其高，因为原始设计师可能会偏离隐含的设计约束或假设。因此，最初的设计人员非常希望清楚地表述设计约束和假设，以便能够在充分了解基本协议、现有实现和当前操作实践的情况下仔细地进行扩展。
To assist extension designers and reviewers, protocol documents should provide guidelines explaining how extensions should be performed, and guidance on how protocol extension mechanisms should be used.
为了帮助扩展设计者和评审者，协议文档应该提供指南，解释如何执行扩展，以及如何使用协议扩展机制。
Protocol components that are designed with the specific intention of allowing extensibility should be clearly identified, with specific and complete instructions on how to extend them. This includes the process for adequate review of extension proposals: do they need community review, and if so, how much and by whom?
应该清楚地标识那些设计有允许扩展性的特定意图的协议组件，并提供关于如何扩展它们的具体而完整的说明。这包括对扩展提案进行充分审查的过程：它们是否需要社区审查，如果需要，需要多少以及由谁进行审查？
The level of review required for protocol extensions will typically vary based on the nature of the extension. Routine extensions may require minimal review, while major extensions may require wide review. Guidance on which extensions may be considered 'routine' and which ones are 'major' is provided in the sections that follow.
协议扩展所需的审查级别通常会根据扩展的性质而有所不同。常规扩展可能需要最少的审查，而主要扩展可能需要广泛的审查。关于哪些扩展可以被视为“常规”以及哪些扩展是“主要”的指导，请参见以下章节。
Major extensions may have characteristics leading to a risk of interoperability failures, security vulnerabilities, or operational problems. Where these characteristics are present, it is necessary to pay close attention to backward compatibility with implementations and deployments of the unextended protocol and to the potential for inadvertent introduction of security or operational exposures.
主要扩展可能具有导致互操作性故障、安全漏洞或操作问题风险的特征。如果存在这些特征，则有必要密切注意与未扩展协议的实现和部署的向后兼容性，以及无意中引入安全或操作风险的可能性。
Extension designers should examine their design for the following issues:
扩展设计人员应检查其设计是否存在以下问题：
1. Modifications or extensions to the underlying protocol. An extension document should be considered to update the underlying protocol specification if an implementation of the underlying protocol would need to be updated to accommodate the extension. This should not be necessary if the underlying protocol was designed with a modular interface. Examples of extensions modifying the underlying protocol include specification of additional transports (see Section 4.6), changing protocol semantics, or defining new message types that may require implementation changes in existing and deployed implementations of the protocol, even if they do not want to make use of the new functions. A base protocol that does not uniformly permit "silent discard" of unknown extensions may automatically enter this category, even for apparently minor extensions. Handling of "unknown" extensions is discussed in more detail in Section 4.7.
1. 对基础协议的修改或扩展。如果需要更新基础协议的实现以适应扩展，则应考虑使用扩展文档来更新基础协议规范。如果底层协议是用模块化接口设计的，则不需要这样做。修改底层协议的扩展示例包括指定其他传输（参见第4.6节）、更改协议语义或定义可能需要在现有和已部署的协议实现中进行实现更改的新消息类型，即使它们不想使用新功能。一个基本协议，如果不统一地允许未知扩展的“静默丢弃”，可能会自动进入这个类别，即使是明显较小的扩展。第4.7节将更详细地讨论“未知”扩展的处理。
2. Changes to the basic architectural assumptions. This may include architectural assumptions that are explicitly stated or those that have been assumed by implementers. For example, this would include adding a requirement for session state to a previously stateless protocol.
2. 对基本架构假设的更改。这可能包括明确说明的架构假设或实现者已经假设的架构假设。例如，这将包括将会话状态的要求添加到以前的无状态协议中。
3. New usage scenarios not originally intended or investigated. This can potentially lead to operational difficulties when deployed, even in cases where the "on-the-wire" format has not changed. For example, the level of traffic carried by the protocol may increase substantially, packet sizes may increase, and implementation algorithms that are widely deployed may not scale sufficiently or otherwise be up to the new task at hand. For example, a new DNS Resource Record (RR) type that is too big to fit into a single UDP packet could cause interoperability problems with existing DNS clients and servers. Similarly, the additional traffic that results from an extension to a routing protocol could have a detrimental impact on the performance or stability of implementations that do not implement the extension.
3. 最初未打算或未调查的新使用场景。这可能会在部署时导致操作困难，即使在“在线”格式没有更改的情况下也是如此。例如，协议所承载的业务量的级别可能会大幅增加，分组大小可能会增加，并且广泛部署的实现算法可能无法充分扩展，或者无法满足手头的新任务。例如，新的DNS资源记录（RR）类型太大，无法装入单个UDP数据包，可能会导致与现有DNS客户端和服务器的互操作性问题。类似地，路由协议扩展产生的额外流量可能对未实现扩展的实现的性能或稳定性产生不利影响。
4. Changes to the extension model. Adverse impacts are very likely if the base protocol contains an extension mechanism and the proposed extension does not fit into the model used to create and define that mechanism. Extensions that have the same properties as those that were anticipated when an extension mechanism was devised are much less likely to be disruptive than extensions that don't fit the model. Also, changes to the extension model itself (including changes limiting further extensibility) can create interoperability problems.
4. 对扩展模型的更改。如果基本协议包含扩展机制，并且提议的扩展不适合用于创建和定义该机制的模型，则很可能产生不利影响。与不符合模型的扩展相比，具有与设计扩展机制时预期的相同属性的扩展破坏性要小得多。此外，对扩展模型本身的更改（包括限制进一步扩展性的更改）可能会产生互操作性问题。
5. Changes to protocol syntax. Changes to protocol syntax bring with them the potential for backward-compatibility issues. If at all possible, extensions should be designed for compatibility with existing syntax, so as to avoid interoperability failures.
5. 对协议语法的更改。协议语法的更改带来了潜在的向后兼容性问题。如果可能，扩展的设计应该与现有语法兼容，以避免互操作性故障。
6. Interrelated extensions to multiple protocols. A set of interrelated extensions to multiple protocols typically carries a greater danger of interoperability issues or incompatibilities than a simple extension. Consequently, it is important that such proposals receive earlier and more in-depth review than unitary extensions.
6. 多协议的相关扩展。与简单的扩展相比，对多个协议的一组相互关联的扩展通常会带来更大的互操作性问题或不兼容风险。因此，重要的是，此类提案应比单一延期得到更早和更深入的审查。
7. Changes to the security model. Changes to the protocol security model (or even addition of new security mechanisms within an existing framework) can introduce security vulnerabilities or adversely impact operations. Consequently, it is important that such proposals undergo security as well as operational review. Security considerations are discussed in Section 5.
7. 对安全模型的更改。对协议安全模型的更改（甚至在现有框架内添加新的安全机制）可能会引入安全漏洞或对操作产生不利影响。因此，必须对这些建议进行安全审查和业务审查。第5节讨论了安全注意事项。
8. Performance impact. An extension that impacts performance can have adverse consequences, particularly if the performance of existing deployments is affected.
8. 性能影响。影响性能的扩展可能会产生不利后果，尤其是在现有部署的性能受到影响的情况下。
An extension may be considered 'routine' if it does not meet the criteria for being considered a 'major' extension and if its handling is opaque to the protocol itself (e.g., does not substantially change the pattern of messages and responses). For this to apply, no changes to the base protocol can be required, nor can changes be required to existing and currently deployed implementations, unless they make use of the extension. Furthermore, existing implementations should not be impacted. This typically requires that implementations be able to ignore 'routine' extensions without ill effects.
如果扩展不符合被视为“主要”扩展的标准，并且其处理对协议本身不透明（例如，没有实质性地改变消息和响应的模式），则可以将其视为“常规”。要应用此功能，不需要更改基本协议，也不需要更改现有和当前部署的实现，除非它们使用扩展。此外，现有的实现不应受到影响。这通常要求实现能够忽略“例程”扩展而不会产生不良影响。
Examples of routine extensions include the Dynamic Host Configuration Protocol (DHCP) vendor-specific option [RFC2132], Remote Authentication Dial In User Service (RADIUS) Vendor-Specific Attributes [RFC2865], the enterprise Object IDentifier (OID) tree for Management Information Base (MIB) modules, and vendor Multipurpose Internet Mail Extension (MIME) types. Such extensions can safely be made with minimal discussion.
例程扩展的示例包括动态主机配置协议（DHCP）供应商特定选项[RFC2132]、远程身份验证拨入用户服务（RADIUS）供应商特定属性[RFC2865]、管理信息库（MIB）模块的企业对象标识符（OID）树以及供应商多用途Internet邮件扩展（MIME）类型。只需很少的讨论就可以安全地进行此类扩展。
Processes that allow routine extensions with minimal or no review (such as "First Come First Served" (FCFS) allocation [RFC5226]) should be used sparingly. In particular, they should be limited to cases that are unlikely to result in interoperability problems or in security or operational exposures.
应谨慎使用允许在最少或不审查的情况下进行常规扩展的流程（如“先到先得”（FCFS）分配[RFC5226]）。特别是，它们应限于不太可能导致互操作性问题或安全或操作风险的情况。
Experience has shown that even routine extensions may benefit from review by experts. For example, even though DHCP carries opaque data, defining a new option using completely unstructured data may lead to an option that is unnecessarily hard for clients and servers to process.
经验表明，即使是常规的扩展也可能受益于专家的审查。例如，即使DHCP携带不透明的数据，但使用完全非结构化的数据定义新选项可能会导致客户端和服务器难以处理的选项。
This section describes basic principles of protocol extensibility:
本节介绍协议扩展性的基本原则：
1. Extensibility features should be limited to what is reasonably anticipated when the protocol is developed.
1. 可扩展性特性应限制在协议开发时合理预期的范围内。
2. Protocol extensions should be designed for global interoperability.
2. 协议扩展应设计为全球互操作性。
3. Protocol extensions should be architecturally compatible with the base protocol.
3. 协议扩展应该在架构上与基本协议兼容。
4. Protocol extension mechanisms should not be used to create incompatible protocol variations.
4. 协议扩展机制不应用于创建不兼容的协议变体。
5. Extension mechanisms need to be testable.
5. 扩展机制需要是可测试的。
6. Protocol parameter assignments need to be coordinated to avoid potential conflicts.
6. 需要协调协议参数分配，以避免潜在冲突。
7. Extensions to critical components require special care. A critical component is one whose failure can lead to Internet-wide reliability and security issues or performance degradation.
7. 关键组件的扩展需要特别小心。关键组件的故障可能导致整个互联网的可靠性和安全问题或性能下降。
Protocols should not be made more extensible than clearly necessary at inception, in order to enable optimization along dimensions (e.g., bandwidth, state, memory requirements, deployment time, latency, etc.) important to the most common use cases.
协议的可扩展性不应超过开始时明确需要的程度，以实现对最常见用例重要的维度（例如带宽、状态、内存需求、部署时间、延迟等）的优化。
The process for defining new extensibility mechanisms should ensure that adequate review of proposed extensions will take place before widespread adoption.
定义新扩展机制的过程应确保在广泛采用之前对提议的扩展进行充分审查。
As noted in "What Makes for a Successful Protocol" [RFC5218], "wildly successful" protocols far exceed their original goals, in terms of scale, purpose (being used in scenarios far beyond the initial design), or both. This implies that all potential uses may not be known at inception. As a result, extensibility mechanisms may need to be revisited as additional use cases reveal themselves. However, this does not imply that an initial design needs to take all potential needs into account at inception.
如“成功协议的要素”[RFC5218]所述，“非常成功”的协议在规模、目的（用于远远超出初始设计的场景）或两者方面远远超出了其原始目标。这意味着所有潜在的用途可能在一开始就不知道。因此，随着其他用例的出现，可能需要重新审视可扩展性机制。然而，这并不意味着初始设计需要在开始时考虑所有潜在需求。
Section 3.1 of "Procedures for Protocol Extensions and Variations" BCP 125 [RFC4775] notes:
“协议扩展和变更程序”BCP 125[RFC4775]第3.1节注释：
According to its Mission Statement [RFC3935], the IETF produces high quality, relevant technical and engineering documents, including protocol standards. The mission statement goes on to say that the benefit of these standards to the Internet "is in interoperability - that multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users".
根据其任务声明[RFC3935]，IETF生产高质量、相关的技术和工程文件，包括协议标准。使命声明接着说，这些标准对互联网的好处在于“互操作性——实现一个标准的多个产品能够协同工作，以便向互联网用户提供有价值的功能”。
One consequence of this mission is that the IETF designs protocols for the single Internet. The IETF expects its protocols to work the same everywhere. Protocol extensions designed for limited environments may be reasonable provided that products with these extensions interoperate with products without the extensions. Extensions that break interoperability are unacceptable when products with and without the extension are mixed. It is the IETF's experience that this tends to happen on the Internet even when the original designers of the extension did not expect this to happen.
该任务的一个结果是IETF为单一互联网设计协议。IETF希望其协议在任何地方都能起到相同的作用。为有限环境设计的协议扩展可能是合理的，前提是具有这些扩展的产品可以与不具有这些扩展的产品进行互操作。当带有和不带有扩展的产品混合使用时，破坏互操作性的扩展是不可接受的。根据IETF的经验，这种情况往往发生在互联网上，即使扩展的原始设计者并不期望这种情况发生。
Another consequence of this definition of interoperability is that the IETF values the ability to exchange one product implementing a protocol with another. The IETF often specifies mandatory-to-implement functionality as part of its protocols so that there is a core set of functionality sufficient for interoperability that all products implement. The IETF tries to avoid situations where protocols need to be profiled to specify which optional features are required for a given environment, because doing so harms interoperability on the Internet as a whole.
互操作性定义的另一个结果是IETF重视实现协议的一个产品与另一个产品的交换能力。IETF通常指定强制实现功能作为其协议的一部分，以便有一组核心功能足以实现所有产品实现的互操作性。IETF试图避免需要分析协议以指定给定环境需要哪些可选功能的情况，因为这样做会损害整个Internet上的互操作性。
Since the global Internet is more than a collection of incompatible protocols (or "profiles") for use in separate private networks, implementers supporting extensions in shipping products or multi-site experimental usage must assume that systems will need to interoperate on the global Internet.
由于全球互联网不仅仅是在单独的专用网络中使用的不兼容协议（或“配置文件”）的集合，支持运输产品扩展或多站点实验使用的实施者必须假设系统需要在全球互联网上进行互操作。
A key requirement for interoperable extension design is that the base protocol must be well designed for interoperability and that extensions must have unambiguous semantics. Ideally, the protocol mechanisms for extension and versioning should be sufficiently well described that compatibility can be assessed on paper. Otherwise, when two "private" or "experimental" extensions encounter each other on a public network, unexpected interoperability problems may occur. However, as noted in the Transport Layer Security (TLS) case study (Appendix A.3), it is not sufficient to design extensibility carefully; it also must be implemented carefully.
可互操作扩展设计的一个关键要求是，基本协议必须针对互操作性进行良好设计，并且扩展必须具有明确的语义。理想情况下，扩展和版本控制的协议机制应该得到充分的描述，以便可以在纸上评估兼容性。否则，当两个“私有”或“实验”扩展在公共网络上相遇时，可能会出现意外的互操作性问题。然而，正如传输层安全（TLS）案例研究（附录A.3）中所述，仔细设计可扩展性是不够的；它也必须认真执行。
Experience shows that separate private networks often end up having portable equipment like laptop computers move between them, and networks that were originally envisaged as being separate can end up being connected later.
经验表明，独立的专用网络通常会在它们之间移动便携式设备，如笔记本电脑，而最初设想为独立的网络可能会在以后连接。
Consider a "private" extension installed on a work computer that, being portable, is sometimes connected to networks other than the work network, like a home network or a hotel network. If the "private" extension is incompatible with an unextended version of the same protocol, problems will occur.
考虑安装在工作计算机上的一个“私人”扩展，它是可移植的，有时连接到工作网络以外的网络，例如家庭网络或酒店网络。如果“专用”扩展与同一协议的未扩展版本不兼容，则会出现问题。
Similarly, problems can occur if "private" extensions conflict with each other. For example, imagine the situation where one site chose to use DHCP [RFC2132] option code 62 for one meaning and a different site chose to use DHCP option code 62 for a completely different, incompatible, meaning. It may be impossible for a vendor of portable computing devices to make a device that works correctly in both environments.
类似地，如果“私有”扩展相互冲突，也会出现问题。例如，假设一个站点选择使用DHCP[RFC2132]选项代码62表示一种含义，而另一个站点选择使用DHCP选项代码62表示完全不同、不兼容的含义。便携式计算设备的供应商可能不可能制造出在两种环境下都能正常工作的设备。
One approach to solving this problem has been to reserve parts of an identifier namespace for "limited applicability" or "site-specific" use, such as "X-" headers in email messages [RFC822] or "P-" headers in SIP [RFC3427]. However, as noted in "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols" [RFC6648], Appendix B:
解决此问题的一种方法是保留标识符名称空间的一部分用于“有限适用性”或“特定于站点”的使用，例如电子邮件[RFC822]中的“X-”头或SIP[RFC3427]中的“P-”头。然而，正如“反对应用协议中的“X-”前缀和类似结构”[RFC6648]中所述，附录B：
The primary problem with the "X-" convention is that unstandardized parameters have a tendency to leak into the protected space of standardized parameters, thus introducing the need for migration from the "X-" name to a standardized name. Migration, in turn, introduces interoperability issues (and sometimes security issues) because older implementations will support only the "X-" name and newer implementations might support only the standardized name. To preserve interoperability, newer implementations simply support the "X-" name forever, which means
“X-”约定的主要问题是，非标准化参数有泄漏到标准化参数的受保护空间的趋势，因此需要从“X-”名称迁移到标准化名称。迁移反过来会带来互操作性问题（有时还会带来安全问题），因为较旧的实现只支持“X-”名称，而较新的实现可能只支持标准化名称。为了保持互操作性，较新的实现只需永远支持“X-”名称，这意味着
that the unstandardized name has become a de facto standard (thus obviating the need for segregation of the name space into standardized and unstandardized areas in the first place).
非标准化名称已成为事实上的标准（因此，首先无需将名称空间划分为标准化和非标准化区域）。
As a result, the notion of "X-" headers from the 1982 Internet Message Format standard [RFC822] was removed when the specification was updated in 2001 [RFC2822]. Within SIP, the guidance published in 2002 regarding "P-" headers [RFC3427] was deprecated eight years later in Section 4 of the 2010 update [RFC5727]. More generally, as noted in Section 1 of the "X-" prefix deprecation document [RFC6648]:
因此，在2001年更新规范[RFC2822]时，1982年互联网消息格式标准[RFC822]中的“X-”头的概念被删除。在SIP内部，2002年发布的关于“P-”标题[RFC3427]的指南在8年后的2010年更新[RFC5727]第4节中被弃用。更一般地说，如“X-”前缀弃用文件[RFC6648]第1节所述：
This document generalizes from the experience of the email and SIP communities by doing the following:
本文档通过以下方式总结了电子邮件和SIP社区的经验：
1. Deprecates the "X-" convention for newly defined parameters in application protocols, including new parameters for established protocols. This change applies even where the "X-" convention was only implicit, and not explicitly provided, such as was done for email in [RFC822].
1. 反对应用程序协议中新定义参数的“X-”约定，包括已建立协议的新参数。即使“X-”约定只是隐式的，而不是显式的，如[RFC822]中对电子邮件所做的那样，这种更改也适用。
Values designated as "experimental" or "local use" are only appropriate in limited circumstances such as in early implementations of an extension restricted to a single site.
指定为“实验性”或“本地使用”的值仅适用于有限的情况，例如早期实现的仅限于单个站点的扩展。
For example, "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers" [RFC4727] discusses experimental values for IP and transport headers, and "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474] defines experimental/local use ranges for differentiated services code points.
例如，“IPv4、IPv6、ICMPv4、ICMPv6、UDP和TCP报头中的实验值”[RFC4727]讨论IP和传输报头的实验值，以及“IPv4和IPv6报头中区分服务字段（DS字段）的定义”[RFC2474]定义区分服务代码点的实验/本地使用范围。
Such values should be used with care and only for their stated purpose: experiments and local use. They are unsuitable for Internet-wide use, since they may be used for conflicting purposes and thereby cause interoperability failures. Packets containing experimental or local use values must not be allowed out of the domain in which they are meaningful.
此类值应谨慎使用，且仅用于其规定目的：实验和局部使用。它们不适合在Internet范围内使用，因为它们可能用于相互冲突的目的，从而导致互操作性故障。包含实验或本地使用值的数据包不得超出其有意义的域。
Section 1 of "Assigning Experimental and Testing Numbers Considered Useful" BCP 82 [RFC3692] provides guidance on the use of experimental code points:
BCP 82[RFC3692]中“分配被认为有用的实验和测试数字”的第1节提供了关于使用实验代码点的指南：
Numbers in the experimentation range ... 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.
需要明确启用实验功能，并且同样能够从实验范围中选择和分配用于特定目的的数字（即，最终用户可以确保特定数字的使用不会与其他正在进行的使用冲突）。装运预先启用了特定值的产品是不合适的，并且当所选值与不同的用法发生冲突时，可能会导致互操作性问题，这一点有朝一日肯定会发生。
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.
一旦扩展被测试并证明是有用的，就可以通过正常的分配程序获得一个永久号码。
However, as noted in Appendix B of the "X-" prefix deprecation document [RFC6648], assigning a parameter block for experimental use is only necessary when the parameter pool is limited:
然而，如“X-”前缀弃用文件[RFC6648]附录B所述，仅当参数池受到限制时，才有必要为实验使用分配参数块：
"Assigning Experimental and Testing Numbers Considered Useful" ...
implies that the "X-" prefix is also useful for experimental
parameters. However, BCP 82 addresses the need for protocol
numbers when the pool of such numbers is strictly limited (e.g.,
DHCP options) or when a number is absolutely required even for
purely experimental purposes (e.g., the Protocol field of the IP
header). In almost all application protocols that make use of
protocol parameters (including email headers, media types, HTTP
headers, vCard parameters and properties, URNs, and LDAP field
names), the name space is not limited or constrained in any way,
so there is no need to assign a block of names for private use or
experimental purposes....
"Assigning Experimental and Testing Numbers Considered Useful" ...
implies that the "X-" prefix is also useful for experimental
parameters. However, BCP 82 addresses the need for protocol
numbers when the pool of such numbers is strictly limited (e.g.,
DHCP options) or when a number is absolutely required even for
purely experimental purposes (e.g., the Protocol field of the IP
header). In almost all application protocols that make use of
protocol parameters (including email headers, media types, HTTP
headers, vCard parameters and properties, URNs, and LDAP field
names), the name space is not limited or constrained in any way,
so there is no need to assign a block of names for private use or
experimental purposes....
Therefore, it appears that segregating the parameter space into a standardized area and a unstandardized area has few, if any, benefits and has at least one significant cost in terms of interoperability.
因此，将参数空间划分为标准化区域和非标准化区域似乎没有什么好处（如果有的话），并且在互操作性方面至少有一个显著的成本。
Where an experiment is undertaken among a diverse set of experimental sites connected via the global Internet, the use of "experimental" or "local use" code points is inadvisable. This might include, for example, sites that take a prototype implementation of some protocol and use that both within their site but, importantly, among the full set of other sites interested in that protocol. In such a situation, it is impractical and probably impossible to coordinate the de-confliction of "experimental" code points. Section 4.1 of the IANA Considerations guidelines document [RFC5226] notes:
如果在通过全球互联网连接的多个实验站点之间进行实验，则不建议使用“实验”或“本地使用”代码点。例如，这可能包括采用某个协议的原型实现并在其站点内使用该协议的站点，但更重要的是，在对该协议感兴趣的所有其他站点中使用该协议的站点。在这种情况下，协调“实验性”代码点的冲突消除是不切实际的，也可能是不可能的。IANA考虑事项指南文件[RFC5226]第4.1节注释：
For private or local use ... No attempt is made to prevent
multiple sites from using the same value in different (and
incompatible) ways.... assignments are not generally useful for
broad interoperability. It is the responsibility of the sites
making use of the Private Use range to ensure that no conflicts
occur (within the intended scope of use).
For private or local use ... No attempt is made to prevent
multiple sites from using the same value in different (and
incompatible) ways.... assignments are not generally useful for
broad interoperability. It is the responsibility of the sites
making use of the Private Use range to ensure that no conflicts
occur (within the intended scope of use).
The Host Identity Protocol (HIP) [RFC5201] and the Locator/ID Separation Protocol [LISP] are examples where a set of experimental sites are collaborating among themselves, but not necessarily in a tightly coordinated way. Both HIP and LISP have dealt with this by having unique non-experimental code points allocated to HIP and LISP, respectively, at the time of publication of their respective Experimental RFCs.
主机标识协议（HIP）[RFC5201]和定位器/ID分离协议[LISP]是一组实验站点相互协作但不一定以紧密协调的方式协作的示例。HIP和LISP在各自的实验RFC发布时，分别为HIP和LISP分配了唯一的非实验性代码点，从而解决了这一问题。
Since protocol extension mechanisms may impact interoperability, it is important that they be architecturally compatible with the base protocol.
由于协议扩展机制可能会影响互操作性，因此它们在体系结构上与基本协议兼容非常重要。
This includes understanding what current implementations do and how a proposed extension will interact with deployed systems. Is it clear when a proposed extension (or its proposed usage), if widely deployed, will operationally stress existing implementations or the underlying protocol itself? If this is not explained in the base protocol specification, is this covered in an extension design guidelines document?
这包括了解当前实现的功能，以及建议的扩展将如何与部署的系统交互。如果广泛部署了一个提议的扩展（或其提议的使用），何时会在操作上对现有实现或底层协议本身造成压力，这一点是否清楚？如果基本协议规范中没有对此进行解释，那么扩展设计指南文档中是否涵盖了这一点？
As part of the definition of a new extension, it is important to address whether the extension makes use of features as envisaged by the original protocol designers, or whether a new extension mechanism is being invented. If a new extension mechanism is being invented, then architectural compatibility issues need to be addressed.
作为新扩展定义的一部分，重要的是要说明扩展是否使用了原始协议设计者设想的功能，或者是否正在发明新的扩展机制。如果正在发明一种新的扩展机制，那么需要解决架构兼容性问题。
To assist in the assessment of architectural compatibility, protocol documents should provide guidelines explaining how extensions should be performed, and guidance on how protocol extension mechanisms should be used.
为了帮助评估体系结构兼容性，协议文档应提供指南，解释如何执行扩展，以及如何使用协议扩展机制。
Protocol components that are designed with the specific intention of allowing extensibility should be clearly identified, with specific and complete instructions on how to extend them. This includes the process for adequate review of extension proposals: do they need community review, and if so, how much and by whom?
应该清楚地标识那些设计有允许扩展性的特定意图的协议组件，并提供关于如何扩展它们的具体而完整的说明。这包括对扩展提案进行充分审查的过程：它们是否需要社区审查，如果需要，需要多少以及由谁进行审查？
Documents relying on extension mechanisms need to explicitly identify the mechanisms being relied upon. For example, a document defining new data elements should not implicitly define new data types or protocol operations without explicitly describing those dependencies and discussing their impact. Where extension guidelines are available, mechanisms need to indicate whether they are compliant with those guidelines and offer an explanation if they are not.
依赖扩展机制的文档需要明确标识所依赖的机制。例如，定义新数据元素的文档不应在没有明确描述这些依赖关系并讨论其影响的情况下隐式定义新的数据类型或协议操作。在有扩展准则的情况下，机制需要表明它们是否符合这些准则，如果不符合，则提供解释。
Examples of documents describing extension guidelines include:
描述扩展指南的文件示例包括：
1. "Guidelines for Extending the Extensible Provisioning Protocol (EPP)" [RFC3735], which provides guidelines for use of EPP's extension mechanisms to define new features and object management capabilities.
1. “扩展可扩展资源调配协议（EPP）的指南”[RFC3735]，它提供了使用EPP扩展机制定义新功能和对象管理功能的指南。
2. "Guidelines for Authors and Reviewers of MIB Documents" BCP 111 [RFC4181], which provides guidance to protocol designers creating new MIB modules.
2. “MIB文档的作者和审阅者指南”BCP 111[RFC4181]，为创建新MIB模块的协议设计者提供指导。
3. "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)" [RFC4485], which outlines guidelines for authors of SIP extensions.
3. “会话启动协议（SIP）扩展作者指南”[RFC4485]，概述了SIP扩展作者指南。
4. "Considerations for Lightweight Directory Access Protocol (LDAP) Extensions" BCP 118 [RFC4521], which discusses considerations for designers of LDAP extensions.
4. “轻型目录访问协议（LDAP）扩展的注意事项”BCP 118[RFC4521]，其中讨论了LDAP扩展设计者的注意事项。
5. "RADIUS Design Guidelines" BCP 158 [RFC6158], which provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol.
5. “RADIUS设计指南”BCP 158[RFC6158]，为远程认证拨入用户服务（RADIUS）协议使用的属性的设计提供指南。
Protocol variations -- specifications that look very similar to the original but don't interoperate with each other or with the original -- are even more harmful to interoperability than extensions. In
协议变体——看起来与原始规范非常相似但彼此之间或与原始规范不互操作的规范——对互操作性的危害甚至比扩展更大。在里面
general, such variations should be avoided. Causes of protocol variations include incompatible protocol extensions, uncoordinated protocol development, and poorly designed "profiles".
一般而言，应避免此类变化。协议变化的原因包括不兼容的协议扩展、不协调的协议开发和设计不良的“概要文件”。
Designing a protocol for extensibility may have the perverse side effect of making it easy to construct incompatible variations. Protocol extension mechanisms should not be used to create incompatible forks in development. An extension may lead to interoperability failures unless the extended protocol correctly supports all mandatory and optional features of the unextended base protocol, and implementations of the base protocol operate correctly in the presence of the extensions. In addition, it is necessary for an extension to interoperate with other extensions.
为可扩展性设计一个协议可能会有一个反常的副作用，那就是容易构造不兼容的变体。协议扩展机制不应用于在开发中创建不兼容的分叉。扩展可能导致互操作性故障，除非扩展协议正确支持未扩展基本协议的所有强制性和可选功能，并且基本协议的实现在扩展存在的情况下正确运行。此外，扩展必须与其他扩展互操作。
As noted in Section 1 of "Uncoordinated Protocol Development Considered Harmful" [RFC5704], incompatible forks in development can result from the uncoordinated adaptation of a protocol, parameter, or code point:
如“被认为有害的不协调协议开发”[RFC5704]第1节所述，开发中的不兼容分叉可能是由于协议、参数或代码点的不协调适应造成的：
In particular, the IAB considers it an essential principle of the protocol development process that only one SDO maintains design authority for a given protocol, with that SDO having ultimate authority over the allocation of protocol parameter code-points and over defining the intended semantics, interpretation, and actions associated with those code-points.
特别是，IAB认为协议开发过程的一个基本原则是，只有一个SDO维护给定协议的设计权限，SDO对协议参数代码点的分配和对预期语义、解释的定义具有最终权限，以及与这些代码点关联的操作。
Note that problems can occur even when one Standards Development Organization (SDO) maintains design authority, if protocol parameter code points are reused. As an example, EAP-FAST [RFC5421][RFC5422] reused previously assigned Extensible Authentication Protocol (EAP) type codes. As described in the IESG note in the EAP-FAST document [RFC5421]:
请注意，如果重用协议参数代码点，即使一个标准开发组织（SDO）维护设计权限，也可能出现问题。例如，EAP-FAST[RFC5421][RFC5422]重用了以前分配的可扩展身份验证协议（EAP）类型代码。如EAP-FAST文件[RFC5421]中IESG注释所述：
The reuse of previously assigned EAP Type Codes is incompatible with EAP method negotiation as defined in RFC 3748.
重复使用先前分配的EAP类型代码与RFC 3748中定义的EAP方法协商不兼容。
Profiling is a common technique for improving interoperability within a target environment or set of scenarios. Generally speaking, there are two approaches to profiling:
分析是一种常用的技术，用于改进目标环境或场景集内的互操作性。一般来说，有两种分析方法：
a) Removal or downgrading of normative requirements (thereby creating potential interoperability problems).
a) 删除或降级规范性要求（从而产生潜在的互操作性问题）。
b) Elevation of normative requirement levels (such as from a MAY/SHOULD to a MUST). This can be done in order to improve interoperability by narrowing potential implementation choices
b) 标准要求水平的提升（例如从“可能/应该”到“必须”）。这可以通过缩小潜在的实现选择来提高互操作性
(such as when the underlying protocol is ill-defined enough to permit non-interoperable yet compliant implementations) or to meet specific operational requirements (such as enabling use of stronger cryptographic mechanisms than those mandated in the specification).
（例如，当底层协议的定义不够明确，无法实现互操作但兼容的实现）或满足特定的操作要求（例如，允许使用比规范中规定的更强大的加密机制）。
While approach a) is potentially harmful, approach b) may be beneficial.
虽然方法a）可能有害，但方法b）可能有益。
In order to avoid interoperability problems when profiled implementations interact with others over the global Internet, profilers need to remain cognizant of the implications of removing normative requirements. As noted in Section 6 of "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119], imperatives are to be used with care, and as a result, their removal within a profile is likely to result in serious consequences:
为了避免在分析的实现通过全球互联网与其他实现交互时出现互操作性问题，分析人员需要了解删除规范性要求的含义。如“RFC中用于指示需求水平的关键词”第6节所述[RFC2119]，必须谨慎使用命令，因此，在概要文件中删除命令可能会导致严重后果：
Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability.
本备忘录中定义的命令类型必须谨慎使用。特别是，它们必须仅在互操作实际需要时使用，或限制可能造成伤害的行为（例如，限制重传）时使用。例如，它们不得用于尝试将互操作不需要的特定方法强加给实现者。
As noted in Sections 3 and 4 of the Key Words document [RFC2119], recommendations cannot be removed from profiles without serious consideration:
如关键词文件[RFC2119]第3节和第4节所述，未经认真考虑，不得从概要文件中删除建议：
[T]here may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
[T] 在特定情况下，可能存在忽略特定项目的正当理由，但在选择不同的课程之前，必须理解并仔细权衡其全部含义。
Even the removal of optional features and requirements can have consequences. As noted in Section 5 of the Key Words document [RFC2119], implementations that do not support optional features still retain the obligation to ensure interoperation with implementations that do:
即使删除可选特性和需求也会产生后果。如关键字文档[RFC2119]第5节所述，不支持可选功能的实现仍有义务确保与以下实现的互操作：
An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)
不包含特定选项的实现必须准备好与另一个包含该选项的实现进行互操作，尽管功能可能有所减少。同样，包含特定选项的实现必须准备好与不包含该选项的另一个实现进行互操作（当然，选项提供的功能除外）
Experience has shown that it is insufficient merely to specify extensibility and backward compatibility correctly in an RFC. It is also important that implementations respect the compatibility mechanisms; if not, non-interoperable pairs of implementations may arise. The TLS case study (Appendix A.3) shows how important this can be.
经验表明，仅仅在RFC中正确地指定可扩展性和向后兼容性是不够的。实现尊重兼容性机制也很重要；否则，可能会出现不可互操作的实现对。TLS案例研究（附录A.3）显示了这一点的重要性。
In order to determine whether protocol extension mechanisms have been properly implemented, testing is required. However, for this to be possible, test cases need to be developed. If a base protocol document specifies extension mechanisms but does not utilize them or provide examples, it may not be possible to develop effective test cases based on the base protocol specification alone. As a result, base protocol implementations may not be properly tested, and non-compliant extension behavior may not be detected until these implementations are widely deployed.
为了确定协议扩展机制是否已正确实现，需要进行测试。然而，为了实现这一点，需要开发测试用例。如果基本协议文档指定了扩展机制，但没有使用它们或提供示例，则可能无法仅基于基本协议规范开发有效的测试用例。因此，可能无法正确测试基本协议实现，并且在广泛部署这些实现之前，可能无法检测到不兼容的扩展行为。
To encourage correct implementation of extension mechanisms, base protocol specifications should clearly articulate the expected behavior of extension mechanisms and should include examples of correct extension behavior.
为了鼓励正确实现扩展机制，基本协议规范应清楚地阐明扩展机制的预期行为，并应包括正确扩展行为的示例。
As noted in Section 3.2 of "Procedures for Protocol Extensions and Variations" BCP 125 [RFC4775]:
如“协议扩展和变更程序”BCP 125[RFC4775]第3.2节所述：
An extension is often likely to make use of additional values
added to an existing IANA registry.... It is essential that such
new values are properly registered by the applicable procedures,
including expert review where applicable.... Extensions may even
need to create new IANA registries in some cases.
An extension is often likely to make use of additional values
added to an existing IANA registry.... It is essential that such
new values are properly registered by the applicable procedures,
including expert review where applicable.... Extensions may even
need to create new IANA registries in some cases.
Experience shows that the importance of this is often underestimated during extension design; designers sometimes assume that a new codepoint is theirs for the asking, or even simply for the taking.
经验表明，在扩展设计过程中，这一点的重要性往往被低估；设计师有时会假设一个新的代码点是他们的要求，甚至只是为了获取。
Before creating a new protocol parameter registry, existing registries should be examined to determine whether one of them can be used instead (see http://www.iana.org/protocols/).
在创建新的协议参数注册表之前，应检查现有注册表，以确定是否可以使用其中一个注册表（请参阅http://www.iana.org/protocols/).
To avoid conflicting usage of the same registry value, as well as to prevent potential difficulties in determining and transferring parameter ownership, it is essential that all new values are
为了避免同一注册表值的使用发生冲突，以及防止在确定和转移参数所有权时出现潜在困难，必须删除所有新值
registered. If this is not done, there is nothing to prevent two different extensions picking the same value. When these two extensions "meet" each other on the Internet, failure is inevitable.
注册的。如果不这样做，就没有什么可以阻止两个不同的扩展选择相同的值。当这两个扩展在互联网上“相遇”时，失败是不可避免的。
A surprisingly common case of this is misappropriation of assigned Transmission Control Protocol (TCP) (or User Datagram Protocol (UDP)) registered port numbers. This can lead to a client for one service attempting to communicate with a server for another service. Another common case is the use of unregistered URI schemes. Numerous cases could be cited, but not without embarrassing specific implementers. For general rules, see the IANA Considerations guidelines document [RFC5226], and for specific rules and registries, see the individual protocol specification RFCs and the IANA web site.
一个令人惊讶的常见情况是盗用指定的传输控制协议（TCP）（或用户数据报协议（UDP））注册端口号。这可能导致一个服务的客户端尝试与另一个服务的服务器通信。另一种常见情况是使用未注册的URI方案。可以举出许多案例，但不能不让具体的实施者感到尴尬。有关一般规则，请参阅IANA注意事项指南文件[RFC5226]，有关具体规则和注册，请参阅单个协议规范RFCs和IANA网站。
While in theory a "Standards Track" or "IETF Consensus" parameter allocation policy may be instituted to encourage protocol parameter registration or to improve interoperability, in practice, problems can arise if the procedures result in so much delay that requesters give up and "self-allocate" by picking presumably unused code points. Where self-allocation is prevalent, the information contained within registries may become inaccurate, particularly when third parties are prohibited from updating entries so as to improve accuracy. In these situations, it is important to consider whether registration processes need to be changed to support the role of a registry as "documentation of how the Internet is operating".
虽然理论上可以制定“标准跟踪”或“IETF共识”参数分配政策，以鼓励协议参数注册或提高互操作性，但在实践中，如果程序导致如此多的延迟，以至于请求者放弃，并通过拾取可能未使用的代码点“自行分配”，则可能会出现问题。在普遍采用自行分配的情况下，登记册内所载信息可能会变得不准确，特别是在禁止第三方更新条目以提高准确性的情况下。在这些情况下，重要的是要考虑是否需要更改注册过程以支持注册表的作用，作为“如何运行互联网的文档”。
Some protocols (such as the Domain Name System (DNS), the Border Gateway Protocol (BGP), and the Hypertext Transfer Protocol (HTTP)) or algorithms (such as congestion control) have become critical components of the Internet infrastructure. A critical component is one whose failure can lead to Internet-wide reliability and security issues or performance degradation. When such protocols or algorithms are extended, the potential exists for negatively impacting the reliability and security of the global Internet.
一些协议（如域名系统（DNS）、边界网关协议（BGP）和超文本传输协议（HTTP））或算法（如拥塞控制）已成为互联网基础设施的关键组件。关键组件的故障可能导致整个互联网的可靠性和安全问题或性能下降。当这些协议或算法被扩展时，可能会对全球互联网的可靠性和安全性产生负面影响。
As a result, special care needs to be taken with these extensions, such as taking explicit steps to isolate existing uses from new ones. For example, this can be accomplished by requiring the extension to utilize a different port or multicast address or by implementing the extension within a separate process, without access to the data and control structures of the base protocol.
因此，需要特别注意这些扩展，例如采取明确步骤将现有用途与新用途隔离开来。例如，这可以通过要求扩展使用不同的端口或多播地址来实现，或者通过在单独的过程中实现扩展而不访问基本协议的数据和控制结构来实现。
Experience has shown that even when a mechanism has proven benign in other uses, unforeseen issues may result when adding it to a critical protocol. For example, both IS-IS and OSPF support opaque Link State Advertisements (LSAs), which are propagated by intermediate nodes
经验表明，即使一种机制在其他用途中被证明是良性的，在将其添加到关键协议时也可能会出现不可预见的问题。例如，IS-IS和OSPF都支持由中间节点传播的不透明链路状态播发（LSA）
that don't understand the LSA. Within Interior Gateway Protocols (IGPs), support for opaque LSAs has proven useful without introducing instability.
他们不了解LSA。在内部网关协议（IGP）中，对不透明LSA的支持在不引入不稳定性的情况下被证明是有用的。
However, within BGP, "attribute tunneling" has resulted in large-scale routing instabilities, since remote nodes may reset the LOCAL session if the tunneled attributes are malformed or aren't understood. This has required modification to BGP error handling, as noted in "Revised Error Handling for BGP UPDATE Messages" [ERROR-HANDLING].
然而，在BGP中，“属性隧道”已导致大规模路由不稳定，因为如果隧道属性的格式不正确或无法理解，远程节点可能会重置本地会话。这需要对BGP错误处理进行修改，如“修订的BGP更新消息错误处理”[错误处理]中所述。
In general, when extending protocols with local failure conditions, tunneling of attributes that may trigger failures in non-adjacent nodes should be avoided. This is particularly problematic when the originating node receives no indicators of remote failures it may have triggered.
一般来说，当扩展具有局部故障条件的协议时，应避免在非相邻节点中触发故障的属性隧道。当发起节点没有收到它可能触发的远程故障的指示时，这尤其有问题。
Good extension design depends on a well-designed base protocol. To promote interoperability, designers should:
良好的扩展设计依赖于设计良好的基本协议。为促进互操作性，设计师应：
1. Ensure a well-written base protocol specification. Does the base protocol specification make clear what an implementer needs to support, and does it define the impact that individual operations (e.g., a message sent to a peer) will have when invoked?
1. 确保编写良好的基本协议规范。基本协议规范是否明确了实现者需要支持的内容，以及它是否定义了单个操作（例如，发送给对等方的消息）在调用时将产生的影响？
2. Design for backward compatibility. Does the base protocol specification describe how to determine the capabilities of a peer and negotiate the use of extensions? Does it indicate how implementations handle extensions that they do not understand? Is it possible for an extended implementation to negotiate with an unextended (or differently-extended) peer to find a common subset of useful functions?
2. 向后兼容性设计。基本协议规范是否描述了如何确定对等方的能力并协商扩展的使用？它是否表明实现如何处理他们不理解的扩展？扩展实现是否可能与未扩展（或不同扩展）的对等方协商，以找到有用函数的公共子集？
3. Respect underlying architectural or security assumptions. Is there a document describing the underlying architectural assumptions, as well as considerations that have arisen in operational experience? Or are there undocumented considerations that have arisen as the result of operational experience, after the original protocol was published?
3. 尊重基础架构或安全性假设。是否有一份文件描述基础架构假设，以及运行经验中出现的考虑因素？或者，在原始协议发布后，是否存在因运营经验而产生的未记录的考虑因素？
For example, will backward-compatibility issues arise if extensions reverse the flow of data, allow formerly static parameters to be changed on the fly, or change assumptions relating to the frequency of reads/writes?
例如，如果扩展逆转了数据流，允许动态更改以前的静态参数，或者更改了与读/写频率相关的假设，是否会出现向后兼容性问题？
4. Minimize impact on critical infrastructure. For a protocol that represents a critical element of Internet infrastructure, it is important to explain when it is appropriate to isolate new uses of the protocol from existing ones.
4. 将对关键基础设施的影响降至最低。对于代表互联网基础设施关键要素的协议，重要的是解释何时适合将协议的新用途与现有用途隔离开来。
For example, is it explained when a proposed extension (or usage) has the potential for negatively impacting critical infrastructure to the point where explicit steps would be appropriate to isolate existing uses from new ones?
例如，当提议的扩展（或使用）可能对关键基础设施产生负面影响，以至于需要明确步骤将现有用途与新用途隔离开来时，是否对此进行了解释？
5. Provide guidance on data model extensions. Is there a document that explains when a protocol extension is routine and when it represents a major change?
5. 提供有关数据模型扩展的指导。是否有文档解释协议扩展何时是常规的，何时代表重大更改？
For example, is it clear when a data model extension represents a major versus a routine change? Are there guidelines describing when an extension (such as a new data type) is likely to require a code change within existing implementations?
例如，当一个数据模型扩展代表一个主要的变化与一个常规的变化时，它是否清晰？是否有准则描述扩展（如新数据类型）何时可能需要在现有实现中更改代码？
Any mechanism for extension by versioning must include provisions to ensure interoperability, or at least clean failure modes. Imagine someone creating a protocol and using a "version" field and populating it with a value (1, let's say), but giving no information about what would happen when a new version number appears in it. This would be a bad protocol design and description; it should be clear what the expectation is and how it can be tested. For example, stating that 1.X must be compatible with any version 1 code, but version 2 or greater is not expected to be compatible, has different implications than stating that version 1 must be a proper subset of version 2.
通过版本控制进行扩展的任何机制都必须包括确保互操作性的规定，或者至少包括干净的故障模式。想象一下，有人创建了一个协议，使用一个“version”字段，并用一个值（比如1）填充它，但没有给出新版本号出现时会发生什么的信息。这将是一个糟糕的协议设计和描述；应该清楚期望是什么以及如何测试。例如，声明1.X必须与任何版本1代码兼容，但版本2或更高版本不应兼容，这与声明版本1必须是版本2的适当子集具有不同的含义。
An example of an under-specified versioning mechanism is provided by the MIME-Version header, originally defined in "MIME (Multipurpose Internet Mail Extensions)" [RFC1341]. As noted in Section 1 of the MIME specification [RFC1341]:
MIME版本头提供了未指定版本控制机制的一个示例，最初在“MIME（多用途Internet邮件扩展）”[RFC1341]中定义。如MIME规范[RFC1341]第1节所述：
A MIME-Version header field ... uses a version number to declare a message to be conformant with this specification and allows mail processing agents to distinguish between such messages and those generated by older or non-conformant software, which is presumed to lack such a field.
MIME版本头字段。。。使用版本号声明邮件符合此规范，并允许邮件处理代理将此类邮件与旧版或不符合规范的软件生成的邮件区分开来，后者被认为缺少此类字段。
Beyond this, the 1992 MIME specification [RFC1341] provided little guidance on versioning behavior, or even the format of the MIME-Version header, which was specified to contain "text". The 1993 update [RFC1521] better defined the format of the version field but still did not clarify the versioning behavior:
除此之外，1992年的MIME规范[RFC1341]对版本控制行为，甚至MIME版本头的格式提供了很少的指导，MIME版本头被指定包含“文本”。1993年的更新[RFC1521]更好地定义了版本字段的格式，但仍然没有澄清版本控制行为：
Thus, future format specifiers, which might replace or extend
"1.0", are constrained to be two integer fields, separated by a
period. If a message is received with a MIME-version value other
than "1.0", it cannot be assumed to conform with this
specification....
Thus, future format specifiers, which might replace or extend
"1.0", are constrained to be two integer fields, separated by a
period. If a message is received with a MIME-version value other
than "1.0", it cannot be assumed to conform with this
specification....
It is not possible to fully specify how a mail reader that conforms with MIME as defined in this document should treat a message that might arrive in the future with some value of MIME-Version other than "1.0". However, conformant software is encouraged to check the version number and at least warn the user if an unrecognized MIME-version is encountered.
无法完全指定符合本文档中定义的MIME的邮件读取器应如何处理将来可能以MIME版本“1.0”以外的值到达的邮件。但是，鼓励一致性软件检查版本号，如果遇到无法识别的MIME版本，则至少警告用户。
Thus, even though the 1993 update [RFC1521] defined a MIME-Version header with a syntax suggestive of a "Major/Minor" versioning scheme, in practice the MIME-Version header was little more than a decoration.
因此，尽管1993年的更新[RFC1521]定义了一个MIME版本头，其语法暗示“主要/次要”版本控制方案，但实际上MIME版本头只是一个装饰。
An example of a protocol with a better versioning scheme is ROHC (Robust Header Compression). ROHCv1 [RFC3095] supports a certain set of profiles for compression algorithms. But experience had shown that these profiles had limitations, so the ROHC WG developed ROHCv2 [RFC5225]. A ROHCv1 implementation does not contain code for the ROHCv2 profiles. As the ROHC WG charter said during the development of ROHCv2:
具有更好版本控制方案的协议的一个例子是ROHC（健壮的头压缩）。ROHCv1[RFC3095]支持压缩算法的特定配置文件集。但经验表明，这些配置文件有局限性，因此ROHC工作组开发了ROHCv2[RFC5225]。ROHCv1实现不包含ROHCv2配置文件的代码。正如ROHC工作组章程在ROHCv2开发过程中所述：
It should be noted that the v2 profiles will thus not be compatible with the original (ROHCv1) profiles, which means less complex ROHC implementations can be realized by not providing support for ROHCv1 (over links not yet supporting ROHC, or by shifting out support for ROHCv1 in the long run). Profile support is agreed through the ROHC channel negotiation, which is part of the ROHC framework and thus not changed by ROHCv2.
需要注意的是，v2配置文件将因此与原始（ROHCv1）配置文件不兼容，这意味着不支持ROHCv1（通过尚未支持ROHC的链接，或者从长远来看，通过取消对ROHCv1的支持），可以实现不太复杂的ROHC实施。概要文件支持通过ROHC渠道协商达成一致，ROHC渠道协商是ROHC框架的一部分，因此ROHCv2不会更改。
Thus, in this case, both backward-compatible and backward-incompatible deployments are possible. The important point is to have a clearly thought out approach to the question of operational compatibility.
因此，在这种情况下，向后兼容和向后不兼容部署都是可能的。重要的一点是对操作兼容性问题有一个经过深思熟虑的方法。
In the past, protocols have utilized a variety of strategies for versioning, each with its own benefits and drawbacks in terms of capability and complexity of implementation:
在过去，协议使用了多种版本控制策略，每种策略在实现的能力和复杂性方面都有各自的优点和缺点：
1. No versioning support. This approach is exemplified by the Extensible Authentication Protocol (EAP) [RFC3748] as well as the Remote Authentication Dial In User Service (RADIUS) protocol [RFC2865], both of which provide no support for versioning. While lack of versioning support protects against the proliferation of incompatible dialects, the need for extensibility is likely to assert itself in other ways, so that ignoring versioning entirely may not be the most forward thinking approach.
1. 没有版本控制支持。可扩展身份验证协议（EAP）[RFC3748]和远程身份验证拨入用户服务（RADIUS）协议[RFC2865]就是这种方法的例子，这两种协议都不支持版本控制。虽然缺乏版本控制支持可以防止不兼容方言的扩散，但对可扩展性的需求可能会以其他方式表现出来，因此完全忽略版本控制可能不是最具前瞻性的方法。
2. Highest mutually supported version (HMSV). In this approach, implementations exchange the version numbers of the highest version each supports, with the negotiation agreeing on the highest mutually supported protocol version. This approach implicitly assumes that later versions provide improved functionality and that advertisement of a particular version number implies support for all lower version numbers. Where these assumptions are invalid, this approach breaks down, potentially resulting in interoperability problems. An example of this issue occurs in the Protected Extensible Authentication Protocol [PEAP] where implementations of higher versions may not necessarily provide support for lower versions.
2. 相互支持的最高版本（HMSV）。在这种方法中，实现交换各自支持的最高版本的版本号，协商就相互支持的最高协议版本达成一致。这种方法隐含地假设较新版本提供了改进的功能，并且特定版本号的广告意味着支持所有较低版本号。如果这些假设无效，这种方法就会失效，可能导致互操作性问题。这个问题的一个例子出现在受保护的可扩展身份验证协议[PEAP]中，其中较高版本的实现可能不一定支持较低版本。
3. Assumed backward compatibility. In this approach, implementations may send packets with higher version numbers to legacy implementations supporting lower versions, but with the assumption that the legacy implementations will interpret packets with higher version numbers using the semantics and syntax defined for lower versions. This is the approach taken by "Port-Based Network Access Control" [IEEE-802.1X]. For this approach to work, legacy implementations need to be able to accept packets of known types with higher protocol versions without discarding them; protocol enhancements need to permit silent discard of unsupported extensions; and implementations supporting higher versions need to refrain from mandating new features when encountering legacy implementations.
3. 假定向后兼容。在这种方法中，实现可以向支持较低版本的遗留实现发送具有较高版本号的数据包，但前提是遗留实现将使用为较低版本定义的语义和语法解释具有较高版本号的数据包。这是“基于端口的网络访问控制”[IEEE-802.1X]采用的方法。为了使这种方法起作用，遗留实现需要能够接受具有更高协议版本的已知类型的数据包，而不丢弃它们；协议增强需要允许无声地丢弃不受支持的扩展；支持更高版本的实现在遇到遗留实现时需要避免强制要求新功能。
4. Major/minor versioning. In this approach, implementations with the same major version but a different minor version are assumed to be backward compatible, but implementations are required to negotiate a mutually supported major version number. This approach assumes that implementations with a lower minor version number but the same major version can safely ignore unsupported protocol messages.
4. 主要/次要版本控制。在这种方法中，假设具有相同主版本但不同次版本的实现是向后兼容的，但实现需要协商相互支持的主版本号。这种方法假设具有较低次要版本号但相同主要版本的实现可以安全地忽略不受支持的协议消息。
5. Min/max versioning. This approach is similar to HMSV, but without the implied obligation for clients and servers to support all versions back to version 1, in perpetuity. It allows clients and servers to cleanly drop support for early versions when those versions become so old that they are no longer relevant and no longer required. In this approach, the client initiating the connection reports the highest and lowest protocol versions it understands. The server reports back the chosen protocol version:
5. 最小/最大版本控制。这种方法类似于HMSV，但没有客户机和服务器永久支持所有版本回到版本1的隐含义务。它允许客户机和服务器在早期版本变得如此陈旧以至于不再相关、不再需要时完全放弃对早期版本的支持。在这种方法中，启动连接的客户端报告它所理解的最高和最低协议版本。服务器报告所选的协议版本：
a. If the server understands one or more versions in the client's range, it reports back the highest mutually understood version.
a. 如果服务器理解客户端范围内的一个或多个版本，则会报告相互理解的最高版本。
b. If there is no mutual version, then the server reports back some version that it does understand (selected as described below). The connection is then typically dropped by client or server, but reporting this version number first helps facilitate useful error messages at the client end:
b. 如果没有交互版本，则服务器会报告其确实理解的某个版本（如下所述选择）。然后，连接通常由客户端或服务器断开，但首先报告此版本号有助于在客户端提供有用的错误消息：
* If there is no mutual version, and the server speaks any version higher than client max, it reports the lowest version it speaks that is greater than the client max. The client can then report to the user, "You need to upgrade to at least version <xx>".
* 如果没有交互版本，并且服务器使用高于客户端最大值的任何版本，则会报告其使用的最低版本，该版本高于客户端最大值。然后，客户端可以向用户报告，“您需要升级到至少版本<xx>”。
* Else, the server reports the highest version it speaks. The client can then report to the user, "You need to request the server operator to upgrade to at least version <min>".
* 否则，服务器将报告它所说的最高版本。然后，客户端可以向用户报告，“您需要请求服务器操作员至少升级到<min>版本”。
Protocols generally do not need any version-negotiation mechanism more complicated than the mechanisms described here. The nature of protocol version-negotiation mechanisms is that, by definition, they don't get widespread real-world testing until *after* the base protocol has been deployed for a while, and its deficiencies have become evident. This means that, to be useful, a protocol version-negotiation mechanism should be simple enough that it can reasonably be assumed that all the implementers of the first protocol version at least managed to implement the version-negotiation mechanism correctly.
协议通常不需要任何比这里描述的机制更复杂的版本协商机制。协议版本协商机制的本质是，根据定义，它们在基本协议部署一段时间后才得到广泛的实际测试，其缺陷也变得显而易见。这意味着，为了有用，协议版本协商机制应该足够简单，以便可以合理地假设第一协议版本的所有实现者至少能够正确地实现版本协商机制。
Protocols commonly include one or more "reserved" fields, clearly intended for future extensions. It is good practice to specify the value to be inserted in such a field by the sender (typically zero) and the action to be taken by the receiver when seeing some other
协议通常包括一个或多个“保留”字段，明确用于将来的扩展。很好的做法是指定发送方在此类字段中插入的值（通常为零）以及接收方在看到其他字段时要采取的操作
value (typically no action). In packet format diagrams, such fields are typically labeled "MBZ", to be read as, "Must Be Zero on transmission, Must Be Ignored on reception".
值（通常无操作）。在数据包格式图中，此类字段通常标记为“MBZ”，读作“传输时必须为零，接收时必须忽略”。
A common mistake of inexperienced protocol implementers is to think that "MBZ" means that it's their software's job to verify that the value of the field is zero on reception and reject the packet if not. This is a mistake, and such software will fail when it encounters future versions of the protocol where these previously reserved fields are given new defined meanings. Similarly, protocols should carefully specify how receivers should react to unknown extensions (headers, TLVs, etc.), such that failures occur only when that is truly the intended outcome.
没有经验的协议实现者的一个常见错误是认为“MBZ”意味着他们的软件的工作是在接收时验证字段值是否为零，如果不是，则拒绝数据包。这是一个错误，当这种软件遇到协议的未来版本时，这些先前保留的字段将被赋予新的定义含义，它将失败。类似地，协议应该仔细地指定接收器应该如何对未知的扩展（报头、TLV等）做出反应，这样只有当这确实是预期的结果时才会发生故障。
Using widely supported encoding formats leads to better interoperability and easier extensibility.
使用广泛支持的编码格式可以实现更好的互操作性和更易于扩展性。
As described in "IAB Thoughts on Encodings for Internationalized Domain Names" [RFC6055], the number of encodings should be minimized, and complex encodings are generally a bad idea. As soon as one moves outside the ASCII repertoire, issues arise relating to collation, valid code points, encoding, normalization, and comparison, which extensions must handle with care [ID-COMPARISON][PRECIS-STATEMENT][PRECIS-FRAMEWORK].
正如“IAB关于国际化域名编码的想法”[RFC6055]中所述，编码的数量应该最小化，复杂的编码通常是个坏主意。一旦跳出ASCII指令集，就会出现与排序、有效代码点、编码、规范化和比较相关的问题，扩展必须小心处理这些问题[ID-comparison][PRECIS-STATEMENT][PRECIS-FRAMEWORK]。
An example is the Simple Network Management Protocol (SNMP) Structure of Managed Information (SMI). Guidelines exist for defining the Management Information Base (MIB) objects that SNMP carries [RFC4181]. Also, multiple textual conventions have been published, so that MIB designers do not have to "reinvent the wheel" when they need a commonly encountered construct. For example, "Textual Conventions for Internet Network Addresses" [RFC4001] can be used by any MIB designer needing to define objects containing IP addresses, thus ensuring consistency as the body of MIBs is extended.
管理信息（SMI）的简单网络管理协议（SNMP）结构就是一个例子。存在定义SNMP承载的管理信息库（MIB）对象的指南[RFC4181]。此外，已经发布了多个文本约定，这样MIB设计人员就不必在需要常见构造时“重新发明轮子”。例如，“Internet网络地址的文本约定”[RFC4001]可由任何需要定义包含IP地址的对象的MIB设计器使用，从而确保MIB主体扩展时的一致性。
In some protocols, the parameter space either has no specified limit (e.g., Header field names) or is sufficiently large that it is unlikely to be exhausted. In other protocols, the parameter space is limited and, in some cases, has proven inadequate to accommodate demand. Common mistakes include:
在某些协议中，参数空间要么没有指定的限制（例如，标题字段名），要么足够大，不太可能耗尽。在其他协议中，参数空间是有限的，在某些情况下，已证明不足以满足需求。常见错误包括：
a. A version field that is too small (e.g., two bits or less). When designing a version field, existing as well as potential versions of a protocol need to be taken into account. For example, if a
a. 太小的版本字段（例如，两位或更少）。在设计版本字段时，需要考虑协议的现有版本和潜在版本。例如，如果
protocol is being standardized for which there are existing implementations with known interoperability issues, more than one version for "pre-standard" implementations may be required. If two "pre-standard" versions are required in addition to a version for an IETF Standard, then a two-bit version field would only leave one additional version code point for a future update, which could be insufficient. This problem was encountered during the development of the PEAPv2 protocol [PEAP].
协议正在被标准化，其中存在已知互操作性问题的现有实现，可能需要多个版本的“预标准”实现。如果除了IETF标准的版本外，还需要两个“预标准”版本，则两位版本字段将只为将来的更新留下一个额外的版本代码点，这可能是不够的。这个问题是在PEAPv2协议[PEAP]的开发过程中遇到的。
b. A small parameter space (e.g., 8 bits or less) along with a First Come, First Served (FCFS) allocation policy [RFC5226]. In general, an FCFS allocation policy is only appropriate in situations where parameter exhaustion is highly unlikely. In situations where substantial demand is anticipated within a parameter space, the space should either be designed to be sufficient to handle that demand, or vendor extensibility should be provided to enable vendors to self-allocate. The combination of a small parameter space, an FCFS allocation policy, and no support for vendor extensibility is particularly likely to prove ill-advised. An example of such a combination was the design of the original 8-bit EAP Type space [RFC2284].
b. 小参数空间（例如，8位或更少）以及先到先服务（FCFS）分配策略[RFC5226]。通常，FCFS分配策略仅适用于参数耗尽可能性极低的情况。在参数空间内预计有大量需求的情况下，该空间应设计为足以处理该需求，或应提供供应商可扩展性，以使供应商能够自行分配。小参数空间、FCFS分配策略和不支持供应商扩展性的组合很可能被证明是不明智的。这种组合的一个例子是原始8位EAP类型空间[RFC2284]的设计。
Once the potential for parameter exhaustion becomes apparent, it is important that it be addressed as quickly as possible. Protocol changes can take years to appear in implementations and by then the exhaustion problem could become acute.
一旦参数耗尽的可能性变得明显，必须尽快解决。协议更改可能需要数年才能在实现中出现，到那时，耗尽问题可能会变得严重。
Options for addressing a protocol parameter exhaustion problem include:
解决协议参数耗尽问题的选项包括：
Rethinking the allocation regime Where it becomes apparent that the size of a parameter space is insufficient to meet demand, it may be necessary to rethink the allocation mechanism, in order to prevent or delay parameter space exhaustion. In revising parameter allocation mechanisms, it is important to consider both supply and demand aspects so as to avoid unintended consequences such as self-allocation or the development of black markets for the resale of protocol parameters.
重新思考分配机制如果参数空间的大小显然不足以满足需求，则可能有必要重新思考分配机制，以防止或延迟参数空间耗尽。在修改参数分配机制时，重要的是考虑供给和需求两方面，以避免诸如分配或开发协议参数转售的黑市等意外后果。
For example, a few years after publication of PPP EAP [RFC2284] in 1998, it became clear that the combination of an FCFS allocation policy [RFC5226] and lack of support for vendor-extensions had created the potential for exhaustion of the EAP Method Type space within a few years. To address the issue, Section 6.2 of the 2004 update [RFC3748] changed the allocation policy for EAP Method Types from FCFS to Expert Review, with Specification Required. Since this allocation policy revision did not change the demand
例如，在1998年发布PPP EAP[RFC2284]几年后，很明显，FCFS分配政策[RFC5226]和缺乏对供应商扩展的支持相结合，导致EAP方法类型空间在几年内耗尽。为了解决这一问题，2004年更新[RFC3748]第6.2节将EAP方法类型的分配政策从FCF更改为专家评审，并要求规范。由于此次分配政策修订没有改变需求
for EAP Method Types, it would have been likely to result in self-allocation within the standards space had mechanisms not been provided to expand the Method Type space (including support for vendor-specific method types).
对于EAP方法类型，如果没有提供扩展方法类型空间的机制（包括对特定于供应商的方法类型的支持），可能会导致在标准空间内进行自我分配。
Support for vendor-specific parameters If the demand that cannot be accommodated is being generated by vendors, merely making allocation harder could make things worse if this encourages vendors to self-allocate, creating interoperability problems. In such a situation, support for vendor-specific parameters should be considered, allowing each vendor to self-allocate within their own vendor-specific space based on a vendor's Private Enterprise Code (PEC). For example, in the case of the EAP Method Type space, Section 6.2 of the 2004 EAP specification [RFC3748] also provided for an Expanded Type space for "functions specific only to one vendor's implementation".
如果供应商产生了无法满足的需求，则支持供应商特定参数，如果这鼓励供应商自行分配，从而造成互操作性问题，那么仅仅增加分配难度可能会使情况变得更糟。在这种情况下，应考虑支持特定于供应商的参数，允许每个供应商根据供应商的私有企业代码（PEC）在自己的特定于供应商的空间内自行分配。例如，在EAP方法类型空间的情况下，2004年EAP规范[RFC3748]第6.2节还为“仅针对一个供应商实现的功能”提供了扩展类型空间。
Extensions to the parameter space If the goal is to stave off exhaustion in the face of high demand, a larger parameter space may be helpful; this may require a new version of the protocol (such as was required for IPv6). Where vendor-specific parameter support is available, this may be achieved by allocating a PEC for IETF use. Otherwise, it may be necessary to try to extend the size of the parameter fields, which could require a new protocol version or other substantial protocol changes.
参数空间的扩展如果目标是避免在面对高需求时耗尽，则较大的参数空间可能会有所帮助；这可能需要新版本的协议（如IPv6所需的协议）。如果供应商特定的参数支持可用，可通过为IETF使用分配PEC来实现。否则，可能需要尝试扩展参数字段的大小，这可能需要新的协议版本或其他重大协议更改。
Parameter reclamation In order to gain time, it may be necessary to reclaim unused parameters. However, it may not be easy to determine whether a parameter that has been allocated is in use or not, particularly if the entity that obtained the allocation no longer exists or has been acquired (possibly multiple times).
参数回收为了获得时间，可能需要回收未使用的参数。然而，确定已分配的参数是否正在使用可能并不容易，特别是在获得分配的实体不再存在或已被获取（可能多次）的情况下。
Parameter transfer When all the above mechanisms have proved infeasible and parameter exhaustion looms in the near future, enabling the transfer of ownership of protocol parameters can be considered as a means for improving allocation efficiency. However, enabling transfer of parameter ownership can be far from simple if the parameter allocation process was not originally designed to enable title searches and ownership transfers.
当上述所有机制均已证明不可行且参数耗尽在不久的将来即将出现时，可将协议参数所有权的转移视为提高分配效率的一种手段。但是，如果参数分配过程最初不是为启用标题搜索和所有权转移而设计的，则启用参数所有权转移可能远不简单。
A parameter allocation process designed to uniquely allocate code points is fundamentally different from one designed to enable title search and transfer. If the only goal is to ensure that a parameter is not allocated more than once, the parameter registry
设计用于唯一分配代码点的参数分配过程与设计用于启用标题搜索和传输的参数分配过程有根本不同。如果唯一的目标是确保参数分配不超过一次，则参数注册表
will only need to record the initial allocation. On the other hand, if the goal is to enable transfer of ownership of a protocol parameter, then it is important not only to record the initial allocation, but also to track subsequent ownership changes, so as to make it possible to determine and transfer the title. Given the difficulty of converting from a unique allocation regime to one requiring support for title search and ownership transfer, it is best for the desired capabilities to be carefully thought through at the time of registry establishment.
只需记录初始分配。另一方面，如果目标是允许协议参数的所有权转移，那么重要的是不仅要记录初始分配，还要跟踪随后的所有权变更，以便能够确定和转移所有权。鉴于难以从一种独特的分配制度转变为一种需要支持所有权搜索和所有权转让的制度，最好在建立登记处时仔细考虑所需的能力。
Extensibility with respect to cryptographic algorithms is desirable in order to provide resilience against the compromise of any particular algorithm. Section 3 of "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management" BCP 132 [RFC4962] provides some basic advice:
对于密码算法的可扩展性是可取的，以便针对任何特定算法的妥协提供弹性。“认证、授权和记帐（AAA）密钥管理指南”BCP 132[RFC4962]第3节提供了一些基本建议：
The ability to negotiate the use of a particular cryptographic
algorithm provides resilience against compromise of a particular
cryptographic algorithm.... This is usually accomplished by
including an algorithm identifier and parameters in the protocol,
and by specifying the algorithm requirements in the protocol
specification. While highly desirable, the ability to negotiate
key derivation functions (KDFs) is not required. For
interoperability, at least one suite of mandatory-to-implement
algorithms MUST be selected....
The ability to negotiate the use of a particular cryptographic
algorithm provides resilience against compromise of a particular
cryptographic algorithm.... This is usually accomplished by
including an algorithm identifier and parameters in the protocol,
and by specifying the algorithm requirements in the protocol
specification. While highly desirable, the ability to negotiate
key derivation functions (KDFs) is not required. For
interoperability, at least one suite of mandatory-to-implement
algorithms MUST be selected....
This requirement does not mean that a protocol must support both public-key and symmetric-key cryptographic algorithms. It means that the protocol needs to be structured in such a way that multiple public-key algorithms can be used whenever a public-key algorithm is employed. Likewise, it means that the protocol needs to be structured in such a way that multiple symmetric-key algorithms can be used whenever a symmetric-key algorithm is employed.
这一要求并不意味着协议必须同时支持公钥和对称密钥加密算法。这意味着协议的结构需要确保在使用公钥算法时可以使用多个公钥算法。同样，这意味着协议的结构需要确保在使用对称密钥算法时可以使用多个对称密钥算法。
In practice, the most difficult challenge in providing cryptographic agility is providing for a smooth transition in the event that a mandatory-to-implement algorithm is compromised. Since it may take significant time to provide for widespread implementation of a previously undeployed alternative, it is often advisable to recommend implementation of alternative algorithms of distinct lineage in addition to those made mandatory-to-implement, so that an alternative algorithm is readily available. If such a recommended alternative is not in place, then it would be wise to issue such a recommendation as soon as indications of a potential weakness surface. This is particularly important in the case of potential weakness in
在实践中，在提供加密灵活性方面最困难的挑战是在强制实现算法被破坏的情况下提供平滑过渡。由于可能需要花费大量时间来提供以前未部署的替代方案的广泛实施，因此除了强制实施的算法外，通常建议实施不同谱系的替代算法，以便替代算法随时可用。如果建议的替代方案不到位，则在出现潜在缺陷迹象时尽快发布建议是明智的。这一点在以下情况下尤为重要：潜在的
algorithms used to authenticate and integrity-protect the cryptographic negotiation itself, such as KDFs or message integrity checks (MICs). Without secure alternatives to compromised KDF or MIC algorithms, it may not be possible to secure the cryptographic negotiation while retaining backward compatibility.
用于认证和完整性保护加密协商本身的算法，如KDFs或消息完整性检查（MICs）。如果没有安全的KDF或MIC算法替代方案，则可能无法在保持向后兼容性的同时保护加密协商。
In the past, IETF protocols have been specified to operate over multiple transports. Often the protocol was originally specified to utilize a single transport, but limitations were discovered in subsequent deployment, so that additional transports were subsequently specified.
在过去，IETF协议被指定在多个传输上运行。通常，协议最初被指定为使用单个传输，但在随后的部署中发现了限制，因此随后指定了其他传输。
In a number of cases, the protocol was originally specified to operate over UDP, but subsequent operation disclosed one or more of the following issues, leading to the specification of alternative transports:
在许多情况下，协议最初被指定在UDP上运行，但随后的操作揭示了以下一个或多个问题，导致了替代传输的规范：
a. Payload fragmentation (often due to the introduction of extensions or additional usage scenarios);
a. 有效负载碎片（通常由于引入扩展或其他使用场景）；
b. Problems with congestion control, transport reliability, or efficiency; and
b. 拥塞控制、运输可靠性或效率方面的问题；和
c. Lack of deployment in multicast scenarios, which had been a motivator for UDP transport.
c. 在多播场景中缺乏部署，这一直是UDP传输的动力。
On the other hand, there are also protocols that were originally specified to operate over reliable transport that have subsequently defined transport over UDP, due to one or more of the following issues:
另一方面，由于以下一个或多个问题，最初指定在可靠传输上运行的协议随后定义了UDP传输：
a. NAT traversal concerns that were more easily addressed with UDP transport;
a. UDP传输更容易解决的NAT穿越问题；
b. Scalability problems, which could be improved by UDP transport.
b. 可伸缩性问题，可通过UDP传输加以改进。
Since specification of a single transport offers the highest potential for interoperability, protocol designers should carefully consider not only initial but potential future requirements in the selection of a transport protocol. Where UDP transport is selected, the guidance provided in "Unicast UDP Usage Guidelines for Application Designers" [RFC5405] should be taken into account.
由于单个传输的规范提供了互操作性的最高潜力，因此协议设计者不仅要仔细考虑在传输协议的选择中的初始需求，而且还要考虑潜在的未来需求。如果选择UDP传输，则应考虑“应用程序设计者单播UDP使用指南”[RFC5405]中提供的指南。
After significant deployment has occurred, there are few satisfactory options for addressing problems with the originally selected transport protocol. While specification of additional transport protocols is possible, removal of a widely used transport protocol is likely to result in interoperability problems and should be avoided.
在大量部署之后，对于解决最初选择的传输协议的问题，几乎没有令人满意的选项。虽然可以指定其他传输协议，但删除广泛使用的传输协议可能会导致互操作性问题，应避免。
Mandating support for the initially selected transport protocol while designating additional transport protocols as optional may have limitations. Since optional transport protocols are typically introduced due to the advantages they afford in certain scenarios, in those situations, implementations not supporting optional transport protocols may exhibit degraded performance or may even fail.
强制支持最初选择的传输协议，同时指定其他传输协议为可选协议可能有局限性。由于可选传输协议通常是由于其在某些场景中提供的优势而引入的，因此在这些情况下，不支持可选传输协议的实现可能会表现出性能下降甚至失败。
While mandating support for multiple transport protocols may appear attractive, designers need to realistically evaluate the likelihood that implementers will conform to the requirements. For example, where resources are limited (such as in embedded systems), implementers may choose to only support a subset of the mandated transport protocols, resulting in non-interoperable protocol variants.
虽然强制支持多种传输协议可能看起来很有吸引力，但设计者需要实际评估实现者符合要求的可能性。例如，在资源有限的情况下（例如在嵌入式系统中），实现者可能选择仅支持强制传输协议的子集，从而导致不可互操作的协议变体。
IETF protocols have utilized several techniques for the handling of unknown extensions. One technique (often used for vendor-specific extensions) is to specify that unknown extensions be "silently discarded".
IETF协议使用了几种技术来处理未知扩展。一种技术（通常用于特定于供应商的扩展）是指定未知扩展被“无声地丢弃”。
While this approach can deliver a high level of interoperability, there are situations in which it is problematic. For example, where security functionality is involved, "silent discard" may not be satisfactory, particularly if the recipient does not provide feedback as to whether or not it supports the extension. This can lead to operational security issues that are difficult to detect and correct, as noted in Appendix A.2 and in Section 2.5 of "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC5080].
虽然这种方法可以提供高水平的互操作性，但在某些情况下它是有问题的。例如，在涉及安全功能的情况下，“静默放弃”可能不令人满意，特别是如果接收者没有提供关于其是否支持扩展的反馈。这可能导致难以检测和纠正的操作安全问题，如附录A.2和“通用远程认证拨入用户服务（RADIUS）实施问题和建议修复”第2.5节所述[RFC5080]。
In order to ensure that a recipient supports an extension, a recipient encountering an unknown extension may be required to explicitly reject it and to return an error, rather than ignoring the unknown extension and proceeding with the remainder of the message. This can be accomplished via a "Mandatory" bit in a TLV-based protocol such as the Layer 2 Tunneling Protocol (L2TP) [RFC2661], or a "Require" or "Proxy-Require" header in a text-based protocol such as SIP [RFC3261] or HTTP [RFC2616].
为了确保收件人支持扩展，可能需要遇到未知扩展的收件人明确拒绝该扩展并返回错误，而不是忽略未知扩展并继续处理邮件的其余部分。这可以通过基于TLV的协议（如第2层隧道协议（L2TP）[RFC2661]）中的“强制”位或基于文本的协议（如SIP[RFC3261]或HTTP[RFC2616]）中的“要求”或“代理要求”头来实现。
Since a mandatory extension can result in an interoperability failure when communicating with a party that does not support the extension, this designation may not be permitted for vendor-specific extensions and may only be allowed for Standards Track extensions. To enable fallback operation with degraded functionality, it is good practice for the recipient to indicate the reason for the failure, including a list of unsupported extensions. The initiator can then retry without the offending extensions.
由于在与不支持扩展的一方通信时，强制扩展可能会导致互操作性故障，因此此指定可能不允许用于特定于供应商的扩展，并且可能仅允许用于标准轨道扩展。要启用降级功能的回退操作，收件人最好指明失败的原因，包括不支持的扩展的列表。然后，发起者可以重试，而不使用有问题的扩展。
Typically, only the recipient will find itself in the position of rejecting a mandatory extension, since the initiator can explicitly indicate which extensions are supported, with the recipient choosing from among the supported extensions. This can be accomplished via an exchange of TLVs, such as in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5996] or Diameter [RFC3588], or via use of "Accept", "Accept-Encoding", "Accept-Language", "Allow", and "Supported" headers in a text-based protocol such as SIP [RFC3261] or HTTP [RFC2616].
通常，只有接收者会发现自己处于拒绝强制扩展的位置，因为发起者可以明确指出支持哪些扩展，接收者可以从支持的扩展中进行选择。这可以通过TLV的交换来实现，例如在Internet密钥交换协议版本2（IKEv2）[RFC5996]或Diameter[RFC3588]中，或者通过在基于文本的协议（例如SIP[RFC3261]或HTTP[RFC2616]）中使用“接受”、“接受编码”、“接受语言”、“允许”和“支持的”头来实现。
An extension must not introduce new security risks without also providing adequate countermeasures; in particular, it must not inadvertently defeat security measures in the unextended protocol. Thus, the security analysis for an extension needs to be as thorough as for the original protocol -- effectively, it needs to be a regression analysis to check that the extension doesn't inadvertently invalidate the original security model.
在没有提供足够的对策的情况下，扩展不得引入新的安全风险；特别是，它不能无意中破坏未扩展协议中的安全措施。因此，扩展的安全性分析需要与原始协议一样彻底——实际上，它需要是一种回归分析，以检查扩展是否会无意中使原始安全模型失效。
This analysis may be simple (e.g., adding an extra opaque data element is unlikely to create a new risk) or quite complex (e.g., adding a handshake to a previously stateless protocol may create a completely new opportunity for an attacker).
这种分析可能很简单（例如，添加额外的不透明数据元素不太可能产生新的风险），也可能很复杂（例如，向以前无状态的协议添加握手可能会为攻击者创造全新的机会）。
When the extensibility of a design includes allowing for new and presumably more powerful cryptographic algorithms to be added, particular care is needed to ensure that the result is, in fact, increased security. For example, it may be undesirable from a security viewpoint to allow negotiation down to an older, less secure algorithm.
当设计的可扩展性包括允许添加新的、可能更强大的加密算法时，需要特别注意确保结果实际上是提高安全性。例如，从安全的角度来看，允许向下协商到较旧、较不安全的算法可能是不可取的。
[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月。
[RFC4775] Bradner, S., Carpenter, B., Ed., and T. Narten, "Procedures for Protocol Extensions and Variations", BCP 125, RFC 4775, December 2006.
[RFC4775]Bradner，S.，Carpenter，B.，Ed.，和T.Narten，“协议扩展和变更程序”，BCP 125，RFC 4775，2006年12月。
[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月。
[ERROR-HANDLING] Scudder, J., Chen, E., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", Work in Progress, June 2012.
[错误处理]Scudder，J.，Chen，E.，Mohapatra，P.，和K.Patel，“修改BGP更新消息的错误处理”，正在进行的工作，2012年6月。
[ID-COMPARISON] Thaler, D., "Issues in Identifier Comparison for Security Purposes", Work in Progress, August 2012.
[ID-COMPARISON]Thaler，D.“出于安全目的的标识符比较问题”，正在进行的工作，2012年8月。
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004, December 2004.
[IEEE-802.1X]电气和电子工程师协会，“局域网和城域网：基于端口的网络访问控制”，IEEE标准802.1X-2004，2004年12月。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, May 2012.
[LISP]Farinaci，D.，Fuller，V.，Meyer，D.，和D.Lewis，“定位器/身份分离协议（LISP）”，正在进行的工作，2012年5月。
[PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
[PEAP]Palekar，A.，Simon，D.，Salowey，J.，Zhou，H.，Zorn，G.，和S.Josefsson，“受保护的EAP协议（PEAP）版本2”，正在进行的工作，2004年10月。
[PRECIS-FRAMEWORK] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols", Work in Progress, August 2012.
[PRECIS-FRAMEWORK]Saint Andre，P.和M.Blanchet，“PRECIS框架：应用协议中国际化字符串的准备和比较”，正在进行的工作，2012年8月。
[PRECIS-STATEMENT] Blanchet, M. and A. Sullivan, "Stringprep Revision and PRECIS Problem Statement", Work in Progress, August 2012.
[PRECIS-STATEMENT]Blanchet，M.和A.Sullivan，“Stringprep修订和PRECIS问题声明”，正在进行的工作，2012年8月。
[RFC822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", STD 11, RFC 822, August 1982.
[RFC822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered Harmful", RFC 1263, October 1991.
[RFC1263]O'Malley，S.和L.Peterson，“被认为有害的TCP扩展”，RFC1263，1991年10月。
[RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, June 1992.
[RFC1341]Borenstein，N.和N.Freed，“MIME（多用途Internet邮件扩展）：指定和描述Internet邮件正文格式的机制”，RFC 13411992年6月。
[RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 1993.
[RFC1521]Borenstein，N.和N.Freed，“MIME（多用途Internet邮件扩展）第一部分：指定和描述Internet邮件正文格式的机制”，RFC 15211993年9月。
[RFC2058] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2058, January 1997.
[RFC2058]Rigney，C.，Rubens，A.，Simpson，W.，和S.Willens，“远程认证拨入用户服务（RADIUS）”，RFC 2058，1997年1月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2284]Blunk，L.和J.Vollbrecht，“PPP可扩展认证协议（EAP）”，RFC 2284，1998年3月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661]汤斯利，W.，瓦伦西亚，A.，鲁本斯，A.，帕尔，G.，佐恩，G.，和B.帕尔特，“第二层隧道协议“L2TP”，RFC 26611999年8月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，Ed.，“互联网信息格式”，RFC 2822，2001年4月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC2882] Mitton, D., "Network Access Servers Requirements: Extended RADIUS Practices", RFC 2882, July 2000.
[RFC2882]Mitton，D.，“网络访问服务器要求：扩展RADIUS实践”，RFC 28822000年7月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP，和未压缩”，RFC 3095，2001年7月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", RFC 3427, December 2002.
[RFC3427]Mankin，A.，Bradner，S.，Mahy，R.，Willis，D.，Ott，J.，和B.Rosen，“会话启动协议（SIP）的更改过程”，RFC 3427，2002年12月。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RFC3575]Aboba，B.“RADIUS（远程认证拨入用户服务）的IANA注意事项”，RFC 3575，2003年7月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]Gustafsson，A.，“未知DNS资源记录（RR）类型的处理”，RFC3597，2003年9月。
[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月。
[RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible Provisioning Protocol (EPP)", RFC 3735, March 2004.
[RFC3735]Hollenbeck，S.，“扩展可扩展资源调配协议（EPP）的指南”，RFC 37352004年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 3748，2004年6月。
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October 2004.
[RFC3935]Alvestrand，H.，“IETF的使命声明”，BCP 95，RFC 3935，2004年10月。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
[RFC4001]Daniele，M.，Haberman，B.，Routhier，S.，和J.Schoenwaeld，“互联网网络地址的文本约定”，RFC 4001，2005年2月。
[RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
[RFC4181]Heard，C.，Ed.，“MIB文件的作者和评审者指南”，BCP 111，RFC 41812005年9月。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[RFC4366]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", RFC 4485, May 2006.
[RFC4485]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）扩展作者指南”，RFC 4485，2006年5月。
[RFC4521] Zeilenga, K., "Considerations for Lightweight Directory Access Protocol (LDAP) Extensions", BCP 118, RFC 4521, June 2006.
[RFC4521]Zeilenga，K.，“轻型目录访问协议（LDAP）扩展的注意事项”，BCP 118，RFC 45212006年6月。
[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月。
[RFC4929] Andersson, L., Ed., and A. Farrel, Ed., "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 2007.
[RFC4929]Andersson，L.，Ed.，和A.Farrel，Ed.“多协议标签交换（MPLS）和通用MPLS（GMPLS）协议和程序的变更过程”，BCP 129，RFC 49292007年6月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962]Housley，R.和B.Aboba，“认证、授权和记帐（AAA）密钥管理指南”，BCP 132，RFC 4962，2007年7月。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080]Nelson，D.和A.DeKok，“通用远程身份验证拨入用户服务（RADIUS）实施问题和建议修复”，RFC 50802007年12月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，Ed.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, July 2008.
[RFC5218]Thaler，D.和B.Aboba，“什么是成功的方案？”RFC 5218，2008年7月。
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008.
[RFC5225]Pelletier，G.和K.Sandlund，“鲁棒头压缩版本2（ROHCv2）：RTP、UDP、IP、ESP和UDP Lite的配置文件”，RFC 52252008年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月。
[RFC5421] Cam-Winget, N. and H. Zhou, "Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", RFC 5421, March 2009.
[RFC5421]Cam Winget，N.和H.Zhou，“通过安全隧道可扩展身份验证协议（EAP-FAST）的灵活身份验证中的基本密码交换”，RFC 54212009年3月。
[RFC5422] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", RFC 5422, March 2009.
[RFC5422]Cam Winget，N.，McGrew，D.，Salowey，J.，和H.Zhou，“通过安全隧道可扩展身份验证协议（EAP-FAST）使用灵活身份验证的动态资源调配”，RFC 5422，2009年3月。
[RFC5704] Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated Protocol Development Considered Harmful", RFC 5704, November 2009.
[RFC5704]Bryant，S.，Ed.，Morrow，M.，Ed.，和IAB，“认为不协调的方案制定有害”，RFC 57042009年11月。
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010.
[RFC5727]Peterson，J.，Jennings，C.，和R.Sparks，“会话启动协议（SIP）和实时应用程序和基础设施领域的变更过程”，BCP 67，RFC 5727，2010年3月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011.
[RFC6055]Thaler，D.，Klensin，J.，和S.Cheshire，“IAB对国际化域名编码的思考”，RFC 60552011年2月。
[RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011.
[RFC6158]DeKok，A.，Ed.，和G.Weber，“半径设计指南”，BCP 158，RFC 6158，2011年3月。
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, June 2012.
[RFC6648]圣安德烈，P.，克罗克，D.，和M.诺丁汉，“反对应用协议中的“X-”前缀和类似结构”，BCP 178，RFC 6648，2012年6月。
This document is heavily based on an earlier draft by Scott Bradner and Thomas Narten, other parts of which were eventually published as RFC 4775.
本文件主要基于斯科特·布拉德纳（Scott Bradner）和托马斯·纳滕（Thomas Narten）的早期草案，其其他部分最终以RFC 4775的形式出版。
That draft stated: "The initial version of this document was put together by the IESG in 2002. Since then, it has been reworked in response to feedback from John Loughney, Henrik Levkowetz, Mark Townsley, Randy Bush and others."
该草案称：“本文件的初始版本由IESG于2002年编制。此后，根据约翰·拉夫尼、亨里克·列夫科维茨、马克·汤斯利、兰迪·布什和其他人的反馈，对其进行了修改。”
Valuable comments and suggestions on the current form of the document were made by Loa Andersson, Ran Atkinson, Stewart Bryant, Leslie Daigle, Alan DeKok, Roy Fielding, Phillip Hallam-Baker, Ted Hardie, Alfred Hoenes, John Klensin, Barry Leiba, Eric Rescorla, Adam Roach, and Pekka Savola. The text on TLS experience was contributed by Yngve Pettersen.
Loa Andersson、Ran Atkinson、Stewart Bryant、Leslie Daigle、Alan DeKok、Roy Fielding、Phillip Hallam Baker、Ted Hardie、Alfred Hoenes、John Klesins、Barry Leiba、Eric Rescorla、Adam Roach和Pekka Savola对文件的当前形式提出了宝贵的意见和建议。关于TLS经验的文本由Yngve Pettersen提供。
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Spencer Dawkins Joel Halpern Russ Housley David Kessens Danny McPherson Jon Peterson Dave Thaler Hannes Tschofenig
伯纳德·阿博巴·贾里·阿尔科·马克·布兰切特·罗斯·卡隆·艾莉莎·库珀·斯宾塞·道金斯·乔尔·哈尔本·罗斯·霍斯利·大卫·凯森斯·丹尼·麦克弗森·乔恩·彼得森·戴夫·泰勒·汉内斯·茨霍芬尼
This section discusses some specific examples as case studies.
本节将讨论一些具体示例作为案例研究。
There are certain documents that specify a change process or describe extension considerations for specific IETF protocols:
某些文件规定了变更过程或描述了特定IETF协议的扩展注意事项：
The SIP change process [RFC3427], [RFC4485], [RFC5727]
The (G)MPLS change process (mainly procedural) [RFC4929]
LDAP extensions [RFC4521]
EPP extensions [RFC3735]
DNS extensions [RFC2671][RFC3597]
SMTP extensions [RFC5321]
The SIP change process [RFC3427], [RFC4485], [RFC5727]
The (G)MPLS change process (mainly procedural) [RFC4929]
LDAP extensions [RFC4521]
EPP extensions [RFC3735]
DNS extensions [RFC2671][RFC3597]
SMTP extensions [RFC5321]
It is relatively common for MIBs, which are all in effect extensions of the SMI data model, to be defined or extended outside the IETF. BCP 111 [RFC4181] offers detailed guidance for authors and reviewers.
MIB在IETF之外定义或扩展是比较常见的，MIB实际上都是SMI数据模型的扩展。BCP 111[RFC4181]为作者和评审员提供了详细的指导。
The RADIUS [RFC2865] protocol was designed to be extensible via addition of Attributes. This extensibility model assumed that Attributes would conform to a limited set of data types and that vendor extensions would be limited to use by vendors in situations in which interoperability was not required. Subsequent developments have stretched those assumptions.
RADIUS[RFC2865]协议旨在通过添加属性进行扩展。此扩展性模型假设属性将符合一组有限的数据类型，并且供应商扩展将限于供应商在不需要互操作性的情况下使用。随后的事态发展使这些假设变得捉襟见肘。
From the beginning, uses of the RADIUS protocol extended beyond the scope of the original protocol definition (and beyond the scope of the RADIUS Working Group charter). In addition to rampant self-allocation within the limited RADIUS standard attribute space, vendors defined their own RADIUS commands. This led to the rapid proliferation of vendor-specific protocol variants. To this day, many common implementation practices have not been documented. For example, authentication server implementations are often typically based on a Data Dictionary, enabling addition of Attributes without requiring code changes. Yet, the concept of a Data Dictionary is not mentioned in the RADIUS specification [RFC2865].
从一开始，RADIUS协议的使用就超出了原始协议定义的范围（以及RADIUS工作组章程的范围）。除了在有限的RADIUS标准属性空间内进行大量的自我分配外，供应商还定义了自己的RADIUS命令。这导致特定于供应商的协议变体迅速增加。到目前为止，许多常见的实现实践还没有被记录下来。例如，身份验证服务器实现通常基于数据字典，支持添加属性而无需更改代码。然而，RADIUS规范[RFC2865]中没有提到数据字典的概念。
As noted in "Extended RADIUS Practices" [RFC2882], Section 1:
如“扩展半径实践”[RFC2882]第1节所述：
The RADIUS Working Group was formed in 1995 to document the protocol of the same name, and was chartered to stay within a set of bounds for dial-in terminal servers. Unfortunately the real world of Network Access Servers (NASes) hasn't stayed that small and simple, and continues to evolve at an amazing rate.
RADIUS工作组成立于1995年，以记录同名协议，并被特许在拨入终端服务器的一组范围内。不幸的是，网络访问服务器（NASE）的现实世界并没有保持那么小和简单，而是继续以惊人的速度发展。
This document shows some of the current implementations on the market have already outstripped the capabilities of the RADIUS protocol. A quite a few features have been developed completely outside the protocol. These features use the RADIUS protocol structure and format, but employ operations and semantics well beyond the RFC documents.
本文档显示，目前市场上的一些实现已经超过了RADIUS协议的功能。相当多的功能完全在协议之外开发。这些特性使用RADIUS协议结构和格式，但使用的操作和语义远远超出RFC文档。
The limited set of data types defined in the RADIUS specification [RFC2865] led to subsequent documents defining new data types. Since new data types are typically defined implicitly as part of defining a new attribute and because RADIUS client and server implementations differ in their support of these additional specifications, there is no definitive registry of RADIUS data types, and data type support has been inconsistent. To catalog commonly implemented data types as well as to provide guidance for implementers and attribute designers, Section 2.1 of "RADIUS Design Guidelines" [RFC6158] includes advice on basic and complex data types. Unfortunately, these guidelines [RFC6158] were published in 2011, 14 years after the RADIUS protocol was first documented [RFC2058] in 1997.
RADIUS规范[RFC2865]中定义的有限数据类型集导致后续文档定义了新的数据类型。由于新数据类型通常是作为定义新属性的一部分隐式定义的，并且由于RADIUS客户端和服务器实现在对这些附加规范的支持方面有所不同，因此没有RADIUS数据类型的最终注册表，并且数据类型支持一直不一致。为了对通常实现的数据类型进行分类，并为实现者和属性设计者提供指导，“RADIUS设计指南”[RFC6158]第2.1节包括关于基本和复杂数据类型的建议。不幸的是，这些指南[RFC6158]是在2011年发布的，距离1997年首次记录RADIUS协议[RFC2058]已有14年之久。
Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism for Vendor-Specific extensions (Attribute 26) and states that use of Vendor-Specific extensions:
RADIUS规范[RFC2865]第6.2节定义了供应商特定扩展的机制（属性26），并说明供应商特定扩展的使用：
should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful.
对于仅针对一家供应商的RADIUS实施的功能，如果认为互操作性没有用处，则应鼓励使用该方法，而不是分配全局属性类型。
However, in practice, usage of Vendor-Specific Attributes (VSAs) has been considerably broader than this. In particular, VSAs have been used by Standards Development Organizations (SDOs) to define their own extensions to the RADIUS protocol. This has caused a number of problems.
然而，在实践中，特定于供应商的属性（VSA）的使用比这要广泛得多。特别是，标准开发组织（SDO）使用VSA来定义自己对RADIUS协议的扩展。这造成了许多问题。
One issue concerns the data model for VSAs. Since it was not envisaged that multi-vendor VSA implementations would need to interoperate, the RADIUS specification [RFC2865] does not define the data model for VSAs and allows multiple sub-attributes to be included within a single Attribute of type 26. Since this enables VSAs to be defined that would not be supportable by current implementations if placed within the standard RADIUS attribute space, this has caused problems in standardizing widely deployed VSAs, as discussed in Section 2.4 of "RADIUS Design Guidelines" BCP 158 [RFC6158]:
一个问题涉及VSAs的数据模型。由于没有设想多供应商VSA实现需要互操作，RADIUS规范[RFC2865]没有定义VSA的数据模型，并且允许在26型的单个属性中包含多个子属性。由于这使得VSA的定义在标准RADIUS属性空间内不受当前实施的支持，这导致了广泛部署VSA的标准化问题，如“RADIUS设计指南”BCP 158[RFC6158]第2.4节所述：
RADIUS attributes can often be developed within the vendor space without loss (and possibly even with gain) in functionality. As a result, translation of RADIUS attributes developed within the vendor space into the standard space may provide only modest
RADIUS属性通常可以在供应商空间内开发，而不会损失（甚至可能获得）功能。因此，将供应商空间内开发的RADIUS属性转换为标准空间可能只能提供适度的效果
benefits, while accelerating the exhaustion of the standard space. We do not expect that all RADIUS attribute specifications requiring interoperability will be developed within the IETF, and allocated from the standard space. A more scalable approach is to recognize the flexibility of the vendor space, while working toward improvements in the quality and availability of RADIUS attribute specifications, regardless of where they are developed.
好处，同时加速标准空间的耗尽。我们不期望要求互操作性的所有RADIUS属性规范都将在IETF内开发，并从标准空间分配。一种更具可扩展性的方法是认识到供应商空间的灵活性，同时努力提高RADIUS属性规范的质量和可用性，而不管这些规范是在哪里开发的。
It is therefore NOT RECOMMENDED that specifications intended solely for use by a vendor or SDO be translated into the standard space.
因此，不建议将仅供供应商或SDO使用的规范转换为标准空间。
Another issue is how implementations should handle unknown VSAs. Section 5.26 of the RADIUS specification [RFC2865] states:
另一个问题是实现应该如何处理未知VSA。半径规范[RFC2865]第5.26节规定：
Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.
未配备解释客户发送的供应商特定信息的服务器必须忽略该信息（尽管可能会报告）。未收到所需供应商特定信息的客户机应尝试在没有供应商特定信息的情况下运行，尽管他们可能会在降级模式下这样做（并报告他们正在这样做）。
However, since VSAs do not contain a "mandatory" bit, RADIUS clients and servers may not know whether it is safe to ignore unknown VSAs. For example, in the case where VSAs pertain to security (e.g., Filters), it may not be safe to ignore them. As a result, Section 2.5 of "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC5080] includes the following caution:
但是，由于VSA不包含“强制”位，RADIUS客户端和服务器可能不知道忽略未知VSA是否安全。例如，在VSA涉及安全性（例如过滤器）的情况下，忽略它们可能不安全。因此，“通用远程身份验证拨入用户服务（RADIUS）实施问题和建议修复”[RFC5080]第2.5节包括以下警告：
To avoid misinterpretation of service requests encoded within VSAs, RADIUS servers SHOULD NOT send VSAs containing service requests to RADIUS clients that are not known to understand them. For example, a RADIUS server should not send a VSA encoding a filter without knowledge that the RADIUS client supports the VSA.
为了避免对VSA中编码的服务请求的误解，RADIUS服务器不应将包含服务请求的VSA发送给不了解它们的RADIUS客户端。例如，RADIUS服务器不应在不知道RADIUS客户端支持VSA的情况下发送编码筛选器的VSA。
In addition to extending RADIUS by use of VSAs, SDOs have also defined new values of the Service-Type attribute in order to create new RADIUS commands. Since the RADIUS specification [RFC2865] defined Service-Type values as being allocated First Come, First Served (FCFS) [RFC5226], this permitted new RADIUS commands to be allocated without IETF review. This oversight has since been fixed in "IANA Considerations for RADIUS" [RFC3575].
除了使用VSA扩展RADIUS之外，SDO还定义了服务类型属性的新值，以便创建新的RADIUS命令。由于RADIUS规范[RFC2865]将服务类型值定义为分配先到先服务（FCFS）[RFC5226]，因此允许在没有IETF审查的情况下分配新的RADIUS命令。这一疏忽已在“IANA对RADIUS的注意事项”[RFC3575]中修复。
The Secure Sockets Layer (SSL) Version 2 Protocol was developed by Netscape to be used to secure online transactions on the Internet. It was later replaced by SSLv3, also developed by Netscape. SSLv3 was then further developed by the IETF as the Transport Layer Security (TLS) 1.0 [RFC2246].
安全套接字层（SSL）第2版协议由Netscape开发，用于保护Internet上的在线交易。后来被同样由Netscape开发的SSLv3取代。SSLv3随后由IETF进一步开发为传输层安全（TLS）1.0[RFC2246]。
The SSLv3 protocol was not explicitly specified to be extended. Even TLS 1.0 did not define an extension mechanism explicitly. However, extension "loopholes" were available. Extension mechanisms were finally defined in "Transport Layer Security (TLS) Extensions" [RFC4366]:
没有明确指定要扩展的SSLv3协议。即使TLS1.0也没有明确定义扩展机制。然而，扩展“漏洞”是存在的。扩展机制最终在“传输层安全（TLS）扩展”[RFC4366]中定义：
o New versions o New cipher suites o Compression o Expanded handshake messages o New record types o New handshake messages
o 新版本o新密码套件o压缩o扩展握手消息o新记录类型o新握手消息
The protocol also defines how implementations should handle unknown extensions.
该协议还定义了实现应该如何处理未知扩展。
Of the above extension methods, new versions and expanded handshake messages have caused the most interoperability problems. Implementations are supposed to ignore unknown record types but to reject unknown handshake messages.
在上述扩展方法中，新版本和扩展的握手消息造成了最多的互操作性问题。实现应该忽略未知的记录类型，但拒绝未知的握手消息。
The new version support in SSL/TLS includes a capability to define new versions of the protocol, while allowing newer implementations to communicate with older implementations. As part of this functionality, some Key Exchange methods include functionality to prevent version rollback attacks.
SSL/TLS中的新版本支持包括定义协议新版本的功能，同时允许较新的实现与较旧的实现通信。作为此功能的一部分，一些密钥交换方法包括防止版本回滚攻击的功能。
The experience with this upgrade functionality in SSL and TLS is decidedly mixed:
在SSL和TLS中使用此升级功能的经验明显混合在一起：
o SSLv2 and SSLv3/TLS are not compatible. It is possible to use SSLv2 protocol messages to initiate an SSLv3/TLS connection, but it is not possible to communicate with an SSLv2 implementation using SSLv3/TLS protocol messages. o There are implementations that refuse to accept handshakes using newer versions of the protocol than they support. o There are other implementations that accept newer versions but have implemented the version rollback protection clumsily.
o SSLv2和SSLv3/TLS不兼容。可以使用SSLv2协议消息来启动SSLv3/TLS连接，但不可能使用SSLv3/TLS协议消息与SSLv2实现通信。o有一些实现拒绝接受使用较新版本的协议进行的握手，而这些版本的协议比它们所支持的版本更新。o还有其他接受较新版本的实现，但笨拙地实现了版本回滚保护。
The SSLv2 problem has forced SSLv3 and TLS clients to continue to use SSLv2 Client Hellos for their initial handshake with almost all servers until 2006, much longer than would have been desirable, in order to interoperate with old servers.
SSLv2问题迫使SSLv3和TLS客户机在2006年之前继续使用SSLv2客户机Hellos与几乎所有服务器进行初始握手，这比预期的要长得多，以便与旧服务器进行互操作。
The problem with incorrect handling of newer versions has also forced many clients to actually disable the newer protocol versions, either by default or by automatically disabling the functionality, to be able to connect to such servers. Effectively, this means that the version rollback protection in SSL and TLS is non-existent if talking to a fatally compromised older version.
错误处理较新版本的问题也迫使许多客户端实际上禁用较新的协议版本（默认情况下或通过自动禁用功能），以便能够连接到此类服务器。实际上，这意味着如果与严重受损的旧版本对话，SSL和TLS中的版本回滚保护将不存在。
SSLv3 and TLS also permitted extension of the Client Hello and Server Hello handshake messages. This functionality was fully defined by the introduction of TLS extensions, which make it possible to add new functionality to the handshake, such as the name of the server the client is connecting to, request certificate status information, and indicate Certificate Authority support, maximum record length, etc. Several of these extensions also introduce new handshake messages.
SSLv3和TLS还允许扩展客户端Hello和服务器Hello握手消息。TLS扩展的引入充分定义了这一功能，它可以为握手添加新功能，例如客户端连接到的服务器的名称、请求证书状态信息，并指示证书颁发机构支持、最大记录长度，其中一些扩展还引入了新的握手消息。
It has turned out that many SSLv3 and TLS implementations that do not support TLS extensions did not ignore the unknown extensions, as required by the protocol specifications, but instead failed to establish connections. Since several of the implementations behaving in this manner are used by high-profile Internet sites, such as online banking sites, this has caused a significant delay in the deployment of clients supporting TLS extensions, and several of the clients that have enabled support are using heuristics that allow them to disable the functionality when they detect a problem.
事实证明，许多不支持TLS扩展的SSLv3和TLS实现并没有按照协议规范的要求忽略未知扩展，而是未能建立连接。由于高知名度的互联网站点（如网上银行站点）使用了几种以这种方式运行的实现，这导致了支持TLS扩展的客户端部署的重大延迟，一些启用了支持的客户机正在使用启发式，允许他们在检测到问题时禁用功能。
Looking forward, the protocol version problem, in particular, can cause future security problems for the TLS protocol. The strength of the digest algorithms (MD5 and SHA-1) used by SSL and TLS is weakening. If MD5 and SHA-1 weaken to the point where it is feasible to mount successful attacks against older SSL and TLS versions, the current error recovery used by clients would become a security vulnerability (among many other serious problems for the Internet).
展望未来，协议版本问题尤其可能导致TLS协议未来的安全问题。SSL和TLS使用的摘要算法（MD5和SHA-1）的强度正在减弱。如果MD5和SHA-1削弱到可以对较旧的SSL和TLS版本成功发起攻击的程度，那么客户端当前使用的错误恢复将成为一个安全漏洞（互联网的许多其他严重问题之一）。
To address this issue, TLS 1.2 [RFC5246] makes use of a newer cryptographic hash algorithm (SHA-256) during the TLS handshake by default. Legacy ciphersuites can still be used to protect application data, but new ciphersuites are specified for data protection as well as for authentication within the TLS handshake. The hashing method can also be negotiated via a Hello extension. Implementations are encouraged to implement new ciphersuites and to enable the negotiation of the ciphersuite used during a TLS session to be governed by policy, thus enabling a more rapid transition away from weakened ciphersuites.
为了解决这个问题，默认情况下，TLS 1.2[RFC5246]在TLS握手期间使用了更新的加密哈希算法（SHA-256）。旧式密码套件仍可用于保护应用程序数据，但新密码套件被指定用于数据保护以及TLS握手中的身份验证。哈希方法也可以通过Hello扩展进行协商。鼓励实现实现新的密码套件，并使TLS会话期间使用的密码套件的协商受策略控制，从而实现从弱化密码套件的更快速过渡。
The lesson to be drawn from this experience is that it isn't sufficient to design extensibility carefully; it must also be implemented carefully by every implementer, without exception. Test suites and certification programs can help provide incentives for implementers to pay attention to implementing extensibility mechanisms correctly.
从这一经验中吸取的教训是，仔细设计可扩展性是不够的；它也必须由每个实施者仔细实施，无一例外。测试套件和认证计划有助于激励实现者注意正确实现可扩展性机制。
The Layer Two Tunneling Protocol (L2TP) [RFC2661] carries Attribute-Value Pairs (AVPs), with most AVPs having no semantics to the L2TP protocol itself. However, it should be noted that L2TP message types are identified by a Message Type AVP (Attribute Type 0) with specific AVP values indicating the actual message type. Thus, extensions relating to Message Type AVPs would likely be considered major extensions.
第二层隧道协议（L2TP）[RFC2661]承载属性值对（AVP），大多数AVP对L2TP协议本身没有语义。但是，应注意，L2TP消息类型由消息类型AVP（属性类型0）标识，特定AVP值指示实际消息类型。因此，与消息类型avp相关的扩展可能被视为主要扩展。
L2TP also provides for vendor-specific AVPs. Because everything in L2TP is encoded using AVPs, it would be easy to define vendor-specific AVPs that would be considered major extensions.
L2TP还提供特定于供应商的AVP。因为L2TP中的所有内容都是使用AVP编码的，所以很容易定义被视为主要扩展的特定于供应商的AVP。
L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP messages containing AVPs that they do not understand but that have the mandatory bit set, are expected to reject the message and terminate the tunnel or session the message refers to. This leads to interesting interoperability issues, because a sender can include a vendor-specific AVP with the M-bit set, which then causes the recipient to not interoperate with the sender. This sort of behavior is counter to the IETF ideals, as implementations of the IETF standard should interoperate successfully with other implementations and not require the implementation of non-IETF extensions in order to interoperate successfully. Section 4.2 of the L2TP specification [RFC2661] includes specific wording on this point, though there was significant debate at the time as to whether such language was by itself sufficient.
L2TP还提供了AVPs中的“强制”位。L2TP消息（包含他们不理解但设置了强制位的AVP）的收件人应拒绝该消息并终止该消息所指的隧道或会话。这导致了有趣的互操作性问题，因为发送方可以将供应商特定的AVP包含在M位集合中，这会导致接收方无法与发送方进行互操作。这种行为与IETF理念背道而驰，因为IETF标准的实现应该与其他实现成功互操作，而不需要实现非IETF扩展才能成功互操作。L2TP规范[RFC2661]第4.2节包含了关于这一点的具体措辞，尽管当时存在着关于此类语言本身是否足够的重大争论。
Fortunately, it does not appear that the potential problems described above have yet become a problem in practice. At the time of this writing, the authors are not aware of the existence of any vendor-specific AVPs that also set the M-bit.
幸运的是，上述潜在问题似乎尚未成为实际问题。在撰写本文时，作者不知道是否存在任何也设置M位的供应商特定AVP。
Authors' Addresses
作者地址
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand
Brian Carpenter奥克兰大学计算机系，奥克兰92019，新西兰1142
EMail: brian.e.carpenter@gmail.com
EMail: brian.e.carpenter@gmail.com
Bernard Aboba (editor) PMB 606 15600 NE 8th Street, Suite B1 Bellevue, WA 98008 USA
Bernard Aboba（编辑）PMB 606 15600美国华盛顿州贝尔维尤东北第八街B1室，邮编：98008
EMail: bernard_aboba@hotmail.com
EMail: bernard_aboba@hotmail.com
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
斯图尔特柴郡苹果公司，美国加利福尼亚州库比蒂诺市无限环路1号，邮编95014
EMail: cheshire@apple.com
EMail: cheshire@apple.com