[要約] RFC 8170は、プロトコルの採用とその後の移行の計画に関するガイドラインです。その目的は、プロトコルの採用と移行プロセスを効果的に管理し、ネットワークの安定性と互換性を確保することです。
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.
インターネットプロトコルの導入以来、長年にわたり、新しいプロトコルの展開、既存のプロトコルの更新または置き換えなど、プロトコルスタック全体で多くの移行が見られました。多くのプロトコルとテクノロジーは、代替案へのスムーズな移行を可能にしたり、拡張機能を簡単に展開したりするようには設計されていません。したがって、IPv6の導入など、一部の移行は困難でした。このドキュメントは、将来の移行を可能にするためのいくつかの基本原則を要約することを試み、また、優れた移行計画を構成するものを要約します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
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.
「遷移」とは、ある状態または状態から別の状態または状態に変化するプロセスまたは期間です。技術的な移行（プロトコルの変更や拡張機能の展開など）と組織の移行（Webサイトを管理する組織の変更など）の両方を含む、このような移行にはいくつかの種類があります。このドキュメントでは、技術的な移行にのみ焦点を当てていますが、他のタイプにもいくつかの原則が適用される場合があります。
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 deployment of an updated version of an existing protocol, or
o以前のプロトコルを廃止する新しいプロトコルの展開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間でのいわゆる「UNilateral Self-Address Fixing（UNSAF）」の技術には、そのようなメカニズムから移行するための出口戦略を含めることを推奨しています。 IABではなくIESGが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 「NAT-PTのフォローアップ作業」[IabIpv6TransitionStatement]に関するIABステートメントは、IPv6への移行時のギャップを指摘し、この結果、この問題を解決するためにIETF Behave WGを再チャーターしました。
More recently, the IAB has done work on more generally applicable principles, including two RFCs.
最近では、IABは2つの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]の「成功したプロトコルを構成するもの」具体的には、プロトコルの成功に寄与する要素とプロトコルの成功を損なう要素を調査し、プロトコルを推奨しました。 「初期の成功」（テクノロジーへの移行）と拡張性（最新バージョンへの移行）の2種類の移行について説明しました。そのドキュメントの原則と推奨事項は、一般的にすべての技術的な移行に適用されます。含まれるいくつかの重要な原則：
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. 段階的な展開：下位互換性により移行が容易になります。さらに、1つのエンティティのみを変更してもそのエンティティにメリットがある場合、移行は最も簡単です。最も簡単なケースでは、利益がコストをすぐに上回るため、エンティティーは自然に移行を促されます。より一般的には、他のかなりの数のエンティティも移行すると、メリットがコストを上回ります。残念ながら、そのような場合、自然な動機は、移行を遅らせることです。
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]は、インターネット技術の導入と移行（ITAT）に関するIABワークショップについて報告しました。 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.
このドキュメントの残りの部分では、これらの2つの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' 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ホップバイホップオプションなど）は、使用を開始すると実際に問題が発生することがよくあります。他の場合では、メカニズムがプロトコルに組み込まれて、それがどのように使用されるかについて十分な感覚がなくても、後で問題が発生する可能性があります（たとえば、SNMPの元の「セキュリティ」フィールド、または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への移行のように下位互換性がない場合、移行計画では「フラグ日」または共存期間を選択する必要があります。多数のエンティティが関係している場合、フラグデーは非現実的または不可能にさえなります。一方、共存には、オーバーラップ期間中に2つの別個のメカニズムを維持するための追加コストがかかり、かなり長くなる可能性があります。さらに、オーバーラップ期間が長いほど、古いメカニズムがさらに展開され、移行の全体的な苦痛が増す可能性があります。
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.
さらに、トランスレータがエンドポイント内にある場合、2つの動作セットの1つをアプリケーションに公開し、それを内部的に他の動作セットにマッピングすることにより、古いプロトコルと新しいプロトコルの違いを隠そうとします。または、より高いレベルの抽象化を公開し、必要なものの検出に応じて、どちらか一方に代替的にマッピングします。対照的に、トランスレータがパスの途中にある場合、通常、パスの途中ではより高いレベルの抽象化を提供できないため、最初のアプローチしか実行できません。
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日までに米国でのアナログTV放送が中止される）か、以下に該当する古いメカニズムの使用に基づく削除である指定されたレベル、または他の基準？
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の移行計画を提案しました。タイムラインは正確には守られていませんでしたが、フェーズとタイムラインはWorld IPv6 DayとWorld IPv6 Launchイベントへのインプットとして機能しました。
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.
たとえば、World IPv6 Dayには、1日の終わりに元の状態に戻すという緊急時対応計画が含まれていました。問題を発見しなかった後、一部の参加者はこの緊急時対応計画は不要であり、新しい状態を維持していることに気付きました。
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シリーズを認識していない可能性があるため、他のチャネルを介した普及は、移行計画の十分に広範なコミュニケーションの鍵となります。旗艦日はインターネット規模では非現実的ですが、World IPv6 Launchなどの調整された「イベント」は、進行中の移行に対する一般的な認識を向上させる可能性があります。
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.
一部の移行では、一部のユーザーの下位互換性が損なわれるリスクがあります。そのような場合、移行が顧客を互いに失うリスクに直面している競合するエンティティに影響を与える場合、移行への経済的阻害要因があります。したがって、促進するエンティティの1つの役割は、この恐怖を緩和するために、競合他社を同じ時間枠の間に移行させることです。たとえば、World IPv6 Launchの成功は、主に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.
さらに、2つのプロトコルの共存は、一般に、攻撃対象領域を2倍にするという意味でリスクを増大させます。これにより、利用者は2つのプロトコルのうち弱い方を使用できる場合は弱い方を選択したり、強い方を理解しないと主張してプロトコル間で交渉する際に弱い方を強制的に使用したりできます。
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コミュニティやarchitecture-discuss@ietf.orgメーリングリストでそのような知識を共有し、将来のドキュメントがこのトピックでは、このような経験を活用できます。
[GREASE] Benjamin, D., "Applying GREASE to TLS Extensibility", Work in Progress, draft-ietf-tls-grease-00, January 2017.
[グリース]ベンジャミンD.、「グリースをTLS拡張に適用する」、作業中、draft-ietf-tls-grease-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/>.
[IabIpv6TransitionStatement] 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 Deployment Survey」、2011、<https://www.nro.net/wp-content/uploads/ ipv6_deployment_survey.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] British Telecommunications、「IPv6 Industry Survey Report」、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.、Kuehlewwind、M.、Boppart、D.、Learmonth、I.、Fairhurst、G。、およびR. Scheffenegger、「インターネット全体での明示的な輻輳通知の展開の有効化」、PAM 2015の議事録、 DOI 10.1007 / 978-3-319-15509-8_15、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]ギリガン、R。およびE.ノードマーク、「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、「Hypertext Transfer Protocol-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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」、RFC 2068、DOI 10.17487 / RFC2068、1月1997、<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]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「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]ダイグル、L。、エド。およびIAB、「ネットワークアドレス変換を介したUNilateral Self-Address Fixing（UNSAF）に関するIABの考慮事項」、RFC 3424、DOI 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。、「Assigning Testing and Testing Numbers考慮された有用」、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：Tunneling IPv6 over UDP through Network Address Translations（NATs）」、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、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、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 5211、DOI 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]ターラー、D。およびB.アボバ、「成功するプロトコルを作るもの」、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。、エド、ブーカデア、M。、デュランド、A。、リーバイス、P。、およびP.ロバーツ、「IPアドレス共有の問題」、RFC 6269、DOI 10.17487 / RFC6269、2011年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、「The WebSocket Protocol」、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.、and J. Doshi、 "Assessing the Impact of Carrier-Grade NAT on Network Applications"、RFC 7021、DOI 10.17487 / RFC7021、2013年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.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、DOI 10.17487 / RFC7228、May 2014、<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]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、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、「Transport Layer Security（TLS）Application-Layer Protocol Negotiation Extension」、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] Lear、E.、Ed。、「インターネットテクノロジーの採用と移行（ITAT）に関するIABワークショップからの報告」、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.、Peon、R。、およびM. Thomson、編、「Hypertext Transfer Protocol Version 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] Peon、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]で標準化され、メカニズムは2つの部分で構成されています。IPレイヤーでの輻輳検出、古いIP Type of Service（TOS）フィールドの2ビットの再利用、およびトランスポートレイヤーでの輻輳フィードバックです。 TCPのフィードバックは、ECN EchoとCongestion Window Reducedの2つのTCPフラグを使用します。 ECNは、適切に構成されたアクティブキュー管理（AQM）と共に、輻輳したリンクでの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のネゴシエーションとサポート）とパス上のデバイス（輻輳が発生したときにトラフィックをマークする）の両方を連携させる必要があることは、さらなる問題でした。インターネット上での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
2000年代後半に、LinuxおよびWindowsサーバーはデフォルトで「パッシブECNサポート」を開始しました。つまり、クライアントから要求された場合はECNをネゴシエートしますが、デフォルトではECNのネゴシエーションを要求しません。この決定はリスクなしと見なされました。ECNをネゴシエートするようにクライアントが明示的に構成されている場合のみ、接続の問題が表面化する可能性があります。これにより、インターネットでのサーバーサポートは2008年のほぼゼロから2011年には上位100万人の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.
DNSでの非ASCIIの導入、Unicodeの新しい各バージョンへの移行、およびIDNA 2003からIDNA 2008への移行など、IDNに関連する複数の技術的な移行がありました。非ASCIIの導入の簡単な歴史DNSとそこで発生したさまざまな複雑化については、[RFC6055]のセクション3をご覧ください。 IDNA 2003はUnicodeバージョン3.2のみに制限されていましたが、IDNA 2008の変更の1つは、その規則を特定のバージョンのUnicodeから切り離すことでした（この点の詳細については、[RFC5894]、特にセクション1.4を参照してください。また、[RFC4690]を参照してください。 IDNA 2008の動機となったIDNA 2003の他の問題のリストについては）。ただし、IDNA 2003からIDNA 2008への移行自体に問題がありました。これは、IDNA 2008がいくつかのコードポイントでIDNA 2003との下位互換性を維持していなかったためです。 IDNA 2008に移行してIDNA 2003の問題を修正することによる全体的な利益は、変更時のいくつかの非互換性による問題よりもはるかに大きいと見られていたため、調査と影響を受ける当事者との議論により、IETFは最終的にIDNA 2008を選択しました、使用されているIDNはそれほど多くなく、非互換性が見られる可能性がある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]を公開しました。これは一部で実装されましたが、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]はIndependent Submissionストリームで公開されていました。マッピングに関するディスカッションでは、主要なトピックの1つは、移行がどれだけ長く続くべきかということでした。期間スペクトルの一方の端は、一部のエンティティが最初に壊れるフラグ日ですが、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]）は、プロトコル自体の1年足らずで公開されました。長期的にはすべてのホストが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.
OSベンダーがすでに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の導入によるネットワークへの影響はありませんでした。 Class4 Inter-Domain Routing（CIDR）[RFC4632]、NAT、およびけちな割り当てなど、IPv4の寿命を延ばすための回避策がそれをより複雑にしたと支持者が主張したとしても、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 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.
[RFC6269]と[RFC7021]に記載されているNATの問題の回避策には、インタラクティブ接続の確立（ICE）、NATのセッショントラバーサルユーティリティ（STUN）、NAT周りのリレーを使用したトラバーサル（TURN）など、問題が発生した人がテクノロジーを展開できるようにするテクノロジーそれらを解決する。エンドツーエンドのIPv6トンネリング（Teredoなど）と同様に、そこでのインセンティブは、問題を修正するコストとメリットを一致させ、それらを使用するユーザーに段階的なメリットをもたらしました。 IABはNAT技術の提案[RFC3424]について議論し、それらは短期的な修正と見なすことを推奨し、提案には時間の経過とともに減少するような出口計画を含める必要があると述べました。特に、IABはNATソリューションの一般化に対して警告を発しました。いくつかの点で、これらのソリューションは、他の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.
間違いなく将来を見据えた企業は、World IPv6 DayとWorld IPv6 LaunchでISOCと協力して、グローバルIPv6の展開を迅速に開始しました。複数の競合他社を含めることにより、World IPv6 Dayは、ユーザーのIPv6実装が壊れた場合に、いずれかの競合他社が顧客を失うリスクを軽減しました。次に、World IPv6 Launchは、コンテンツプロバイダーがIPv6を永続的に有効にし、大規模なISPがエンドユーザーの少なくとも1％でIPv6を有効にするという目標を設定します。これらの大規模で目に見える展開は、IPv6を適切にサポートするための特定の機能と目標日をベンダーに与えました。 World IPv6 DayとWorld IPv6 Launchの成功に貢献した主な側面（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-onlyホストを使用することを選択しています。ネットワークのコアにIPv6のみのルーターを備えたデュアルスタックホストを使用し、IPv4をトンネル経由またはデュアルスタックエッジルーターに変換するホストもあります。さらに、ネットワーク全体でネイティブデュアルスタックを使用している人もいますが、それは一般的に暫定的な措置として持続します。2つのテクノロジーの採用は、あるテクノロジーから別のテクノロジーへの移行と同じではありません。最後に、いくつかの壁に囲まれた庭園や管理ネットワークなどの分離されたネットワークは、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などの他のプロトコル（[GREASE]で例示）で観察されており、そのような「グリース」を必要とする拡張ポイントを特定し、それらが使用中のように見えるようにする積極的な取り組みがあります。
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 result, interoperability and deployment suffered and is still considered a "problem area" for the protocol.
同様に、HTTP / 1.1のExpect / Continueメカニズムは、それが導入した新しいセマンティクスの幅広いサポートに依存しており、プロトコルの以前のバージョンに対する適切なフォールバック戦略を持っていませんでした。その結果、相互運用性と展開に影響が出ており、プロトコルの「問題領域」と見なされています。
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の他の多くの機能または特性は、HTTP / 2プロセスの一部として望ましくない可能性があると識別され、削除が検討されました。これには、トレーラー、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ヘッダーフィールドを提供しました。これまでのところ、これはWebSockets [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 with [RFC6709]: few extension points were added, unless an immediate need was understood.
[RFC5218]のアドバイスに照らして、新しいバージョンは必要に応じて簡単に展開できるという信頼は、[RFC5218]のアドバイスに照らして異常と見なされる可能性がある特定の設計スタンスにつながります。必要性が理解された。
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 Stack Evolution Programの製品であり、他の多くの人々からのインプットを含んでいます。特に、Mark Nottingham、Dave Crocker、Eliot Lear、Joe Touch、Cameron Byrne、John Klensin、Patrik Faltstrom、IETF Applications Area WGなどが、このドキュメントに関する有益な情報を提供してくれました。
Author's Address
著者のアドレス
Dave Thaler (editor) One Microsoft Way Redmond, WA 98052 United States of America
Dave Thaler（編集者）One Microsoft Wayレドモンド、ワシントン州98052アメリカ合衆国
Email: dthaler@microsoft.com