[要約] RFC 6709は、プロトコル拡張の設計に関する考慮事項をまとめたものであり、プロトコルの拡張性と互換性を向上させることを目的としています。
Internet Architecture Board (IAB) B. Carpenter
Request for Comments: 6709 B. Aboba, Ed.
Category: Informational S. Cheshire
ISSN: 2070-1721 September 2012
Design Considerations for Protocol Extensions
プロトコル拡張の設計上の考慮事項
Abstract
概要
This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols.
このドキュメントでは、設計上の考慮事項に重点を置いて、インターネットプロトコルの拡張性に関連するアーキテクチャの問題について説明します。基本プロトコルと拡張機能の両方の設計者を支援することを目的としています。ケーススタディが含まれています。関連ドキュメントであるRFC 4775（BCP 125）では、IETFプロトコルの拡張性に関連する手順について説明しています。
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 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6709.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6709で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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 ....................................................3
1.1. Requirements Language ......................................4
2. Routine and Major Extensions ....................................4
2.1. What Constitutes a Major Extension? ........................4
2.2. When is an Extension Routine? ..............................6
3. Architectural Principles ........................................7
3.1. Limited Extensibility ......................................7
3.2. Design for Global Interoperability .........................8
3.3. Architectural Compatibility ...............................12
3.4. Protocol Variations .......................................13
3.5. Testability ...............................................16
3.6. Protocol Parameter Registration ...........................16
3.7. Extensions to Critical Protocols ..........................17
4. Considerations for the Base Protocol ...........................18
4.1. Version Numbers ...........................................19
4.2. Reserved Fields ...........................................22
4.3. Encoding Formats ..........................................23
4.4. Parameter Space Design ....................................23
4.5. Cryptographic Agility .....................................26
4.6. Transport .................................................27
4.7. Handling of Unknown Extensions ............................28
5. Security Considerations ........................................29
6. References .....................................................30
6.1. Normative References ......................................30
6.2. Informative References ....................................30
7. Acknowledgments ................................................35
8. IAB Members at the Time of Approval ............................35
Appendix A. Examples .............................................36
A.1. Already-Documented Cases ..................................36
A.2. RADIUS Extensions .........................................36
A.3. TLS Extensions ............................................39
A.4. L2TP Extensions ...........................................41
When developing protocols, IETF Working Groups (WGs) often include mechanisms whereby these protocols can be extended in the future. It is often a good principle to design extensibility into protocols; as described in "What Makes for a Successful Protocol" [RFC5218], a "wildly successful" protocol is one that becomes widely used in ways not originally anticipated. Well-designed extensibility mechanisms facilitate the evolution of protocols and help make it easier to roll out incremental changes in an interoperable fashion. However, at the same time, experience has shown that extensions carry the risk of unintended consequences, such as interoperability issues, operational problems, or security vulnerabilities.
プロトコルを開発する場合、IETFワーキンググループ（WG）には、これらのプロトコルを将来拡張できるメカニズムが含まれていることがよくあります。プロトコルへの拡張性を設計することは、多くの場合良い原則です。 「成功するプロトコルの原因」[RFC5218]で説明されているように、「非常に成功する」プロトコルは、当初予想されていなかった方法で広く使用されるようになるプロトコルです。適切に設計された拡張メカニズムは、プロトコルの進化を促進し、相互運用可能な方法で増分変更を簡単にロールアウトできるようにします。ただし、同時に、拡張機能には、相互運用性の問題、運用上の問題、またはセキュリティの脆弱性などの意図しない結果のリスクがあることが経験上示されています。
The proliferation of extensions, even well-designed ones, can be costly. As noted in "Simple Mail Transfer Protocol" [RFC5321] Section 2.2.1:
拡張機能の拡散は、適切に設計されたものであっても、コストがかかる可能性があります。 「Simple Mail Transfer Protocol」[RFC5321]セクション2.2.1に記載されているとおり：
Experience with many protocols has shown that protocols with few options tend towards ubiquity, whereas protocols with many options tend towards obscurity.
多くのプロトコルの経験から、オプションの少ないプロトコルは遍在する傾向があるのに対し、オプションの多いプロトコルは不明瞭になる傾向があります。
Each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs.
それぞれの拡張機能は、その利点に関係なく、その実装、展開、および相互運用性のコストに関して慎重に精査する必要があります。
This is hardly a recent concern. "TCP Extensions Considered Harmful" [RFC1263] was published in 1991. "Extend" or "extension" occurs in the title of more than 400 existing Request for Comments (RFC) documents. Yet, generic extension considerations have not been documented previously.
これは最近の懸念ではありません。 「有害なTCP拡張機能」[RFC1263]は1991年に公開されました。「拡張」または「拡張機能」は、400を超える既存のRequest for Comments（RFC）ドキュメントのタイトルで発生します。ただし、拡張機能に関する一般的な考慮事項はこれまでに文書化されていません。
The purpose of this document is to describe the architectural principles of sound extensibility design, in order to minimize such risks. Formal procedures for extending IETF protocols are discussed in "Procedures for Protocol Extensions and Variations" BCP 125 [RFC4775].
このドキュメントの目的は、このようなリスクを最小限に抑えるために、適切な拡張性設計のアーキテクチャの原則を説明することです。 IETFプロトコルを拡張するための正式な手順については、「プロトコルの拡張とバリエーションの手順」BCP 125 [RFC4775]で説明しています。
The rest of this document is organized as follows: Section 2 discusses routine and major extensions. Section 3 describes architectural principles for protocol extensibility. Section 4 explains how designers of base protocols can take steps to anticipate and facilitate the creation of such subsequent extensions in a safe and reliable manner. Section 5 discusses security considerations. Appendix A provides case studies.
このドキュメントの残りの部分は、次のように構成されています。セクション2では、日常的な拡張と主要な拡張について説明します。セクション3では、プロトコルの拡張性に関するアーキテクチャの原則について説明します。セクション4では、基本プロトコルの設計者が、このような後続の拡張機能の作成を安全かつ信頼できる方法で予測および促進するための手順をどのように実行できるかについて説明します。セクション5では、セキュリティに関する考慮事項について説明します。付録Aにケーススタディを示します。
Readers are advised to study the whole document, since the considerations are closely linked.
考慮事項は密接に関連しているため、読者はドキュメント全体を検討することをお勧めします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" BCP 14 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 「要件レベルを示すRFCで使用するキーワード」BCP 14 [RFC2119]で説明されているように解釈されます。
The risk of unintended consequences from an extension is especially high if the extension is performed by a different team than the original designers, who may stray outside implicit design constraints or assumptions. As a result, it is highly desirable for the original designers to articulate the design constraints and assumptions, so as to enable extensions to be done carefully and with a full understanding of the base protocol, existing implementations, and current operational practice.
拡張機能が意図しない結果を引き起こす可能性は、拡張機能が元の設計者とは異なるチームによって実行された場合に特に高くなります。その結果、基本プロトコル、既存の実装、および現在の運用方法を十分に理解して拡張を慎重に実行できるように、元の設計者が設計の制約と仮定を明確にすることが非常に望ましいです。
To assist extension designers and reviewers, protocol documents should provide guidelines explaining how extensions should be performed, and guidance on how protocol extension mechanisms should be used.
拡張機能の設計者とレビュー担当者を支援するために、プロトコルドキュメントは、拡張機能の実行方法を説明するガイドラインと、プロトコル拡張機能メカニズムの使用方法に関するガイダンスを提供する必要があります。
Protocol components that are designed with the specific intention of allowing extensibility should be clearly identified, with specific and complete instructions on how to extend them. This includes the process for adequate review of extension proposals: do they need community review, and if so, how much and by whom?
拡張性を可能にするという特定の目的で設計されたプロトコルコンポーネントは、それらを拡張する方法に関する具体的かつ完全な指示とともに、明確に識別される必要があります。これには、エクステンションの提案を適切にレビューするプロセスが含まれます。コミュニティのレビューが必要ですか？必要な場合は、どの程度、誰がレビューしますか？
The level of review required for protocol extensions will typically vary based on the nature of the extension. Routine extensions may require minimal review, while major extensions may require wide review. Guidance on which extensions may be considered 'routine' and which ones are 'major' is provided in the sections that follow.
プロトコル拡張に必要なレビューのレベルは、通常、拡張の性質によって異なります。ルーチン拡張は最小限のレビューが必要な場合がありますが、メジャー拡張は幅広いレビューが必要な場合があります。次のセクションでは、「ルーチン」と見なすことができる拡張機能と「メジャー」である拡張機能のガイダンスを示します。
Major extensions may have characteristics leading to a risk of interoperability failures, security vulnerabilities, or operational problems. Where these characteristics are present, it is necessary to pay close attention to backward compatibility with implementations and deployments of the unextended protocol and to the potential for inadvertent introduction of security or operational exposures.
主要な拡張機能には、相互運用性の障害、セキュリティの脆弱性、または運用上の問題のリスクにつながる特性がある場合があります。これらの特性が存在する場合、拡張されていないプロトコルの実装および展開との下位互換性、およびセキュリティまたは運用上の危険性の不注意による導入の可能性に細心の注意を払う必要があります。
Extension designers should examine their design for the following issues:
拡張機能の設計者は、次の問題について設計を検討する必要があります。
1. Modifications or extensions to the underlying protocol. An extension document should be considered to update the underlying protocol specification if an implementation of the underlying protocol would need to be updated to accommodate the extension. This should not be necessary if the underlying protocol was designed with a modular interface. Examples of extensions modifying the underlying protocol include specification of additional transports (see Section 4.6), changing protocol semantics, or defining new message types that may require implementation changes in existing and deployed implementations of the protocol, even if they do not want to make use of the new functions. A base protocol that does not uniformly permit "silent discard" of unknown extensions may automatically enter this category, even for apparently minor extensions. Handling of "unknown" extensions is discussed in more detail in Section 4.7.
1. 基になるプロトコルの変更または拡張。拡張機能に対応するために基礎となるプロトコルの実装を更新する必要がある場合、拡張ドキュメントは、基礎となるプロトコル仕様を更新すると見なされます。基になるプロトコルがモジュラーインターフェイスで設計されている場合、これは必要ありません。基礎となるプロトコルを変更する拡張の例には、追加のトランスポートの仕様（セクション4.6を参照）、プロトコルのセマンティクスの変更、またはプロトコルの既存およびデプロイ済み実装の実装変更が必要な場合でも、それらを使用したくない場合でも、新しいメッセージタイプの定義が含まれます。新機能の。不明な拡張機能の「サイレント破棄」を統一的に許可しない基本プロトコルは、明らかにマイナーな拡張機能であっても、自動的にこのカテゴリに入る場合があります。 「不明な」拡張の処理については、セクション4.7で詳しく説明します。
2. Changes to the basic architectural assumptions. This may include architectural assumptions that are explicitly stated or those that have been assumed by implementers. For example, this would include adding a requirement for session state to a previously stateless protocol.
2. 基本的なアーキテクチャの前提条件の変更。これには、明示的に述べられているアーキテクチャ上の想定や、実装者によって想定されているものを含めることができます。たとえば、これには、以前のステートレスプロトコルにセッション状態の要件を追加することが含まれます。
3. New usage scenarios not originally intended or investigated. This can potentially lead to operational difficulties when deployed, even in cases where the "on-the-wire" format has not changed. For example, the level of traffic carried by the protocol may increase substantially, packet sizes may increase, and implementation algorithms that are widely deployed may not scale sufficiently or otherwise be up to the new task at hand. For example, a new DNS Resource Record (RR) type that is too big to fit into a single UDP packet could cause interoperability problems with existing DNS clients and servers. Similarly, the additional traffic that results from an extension to a routing protocol could have a detrimental impact on the performance or stability of implementations that do not implement the extension.
3. 当初は意図も調査もされていなかった新しい使用シナリオ。これにより、「オンザワイヤー」形式が変更されていない場合でも、展開時に運用上の問題が発生する可能性があります。たとえば、プロトコルによって運ばれるトラフィックのレベルが大幅に増加し、パケットサイズが増加し、広く展開されている実装アルゴリズムが十分に拡張されないか、さもなければ新しいタスクに対応できない場合があります。たとえば、大きすぎて単一のUDPパケットに収まらない新しいDNSリソースレコード（RR）タイプは、既存のDNSクライアントおよびサーバーとの相互運用性の問題を引き起こす可能性があります。同様に、ルーティングプロトコルへの拡張から生じる追加のトラフィックは、拡張を実装しない実装のパフォーマンスまたは安定性に悪影響を与える可能性があります。
4. Changes to the extension model. Adverse impacts are very likely if the base protocol contains an extension mechanism and the proposed extension does not fit into the model used to create and define that mechanism. Extensions that have the same properties as those that were anticipated when an extension mechanism was devised are much less likely to be disruptive than extensions that don't fit the model. Also, changes to the extension model itself (including changes limiting further extensibility) can create interoperability problems.
4. 拡張モデルへの変更。基本プロトコルに拡張メカニズムが含まれていて、提案された拡張がそのメカニズムの作成と定義に使用されるモデルに適合しない場合、悪影響が生じる可能性が非常に高くなります。拡張メカニズムが考案されたときに予想されたものと同じプロパティを持つ拡張機能は、モデルに適合しない拡張機能よりも混乱を招く可能性がはるかに低くなります。また、拡張モデル自体への変更（さらなる拡張性を制限する変更を含む）は、相互運用性の問題を引き起こす可能性があります。
5. Changes to protocol syntax. Changes to protocol syntax bring with them the potential for backward-compatibility issues. If at all possible, extensions should be designed for compatibility with existing syntax, so as to avoid interoperability failures.
5. プロトコル構文の変更。プロトコル構文の変更により、下位互換性の問題が発生する可能性があります。可能であれば、既存の構文との互換性を保つように拡張機能を設計し、相互運用性の障害を回避する必要があります。
6. Interrelated extensions to multiple protocols. A set of interrelated extensions to multiple protocols typically carries a greater danger of interoperability issues or incompatibilities than a simple extension. Consequently, it is important that such proposals receive earlier and more in-depth review than unitary extensions.
6. 複数のプロトコルの相互に関連する拡張。複数のプロトコルに対する相互に関連する一連の拡張機能は、通常、単純な拡張機能よりも相互運用性の問題や非互換性の危険性が高くなります。したがって、そのような提案は単一の拡張よりも早く、より詳細なレビューを受けることが重要です。
7. Changes to the security model. Changes to the protocol security model (or even addition of new security mechanisms within an existing framework) can introduce security vulnerabilities or adversely impact operations. Consequently, it is important that such proposals undergo security as well as operational review. Security considerations are discussed in Section 5.
7. セキュリティモデルの変更。プロトコルセキュリティモデルの変更（または既存のフレームワーク内に新しいセキュリティメカニズムを追加すること）は、セキュリティの脆弱性をもたらしたり、運用に悪影響を及ぼしたりする可能性があります。したがって、そのような提案は、セキュリティと運用のレビューを受けることが重要です。セキュリティに関する考慮事項については、セクション5で説明します。
8. Performance impact. An extension that impacts performance can have adverse consequences, particularly if the performance of existing deployments is affected.
8. パフォーマンスへの影響。パフォーマンスに影響を与える拡張機能は、特に既存のデプロイメントのパフォーマンスが影響を受ける場合、悪影響を与える可能性があります。
An extension may be considered 'routine' if it does not meet the criteria for being considered a 'major' extension and if its handling is opaque to the protocol itself (e.g., does not substantially change the pattern of messages and responses). For this to apply, no changes to the base protocol can be required, nor can changes be required to existing and currently deployed implementations, unless they make use of the extension. Furthermore, existing implementations should not be impacted. This typically requires that implementations be able to ignore 'routine' extensions without ill effects.
拡張が「メジャー」拡張と見なされる基準を満たさず、その処理がプロトコル自体に対して不透明である場合（たとえば、メッセージと応答のパターンを実質的に変更しない場合）、拡張は「ルーチン」と見なされます。これを適用するには、拡張機能を使用しない限り、基本プロトコルへの変更は必要ありません。また、既存および現在展開されている実装に変更を加える必要はありません。さらに、既存の実装は影響を受けません。通常、これには、実装が悪影響なしに「ルーチン」拡張を無視できることが必要です。
Examples of routine extensions include the Dynamic Host Configuration Protocol (DHCP) vendor-specific option [RFC2132], Remote Authentication Dial In User Service (RADIUS) Vendor-Specific Attributes [RFC2865], the enterprise Object IDentifier (OID) tree for Management Information Base (MIB) modules, and vendor Multipurpose Internet Mail Extension (MIME) types. Such extensions can safely be made with minimal discussion.
ルーチン拡張の例には、動的ホスト構成プロトコル（DHCP）ベンダー固有オプション[RFC2132]、リモート認証ダイヤルインユーザーサービス（RADIUS）ベンダー固有属性[RFC2865]、管理情報ベースのエンタープライズオブジェクトID（OID）ツリーが含まれます。 （MIB）モジュール、およびベンダーのMultipurpose Internet Mail Extension（MIME）タイプ。そのような拡張は、最小限の議論で安全に行うことができます。
Processes that allow routine extensions with minimal or no review (such as "First Come First Served" (FCFS) allocation [RFC5226]) should be used sparingly. In particular, they should be limited to cases that are unlikely to result in interoperability problems or in security or operational exposures.
最小限のレビューまたはレビューなしのルーチン拡張を許可するプロセス（「先着順」（FCFS）割り当て[RFC5226]など）は慎重に使用する必要があります。特に、相互運用性の問題や、セキュリティや運用上の問題が発生する可能性が低いケースに限定する必要があります。
Experience has shown that even routine extensions may benefit from review by experts. For example, even though DHCP carries opaque data, defining a new option using completely unstructured data may lead to an option that is unnecessarily hard for clients and servers to process.
経験によれば、日常的な拡張でさえ、専門家によるレビューから利益を得る可能性があります。たとえば、DHCPは不透明なデータを伝送しますが、完全に構造化されていないデータを使用して新しいオプションを定義すると、クライアントとサーバーの処理が不必要に困難になる可能性があります。
This section describes basic principles of protocol extensibility:
このセクションでは、プロトコル拡張の基本原則について説明します。
1. Extensibility features should be limited to what is reasonably anticipated when the protocol is developed.
1. 拡張機能は、プロトコルの開発時に合理的に予想されるものに制限する必要があります。
2. Protocol extensions should be designed for global interoperability.
2. プロトコル拡張は、グローバルな相互運用性のために設計する必要があります。
3. Protocol extensions should be architecturally compatible with the base protocol.
3. プロトコル拡張は、基本プロトコルとアーキテクチャ的に互換性がある必要があります。
4. Protocol extension mechanisms should not be used to create incompatible protocol variations.
4. プロトコル拡張メカニズムを使用して、互換性のないプロトコルバリエーションを作成しないでください。
5. Extension mechanisms need to be testable.
5. 拡張メカニズムはテスト可能である必要があります。
6. Protocol parameter assignments need to be coordinated to avoid potential conflicts.
6. プロトコルパラメータの割り当ては、潜在的な競合を回避するために調整する必要があります。
7. Extensions to critical components require special care. A critical component is one whose failure can lead to Internet-wide reliability and security issues or performance degradation.
7. 重要なコンポーネントの拡張には特別な注意が必要です。重要なコンポーネントとは、その障害がインターネット全体の信頼性とセキュリティの問題、またはパフォーマンスの低下につながる可能性があるコンポーネントです。
Protocols should not be made more extensible than clearly necessary at inception, in order to enable optimization along dimensions (e.g., bandwidth, state, memory requirements, deployment time, latency, etc.) important to the most common use cases.
プロトコルは、最も一般的な使用例にとって重要な次元（帯域幅、状態、メモリ要件、展開時間、レイテンシなど）に沿った最適化を可能にするために、開始時に明らかに必要以上に拡張可能にすべきではありません。
The process for defining new extensibility mechanisms should ensure that adequate review of proposed extensions will take place before widespread adoption.
新しい拡張メカニズムを定義するプロセスは、提案された拡張の適切なレビューが広く採用される前に行われることを保証する必要があります。
As noted in "What Makes for a Successful Protocol" [RFC5218], "wildly successful" protocols far exceed their original goals, in terms of scale, purpose (being used in scenarios far beyond the initial design), or both. This implies that all potential uses may not be known at inception. As a result, extensibility mechanisms may need to be revisited as additional use cases reveal themselves. However, this does not imply that an initial design needs to take all potential needs into account at inception.
「成功するプロトコルの原因」[RFC5218]で述べたように、「大成功する」プロトコルは、規模、目的（初期設計をはるかに超えるシナリオで使用されている）、またはその両方の点で元の目標をはるかに超えています。これは、すべての潜在的な用途が最初に知られているわけではないことを意味します。その結果、追加のユースケースが明らかになったため、拡張メカニズムを再検討する必要があるかもしれません。ただし、これは、初期の設計で、開始時にすべての潜在的なニーズを考慮する必要があることを意味するものではありません。
Section 3.1 of "Procedures for Protocol Extensions and Variations" BCP 125 [RFC4775] notes:
「プロトコル拡張およびバリエーションの手順」のセクション3.1 BCP 125 [RFC4775]は次のように記しています。
According to its Mission Statement [RFC3935], the IETF produces high quality, relevant technical and engineering documents, including protocol standards. The mission statement goes on to say that the benefit of these standards to the Internet "is in interoperability - that multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users".
ミッションステートメント[RFC3935]によると、IETFは、プロトコル標準を含む、高品質で関連性のある技術およびエンジニアリングドキュメントを作成しています。ミッションステートメントはさらに、インターネットに対するこれらの標準の利点は「相互運用性にあります-標準を実装する複数の製品がインターネットのユーザーに価値ある機能を提供するために連携して機能できることです」。
One consequence of this mission is that the IETF designs protocols for the single Internet. The IETF expects its protocols to work the same everywhere. Protocol extensions designed for limited environments may be reasonable provided that products with these extensions interoperate with products without the extensions. Extensions that break interoperability are unacceptable when products with and without the extension are mixed. It is the IETF's experience that this tends to happen on the Internet even when the original designers of the extension did not expect this to happen.
この使命の結果の1つは、IETFが単一のインターネット用のプロトコルを設計することです。 IETFは、そのプロトコルがどこでも同じように機能することを期待しています。制限された環境向けに設計されたプロトコル拡張は、これらの拡張機能を備えた製品が拡張機能を備えていない製品と相互運用できる限り、妥当な場合があります。拡張機能のある製品とない製品が混在している場合、相互運用性を損なう拡張機能は受け入れられません。拡張機能の元の設計者がこれが起こることを予期していなかったとしても、これがインターネット上で起こる傾向があるのはIETFの経験です。
Another consequence of this definition of interoperability is that the IETF values the ability to exchange one product implementing a protocol with another. The IETF often specifies mandatory-to-implement functionality as part of its protocols so that there is a core set of functionality sufficient for interoperability that all products implement. The IETF tries to avoid situations where protocols need to be profiled to specify which optional features are required for a given environment, because doing so harms interoperability on the Internet as a whole.
この相互運用性の定義のもう1つの結果は、IETFが、プロトコルを実装する1つの製品を別の製品と交換する機能を重視することです。多くの場合、IETFはプロトコルの一部として必須から実装までの機能を指定しているため、すべての製品が実装する相互運用性に十分な機能のコアセットがあります。 IETFは、インターネット全体の相互運用性を損なうため、特定の環境に必要なオプション機能を指定するためにプロトコルをプロファイルする必要がある状況を回避しようとします。
Since the global Internet is more than a collection of incompatible protocols (or "profiles") for use in separate private networks, implementers supporting extensions in shipping products or multi-site experimental usage must assume that systems will need to interoperate on the global Internet.
グローバルインターネットは、個別のプライベートネットワークで使用するための互換性のないプロトコル（または「プロファイル」）のコレクションにとどまらないため、製品の出荷やマルチサイトの実験的使用における拡張をサポートする実装者は、システムがグローバルインターネット上で相互運用する必要があると想定する必要があります。
A key requirement for interoperable extension design is that the base protocol must be well designed for interoperability and that extensions must have unambiguous semantics. Ideally, the protocol mechanisms for extension and versioning should be sufficiently well described that compatibility can be assessed on paper. Otherwise, when two "private" or "experimental" extensions encounter each other on a public network, unexpected interoperability problems may occur. However, as noted in the Transport Layer Security (TLS) case study (Appendix A.3), it is not sufficient to design extensibility carefully; it also must be implemented carefully.
相互運用可能な拡張設計の重要な要件は、基本プロトコルが相互運用性のために適切に設計されていること、および拡張に明確なセマンティクスが必要であることです。理想的には、拡張とバージョン管理のプロトコルメカニズムは、互換性を紙で評価できるように十分に説明されている必要があります。そうでない場合、2つの「プライベート」または「実験的」拡張機能がパブリックネットワークで互いに遭遇すると、予期しない相互運用性の問題が発生する可能性があります。ただし、トランスポート層セキュリティ（TLS）のケーススタディ（付録A.3）で述べたように、拡張性を注意深く設計するだけでは不十分です。また、慎重に実装する必要があります。
Experience shows that separate private networks often end up having portable equipment like laptop computers move between them, and networks that were originally envisaged as being separate can end up being connected later.
経験上、個別のプライベートネットワークはラップトップコンピューターなどのポータブル機器を移動することが多く、元々個別であると想定されていたネットワークが後で接続されることもあります。
Consider a "private" extension installed on a work computer that, being portable, is sometimes connected to networks other than the work network, like a home network or a hotel network. If the "private" extension is incompatible with an unextended version of the same protocol, problems will occur.
ポータブルで、ホームネットワークやホテルのネットワークなど、職場のネットワーク以外のネットワークに接続されている場合がある職場のコンピューターにインストールされた「プライベート」拡張機能について考えてみます。 「プライベート」拡張が同じプロトコルの拡張されていないバージョンと互換性がない場合、問題が発生します。
Similarly, problems can occur if "private" extensions conflict with each other. For example, imagine the situation where one site chose to use DHCP [RFC2132] option code 62 for one meaning and a different site chose to use DHCP option code 62 for a completely different, incompatible, meaning. It may be impossible for a vendor of portable computing devices to make a device that works correctly in both environments.
同様に、「プライベート」拡張機能が互いに競合する場合にも問題が発生する可能性があります。たとえば、あるサイトがDHCP [RFC2132]オプションコード62を1つの意味で使用することを選択し、別のサイトがDHCPオプションコード62を完全に異なる互換性のない意味で使用することを選択した状況を想像してください。ポータブルコンピューティングデバイスのベンダーが、両方の環境で正しく動作するデバイスを作成することは不可能かもしれません。
One approach to solving this problem has been to reserve parts of an identifier namespace for "limited applicability" or "site-specific" use, such as "X-" headers in email messages [RFC822] or "P-" headers in SIP [RFC3427]. However, as noted in "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols" [RFC6648], Appendix B:
この問題を解決する1つのアプローチは、識別子の名前空間の一部を、「制限付きの適用性」または「サイト固有」の使用のために予約することでした。たとえば、メールメッセージの[X-]ヘッダー[RFC822]やSIPの[P-]ヘッダーなどRFC3427]。ただし、「アプリケーションプロトコルでの「X-」プレフィックスと同様の構成の非推奨」[RFC6648]、付録Bに記載されているように、
The primary problem with the "X-" convention is that unstandardized parameters have a tendency to leak into the protected space of standardized parameters, thus introducing the need for migration from the "X-" name to a standardized name. Migration, in turn, introduces interoperability issues (and sometimes security issues) because older implementations will support only the "X-" name and newer implementations might support only the standardized name. To preserve interoperability, newer implementations simply support the "X-" name forever, which means that the unstandardized name has become a de facto standard (thus obviating the need for segregation of the name space into standardized and unstandardized areas in the first place).
「X-」規則の主な問題は、標準化されていないパラメーターが標準化されたパラメーターの保護されたスペースにリークする傾向があるため、「X-」名から標準化された名前への移行が必要になることです。一方、古い実装は「X-」名のみをサポートし、新しい実装は標準化された名前のみをサポートする可能性があるため、移行は相互運用性の問題（場合によってはセキュリティの問題）を引き起こします。相互運用性を維持するために、新しい実装は単に「X-」名を永久にサポートします。つまり、非標準化された名前が事実上の標準になったということです（したがって、最初に名前空間を標準化された領域と非標準化された領域に分離する必要がなくなります）。
As a result, the notion of "X-" headers from the 1982 Internet Message Format standard [RFC822] was removed when the specification was updated in 2001 [RFC2822]. Within SIP, the guidance published in 2002 regarding "P-" headers [RFC3427] was deprecated eight years later in Section 4 of the 2010 update [RFC5727]. More generally, as noted in Section 1 of the "X-" prefix deprecation document [RFC6648]:
その結果、1982 Internet Message Format標準[RFC822]の「X-」ヘッダーの概念は、仕様が2001年に更新されたときに削除されました[RFC2822]。 SIP内で、 "P-"ヘッダー[RFC3427]に関して2002年に公開されたガイダンスは、2010年の更新[RFC5727]のセクション4で8年後に廃止されました。より一般的には、「X-」接頭辞の非推奨ドキュメント[RFC6648]のセクション1で述べたように、
This document generalizes from the experience of the email and SIP communities by doing the following:
このドキュメントは、以下を実行することにより、電子メールおよびSIPコミュニティの経験から一般化します。
1. Deprecates the "X-" convention for newly defined parameters in application protocols, including new parameters for established protocols. This change applies even where the "X-" convention was only implicit, and not explicitly provided, such as was done for email in [RFC822].
1. 確立されたプロトコルの新しいパラメーターを含む、アプリケーションプロトコルで新しく定義されたパラメーターの「X-」規則を廃止します。この変更は、[RFC822]で電子メールに対して行われたように、「X-」規則が暗黙的であり、明示的に提供されなかった場合にも適用されます。
Values designated as "experimental" or "local use" are only appropriate in limited circumstances such as in early implementations of an extension restricted to a single site.
「実験的」または「ローカルでの使用」として指定された値は、単一のサイトに制限された拡張機能の初期の実装など、限られた状況でのみ適切です。
For example, "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers" [RFC4727] discusses experimental values for IP and transport headers, and "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474] defines experimental/local use ranges for differentiated services code points.
たとえば、「IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験値」[RFC4727]では、IPおよびトランスポートヘッダーの実験値について説明し、「IPv4およびIPv6のDiffServフィールド（DSフィールド）の定義」ヘッダー」[RFC2474]は、差別化サービスコードポイントの実験的/ローカル使用範囲を定義します。
Such values should be used with care and only for their stated purpose: experiments and local use. They are unsuitable for Internet-wide use, since they may be used for conflicting purposes and thereby cause interoperability failures. Packets containing experimental or local use values must not be allowed out of the domain in which they are meaningful.
このような値は、注意深く、指定された目的（実験およびローカルでの使用）にのみ使用してください。これらは競合する目的で使用され、相互運用性の障害を引き起こす可能性があるため、インターネット全体での使用には適していません。試験的またはローカル使用の値を含むパケットは、それらが意味のあるドメインの外に出てはなりません。
Section 1 of "Assigning Experimental and Testing Numbers Considered Useful" BCP 82 [RFC3692] provides guidance on the use of experimental code points:
「有用と見なされる実験番号とテスト番号の割り当て」のBCP 82 [RFC3692]のセクション1は、実験コードポイントの使用に関するガイダンスを提供します。
Numbers in the experimentation range ... are not intended to be used in general deployments or be enabled by default in products or other general releases. In those cases where a product or release makes use of an experimental number, the end user must be required to explicitly enable the experimental feature and likewise have the ability to chose and assign which number from the experimental range will be used for a specific purpose (i.e., so the end user can ensure that use of a particular number doesn't conflict with other on-going uses). Shipping a product with a specific value pre-enabled would be inappropriate and can lead to interoperability problems when the chosen value collides with a different usage, as it someday surely will.
実験範囲の数値...は、一般的な展開で使用することを意図したものではなく、製品やその他の一般的なリリースでデフォルトで有効にすることもできません。製品またはリリースが実験的な番号を使用する場合、エンドユーザーは実験的な機能を明示的に有効にする必要があり、同様に、実験的な範囲から特定の目的に使用する番号を選択して割り当てることができる必要があります（つまり、エンドユーザーは、特定の番号の使用が他の継続的な使用と競合しないことを確認できます）。特定の値を事前に有効にして製品を出荷することは不適切であり、選択した値が別の使用法と衝突すると、いつかは確実に相互運用性の問題が発生する可能性があります。
From the above, it follows that it would be inappropriate for a group of vendors, a consortia, or another Standards Development Organization to agree among themselves to use a particular value for a specific purpose and then agree to deploy devices using those values. By definition, experimental numbers are not guaranteed to be unique in any environment other than one where the local system administrator has chosen to use a particular number for a particular purpose and can ensure that a particular value is not already in use for some other purpose.
上記から、ベンダーのグループ、コンソーシアム、または他の標準開発組織が特定の目的のために特定の値を使用することに合意し、それらの値を使用してデバイスを展開することに同意することは不適切であることになります。定義により、実験的な数値は、ローカルシステム管理者が特定の目的で特定の数値を使用することを選択している環境以外の環境で一意であることが保証されておらず、特定の値が他の目的ですでに使用されていないことを確認できます。
Once an extension has been tested and shown to be useful, a permanent number could be obtained through the normal assignment procedures.
拡張機能がテストされ、有用であることが示されると、通常の割り当て手順で永続的な番号を取得できます。
However, as noted in Appendix B of the "X-" prefix deprecation document [RFC6648], assigning a parameter block for experimental use is only necessary when the parameter pool is limited:
ただし、「X-」接頭辞の非推奨ドキュメント[RFC6648]の付録Bに記載されているように、実験用にパラメーターブロックを割り当てる必要があるのは、パラメータープールが制限されている場合のみです。
"Assigning Experimental and Testing Numbers Considered Useful" ...
implies that the "X-" prefix is also useful for experimental
parameters. However, BCP 82 addresses the need for protocol
numbers when the pool of such numbers is strictly limited (e.g.,
DHCP options) or when a number is absolutely required even for
purely experimental purposes (e.g., the Protocol field of the IP
header). In almost all application protocols that make use of
protocol parameters (including email headers, media types, HTTP
headers, vCard parameters and properties, URNs, and LDAP field
names), the name space is not limited or constrained in any way,
so there is no need to assign a block of names for private use or
experimental purposes....
Therefore, it appears that segregating the parameter space into a standardized area and a unstandardized area has few, if any, benefits and has at least one significant cost in terms of interoperability.
したがって、パラメーター空間を標準化された領域と非標準化された領域に分離することには利点があったとしても、利点は少なく、相互運用性の点で少なくとも1つの大きなコストがあるようです。
Where an experiment is undertaken among a diverse set of experimental sites connected via the global Internet, the use of "experimental" or "local use" code points is inadvisable. This might include, for example, sites that take a prototype implementation of some protocol and use that both within their site but, importantly, among the full set of other sites interested in that protocol. In such a situation, it is impractical and probably impossible to coordinate the de-confliction of "experimental" code points. Section 4.1 of the IANA Considerations guidelines document [RFC5226] notes:
グローバルなインターネットを介して接続されたさまざまな実験サイトのセット間で実験が行われる場合、「実験的」または「ローカル使用」のコードポイントの使用はお勧めできません。これには、たとえば、プロトコルのプロトタイプ実装を採用し、サイト内だけでなく、重要なことに、そのプロトコルに関心のある他のすべてのサイト間でそれを使用するサイトが含まれる場合があります。このような状況では、「実験的」コードポイントの矛盾の解消を調整することは実際的ではなく、おそらく不可能です。 IANA考慮事項ガイドラインドキュメント[RFC5226]のセクション4.1には、次のように記載されています。
For private or local use ... No attempt is made to prevent
multiple sites from using the same value in different (and
incompatible) ways.... assignments are not generally useful for
broad interoperability. It is the responsibility of the sites
making use of the Private Use range to ensure that no conflicts
occur (within the intended scope of use).
The Host Identity Protocol (HIP) [RFC5201] and the Locator/ID Separation Protocol [LISP] are examples where a set of experimental sites are collaborating among themselves, but not necessarily in a tightly coordinated way. Both HIP and LISP have dealt with this by having unique non-experimental code points allocated to HIP and LISP, respectively, at the time of publication of their respective Experimental RFCs.
Host Identity Protocol（HIP）[RFC5201]とLocator / ID Separation Protocol [LISP]は、実験サイトのセットが相互に協力している例ですが、必ずしも厳密に調整されているわけではありません。 HIPとLISPはどちらも、それぞれの実験的RFCの公開時に、HIPとLISPにそれぞれ一意の非実験的なコードポイントを割り当てることでこれに対処しました。
Since protocol extension mechanisms may impact interoperability, it is important that they be architecturally compatible with the base protocol.
プロトコル拡張メカニズムは相互運用性に影響を与える可能性があるため、それらが基本プロトコルとアーキテクチャ的に互換性があることが重要です。
This includes understanding what current implementations do and how a proposed extension will interact with deployed systems. Is it clear when a proposed extension (or its proposed usage), if widely deployed, will operationally stress existing implementations or the underlying protocol itself? If this is not explained in the base protocol specification, is this covered in an extension design guidelines document?
これには、現在の実装の機能と、提案された拡張機能がデプロイされたシステムとどのように相互作用するかを理解することが含まれます。提案された拡張機能（またはその提案された使用法）が広く展開されている場合、既存の実装または基盤となるプロトコル自体に運用上のストレスがかかるのはいつですか？これが基本プロトコル仕様で説明されていない場合、これは拡張設計ガイドライン文書でカバーされていますか？
As part of the definition of a new extension, it is important to address whether the extension makes use of features as envisaged by the original protocol designers, or whether a new extension mechanism is being invented. If a new extension mechanism is being invented, then architectural compatibility issues need to be addressed.
新しい拡張機能の定義の一部として、拡張機能が元のプロトコル設計者が想定した機能を使用しているかどうか、または新しい拡張メカニズムが発明されているかどうかに対処することが重要です。新しい拡張メカニズムが発明されている場合、アーキテクチャの互換性の問題に対処する必要があります。
To assist in the assessment of architectural compatibility, protocol documents should provide guidelines explaining how extensions should be performed, and guidance on how protocol extension mechanisms should be used.
アーキテクチャの互換性の評価を支援するために、プロトコルドキュメントは、拡張の実行方法を説明するガイドラインと、プロトコル拡張メカニズムの使用方法に関するガイダンスを提供する必要があります。
Protocol components that are designed with the specific intention of allowing extensibility should be clearly identified, with specific and complete instructions on how to extend them. This includes the process for adequate review of extension proposals: do they need community review, and if so, how much and by whom?
拡張性を可能にするという特定の目的で設計されたプロトコルコンポーネントは、それらを拡張する方法に関する具体的かつ完全な指示とともに、明確に識別される必要があります。これには、エクステンションの提案を適切にレビューするプロセスが含まれます。コミュニティのレビューが必要ですか？必要な場合は、どの程度、誰がレビューしますか？
Documents relying on extension mechanisms need to explicitly identify the mechanisms being relied upon. For example, a document defining new data elements should not implicitly define new data types or protocol operations without explicitly describing those dependencies and discussing their impact. Where extension guidelines are available, mechanisms need to indicate whether they are compliant with those guidelines and offer an explanation if they are not.
拡張メカニズムに依存するドキュメントは、依存するメカニズムを明示的に識別する必要があります。たとえば、新しいデータ要素を定義するドキュメントは、それらの依存関係を明示的に説明し、それらの影響について説明することなく、新しいデータ型またはプロトコル操作を暗黙的に定義するべきではありません。拡張ガイドラインが利用可能な場合、メカニズムはそれらがガイドラインに準拠しているかどうかを示し、準拠していない場合は説明を提供する必要があります。
Examples of documents describing extension guidelines include:
拡張ガイドラインを説明するドキュメントの例は次のとおりです。
1. "Guidelines for Extending the Extensible Provisioning Protocol (EPP)" [RFC3735], which provides guidelines for use of EPP's extension mechanisms to define new features and object management capabilities.
1. 「拡張可能プロビジョニングプロトコル（EPP）の拡張に関するガイドライン」[RFC3735]。EPPの拡張メカニズムを使用して新しい機能とオブジェクト管理機能を定義するためのガイドラインを提供します。
2. "Guidelines for Authors and Reviewers of MIB Documents" BCP 111 [RFC4181], which provides guidance to protocol designers creating new MIB modules.
2. 「MIBドキュメントの作成者とレビュー担当者向けガイドライン」BCP 111 [RFC4181]。新しいMIBモジュールを作成するプロトコル設計者にガイダンスを提供します。
3. "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)" [RFC4485], which outlines guidelines for authors of SIP extensions.
3. 「Session Initiation Protocol（SIP）の拡張機能の作成者向けガイドライン」[RFC4485]、SIP拡張機能の作成者向けガイドラインの概要。
4. "Considerations for Lightweight Directory Access Protocol (LDAP) Extensions" BCP 118 [RFC4521], which discusses considerations for designers of LDAP extensions.
4. 「ライトウェイトディレクトリアクセスプロトコル（LDAP）拡張機能に関する考慮事項」BCP 118 [RFC4521]。LDAP拡張機能の設計者向けの考慮事項について説明しています。
5. "RADIUS Design Guidelines" BCP 158 [RFC6158], which provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol.
5. 「RADIUS設計ガイドライン」BCP 158 [RFC6158]。これは、リモート認証ダイヤルインユーザーサービス（RADIUS）プロトコルで使用される属性の設計に関するガイドラインを提供します。
Protocol variations -- specifications that look very similar to the original but don't interoperate with each other or with the original -- are even more harmful to interoperability than extensions. In general, such variations should be avoided. Causes of protocol variations include incompatible protocol extensions, uncoordinated protocol development, and poorly designed "profiles".
プロトコルのバリエーション-オリジナルと非常によく似ているが、相互にまたはオリジナルと相互運用しない仕様-は、拡張機能よりも相互運用性に有害です。一般に、このような変動は避ける必要があります。プロトコルのバリエーションの原因には、互換性のないプロトコル拡張、調整されていないプロトコル開発、設計が不十分な「プロファイル」などがあります。
Designing a protocol for extensibility may have the perverse side effect of making it easy to construct incompatible variations. Protocol extension mechanisms should not be used to create incompatible forks in development. An extension may lead to interoperability failures unless the extended protocol correctly supports all mandatory and optional features of the unextended base protocol, and implementations of the base protocol operate correctly in the presence of the extensions. In addition, it is necessary for an extension to interoperate with other extensions.
拡張性のためにプロトコルを設計すると、互換性のないバリエーションを簡単に構築できるという、ひどい副作用が生じる可能性があります。プロトコル拡張メカニズムを使用して、開発中に互換性のないフォークを作成しないでください。拡張プロトコルが拡張されていない基本プロトコルの必須機能とオプション機能をすべて正しくサポートし、拡張機能が存在しても基本プロトコルの実装が正しく動作しない限り、拡張機能は相互運用性の障害につながる可能性があります。また、拡張機能は他の拡張機能と相互運用する必要があります。
As noted in Section 1 of "Uncoordinated Protocol Development Considered Harmful" [RFC5704], incompatible forks in development can result from the uncoordinated adaptation of a protocol, parameter, or code point:
「有害な非協調的プロトコル開発」[RFC5704]のセクション1で述べたように、プロトコル、パラメータ、またはコードポイントの非協調的適合により、開発における互換性のないフォークが発生する可能性があります。
In particular, the IAB considers it an essential principle of the protocol development process that only one SDO maintains design authority for a given protocol, with that SDO having ultimate authority over the allocation of protocol parameter code-points and over defining the intended semantics, interpretation, and actions associated with those code-points.
特に、IABは、1つのSDOだけが特定のプロトコルの設計権限を維持することをプロトコル開発プロセスの重要な原則であると見なし、そのSDOはプロトコルパラメータコードポイントの割り当ておよび意図されたセマンティクスの定義、解釈に対する最終的な権限を持っています。 、およびそれらのコードポイントに関連付けられたアクション。
Note that problems can occur even when one Standards Development Organization (SDO) maintains design authority, if protocol parameter code points are reused. As an example, EAP-FAST [RFC5421][RFC5422] reused previously assigned Extensible Authentication Protocol (EAP) type codes. As described in the IESG note in the EAP-FAST document [RFC5421]:
プロトコルパラメータコードポイントが再利用される場合、1つの標準開発機構（SDO）が設計権限を維持していても問題が発生する可能性があることに注意してください。例として、EAP-FAST [RFC5421] [RFC5422]は、以前に割り当てられた拡張認証プロトコル（EAP）タイプコードを再利用しました。 EAP-FASTドキュメント[RFC5421]のIESGノートに記載されているとおり：
The reuse of previously assigned EAP Type Codes is incompatible with EAP method negotiation as defined in RFC 3748.
以前に割り当てられたEAPタイプコードの再利用は、RFC 3748で定義されているEAPメソッドネゴシエーションと互換性がありません。
Profiling is a common technique for improving interoperability within a target environment or set of scenarios. Generally speaking, there are two approaches to profiling:
プロファイリングは、ターゲット環境または一連のシナリオ内での相互運用性を向上させるための一般的な手法です。一般的に、プロファイリングには2つの方法があります。
a) Removal or downgrading of normative requirements (thereby creating potential interoperability problems).
a) 規範的な要件の削除またはダウングレード（これにより、潜在的な相互運用性の問題が発生します）。
b) Elevation of normative requirement levels (such as from a MAY/SHOULD to a MUST). This can be done in order to improve interoperability by narrowing potential implementation choices (such as when the underlying protocol is ill-defined enough to permit non-interoperable yet compliant implementations) or to meet specific operational requirements (such as enabling use of stronger cryptographic mechanisms than those mandated in the specification).
b）標準要件レベルの昇格（MAY / SHOULDからMUSTへの変更など）。これは、潜在的な実装の選択肢を狭めることで相互運用性を向上させる（たとえば、基になるプロトコルが十分に定義されておらず、相互運用性はないが準拠した実装を許可する）か、特定の運用要件（強力な暗号化メカニズムの使用を有効にするなど）を満たすために実行できます。仕様で規定されているものより）。
While approach a) is potentially harmful, approach b) may be beneficial.
アプローチa）は潜在的に有害ですが、アプローチb）は有益な場合があります。
In order to avoid interoperability problems when profiled implementations interact with others over the global Internet, profilers need to remain cognizant of the implications of removing normative requirements. As noted in Section 6 of "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119], imperatives are to be used with care, and as a result, their removal within a profile is likely to result in serious consequences:
プロファイリングされた実装がグローバルインターネット経由で他の実装と相互作用するときの相互運用性の問題を回避するために、プロファイラーは規範的な要件を削除することの影響を認識し続ける必要があります。 「要件レベルを示すためにRFCで使用するキーワード」[RFC2119]のセクション6で述べたように、命令は注意して使用する必要があり、その結果、プロファイル内での削除は深刻な結果をもたらす可能性があります。
Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability.
このメモで定義されているタイプの命令は、慎重かつ慎重に使用する必要があります。特に、それらは、相互運用に実際に必要な場合、または害を引き起こす可能性のある動作を制限する場合（たとえば、再送信の制限）にのみ使用する必要があります。たとえば、特定のメソッドを実装者に課そうとするために使用してはなりません。相互運用性のためにメソッドは必要ありません。
As noted in Sections 3 and 4 of the Key Words document [RFC2119], recommendations cannot be removed from profiles without serious consideration:
キーワードドキュメント[RFC2119]のセクション3と4で述べたように、推奨事項は深刻な考慮なしにプロファイルから削除することはできません。
[T]here may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
特定の状況で特定の項目を無視する正当な理由が存在する場合がありますが、別のコースを選択する前に、すべての影響を理解し、慎重に検討する必要があります。
Even the removal of optional features and requirements can have consequences. As noted in Section 5 of the Key Words document [RFC2119], implementations that do not support optional features still retain the obligation to ensure interoperation with implementations that do:
オプションの機能や要件の削除でさえ、結果をもたらす可能性があります。キーワードドキュメント[RFC2119]のセクション5に記載されているように、オプション機能をサポートしない実装は、次のことを行う実装との相互運用を保証する義務を保持します。
An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)
特定のオプションを含まない実装は、おそらく機能が低下しますが、オプションを含む別の実装と相互運用できるように準備する必要があります。同様に、特定のオプションを含む実装は、オプションを含まない別の実装と相互運用できるように準備する必要があります（もちろん、オプションが提供する機能を除きます）。
Experience has shown that it is insufficient merely to specify extensibility and backward compatibility correctly in an RFC. It is also important that implementations respect the compatibility mechanisms; if not, non-interoperable pairs of implementations may arise. The TLS case study (Appendix A.3) shows how important this can be.
経験から、RFCで拡張性と下位互換性を正しく指定するだけでは不十分であることがわかっています。実装が互換性メカニズムを尊重することも重要です。そうでない場合、相互運用できない実装のペアが発生する可能性があります。 TLSのケーススタディ（付録A.3）は、これがいかに重要であるかを示しています。
In order to determine whether protocol extension mechanisms have been properly implemented, testing is required. However, for this to be possible, test cases need to be developed. If a base protocol document specifies extension mechanisms but does not utilize them or provide examples, it may not be possible to develop effective test cases based on the base protocol specification alone. As a result, base protocol implementations may not be properly tested, and non-compliant extension behavior may not be detected until these implementations are widely deployed.
プロトコル拡張メカニズムが適切に実装されているかどうかを判断するには、テストが必要です。ただし、これを可能にするには、テストケースを開発する必要があります。基本プロトコルドキュメントが拡張メカニズムを指定しているが、それらを利用しないか、例を提供していない場合、基本プロトコル仕様のみに基づいて効果的なテストケースを開発することができない場合があります。その結果、基本プロトコルの実装が適切にテストされず、これらの実装が広く展開されるまで、非準拠の拡張動作が検出されない可能性があります。
To encourage correct implementation of extension mechanisms, base protocol specifications should clearly articulate the expected behavior of extension mechanisms and should include examples of correct extension behavior.
拡張メカニズムの正しい実装を促進するために、基本プロトコル仕様は、拡張メカニズムの予想される動作を明確に明確にし、正しい拡張動作の例を含める必要があります。
As noted in Section 3.2 of "Procedures for Protocol Extensions and Variations" BCP 125 [RFC4775]:
「プロトコル拡張およびバリエーションの手順」のセクション3.2で述べたように、BCP 125 [RFC4775]：
An extension is often likely to make use of additional values
added to an existing IANA registry.... It is essential that such
new values are properly registered by the applicable procedures,
including expert review where applicable.... Extensions may even
need to create new IANA registries in some cases.
Experience shows that the importance of this is often underestimated during extension design; designers sometimes assume that a new codepoint is theirs for the asking, or even simply for the taking.
経験上、これの重要性はエクステンションの設計中に過小評価されることがよくあります。デザイナーは時々、新しいコードポイントが要求のためのものであるか、あるいは単に取るためのものであると仮定します。
Before creating a new protocol parameter registry, existing registries should be examined to determine whether one of them can be used instead (see http://www.iana.org/protocols/).
新しいプロトコルパラメータレジストリを作成する前に、既存のレジストリを調べて、それらの1つを代わりに使用できるかどうかを判断する必要があります（http://www.iana.org/protocols/を参照）。
To avoid conflicting usage of the same registry value, as well as to prevent potential difficulties in determining and transferring parameter ownership, it is essential that all new values are registered. If this is not done, there is nothing to prevent two different extensions picking the same value. When these two extensions "meet" each other on the Internet, failure is inevitable.
同じレジストリ値の競合する使用を回避し、パラメータの所有権を決定および転送する際の潜在的な問題を回避するには、すべての新しい値を登録することが不可欠です。これが行われない場合、2つの異なる拡張機能が同じ値を選択するのを防ぐ方法はありません。これら2つの拡張機能がインターネット上で互いに「会う」とき、失敗は避けられません。
A surprisingly common case of this is misappropriation of assigned Transmission Control Protocol (TCP) (or User Datagram Protocol (UDP)) registered port numbers. This can lead to a client for one service attempting to communicate with a server for another service. Another common case is the use of unregistered URI schemes. Numerous cases could be cited, but not without embarrassing specific implementers. For general rules, see the IANA Considerations guidelines document [RFC5226], and for specific rules and registries, see the individual protocol specification RFCs and the IANA web site.
これの驚くほど一般的なケースは、割り当てられた伝送制御プロトコル（TCP）（またはユーザーデータグラムプロトコル（UDP））の登録済みポート番号の横領です。これにより、あるサービスのクライアントが別のサービスのサーバーと通信しようとする可能性があります。もう1つの一般的なケースは、未登録のURIスキームの使用です。多数の事例が引用された可能性がありますが、特定の実装者を恥ずかしげにしない限り、一般的なルールについては、IANAの考慮事項に関するガイドラインドキュメント[RFC5226]を参照してください。特定のルールとレジストリについては、個々のプロトコル仕様RFCとIANA Webサイトを参照してください。
While in theory a "Standards Track" or "IETF Consensus" parameter allocation policy may be instituted to encourage protocol parameter registration or to improve interoperability, in practice, problems can arise if the procedures result in so much delay that requesters give up and "self-allocate" by picking presumably unused code points. Where self-allocation is prevalent, the information contained within registries may become inaccurate, particularly when third parties are prohibited from updating entries so as to improve accuracy. In these situations, it is important to consider whether registration processes need to be changed to support the role of a registry as "documentation of how the Internet is operating".
理論的には、「Standards Track」または「IETF Consensus」パラメータ割り当てポリシーを設定して、プロトコルパラメータの登録を促進したり、相互運用性を向上させたりすることができますが、実際には、リクエスタが断念し、「自己おそらく未使用のコードポイントを選択することにより、「-allocate」。自己割り当てが普及している場合、特に精度を向上させるために第三者がエントリを更新することが禁止されている場合は、レジストリに含まれる情報が不正確になる可能性があります。このような状況では、「インターネットがどのように動作しているかのドキュメント」としてレジストリの役割をサポートするために登録プロセスを変更する必要があるかどうかを検討することが重要です。
Some protocols (such as the Domain Name System (DNS), the Border Gateway Protocol (BGP), and the Hypertext Transfer Protocol (HTTP)) or algorithms (such as congestion control) have become critical components of the Internet infrastructure. A critical component is one whose failure can lead to Internet-wide reliability and security issues or performance degradation. When such protocols or algorithms are extended, the potential exists for negatively impacting the reliability and security of the global Internet.
一部のプロトコル（ドメインネームシステム（DNS）、ボーダーゲートウェイプロトコル（BGP）、ハイパーテキスト転送プロトコル（HTTP）など）またはアルゴリズム（輻輳制御など）は、インターネットインフラストラクチャの重要なコンポーネントになっています。重要なコンポーネントとは、その障害がインターネット全体の信頼性とセキュリティの問題、またはパフォーマンスの低下につながる可能性があるコンポーネントです。このようなプロトコルまたはアルゴリズムが拡張されると、グローバルインターネットの信頼性とセキュリティに悪影響を及ぼす可能性があります。
As a result, special care needs to be taken with these extensions, such as taking explicit steps to isolate existing uses from new ones. For example, this can be accomplished by requiring the extension to utilize a different port or multicast address or by implementing the extension within a separate process, without access to the data and control structures of the base protocol.
その結果、これらの拡張には特別な注意を払う必要があります。たとえば、既存の使用を新しい使用から分離する明示的な手順を実行するなどです。たとえば、これは、拡張機能に別のポートまたはマルチキャストアドレスを利用するよう要求するか、ベースプロトコルのデータおよび制御構造にアクセスせずに、別のプロセス内に拡張機能を実装することで実現できます。
Experience has shown that even when a mechanism has proven benign in other uses, unforeseen issues may result when adding it to a critical protocol. For example, both IS-IS and OSPF support opaque Link State Advertisements (LSAs), which are propagated by intermediate nodes that don't understand the LSA. Within Interior Gateway Protocols (IGPs), support for opaque LSAs has proven useful without introducing instability.
経験上、メカニズムが他の用途で良性であることが証明されている場合でも、それを重要なプロトコルに追加すると予期しない問題が発生する可能性があることが示されています。たとえば、IS-ISとOSPFの両方が不透明なリンク状態アドバタイズメント（LSA）をサポートします。LSAは、LSAを理解しない中間ノードによって伝播されます。 Interior Gateway Protocol（IGP）内では、不透明なLSAのサポートが不安定さを招くことなく有用であることが証明されています。
However, within BGP, "attribute tunneling" has resulted in large-scale routing instabilities, since remote nodes may reset the LOCAL session if the tunneled attributes are malformed or aren't understood. This has required modification to BGP error handling, as noted in "Revised Error Handling for BGP UPDATE Messages" [ERROR-HANDLING].
ただし、BGP内では、「属性トンネリング」によって大規模なルーティングが不安定になります。トンネリングされた属性の形式が正しくないか、理解されない場合、リモートノードがLOCALセッションをリセットする可能性があるためです。これには、「BGP UPDATEメッセージのエラー処理の改訂版」[エラー処理]に記載されているように、BGPエラー処理を変更する必要がありました。
In general, when extending protocols with local failure conditions, tunneling of attributes that may trigger failures in non-adjacent nodes should be avoided. This is particularly problematic when the originating node receives no indicators of remote failures it may have triggered.
一般に、ローカルの障害状態でプロトコルを拡張する場合、隣接していないノードで障害を引き起こす可能性のある属性のトンネリングは回避する必要があります。これは、発信ノードがトリガーした可能性のあるリモート障害のインジケータを受信しない場合に特に問題になります。
Good extension design depends on a well-designed base protocol. To promote interoperability, designers should:
適切な拡張設計は、適切に設計された基本プロトコルに依存します。相互運用性を促進するには、設計者は次のことを行う必要があります。
1. Ensure a well-written base protocol specification. Does the base protocol specification make clear what an implementer needs to support, and does it define the impact that individual operations (e.g., a message sent to a peer) will have when invoked?
1. よく書かれた基本プロトコル仕様を確認してください。基本プロトコル仕様は、実装者がサポートする必要があることを明確にし、個々の操作（たとえば、ピアに送信されるメッセージ）が呼び出されたときの影響を定義していますか？
2. Design for backward compatibility. Does the base protocol specification describe how to determine the capabilities of a peer and negotiate the use of extensions? Does it indicate how implementations handle extensions that they do not understand? Is it possible for an extended implementation to negotiate with an unextended (or differently-extended) peer to find a common subset of useful functions?
2. 下位互換性のための設計。基本プロトコル仕様は、ピアの機能を決定し、拡張機能の使用をネゴシエートする方法を説明していますか？それは、実装が理解できない拡張を処理する方法を示していますか？拡張実装が拡張されていない（または拡張が異なる）ピアとネゴシエートして、有用な関数の共通サブセットを見つけることは可能ですか？
3. Respect underlying architectural or security assumptions. Is there a document describing the underlying architectural assumptions, as well as considerations that have arisen in operational experience? Or are there undocumented considerations that have arisen as the result of operational experience, after the original protocol was published?
3. 基盤となるアーキテクチャまたはセキュリティの前提を尊重します。基盤となるアーキテクチャの前提と、運用経験で発生した考慮事項について説明したドキュメントはありますか？または、元のプロトコルが公開された後、運用経験の結果として生じた文書化されていない考慮事項はありますか？
For example, will backward-compatibility issues arise if extensions reverse the flow of data, allow formerly static parameters to be changed on the fly, or change assumptions relating to the frequency of reads/writes?
たとえば、拡張機能がデータの流れを逆にしたり、以前は静的だったパラメーターをその場で変更したり、読み取り/書き込みの頻度に関する仮定を変更したりすると、下位互換性の問題が発生しますか？
4. Minimize impact on critical infrastructure. For a protocol that represents a critical element of Internet infrastructure, it is important to explain when it is appropriate to isolate new uses of the protocol from existing ones.
4. 重要なインフラストラクチャへの影響を最小限に抑えます。インターネットインフラストラクチャの重要な要素を表すプロトコルの場合、プロトコルの新しい使用を既存の使用から分離することが適切な場合について説明することが重要です。
For example, is it explained when a proposed extension (or usage) has the potential for negatively impacting critical infrastructure to the point where explicit steps would be appropriate to isolate existing uses from new ones?
たとえば、提案された拡張（または使用法）が、重要なインフラストラクチャに悪影響を与える可能性がある場合に、既存の使用法を新しい使用法から分離するための明示的な手順が適切になるまで説明されていますか？
5. Provide guidance on data model extensions. Is there a document that explains when a protocol extension is routine and when it represents a major change?
5. データモデルの拡張に関するガイダンスを提供します。プロトコル拡張が日常的であり、それがいつ大きな変更になるかを説明したドキュメントはありますか？
For example, is it clear when a data model extension represents a major versus a routine change? Are there guidelines describing when an extension (such as a new data type) is likely to require a code change within existing implementations?
たとえば、データモデルの拡張機能がメジャーな変更と日常的な変更を表すのはいつですか。拡張（新しいデータ型など）が既存の実装内でコードの変更を必要とする可能性がある場合を説明するガイドラインはありますか？
Any mechanism for extension by versioning must include provisions to ensure interoperability, or at least clean failure modes. Imagine someone creating a protocol and using a "version" field and populating it with a value (1, let's say), but giving no information about what would happen when a new version number appears in it. This would be a bad protocol design and description; it should be clear what the expectation is and how it can be tested. For example, stating that 1.X must be compatible with any version 1 code, but version 2 or greater is not expected to be compatible, has different implications than stating that version 1 must be a proper subset of version 2.
バージョニングによる拡張のメカニズムには、相互運用性を確保するための対策、または少なくともクリーンな障害モードを含める必要があります。誰かがプロトコルを作成して「バージョン」フィールドを使用し、それに値（1としましょう）を入力しているが、新しいバージョン番号が表示されたときに何が起こるかについての情報を提供していないとします。これはプロトコルの設計と説明としては不適切です。期待値とは何か、どのようにテストできるかを明確にする必要があります。たとえば、1.Xはバージョン1のコードと互換性がなければならないが、バージョン2以降は互換性がないと想定すると、バージョン1はバージョン2の適切なサブセットである必要があると述べることとは意味が異なります。
An example of an under-specified versioning mechanism is provided by the MIME-Version header, originally defined in "MIME (Multipurpose Internet Mail Extensions)" [RFC1341]. As noted in Section 1 of the MIME specification [RFC1341]:
仕様が不十分なバージョン管理メカニズムの例は、もともと「MIME（多目的インターネットメール拡張）」[RFC1341]で定義されたMIME-Versionヘッダーによって提供されます。 MIME仕様[RFC1341]のセクション1で述べたように、
A MIME-Version header field ... uses a version number to declare a message to be conformant with this specification and allows mail processing agents to distinguish between such messages and those generated by older or non-conformant software, which is presumed to lack such a field.
MIME-Versionヘッダーフィールド...バージョン番号を使用して、この仕様に準拠するメッセージを宣言し、メール処理エージェントがそのようなメッセージと、古いまたは非準拠のソフトウェアによって生成されたメッセージを区別できるようにします。フィールド。
Beyond this, the 1992 MIME specification [RFC1341] provided little guidance on versioning behavior, or even the format of the MIME-Version header, which was specified to contain "text". The 1993 update [RFC1521] better defined the format of the version field but still did not clarify the versioning behavior:
これを超えると、1992 MIME仕様[RFC1341]は、バージョニングの動作、または「テキスト」を含むように指定されたMIME-Versionヘッダーのフォーマットについてのガイダンスをほとんど提供しませんでした。 1993年の更新[RFC1521]は、バージョンフィールドの形式をより適切に定義しましたが、バージョン管理の動作はまだ明確ではありませんでした。
Thus, future format specifiers, which might replace or extend
"1.0", are constrained to be two integer fields, separated by a
period. If a message is received with a MIME-version value other
than "1.0", it cannot be assumed to conform with this
specification....
It is not possible to fully specify how a mail reader that conforms with MIME as defined in this document should treat a message that might arrive in the future with some value of MIME-Version other than "1.0". However, conformant software is encouraged to check the version number and at least warn the user if an unrecognized MIME-version is encountered.
このドキュメントで定義されているように、MIMEに準拠するメールリーダーが、「1.0」以外のMIME-Versionの値で将来到着する可能性があるメッセージをどのように処理するかを完全に指定することはできません。ただし、適合ソフトウェアでは、バージョン番号を確認し、認識できないMIMEバージョンが検出された場合は少なくともユーザーに警告することをお勧めします。
Thus, even though the 1993 update [RFC1521] defined a MIME-Version header with a syntax suggestive of a "Major/Minor" versioning scheme, in practice the MIME-Version header was little more than a decoration.
したがって、1993年の更新[RFC1521]は、「メジャー/マイナー」バージョン管理スキームを連想させる構文でMIME-Versionヘッダーを定義しましたが、実際にはMIME-Versionヘッダーは装飾に過ぎませんでした。
An example of a protocol with a better versioning scheme is ROHC (Robust Header Compression). ROHCv1 [RFC3095] supports a certain set of profiles for compression algorithms. But experience had shown that these profiles had limitations, so the ROHC WG developed ROHCv2 [RFC5225]. A ROHCv1 implementation does not contain code for the ROHCv2 profiles. As the ROHC WG charter said during the development of ROHCv2:
より優れたバージョン管理スキームを持つプロトコルの例は、ROHC（Robust Header Compression）です。 ROHCv1 [RFC3095]は、圧縮アルゴリズム用の特定のプロファイルセットをサポートしています。しかし、経験上、これらのプロファイルには制限があることが示されているため、ROHC WGはROHCv2 [RFC5225]を開発しました。 ROHCv1実装には、ROHCv2プロファイルのコードは含まれていません。 ROHCv2の開発中にROHC WG憲章が述べたように、
It should be noted that the v2 profiles will thus not be compatible with the original (ROHCv1) profiles, which means less complex ROHC implementations can be realized by not providing support for ROHCv1 (over links not yet supporting ROHC, or by shifting out support for ROHCv1 in the long run). Profile support is agreed through the ROHC channel negotiation, which is part of the ROHC framework and thus not changed by ROHCv2.
したがって、v2プロファイルは元の（ROHCv1）プロファイルと互換性がないことに注意してください。これは、ROHCv1のサポートを提供しないことで（ROHCをまだサポートしていないリンクを介して）、またはサポートをシフトアウトすることで、より複雑でないROHC実装を実現できることを意味します長期的にはROHCv1）。プロファイルのサポートは、ROHCチャネルネゴシエーションを通じて合意されます。これは、ROHCフレームワークの一部であり、ROHCv2によって変更されません。
Thus, in this case, both backward-compatible and backward-incompatible deployments are possible. The important point is to have a clearly thought out approach to the question of operational compatibility.
したがって、この場合、下位互換性のある展開と下位互換性のない展開の両方が可能です。重要な点は、運用上の互換性の問題に明確に考えられたアプローチをとることです。
In the past, protocols have utilized a variety of strategies for versioning, each with its own benefits and drawbacks in terms of capability and complexity of implementation:
これまで、プロトコルはバージョン管理にさまざまな戦略を利用してきましたが、それぞれに実装の機能と複雑さの点で独自の利点と欠点があります。
1. No versioning support. This approach is exemplified by the Extensible Authentication Protocol (EAP) [RFC3748] as well as the Remote Authentication Dial In User Service (RADIUS) protocol [RFC2865], both of which provide no support for versioning. While lack of versioning support protects against the proliferation of incompatible dialects, the need for extensibility is likely to assert itself in other ways, so that ignoring versioning entirely may not be the most forward thinking approach.
1. バージョン管理のサポートはありません。このアプローチの例は、拡張認証プロトコル（EAP）[RFC3748]とリモート認証ダイヤルインユーザーサービス（RADIUS）プロトコル[RFC2865]であり、どちらもバージョン管理をサポートしていません。バージョン管理のサポートの欠如は互換性のない方言の急増を防ぎますが、拡張性の必要性は他の方法でそれ自体を主張する可能性が高いため、バージョン管理を完全に無視することは最も前向きなアプローチではない可能性があります。
2. Highest mutually supported version (HMSV). In this approach, implementations exchange the version numbers of the highest version each supports, with the negotiation agreeing on the highest mutually supported protocol version. This approach implicitly assumes that later versions provide improved functionality and that advertisement of a particular version number implies support for all lower version numbers. Where these assumptions are invalid, this approach breaks down, potentially resulting in interoperability problems. An example of this issue occurs in the Protected Extensible Authentication Protocol [PEAP] where implementations of higher versions may not necessarily provide support for lower versions.
2. 相互にサポートされる最も高いバージョン（HMSV）。このアプローチでは、相互にサポートされている最も高いプロトコルバージョンについてネゴシエーションが合意し、実装がそれぞれがサポートしている最も高いバージョンのバージョン番号を交換します。このアプローチでは、新しいバージョンの機能が改善され、特定のバージョン番号の通知がそれよりも低いすべてのバージョン番号のサポートを意味することを暗黙的に想定しています。これらの仮定が無効である場合、このアプローチは失敗し、潜在的に相互運用性の問題が発生します。この問題の例は、Protected Extensible Authentication Protocol [PEAP]で発生し、上位バージョンの実装が下位バージョンのサポートを提供するとは限りません。
3. Assumed backward compatibility. In this approach, implementations may send packets with higher version numbers to legacy implementations supporting lower versions, but with the assumption that the legacy implementations will interpret packets with higher version numbers using the semantics and syntax defined for lower versions. This is the approach taken by "Port-Based Network Access Control" [IEEE-802.1X]. For this approach to work, legacy implementations need to be able to accept packets of known types with higher protocol versions without discarding them; protocol enhancements need to permit silent discard of unsupported extensions; and implementations supporting higher versions need to refrain from mandating new features when encountering legacy implementations.
3. 下位互換性を想定しています。このアプローチでは、実装はより高いバージョン番号のパケットをより低いバージョンをサポートするレガシー実装に送信できますが、レガシー実装はより低いバージョンに定義されたセマンティクスと構文を使用してより高いバージョン番号のパケットを解釈するものと想定しています。これは、「ポートベースのネットワークアクセスコントロール」[IEEE-802.1X]によって採用されたアプローチです。このアプローチが機能するためには、レガシー実装は、それらを破棄せずに、より高いプロトコルバージョンを持つ既知のタイプのパケットを受け入れることができる必要があります。プロトコルの拡張では、サポートされていない拡張機能のサイレント破棄を許可する必要があります。より高いバージョンをサポートする実装では、レガシー実装に遭遇したときに新機能を強制することを控える必要があります。
4. Major/minor versioning. In this approach, implementations with the same major version but a different minor version are assumed to be backward compatible, but implementations are required to negotiate a mutually supported major version number. This approach assumes that implementations with a lower minor version number but the same major version can safely ignore unsupported protocol messages.
4. メジャー/マイナーバージョン管理。このアプローチでは、メジャーバージョンは同じでマイナーバージョンが異なる実装は下位互換性があると見なされますが、相互にサポートされているメジャーバージョン番号をネゴシエートするための実装が必要です。このアプローチでは、マイナーバージョン番号は小さいが、メジャーバージョンが同じである実装は、サポートされていないプロトコルメッセージを安全に無視できると想定しています。
5. Min/max versioning. This approach is similar to HMSV, but without the implied obligation for clients and servers to support all versions back to version 1, in perpetuity. It allows clients and servers to cleanly drop support for early versions when those versions become so old that they are no longer relevant and no longer required. In this approach, the client initiating the connection reports the highest and lowest protocol versions it understands. The server reports back the chosen protocol version:
5. 最小/最大バージョン管理。このアプローチはHMSVに似ていますが、クライアントとサーバーがバージョン1までのすべてのバージョンを永続的にサポートするという暗黙の義務はありません。これにより、クライアントとサーバーは、古いバージョンが古くなり、関連性がなくなり、不要になったときに、サポートを完全に削除できます。このアプローチでは、接続を開始するクライアントは、クライアントが理解できる最高および最低のプロトコルバージョンを報告します。サーバーは、選択したプロトコルバージョンを報告します。
a. If the server understands one or more versions in the client's range, it reports back the highest mutually understood version.
a. サーバーがクライアントの範囲内の1つ以上のバージョンを理解している場合、相互に理解している最も高いバージョンを報告します。
b. If there is no mutual version, then the server reports back some version that it does understand (selected as described below). The connection is then typically dropped by client or server, but reporting this version number first helps facilitate useful error messages at the client end:
b. 相互バージョンがない場合、サーバーは、理解できるバージョン（以下で説明するように選択）を報告します。その後、接続は通常クライアントまたはサーバーによってドロップされますが、このバージョン番号を最初に報告すると、クライアントエンドでの有用なエラーメッセージが容易になります。
* If there is no mutual version, and the server speaks any version higher than client max, it reports the lowest version it speaks that is greater than the client max. The client can then report to the user, "You need to upgrade to at least version <xx>".
* 相互バージョンがなく、サーバーがクライアントの最大値よりも高いバージョンを話す場合、サーバーはクライアントの最大値より大きい、最も低いバージョンを報告します。次に、クライアントはユーザーに「少なくともバージョン<xx>にアップグレードする必要があります」と報告できます。
* Else, the server reports the highest version it speaks. The client can then report to the user, "You need to request the server operator to upgrade to at least version <min>".
* さもなければ、サーバーはそれが話す最も高いバージョンを報告します。次に、クライアントはユーザーに「少なくともバージョン<min>にアップグレードするようサーバーオペレーターに要求する必要があります」と報告できます。
Protocols generally do not need any version-negotiation mechanism more complicated than the mechanisms described here. The nature of protocol version-negotiation mechanisms is that, by definition, they don't get widespread real-world testing until *after* the base protocol has been deployed for a while, and its deficiencies have become evident. This means that, to be useful, a protocol version-negotiation mechanism should be simple enough that it can reasonably be assumed that all the implementers of the first protocol version at least managed to implement the version-negotiation mechanism correctly.
プロトコルは通常、ここで説明するメカニズムよりも複雑なバージョンネゴシエーションメカニズムを必要としません。プロトコルバージョンネゴシエーションメカニズムの性質は、基本的に、ベースプロトコルがしばらく展開されてから、その欠陥が明らかになるまで、広範囲にわたる実際のテストを受けないということです。つまり、プロトコルバージョンネゴシエーションメカニズムは、最初のプロトコルバージョンのすべての実装者が少なくともバージョンネゴシエーションメカニズムを正しく実装するように管理されていると合理的に想定できるほどシンプルである必要があります。
Protocols commonly include one or more "reserved" fields, clearly intended for future extensions. It is good practice to specify the value to be inserted in such a field by the sender (typically zero) and the action to be taken by the receiver when seeing some other value (typically no action). In packet format diagrams, such fields are typically labeled "MBZ", to be read as, "Must Be Zero on transmission, Must Be Ignored on reception".
プロトコルには通常、将来の拡張を明確に意図した1つ以上の「予約済み」フィールドが含まれています。送信者がこのようなフィールドに挿入する値（通常はゼロ）と、他の値を見つけたときに受信者が実行するアクション（通常はアクションなし）を指定することをお勧めします。パケット形式の図では、このようなフィールドには通常「MBZ」というラベルが付けられており、「送信時にはゼロでなければならず、受信時には無視する必要がある」と解釈されます。
A common mistake of inexperienced protocol implementers is to think that "MBZ" means that it's their software's job to verify that the value of the field is zero on reception and reject the packet if not. This is a mistake, and such software will fail when it encounters future versions of the protocol where these previously reserved fields are given new defined meanings. Similarly, protocols should carefully specify how receivers should react to unknown extensions (headers, TLVs, etc.), such that failures occur only when that is truly the intended outcome.
経験の浅いプロトコル実装者の一般的な間違いは、「MBZ」は、フィールドの値が受信時にゼロであることを確認し、そうでない場合はパケットを拒否するのがソフトウェアの仕事だと考えることです。これは誤りであり、これらのソフトウェアは、これらの以前に予約されたフィールドに新しい定義された意味が与えられるプロトコルの将来のバージョンに遭遇すると失敗します。同様に、プロトコルは、不明な拡張（ヘッダー、TLVなど）にレシーバーがどのように反応するかを注意深く指定する必要があります。これにより、本当に意図した結果である場合にのみ障害が発生します。
Using widely supported encoding formats leads to better interoperability and easier extensibility.
広くサポートされているエンコード形式を使用すると、相互運用性が向上し、拡張性が向上します。
As described in "IAB Thoughts on Encodings for Internationalized Domain Names" [RFC6055], the number of encodings should be minimized, and complex encodings are generally a bad idea. As soon as one moves outside the ASCII repertoire, issues arise relating to collation, valid code points, encoding, normalization, and comparison, which extensions must handle with care [ID-COMPARISON][PRECIS-STATEMENT][PRECIS-FRAMEWORK].
「国際化ドメイン名のエンコーディングに関するIABの考え方」[RFC6055]で説明されているように、エンコーディングの数は最小限に抑える必要があり、複雑なエンコーディングは一般に悪い考えです。 ASCIIレパートリーの外に移動するとすぐに、照合、有効なコードポイント、エンコーディング、正規化、および比較に関連する問題が発生します。これらの拡張機能では、[ID-COMPARISON] [PRECIS-STATEMENT] [PRECIS-FRAMEWORK]を慎重に処理する必要があります。
An example is the Simple Network Management Protocol (SNMP) Structure of Managed Information (SMI). Guidelines exist for defining the Management Information Base (MIB) objects that SNMP carries [RFC4181]. Also, multiple textual conventions have been published, so that MIB designers do not have to "reinvent the wheel" when they need a commonly encountered construct. For example, "Textual Conventions for Internet Network Addresses" [RFC4001] can be used by any MIB designer needing to define objects containing IP addresses, thus ensuring consistency as the body of MIBs is extended.
例は、管理情報の簡易ネットワーク管理プロトコル（SNMP）構造（SMI）です。 SNMPが運ぶ管理情報ベース（MIB）オブジェクトを定義するためのガイドラインが存在します[RFC4181]。また、複数のテキスト表記法が公開されているため、MIB設計者は、一般的に遭遇する構造を必要とするときに「車輪を再発明」する必要がありません。たとえば、「インターネットネットワークアドレスのテキスト規約」[RFC4001]は、IPアドレスを含むオブジェクトを定義する必要があるMIB設計者が使用できるため、MIBの本体が拡張されるときに一貫性を確保できます。
In some protocols, the parameter space either has no specified limit (e.g., Header field names) or is sufficiently large that it is unlikely to be exhausted. In other protocols, the parameter space is limited and, in some cases, has proven inadequate to accommodate demand. Common mistakes include:
一部のプロトコルでは、パラメータースペースに指定された制限がない（ヘッダーフィールド名など）か、十分に大きいため、使い果たされる可能性が低いです。他のプロトコルでは、パラメータスペースが制限されており、場合によっては需要に対応するのに不十分であることが判明しています。一般的な間違いは次のとおりです。
a. A version field that is too small (e.g., two bits or less). When designing a version field, existing as well as potential versions of a protocol need to be taken into account. For example, if a protocol is being standardized for which there are existing implementations with known interoperability issues, more than one version for "pre-standard" implementations may be required. If two "pre-standard" versions are required in addition to a version for an IETF Standard, then a two-bit version field would only leave one additional version code point for a future update, which could be insufficient. This problem was encountered during the development of the PEAPv2 protocol [PEAP].
a。小さすぎる（たとえば、2ビット以下の）バージョンフィールド。バージョンフィールドを設計するときは、プロトコルの既存のバージョンと潜在的なバージョンを考慮する必要があります。たとえば、既知の相互運用性の問題を持つ既存の実装があるプロトコルが標準化されている場合、「先行標準」実装の複数のバージョンが必要になる場合があります。 IETF標準のバージョンに加えて2つの「先行標準」バージョンが必要な場合、2ビットバージョンフィールドは、将来の更新のために1つの追加バージョンコードポイントしか残さないため、不十分な場合があります。この問題は、PEAPv2プロトコル[PEAP]の開発中に発生しました。
b. A small parameter space (e.g., 8 bits or less) along with a First Come, First Served (FCFS) allocation policy [RFC5226]. In general, an FCFS allocation policy is only appropriate in situations where parameter exhaustion is highly unlikely. In situations where substantial demand is anticipated within a parameter space, the space should either be designed to be sufficient to handle that demand, or vendor extensibility should be provided to enable vendors to self-allocate. The combination of a small parameter space, an FCFS allocation policy, and no support for vendor extensibility is particularly likely to prove ill-advised. An example of such a combination was the design of the original 8-bit EAP Type space [RFC2284].
b. 小さなパラメータスペース（8ビット以下など）と先着順（FCFS）割り当てポリシー[RFC5226]。一般に、FCFS割り当てポリシーは、パラメータが枯渇する可能性が非常に低い状況でのみ適切です。パラメータスペース内でかなりの需要が予想される状況では、スペースはその需要を処理するのに十分であるように設計するか、ベンダーが自己割り当てできるようにベンダーの拡張性を提供する必要があります。小さなパラメータースペース、FCFS割り当てポリシー、およびベンダーの拡張性のサポートがないことの組み合わせは、特に不適切であることが判明する可能性があります。そのような組み合わせの例は、元の8ビットEAPタイプスペース[RFC2284]の設計でした。
Once the potential for parameter exhaustion becomes apparent, it is important that it be addressed as quickly as possible. Protocol changes can take years to appear in implementations and by then the exhaustion problem could become acute.
パラメータの枯渇の可能性が明らかになったら、できるだけ早く対処することが重要です。プロトコルの変更が実装に反映されるまでには何年もかかる可能性があり、それまでに消耗の問題が深刻になる可能性があります。
Options for addressing a protocol parameter exhaustion problem include:
プロトコルパラメータの枯渇問題に対処するためのオプションは次のとおりです。
Rethinking the allocation regime Where it becomes apparent that the size of a parameter space is insufficient to meet demand, it may be necessary to rethink the allocation mechanism, in order to prevent or delay parameter space exhaustion. In revising parameter allocation mechanisms, it is important to consider both supply and demand aspects so as to avoid unintended consequences such as self-allocation or the development of black markets for the resale of protocol parameters.
割り当てレジームの再考パラメータ空間のサイズが需要を満たすには不十分であることが明らかになった場合、パラメータ空間の枯渇を防止または遅延させるために、割り当てメカニズムを再考する必要があるかもしれません。パラメータ割り当てメカニズムを改訂する際には、自己割り当てやプロトコルパラメータの再販のための闇市場の開発などの意図しない結果を回避するために、供給と需要の両方の側面を考慮することが重要です。
For example, a few years after publication of PPP EAP [RFC2284] in 1998, it became clear that the combination of an FCFS allocation policy [RFC5226] and lack of support for vendor-extensions had created the potential for exhaustion of the EAP Method Type space within a few years. To address the issue, Section 6.2 of the 2004 update [RFC3748] changed the allocation policy for EAP Method Types from FCFS to Expert Review, with Specification Required. Since this allocation policy revision did not change the demand for EAP Method Types, it would have been likely to result in self-allocation within the standards space had mechanisms not been provided to expand the Method Type space (including support for vendor-specific method types).
たとえば、1998年にPPP EAP [RFC2284]が公開されてから数年後、FCFS割り当てポリシー[RFC5226]とベンダー拡張のサポートの欠如の組み合わせにより、EAPメソッドタイプが使い果たされる可能性があることが明らかになりました。数年以内のスペース。この問題に対処するため、2004年の更新[RFC3748]のセクション6.2では、仕様が必要なEAPメソッドタイプの割り当てポリシーをFCFSからExpert Reviewに変更しました。この割り当てポリシーの改訂によりEAPメソッドタイプの需要が変更されなかったため、メソッドタイプスペースを拡張するメカニズムが提供されていなかった場合、ベンダー固有のメソッドタイプのサポートを含め、標準スペース内での自己割り当てが発生する可能性がありました。 ）。
Support for vendor-specific parameters If the demand that cannot be accommodated is being generated by vendors, merely making allocation harder could make things worse if this encourages vendors to self-allocate, creating interoperability problems. In such a situation, support for vendor-specific parameters should be considered, allowing each vendor to self-allocate within their own vendor-specific space based on a vendor's Private Enterprise Code (PEC). For example, in the case of the EAP Method Type space, Section 6.2 of the 2004 EAP specification [RFC3748] also provided for an Expanded Type space for "functions specific only to one vendor's implementation".
ベンダー固有のパラメータのサポートベンダーが対応できない需要をベンダーが生成している場合、ベンダーが自己割り当てを促し、相互運用性の問題が発生すると、割り当てを難しくするだけで事態が悪化する可能性があります。このような状況では、ベンダー固有のパラメーターのサポートを検討する必要があります。これにより、各ベンダーは、ベンダーのプライベートエンタープライズコード（PEC）に基づいて、独自のベンダー固有のスペース内に自己割り当てできます。たとえば、EAPメソッドタイプスペースの場合、2004年のEAP仕様[RFC3748]のセクション6.2は、「1つのベンダーの実装にのみ固有の機能」のための拡張タイプスペースも提供しました。
Extensions to the parameter space If the goal is to stave off exhaustion in the face of high demand, a larger parameter space may be helpful; this may require a new version of the protocol (such as was required for IPv6). Where vendor-specific parameter support is available, this may be achieved by allocating a PEC for IETF use. Otherwise, it may be necessary to try to extend the size of the parameter fields, which could require a new protocol version or other substantial protocol changes.
パラメータスペースの拡張需要が多い場合に消耗を防ぐことを目標とする場合は、パラメータスペースを大きくすると役立つ場合があります。これには、新しいバージョンのプロトコルが必要になる場合があります（IPv6に必要なものなど）。ベンダー固有のパラメータサポートが利用可能な場合、IETFで使用するためにPECを割り当てることでこれを実現できます。それ以外の場合は、パラメータフィールドのサイズを拡張する必要があり、新しいプロトコルバージョンやその他の大幅なプロトコル変更が必要になる場合があります。
Parameter reclamation In order to gain time, it may be necessary to reclaim unused parameters. However, it may not be easy to determine whether a parameter that has been allocated is in use or not, particularly if the entity that obtained the allocation no longer exists or has been acquired (possibly multiple times).
パラメータの再生時間を稼ぐために、未使用のパラメータを再生する必要がある場合があります。ただし、割り当てられたパラメーターが使用中かどうかを判別するのは簡単ではない場合があります。特に、割り当てを取得したエンティティーが存在しないか、取得されている場合（おそらく複数回）は、そうでない場合があります。
Parameter transfer When all the above mechanisms have proved infeasible and parameter exhaustion looms in the near future, enabling the transfer of ownership of protocol parameters can be considered as a means for improving allocation efficiency. However, enabling transfer of parameter ownership can be far from simple if the parameter allocation process was not originally designed to enable title searches and ownership transfers.
パラメータの転送上記のメカニズムがすべて実行不可能であることが判明し、近い将来にパラメータの枯渇が迫っている場合、プロトコルパラメータの所有権の転送を有効にすることは、割り当て効率を向上させる手段と見なすことができます。ただし、パラメータの割り当てプロセスがタイトル検索と所有権の転送を可能にするように本来設計されていなかった場合、パラメータの所有権の転送を有効にすることは簡単ではありません。
A parameter allocation process designed to uniquely allocate code points is fundamentally different from one designed to enable title search and transfer. If the only goal is to ensure that a parameter is not allocated more than once, the parameter registry will only need to record the initial allocation. On the other hand, if the goal is to enable transfer of ownership of a protocol parameter, then it is important not only to record the initial allocation, but also to track subsequent ownership changes, so as to make it possible to determine and transfer the title. Given the difficulty of converting from a unique allocation regime to one requiring support for title search and ownership transfer, it is best for the desired capabilities to be carefully thought through at the time of registry establishment.
コードポイントを一意に割り当てるように設計されたパラメーター割り当てプロセスは、タイトルの検索と転送を可能にするように設計されたプロセスとは根本的に異なります。パラメータが2回以上割り当てられないようにすることが唯一の目標である場合、パラメータレジストリは初期割り当てのみを記録する必要があります。一方、プロトコルパラメータの所有権の転送を可能にすることを目的とする場合は、初期割り当てを記録するだけでなく、その後の所有権の変更を追跡して、決定と転送を可能にすることが重要です。題名。一意の割り当て方式から、タイトル検索と所有権移転のサポートを必要とするものへの変換が困難であることを考えると、レジストリの確立時に必要な機能を慎重に検討するのが最善です。
Extensibility with respect to cryptographic algorithms is desirable in order to provide resilience against the compromise of any particular algorithm. Section 3 of "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management" BCP 132 [RFC4962] provides some basic advice:
暗号化アルゴリズムに関する拡張性は、特定のアルゴリズムの侵害に対する回復力を提供するために望ましいです。 「認証、承認、アカウンティング（AAA）鍵管理のガイダンス」のセクション3 BCP 132 [RFC4962]は、いくつかの基本的なアドバイスを提供します。
The ability to negotiate the use of a particular cryptographic
algorithm provides resilience against compromise of a particular
cryptographic algorithm.... This is usually accomplished by
including an algorithm identifier and parameters in the protocol,
and by specifying the algorithm requirements in the protocol
specification. While highly desirable, the ability to negotiate
key derivation functions (KDFs) is not required. For
interoperability, at least one suite of mandatory-to-implement
algorithms MUST be selected....
This requirement does not mean that a protocol must support both public-key and symmetric-key cryptographic algorithms. It means that the protocol needs to be structured in such a way that multiple public-key algorithms can be used whenever a public-key algorithm is employed. Likewise, it means that the protocol needs to be structured in such a way that multiple symmetric-key algorithms can be used whenever a symmetric-key algorithm is employed.
この要件は、プロトコルが公開鍵と対称鍵の両方の暗号化アルゴリズムをサポートする必要があることを意味するものではありません。これは、公開鍵アルゴリズムが使用される場合は常に複数の公開鍵アルゴリズムを使用できるようにプロトコルを構成する必要があることを意味します。同様に、対称鍵アルゴリズムが使用される場合は常に複数の対称鍵アルゴリズムを使用できるようにプロトコルを構成する必要があることを意味します。
In practice, the most difficult challenge in providing cryptographic agility is providing for a smooth transition in the event that a mandatory-to-implement algorithm is compromised. Since it may take significant time to provide for widespread implementation of a previously undeployed alternative, it is often advisable to recommend implementation of alternative algorithms of distinct lineage in addition to those made mandatory-to-implement, so that an alternative algorithm is readily available. If such a recommended alternative is not in place, then it would be wise to issue such a recommendation as soon as indications of a potential weakness surface. This is particularly important in the case of potential weakness in algorithms used to authenticate and integrity-protect the cryptographic negotiation itself, such as KDFs or message integrity checks (MICs). Without secure alternatives to compromised KDF or MIC algorithms, it may not be possible to secure the cryptographic negotiation while retaining backward compatibility.
実際には、暗号化の俊敏性を提供する上で最も困難な課題は、必須から実装へのアルゴリズムが侵害された場合にスムーズな移行を提供することです。以前にデプロイされていない代替の広範な実装を提供するにはかなりの時間がかかる可能性があるため、必須から実装までのアルゴリズムに加えて、異なる系統の代替アルゴリズムの実装を推奨して、代替アルゴリズムがすぐに利用できるようにすることをお勧めします。そのような推奨される代替案が実施されていない場合は、潜在的な脆弱性の兆候が現れ次第、そのような推奨を発行するのが賢明でしょう。これは、KDFやメッセージ整合性チェック（MIC）など、暗号化ネゴシエーション自体の認証と整合性保護に使用されるアルゴリズムに潜在的な弱点がある場合に特に重要です。侵害されたKDFまたはMICアルゴリズムの安全な代替手段がないと、下位互換性を維持しながら暗号化交渉を保護することができない場合があります。
In the past, IETF protocols have been specified to operate over multiple transports. Often the protocol was originally specified to utilize a single transport, but limitations were discovered in subsequent deployment, so that additional transports were subsequently specified.
これまで、IETFプロトコルは複数のトランスポート上で動作するように指定されていました。多くの場合、プロトコルは単一のトランスポートを利用するように指定されていましたが、その後の展開で制限が発見されたため、追加のトランスポートが後で指定されました。
In a number of cases, the protocol was originally specified to operate over UDP, but subsequent operation disclosed one or more of the following issues, leading to the specification of alternative transports:
多くの場合、プロトコルはもともとUDPで動作するように指定されていましたが、その後の動作で次の問題の1つまたは複数が明らかになり、代替トランスポートが指定されました。
a. Payload fragmentation (often due to the introduction of extensions or additional usage scenarios);
a. ペイロードの断片化（多くの場合、拡張機能の導入または追加の使用シナリオが原因です）。
b. Problems with congestion control, transport reliability, or efficiency; and
b. 輻輳制御、輸送の信頼性、または効率に関する問題。そして
c. Lack of deployment in multicast scenarios, which had been a motivator for UDP transport.
c. UDPトランスポートの動機であった、マルチキャストシナリオでの展開の欠如。
On the other hand, there are also protocols that were originally specified to operate over reliable transport that have subsequently defined transport over UDP, due to one or more of the following issues:
一方、次の1つまたは複数の問題により、信頼性の高いトランスポートで動作するように最初に指定されたプロトコルがあり、その後UDPでトランスポートを定義しました。
a. NAT traversal concerns that were more easily addressed with UDP transport;
a. UDPトランスポートでより簡単に対処されたNATトラバーサルの懸念。
b. Scalability problems, which could be improved by UDP transport.
b. UDPトランスポートによって改善できるスケーラビリティの問題。
Since specification of a single transport offers the highest potential for interoperability, protocol designers should carefully consider not only initial but potential future requirements in the selection of a transport protocol. Where UDP transport is selected, the guidance provided in "Unicast UDP Usage Guidelines for Application Designers" [RFC5405] should be taken into account.
単一のトランスポートの仕様は相互運用性の可能性が最も高いため、プロトコル設計者は、トランスポートプロトコルの選択において、初期だけでなく将来の要件も慎重に検討する必要があります。 UDPトランスポートが選択されている場合、「アプリケーション設計者のためのユニキャストUDP使用ガイドライン」[RFC5405]で提供されるガイダンスを考慮する必要があります。
After significant deployment has occurred, there are few satisfactory options for addressing problems with the originally selected transport protocol. While specification of additional transport protocols is possible, removal of a widely used transport protocol is likely to result in interoperability problems and should be avoided.
重要な展開が行われた後、最初に選択されたトランスポートプロトコルの問題に対処するための満足できるオプションはほとんどありません。追加のトランスポートプロトコルを指定することは可能ですが、広く使用されているトランスポートプロトコルを削除すると相互運用性の問題が発生する可能性があるため、回避する必要があります。
Mandating support for the initially selected transport protocol while designating additional transport protocols as optional may have limitations. Since optional transport protocols are typically introduced due to the advantages they afford in certain scenarios, in those situations, implementations not supporting optional transport protocols may exhibit degraded performance or may even fail.
追加のトランスポートプロトコルをオプションとして指定しながら、最初に選択されたトランスポートプロトコルのサポートを必須にすると、制限が生じる場合があります。オプションのトランスポートプロトコルは、特定のシナリオで得られる利点のために通常導入されるため、そのような状況では、オプションのトランスポートプロトコルをサポートしない実装がパフォーマンスの低下を示したり、失敗することさえあります。
While mandating support for multiple transport protocols may appear attractive, designers need to realistically evaluate the likelihood that implementers will conform to the requirements. For example, where resources are limited (such as in embedded systems), implementers may choose to only support a subset of the mandated transport protocols, resulting in non-interoperable protocol variants.
複数のトランスポートプロトコルのサポートを強制することは魅力的なように見えるかもしれませんが、設計者は、実装者が要件に準拠する可能性を現実的に評価する必要があります。たとえば、リソースが限られている場合（組み込みシステムなど）、実装者は必須のトランスポートプロトコルのサブセットのみをサポートすることを選択する場合があり、その結果、相互運用できないプロトコルバリアントが生じます。
IETF protocols have utilized several techniques for the handling of unknown extensions. One technique (often used for vendor-specific extensions) is to specify that unknown extensions be "silently discarded".
IETFプロトコルは、未知の拡張を処理するためにいくつかの手法を利用しています。 （ベンダー固有の拡張によく使用される）1つの手法は、不明な拡張を「サイレントに破棄」するように指定することです。
While this approach can deliver a high level of interoperability, there are situations in which it is problematic. For example, where security functionality is involved, "silent discard" may not be satisfactory, particularly if the recipient does not provide feedback as to whether or not it supports the extension. This can lead to operational security issues that are difficult to detect and correct, as noted in Appendix A.2 and in Section 2.5 of "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC5080].
このアプローチは高いレベルの相互運用性を提供できますが、問題が発生する場合があります。たとえば、セキュリティ機能が関係している場合、特に受信者が拡張機能をサポートしているかどうかについてフィードバックを提供しない場合、「サイレント破棄」は満足できない場合があります。これは、付録A.2および「一般的なリモート認証ダイヤルインユーザーサービス（RADIUS）の実装の問題と推奨される修正」[RFC5080]のセクション2.5に記載されているように、検出および修正が難しい運用セキュリティの問題につながる可能性があります。
In order to ensure that a recipient supports an extension, a recipient encountering an unknown extension may be required to explicitly reject it and to return an error, rather than ignoring the unknown extension and proceeding with the remainder of the message. This can be accomplished via a "Mandatory" bit in a TLV-based protocol such as the Layer 2 Tunneling Protocol (L2TP) [RFC2661], or a "Require" or "Proxy-Require" header in a text-based protocol such as SIP [RFC3261] or HTTP [RFC2616].
受信者が拡張機能をサポートしていることを確認するために、不明な拡張機能を無視してメッセージの残りの部分を続行するのではなく、不明な拡張機能に遭遇した受信者は、明示的に拒否してエラーを返す必要があります。これは、レイヤー2トンネリングプロトコル（L2TP）[RFC2661]などのTLVベースのプロトコルの「必須」ビット、またはテキストベースのプロトコルのような「必須」または「プロキシー必須」ヘッダーを介して実現できます。 SIP [RFC3261]またはHTTP [RFC2616]。
Since a mandatory extension can result in an interoperability failure when communicating with a party that does not support the extension, this designation may not be permitted for vendor-specific extensions and may only be allowed for Standards Track extensions. To enable fallback operation with degraded functionality, it is good practice for the recipient to indicate the reason for the failure, including a list of unsupported extensions. The initiator can then retry without the offending extensions.
必須の拡張機能は、拡張機能をサポートしないパーティと通信するときに相互運用性の障害を引き起こす可能性があるため、この指定はベンダー固有の拡張機能では許可されず、Standards Track拡張機能でのみ許可される場合があります。機能が低下したフォールバック操作を有効にするには、サポートされていない拡張機能のリストを含め、受信者が失敗の理由を示すことをお勧めします。その後、イニシエーターは問題の拡張機能なしで再試行できます。
Typically, only the recipient will find itself in the position of rejecting a mandatory extension, since the initiator can explicitly indicate which extensions are supported, with the recipient choosing from among the supported extensions. This can be accomplished via an exchange of TLVs, such as in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5996] or Diameter [RFC3588], or via use of "Accept", "Accept-Encoding", "Accept-Language", "Allow", and "Supported" headers in a text-based protocol such as SIP [RFC3261] or HTTP [RFC2616].
通常、受信者のみが必須の拡張子を拒否する立場にあります。開始者はサポートされている拡張子を明示的に示すことができ、受信者はサポートされている拡張子から選択するためです。これは、インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）[RFC5996]またはDiameter [RFC3588]などのTLVの交換を介して、または「Accept」、「Accept-Encoding」、「Accept-Languageの使用を介して実現できます。 SIP、[RFC3261]、HTTP [RFC2616]などのテキストベースのプロトコルの "、" Allow "、および" Supported "ヘッダー。
An extension must not introduce new security risks without also providing adequate countermeasures; in particular, it must not inadvertently defeat security measures in the unextended protocol. Thus, the security analysis for an extension needs to be as thorough as for the original protocol -- effectively, it needs to be a regression analysis to check that the extension doesn't inadvertently invalidate the original security model.
拡張機能は、適切な対策を講じることなく、新しいセキュリティリスクを導入してはなりません。特に、拡張されていないプロトコルのセキュリティ対策を誤って無効にしてはなりません。したがって、拡張機能のセキュリティ分析は、元のプロトコルと同様に徹底する必要があります。事実上、拡張機能が元のセキュリティモデルを誤って無効にしないことを確認するための回帰分析である必要があります。
This analysis may be simple (e.g., adding an extra opaque data element is unlikely to create a new risk) or quite complex (e.g., adding a handshake to a previously stateless protocol may create a completely new opportunity for an attacker).
この分析は単純な場合（たとえば、不透明なデータ要素を追加しても新しいリスクが発生する可能性は低い）または非常に複雑な場合があります（たとえば、以前のステートレスプロトコルにハンドシェイクを追加すると、攻撃者にとってまったく新しい機会が作成される可能性があります）。
When the extensibility of a design includes allowing for new and presumably more powerful cryptographic algorithms to be added, particular care is needed to ensure that the result is, in fact, increased security. For example, it may be undesirable from a security viewpoint to allow negotiation down to an older, less secure algorithm.
設計の拡張性が、新しい、おそらくより強力な暗号化アルゴリズムの追加を可能にすることを含む場合、結果が実際にセキュリティを確実に高めるように、特別な注意が必要です。たとえば、古い、安全性の低いアルゴリズムへのネゴシエーションを許可することは、セキュリティの観点から望ましくない場合があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4775] Bradner, S., Carpenter, B., Ed., and T. Narten, "Procedures for Protocol Extensions and Variations", BCP 125, RFC 4775, December 2006.
[RFC4775] Bradner、S.、Carpenter、B.、Ed。、およびT. Narten、「Procedures for Protocol Extensions and Variations」、BCP 125、RFC 4775、2006年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[ERROR-HANDLING] Scudder, J., Chen, E., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", Work in Progress, June 2012.
[エラー処理] Scudder、J.、Chen、E.、Mohapatra、P。、およびK. Patel、「BGP UPDATEメッセージのエラー処理の改訂版」、作業中、2012年6月。
[ID-COMPARISON] Thaler, D., "Issues in Identifier Comparison for Security Purposes", Work in Progress, August 2012.
[ID-COMPARISON] Thaler、D。、「Issues in Identifier Comparison for Security Purposes」、Work in Progress、2012年8月。
[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004, December 2004.
[IEEE-802.1X] Institute of Electrical and Electronics Engineers、「Local and Metropolitan Area Networks：Port-Based Network Access Control」、IEEE Standard 802.1X-2004、2004年12月。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, May 2012.
[LISP] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol（LISP）」、Work in Progress、2012年5月。
[PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
[PEAP] Palekar、A.、Simon、D.、Salowey、J.、Zhou、H.、Zorn、G。、およびS. Josefsson、「Protected EAP Protocol（PEAP）Version 2」、Work in Progress、2004年10月。
[PRECIS-FRAMEWORK] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols", Work in Progress, August 2012.
[PRECIS-FRAMEWORK] Saint-Andre、P.およびM. Blanchet、「PRECIS Framework：Preparation and Comparison of Internationalized Strings in Application Protocols」、Work in Progress、2012年8月。
[PRECIS-STATEMENT] Blanchet, M. and A. Sullivan, "Stringprep Revision and PRECIS Problem Statement", Work in Progress, August 2012.
[PRECIS-STATEMENT] Blanchet、M.およびA. Sullivan、「Stringprep Revision and PRECIS Problem Statement」、Work in Progress、2012年8月。
[RFC822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES", STD 11, RFC 822, August 1982.
[RFC822]クロッカー、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered Harmful", RFC 1263, October 1991.
[RFC1263] O'Malley、S。およびL. Peterson、「有害なTCP拡張機能」、RFC 1263、1991年10月。
[RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, June 1992.
[RFC1341] Borenstein、N。およびN. Freed、「MIME（多目的インターネットメール拡張）：インターネットメッセージ本文の形式を指定および説明するためのメカニズム」、RFC 1341、1992年6月。
[RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 1993.
[RFC1521] Borenstein、N。およびN. Freed、「MIME（多目的インターネットメール拡張）パート1：インターネットメッセージ本文の形式を指定および記述するためのメカニズム」、RFC 1521、1993年9月。
[RFC2058] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2058, January 1997.
[RFC2058] Rigney、C.、Rubens、A.、Simpson、W。、およびS. Willens、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2058、1997年1月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月。
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2284] Blunk、L。およびJ. Vollbrecht、「PPP Extensible Authentication Protocol（EAP）」、RFC 2284、1998年3月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「Definition of the Differentiated Services Field（DS Field）in the IPv4 and IPv6 Headers」、RFC 2474、1998年12月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC2661]タウンズリー、W。、バレンシア、A。、ルーベンス、A。、ポール、G。、ゾーン、G。、およびB.パルター、「レイヤー2トンネリングプロトコル "L2TP"」、RFC 2661、1999年8月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P。、編、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[RFC2882] Mitton, D., "Network Access Servers Requirements: Extended RADIUS Practices", RFC 2882, July 2000.
[RFC2882]ミトンD.、「ネットワークアクセスサーバーの要件：拡張RADIUSプラクティス」、RFC 2882、2000年7月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095] Bormann、C.、Burmeister、C.、Degermark、M。、福島、H.、Hannu、H.、Jonsson、LE。、Hakenberg、R.、Koren、T.、Le、K.、Liu、 Z.、Martensson、A。、宮崎、A.、Svanbro、K.、Wiebke、T。、吉村、T。、およびH. Zheng、「RObust Header Compression（ROHC）：Framework and 4 profiles：RTP、UDP、 ESP、および非圧縮」、RFC 3095、2001年7月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", RFC 3427, December 2002.
[RFC3427] Mankin、A.、Bradner、S.、Mahy、R.、Willis、D.、Ott、J。、およびB. Rosen、「セッション開始プロトコル（SIP）の変更プロセス」、RFC 3427、12月2002年
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RFC3575] Aboba、B。、「RADIUS（リモート認証ダイヤルインユーザーサービス）に関するIANAの考慮事項」、RFC 3575、2003年7月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「Diameter Base Protocol」、RFC 3588、2003年9月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597] Gustafsson、A。、「未知のDNSリソースレコード（RR）タイプの処理」、RFC 3597、2003年9月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]ナルテン、T。、「実験的およびテスト番号の割り当ては有用と見なされた」、BCP 82、RFC 3692、2004年1月。
[RFC3735] Hollenbeck, S., "Guidelines for Extending the Extensible Provisioning Protocol (EPP)", RFC 3735, March 2004.
[RFC3735] Hollenbeck、S。、「Extensible Provisioning Protocol（EPP）を拡張するためのガイドライン」、RFC 3735、2004年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、編、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October 2004.
[RFC3935] Alvestrand、H。、「IETFのミッションステートメント」、BCP 95、RFC 3935、2004年10月。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
[RFC4001] Daniele、M.、Haberman、B.、Routhier、S。、およびJ. Schoenwaelder、「インターネットネットワークアドレスのテキスト表記法」、RFC 4001、2005年2月。
[RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
[RFC4181]ハード、C。、編、「MIBドキュメントの作成者とレビュー担当者のためのガイドライン」、BCP 111、RFC 4181、2005年9月。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[RFC4366] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 4366、2006年4月。
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)", RFC 4485, May 2006.
[RFC4485] Rosenberg、J。およびH. Schulzrinne、「Session Initiation Protocol（SIP）の拡張機能の作成者向けガイドライン」、RFC 4485、2006年5月。
[RFC4521] Zeilenga, K., "Considerations for Lightweight Directory Access Protocol (LDAP) Extensions", BCP 118, RFC 4521, June 2006.
[RFC4521] Zeilenga、K。、「ライトウェイトディレクトリアクセスプロトコル（LDAP）拡張の考慮事項」、BCP 118、RFC 4521、2006年6月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727] Fenner、B。、「IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験値」、RFC 4727、2006年11月。
[RFC4929] Andersson, L., Ed., and A. Farrel, Ed., "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 2007.
[RFC4929] Andersson、L.、Ed。、and A. Farrel、Ed。、 "Change Process for Multiprotocol Label Switching（MPLS）and Generalized MPLS（GMPLS）Protocols and Procedures"、BCP 129、RFC 4929、June 2007。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962] Housley、R。およびB. Aboba、「認証、承認、およびアカウンティング（AAA）キー管理のガイダンス」、BCP 132、RFC 4962、2007年7月。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080] Nelson、D。およびA. DeKok、「Common Remote Authentication Dial In User Service（RADIUS）Implementation Issues and Suggested Fixes」、RFC 5080、2007年12月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P.、Ed。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, July 2008.
[RFC5218]ターラー、D。、およびB.アボバ、「成功するプロトコルを作るもの」、RFC 5218、2008年7月。
[RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, April 2008.
[RFC5225] Pelletier、G。およびK. Sandlund、「RObust Header Compression Version 2（ROHCv2）：Profiles for RTP、UDP、IP、ESP and UDP-Lite」、RFC 5225、2008年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーション設計者のためのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、2008年11月。
[RFC5421] Cam-Winget, N. and H. Zhou, "Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", RFC 5421, March 2009.
[RFC5421] Cam-Winget、N。およびH. Zhou、「Secure Tunneling Extensible Authentication Protocol（EAP-FAST）による柔軟な認証内の基本的なパスワード交換」、RFC 5421、2009年3月。
[RFC5422] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", RFC 5422, March 2009.
[RFC5422] Cam-Winget、N.、McGrew、D.、Salowey、J。、およびH. Zhou、「Secure Tunneling Extensible Authentication Protocol（EAP-FAST）による柔軟な認証を使用したダイナミックプロビジョニング」、RFC 5422、2009年3月。
[RFC5704] Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated Protocol Development Considered Harmful", RFC 5704, November 2009.
[RFC5704]ブライアント、S。、エド、モロー、M。、エド、およびIAB、「有害な非協調型プロトコル開発」、RFC 5704、2009年11月。
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010.
[RFC5727] Peterson、J.、Jennings、C。、およびR. Sparks、「Session Initiation Protocol（SIP）およびReal-time Applications and Infrastructure Areaの変更プロセス」、BCP 67、RFC 5727、2010年3月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキー交換プロトコルバージョン2（IKEv2）」、RFC 5996、2010年9月。
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on Encodings for Internationalized Domain Names", RFC 6055, February 2011.
[RFC6055] Thaler、D.、Klensin、J。、およびS. Cheshire、「IAB Thoughts on Encodings for Internationalized Domain Names」、RFC 6055、2011年2月。
[RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011.
[RFC6158] DeKok、A.、Ed。、およびG. Weber、「RADIUS Design Guidelines」、BCP 158、RFC 6158、2011年3月。
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, June 2012.
[RFC6648]セントアンドレ、P。、クロッカー、D。、およびM.ノッティンガム、「アプリケーションプロトコルでの「X-」プレフィックスと同様の構成の非推奨」、BCP 178、RFC 6648、2012年6月。
This document is heavily based on an earlier draft by Scott Bradner and Thomas Narten, other parts of which were eventually published as RFC 4775.
このドキュメントは、Scott BradnerとThomas Nartenによる以前のドラフトに大きく基づいており、その他の部分は最終的にRFC 4775として公開されました。
That draft stated: "The initial version of this document was put together by the IESG in 2002. Since then, it has been reworked in response to feedback from John Loughney, Henrik Levkowetz, Mark Townsley, Randy Bush and others."
その草案は、「この文書の最初のバージョンは2002年にIESGによってまとめられました。それ以来、ジョン・ラフニー、ヘンリック・レフコウェッツ、マーク・タウンズリー、ランディ・ブッシュなどからのフィードバックに応じて再作成されました」
Valuable comments and suggestions on the current form of the document were made by Loa Andersson, Ran Atkinson, Stewart Bryant, Leslie Daigle, Alan DeKok, Roy Fielding, Phillip Hallam-Baker, Ted Hardie, Alfred Hoenes, John Klensin, Barry Leiba, Eric Rescorla, Adam Roach, and Pekka Savola. The text on TLS experience was contributed by Yngve Pettersen.
ドキュメントの現在のフォームに関する貴重なコメントと提案は、ロアアンダーソン、ランアトキンソン、スチュワートブライアント、レスリーデイグル、アランデコック、ロイフィールディング、フィリップハラムベイカー、テッドハーディ、アルフレッドホーネス、ジョンクレシン、バリーレイバ、エリックが行いましたRescorla、Adam Roach、Pekka Savola。 TLSエクスペリエンスに関するテキストはYngve Pettersenによって寄稿されました。
Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Spencer Dawkins Joel Halpern Russ Housley David Kessens Danny McPherson Jon Peterson Dave Thaler Hannes Tschofenig
バーナードアボバジャリアルコマルクブランシェロスカロンアリッサクーパースペンサードーキンスジョエルハルパーンラスハウズリーデビッドケセンスダニーマクファーソンジョンピーターソンデイブターラーハネスチョーフェニグ
This section discusses some specific examples as case studies.
このセクションでは、ケーススタディとしていくつかの特定の例について説明します。
There are certain documents that specify a change process or describe extension considerations for specific IETF protocols:
変更プロセスを指定するか、特定のIETFプロトコルの拡張に関する考慮事項を説明する特定のドキュメントがあります。
The SIP change process [RFC3427], [RFC4485], [RFC5727]
The (G)MPLS change process (mainly procedural) [RFC4929]
LDAP extensions [RFC4521]
EPP extensions [RFC3735]
DNS extensions [RFC2671][RFC3597]
SMTP extensions [RFC5321]
It is relatively common for MIBs, which are all in effect extensions of the SMI data model, to be defined or extended outside the IETF. BCP 111 [RFC4181] offers detailed guidance for authors and reviewers.
事実上すべてSMIデータモデルの拡張であるMIBがIETFの外部で定義または拡張されることは比較的一般的です。 BCP 111 [RFC4181]は、執筆者と査読者に詳細なガイダンスを提供します。
The RADIUS [RFC2865] protocol was designed to be extensible via addition of Attributes. This extensibility model assumed that Attributes would conform to a limited set of data types and that vendor extensions would be limited to use by vendors in situations in which interoperability was not required. Subsequent developments have stretched those assumptions.
RADIUS [RFC2865]プロトコルは、属性を追加することで拡張できるように設計されています。この拡張性モデルでは、属性が限られたデータ型のセットに準拠し、相互運用性が不要な状況でベンダー拡張がベンダーによる使用に限定されると想定していました。その後の展開により、これらの仮定は拡大しました。
From the beginning, uses of the RADIUS protocol extended beyond the scope of the original protocol definition (and beyond the scope of the RADIUS Working Group charter). In addition to rampant self-allocation within the limited RADIUS standard attribute space, vendors defined their own RADIUS commands. This led to the rapid proliferation of vendor-specific protocol variants. To this day, many common implementation practices have not been documented. For example, authentication server implementations are often typically based on a Data Dictionary, enabling addition of Attributes without requiring code changes. Yet, the concept of a Data Dictionary is not mentioned in the RADIUS specification [RFC2865].
当初から、RADIUSプロトコルの使用は、元のプロトコル定義の範囲を超えて（そしてRADIUSワーキンググループ憲章の範囲を超えて）拡張されました。ベンダーは、限られたRADIUS標準属性スペース内で蔓延する自己割り当てに加えて、独自のRADIUSコマンドを定義しました。これにより、ベンダー固有のプロトコルバリアントが急速に普及しました。今日まで、多くの一般的な実装方法は文書化されていません。たとえば、認証サーバーの実装は通常、データディクショナリに基づいていることが多く、コードを変更せずに属性を追加できます。しかし、RADIUS仕様[RFC2865]では、データディクショナリの概念については触れられていません。
As noted in "Extended RADIUS Practices" [RFC2882], Section 1:
「拡張RADIUSプラクティス」[RFC2882]のセクション1に記載されているとおり：
The RADIUS Working Group was formed in 1995 to document the protocol of the same name, and was chartered to stay within a set of bounds for dial-in terminal servers. Unfortunately the real world of Network Access Servers (NASes) hasn't stayed that small and simple, and continues to evolve at an amazing rate.
RADIUSワーキンググループは、同じ名前のプロトコルを文書化するために1995年に設立され、ダイヤルインターミナルサーバーの一連の境界内に留まるように設立されました。残念ながら、ネットワークアクセスサーバー（NAS）の現実はそれほど小さく単純なものではなく、驚くべき速度で進化し続けています。
This document shows some of the current implementations on the market have already outstripped the capabilities of the RADIUS protocol. A quite a few features have been developed completely outside the protocol. These features use the RADIUS protocol structure and format, but employ operations and semantics well beyond the RFC documents.
このドキュメントは、市場での現在の実装のいくつかが、RADIUSプロトコルの機能をすでに上回っていることを示しています。かなりの数の機能が完全にプロトコルの外で開発されました。これらの機能は、RADIUSプロトコルの構造と形式を使用しますが、RFCドキュメントをはるかに超える操作とセマンティクスを採用しています。
The limited set of data types defined in the RADIUS specification [RFC2865] led to subsequent documents defining new data types. Since new data types are typically defined implicitly as part of defining a new attribute and because RADIUS client and server implementations differ in their support of these additional specifications, there is no definitive registry of RADIUS data types, and data type support has been inconsistent. To catalog commonly implemented data types as well as to provide guidance for implementers and attribute designers, Section 2.1 of "RADIUS Design Guidelines" [RFC6158] includes advice on basic and complex data types. Unfortunately, these guidelines [RFC6158] were published in 2011, 14 years after the RADIUS protocol was first documented [RFC2058] in 1997.
RADIUS仕様[RFC2865]で定義されたデータタイプの制限されたセットは、新しいデータタイプを定義する後続のドキュメントにつながりました。新しいデータ型は通常、新しい属性の定義の一部として暗黙的に定義され、RADIUSクライアントとサーバーの実装ではこれらの追加仕様のサポートが異なるため、RADIUSデータ型の明確なレジストリはなく、データ型のサポートは一貫していません。一般的に実装されるデータ型をカタログ化し、実装者と属性設計者にガイダンスを提供するために、「RADIUS設計ガイドライン」[RFC6158]のセクション2.1には、基本および複雑なデータ型に関するアドバイスが含まれています。残念ながら、これらのガイドライン[RFC6158]は、RADIUSプロトコルが最初に文書化されて[RFC2058]になった14年後の2011年に1997年に公開されました。
Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism for Vendor-Specific extensions (Attribute 26) and states that use of Vendor-Specific extensions:
RADIUS仕様[RFC2865]のセクション6.2では、ベンダー固有の拡張機能（属性26）のメカニズムを定義し、ベンダー固有の拡張機能の使用について次のように述べています。
should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful.
相互運用性が役に立たないと見なされるRADIUSの1つのベンダーの実装にのみ固有の機能のために、グローバル属性タイプの割り当ての代わりに推奨されるべきです。
However, in practice, usage of Vendor-Specific Attributes (VSAs) has been considerably broader than this. In particular, VSAs have been used by Standards Development Organizations (SDOs) to define their own extensions to the RADIUS protocol. This has caused a number of problems.
ただし、実際には、Vendor-Specific Attributes（VSA）の使用はこれよりもかなり広範です。特に、VSAは標準開発機関（SDO）がRADIUSプロトコルへの独自の拡張を定義するために使用されています。これは多くの問題を引き起こしています。
One issue concerns the data model for VSAs. Since it was not envisaged that multi-vendor VSA implementations would need to interoperate, the RADIUS specification [RFC2865] does not define the data model for VSAs and allows multiple sub-attributes to be included within a single Attribute of type 26. Since this enables VSAs to be defined that would not be supportable by current implementations if placed within the standard RADIUS attribute space, this has caused problems in standardizing widely deployed VSAs, as discussed in Section 2.4 of "RADIUS Design Guidelines" BCP 158 [RFC6158]:
1つの問題は、VSAのデータモデルに関するものです。マルチベンダーVSA実装が相互運用する必要があるとは想定されていなかったため、RADIUS仕様[RFC2865]はVSAのデータモデルを定義せず、タイプ26の単一の属性内に複数のサブ属性を含めることを許可しています。 「RADIUS設計ガイドライン」BCP 158 [RFC6158]のセクション2.4で説明されているように、標準のRADIUS属性スペース内に配置した場合、現在の実装ではサポートできないVSAが定義されるため、広く展開されているVSAの標準化で問題が発生しました。
RADIUS attributes can often be developed within the vendor space without loss (and possibly even with gain) in functionality. As a result, translation of RADIUS attributes developed within the vendor space into the standard space may provide only modest benefits, while accelerating the exhaustion of the standard space. We do not expect that all RADIUS attribute specifications requiring interoperability will be developed within the IETF, and allocated from the standard space. A more scalable approach is to recognize the flexibility of the vendor space, while working toward improvements in the quality and availability of RADIUS attribute specifications, regardless of where they are developed.
RADIUSの属性は、多くの場合、機能を損なうことなく（場合によっては向上させても）ベンダースペース内で開発できます。その結果、ベンダースペース内で開発されたRADIUS属性を標準スペースに変換しても、標準スペースの枯渇を加速させながら、適度なメリットしか得られない可能性があります。相互運用性を必要とするすべてのRADIUS属性仕様がIETF内で開発され、標準スペースから割り当てられるとは限りません。よりスケーラブルなアプローチは、ベンダースペースの柔軟性を認識しながら、開発された場所に関係なく、RADIUS属性仕様の品質と可用性の向上に向けて取り組むことです。
It is therefore NOT RECOMMENDED that specifications intended solely for use by a vendor or SDO be translated into the standard space.
したがって、ベンダーまたはSDOによる使用のみを目的とした仕様を標準スペースに変換することはお勧めしません。
Another issue is how implementations should handle unknown VSAs. Section 5.26 of the RADIUS specification [RFC2865] states:
別の問題は、実装が未知のVSAをどのように処理するかです。 RADIUS仕様[RFC2865]のセクション5.26には次のように記載されています。
Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.
クライアントから送信されたベンダー固有の情報を解釈する機能を備えていないサーバーは、それを無視する必要があります（報告される場合があります）。必要なベンダー固有の情報を受信しないクライアントは、それなしで動作するように試みるべきです（SHOULD）。
However, since VSAs do not contain a "mandatory" bit, RADIUS clients and servers may not know whether it is safe to ignore unknown VSAs. For example, in the case where VSAs pertain to security (e.g., Filters), it may not be safe to ignore them. As a result, Section 2.5 of "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC5080] includes the following caution:
ただし、VSAには「必須」ビットが含まれていないため、RADIUSクライアントおよびサーバーは、不明なVSAを無視しても安全かどうかを認識できない場合があります。たとえば、VSAがセキュリティ（フィルターなど）に関連している場合、それらを無視しても安全ではない場合があります。その結果、「一般的なリモート認証ダイヤルインユーザーサービス（RADIUS）の実装の問題と推奨される修正」のセクション2.5 [RFC5080]には、次の注意が含まれています。
To avoid misinterpretation of service requests encoded within VSAs, RADIUS servers SHOULD NOT send VSAs containing service requests to RADIUS clients that are not known to understand them. For example, a RADIUS server should not send a VSA encoding a filter without knowledge that the RADIUS client supports the VSA.
VSA内でエンコードされたサービスリクエストの誤解を避けるために、RADIUSサーバーは、サービスリクエストを含むVSAを、それらを理解することが知られていないRADIUSクライアントに送信しないでください。たとえば、RADIUSサーバーは、RADIUSクライアントがVSAをサポートしていることを認識せずに、フィルターをエンコードするVSAを送信しないでください。
In addition to extending RADIUS by use of VSAs, SDOs have also defined new values of the Service-Type attribute in order to create new RADIUS commands. Since the RADIUS specification [RFC2865] defined Service-Type values as being allocated First Come, First Served (FCFS) [RFC5226], this permitted new RADIUS commands to be allocated without IETF review. This oversight has since been fixed in "IANA Considerations for RADIUS" [RFC3575].
VSAを使用してRADIUSを拡張することに加えて、SDOは新しいRADIUSコマンドを作成するために、Service-Type属性の新しい値も定義しています。 RADIUS仕様[RFC2865]ではService-Type値が先着順（FCFS）[RFC5226]として割り当てられると定義されているため、IETFによる確認なしで新しいRADIUSコマンドを割り当てることができました。この見落としは、「RADIUSに関するIANAの考慮事項」[RFC3575]で修正されています。
The Secure Sockets Layer (SSL) Version 2 Protocol was developed by Netscape to be used to secure online transactions on the Internet. It was later replaced by SSLv3, also developed by Netscape. SSLv3 was then further developed by the IETF as the Transport Layer Security (TLS) 1.0 [RFC2246].
Secure Sockets Layer（SSL）バージョン2プロトコルは、インターネット上のオンライントランザクションを保護するためにNetscapeによって開発されました。その後、Netscapeによって開発されたSSLv3に置き換えられました。 SSLv3は、IETFによってトランスポート層セキュリティ（TLS）1.0 [RFC2246]としてさらに開発されました。
The SSLv3 protocol was not explicitly specified to be extended. Even TLS 1.0 did not define an extension mechanism explicitly. However, extension "loopholes" were available. Extension mechanisms were finally defined in "Transport Layer Security (TLS) Extensions" [RFC4366]:
SSLv3プロトコルは、拡張するよう明示的に指定されていません。 TLS 1.0でも、拡張メカニズムを明示的に定義していませんでした。ただし、拡張「抜け穴」は利用可能でした。拡張メカニズムは、「トランスポート層セキュリティ（TLS）拡張」[RFC4366]で最終的に定義されました。
o New versions o New cipher suites o Compression o Expanded handshake messages o New record types o New handshake messages
o 圧縮に関する新しい暗号スイートの新バージョンo拡張ハンドシェイクメッセージo新しいレコードタイプo新しいハンドシェイクメッセージ
The protocol also defines how implementations should handle unknown extensions.
プロトコルはまた、実装が未知の拡張を処理する方法を定義します。
Of the above extension methods, new versions and expanded handshake messages have caused the most interoperability problems. Implementations are supposed to ignore unknown record types but to reject unknown handshake messages.
上記の拡張メソッドの中で、新しいバージョンと拡張されたハンドシェイクメッセージが最も相互運用性の問題を引き起こしています。実装では、不明なレコードタイプは無視しますが、不明なハンドシェイクメッセージは拒否します。
The new version support in SSL/TLS includes a capability to define new versions of the protocol, while allowing newer implementations to communicate with older implementations. As part of this functionality, some Key Exchange methods include functionality to prevent version rollback attacks.
SSL / TLSの新しいバージョンのサポートには、新しい実装が古い実装と通信できるようにしながら、プロトコルの新しいバージョンを定義する機能が含まれています。この機能の一部として、一部のキー交換方式には、バージョンロールバック攻撃を防止する機能が含まれています。
The experience with this upgrade functionality in SSL and TLS is decidedly mixed:
SSLおよびTLSでのこのアップグレード機能の使用経験は明らかに混合しています。
o SSLv2 and SSLv3/TLS are not compatible. It is possible to use SSLv2 protocol messages to initiate an SSLv3/TLS connection, but it is not possible to communicate with an SSLv2 implementation using SSLv3/TLS protocol messages. o There are implementations that refuse to accept handshakes using newer versions of the protocol than they support. o There are other implementations that accept newer versions but have implemented the version rollback protection clumsily.
o SSLv2とSSLv3 / TLSには互換性がありません。 SSLv2プロトコルメッセージを使用してSSLv3 / TLS接続を開始することは可能ですが、SSLv3 / TLSプロトコルメッセージを使用してSSLv2実装と通信することはできません。 oサポートされているよりも新しいバージョンのプロトコルを使用してハンドシェイクの受け入れを拒否する実装があります。 o新しいバージョンを受け入れる他の実装がありますが、バージョンロールバック保護を不器用に実装しています。
The SSLv2 problem has forced SSLv3 and TLS clients to continue to use SSLv2 Client Hellos for their initial handshake with almost all servers until 2006, much longer than would have been desirable, in order to interoperate with old servers.
SSLv2の問題により、SSLv3およびTLSクライアントは、2006年までほとんどすべてのサーバーとの最初のハンドシェイクにSSLv2 Client Hellosを使用し続ける必要がありました。これは、古いサーバーと相互運用するために、必要以上に長い時間です。
The problem with incorrect handling of newer versions has also forced many clients to actually disable the newer protocol versions, either by default or by automatically disabling the functionality, to be able to connect to such servers. Effectively, this means that the version rollback protection in SSL and TLS is non-existent if talking to a fatally compromised older version.
新しいバージョンの不適切な処理の問題により、多くのクライアントは、デフォルトで、または機能を自動的に無効にして、そのようなサーバーに接続できるように、新しいプロトコルバージョンを実際に無効にする必要がありました。事実上、これは、SSLとTLSのバージョンロールバック保護が、致命的に危険にさらされた古いバージョンと通信する場合には存在しないことを意味します。
SSLv3 and TLS also permitted extension of the Client Hello and Server Hello handshake messages. This functionality was fully defined by the introduction of TLS extensions, which make it possible to add new functionality to the handshake, such as the name of the server the client is connecting to, request certificate status information, and indicate Certificate Authority support, maximum record length, etc. Several of these extensions also introduce new handshake messages.
SSLv3およびTLSでは、Client HelloおよびServer Helloハンドシェイクメッセージの拡張も許可されていました。この機能はTLS拡張の導入によって完全に定義されました。これにより、クライアントが接続しているサーバーの名前、証明書ステータス情報の要求、認証局サポートの指定、最大レコードなど、新しい機能をハンドシェイクに追加できます。長さなど。これらの拡張機能のいくつかでは、新しいハンドシェイクメッセージも導入されています。
It has turned out that many SSLv3 and TLS implementations that do not support TLS extensions did not ignore the unknown extensions, as required by the protocol specifications, but instead failed to establish connections. Since several of the implementations behaving in this manner are used by high-profile Internet sites, such as online banking sites, this has caused a significant delay in the deployment of clients supporting TLS extensions, and several of the clients that have enabled support are using heuristics that allow them to disable the functionality when they detect a problem.
TLS拡張をサポートしない多くのSSLv3およびTLS実装は、プロトコル仕様で要求されているように、未知の拡張を無視せず、代わりに接続の確立に失敗したことが判明しました。このように動作する実装のいくつかはオンラインバンキングサイトなどの注目のインターネットサイトで使用されているため、TLS拡張をサポートするクライアントの展開に大幅な遅延が発生し、サポートを有効にしたクライアントのいくつかは問題を検出したときに機能を無効にできるヒューリスティック。
Looking forward, the protocol version problem, in particular, can cause future security problems for the TLS protocol. The strength of the digest algorithms (MD5 and SHA-1) used by SSL and TLS is weakening. If MD5 and SHA-1 weaken to the point where it is feasible to mount successful attacks against older SSL and TLS versions, the current error recovery used by clients would become a security vulnerability (among many other serious problems for the Internet).
特に、プロトコルバージョンの問題は、TLSプロトコルの将来のセキュリティ問題を引き起こす可能性があります。 SSLおよびTLSで使用されるダイジェストアルゴリズム（MD5およびSHA-1）の強度は弱くなっています。 MD5とSHA-1が、古いバージョンのSSLおよびTLSに対して攻撃を仕掛けることが可能になるまで弱体化する場合、クライアントが使用する現在のエラー回復は（インターネットに関する他の多くの深刻な問題の中でも）セキュリティの脆弱性になります。
To address this issue, TLS 1.2 [RFC5246] makes use of a newer cryptographic hash algorithm (SHA-256) during the TLS handshake by default. Legacy ciphersuites can still be used to protect application data, but new ciphersuites are specified for data protection as well as for authentication within the TLS handshake. The hashing method can also be negotiated via a Hello extension. Implementations are encouraged to implement new ciphersuites and to enable the negotiation of the ciphersuite used during a TLS session to be governed by policy, thus enabling a more rapid transition away from weakened ciphersuites.
この問題に対処するために、TLS 1.2 [RFC5246]は、デフォルトでTLSハンドシェイク中に新しい暗号化ハッシュアルゴリズム（SHA-256）を使用します。従来の暗号スイートは引き続きアプリケーションデータの保護に使用できますが、TLSハンドシェイク内の認証だけでなくデータ保護にも新しい暗号スイートが指定されています。ハッシュ方式は、Hello拡張を介してネゴシエートすることもできます。実装では、新しい暗号スイートを実装し、TLSセッション中に使用される暗号スイートのネゴシエーションをポリシーで管理できるようにすることをお勧めします。これにより、脆弱な暗号スイートからの迅速な移行が可能になります。
The lesson to be drawn from this experience is that it isn't sufficient to design extensibility carefully; it must also be implemented carefully by every implementer, without exception. Test suites and certification programs can help provide incentives for implementers to pay attention to implementing extensibility mechanisms correctly.
この経験から得られる教訓は、拡張性を注意深く設計するだけでは十分ではないということです。また、例外なく、すべての実装者が注意深く実装する必要があります。テストスイートと認定プログラムは、実装者が拡張メカニズムを正しく実装することに注意を払うインセンティブを提供するのに役立ちます。
The Layer Two Tunneling Protocol (L2TP) [RFC2661] carries Attribute-Value Pairs (AVPs), with most AVPs having no semantics to the L2TP protocol itself. However, it should be noted that L2TP message types are identified by a Message Type AVP (Attribute Type 0) with specific AVP values indicating the actual message type. Thus, extensions relating to Message Type AVPs would likely be considered major extensions.
レイヤー2トンネリングプロトコル（L2TP）[RFC2661]は属性値ペア（AVP）を伝送し、ほとんどのAVPはL2TPプロトコル自体に対するセマンティクスを持ちません。ただし、L2TPメッセージタイプは、実際のメッセージタイプを示す特定のAVP値を持つメッセージタイプAVP（属性タイプ0）によって識別されることに注意してください。したがって、メッセージタイプAVPに関連する拡張機能は、主要な拡張機能と見なされる可能性があります。
L2TP also provides for vendor-specific AVPs. Because everything in L2TP is encoded using AVPs, it would be easy to define vendor-specific AVPs that would be considered major extensions.
L2TPは、ベンダー固有のAVPも提供します。 L2TPのすべてがAVPを使用してエンコードされているため、主要な拡張機能と見なされるベンダー固有のAVPを簡単に定義できます。
L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP messages containing AVPs that they do not understand but that have the mandatory bit set, are expected to reject the message and terminate the tunnel or session the message refers to. This leads to interesting interoperability issues, because a sender can include a vendor-specific AVP with the M-bit set, which then causes the recipient to not interoperate with the sender. This sort of behavior is counter to the IETF ideals, as implementations of the IETF standard should interoperate successfully with other implementations and not require the implementation of non-IETF extensions in order to interoperate successfully. Section 4.2 of the L2TP specification [RFC2661] includes specific wording on this point, though there was significant debate at the time as to whether such language was by itself sufficient.
L2TPは、AVPの「必須」ビットも提供します。理解できないが必須ビットが設定されているAVPを含むL2TPメッセージの受信者は、メッセージを拒否し、メッセージが参照するトンネルまたはセッションを終了することが期待されます。これは興味深い相互運用性の問題につながります。送信者がベンダー固有のAVPにMビットセットを含めることができるため、受信者が送信者と相互運用できないためです。 IETF標準の実装は他の実装と正常に相互運用でき、相互運用を正常に行うために非IETF拡張の実装を必要としないため、この種の動作はIETFの理想に反しています。 L2TP仕様[RFC2661]のセクション4.2には、この点に関する特定の表現が含まれていますが、そのような言語だけで十分かどうかについては当時かなりの議論がありました。
Fortunately, it does not appear that the potential problems described above have yet become a problem in practice. At the time of this writing, the authors are not aware of the existence of any vendor-specific AVPs that also set the M-bit.
幸いにも、上記の潜在的な問題が実際にはまだ問題になっているようには見えません。この記事の執筆時点では、Mビットを設定するベンダー固有のAVPの存在を筆者は認識していません。
Authors' Addresses
著者のアドレス
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand
ブライアンカーペンターコンピュータサイエンス学部オークランド大学PB 92019オークランド、1142ニュージーランド
EMail: brian.e.carpenter@gmail.com
Bernard Aboba (editor) PMB 606 15600 NE 8th Street, Suite B1 Bellevue, WA 98008 USA
べｒなｒｄ あぼば （えぢとｒ） ＰＭＢ ６０６ １５６００ ね ８ｔｈ Ｓｔれえｔ、 すいて Ｂ１ べっぇゔえ、 わ ９８００８ うさ
EMail: bernard_aboba@hotmail.com
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino、CA 95014 USA
EMail: cheshire@apple.com