Internet Architecture Board (IAB) D. Thaler, Ed.
Request for Comments: 8170 May 2017
Category: Informational
ISSN: 2070-1721
Internet Architecture Board (IAB) D. Thaler, Ed.
Request for Comments: 8170 May 2017
Category: Informational
ISSN: 2070-1721
Planning for Protocol Adoption and Subsequent Transitions
协议采用和后续过渡的规划
Abstract
摘要
Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions; thus, some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and it also summarizes what makes for a good transition plan.
自从引入Internet协议以来的许多年中，我们看到了协议栈中的许多转换，例如部署新协议，或更新或替换现有协议。许多协议和技术的设计并不是为了能够顺利过渡到替代方案或轻松部署扩展；因此，一些过渡，如IPv6的引入，一直很困难。本文档试图总结一些基本原则，以实现未来的过渡，同时也总结了如何制定一个好的过渡计划。
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 7841.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8170.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8170.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Transition vs. Coexistence . . . . . . . . . . . . . . . . . 5
4. Translation/Adaptation Location . . . . . . . . . . . . . . . 6
5. Transition Plans . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Understanding of Existing Deployment . . . . . . . . . . 7
5.2. Explanation of Incentives . . . . . . . . . . . . . . . . 7
5.3. Description of Phases and Proposed Criteria . . . . . . . 8
5.4. Measurement of Success . . . . . . . . . . . . . . . . . 8
5.5. Contingency Planning . . . . . . . . . . . . . . . . . . 8
5.6. Communicating the Plan . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . 10
Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 14
A.1. Explicit Congestion Notification . . . . . . . . . . . . 14
A.2. Internationalized Domain Names . . . . . . . . . . . . . 15
A.3. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.4. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.4.1. Protocol Versioning, Extensions, and 'Grease' . . . . 20
A.4.2. Limits on Changes in Major Versions . . . . . . . . . 20
A.4.3. Planning for Replacement . . . . . . . . . . . . . . 21
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Transition vs. Coexistence . . . . . . . . . . . . . . . . . 5
4. Translation/Adaptation Location . . . . . . . . . . . . . . . 6
5. Transition Plans . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Understanding of Existing Deployment . . . . . . . . . . 7
5.2. Explanation of Incentives . . . . . . . . . . . . . . . . 7
5.3. Description of Phases and Proposed Criteria . . . . . . . 8
5.4. Measurement of Success . . . . . . . . . . . . . . . . . 8
5.5. Contingency Planning . . . . . . . . . . . . . . . . . . 8
5.6. Communicating the Plan . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . 10
Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 14
A.1. Explicit Congestion Notification . . . . . . . . . . . . 14
A.2. Internationalized Domain Names . . . . . . . . . . . . . 15
A.3. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.4. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.4.1. Protocol Versioning, Extensions, and 'Grease' . . . . 20
A.4.2. Limits on Changes in Major Versions . . . . . . . . . 20
A.4.3. Planning for Replacement . . . . . . . . . . . . . . 21
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
A "transition" is the process or period of changing from one state or condition to another. There are several types of such transitions, including both technical transitions (e.g., changing protocols or deploying an extension) and organizational transitions (e.g., changing what organization manages a web site). This document focuses solely on technical transitions, although some principles might apply to other types as well.
“过渡”是指从一种状态或条件转变为另一种状态或条件的过程或时期。这种转换有几种类型，包括技术转换（例如，更改协议或部署扩展）和组织转换（例如，更改组织管理网站的内容）。本文档仅关注技术转换，尽管有些原则也可能适用于其他类型。
In this document, we use the term "transition" generically to apply to any of:
在本文件中，我们一般使用术语“过渡”来适用于以下任何情况：
o adoption of a new protocol where none existed before,
o 通过一项以前不存在的新议定书，
o deployment of a new protocol that obsoletes a previous protocol,
o 部署淘汰以前协议的新协议，
o deployment of an updated version of an existing protocol, or
o 部署现有协议的更新版本，或
o decommissioning of an obsolete protocol.
o 废弃协议的退役。
There have been many IETF and IAB RFCs and IAB statements discussing transitions of various sorts. Most are protocol-specific documents about specific transitions. For example, some relevant ones in which the IAB has been involved include:
已经有许多IETF和IAB RFC以及IAB声明讨论了各种类型的转换。大多数是关于特定转换的协议特定文档。例如，IAB参与的一些相关项目包括：
o IAB RFC 3424 [RFC3424] recommended that any technology for so-called "UNilateral Self-Address Fixing (UNSAF)" across NATs include an exit strategy to transition away from such a mechanism. Since the IESG, not the IAB, approves IETF documents, the IESG thus became the body to enforce (or not) such a requirement.
o IAB RFC 3424[RFC3424]建议，任何跨NAT的所谓“单边自定址（UNSAF）”技术都应包括一种退出策略，以摆脱这种机制。由于IESG而非IAB批准IETF文件，因此IESG成为执行（或不执行）此类要求的机构。
o IAB RFC 4690 [RFC4690] gave recommendations around internationalized domain names. It discussed issues around the process of transitioning to new versions of Unicode, and this resulted in the creation of the IETF Precis Working Group (WG) to address this problem.
o IAB RFC 4690[RFC4690]给出了关于国际化域名的建议。它讨论了向Unicode新版本过渡过程中的问题，并由此成立了IETF Precis工作组（WG）来解决这个问题。
o The IAB statement on "Follow-up work on NAT-PT" [IabIpv6TransitionStatement] pointed out gaps at the time in transitioning to IPv6, and this resulted in the rechartering of the IETF Behave WG to solve this problem.
o IAB关于“NAT-PT的后续工作”[IabIpv6TransitionStatement]的声明指出了过渡到IPv6时的差距，这导致IETF Behave WG重新调整以解决此问题。
More recently, the IAB has done work on more generally applicable principles, including two RFCs.
最近，IAB就更普遍适用的原则开展了工作，包括两个RFC。
IAB RFC 5218 [RFC5218] on "What Makes for a Successful Protocol?" studied specifically what factors contribute to, and detract from, the success of a protocol and it made a number of recommendations. It discussed two types of transitions: "initial success" (the transition to the technology) and extensibility (the transition to updated versions of it). The principles and recommendations in that document are generally applicable to all technical transitions. Some important principles included:
IAB RFC 5218[RFC5218]关于“什么促成了一个成功的方案？”专门研究了哪些因素有助于和有损于一个方案的成功，并提出了一些建议。它讨论了两种类型的转换：“初始成功”（向技术的转换）和可扩展性（向更新版本的转换）。该文件中的原则和建议通常适用于所有技术过渡。一些重要原则包括：
1. Incentive: Transition is easiest when the benefits come to those bearing the costs. That is, the benefits should outweigh the costs at *each* entity. Some successful cases did this by providing incentives (e.g., tax breaks), or by reducing costs (e.g., freely available source), or by imposing costs of not transitioning (e.g., regulation), or even by narrowing the scenarios of applicability to just the cases where benefits do outweigh costs at all relevant entities.
1. 激励措施：当利益降临到承担成本的人身上时，转型是最容易的。也就是说，每个实体的收益应该大于成本。一些成功案例通过提供激励（如税收减免）或通过降低成本（如免费提供来源），或通过施加不过渡的成本（如监管），甚至通过将适用场景缩小到所有相关实体的收益确实大于成本的情况来实现这一点。
2. Incremental Deployability: Backwards compatibility makes transition easier. Furthermore, transition is easiest when changing only one entity still benefits that entity. In the easiest case, the benefit immediately outweighs the cost, so entities are naturally incented to transition. More commonly, the benefits only outweigh the costs once a significant number of other entities also transition. Unfortunately, in such cases, the natural incentive is often to delay transitioning.
2. 增量部署能力：向后兼容性使转换更容易。此外，当仅更改一个实体仍使该实体受益时，转换是最容易的。在最简单的情况下，收益立即超过成本，因此实体自然会被激励进行转型。更常见的情况是，一旦大量其他实体也进行了转型，收益才会超过成本。不幸的是，在这种情况下，自然的动机往往是推迟过渡。
3. Total Cost: It is important to consider costs that go beyond the core hardware and software, such as operational tools and processes, personnel training, business model (accounting/ billing) dependencies, and legal (regulation, patents, etc.) costs.
3. 总成本：重要的是考虑超出核心硬件和软件的成本，如操作工具和过程、人员培训、业务模型（计费/计费）依赖和法律（法规、专利等）成本。
4. Extensibility: Design for extensibility [RFC6709] so that things can be fixed up later.
4. 可扩展性：针对可扩展性[RFC6709]进行设计，以便以后可以解决问题。
IAB RFC 7305 [RFC7305] reported on an IAB workshop on Internet Technology Adoption and Transition (ITAT). Like RFC 5218, this workshop also discussed economic aspects of transition, not just technical aspects. Some important observations included:
IAB RFC 7305[RFC7305]报告了IAB关于互联网技术采用和过渡（ITAT）的研讨会。与RFC 5218一样，本次研讨会也讨论了转型的经济方面，而不仅仅是技术方面。一些重要的意见包括：
1. Early-Adopter Incentives: Part of Bitcoin's strategy was extra incentives for early adopters compared to late adopters. That is, providing a long-term advantage to early adopters can help stimulate transition even when the initial costs outweigh the initial benefit.
1. 早期采用者激励：比特币战略的一部分是与后期采用者相比，对早期采用者的额外激励。也就是说，为早期采用者提供长期优势有助于刺激转型，即使初始成本超过初始收益。
2. Policy Partners: Policy-making organizations of various sorts (Regional Internet Registries (RIRs), ICANN, etc.) can be important partners in enabling and facilitating transition.
2. 政策伙伴：各种政策制定组织（区域互联网注册中心（RIR）、ICANN等）可以成为促成和促进转型的重要伙伴。
The remainder of this document continues the discussion started in those two RFCs and provides some additional thoughts on the topic of transition strategies and plans.
本文件的其余部分继续了这两个RFC中开始的讨论，并就过渡战略和计划的主题提供了一些额外的想法。
Many protocols are designed to be extensible, using mechanisms such as options, version negotiation, etc., to ease the transition to new features. However, implementations often succumb to commercial pressures to ignore this flexibility in favor of performance or economy, and as a result such extension mechanisms (e.g., IPv6 Hop-by-Hop Options) often experience problems in practice once they begin to be used. In other cases, a mechanism might be put into a protocol for future use without having an adequate sense of how it will be used, which causes problems later (e.g., SNMP's original 'security'
许多协议被设计为可扩展的，使用诸如选项、版本协商等机制来简化向新功能的转换。然而，实现往往屈服于商业压力，为了性能或经济性而忽略这种灵活性，因此，这种扩展机制（例如，IPv6逐跳选项）一旦开始使用，在实践中往往会遇到问题。在其他情况下，可能会将一种机制放入协议中供将来使用，而对如何使用该机制没有足够的认识，这会导致以后出现问题（例如，SNMP最初的“安全性”）
field, or the IPv6 Flow Label). Thus, designers need to consider whether it would be easier to transition to a new protocol than it would be to ensure that an extension point is correctly specified and implemented such that it would be available when needed.
字段或IPv6流标签）。因此，设计者需要考虑是否更容易过渡到新的协议，而不是确保扩展点被正确地指定和实现，以便在需要时可用。
A protocol that plans for its own eventual replacement during its design makes later transitions easier. Developing and testing a design for the technical mechanisms needed to signal or negotiate a replacement is essential in such a plan.
在设计过程中计划自己最终替换的协议使以后的转换更容易。在这样一个计划中，开发和测试发出更换信号或协商更换所需的技术机制设计至关重要。
When there is interest in translation between a new mechanism and an old one, complexity of such translation must also be considered. The major challenge in translation is for semantic differences. Often, syntactic differences can be translated seamlessly; semantic ones almost never. Hence, when designing for translatability, syntactic and semantic differences should be clearly documented.
当人们对新机制和旧机制之间的转换感兴趣时，也必须考虑这种转换的复杂性。翻译中的主要挑战是语义差异。通常，句法差异可以无缝翻译；语义的几乎从来没有。因此，在设计可译性时，应明确记录句法和语义差异。
See RFC 3692 [RFC3692] and RFC 6709 [RFC6709] for more discussion of design considerations for protocol extensions.
有关协议扩展设计注意事项的更多讨论，请参见RFC 3692[RFC3692]和RFC 6709[RFC6709]。
There is an important distinction between a strict "flag day" style transition where an old mechanism is immediately replaced with a new mechanism, vs. a looser coexistence-based approach where transition proceeds in stages where a new mechanism is first added alongside an existing one for some overlap period, and then the old mechanism is removed at a later stage.
严格的“卖旗日”式过渡（即旧机制立即被新机制取代）与更宽松的基于共存的方法（即过渡分阶段进行，在一段重叠期内，新机制首先与现有机制一起添加）之间存在重要区别，然后，旧机制将在稍后阶段移除。
When a new mechanism is backwards compatible with an existing mechanism, transition is easiest because different parties can transition at different times. However, when no backwards compatibility exists such as in the IPv4 to IPv6 transition, a transition plan must choose either a "flag day" or a period of coexistence. When a large number of entities are involved, a flag day becomes impractical or even impossible. Coexistence, on the other hand, involves additional costs of maintaining two separate mechanisms during the overlap period, which could be quite long. Furthermore, the longer the overlap period, the more the old mechanism might get further deployment and thus increase the overall pain of transition.
当新机制与现有机制向后兼容时，转换最容易，因为不同的参与方可以在不同的时间进行转换。但是，如果不存在向后兼容性，例如IPv4到IPv6过渡，则过渡计划必须选择“国旗日”或共存期。当涉及大量实体时，卖旗日变得不切实际，甚至不可能。另一方面，共存涉及在可能相当长的重叠期内维持两个单独机制的额外费用。此外，重叠期越长，旧机制得到进一步部署的可能性就越大，从而增加过渡的总体痛苦。
Often the decision between a "flag day" and a sustained coexistence period may be complicated when differing incentives are involved (e.g., see the case studies in the Appendix).
通常，当涉及不同的激励时，“卖旗日”和持续共存期之间的决定可能会很复杂（例如，见附录中的案例研究）。
Some new protocols or protocol versions are developed with the intent of never retiring the protocol they intend to replace. Such a
开发一些新协议或协议版本的目的是永远不会使它们打算替换的协议失效。这样的
protocol might only aim to address a subset of the use cases for which an original is used. For these protocols, coexistence is the end state.
协议可能只针对使用原始版本的用例的子集。对于这些协议，共存是最终状态。
Indefinite coexistence as an approach could be viable if removal of the existing protocol is not an urgent goal. It might also be necessary for "wildly successful" protocols that have more disparate uses than can reasonably be considered during the design of a replacement. For example, HTTP/2 does not aspire to cause the eventual decommissioning of HTTP/1.1 for these reasons.
如果取消现有议定书不是一个紧迫的目标，无限期共存作为一种办法是可行的。对于“非常成功”的协议来说，这也是必要的，因为这些协议具有比设计替换协议时合理考虑的更多的不同用途。例如，由于这些原因，HTTP/2不希望导致HTTP/1.1最终退役。
A translation or adaptation mechanism is often required if the old and new mechanisms are not interoperable. Care must be taken when determining whether one will work and where such a translator is best placed.
如果新旧机制不可互操作，则通常需要翻译或改编机制。在决定一个人是否会工作以及这样一名翻译的最佳位置时，必须小心。
A translation mechanism may not work for every use case. For example, if translation from one protocol (or protocol version) to another produces indeterminate results, translation will not work reliably. In addition, if translation always produces a downgraded protocol result, the incentive considerations in Section 5.2 will be relevant.
翻译机制可能不适用于所有用例。例如，如果从一个协议（或协议版本）到另一个协议的转换产生不确定的结果，则转换将无法可靠地工作。此外，如果翻译总是产生降级协议结果，则第5.2节中的激励因素将是相关的。
Requiring a translator in the middle of the path can hamper end-to-end security and reliability. For example, see the discussion of network-based filtering in [RFC7754].
需要在路径中间的翻译器会妨碍端到端的安全性和可靠性。例如，请参阅[RFC7754]中关于基于网络的过滤的讨论。
On the other hand, requiring a translation layer within an endpoint can be a resource issue in some cases, such as if the endpoint could be a constrained node [RFC7228].
另一方面，在某些情况下，需要端点内的转换层可能是一个资源问题，例如端点可能是受约束的节点[RFC7228]。
In addition, when a translator is within an endpoint, it can attempt to hide the difference between an older protocol and a newer protocol, either by exposing one of the two sets of behavior to applications and internally mapping it to the other set of behavior, or by exposing a higher level of abstraction that is then alternatively mapped to either one depending on detecting which is needed. In contrast, when a translator is in the middle of the path, typically only the first approach can be done since the middle of the path is typically unable to provide a higher level of abstraction.
此外，当转换器位于端点内时，它可以尝试隐藏较旧协议和较新协议之间的差异，方法是向应用程序公开两组行为中的一组，并在内部将其映射到另一组行为，或者通过公开更高级别的抽象，然后根据需要将其映射到其中一个。相反，当翻译器位于路径的中间时，通常只有第一个方法可以完成，因为路径的中间通常不能提供更高级别的抽象。
Any transition strategy for a non-backward-compatible mechanism should include a discussion of where the incompatible mechanism is placed and a rationale. The transition plan should also consider the transition away from the use of translation and adaptation technologies.
非向后兼容机制的任何转换策略都应包括对不兼容机制放置位置的讨论和基本原理。过渡计划也应该考虑远离翻译和适应技术的使用。
A review of the case studies described in Appendix A suggests that a good transition plan include at least the following components: an understanding of what is already deployed and in use, an explanation of incentives for each entity involved, a description of the phases of the transition along with a proposed criteria for each phase, a method for measuring the transition's success, a contingency plan for failure of the transition, and an effective method for communicating the plan to the entities involved and incorporating their feedback thereon. We recommend that such criteria be considered when evaluating proposals to transition to new or updated protocols. Each of these components is discussed in the subsections below.
对附录A中所述案例研究的审查表明，良好的过渡计划至少包括以下组成部分：了解已经部署和使用的内容，解释每个相关实体的激励措施，描述过渡阶段以及每个阶段的拟议标准，衡量过渡成功与否的方法，过渡失败的应急计划，以及将计划传达给相关实体并纳入其反馈的有效方法。我们建议在评估向新的或更新的议定书过渡的提案时考虑这些标准。下面的小节将讨论这些组件中的每一个。
Often an existing mechanism has variations in implementations and operational deployments. For example, a specification might include optional behaviors that may or may not be implemented or deployed. In addition, there may also be implementations or deployments that deviate from, or include vendor-specific extensions to, various aspects of a specification. It is important when considering a transition to understand what variations one is intending to transition from or coexist with, since the technical and non-technical issues may vary greatly as a result.
通常，现有机制在实现和操作部署方面存在差异。例如，规范可能包括可选的行为，这些行为可能实现或部署，也可能未实现或部署。此外，还可能有一些实现或部署偏离规范的各个方面，或包括特定于供应商的对规范各个方面的扩展。在考虑过渡时，重要的是要了解打算从哪些变化过渡或与哪些变化共存，因为技术和非技术问题可能会因此发生很大变化。
A transition plan should explain the incentives to each involved entity to support the transition. Note here that many entities other than the endpoint applications and their users may be affected, and the barriers to transition may be non-technical as well as technical. When considering these incentives, also consider network operations tools, practices and processes, personnel training, accounting and billing dependencies, and legal and regulatory incentives.
过渡计划应向每个相关实体解释支持过渡的激励措施。请注意，除了端点应用程序及其用户之外，许多实体都可能受到影响，过渡的障碍可能是非技术性的，也可能是技术性的。当考虑这些激励措施时，也要考虑网络运营工具、实践和过程、人员培训、会计和计费依赖、以及法律和监管激励。
If there is opposition to a particular new protocol (e.g., from another standards organization, or a government, or some other affected entity), various non-technical issues arise that should be part of what is planned and dealt with. Similarly, if there are significant costs or other disincentives, the plan needs to consider how to overcome them.
如果有人反对某一特定的新协议（例如，来自另一个标准组织、政府或其他受影响的实体），则会出现各种非技术性问题，这些问题应成为计划和处理的内容的一部分。同样，如果有明显的成本或其他不利因素，该计划需要考虑如何克服它们。
It's worth noting that an analysis of incentives can be difficult and at times led astray by wishful thinking, as opposed to adequately considering economic realities. Thus, honestly considering any barriers to transition, and justifying one's conclusions about others' incentives, are key to a successful analysis.
值得注意的是，与充分考虑经济现实相反，对激励因素的分析可能很困难，有时会被一厢情愿引入歧途。因此，诚实地考虑任何过渡障碍，并证明自己对他人激励的结论是正确的，这是成功分析的关键。
Transition phases might include pilot/experimental deployment, coexistence, deprecation, and removal phases for a transition from one technology to another incompatible one.
过渡阶段可能包括从一种技术过渡到另一种不兼容技术的试点/实验部署、共存、弃用和删除阶段。
Timelines are notoriously difficult to predict and impossible to impose on uncoordinated transitions at the scale of the Internet, but rough estimates can sometimes help all involved entities to understand the intended duration of each phase. More often, it is useful to provide criteria that must be met in order to move to the next phase. For example, is removal scheduled for a particular date (e.g., Federal Communications Commission (FCC) regulation to discontinue analog TV broadcasts in the U.S. by June 12, 2009), or is removal to be based on the use of the old mechanism falling below a specified level, or some other criteria?
众所周知，时间线很难预测，也不可能强加给互联网规模的不协调过渡，但粗略估计有时可以帮助所有相关实体了解每个阶段的预期持续时间。通常，提供进入下一阶段必须满足的标准是有用的。例如，删除是否计划在特定日期进行（例如，联邦通信委员会（FCC）规定在2009年6月12日之前停止美国的模拟电视广播），或者删除是基于旧机制的使用低于规定水平，还是基于其他标准？
As one example, RFC 5211 [RFC5211] proposed a transition plan for IPv6 that included a proposed timeline and criteria specific to each phase. While the timeline was not accurately followed, the phases and timeline did serve as inputs to the World IPv6 Day and World IPv6 Launch events.
例如，RFC 5211[RFC5211]提出了IPv6的过渡计划，其中包括针对每个阶段提出的时间表和标准。虽然没有准确遵循时间线，但阶段和时间线确实作为世界IPv6日和世界IPv6发布活动的输入。
The degree of deployment of a given protocol or feature at a given phase in its transition can be measured differently, depending on its design. For example, server-side protocols and options that identify themselves through a versioning or negotiation mechanism can be discovered through active Internet measurement studies.
给定协议或特性在其转换的给定阶段的部署程度可以根据其设计进行不同的度量。例如，通过版本控制或协商机制识别自身的服务器端协议和选项可以通过主动互联网测量研究发现。
A contingency plan can be as simple as providing for indefinite coexistence between an old and new protocol, or for reverting to the old protocol until an updated version of the new protocol is available. Such a plan is useful in the event that unforeseen problems are discovered during deployment, so that such problems can be quickly mitigated.
应急计划可以简单到规定新旧协议无限期共存，或者在新协议的更新版本可用之前恢复到旧协议。如果在部署过程中发现不可预见的问题，这样的计划很有用，因此可以快速缓解此类问题。
For example, World IPv6 Day included a contingency plan that was to revert to the original state at the end of the day. After discovering no issues, some participants found that this contingency plan was unnecessary and kept the new state.
例如，世界IPv6日包括一项应急计划，即在一天结束时恢复到原始状态。在没有发现任何问题后，一些参与者发现该应急计划没有必要，并保持了新状态。
Many of the entities involved in a protocol transition may not be aware of the IETF or the RFC series, so dissemination through other channels is key for sufficiently broad communication of the transition plan. While flag days are impractical at Internet scale, coordinated "events" such as World IPv6 Launch may improve general awareness of an ongoing transition.
协议转换涉及的许多实体可能不知道IETF或RFC系列，因此通过其他渠道传播是转换计划充分广泛传播的关键。虽然卖旗日在互联网规模上是不切实际的，但协调一致的“活动”，如世界IPv6的推出，可能会提高人们对正在进行的过渡的普遍认识。
Also, there is often a need for an entity facilitating the transition through advocacy and focus. Such an entity, independent of the IETF, can be key in communicating the plan and its progress.
此外，往往需要一个实体通过宣传和重点促进过渡。这样一个独立于IETF的实体可以是传达计划及其进度的关键。
Some transitions have a risk of breaking backwards compatibility for some fraction of users. In such a case, when a transition affects competing entities facing the risk of losing customers to each other, there is an economic disincentive to transition. Thus, one role for a facilitating entity is to get competitors to transition during the same timeframe, so as to mitigate this fear. For example, the success of World IPv6 Launch was largely due to ISOC playing this role.
某些转换有可能破坏部分用户的向后兼容性。在这种情况下，当转型影响到面临相互失去客户风险的竞争实体时，经济上会抑制转型。因此，促进实体的一个作用是让竞争对手在同一时间段内转型，以缓解这种担忧。例如，IPv6在世界范围内的成功推出主要是由于ISOC发挥了这一作用。
This document discusses attributes of protocol transitions. Some types of transition can adversely affect security or privacy. For example, requiring a translator in the middle of the path may hamper end-to-end security and privacy, since it creates an attractive target. For further discussion of some of these issues, see Section 5 of [RFC7754].
本文档讨论协议转换的属性。某些类型的转换可能会对安全或隐私产生不利影响。例如，在路径中间需要一个翻译器可能会妨碍端到端的安全和隐私，因为它创建了一个吸引人的目标。关于其中一些问题的进一步讨论，请参见[RFC7754]第5节。
In addition, coexistence of two protocols in general increases risk in the sense that it doubles the attack surface. It allows exploiters to choose the weaker of two protocols when both are available, or to force use of the weaker when negotiating between the protocols by claiming not to understand the stronger one.
此外，两个协议的共存通常会增加风险，因为这会使攻击面翻倍。它允许攻击者在两个协议都可用时选择较弱的协议，或者在协议之间进行协商时通过声称不理解较强的协议来强制使用较弱的协议。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
This document summarized the set of issues that should be considered by protocol designers and deployers to facilitate transition and provides pointers to previous work (e.g., [RFC3692] and [RFC6709]) that provided detailed design guidelines. This document also covered what makes for a good transition plan and includes several case studies that provide examples. As more experience is gained over time on how to successfully apply these principles and design effective transition plans, we encourage the community to share such learnings with the IETF community and on the architecture-discuss@ietf.org mailing list so that any future document on this topic can leverage such experience.
本文档总结了协议设计人员和部署人员应考虑的一组问题，以促进过渡，并为以前提供详细设计指南的工作（例如，[RFC3692]和[RFC6709]）提供了参考。本文件还涵盖了如何制定一个好的过渡计划，并包含了几个提供示例的案例研究。随着时间的推移，在如何成功应用这些原则和设计有效的过渡计划方面获得了更多的经验，我们鼓励社区与IETF社区和架构分享这些经验-discuss@ietf.org邮件列表，以便将来有关此主题的任何文档都可以利用此类经验。
[GREASE] Benjamin, D., "Applying GREASE to TLS Extensibility", Work in Progress, draft-ietf-tls-grease-00, January 2017.
[润滑脂]Benjamin，D.，“将润滑脂应用于TLS可扩展性”，正在进行的工作，草稿-ietf-TLS-GLEE-00，2017年1月。
[HTTP0.9] Tim Berners-Lee, "The Original HTTP as defined in 1991", 1991, <https://www.w3.org/Protocols/HTTP/ AsImplemented.html>.
[HTTP0.9]Tim Berners Lee，“1991年定义的原始HTTP”，1991年<https://www.w3.org/Protocols/HTTP/ AsImplemented.html>。
[IabIpv6TransitionStatement] IAB, "Follow-up work on NAT-PT", October 2007, <https://www.iab.org/documents/correspondence-reports-documents/docs2007/follow-up-work-on-nat-pt/>.
[IABIPV6转换声明]IAB，“NAT-PT的后续工作”，2007年10月<https://www.iab.org/documents/correspondence-reports-documents/docs2007/follow-up-work-on-nat-pt/>.
[IPv6Survey2011] Botterman, M., "IPv6 Deployment Survey", 2011, <https://www.nro.net/wp-content/uploads/ ipv6_deployment_survey.pdf>.
[IPv6Survey2011]Botterman，M.，“IPv6部署调查”，2011年<https://www.nro.net/wp-content/uploads/ ipv6\u部署\u调查.pdf>。
[IPv6Survey2015] British Telecommunications, "IPv6 Industry Survey Report", August 2015, <http://www.globalservices.bt.com/static/asse ts/pdf/products/diamond_ip/IPv6-Survey-Report-2015.pdf>.
[IPv6Survey2015]英国电信，“IPv6行业调查报告”，2015年8月<http://www.globalservices.bt.com/static/asse ts/pdf/products/diamond_ip/IPv6-Survey-Report-2015.pdf>。
[PAM2015] Trammell, B., Kuehlewind, M., Boppart, D., Learmonth, I., Fairhurst, G., and R. Scheffenegger, "Enabling Internet-Wide Deployment of Explicit Congestion Notification", Proceedings of PAM 2015, DOI 10.1007/978-3-319-15509-8_15, 2015, <http://ecn.ethz.ch/ecn-pam15.pdf>.
[PAM2015]Trammell，B.，Kuehlewind，M.，Boppart，D.，Learmonth，I.，Fairhurst，G.，和R.Scheffenegger，“在互联网范围内部署明确的拥塞通知”，PAM 2015会议录，DOI 10.1007/978-3-319-15509-8，2015<http://ecn.ethz.ch/ecn-pam15.pdf>.
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883, December 1995, <http://www.rfc-editor.org/info/rfc1883>.
[RFC1883]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 1883，DOI 10.17487/RFC1883，1995年12月<http://www.rfc-editor.org/info/rfc1883>.
[RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, DOI 10.17487/RFC1933, April 1996, <http://www.rfc-editor.org/info/rfc1933>.
[RFC1933]Gilligan，R.和E.Nordmark，“IPv6主机和路由器的过渡机制”，RFC 1933，DOI 10.17487/RFC1933，1996年4月<http://www.rfc-editor.org/info/rfc1933>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 10.17487/RFC1945, May 1996, <http://www.rfc-editor.org/info/rfc1945>.
[RFC1945]Berners Lee，T.，Fielding，R.，和H.Frystyk，“超文本传输协议——HTTP/1.0”，RFC 1945，DOI 10.17487/RFC1945，1996年5月<http://www.rfc-editor.org/info/rfc1945>.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, DOI 10.17487/RFC2068, January 1997, <http://www.rfc-editor.org/info/rfc2068>.
[RFC2068]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，DOI 10.17487/RFC2068，1997年1月<http://www.rfc-editor.org/info/rfc2068>.
[RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Frystyk, "Use and Interpretation of HTTP Version Numbers", RFC 2145, DOI 10.17487/RFC2145, May 1997, <http://www.rfc-editor.org/info/rfc2145>.
[RFC2145]Mogul，J.，Fielding，R.，Gettys，J.，和H.Frystyk，“HTTP版本号的使用和解释”，RFC 2145，DOI 10.17487/RFC2145，1997年5月<http://www.rfc-editor.org/info/rfc2145>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <http://www.rfc-editor.org/info/rfc3168>.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，DOI 10.17487/RFC3168，2001年9月<http://www.rfc-editor.org/info/rfc3168>.
[RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, DOI 10.17487/RFC3424, November 2002, <http://www.rfc-editor.org/info/rfc3424>.
[RFC3424]Daigle，L.，Ed.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 3424DOI 10.17487/RFC3424，2002年11月<http://www.rfc-editor.org/info/rfc3424>.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, <http://www.rfc-editor.org/info/rfc3692>.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，DOI 10.17487/RFC3692，2004年1月<http://www.rfc-editor.org/info/rfc3692>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006, <http://www.rfc-editor.org/info/rfc4380>.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 4380，DOI 10.17487/RFC4380，2006年2月<http://www.rfc-editor.org/info/rfc4380>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <http://www.rfc-editor.org/info/rfc4632>.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，DOI 10.17487/RFC4632，2006年8月<http://www.rfc-editor.org/info/rfc4632>.
[RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, DOI 10.17487/RFC4690, September 2006, <http://www.rfc-editor.org/info/rfc4690>.
[RFC4690]Klensin，J.，Faltstrom，P.，Karp，C.，和IAB，“国际化域名（IDN）的审查和建议”，RFC 4690，DOI 10.17487/RFC4690，2006年9月<http://www.rfc-editor.org/info/rfc4690>.
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, DOI 10.17487/RFC5211, July 2008, <http://www.rfc-editor.org/info/rfc5211>.
[RFC5211]Curran，J.，“互联网转型计划”，RFC 5211DOI 10.17487/RFC5211，2008年7月<http://www.rfc-editor.org/info/rfc5211>.
[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, <http://www.rfc-editor.org/info/rfc5218>.
[RFC5218]Thaler，D.和B.Aboba，“什么是成功的方案？”RFC 5218，DOI 10.17487/RFC5218，2008年7月<http://www.rfc-editor.org/info/rfc5218>.
[RFC5894] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, <http://www.rfc-editor.org/info/rfc5894>.
[RFC5894]Klensin，J.，“应用程序的国际化域名（IDNA）：背景、解释和理由”，RFC 5894，DOI 10.17487/RFC5894，2010年8月<http://www.rfc-editor.org/info/rfc5894>.
[RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008", RFC 5895, DOI 10.17487/RFC5895, September 2010, <http://www.rfc-editor.org/info/rfc5895>.
[RFC5895]Resnick，P.和P.Hoffman，“应用程序中国际化域名的映射字符（IDNA）2008”，RFC 5895，DOI 10.17487/RFC5895，2010年9月<http://www.rfc-editor.org/info/rfc5895>.
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, DOI 10.17487/RFC6055, February 2011, <http://www.rfc-editor.org/info/rfc6055>.
[RFC6055]Thaler，D.，Klensin，J.，和S.Cheshire，“IAB对国际化域名编码的思考”，RFC 6055，DOI 10.17487/RFC6055，2011年2月<http://www.rfc-editor.org/info/rfc6055>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <http://www.rfc-editor.org/info/rfc6269>.
[RFC6269]福特，M.，Ed.，Boucadair，M.，Durand，A.，Levis，P.，和P.Roberts，“IP地址共享问题”，RFC 6269，DOI 10.17487/RFC62692011年6月<http://www.rfc-editor.org/info/rfc6269>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <http://www.rfc-editor.org/info/rfc6455>.
[RFC6455]Fette，I.和A.Melnikov，“WebSocket协议”，RFC 6455，DOI 10.17487/RFC6455，2011年12月<http://www.rfc-editor.org/info/rfc6455>.
[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, September 2012, <http://www.rfc-editor.org/info/rfc6709>.
[RFC6709]Carpenter，B.，Aboba，B.，Ed.，和S.Cheshire，“协议扩展的设计考虑”，RFC 6709，DOI 10.17487/RFC6709，2012年9月<http://www.rfc-editor.org/info/rfc6709>.
[RFC7021] Donley, C., Ed., Howard, L., Kuarsingh, V., Berg, J., and J. Doshi, "Assessing the Impact of Carrier-Grade NAT on Network Applications", RFC 7021, DOI 10.17487/RFC7021, September 2013, <http://www.rfc-editor.org/info/rfc7021>.
[RFC7021]Donley，C.，Ed.，Howard，L.，Kuarsingh，V.，Berg，J.，和J.Doshi，“评估运营商级NAT对网络应用的影响”，RFC 7021，DOI 10.17487/RFC70212013年9月<http://www.rfc-editor.org/info/rfc7021>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228]Bormann，C.，Ersue，M.和A.Keranen，“受限节点网络的术语”，RFC 7228，DOI 10.17487/RFC7228，2014年5月<http://www.rfc-editor.org/info/rfc7228>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <http://www.rfc-editor.org/info/rfc7301>.
[RFC7301]Friedl，S.，Popov，A.，Langley，A.，和E.Stephan，“传输层安全（TLS）应用层协议协商扩展”，RFC 7301，DOI 10.17487/RFC7301，2014年7月<http://www.rfc-editor.org/info/rfc7301>.
[RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)", RFC 7305, DOI 10.17487/RFC7305, July 2014, <http://www.rfc-editor.org/info/rfc7305>.
[RFC7305]李尔，E.，编辑，“IAB互联网技术采用和转型研讨会（ITAT）的报告”，RFC 7305，DOI 10.17487/RFC7305，2014年7月<http://www.rfc-editor.org/info/rfc7305>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.
[RFC7540]Belshe，M.，Paon，R.，和M.Thomson，编辑，“超文本传输协议版本2（HTTP/2）”，RFC 7540，DOI 10.17487/RFC7540，2015年5月<http://www.rfc-editor.org/info/rfc7540>.
[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, <http://www.rfc-editor.org/info/rfc7541>.
[RFC7541]Paun，R.和H.Ruellan，“HPACK：HTTP/2的报头压缩”，RFC 7541，DOI 10.17487/RFC7541，2015年5月<http://www.rfc-editor.org/info/rfc7541>.
[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. Nordmark, "Technical Considerations for Internet Service Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, March 2016, <http://www.rfc-editor.org/info/rfc7754>.
[RFC7754]Barnes，R.，Cooper，A.，Kolkman，O.，Thaler，D.，和E.Nordmark，“互联网服务阻塞和过滤的技术考虑”，RFC 7754，DOI 10.17487/RFC7754，2016年3月<http://www.rfc-editor.org/info/rfc7754>.
[TR46] The Unicode Consortium, "Unicode IDNA Compatibility Processing", Version 9.0.0, June 2016, <http://www.unicode.org/reports/tr46/>.
[TR46]Unicode联盟，“Unicode IDNA兼容性处理”，9.0.0版，2016年6月<http://www.unicode.org/reports/tr46/>.
[TSV2007] Sridharan, M., Bansal, D., and D. Thaler, "Implementation Report on Experiences with Various TCP RFCs", Proceedings of IETF 68, March 2007, <http://www.ietf.org/proceedings/ 68/slides/tsvarea-3/sld1.htm>.
[TSV2007]Sridharan，M.，Bansal，D.，和D.Thaler，“关于各种TCP RFC经验的实施报告”，IETF 68会议记录，2007年3月<http://www.ietf.org/proceedings/ 68/slides/tsvarea-3/sld1.htm>。
Appendix A of [RFC5218] describes a number of case studies that are relevant to this document and highlight various transition problems and strategies (see, for instance, the Inter-Domain Multicast case study in Appendix A.4 of [RFC5218]). We now include several additional case studies that focus on transition problems and strategies. Many other equally good case studies could have been included, but, in the interests of brevity, only a sampling is included here that is sufficient to justify the conclusions in the body of this document.
[RFC5218]的附录A描述了许多与本文件相关的案例研究，并强调了各种过渡问题和策略（例如，参见[RFC5218]附录A.4中的域间多播案例研究）。现在，我们将包括几个其他案例研究，这些案例研究侧重于过渡问题和战略。许多其他同样好的案例研究本可以包括在内，但为了简洁起见，这里只包括足以证明本文件正文中结论的抽样。
Explicit Congestion Notification (ECN) is a mechanism to replace loss as the only signal for the detection of congestion. It does this with an explicit signal first sent from a router to a recipient of a packet, which is then reflected back to the sender. It was standardized in 2001 in [RFC3168], and the mechanism consists of two parts: congestion detection in the IP layer, reusing two bits of the old IP Type of Service (TOS) field, and congestion feedback in the transport layer. Feedback in TCP uses two TCP flags, ECN Echo and Congestion Window Reduced. Together with a suitably configured active queue management (AQM), ECN can improve TCP performance on congested links.
显式拥塞通知（ECN）是一种替代丢失作为拥塞检测唯一信号的机制。它通过一个明确的信号来实现这一点，该信号首先从路由器发送到数据包的接收者，然后反射回发送者。该机制于2001年在[RFC3168]中进行了标准化，该机制由两部分组成：IP层中的拥塞检测、重用旧IP服务类型（TOS）字段的两位以及传输层中的拥塞反馈。TCP中的反馈使用两个TCP标志，ECN Echo和拥塞窗口缩减。与适当配置的主动队列管理（AQM）一起，ECN可以提高拥塞链路上的TCP性能。
The deployment of ECN is a case study in failed transition followed by possible redemption. Initial deployment of ECN in the early and mid 2000s led to severe problems with some network equipment, including home router crashes and reboots when packets with ECN IP or TCP flags were received [TSV2007]. This led to firewalls stripping ECN IP and TCP flags, or even dropping packets with these flags set. This stalled deployment. The need for both endpoints (to negotiate and support ECN) and on-path devices (to mark traffic when congestion occurs) to cooperate in order to see any benefits from ECN deployment was a further issue. The deployment of ECN across the Internet had failed.
ECN的部署是一个失败的过渡以及可能的赎回的案例研究。在2000年代早期和中期首次部署ECN导致一些网络设备出现严重问题，包括当接收到带有ECN IP或TCP标志的数据包时家庭路由器崩溃和重新启动[TSV2007]。这导致防火墙剥离ECN IP和TCP标志，甚至丢弃设置了这些标志的数据包。这使部署陷入僵局。需要两个端点（协商并支持ECN）和路径设备（在发生拥塞时标记流量）进行合作，以便从ECN部署中看到任何好处，这是一个进一步的问题。在Internet上部署ECN失败。
In the late 2000s, Linux and Windows servers began defaulting to "passive ECN support", meaning they would negotiate ECN if asked by the client but would not ask to negotiate ECN by default. This decision was regarded as without risk: only if a client was explicitly configured to negotiate ECN would any possible connectivity problems surface. Gradually, this has increased server support in the Internet from near zero in 2008, to 11% of the top million Alexa webservers in 2011, to 30% in 2012, and to 65% in late 2014. In the meantime, the risk to connectivity of ECN negotiation has reduced dramatically [PAM2015], leading to ongoing work to make
在21世纪末，Linux和Windows服务器开始默认为“被动ECN支持”，这意味着如果客户端要求，它们将协商ECN，但默认情况下不会要求协商ECN。这个决定被认为是没有风险的：只有当客户端被明确配置为协商ECN时，任何可能的连接问题才会出现。逐渐地，这增加了互联网上的服务器支持，从2008年的接近零，到2011年Alexa Web服务器总数的11%，到2012年的30%，到2014年底的65%。同时，ECN协商的连通性风险已大幅降低[PAM2015]，导致正在进行的工作需要进一步改进
Windows, Apple iOS, OSX, and Linux clients negotiate ECN by default. It is hoped that a critical mass of clients and servers negotiating ECN will provide an incentive to mark congestion on ECN-enabled traffic, thus breaking the logjam.
默认情况下，Windows、Apple iOS、OSX和Linux客户端协商ECN。希望通过协商ECN的大量客户机和服务器将提供一种激励，在启用ECN的流量上标记拥塞，从而打破僵局。
The deployment of Internationalized Domain Names (IDNs) has a long and complicated history. This should not be surprising, since internationalization deals with language and cultural issues regarding differing expectations of users around the world, thus making it inherently difficult to agree on common rules.
国际化域名（IDN）的部署有着漫长而复杂的历史。这并不奇怪，因为国际化处理的是与世界各地用户不同期望有关的语言和文化问题，因此在本质上难以就共同规则达成一致。
Furthermore, because human languages evolve and change over time, even if common rules can be established, there is likely to be a need to review and update them regularly.
此外，由于人类语言随着时间的推移而演变和变化，即使可以建立共同的规则，也可能需要定期审查和更新这些规则。
There have been multiple technical transitions related to IDNs, including the introduction of non-ASCII in DNS, the transition to each new version of Unicode, and the transition from IDNA 2003 to IDNA 2008. A brief history of the introduction of non-ASCII in DNS and the various complications that arose therein, can be found in Section 3 of [RFC6055]. While IDNA 2003 was limited to Unicode version 3.2 only, one of the IDNA 2008 changes was to decouple its rules from any particular version of Unicode (see [RFC5894], especially Section 1.4, for more discussion of this point, and see [RFC4690] for a list of other issues with IDNA 2003 that motivated IDNA 2008). However, the transition from IDNA 2003 to IDNA 2008 itself presented a problem since IDNA 2008 did not preserve backwards compatibility with IDNA 2003 for a couple of codepoints. Investigations and discussions with affected parties led to the IETF ultimately choosing IDNA 2008 because the overall gain by moving to IDNA 2008 to fix the problems with IDNA 2003 was seen to be much greater than the problems due to the few incompatibilities at the time of the change, as not many IDNs were in use and even fewer that might see incompatibilities.
与IDN相关的技术转换有多个，包括在DNS中引入非ASCII，转换到每个新版本的Unicode，以及从IDNA 2003转换到IDNA 2008。[RFC6055]第3节简要介绍了DNS中引入非ASCII码的历史以及由此产生的各种复杂情况。虽然IDNA 2003仅限于Unicode版本3.2，但IDNA 2008的一个变化是将其规则与任何特定的Unicode版本分离（有关这一点的更多讨论，请参阅[RFC5894]，特别是第1.4节，并参阅[RFC4690]以了解IDNA 2003引发IDNA 2008的其他问题列表）。然而，从IDNA 2003到IDNA 2008的过渡本身就带来了一个问题，因为IDNA 2008没有为几个代码点保留与IDNA 2003的向后兼容性。通过与受影响方的调查和讨论，IETF最终选择了IDNA 2008，因为通过转移到IDNA 2008解决IDNA 2003的问题，总体收益被视为远远大于因变更时少数不兼容而产生的问题，由于使用的IDN不多，甚至更少，因此可能会出现不兼容。
A couple of browser vendors in particular were concerned about the differences between IDNA 2003 and IDNA 2008, and the fact that if a browser stopped being able to get to some site, or unknowingly sent a user to a different (e.g., phishing) site instead, the browser would be blamed. As such, any user-perceivable change from IDNA 2003 behavior would be painful to the vendor to deal with; hence, they could not depend on solutions that would need action by other entities.
一些浏览器供应商特别关注IDNA 2003和IDNA 2008之间的差异，如果浏览器无法访问某个站点，或者在不知情的情况下将用户发送到另一个（如钓鱼）站点，那么浏览器将受到指责。因此，用户从IDNA 2003行为中感知到的任何变化都会让供应商感到痛苦；因此，它们不能依赖需要其他实体采取行动的解决办法。
Thus, to deal with issues like such incompatibilities, some applications and client-side frameworks wanted to map one string into another (namely, a string that would give the same result as when IDNA 2003 was used) before invoking DNS.
因此，为了处理此类不兼容问题，一些应用程序和客户端框架希望在调用DNS之前将一个字符串映射到另一个字符串（即，一个与使用IDNA 2003时产生相同结果的字符串）。
To provide such mapping (and some other functionality), the Unicode Consortium published [TR46], which continued down the path of IDNA 2003 with a code point by code point selection mechanism. This was implemented by some, but never adopted by the IETF.
为了提供这样的映射（以及一些其他功能），Unicode联盟发布了[TR46]，它通过一种逐码点选择机制沿着IDNA 2003的道路继续前进。这是由一些人实现的，但IETF从未采用过。
Meanwhile, the IETF did not publish any mapping mechanism, but [RFC5895] was published on the Independent Submission stream. In discussions around mapping, one of the key topics was about how long the transition should last. At one end of the duration spectrum is a flag day where some entities would be broken initially but the change would happen before IDN usage became even more ubiquitous. At the other end of the spectrum is the need to maintain mappings indefinitely. Local incentives at each entity who needed to change, however, meant that a short timeframe was impractical.
同时，IETF没有发布任何映射机制，但[RFC5895]发布在独立提交流上。在围绕映射的讨论中，一个关键主题是过渡应该持续多长时间。在持续时间范围的一端是卖旗日，在这一天，一些实体最初会被打破，但这种变化会在IDN使用变得更加普遍之前发生。另一方面，需要无限期地维护映射。然而，每个需要改变的实体的地方激励意味着短期内是不现实的。
There are many affected types of entities with very different incentives. For example, the incentives affecting browser vendors, registries, domain name marketers and applicants, app developers, and protocol designers are each quite different, and the various solutions require changes by multiple types of entities, where the benefits do not always align with the costs. If there is some group (or even an individual) that is opposed to a change/transition and able to put significant resources behind their opposition, transitions get a lot harder.
有许多受影响的实体类型具有非常不同的激励。例如，影响浏览器供应商、注册中心、域名营销者和申请人、应用程序开发人员和协议设计者的激励措施各不相同，各种解决方案需要多种类型的实体进行更改，其好处并不总是与成本一致。如果有某个群体（甚至个人）反对变革/转型，并且能够在反对背后投入大量资源，转型就会变得更加困难。
Finally, there are multiple naming contexts, and the protocol behavior (including how internationalized domain names are handled) within each naming context can be different. Hence, applications and frameworks often encounter a variety of behaviors and may or may not be designed to deal with them. See Sections 2 and 3 of [RFC6055] for more discussion.
最后，有多个命名上下文，每个命名上下文中的协议行为（包括如何处理国际化域名）可能不同。因此，应用程序和框架经常会遇到各种各样的行为，设计时可能会也可能不会处理这些行为。更多讨论见[RFC6055]第2节和第3节。
In summary, all this diversity can cause problems for each affected entity, especially if a competitor does not have such a problem, e.g., for browser vendors if competing browsers do not have the same problems, or for an email server provider if competing server providers do not have the same problems.
总之，所有这些多样性都会给每个受影响的实体带来问题，特别是如果竞争对手没有这样的问题，例如，如果竞争对手的浏览器没有相同的问题，则会给浏览器供应商带来问题；如果竞争对手的服务器提供商没有相同的问题，则会给电子邮件服务器提供商带来问题。
Twenty-one years after publication of [RFC1883], the transition to IPv6 is still in progress. The first document to describe a transition plan ([RFC1933]) was published less than a year after the protocol itself. It recommended coexistence (dual-stack or tunneling technology) with the expectation that over time, all hosts would have IPv6, and IPv4 could be quietly retired.
[RFC1883]发布21年后，向IPv6的过渡仍在进行中。第一份描述过渡计划的文件（[RFC1933]）在协议本身发布后不到一年就发布了。它建议共存（双栈或隧道技术），并期望随着时间的推移，所有主机都将拥有IPv6，IPv4可以悄悄地退役。
In the early stages, deployment was limited to peer-to-peer uses tunneled over IPv4 networks. For example, Teredo [RFC4380] aligned the cost of fixing the problem with the benefit and allowed for incremental benefits to those who used it.
在早期阶段，部署仅限于通过IPv4网络进行的对等使用。例如，Teredo[RFC4380]将解决问题的成本与收益挂钩，并允许使用它的人获得增量收益。
Operating system vendors had incentives because with such tunneling protocols, they could get peer-to-peer apps working without depending on any infrastructure changes. That resulted in the main apps using IPv6 being in the peer-to-peer category (BitTorrent, Xbox gaming, etc.).
操作系统供应商有激励措施，因为有了这样的隧道协议，他们可以让点对点应用程序工作，而不依赖于任何基础设施的变化。这导致使用IPv6的主要应用属于点对点类别（BitTorrent、Xbox游戏等）。
Router vendors had some incentive because IPv6 could be used within an intra-domain network more efficiently than tunneling, once the OS vendors already had IPv6 support and some special-purpose apps existed.
路由器供应商有一些动机，因为一旦操作系统供应商已经有了IPv6支持和一些特殊用途的应用程序，IPv6可以比隧道更有效地在域内网络中使用。
For content providers and ISPs, on the other hand, there was little incentive for deployment: there was no incremental benefit to deploying locally. Since everyone already had IPv4, there was no network effect benefit to deploying IPv6. Even as proponents argued that workarounds to extend the life of IPv4 -- such as Classless Inter-Domain Routing (CIDR) [RFC4632] , NAT, and stingy allocations -- made it more complex, IPv4 continued to work well enough for most applications.
另一方面，对于内容提供商和ISP来说，部署的动机很小：在本地部署不会带来增量好处。因为每个人都已经有了IPv4，部署IPv6对网络没有任何好处。尽管支持者认为延长IPv4使用寿命的变通方法——如无类域间路由（CIDR）[RFC4632]、NAT和吝啬分配——使其变得更加复杂，但IPv4对于大多数应用程序来说仍然工作得很好。
Workarounds to NAT problems documented in [RFC6269] and [RFC7021] included Interactive Connectivity Establishment (ICE), Session Traversal Utilities for NAT (STUN), and Traversal Using Relays around NAT (TURN), technologies that allowed those experiencing the problems to deploy technologies to resolve them. As with end-to-end IPv6 tunneling (e.g., Teredo), the incentives there aligned the cost of fixing the problem with the benefit and allowed for incremental benefits to those who used them. The IAB discussed NAT technology proposals [RFC3424] and recommended that they be considered short-term fixes and said that proposals must include an exit plan, such that they would decline over time. In particular, the IAB warned against generalizing NAT solutions, which would lead to greater
[RFC6269]和[RFC7021]中记录的NAT问题的解决方法包括交互式连接建立（ICE）、NAT会话遍历实用程序（STUN）和使用NAT周围的中继进行遍历（TURN），这些技术允许遇到问题的人部署技术来解决问题。与端到端IPv6隧道（例如Teredo）一样，那里的激励措施将解决问题的成本与收益相一致，并允许使用这些问题的人获得增量收益。IAB讨论了NAT技术提案[RFC3424]，并建议将其视为短期修复方案，并表示提案必须包括退出计划，以便随着时间的推移而下降。特别是，IAB警告不要推广NAT解决方案，这将导致更大的风险
dependence on them. In some ways, these solutions, along with other IPv4 development (e.g., the workarounds above, and retrofitting IPsec into IPv4) continued to reduce the incentive to deploy IPv6.
对他们的依赖。在某些方面，这些解决方案以及其他IPv4开发（例如，上述解决方法，以及将IPsec改装为IPv4）继续降低部署IPv6的动机。
Some early advocates overstated the benefits of IPv6, suggesting that it had better security (because IPsec was required) or that NAT was worse than it often appeared to be or that IPv4 exhaustion would happen years sooner than it actually did. Some people pushed back on these exaggerations, and decided that the protocol itself somehow lacked credibility.
一些早期的倡导者夸大了IPv6的好处，认为它具有更好的安全性（因为需要IPsec），或者NAT比通常看起来更糟糕，或者IPv4耗尽的时间比实际情况早几年。一些人反驳了这些夸张的说法，认为议定书本身缺乏可信度。
Not until a few years after IPv4 addresses were exhausted in various RIR regions did IPv6 deployment significantly increase. The RIRs had been advocating in their communities for IPv6 for some time, reducing fees for IPv6, and in some cases providing training; there is little to suggest that these had a significant effect. The RIRs and others conducted surveys of different industries and industry segments to learn why people did not deploy IPv6 [IPv6Survey2011] [IPv6Survey2015], which commonly listed lack of a business case, lack of training, and lack of vendor support as primary hurdles.
直到IPv4地址在各个RIR区域耗尽后的几年，IPv6部署才显著增加。RIR在其社区倡导IPv6已有一段时间，降低了IPv6的费用，并在某些情况下提供了培训；几乎没有证据表明这些措施有显著效果。RIR和其他人对不同行业和行业细分进行了调查，以了解为什么人们没有部署IPv6[IPv6Survey2011][IPv6Survey2015]，这通常将缺乏商业案例、缺乏培训和缺乏供应商支持列为主要障碍。
Arguably forward-looking companies collaborated, with ISOC, on World IPv6 Day and World IPv6 Launch to jump-start global IPv6 deployment. By including multiple competitors, World IPv6 Day reduced the risk that any of them would lose customers if a user's IPv6 implementation was broken. World IPv6 Launch then set a goal for content providers to permanently enable IPv6, and for large ISPs to enable IPv6 for at least 1% of end users. These large, visible deployments gave vendors specific features and target dates to support IPv6 well. Key aspects of World IPv6 Day and World IPv6 Launch that contributed to their successes (measured as increased deployment of IPv6) were the communication through ISOC, and that measurement metrics and contingency plans were announced in advance.
可以说，具有前瞻性的公司在世界IPv6日和世界IPv6发布日与ISOC合作，以启动全球IPv6部署。通过将多个竞争对手包括在内，世界IPv6日降低了如果用户的IPv6实施被破坏，其中任何一家都会失去客户的风险。然后，World IPv6 Launch为内容提供商设定了永久启用IPv6的目标，并为大型ISP设定了至少1%的最终用户启用IPv6的目标。这些大型、可见的部署为供应商提供了特定的功能和目标日期，以更好地支持IPv6。世界IPv6日和世界IPv6发布的关键方面（衡量为IPv6部署的增加）是通过ISOC进行的通信，并且提前宣布了度量指标和应急计划，这两个方面为其成功做出了贡献。
Several efforts have been made to mitigate the lack of a business case. Some governments (South Korea and Japan) provided tax incentives to include IPv6. Other governments (Belgium and Singapore) mandated IPv6 support by private companies. Few of these had enough value to drive significant IPv6 deployment.
已经做出了一些努力来缓解业务案例的缺乏。一些政府（韩国和日本）提供了税收优惠，以纳入IPv6。其他政府（比利时和新加坡）要求私营公司提供IPv6支持。其中很少有足够的价值来推动重大的IPv6部署。
The concern about lack of training is often a common issue in transitions. Because IPv4 is so ubiquitous, its use is routine and simplified with common tools, and it is taught in network training everywhere. While IPv6 deployment was low, ignorance of it was no obstacle to being hired as a network administrator or developer.
对缺乏培训的担忧通常是过渡中的一个常见问题。因为IPv4是如此普遍，它的使用是常规的，并通过常用工具简化，而且在各地的网络培训中都会教授它。虽然IPv6部署率很低，但对它的无知并不会成为被聘用为网络管理员或开发人员的障碍。
Organizations with the greatest incentives to deploy IPv6 are those that continue to grow quickly, even after IPv4 free-pool exhaustion. Thus, ISPs have had varying levels of commitment, based on the growth of their user base, services being added (especially video over IP), and the number of IPv4 addresses they had available. Cloud-based providers, including Content Delivery Network (CDN) and hosting companies, have been major buyers of IPv4 addresses, and several have been strong deployers and advocates of IPv6.
部署IPv6的最大动机是那些继续快速增长的组织，即使在IPv4免费池耗尽之后也是如此。因此，ISP根据其用户群的增长、增加的服务（特别是IP视频）以及可用的IPv4地址数量，做出了不同程度的承诺。基于云的提供商，包括内容交付网络（CDN）和托管公司，一直是IPv4地址的主要买家，其中一些是IPv6的有力部署者和倡导者。
Different organizations will use different transition models for their networks, based on their needs. Some are electing to use IPv6-only hosts in the network with IPv6-IPv4 translation at the edge. Others are using dual-stack hosts with IPv6-only routers in the core of the network, and IPv4 tunneled or translated through them to dual-stack edge routers. Still others are using native dual-stack throughout the network, but that generally persists as an interim measure: adoption of two technologies is not the same as transitioning from one technology to another. Finally, some walled gardens or isolated networks, such as management networks, use IPv6-only end-to-end.
不同的组织将根据其需求为其网络使用不同的过渡模型。一些用户选择在网络边缘使用IPv6-IPv4转换的仅IPv6主机。另一些则使用双栈主机，在网络核心中使用仅限IPv6的路由器，IPv4通过隧道或转换为双栈边缘路由器。还有一些人在整个网络中使用本机双堆栈，但这通常是一种临时措施：采用两种技术并不等同于从一种技术过渡到另一种技术。最后，一些有围墙的花园或隔离的网络（如管理网络）仅使用IPv6端到端。
It is impossible to predict with certainty the path IPv6 deployment will have taken when it is complete. Lessons learned so far include aligning costs and benefits (incentive), and ensuring incremental benefit (network effect or backward compatibility).
无法肯定地预测IPv6部署完成后将采取的路径。迄今为止的经验教训包括调整成本和收益（激励），确保增量收益（网络效应或向后兼容性）。
HTTP has been through several transitions as a protocol.
HTTP作为一种协议已经经历了多次转换。
The first version [HTTP0.9] was extremely simple, with no headers, status codes, or explicit versioning. HTTP/1.0 [RFC1945] introduced these and a number of other concepts; it succeeded mostly because deployment of HTTP was still relatively new, with a small pool of implementers and (comparatively) small set of deployments and users.
第一个版本[HTTP0.9]非常简单，没有标题、状态代码或显式版本控制。HTTP/1.0[RFC1945]引入了这些和一些其他概念；它之所以成功，主要是因为HTTP的部署仍然相对较新，实现者人数较少，部署和用户（相对）较少。
HTTP/1.1 [RFC7230] (first defined in [RFC2068]) was an attempt to make the protocol suitable for the massive scale it was being deployed upon and to introduce some new features.
HTTP/1.1[RFC7230]（首先在[RFC2068]中定义）是一种尝试，旨在使该协议适合其所部署的大规模应用，并引入一些新特性。
HTTP/2 [RFC7540] was largely aimed at improving performance. The primary improvement was the introduction of request multiplexing, which is supported by request prioritization and flow control. It also introduced header compression [RFC7541] and binary framing; this made it completely backwards incompatible on the wire, but still semantically compatible with previous versions of the protocol.
HTTP/2[RFC7540]主要是为了提高性能。主要的改进是引入了请求多路复用，这是由请求优先级和流控制支持的。它还引入了报头压缩[RFC7541]和二进制帧；这使得它在线路上完全向后不兼容，但在语义上仍然与以前版本的协议兼容。
During the development of HTTP/1.1, there was a fair amount of confusion regarding the semantics of HTTP version numbers, resulting in [RFC2145]. Later, it was felt that minor versioning in the protocol caused more confusion than it was worth, so HTTP/2.0 became HTTP/2.
在HTTP/1.1的开发过程中，关于HTTP版本号的语义有相当多的混淆，导致[RFC2145]。后来，人们觉得协议中的小版本控制造成了更多的混乱，因此HTTP/2.0变成了HTTP/2。
This decision was informed by the observation that many implementations ignored the major version number of the protocol or misinterpreted it. As is the case with many protocol extension points, HTTP versioning had failed to be "greased" by use often enough, and so had become "rusted" so that only a limited range of values could interoperate.
这一决定是通过观察到许多实现忽略了协议的主要版本号或错误地解释了它而做出的。与许多协议扩展点的情况一样，HTTP版本控制未能通过足够频繁的使用来“润滑”，因此变得“生锈”，只有有限范围的值可以互操作。
This phenomenon has been observed in other protocols, such as TLS (as exemplified by [GREASE]), and there are active efforts to identify extension points that are in need of such "grease" and making it appear as if they are in use.
在其他协议中也观察到了这种现象，例如TLS（以[Libe]为例），并且正在积极努力确定需要这种“Libe”的扩展点，并使其看起来好像正在使用。
Besides the protocol version, HTTP's extension points that are well-greased include header fields, status codes, media types, and cache-control extensions; HTTP methods, content-encodings, and chunk-extensions enjoy less flexibility, and need to be extended more cautiously.
除了协议版本外，HTTP的扩展点还包括头字段、状态代码、媒体类型和缓存控制扩展；HTTP方法、内容编码和块扩展的灵活性较低，需要更加谨慎地进行扩展。
Each update to the "major" version of HTTP has been accompanied by changes that weren't compatible with previous versions. This was not uniformly successful given the diversity and scale of deployment and implementations.
对HTTP“主要”版本的每次更新都伴随着与以前版本不兼容的更改。考虑到部署和实现的多样性和规模，这并不是一致成功的。
HTTP/1.1 introduced pipelining to improve protocol efficiency. Although it did enjoy implementation, interoperability did not follow.
HTTP/1.1引入了流水线以提高协议效率。尽管它确实享受到了实现，但互操作性并没有随之实现。
This was partially because many existing implementations had chosen architectures that did not lend themselves to supporting it; pipelining was not uniformly implemented and where it was, support was sometimes incorrect or incomplete. Since support for pipelining was indicated by the protocol version number itself, interop was difficult to achieve, and furthermore its inability to completely address head-of-line blocking issues made pipelining unattractive.
这部分是因为许多现有的实现选择了不适合支持它的架构；流水线并没有得到统一的实施，在这种情况下，支持有时是不正确的或不完整的。由于对流水线的支持是由协议版本号本身表示的，因此很难实现互操作，而且它无法完全解决行首阻塞问题，这使得流水线没有吸引力。
Likewise, HTTP/1.1's Expect/Continue mechanism relied on wide support for the new semantics it introduced and did not have an adequate fallback strategy for previous versions of the protocol. As a
类似地，HTTP/1.1的Expect/Continue机制依赖于对其引入的新语义的广泛支持，并且对于协议的早期版本没有足够的回退策略。作为一个
result, interoperability and deployment suffered and is still considered a "problem area" for the protocol.
结果，互操作性和部署受到影响，仍然被认为是协议的“问题领域”。
More recently, the HTTP working group decided that HTTP/2 represented an opportunity to improve security, making the protocol much stricter than previous versions about the use of TLS. To this end, a long list of TLS cipher suites were prohibited, constraints were placed on the key exchange method, and renegotiation was prohibited.
最近，HTTP工作组决定HTTP/2代表了一个提高安全性的机会，使得该协议在TLS的使用方面比以前的版本更加严格。为此，禁止了一长串TLS密码套件，对密钥交换方法进行了限制，并禁止了重新协商。
This did cause deployment problems. Though most were minor and transitory, disabling renegotiation caused problems for deployments that relied on the feature to authenticate clients and prompted new work to replace the feature.
这确实会导致部署问题。尽管大多数都是次要的和暂时的，但禁用重新协商会给依赖该功能对客户端进行身份验证的部署带来问题，并促使新的工作来替换该功能。
A number of other features or characteristics of HTTP were identified as potentially undesirable as part of the HTTP/2 process and considered for removal. This included trailers, the 1xx series of responses, certain modes of request forms, and the unsecured (http://) variant of the protocol.
作为HTTP/2过程的一部分，HTTP的许多其他特性或特征被确定为可能不受欢迎的，并被考虑删除。这包括预告片、1xx系列响应、请求表单的某些模式以及协议的不安全（http://）变体。
For each of these, the risk to the successful deployment of the new version was considered to be too great to justify removing the feature. However, deployment of the unsecured variant of HTTP/2 remains extremely limited.
对于其中的每一项，成功部署新版本的风险都被认为太大，不值得删除该功能。然而，HTTP/2的不安全变体的部署仍然非常有限。
HTTP/1.1 provided the Upgrade header field to enable transitioning a connection to an entirely different protocol. So far, this has been little-used, other than to enable the use of WebSockets [RFC6455].
HTTP/1.1提供了Upgrade header字段，以允许将连接转换为完全不同的协议。到目前为止，除了支持WebSocket的使用[RFC6455]之外，很少使用它。
With performance being a primary motivation for HTTP/2, a new mechanism was needed to avoid spending an additional round trip on protocol negotiation. A new mechanism was added to TLS to permit the negotiation of the new version of HTTP: Application-Layer Protocol Negotiation (ALPN) [RFC7301]. Upgrade was used only for the unsecured variant of the protocol.
由于性能是HTTP/2的主要动机，因此需要一种新的机制来避免在协议协商上花费额外的往返时间。TLS中添加了一种新机制，以允许协商新版本的HTTP：应用层协议协商（ALPN）[RFC7301]。升级仅用于协议的不安全变体。
ALPN was identified as the primary way in which future protocol versions would be negotiated. The mechanism was well-tested during development of the specification, proving that new versions could be deployed safely and easily. Several draft versions of the protocol were successfully deployed during development, and version negotiation was never shown to be an issue.
ALPN被确定为未来协议版本谈判的主要方式。该机制在规范的开发过程中得到了很好的测试，证明新版本可以安全轻松地部署。在开发过程中，成功地部署了协议的几个草案版本，版本协商从未成为问题。
Confidence that new versions would be easy to deploy if necessary lead to a particular design stance that might be considered unusual in light of the advice in [RFC5218], though is completely consistent
新版本在必要时易于部署的信心导致了一种特殊的设计立场，根据[RFC5218]中的建议，这种立场可能被认为是不寻常的，尽管这是完全一致的
with [RFC6709]: few extension points were added, unless an immediate need was understood.
对于[RFC6709]：除非理解了当前的需求，否则很少添加扩展点。
This decision was made on the basis that it would be easier to revise the entire protocol than it would be to ensure that an extension point was correctly specified and implemented such that it would be available when needed.
作出这一决定的依据是，修订整个议定书比确保正确指定和实施扩展点更容易，以便在需要时提供扩展点。
IAB Members at the Time of Approval
批准时的IAB成员
Jari Arkko Ralph Droms Ted Hardie Joe Hildebrand Russ Housley Lee Howard Erik Nordmark Robert Sparks Andrew Sullivan Dave Thaler Martin Thomson Brian Trammell Suzanne Woolf
贾里·阿克科·拉尔夫·德罗姆斯·泰德·哈迪·乔·希尔德布兰德·罗斯·霍斯利·李·霍华德·埃里克·诺德马克·罗伯特·斯帕克斯·安德鲁·沙利文·戴夫·泰勒·马丁·汤姆森·布莱恩·特拉梅尔·苏珊娜·伍尔夫
Acknowledgements
致谢
This document is a product of the IAB Stack Evolution Program, with input from many others. In particular, Mark Nottingham, Dave Crocker, Eliot Lear, Joe Touch, Cameron Byrne, John Klensin, Patrik Faltstrom, the IETF Applications Area WG, and others provided helpful input on this document.
本文档是IAB堆栈演化程序的产物，有许多其他人的输入。特别是，马克·诺丁汉、戴夫·克罗克、艾略特·李尔、乔·图奇、卡梅隆·伯恩、约翰·克莱辛、帕特里克·法尔茨特罗姆、IETF应用领域工作组和其他人就本文件提供了有益的意见。
Author's Address
作者地址
Dave Thaler (editor) One Microsoft Way Redmond, WA 98052 United States of America
Dave Thaler（编辑）One Microsoft Way Redmond，WA 98052美利坚合众国
Email: dthaler@microsoft.com
Email: dthaler@microsoft.com