[要約] RFC 9170は、プロトコル拡張メカニズムの長期的な実用性に関する文書です。その目的は、将来の技術変化に対応できるように、プロトコル設計における拡張性を確保することにあります。この文書は、インターネットプロトコルの設計者や開発者が、長期にわたって有効な拡張機能を設計する際の指針として利用されます。
Internet Architecture Board (IAB) M. Thomson
Request for Comments: 9170
Category: Informational T. Pauly
ISSN: 2070-1721 December 2021
Long-Term Viability of Protocol Extension Mechanisms
プロトコル拡張メカニズムの長期生存率
Abstract
概要
The ability to change protocols depends on exercising the extension and version-negotiation mechanisms that support change. This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol. Examples are given where lack of use caused changes to be more difficult or costly.
プロトコルを変更する機能は、変更をサポートする拡張機能とバージョン - ネゴシエーションメカニズムの実行によって異なります。このドキュメントでは、新しいプロトコル機能の通常の使用方法をプロトコルに変更することができるようにすることができることを確認できます。使用の欠如がより困難または費用がかかるという変化が生じた場合の例として与えられます。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書はインターネットアーキテクチャボード（IAB）の積であり、IABが恒久的な記録を提供するために貴重な情報を表しています。ITインターネットアーキテクチャボード（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 https://www.rfc-editor.org/info/rfc9170.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9170で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2021 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。
Table of Contents
目次
1. Introduction
2. Imperfect Implementations Limit Protocol Evolution
2.1. Good Protocol Design Is Not Itself Sufficient
2.2. Disuse Can Hide Problems
2.3. Multi-party Interactions and Middleboxes
3. Active Use
3.1. Dependency Is Better
3.2. Version Negotiation
3.3. Falsifying Active Use
3.4. Examples of Active Use
3.5. Restoring Active Use
4. Complementary Techniques
4.1. Fewer Extension Points
4.2. Invariants
4.3. Limiting Participation
4.4. Effective Feedback
5. Security Considerations
6. IANA Considerations
7. Informative References
Appendix A. Examples
A.1. DNS
A.2. HTTP
A.3. IP
A.4. SNMP
A.5. TCP
A.6. TLS
IAB Members at the Time of Approval
Acknowledgments
Authors' Addresses
A successful protocol [SUCCESS] needs to change in ways that allow it to continue to fulfill the changing needs of its users. New use cases, conditions, and constraints on the deployment of a protocol can render a protocol that does not change obsolete.
正常なプロトコル[成功]は、ユーザーのニーズを変える必要があることを継続することを可能にする方法で変更する必要があります。プロトコルの展開に対する新しいユースケース、条件、および制約は、廃止されないプロトコルをレンダリングすることができます。
Usage patterns and requirements for a protocol shift over time. In response, implementations might adjust usage patterns within the constraints of the protocol, the protocol could be extended, or a replacement protocol might be developed. Experience with Internet-scale protocol deployment shows that each option comes with different costs. [TRANSITIONS] examines the problem of protocol evolution more broadly.
使用状況パターンとプロトコルシフトの要件それに応答して、実装はプロトコルの制約内で使用パターンを調整する可能性があり、プロトコルを拡張することも、置換プロトコルを開発する可能性がある。インターネットスケールプロトコル展開の経験は、各オプションが異なるコストが付いていることを示しています。[遷移]プロトコルの進化の問題をより広く調べます。
An extension point is a mechanism that allows a protocol to be changed or enhanced. This document examines the specific conditions that determine whether protocol maintainers have the ability to design and deploy new or modified protocols via their specified extension points. Section 2 highlights some historical examples of difficulties in transitions to new protocol features. Section 3 argues that ossified protocols are more difficult to update and describes how successful protocols make frequent use of new extensions and code points. Section 4 outlines several additional strategies that might aid in ensuring that protocol changes remain possible over time.
拡張ポイントは、プロトコルを変更または強化することを可能にするメカニズムです。この文書では、プロトコルメンテナが、指定された拡張ポイントを介して新しいプロトコルまたは変更されたプロトコルを設計および展開する能力を有する特定の条件を調べます。セクション2は、新しいプロトコル機能への移行における困難の歴史的な例を強調しています。セクション3は、斬新なプロトコルが、プロトコルが新しい拡張機能とコードポイントをどのように使用するかを更新および説明するのがより困難であると主張しています。セクション4は、プロトコルの変更が時間の経過とともに可能なままであることを保証するのを助けることができるいくつかの追加の戦略を概説しています。
The experience that informs this document is predominantly at "higher" layers of the network stack, in protocols with limited numbers of participants. Though similar issues are present in many protocols that operate at scale, the trade-offs involved with applying some of the suggested techniques can be more complex when there are many participants, such as at the network layer or in routing systems.
この文書に通知する経験は、主にネットワークスタックの層で、限られた数の参加者を備えたプロトコルでも主にあります。スケールで動作する多くのプロトコルにも同様の問題が存在していますが、ネットワーク層やルーティングシステムなどの多くの参加者がある場合、推奨されるテクニックのいくつかを適用することに関わるトレードオフはより複雑になる可能性があります。
It can be extremely difficult to deploy a change to a protocol if implementations with which the new deployment needs to interoperate do not operate predictably. Variation in how new code points or extensions are handled can be the result of bugs in implementation or specifications. Unpredictability can manifest as errors, crashes, timeouts, abrupt termination of sessions, or disappearances of endpoints.
新しい展開が相互運用する必要がある実装が予測可能に動作しないように、プロトコルに変更を展開することは極めて困難です。新しいコードポイントまたは拡張機能がどのように処理されるかのバリエーションは、実装または仕様のバグの結果です。予測不可能性は、エラー、クラッシュ、タイムアウト、セッションの突然の終点、またはエンドポイントの消失としてマニフェートできます。
The risk of interoperability problems can in turn make it infeasible to deploy certain protocol changes. If deploying a new code point or extension makes an implementation less reliable than others, even if only in rare cases, it is far less likely that implementations will adopt the change.
相互運用性の問題のリスクは、特定のプロトコルの変更を展開することができなくなる可能性があります。新しいコードポイントまたは拡張子を展開すると、実装が他の場合よりも信頼性が低くなりますが、まれな場合にのみ、実装が変更を採用する可能性がはるかに低いです。
Deploying a change to a protocol could require implementations to fix a substantial proportion of the bugs that the change exposes. This can involve a difficult process that includes identifying the cause of these errors, finding the responsible implementation(s), coordinating a bug fix and release plan, contacting users and/or the operator of affected services, and waiting for the fix to be deployed.
プロトコルへの変更を展開すると、変更が公開するバグのかなりの割合を修正するための実装が必要になる可能性があります。これは、これらのエラーの原因を特定すること、責任ある実装を見つける、バグ修正とリリースプランの調整、ユーザーと影響を受けるサービスのオペレータに連絡し、修正を展開するのを待っているという困難なプロセスを含みます。。
Given the effort involved in fixing problems, the existence of these sorts of bugs can outright prevent the deployment of some types of protocol changes, especially for protocols involving multiple parties or that are considered critical infrastructure (e.g., IP, BGP, DNS, or TLS). It could even be necessary to come up with a new protocol design that uses a different method to achieve the same result.
問題を修正することに関わる努力を考えると、これらの種類のバグの存在は、特に複数の締約国を含むプロトコルまたは重要なインフラストラクチャと見なされるプロトコルのための、ある種のプロトコル変更の展開を完全に妨げることができます（または、IP、BGP、DNS、またはTLS）。）。同じ結果を達成するために別の方法を使用する新しいプロトコルデザインを考え出すことさえ必要となる可能性さえあります。
This document only addresses cases where extensions are not deliberately blocked. Some deployments or implementations apply policies that explicitly prohibit the use of unknown capabilities. This is especially true of functions that seek to make security guarantees, like firewalls.
このドキュメントは、拡張機能が故意にブロックされていない場合にのみ対処します。いくつかの展開または実装には、未知の機能の使用を明示的に禁止するポリシーが適用されます。これは、ファイアウォールのようにセキュリティ保証を確保することを求める機能に特に当てはまります。
The set of interoperable features in a protocol is often the subset of its features that have some value to those implementing and deploying the protocol. It is not always the case that future extensibility is in that set.
プロトコル内の相互運用可能な機能のセットは、プロトコルを実装して展開するものにある程度の値を持つその機能のサブセットです。そのセットに将来の拡張性がある場合は必ずしもそうではありません。
It is often argued that the careful design of a protocol extension point or version-negotiation capability is critical to the freedom that it ultimately offers.
プロトコル拡張ポイントまたはバージョンネゴシエーション機能の慎重な設計は、それが最終的に提供する自由にとって重要であるとしばしば主張されています。
RFC 6709 [EXTENSIBILITY] contains a great deal of well-considered advice on designing for extensions. It includes the following advice:
RFC 6709 [Extensibility]には、拡張機能の設計に関する大容易なアドバイスが含まれています。以下のアドバイスが含まれます。
| This means that, to be useful, a protocol version-negotiation
| mechanism should be simple enough that it can reasonably be
| assumed that all the implementers of the first protocol version at
| least managed to implement the version-negotiation mechanism
| correctly.
There are a number of protocols for which this has proven to be insufficient in practice. These protocols have imperfect implementations of these mechanisms. Mechanisms that aren't used are the ones that fail most often. The same paragraph from RFC 6709 acknowledges the existence of this problem but does not offer any remedy:
これが実際には不十分であることが証明されているプロトコルがいくつかあります。これらのプロトコルはこれらのメカニズムの実装が不完全です。使用されていないメカニズムは、最も頻繁に失敗するものです。RFC 6709からの同じ段落は、この問題の存在を認めますが、救済策は提供されていません。
| The nature of protocol version-negotiation mechanisms is that, by
| definition, they don't get widespread real-world testing until
| *after* the base protocol has been deployed for a while, and its
| deficiencies have become evident.
Indeed, basic interoperability is considered critical early in the deployment of a protocol. A desire to deploy can result in early focus on a reduced feature set, which could result in deferring implementation of version-negotiation and extension mechanisms. This leads to these mechanisms being particularly affected by this problem.
実際、基本的な相互運用性は、プロトコルの展開の早い段階で重要と考えられています。展開したいという要望は、縮小機能セットに早期に焦点を当てることができ、それはバージョン交渉および拡張メカニズムの実施を延期する可能性がある。これは、これらのメカニズムがこの問題によって特に影響を受ける可能性があります。
There are many examples of extension points in protocols that have been either completely unused or their use was so infrequent that they could no longer be relied upon to function correctly.
完全に未使用であったプロトコル内の拡張ポイントの例は、正しく機能することができなくなったことができなかったことで、それらが正しく機能することができなかったことが多数ありました。
Appendix A includes examples of disuse in a number of widely deployed Internet protocols.
付録Aには、多数の広く展開されたインターネットプロトコルの中断の例が含まれています。
Even where extension points have multiple valid values, if the set of permitted values does not change over time, there is still a risk that new values are not tolerated by existing implementations. If the set of values for a particular field of a protocol or the order in which these values appear remains fixed over a long period, some implementations might not correctly handle a new value when it is introduced. For example, implementations of TLS broke when new values of the signature_algorithms extension were introduced.
拡張ポイントが複数の有効な値を持つ場合でも、許可された値のセットが時間とともに変化しない場合、新しい値が既存の実装によって許容されないというリスクがあります。プロトコルの特定のフィールドまたはこれらの値が表示される順序の値のセットが長期間にわたって固定されたままである場合、いくつかの実装は、導入されたときに新しい値を正しく処理されない可能性があります。たとえば、Signature_algorithms拡張子の新しい値が導入されたときにTLSの実装が破損しました。
One of the key challenges in deploying new features is ensuring compatibility with all actors that could be involved in the protocol. Even the most superficially simple protocols can often involve more actors than is immediately apparent.
新機能を展開する際の重要な課題の1つは、プロトコルに関与する可能性があるすべてのアクターとの互換性を確保しています。最も超微妙に単純なプロトコルでさえも、すぐに明らかなものよりも多くのアクターを巻き込むことができます。
The design of extension points needs to consider what actions middleboxes might take in response to a protocol change as well as the effect those actions could have on the operation of the protocol.
拡張ポイントの設計は、プロトコルの変更に応じて、プロトコルの変更に応じてどのようなアクションを考慮する必要があるか、プロトコルの操作に使用できることを考慮する必要があります。
Deployments of protocol extensions also need to consider the impact of the changes on entities beyond protocol participants and middleboxes. Protocol changes can affect the behavior of applications or systems that don't directly interact with the protocol, such as when a protocol change modifies the formatting of data delivered to an application.
プロトコル拡張子の展開も、プロトコル参加者およびミドルボックスを超えたエンティティに対する変更の影響を考慮する必要があります。プロトコルの変更は、プロトコル変更がアプリケーションに配信されるデータのフォーマットを変更したときなど、プロトコルと直接対話しないアプリケーションまたはシステムの動作に影響を与える可能性があります。
The design of a protocol for extensibility and eventual replacement [EXTENSIBILITY] does not guarantee the ability to exercise those options. The set of features that enable future evolution need to be interoperable in the first implementations and deployments of the protocol. Implementation of mechanisms that support evolution is necessary to ensure that they remain available for new uses, and history has shown this occurs almost exclusively through active mechanism use.
拡張性と最終的な交換のためのプロトコルの設計[拡張性]は、それらのオプションを行使する能力を保証するものではありません。将来の進化を可能にする一連の機能は、最初の実装とプロトコルの展開で相互運用可能である必要があります。進化をサポートするメカニズムの実装は、新しい用途に使用できるようにするために必要であり、これがActive Mechaniseの使用を介してほとんど排他的に発生したことを示しました。
Only by using the extension capabilities of a protocol is the availability of that capability assured. "Using" here includes specifying, implementing, and deploying capabilities that rely on the extension capability. Protocols that fail to use a mechanism, or a protocol that only rarely uses a mechanism, could lead to that mechanism being unreliable.
プロトコルの拡張機能を使用することによってのみ、保証されたその機能の可用性です。ここでの「使用」には、拡張機能に依存する機能、実装、および展開が含まれます。メカニズムを使用できないプロトコル、またはメカニズムを使用するだけのプロトコルは、そのメカニズムが信頼できないことにつながる可能性があります。
Implementations that routinely see new values are more likely to correctly handle new values. More frequent changes will improve the likelihood that incorrect handling or intolerance is discovered and rectified. The longer an intolerant implementation is deployed, the more difficult it is to correct.
新しい値を確信しているのは、新しい値を正しく処理する可能性が高いです。より頻繁な変更は、誤った取扱いまたは侵害が発見され修正される可能性を向上させます。耐えられない実装が長いほど展開されますが、それが正しいことが難しいです。
Protocols that routinely add new extensions and code points rarely have trouble adding additional ones especially when the handling of new versions or extensions are well defined. The definition of mechanisms alone is insufficient; it is the assured implementation and active use of those mechanisms that determines their availability.
新しい拡張子とコードポイントを日常的に追加するプロトコルは、特に新しいバージョンまたは拡張機能の処理が正しく定義されている場合に、追加のものを追加するのに問題がありません。メカニズムのみの定義だけが不十分です。それは彼らの可用性を決定するメカニズムの確実な実装と積極的な使用です。
What constitutes "active use" can depend greatly on the environment in which a protocol is deployed. The frequency of changes necessary to safeguard some mechanisms might be slow enough to attract ossification in another protocol deployment, while being excessive in others.
「アクティブな使用」を構成するものは、プロトコルが展開されている環境に大きく依存できます。いくつかのメカニズムを保護するのに必要な変化の頻度は、他のプロトコル展開で骨化を引き付けるのに十分遅くなる可能性があります。
The easiest way to guarantee that a protocol mechanism is used is to make the handling of it critical to an endpoint participating in that protocol. This means that implementations must rely on both the existence of extension mechanisms and their continued, repeated expansion over time.
プロトコルメカニズムが使用されていることを保証する最も簡単な方法は、そのプロトコルに参加しているエンドポイントにとって重要なのを処理することです。つまり、実装は、エクステンションメカニズムの存在とその継続的な繰り返し拡張の両方に依存している必要があります。
For example, the message format in SMTP relies on header fields for most of its functions, including the most basic delivery functions. A deployment of SMTP cannot avoid including an implementation of header field handling. In addition to this, the regularity with which new header fields are defined and used ensures that deployments frequently encounter header fields that they do not yet (and may never) understand. An SMTP implementation therefore needs to be able to both process header fields that it understands and ignore those that it does not.
たとえば、SMTPのメッセージフォーマットは、最も基本的な配信機能を含めて、ほとんどの機能のヘッダーフィールドに依存しています。SMTPの展開は、ヘッダーフィールド処理の実装を含めることは避けられません。これに加えて、新しいヘッダーフィールドが定義され使用される規則性は、デプロイメントがまだそれらがまだ理解していないヘッダーフィールドに遭遇することが頻繁に発生します。したがって、SMTP実装は、それが理解しているプロセスヘッダーフィールドの両方を受信して無視することができなければなりません。
In this way, implementing the extensibility mechanism is not merely mandated by the specification, it is crucial to the functioning of a protocol deployment. Should an implementation fail to correctly implement the mechanism, that failure would quickly become apparent.
このようにして、拡張メカニズムを実装することは単に仕様によって義務付けられていないため、プロトコル展開の機能にとって非常に重要です。実装がメカニズムを正しく実装できない場合、その失敗はすぐに明らかになるでしょう。
Caution is advised to avoid assuming that building a dependency on an extension mechanism is sufficient to ensure availability of that mechanism in the long term. If the set of possible uses is narrowly constrained and deployments do not change over time, implementations might not see new variations or assume a narrower interpretation of what is possible. Those implementations might still exhibit errors when presented with new variations.
注意は、長期的にそのメカニズムの可用性を確保するのに十分であることを想定しないでください。可能な用途のセットが狭く制約があり、展開が時間の経過とともに変化しない場合、実装は新しいバリエーションを見たり、可能な限り狭い解釈を想定している可能性があります。これらの実装は、新しいバリエーションで提示されたときにエラーを展示する可能性があります。
As noted in Section 2.1, protocols that provide version-negotiation mechanisms might not be able to test that feature until a new version is deployed. One relatively successful design approach has been to use the protocol selection mechanisms built into a lower-layer protocol to select the protocol. This could allow a version-negotiation mechanism to benefit from active use of the extension point by other protocols.
セクション2.1に記載されているように、バージョンネゴシエーションメカニズムを提供するプロトコルは、新しいバージョンがデプロイされるまでその機能をテストできない可能性があります。比較的成功した設計アプローチの1つは、プロトコルを選択するために下位レイヤープロトコルに組み込まれているプロトコル選択メカニズムを使用することでした。これにより、バージョンネゴシエーションメカニズムが他のプロトコルによる拡張ポイントの積極的な使用から利益を得ることができます。
For instance, all published versions of IP contain a version number as the four high bits of the first header byte. However, version selection using this field proved to be unsuccessful. Ultimately, successful deployment of IPv6 over Ethernet [RFC2464] required a different EtherType from IPv4. This change took advantage of the already diverse usage of EtherType.
たとえば、公開されているすべてのIPには、最初のヘッダーバイトの4つのハイビットとしてのバージョン番号が含まれています。ただし、このフィールドを使用したバージョン選択は失敗しました。最終的には、イーサネット（RFC2464 over over ishernetnet [RFC2464]のIPv6の展開を成功させる必要があります。この変更は、既に多様なEtherTypeの使用を利用しました。
Other examples of this style of design include Application-Layer Protocol Negotiation ([ALPN]) and HTTP content negotiation (Section 12 of [HTTP]).
このスタイルの設計の他の例としては、アプリケーション層プロトコルネゴシエーション（[ALPN]）およびHTTPコンテンツネゴシエーションが含まれます（[HTTP]のセクション12）。
This technique relies on the code point being usable. For instance, the IP protocol number is known to be unreliable and therefore not suitable [NEW-PROTOCOLS].
この手法は、使用可能なコードポイントに依存しています。たとえば、IPプロトコル番号は信頼できないため、適切な[新規プロトコル]ではありません。
"Grease" was originally defined for TLS [GREASE] but has been adopted by other protocols such as QUIC [QUIC]. Grease identifies lack of use as an issue (protocol mechanisms "rusting" shut) and proposes reserving values for extensions that have no semantic value attached.
「グリース」はもともとTLS [グリース]に対して定義されていましたが、QUICのような他のプロトコルによって採用されています。グリースは問題としての使用不足を識別します（プロトコルメカニズム「錆」シャットされている）、意味値が添付されていない拡張機能の予約を提案します。
The design in [GREASE] is aimed at the style of negotiation most used in TLS, where one endpoint offers a set of options and the other chooses the one that it most prefers from those that it supports. An endpoint that uses grease randomly offers options, usually just one, from a set of reserved values. These values are guaranteed to never be assigned real meaning, so its peer will never have cause to genuinely select one of these values.
[グリース]の設計は、TLSで最も使用されている交渉のスタイルを目的としています。グリースを使用するエンドポイントは、通常、1つの予約値から1つだけのオプションを提供します。これらの値は実際の意味を割り当てないことが保証されているため、ピアは本当にこれらの値の1つを選択する原因はありません。
More generally, greasing is used to refer to any attempt to exercise extension points without changing endpoint behavior other than to encourage participants to tolerate new or varying values of protocol elements.
より一般的には、プロトコル要素の新規または変化する値を許容するために、参加者が参加者を奨励するために、エンドポイントの動作を変えることなく延長点を行使するための試みを指すために粉砕が使用されます。
The principle that grease operates on is that an implementation that is regularly exposed to unknown values is less likely to be intolerant of new values when they appear. This depends largely on the assumption that the difficulty of implementing the extension mechanism correctly is as easy or easier than implementing code to identify and filter out reserved values. Reserving random or unevenly distributed values for this purpose is thought to further discourage special treatment.
グリースが操作する原則は、未知の値に定期的に公開されている実装が、表示されたときに新しい値を軽期化する可能性が低いということです。これは、拡張メカニズムを正しく実装することの困難さが、予約値を識別してフィルタリングするためのコードを実装することよりも簡単であるかやや容易であることを前提としています。この目的のためのランダムまたは不均一な分布値を予約することは、特別な治療をさらに阻止すると考えられています。
Without reserved greasing code points, an implementation can use code points from spaces used for private or experimental use if such a range exists. In addition to the risk of triggering participation in an unwanted experiment, this can be less effective. Incorrect implementations might still be able to identify these code points and ignore them.
グリースコードポイントを予約せずに、実装は、そのような範囲が存在する場合には、プライベートまたは実験的使用に使用されるスペースからコードポイントを使用できます。不要な実験への参加を誘発する危険性に加えて、これは効果的ではない可能性があります。誤った実装は、まだこれらのコードポイントを識別してそれらを無視することができる可能性があります。
In addition to advertising bogus capabilities, an endpoint might also selectively disable noncritical protocol elements to test the ability of peers to handle the absence of certain capabilities.
ボーガス機能を広告することに加えて、エンドポイントは、非重要プロトコル要素を選択的に無効にして、特定の機能がないことを処理するためのピアの能力をテストすることもできます。
This style of defensive design is limited because it is only superficial. As greasing only mimics active use of an extension point, it only exercises a small part of the mechanisms that support extensibility. More critically, it does not easily translate to all forms of extension points. For instance, highest mutually supported version (HMSV) negotiation cannot be greased in this fashion. Other techniques might be necessary for protocols that don't rely on the particular style of exchange that is predominant in TLS.
このスタイルの防御デザインは、それが表面的なだけであるため制限されています。延長点の故障のみを模倣するにつれて、拡張性をサポートするメカニズムのわずかな部分を実行します。より重大な場合、それはすべての形式の拡張ポイントに翻訳されません。たとえば、最も高い相互にサポートされているバージョン（HMSV）ネゴシエーションはこのようにしてグリースすることはできません。TLSで優勢であるExchangeの特定のスタイルに依存しないプロトコルには、他のテクニックが必要になる可能性があります。
Grease is deployed with the intent of quickly revealing errors in implementing the mechanisms it safeguards. Though it has been effective at revealing problems in some cases with TLS, the efficacy of greasing isn't proven more generally. Where implementations are able to tolerate a non-zero error rate in their operation, greasing offers a potential option for safeguarding future extensibility. However, this relies on there being a sufficient proportion of participants that are willing to invest the effort and tolerate the risk of interoperability failures.
それが保護するメカニズムを実装する際にエラーを迅速に明らかにしたという意図でグリースが展開されます。TLSを用いて問題を明らかにするのに効果的であったが、グリースの有効性はより一般的に証明されていない。実装がそれらの運用においてゼロ以外の誤り率を許容することができる場合、GreAdingは将来の拡張性を保護するための潜在的な選択肢を提供します。しかし、これは、努力を投資し、相互運用性の失敗のリスクを許容することを望んでいる十分な割合の参加者があることに依存しています。
Header fields in email [SMTP], HTTP [HTTP], and SIP [SIP] all derive from the same basic design, which amounts to a list of name/value pairs. There is no evidence of significant barriers to deploying header fields with new names and semantics in email and HTTP as clients and servers generally ignore headers they do not understand or need. The widespread deployment of SIP back-to-back user agents (B2BUAs), which generally do not ignore unknown fields, means that new SIP header fields do not reliably reach peers. This does not necessarily cause interoperability issues in SIP but rather causes features to remain unavailable until the B2BUA is updated. All three protocols are still able to deploy new features reliably, but SIP features are deployed more slowly due to the larger number of active participants that need to support new features.
電子メール[SMTP]、HTTP [HTTP]、およびSIP [SIP]のヘッダーフィールドは、すべて同じ基本設計から派生しています。これは、名前と値のペアのリストになります。クライアントやサーバーとしてのHTTPでヘッダーフィールドを展開するための重要な障壁の証拠はありません。一般的に未知のフィールドを無視しないSIPバックツーバックユーザエージェント（B2BUAS）の広範な展開は、新しいSIPヘッダフィールドが確実にピアに到達しないことを意味します。これは必ずしもSIPで相互運用性の問題を引き起こすわけではなく、B2BUAが更新されるまで機能を使用できなくなります。3つのプロトコルすべてがまだ確実に展開することができますが、SIP機能は新しい機能をサポートする必要がある多数のアクティブな参加者がよりゆっくりと展開されます。
As another example, the attribute-value pairs (AVPs) in Diameter [DIAMETER] are fundamental to the design of the protocol. Any use of Diameter requires exercising the ability to add new AVPs. This is routinely done without fear that the new feature might not be successfully deployed.
別の例として、直径の属性値対（AVPS）は、プロトコルの設計に対して基本的である。直径の使用は、新しいAVPを追加する能力を実行する必要があります。これは、新機能が正常にデプロイされない可能性があることを恐れずに定期的に行われます。
These examples show extension points that are heavily used are also being relatively unaffected by deployment issues preventing addition of new values for new use cases.
これらの例は、普及している展開点を示しています。また、新規使用例のための新しい値の追加を妨げる展開問題によって比較的影響を受けません。
These examples show that a good design is not required for success. On the contrary, success is often despite shortcomings in the design. For instance, the shortcomings of HTTP header fields are significant enough that there are ongoing efforts to improve the syntax [HTTP-HEADERS].
これらの例は、成功のために良いデザインが必要ではないことを示しています。それどころか、成功はデザインの欠点にもかかわらずしばしばあります。たとえば、HTTPヘッダーフィールドの欠点は、構文[HTTP-HEADERS]を改善するための継続的な努力があるのに十分です。
With enough effort, active use can be used to restore capabilities.
十分な努力で、能動的な使用を使用して機能を回復させることができます。
Extension Mechanisms for DNS ([EDNS]) was defined to provide extensibility in DNS. Intolerance of the extension in DNS servers resulted in a fallback method being widely deployed (see Section 6.2.2 of [EDNS]). This fallback resulted in EDNS being disabled for affected servers. Over time, greater support for EDNS and increased reliance on it for different features motivated a flag day [DNSFLAGDAY] where the workaround was removed.
DNS（[EDNS]）の拡張メカニズムは、DNSで拡張性を提供するように定義されました。DNSサーバーの拡張機能の不耐性は、広く展開されているフォールバックメソッドをもたらしました（[EDNS]のセクション6.2.2を参照）。このフォールバックには、影響を受けるサーバーに対してEDNが無効になっていました。時間の経過とともに、EDNのためのより大きなサポートとさまざまな機能のためのそれへの依存性の向上は、回避策が削除されたフラグの日[DNSFLAGDAY]をやる気にさせました。
The EDNS example shows that effort can be used to restore capabilities. This is in part because EDNS was actively used with most resolvers and servers. It was therefore possible to force a change to ensure that extension capabilities would always be available. However, this required an enormous coordination effort. A small number of incompatible servers and the names they serve also became inaccessible to most clients.
EDNSの例は、能力を復元するために努力を使用することができることを示しています。EDNSがほとんどのリゾルバとサーバーで積極的に使用されていたため、これは一部です。したがって、拡張機能が常に利用可能になるように変更を強制することが可能でした。しかし、これは莫大な調整努力を必要としました。少数の互換性のないサーバーと彼らが奉仕する名前も、ほとんどのクライアントにアクセスできなくなりました。
The protections to protocol evolution that come from active use (Section 3) can be improved through the use of other defensive techniques. The techniques listed here might not prevent ossification on their own, but they can make active use more effective.
積極的な使用から来るプロトコル進化への保護（セクション3）は、他の防御的な技術を使用することによって改善することができる。ここにリストされているテクニックは、それら自身での骨化を防ぐことはできませんが、それらは積極的な使用をより効果的にすることができます。
A successful protocol will include many potential types of extensions. Designing multiple types of extension mechanisms, each suited to a specific purpose, might leave some extension points less heavily used than others.
正常なプロトコルには、多くの潜在的なエクステンションが含まれます。特定の目的に合った複数種類の拡張メカニズムを設計すると、延長点が他のものよりも大きく使用されなくなる可能性があります。
Disuse of a specialized extension point might render it unusable. In contrast, having a smaller number of extension points with wide applicability could improve the use of those extension points. Use of a shared extension point for any purpose can protect rarer or more specialized uses.
特殊な拡張ポイントの乱用は使用できなくなる可能性があります。対照的に、広い適用可能性を有する延長点数が少ないほど、それらの延長点の使用を改善することができる。いかなる目的のための共有拡張ポイントの使用は、RARER以上の特殊な用途を保護することができます。
Both extensions and core protocol elements use the same extension points in protocols like HTTP [HTTP] and DIAMETER [DIAMETER]; see Section 3.4.
ExtensionsとCore Protocol Elementsの両方がHTTP [HTTP]とDiameter [Diamety]のようなプロトコル内の同じ拡張ポイントを使用します。セクション3.4を参照してください。
Documenting aspects of the protocol that cannot or will not change as extensions or new versions are added can be a useful exercise. Section 2.2 of [RFC5704] defines invariants as:
拡張または新しいバージョンが追加されないプロトコルの側面を文書化することは、有用な演習である可能性があります。[RFC5704]のセクション2.2は、以下のように不変式を定義します。
| Invariants are core properties that are consistent across the | network and do not change over extremely long time-scales.
| ..不変式は、|を越えて一致するコアプロパティです。ネットワークで、非常に長い時間スケールを変えないでください。
Understanding what aspects of a protocol are invariant can help guide the process of identifying those parts of the protocol that might change. [QUIC-INVARIANTS] and Section 9.3 of [TLS13] are both examples of documented invariants.
プロトコルのどの側面が不可欠であるかを理解することは、変更される可能性があるプロトコルのそれらの部分を識別するプロセスを導くのに役立ちます。[TLS13]の[QUIC-Invariants]とセクション9.3はどちらも文書化された不変量の例です。
As a means of protecting extensibility, a declaration of protocol invariants is useful only to the extent that protocol participants are willing to allow new uses for the protocol. A protocol that declares protocol invariants relies on implementations understanding and respecting those invariants. If active use is not possible for all non-invariant parts of the protocol, greasing (Section 3.3) might be used to improve the chance that invariants are respected.
拡張性を保護する手段として、プロトコル不変式の宣言は、プロトコル参加者がプロトコルの新しい用途を許可する意思がある範囲でのみ有用です。プロトコル不変式を宣言するプロトコルは、それらの不変式を理解し、尊重する実装に依存しています。プロトコルのすべての非不変部分に対して能動的な使用が不可能な場合は、不変式が尊重されている可能性を向上させるために穀物（セクション3.3）を使用することがあります。
Protocol invariants need to be clearly and concisely documented. Including examples of aspects of the protocol that are not invariant, such as Appendix A of [QUIC-INVARIANTS], can be used to clarify intent.
プロトコル不変式は明確かつ簡潔に文書化される必要があります。[QUIC-不変式]の付録Aのような不変のプロトコルの態様の例の例を含めて、意図を明確にするために使用することができます。
Reducing the number of entities that can participate in a protocol or limiting the extent of participation can reduce the number of entities that might affect extensibility. Using TLS or other cryptographic tools can therefore reduce the number of entities that can influence whether new features are usable.
プロトコルに参加できるエンティティの数を減らすか、参加の範囲を制限することで、拡張性に影響を与える可能性があるエンティティの数を減らすことができます。したがって、TLSまたは他の暗号化ツールを使用することで、新機能が使用可能かどうかに影響を与える可能性があるエンティティの数を減らすことができます。
[PATH-SIGNALS] also recommends the use of encryption and integrity protection to limit participation. For example, encryption is used by the QUIC protocol [QUIC] to limit the information that is available to middleboxes and integrity protection prevents modification.
[PATH-SIGNES]参加を制限するための暗号化と整合性保護を使用することをお勧めします。たとえば、中QUICプロトコル[QUIC]によって暗号化が使用され、ミドルボックスが使用できる情報を制限し、完全性保護は変更を防ぎます。
While not a direct means of protecting extensibility mechanisms, feedback systems can be important to discovering problems.
拡張メカニズムを保護する直接の手段ではないが、フィードバックシステムは問題を発見するために重要であり得る。
The visibility of errors is critical to the success of techniques like grease (see Section 3.3). The grease design is most effective if a deployment has a means of detecting and reporting errors. Ignoring errors could allow problems to become entrenched.
誤差の可視性は、グリースのような技術の成功にとって重要です（セクション3.3を参照）。展開にエラーを検出して報告する手段がある場合、グリース設計は最も効果的です。エラーを無視すると、問題が発生する可能性があります。
Feedback on errors is more important during the development and early deployment of a change. It might also be helpful to disable automatic error recovery methods during development.
エラーについてのフィードバックは、変化の開発と早期展開中により重要です。開発中に自動エラー回復方法を無効にするのに役立ちます。
Automated feedback systems are important for automated systems, or where error recovery is also automated. For instance, connection failures with HTTP alternative services [ALT-SVC] are not permitted to affect the outcome of transactions. An automated feedback system for capturing failures in alternative services is therefore necessary for failures to be detected.
自動化されたフィードバックシステムは自動システムにとって重要です。またはエラー回復も自動化されています。たとえば、HTTP代替サービスの接続障害[ALT-SVC]は、トランザクションの結果に影響を与えることは許可されていません。したがって、代替サービスの障害をキャプチャするための自動フィードバックシステムは、障害が検出されるために必要である。
How errors are gathered and reported will depend greatly on the nature of the protocol deployment and the entity that receives the report. For instance, end users, developers, and network operations each have different requirements for how error reports are created, managed, and acted upon.
エラーが収集され報告され、報告された方法は、プロトコルの展開の性質とレポートを受信するエンティティに大きく依存します。たとえば、エンドユーザー、開発者、およびネットワーク操作には、エラーレポートがどのように作成、管理、および実行されるかについて異なります。
Automated delivery of error reports can be critical for rectifying deployment errors as early as possible, as seen in [DMARC] and [SMTP-TLS-REPORTING].
[DMARC]および[SMTP-TLSレポート]に見られるように、展開エラーをできるだけ早く整理するために、エラー報告の自動配信が重要です。
Many of the problems identified in this document are not the result of deliberate actions by an adversary but more the result of mistakes, decisions made without sufficient context, or simple neglect, i.e., problems therefore not the result of opposition by an adversary. In response, the recommended measures generally assume that other protocol participants will not take deliberate action to prevent protocol evolution.
この文書で特定された問題の多くは、敵対者による意図的な行動の結果ではありませんが、間違いの結果、十分な文脈なしに行われた決定、すなわち、敵対者による反対の結果ではありません。それに応じて、推奨される措置は一般に、他のプロトコル参加者がプロトコルの進化を防ぐために意図的な処置を受けないと仮定します。
The use of cryptographic techniques to exclude potential participants is the only strong measure that the document recommends. However, authorized protocol peers are most often responsible for the identified problems, which can mean that cryptography is insufficient to exclude them.
潜在的な参加者を除外するための暗号化技術の使用は、文書が推奨する唯一の強い測定値です。しかしながら、承認されたプロトコルピアは、識別された問題に対して最も頻繁に責任があるため、暗号化がそれらを除外するのに不十分であることを意味する可能性がある。
The ability to design, implement, and deploy new protocol mechanisms can be critical to security. In particular, it is important to be able to replace cryptographic algorithms over time [AGILITY]. For example, preparing for the replacement of weak hash algorithms was made more difficult through misuse [HASH].
新しいプロトコルメカニズムを設計、実装、および展開する機能は、セキュリティにとって重要です。特に、敏捷性の経過とともに暗号化アルゴリズムを置き換えることができることが重要です。例えば、弱いハッシュアルゴリズムの置き換えの準備は、誤用を通してより困難にされた[ハッシュ]。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, <https://www.rfc-editor.org/info/rfc7696>.
[敏捷性]ホームリー、R.、「暗号化アルゴリズムの敏捷性のためのガイドラインと必須の実施のためのガイドライン」、BCP 201、RFC 7696、DOI 10.17487 / RFC7696、2015年11月、<https：//www.rfc-editor.org/ info / rfc7696>。
[ALPN] 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, <https://www.rfc-editor.org/info/rfc7301>.
[ALPN] Friedl、S.、Popov、A.、Langley、A.、およびE.Stethan、「トランスポート層セキュリティ（TLS）アプリケーション層プロトコルネゴシエーション拡張」、RFC 7301、DOI 10.17487 / RFC7301、2014年7月、<https://www.rfc-editor.org/info/rfc7301>。
[ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[ALT-SVC]ノッティンガム、M.、McManus、P.、J. Reschke、RFC 7838、DOI 10.17487 / RFC7838、2016年4月、<https：//www.rfc-editor.org/情報/ RFC7838>。
[DIAMETER] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <https://www.rfc-editor.org/info/rfc6733>.
[直径] Fajardo、V.、Ed。、Arkko、J.、Loughney、J.、およびG. Zorn、Ed。、「Diameter Base Protocol」、RFC 6733、DOI 10.17487 / RFC6733、2012年10月、<https：//ww.rfc-editor.org/info/rfc6733>。
[DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.
[DMARC] Kucherawy、M.、ED。E. Zwicky、Ed。、「ドメインベースのメッセージ認証、報告、および適合性（DMARC）」、RFC 7489、DOI 10.17487 / RFC7489、2015年3月、<https：//www.rfc-editor.org/info/RFC7489>。
[DNSFLAGDAY] "DNS Flag Day 2019", May 2019, <https://dnsflagday.net/2019/>.
[DNSFLAGDAY]「DNS Flag Day 2019」、2019年5月、<https：//dnsflagday.net/2019/>。
[EDNS] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, <https://www.rfc-editor.org/info/rfc6891>.
[EDNS] Damas、J.、Graff、M.、およびP.Vixie、「DNSの拡張メカニズム（EDNS（0））」、STD 75、RFC 6891、DOI 10.17487 / RFC6891、2013年4月、<https：//www.rfc-editor.org/info/rfc6891>。
[EXT-TCP] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M., and H. Tokuda, "Is it still possible to extend TCP?", IMC '11: Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference, DOI 10.1145/2068816.2068834, November 2011, <https://doi.org/10.1145/2068816.2068834>.
[EXT-TCP]ホンダ、M、西田、Y。、RaiCyu、C.、Greenhalgh、A.、Handley、M.、およびH. Tokuda、「TCPを拡張することはまだ可能ですか？」、IMC '11：2011年インターネット測定会議、DOI 10.1145 / 2068816.2068834、2011年11月、<https://doi.org/10.1145/2068866.2068834>。
[EXTENSIBILITY] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, September 2012, <https://www.rfc-editor.org/info/rfc6709>.
[拡張性]大工、B.、ABOBA、B、B.、ED。、およびS.チェシャー、「プロトコル拡張の設計上の考慮事項」、RFC 6709、DOI 10.17487 / RFC6709、2012年9月、<https：///www.rfc-編集者.ORG / INFO / RFC6709>。
[GREASE] Benjamin, D., "Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility", RFC 8701, DOI 10.17487/RFC8701, January 2020, <https://www.rfc-editor.org/info/rfc8701>.
[グリース]ベンジャミン、D.、「ランダムエクステンションを生成し、Sustain Extensibility（Grease）への伸び率（グリース）を伸ばす（グリース）、DOI 10.17487 / RFC8701、2020年1月、<https：//www.rfc-editor.org/info/RFC8701>。
[HASH] Bellovin, S. and E. Rescorla, "Deploying a New Hash Algorithm", Proceedings of NDSS, 2006, <https://www.cs.columbia.edu/~smb/papers/new-hash.pdf>.
[HASH] Bellovin、S.およびE. Rescorla、「新しいハッシュアルゴリズムの展開」、NDSS、2006年、<https://www.cs.columbia.edu/~smb/papers/new-hash.pdf>。
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", Work in Progress, Internet-Draft, draft-ietf-httpbis-semantics-19, September 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-19>.
[HTTP]フィールド、R.、ED、Nottingham、M.、Ed。、J.Reschke、Ed。、「HTTP Semantics」、進行中の作業、インターネットドラフト、romp-ietf-httpbis-semantics-19、2021年9月、<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-19>。
[HTTP-HEADERS] Nottingham, M. and P-H. Kamp, "Structured Field Values for HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, <https://www.rfc-editor.org/info/rfc8941>.
[HTTP-HEADERS]ノッティンガム、M.およびP-H。Kamp、「HTTPの構造化フィールド値」、RFC 8941、DOI 10.17487 / RFC8941、2021年2月、<https：//www.rfc-editor.org/info/rfc8941>。
[HTTP11] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf-httpbis-messaging-19, September 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-messaging-19>.
[HTTP11]フィールド、R.、ED、Nottingham、M.、Ed。、J.Reschke、Ed。、 "HTTP / 1.1"、進行中の作業、インターネットドラフト、ドラフト - IETF-HTTPBIS-19、2021年9月、<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-messaging-19>。
[INTOLERANCE] Kario, H., "Re: [TLS] Thoughts on Version Intolerance", July 2016, <https://mailarchive.ietf.org/arch/msg/tls/ bOJ2JQc3HjAHFFWCiNTIb0JuMZc>.
[Intolerance] Kario、H.、 "RE：[TLS]バージョンIntoleranceについての考え"、2016年7月、<https：//mailarchive.ietf.org/arch/msg/tls/ boj2jqc3hjahffwcintib0jumzc>。
[MPTCP] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 2020, <https://www.rfc-editor.org/info/rfc8684>.
[MPTCP]フォード、A.、RaiCy、C.、Handley、M.、Bonaventure、O.、およびC. PaaSch、RFC 8684、DOI 10.17487 / RFC8684、2020年3月、<https://www.rfc-editor.org/info/rfc8684>。
[MPTCP-HOW-HARD] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M., Duchene, F., Bonaventure, O., and M. Handley, "How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP", April 2012, <https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu>.
[MPTCP-HOW-HARD] RAICIU、C。、PAASCH、C.、Barre、S.、Ford、A。、Honda、M.、Duchene、F.、Bonaventure、O.、およびM. Handley "展開可能なマルチパスTCPの設計と実装、2012年4月、<https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu>。
[NEW-PROTOCOLS] Barik, R., Welzl, M., Fairhurst, G., Elmokashfi, A., Dreibholz, T., and S. Gjessing, "On the usability of transport protocols other than TCP: A home gateway and internet path traversal study", Computer Networks, Vol. 173, pp. 107211, DOI 10.1016/j.comnet.2020.107211, May 2020, <https://doi.org/10.1016/j.comnet.2020.107211>.
[新規プロトコル] Barik、R.、Welzl、M.、Fairhurst、G.、Elmokashfi、A.、Dreibholz、T.、およびS. Gjessing、TCP以外のトランスポートプロトコルの使いやすさ：ホームゲートウェイとインターネットパストラバーサルスタディ「コンピュータネットワーク、Vol。173、PP。107211、DOI 10.1016 / J.com 2020.107211、2020年5月、<https：//doi.org/10.1016/j.jp.2020.107211>。
[PATH-SIGNALS] Hardie, T., Ed., "Transport Protocol Path Signals", RFC 8558, DOI 10.17487/RFC8558, April 2019, <https://www.rfc-editor.org/info/rfc8558>.
[PATH-SIGNES]、T.、ED。、「トランスポートプロトコルパス信号」、RFC 8558、DOI 10.17487 / RFC8558、2019年4月、<https：//www.rfc-editor.org/info/rfc8558>。
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[QUIC] Iyngar、J.、ED。M. Thomson、ED。、「QUIC：UDPベースの多重化および安全な輸送」、RFC 9000、DOI 10.17487 / RFC9000、2021年5月、<https：//www.rfc-editor.org/info/rfc9000>。
[QUIC-INVARIANTS] Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, May 2021, <https://www.rfc-editor.org/info/rfc8999>.
[QUIC-不変の] Thomson、M。、「QUICのバージョン非依存のプロパティ」、RFC 8999、DOI 10.17487 / RFC8999、2021年5月、<https：//www.rfc-editor.org/info/rfc8999>。
[RAv4] Katz, D., "IP Router Alert Option", RFC 2113, DOI 10.17487/RFC2113, February 1997, <https://www.rfc-editor.org/info/rfc2113>.
[RAV4] Katz、D.、「IP Router Alert Option」、RFC 2113、DOI 10.17487 / RFC2113、1997年2月、<https：//www.rfc-editor.org/info/rfc2113>。
[RAv6] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, DOI 10.17487/RFC2711, October 1999, <https://www.rfc-editor.org/info/rfc2711>.
[RAV6]パーリッジ、CおよびA.ジャクソン、「IPv6ルータアラートオプション」、RFC 2711、DOI 10.17487 / RFC2711、1999年10月、<https：//www.rfc-editor.org/info/rfc2711>。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC0791] Postel、J.、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<https：//www.rfc-editor.org/info/rfc791>。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <https://www.rfc-editor.org/info/rfc1112>.
[RFC1112]「IPマルチキャスト用のホスト拡張」、STD 5、RFC 1112、DOI 10.17487 / RFC1112、<https://www.rfc-editor.org/info/rfc1112>。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, <https://www.rfc-editor.org/info/rfc2464>.
[RFC2464] Crawford、M。、「イーサネットネットワークを介したIPv6パケットの送信」、RFC 2464、DOI 10.17487 / RFC2464、1998年12月、<https：//www.rfc-editor.org/info/rfc2464>。
[RFC5704] Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated Protocol Development Considered Harmful", RFC 5704, DOI 10.17487/RFC5704, November 2009, <https://www.rfc-editor.org/info/rfc5704>.
[RFC5704]ブライアント、S、ED。、明日、M.、ED。、およびIAB、「アンサーインされていないプロトコル開発は有害なもの」、RFC 5704、DOI 10.17487 / RFC5704、2009年11月、<https：///www.rfc-editor.org/info/rfc5704>。
[RRTYPE] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, <https://www.rfc-editor.org/info/rfc3597>.
[RRType] Gustafsson、A。、「未知のDNSリソースレコード（RR）型の処理」、RFC 3597、DOI 10.17487 / RFC3597、2003年9月、<https：//www.rfc-editor.org/info/rfc3597>。
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[SIP] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、Sip：セッション開始プロトコル、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https：//www.rfc-editor.org/info/rfc3261>。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.
[SMTP] Klensin、J.、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487 / RFC5321、2008年10月、<https：//www.rfc-editor.org/info/rfc5321>。
[SMTP-TLS-REPORTING] Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J., and M. Risher, "SMTP TLS Reporting", RFC 8460, DOI 10.17487/RFC8460, September 2018, <https://www.rfc-editor.org/info/rfc8460>.
[SMTP-TLS報告]マルゴリス、D.、Brotman、A.、Ramakrishnan、B.、Jones、J.、およびM.Risher、「SMTP TLSレポート」、RFC 8460、DOI 10.17487 / RFC8460、2018年9月、<https://www.rfc-editor.org/info/rfc8460>。
[SNI] Langley, A., "[TLS] Accepting that other SNI name types will never work.", March 2016, <https://mailarchive.ietf.org/arch/msg/ tls/1t79gzNItZd71DwwoaqcQQ_4Yxc>.
[SNI] Langley、A。、「他のSNI名の種類が決して働かないことを受け入れます。2016年3月、<https：//mailarchive.ietf.org/arch/msg/tls / 1t79gznitzd71dwwoaqqq_4yxc>。
[SNMPv1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", RFC 1157, DOI 10.17487/RFC1157, May 1990, <https://www.rfc-editor.org/info/rfc1157>.
[SNMPV1]ケース、J.、Fedor、M.、Schoffstall、M.、およびJ.Davin、「Simple Network Management Protocol（SNMP）」、RFC 1157、DOI 10.17487 / RFC1157、<https：// www.rfc-editor.org / info / rfc1157>。
[SPF] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>.
[SPF]キタマン、S.、電子メールのドメインの使用、バージョン1 "、RFC 7208、DOI 10.17487 / RFC7208、2014年4月、<https://ww.rfc-editor.org/ info / rfc7208>。
[SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, <https://www.rfc-editor.org/info/rfc5218>.
[成功] Thaler、D.およびB. Aboba、「正常なプロトコルのために何が成功するのか」、RFC 5218、DOI 10.17487 / RFC5218、2008年7月、<https://www.rfc-editor.org/info/rfc5218>。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[TCP] Postel、J.、 "Transmission Control Protocol"、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https：//www.rfc-editor.org/info/rfc793>。
[TFO] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, <https://www.rfc-editor.org/info/rfc7413>.
[TFO] Cheng、Y.、Chu、J.、Radhakrishnan、S.、A. Jain、 "TCP Fast Open"、RFC 7413、DOI 10.17487 / RFC7413、2014年12月、<https：///www.rfc-編集者.ORG / INFO / RFC7413>。
[TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[TLS-EXT]イーストレイク3RD、D。、「トランスポートレイヤセキュリティ（TLS）エクステンション：拡張定義」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<https：//www.rfc-editor.org/info/RFC6066>。
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[TLS12] Dierks、T.およびE. Rescorla、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https：//www.rfc-editor.org/info/ RFC5246>。
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[TLS13] RESCORLA、E。、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[TRANSITIONS] Thaler, D., Ed., "Planning for Protocol Adoption and Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, May 2017, <https://www.rfc-editor.org/info/rfc8170>.
[遷移] Thaler、D.、ED。、「プロトコル採用およびその後の遷移の計画」、RFC 8170、DOI 10.17487 / RFC8170、<https：//www.rfc-editor.org/info/rfc8170>。
This appendix contains a brief study of problems in a range of Internet protocols at different layers of the stack.
この付録には、スタックの異なる層のある範囲のインターネットプロトコルの問題に関する簡単な検討が含まれています。
Ossified DNS code bases and systems resulted in new Resource Record Codes (RRCodes) being unusable. A new code point would take years of coordination between implementations and deployments before it could be relied upon. Consequently, use of the TXT record was overloaded in order to avoid the effort and delays involved in allocating new code points; this approach was used in the Sender Policy Framework [SPF] and other protocols.
省略されたDNSコードベースおよびシステムは、新しいリソースレコードコード（RRコード）をもたらしたシステム（RRコード）が使用できない。新しいコードポイントは、それが信頼される前に実装と展開の間の調整を受けます。その結果、新しいコードポイントの割り当てに関わる努力と遅延を回避するために、TXTレコードを使用していました。このアプローチは、送信者ポリシーフレームワーク[SPF]および他のプロトコルで使用されていました。
It was not until after the standard mechanism for dealing with new RRCodes [RRTYPE] was considered widely deployed that new RRCodes could be safely created and used.
新しいRRコードを扱うための標準メカニズムが、新しいRRコードを安全に作成して使用できることを広く展開されていると見なされたことはありませんでした。
HTTP has a number of very effective extension points in addition to the aforementioned header fields. It also has some examples of extension points that are so rarely used that it is possible that they are not at all usable.
HTTPには、前述のヘッダーフィールドに加えて、非常に効果的な拡張ポイントがいくつかあります。それはまたそれらがすべて使用可能ではないことが可能であることが可能であることがめったに使用されない延長点のいくつかの例を有する。
Extension points in HTTP that might be unwise to use include the extension point on each chunk in the chunked transfer coding (Section 7.1 of [HTTP11]), the ability to use transfer codings other than the chunked coding, and the range unit in a range request (Section 14 of [HTTP]).
HTTP内の拡張ポイントは、チャンクされた転送符号化（[HTTP11]のセクション7.1）の各チャンクの拡張ポイント、チャンクされたコーディング以外の転送コーディング、および範囲内の範囲単位を使用する機能を含みます。リクエスト（[HTTP]のセクション14）。
The version field in IP was rendered useless when encapsulated over Ethernet, requiring a new EtherType with IPv6 [RFC2464], due in part to Layer 2 devices making version-independent assumptions about the structure of the IPv4 header.
イーサネットを介してカプセル化されている場合、IPのバージョンフィールドは、IPv4ヘッダーの構造に関するバージョンに依存しない仮定を作成するために、IPv6 [RFC2464]を持つ新しいEtherTypeを必要とします。
Protocol identifiers or code points that are reserved for future use can be especially problematic. Reserving values without attributing semantics to their use can result in diverse or conflicting semantics being attributed without any hope of interoperability. An example of this is the 224/3 address space in IPv4 that [RFC0791] reserved without assigning any semantics. [RFC1112] partially reclaimed that reserved address space for use in multicast (224/4), but the remaining address space (240/4) has not been successfully reclaimed for any purpose.
将来の使用のために予約されているプロトコル識別子またはコードポイントは、特に問題がある可能性があります。セマンティクスを使用することなく値を予約すると、相互運用性の希望なしに、多様なまたは矛盾するセマンティクスが発生する可能性があります。この例は、IPv4の224/3アドレス空間です。[RFC1112]マルチキャスト（224/4）で使用するための予約されたアドレス空間を部分的に再生するが、残りのアドレス空間（240/4）は任意の目的のために首尾よく再利用されていない。
For protocols that can use negotiation to attribute semantics to values, it is possible that unused code points can be reclaimed for active use, though this requires that the negotiation include all protocol participants. For something as fundamental as addressing, negotiation is difficult or even impossible, as all nodes on the network path plus potential alternative paths would need to be involved.
属性セマンティクスに値を使用できるプロトコルの場合、未使用のコードポイントをアクティブな使用に取り戻すことができる可能性がありますが、ネゴシエーションにはすべてのプロトコル参加者が含まれます。ネットワークパス上のすべてのノードと潜在的な代替パスが関与する必要があるため、交渉は困難であるか、または不可能でさえ不可能です。
IP Router Alerts [RAv4][RAv6] use IP options or extension headers to indicate that data is intended for consumption by the next-hop router rather than the addressed destination. In part, the deployment of router alerts was unsuccessful due to the realities of processing IP packets at line rates, combined with bad assumptions in the protocol design about these performance constraints. However, this was not exclusively down to design problems or bugs, as the capability was also deliberately blocked at some routers.
IP Router Alerts [RAV4] [RAV6] IPオプションまたは拡張ヘッダーを使用して、データがアドレス指定された宛先ではなくネクストホップルータによる消費を目的としていることを示します。一部では、これらのパフォーマンス上の制約に関するプロトコル設計の不良仮定と組み合わされた、ラインレートでIPパケットを処理することの現実により、ルータアラートの展開が失敗しました。ただし、これは能力がいくつかのルータでも意図的にブロックされていたため、これは排他的な問題やバグには削除されませんでした。
As a counter example, the first version of the Simple Network Management Protocol (SNMP) [SNMPv1] states that unparseable or unauthenticated messages are simply discarded without response:
対策例として、単純なネットワーク管理プロトコル（SNMPV1）の最初のバージョンは、解析不可または認証されていないメッセージが応答なしに廃棄されることを示しています。
| It then verifies the version number of the SNMP message. If there
| is a mismatch, it discards the datagram and performs no further
| actions.
When SNMP versions 2, 2c, and 3 came along, older agents did exactly what the protocol specifies. Deployment of new versions was likely successful because the handling of newer versions was both clear and simple.
SNMPバージョン2,2C、および3が登場すると、古いエージェントはプロトコルが指定するものを正確にしました。新しいバージョンの展開は、新しいバージョンの処理が明確で単純であるため、成功した可能性があります。
Extension points in TCP [TCP] have been rendered difficult to use largely due to middlebox interactions; see [EXT-TCP].
TCP [TCP]の拡張ポイントは、ミドルボックスの対話のために主に使用するのが難しくされています。[ext-tcp]を参照してください。
For instance, multipath TCP ([MPTCP]) can only be deployed opportunistically; see [MPTCP-HOW-HARD]. Since MPTCP is a protocol enhancement that doesn't impair the connection if it is blocked, network path intolerance of the extension only results in the multipath functionality becoming unavailable.
たとえば、マルチパスTCP（[MPTCP]）は日和見主義のみを展開できます。[MPTCP-HARD]を参照してください。MPTCPは、接続をブロックしていれば接続を損なわないプロトコル機能強化であるため、拡張子のネットワークパスの侵入はマルチパス機能が利用できなくなります。
In comparison, the deployment of TCP Fast Open ([TFO]) critically depends on extension capability being widely available. Though very few network paths were intolerant of the extension in absolute terms, TCP Fast Open could not be deployed as a result.
比較すると、TCP Fast Open（[TFO]）の展開は、広く利用可能である拡張機能に依存します。ネットワークパスは絶対的な用語の拡張に耐えられていたが、結果としてTCP Fast Openを展開できませんでした。
Transport Layer Security (TLS) [TLS12] provides examples of where a design that is objectively sound fails when incorrectly implemented. TLS provides examples of failures in protocol version negotiation and extensibility.
トランスポート層セキュリティ（TLS）[TLS12]は、誤って実装されたときに客観的に音が鳴るデザインが失敗した場所の例を示しています。TLSは、プロトコルバージョンのネゴシエーションと拡張性の障害の例を示しています。
Version negotiation in TLS 1.2 and earlier uses the "Highest mutually supported version (HMSV)" scheme exactly as it is described in [EXTENSIBILITY]. However, clients are unable to advertise a new version without causing a non-trivial proportion of sessions to fail due to bugs in server and middlebox implementations.
TLS 1.2以前のバージョンネゴシエーションは、[Extensibility]で説明されているとおりに「最高の相互にサポートされているバージョン（HMSV）」方式を使用します。ただし、サーバーとミドルボックスの実装のバグのために、些細な割合のセッションが失敗することなく、クライアントは新しいバージョンを宣伝できません。
Intolerance to new TLS versions is so severe [INTOLERANCE] that TLS 1.3 [TLS13] abandoned HMSV version negotiation for a new mechanism.
新しいTLSバージョンへの不耐性は、そのTLS 1.3 [TLS13]が新しいメカニズムのHMSVバージョンネゴシエーションを放棄した。
The server name indication (SNI) [TLS-EXT] in TLS is another excellent example of the failure of a well-designed extensibility point. SNI uses the same technique for extensions that is used successfully in other parts of the TLS protocol. The original design of SNI anticipated the ability to include multiple names of different types.
TLSのサーバー名指示（SNI）[TLS-EXT]は、よく設計された拡張ポイントの障害の優れた例です。SNIは、TLSプロトコルの他の部分で正常に使用される拡張機能に同じ手法を使用します。SNIの元の設計は、さまざまな種類の複数の名前を含む能力を予想していました。
SNI was originally defined with just one type of name: a domain name. No other type has ever been standardized, though several have been proposed. Despite an otherwise exemplary design, SNI is so inconsistently implemented that any hope for using the extension point it defines has been abandoned [SNI].
SNIは最初に1つのタイプの名前だけで定義されていました。ドメイン名。いくつか提案されていますが、他のタイプは標準化されていません。そうでない例示的な設計にもかかわらず、SNIはその延長点を使用することに対する希望があらゆる希望が放棄されていることを矛盾する。
IAB Members at the Time of Approval
承認時のIABメンバー
Internet Architecture Board members at the time this document was approved for publication were:
インターネットアーキテクチャボードメンバーこの文書が出版のために承認された時点では、次のとおりです。
Jari Arkko Deborah Brungard Ben Campbell Lars Eggert Wes Hardaker Cullen Jennings Mirja Kühlewind Zhenbin Li Jared Mauch Tommy Pauly David Schinazi Russ White Jiankang Yao
Jari Arkko Deborah Brungard Ben Campbell Lars Eggert Wes Hardaker Cullen JenningsMirjaKühlewindZhenbin Li Jared Mauch Tommy Pauly David Schinazi Russ White Jiankang Yao
Acknowledgments
謝辞
Toerless Eckert, Wes Hardaker, Mirja Kühlewind, Eliot Lear, Mark Nottingham, and Brian Trammell made significant contributions to this document.
TOERLESS ECKERT、WESの賢明な、MirjaKühlewind、Eliot Lear、Mark Nottingham、Brian Trammellはこの文書に大きな貢献をしました。
Authors' Addresses
著者の住所
Martin Thomson
マーティントムソン
Email: mt@lowentropy.net
Tommy Pauly
トミーポーリー
Email: tpauly@apple.com