[要約] RFC 6994は、実験的なTCPオプションの共有利用に関するガイドラインです。その目的は、実験的なTCPオプションの使用を促進し、ネットワークの進化と改善を支援することです。
Internet Engineering Task Force (IETF) J. Touch
Request for Comments: 6994 USC/ISI
Category: Standards Track August 2013
ISSN: 2070-1721
Shared Use of Experimental TCP Options
試験的なTCPオプションの共有使用
Abstract
概要
This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints.
このドキュメントでは、新しいIANA TCP実験IDを使用して、同じ接続内でも、実験的なTCPオプションコードポイントが複数のTCP拡張を同時にサポートする方法について説明します。このアプローチは、登録されていない実験およびこの共有メカニズムを使用しない実験に対して堅牢です。これらのコードポイントを使用するすべての新しいTCPオプションに推奨されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、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/rfc6994.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6994で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. TCP Experimental Option Structure ...............................4
3.1. Selecting an ExID ..........................................5
3.2. Impact on TCP Option Processing ............................6
4. Reducing the Impact of False Positives ..........................7
5. Migration to Assigned Options ...................................7
6. Rationale .......................................................8
7. Security Considerations .........................................9
8. IANA Considerations .............................................9
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
10. Acknowledgments ...............................................11
TCP includes options to enable new protocol capabilities that can be activated only where needed and supported [RFC793]. The space for identifying such options is small -- 256 values, of which 30 are assigned at the time of this document's publication [IANA]. Two of these codepoints (253, 254) are allocated to support experiments [RFC4727]. These values are intended for testing purposes or for use when an assigned codepoint is either not warranted or available, e.g., based on the maturity status of the defined capability (i.e., Experimental or Informational, rather than Standards Track).
TCPには、必要でサポートされている場所でのみアクティブ化できる新しいプロトコル機能を有効にするオプションが含まれています[RFC793]。そのようなオプションを識別するためのスペースは小さく、256個の値があります。そのうち30個は、このドキュメントの発行時に割り当てられています[IANA]。これらのコードポイントの2つ（253、254）は、実験をサポートするために割り当てられています[RFC4727]。これらの値は、テスト目的、または割り当てられたコードポイントが保証されていないか、利用できない場合に使用することを目的としています。たとえば、定義された機能の成熟度ステータス（つまり、標準トラックではなく試験的または情報的）に基づいています。
Here, the term "experimental TCP options" refers to options that use the TCP experimental option codepoints [RFC4727]. Such experiments can be described in an RFC of any status (e.g., Experimental, Informational, etc.) and are intended to be used in controlled environments and are allowed in public deployments (when not enabled as default [RFC3692]). Nothing prohibits the deployment of multiple experiments in the same environment -- controlled or public. Further, some protocols are specified in Experimental or Informational RFCs, which either include parameters or design choices not yet understood or which might not be widely deployed [RFC2026]. Typically, these TCP options are not eligible to receive assigned codepoints [RFC2780], so they need a way to share their use of the experimental codepoints.
ここで、「実験的TCPオプション」という用語は、TCP実験的オプションコードポイント[RFC4727]を使用するオプションを指します。このような実験は、任意のステータス（実験、情報など）のRFCで記述でき、制御された環境で使用することを目的としており、パブリックデプロイメントで許可されています（デフォルトとして有効になっていない場合[RFC3692]）。同じ環境での複数の実験の展開を禁止するものは何もありません-制御されているか、公開されています。さらに、いくつかのプロトコルは、実験的または情報的RFCで指定されており、まだ理解されていないパラメータまたは設計の選択を含むか、広く展開されていない可能性があります[RFC2026]。通常、これらのTCPオプションは割り当てられたコードポイント[RFC2780]を受け取る資格がないため、実験的なコードポイントの使用を共有する方法が必要です。
There is currently no mechanism to support shared use of the TCP experimental option codepoints, either by different experiments on different connections or for more than two experimental options in the same connection. Experimental options 253 and 254 are already deployed in operational code to support an early version of TCP authentication. Option 253 is also documented for the experimental TCP Cookie Transaction option [RFC6013]. This shared use results in collisions in which a single codepoint can appear multiple times in a single TCP segment and for which each use is ambiguous.
現在、異なる接続での異なる実験による、または同じ接続での3つ以上の実験的オプションのいずれかによる、TCP実験的オプションコードポイントの共有使用をサポートするメカニズムはありません。実験的なオプション253と254は、TCP認証の初期バージョンをサポートするために、運用コードにすでに導入されています。オプション253は、試験的なTCP Cookieトランザクションオプション[RFC6013]についても文書化されています。この共有使用は、単一のコードポイントが単一のTCPセグメントで複数回出現する可能性があり、それぞれの使用があいまいな衝突を引き起こします。
Other codepoints have been used without assignment (known as "squatting"), notably 31-32 (TCP cookie transactions, as originally distributed and in its API doc) and 76-78 (tcpcrypt) [Bi11] [Si11]. Commercial products reportedly also use unassigned options 33, 69-70, and 76-78. Even though these uses are unauthorized, they currently impact legitimate assignees.
他のコードポイントは、割り当てなしで使用され（ "しゃがむ"と呼ばれます）、特に31-32（TCP cookieトランザクション、最初に配布され、そのAPIドキュメントで）および76-78（tcpcrypt）[Bi11] [Si11]。伝えられるところによると、商用製品は割り当てられていないオプション33、69-70、および76-78も使用しています。これらの使用は許可されていませんが、現在は正当な譲受人に影響を与えています。
Both such misuses (squatting on both experimental and assigned codepoints) are expected to continue, but there are several approaches that can alleviate the impact on cooperating protocol designers. One proposal relaxes the requirements for assignment of TCP options, allowing them to be assigned more readily for protocols that have not been standardized through the IETF process [RFC5226]. Another proposal assigns a larger pool to the TCP experiment option codepoints and manages their sharing through IANA coordination [Ed11].
このような誤用（実験的コードポイントと割り当てられたコードポイントの両方で不法占拠）は継続すると予想されますが、協力するプロトコル設計者への影響を軽減できるいくつかのアプローチがあります。 1つの提案は、TCPオプションの割り当ての要件を緩和し、IETFプロセス[RFC5226]を通じて標準化されていないプロトコルにそれらをより簡単に割り当てることができるようにします。別の提案では、TCP実験オプションのコードポイントに大きなプールを割り当て、IANA調整[Ed11]を通じてそれらの共有を管理しています。
The approach proposed in this document does not require additional TCP option codepoints and is robust to those who choose either not to support it or not to register their experiments. The solution adds a field to the structure of the experimental TCP option. This field is populated with an "experiment identifier" (ExID) defined as part of a specific option experiment. The ExID helps reduce the probability of a collision of independent experimental uses of the same option codepoint, both for those who follow this document (using registered ExIDs) and those who do not (squatters who either ignore this extension or do not register their ExIDs).
このドキュメントで提案されているアプローチは、追加のTCPオプションコードポイントを必要とせず、それをサポートしないか、実験を登録しないことを選択した人にとって堅牢です。ソリューションは、実験的なTCPオプションの構造にフィールドを追加します。このフィールドには、特定のオプション実験の一部として定義された「実験識別子」（ExID）が入力されます。 ExIDは、このオプションコードポイントの独立した実験的使用の衝突の可能性を減らすのに役立ちます。これは、このドキュメントをフォローしているユーザー（登録済みのExIDを使用）と従わないユーザー（この拡張を無視するか、ExIDを登録していない不法占拠者）の両方を対象としています。 。
The solution proposed in this document is recommended for all new protocols that use TCP experimental option codepoints. The techniques described here may also enable shared use of other experimental codepoints, but that issue is out of scope for this document.
このドキュメントで提案されているソリューションは、TCP実験的オプションコードポイントを使用するすべての新しいプロトコルに推奨されます。ここで説明する手法は、他の実験的コードポイントの共有使用を可能にすることもありますが、その問題はこのドキュメントの範囲外です。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
In this document, these words will appear with that interpretation only when in ALL CAPS. Lowercase uses of these words are not to be interpreted as carrying RFC 2119 significance.
このドキュメントでは、これらの単語はすべて大文字の場合にのみその解釈で表示されます。これらの単語の小文字の使用は、RFC 2119の重要性を持つと解釈されるべきではありません。
In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC.
このドキュメントでは、インデントされた行の前の「>>」という文字は、上記のキーワードを使用したコンプライアンス要件ステートメントを示しています。この規則は、レビュー担当者がこのRFCの明示的なコンプライアンス要件をすばやく特定または見つけるのに役立ちます。
TCP options have the current common structure [RFC793], in which the first byte is the codepoint (Kind) and the second byte is the length of the option in bytes (Length):
TCPオプションは現在の一般的な構造[RFC793]を持っています。最初のバイトはコードポイント（種類）で、2番目のバイトはオプションの長さ（バイト）です：
0 1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| Kind | Length | ... |
+--------+--------+--------+--------+
| ...
+--------
Figure 1. TCP Option Structure [RFC793]
図1. TCPオプション構造[RFC793]
This document extends the option structure for experimental codepoints (253, 254) with an experiment identifier (ExID), which is either 2 or 4 bytes in length. The ExID is used to differentiate experiments and is the first field after Kind and Length, as follows:
このドキュメントでは、実験コードポイント（253、254）のオプション構造を、2または4バイトの長さの実験識別子（ExID）で拡張しています。 ExIDは実験を区別するために使用され、次のように、種類と長さの後に最初のフィールドです。
0 1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| Kind | Length | ExID |
+--------+--------+--------+--------+
| option contents...
+--------+--------+--------+---
Figure 2. TCP Experimental Option with a 16-bit ExID
図2. 16ビットExIDを使用したTCP試験運用オプション
0 1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| Kind | Length | ExID |
+--------+--------+--------+--------+
| ExID (con't) | option contents...
+--------+--------+--------+---
Figure 3. TCP Experimental Option with a 32-bit ExID
図3. 32ビットExIDを使用したTCP試験運用オプション
This mechanism is encouraged for all TCP options that are not yet eligible for assigned codepoints:
このメカニズムは、割り当てられたコードポイントにまだ適格ではないすべてのTCPオプションに推奨されます。
>> Protocols requiring new TCP option codepoints that are not eligible for assigned values SHOULD use the existing TCP experimental option codepoints (253, 254) with ExIDs as described in this document.
>>割り当てられた値に適さない新しいTCPオプションコードポイントを必要とするプロトコルは、このドキュメントで説明されているように、ExIDを持つ既存のTCP試験運用オプションコードポイント（253、254）を使用する必要があります。
This mechanism is encouraged for all TCP options using the current experimental codepoints in controlled environments:
このメカニズムは、制御された環境で現在の実験的なコードポイントを使用するすべてのTCPオプションで推奨されます。
>> All protocols using the TCP experimental option codepoints (253, 254), even those deployed in controlled environments, SHOULD use ExIDs as described in this document.
>> TCP実験的オプションコードポイント（253、254）を使用するすべてのプロトコルは、制御された環境で展開されたものであっても、このドキュメントで説明されているようにExIDを使用する必要があります。
This mechanism is required for all TCP options using the current experimental codepoints that are publicly deployed, whether enabled by default or not:
このメカニズムは、デフォルトで有効化されているかどうかにかかわらず、パブリックにデプロイされている現在の実験的コードポイントを使用するすべてのTCPオプションに必要です。
>> All protocols using the TCP experimental option codepoints (253, 254) that are deployed outside controlled environments, such as in the public Internet, MUST use ExIDs as described in this document.
>>パブリックインターネットなどの制御された環境の外部に展開されるTCP実験オプションコードポイント（253、254）を使用するすべてのプロトコルは、このドキュメントで説明されているようにExIDを使用する必要があります。
Once a TCP option uses the mechanism in this document, registration of the ExID with IANA is required:
TCPオプションがこのドキュメントのメカニズムを使用すると、IANAへのExIDの登録が必要になります。
>> All protocols using ExIDs as described in this document MUST register those ExIDs with IANA.
>>このドキュメントで説明されているExIDを使用するすべてのプロトコルは、それらのExIDをIANAに登録する必要があります。
Applicants register their desired ExID by contacting IANA [IANA].
申請者は、IANA [IANA]に連絡して、希望するExIDを登録します。
ExIDs are selected at design time, when the protocol designer first implements or specifies the experimental option. ExIDs can be either 16 bits or 32 bits. In both cases, the value is stored in the header in network-standard (big-endian) byte order. ExIDs combine properties of IANA registered codepoints with "magic numbers".
ExIDは、プロトコルデザイナーが最初に実験オプションを実装または指定する設計時に選択されます。 ExIDは、16ビットまたは32ビットのいずれかです。どちらの場合も、値はヘッダーにネットワーク標準（ビッグエンディアン）バイトオーダーで格納されます。 ExIDは、IANA登録コードポイントのプロパティと「マジックナンバー」を組み合わせたものです。
>> All ExIDs MUST be either 16 bits or 32 bits long.
>>すべてのExIDは16ビットまたは32ビットの長さでなければなりません。
Use of the ExID, whether 16 bit or 32 bit, helps reduce the probability of a false positive collision with those who either do not register their experiment or who do not implement this mechanism.
ExIDを使用すると、16ビットでも32ビットでも、実験を登録していない人や、このメカニズムを実装していない人との誤検出の可能性を減らすことができます。
In order to conserve TCP option space, either for use within a specific option or to be available for other options:
特定のオプション内で使用するため、または他のオプションで使用可能にするために、TCPオプションスペースを節約するために、
>> Options implementing the mechanism of this document SHOULD use 16-bit ExIDs, except where explicitly motivating the need for 32-bit ExIDs, e.g., to avoid false positives or maintain alignment with an expected future assigned codepoint.
>>このドキュメントのメカニズムを実装するオプションは16ビットのExIDを使用する必要があります。ただし、32ビットのExIDの必要性を明示的に動機付けする場合を除きます。
ExIDs are registered with IANA using "first come, first served" (FCFS) priority based on the first two bytes. Those two bytes are thus sufficient to interpret which experimental option is contained in the option field.
ExIDは、最初の2バイトに基づく「先着順」（FCFS）優先順位を使用してIANAに登録されます。したがって、これらの2バイトは、オプションフィールドに含まれている実験的なオプションを解釈するのに十分です。
>> All ExIDs MUST be unique based on their first 16 bits.
>>すべてのExIDは、最初の16ビットに基づいて一意である必要があります。
The second two bytes serve as a "magic number". A magic number is a self-selected codepoint whose primary value is its unlikely collision with values selected by others. Magic numbers are used in other protocols, e.g., bootstrap protocol (BOOTP) [RFC951] and DHCP [RFC2131].
次の2バイトは「マジックナンバー」として機能します。マジックナンバーは自己選択されたコードポイントであり、その主な値は、他のユーザーが選択した値との衝突の可能性が低いことです。マジックナンバーは、ブートストラッププロトコル（BOOTP）[RFC951]やDHCP [RFC2131]などの他のプロトコルで使用されます。
Using the additional magic number bytes helps the option contents have the same byte alignment in the TCP header as they would have if (or when) a conventional (non-experiment) TCP option codepoint is assigned. Use of the same alignment reduces the potential for implementation errors, especially in using the same word-alignment padding, if the same software is later modified to use a conventional codepoint. Use of the longer, 32-bit ExID further decreases the probability of such a false positive compared to those using shorter, 16-bit ExIDs.
追加のマジックナンバーバイトを使用すると、従来の（非実験的）TCPオプションコードポイントが割り当てられている場合（またはその場合）と同じように、オプションの内容がTCPヘッダー内で同じバイトアライメントになります。同じソフトウェアを後で従来のコードポイントを使用するように変更した場合、同じアライメントを使用すると、特に同じワードアライメントパディングを使用する場合に、実装エラーの可能性が減少します。長い32ビットのExIDを使用すると、短い16ビットのExIDを使用する場合と比較して、このような誤検知の確率がさらに減少します。
Use of the ExID does consume TCP option space but enables concurrent use of the experimental codepoints and provides protection against false positives, leaving less space for other options (including other experiments). Use of the longer, 32-bit ExID consumes more space, but provides more protection against false positives.
ExIDを使用すると、TCPオプションスペースが消費されますが、実験的コードポイントの同時使用が可能になり、誤検知に対する保護が提供され、他のオプション（他の実験を含む）のためのスペースが少なくなります。より長い32ビットExIDを使用すると、より多くのスペースを消費しますが、誤検知に対する保護が強化されます。
The ExID number is considered part of the TCP option, not the TCP option header. The presence of the ExID increases the effective option Length field by the size of the ExID. The presence of this ExID is thus transparent to implementations that do not support TCP options.
ExID番号は、TCPオプションヘッダーではなく、TCPオプションの一部と見なされます。 ExIDが存在すると、有効なオプションの長さフィールドがExIDのサイズだけ増加します。したがって、このExIDの存在は、TCPオプションをサポートしない実装に対して透過的です。
During TCP processing, ExIDs in experimental options are matched against the ExIDs for each implemented protocol. The remainder of the option is specified by the particular experimental protocol.
TCP処理中に、実験的なオプションのExIDは、実装されている各プロトコルのExIDと照合されます。オプションの残りの部分は、特定の実験プロトコルによって指定されます。
>> Experimental options with ExIDs that do not match implemented protocols MUST be ignored.
>>実装されたプロトコルと一致しないExIDの実験的オプションは無視する必要があります。
The ExID mechanism must be coordinated during connection establishment, just as with any TCP option.
ExIDメカニズムは、TCPオプションと同様に、接続の確立時に調整する必要があります。
>> TCP ExID, if used in any TCP segment of a connection, MUST be present in TCP SYN segments of that connection.
>>接続のTCPセグメントでTCP ExIDを使用する場合、その接続のTCP SYNセグメントに存在する必要があります。
>> TCP experimental option ExIDs, if used in any TCP segment of a connection, SHOULD be used in all TCP segments of that connection in which any experimental option is present.
>> TCP実験オプションExID、接続のTCPセグメントで使用する場合、実験オプションが存在するその接続のすべてのTCPセグメントで使用する必要があります（SHOULD）。
Use of an ExID uses additional space in the TCP header and requires additional protocol processing by experimental protocols. Because these are experiments, neither consideration is a substantial impediment; a finalized protocol can avoid both issues with the assignment of a dedicated option codepoint later.
ExIDを使用すると、TCPヘッダーに追加のスペースが使用され、実験的なプロトコルによる追加のプロトコル処理が必要になります。これらは実験であるため、どちらの考慮事項も実質的な障害にはなりません。最終的なプロトコルは、後で専用オプションコードポイントを割り当てることで両方の問題を回避できます。
False positives occur where the registered ExID of an experiment matches the value of an option that does not use ExIDs. Such collisions can cause an option to be interpreted by the incorrect processing routine. Use of checksums or signatures may help an experiment use the shorter ExID while reducing the corresponding increased potential for false positives.
誤検知は、実験の登録済みExIDがExIDを使用しないオプションの値と一致する場合に発生します。このような衝突により、オプションが誤った処理ルーチンによって解釈される可能性があります。チェックサムまたはシグネチャを使用すると、実験が短いExIDを使用するのに役立ち、対応する誤検出の可能性が高まります。
>> Experiments that are not robust to ExID false positives SHOULD implement other detection measures, such as checksums or minimal digital signatures over the experimental options they support.
>> ExID誤検知に対して堅牢ではない実験は、サポートする実験オプションに対して、チェックサムや最小限のデジタル署名などの他の検出手段を実装する必要があります（SHOULD）。
Some experiments may transition away from being experimental and become eligible for an assigned TCP option codepoint. This document does not recommend a specific migration plan to transition from use of the experimental TCP options/ExIDs to use of an assigned codepoint.
一部の実験は実験から移行し、割り当てられたTCPオプションコードポイントの対象となります。このドキュメントでは、実験的なTCPオプション/ ExIDの使用から割り当てられたコードポイントの使用に移行するための特定の移行計画を推奨していません。
However, once an assigned codepoint is allocated, use of an ExID represents unnecessary overhead. As a result:
ただし、割り当てられたコードポイントが割り当てられると、ExIDを使用すると不要なオーバーヘッドが発生します。結果として：
>> Once a TCP option codepoint is assigned to a protocol, that protocol SHOULD NOT continue to use an ExID as part of that assigned codepoint.
>> TCPオプションコードポイントがプロトコルに割り当てられると、そのプロトコルは、割り当てられたコードポイントの一部としてExIDを使用し続けるべきではありません（SHOULD NOT）。
This document does not recommend whether or how an implementation of an assigned codepoint can be backward compatible with use of the experimental codepoint/ExID.
このドキュメントでは、割り当てられたコードポイントの実装に、実験的なコードポイント/ ExIDの使用との下位互換性があるかどうか、またはその方法を推奨していません。
However, some implementers may be tempted to include both the experimental and assigned codepoint in the same segment, e.g., in a SYN to support backward compatibility during connection establishment. This is a poor use of limited resources; so, to ensure conservation of the TCP option space:
ただし、一部の実装者は、実験的コードポイントと割り当てられたコードポイントの両方を同じセグメントに含めようとする可能性があります（たとえば、接続確立時の下位互換性をサポートするためにSYNに）。これは限られたリソースの不適切な使用です。したがって、TCPオプションスペースを確実に保存するには、次のようにします。
>> A TCP segment MUST NOT contain both an assigned TCP option codepoint and a TCP experimental option codepoint for the same protocol.
>> TCPセグメントには、同じプロトコルに割り当てられたTCPオプションコードポイントとTCP試験運用オプションコードポイントの両方を含めることはできません。
Instead, a TCP that intends backward compatibility might send multiple SYNs with alternates of the same option and discard all but the most desired successful connection. Although this approach may resolve more slowly or require additional effort at the endpoints, it is preferable to excessively consuming TCP option space.
代わりに、下位互換性を目的とするTCPは、同じオプションの代替で複数のSYNを送信し、最も望ましい接続を除いてすべてを破棄する可能性があります。このアプローチは解決に時間がかかるか、エンドポイントで追加の作業が必要になる場合がありますが、TCPオプションスペースを過度に消費するよりも望ましい方法です。
The ExIDs described in this document combine properties of IANA FCFS-registered values with magic numbers. Although IANA FCFS registries are common, so too are those who either fail to register or who 'squat' by deliberately using codepoints that are assigned to others. The approach in this document is intended to recognize this reality and be more robust to its consequences than would be a conventional IANA FCFS registry.
このドキュメントで説明されているExIDは、IANA FCFS登録値のプロパティとマジックナンバーを組み合わせたものです。 IANA FCFSレジストリは一般的ですが、登録に失敗したり、他の人に割り当てられているコードポイントを意図的に使用して「スクワット」したりする人もそうです。このドキュメントのアプローチは、この現実を認識し、従来のIANA FCFSレジストリよりもその結果に対してより堅牢になることを目的としています。
Existing ID spaces were considered as ExIDs in the development of this mechanism, including IEEE Organizationally Unique Identifier (OUI) and IANA Private Enterprise Numbers (PENs) [IEEE802] [OUI] [RFC1155].
この機構の開発では、既存のIDスペースがExIDと見なされました。これには、IEEE組織固有識別子（OUI）およびIANA Private Enterprise Numbers（PEN）[IEEE802] [OUI] [RFC1155]が含まれます。
OUIs are 24-bit identifiers that are combined with 24 to 40 bits of privately assigned space to create identifiers that are commonly assigned to a unique piece of hardware. OUIs are already longer than the smaller ExID value, and obtaining an OUI is costly (currently $1,885.00 USD). An OUI could be obtained for each experiment, but this could be considered expensive. An OUI already assigned to an organization could be shared if extended (to support multiple experiments within an organization), but this would either require coordination within an organization or an IANA registry; the former is prohibitive, and the latter is more complicated than having IANA manage the entire space.
OUIは24ビットの識別子であり、24〜40ビットのプライベートに割り当てられたスペースと組み合わせて、一意のハードウェアに一般的に割り当てられる識別子を作成します。 OUIはすでに小さいExID値よりも長く、OUIの取得にはコストがかかります（現在は$ 1,885.00 USD）。実験ごとにOUIを取得できますが、これはコストがかかると考えられます。組織にすでに割り当てられているOUIは、拡張された場合は共有できます（組織内の複数の実験をサポートするため）。ただし、これには、組織内の調整またはIANAレジストリが必要です。前者は禁止されており、後者はIANAがスペース全体を管理するよりも複雑です。
PENs were originally used in the Simple Network Management Protocol (SNMP) [RFC1157]. PENs are identifiers that can be obtained without cost from IANA [PEN]. Despite the current registry, the size of the PEN assignment space is currently undefined and has only recently been proposed (as 32 bits) [IANA-PEN]. PENs are currently assigned to organizations, and there is no current process for assigning them to individuals. Finally, if the PENs are 32 bits as expected, they would be larger than needed in many cases.
PENは当初、シンプルネットワーク管理プロトコル（SNMP）[RFC1157]で使用されていました。 PENは、IANA [PEN]から無料で取得できる識別子です。現在のレジストリにもかかわらず、PEN割り当てスペースのサイズは現在定義されておらず、最近提案された（32ビットとして）[IANA-PEN]。 PENは現在組織に割り当てられており、現在PENを個人に割り当てるプロセスはありません。最後に、PENが予想どおり32ビットの場合、多くの場合必要以上に大きくなります。
The mechanism described in this document is not intended to enhance, nor does it weaken the existing state of security for TCP option processing.
このドキュメントで説明されているメカニズムは、TCPオプション処理の既存のセキュリティ状態を強化することも、弱めることも意図していません。
IANA has created a "TCP Experimental Option Experiment Identifiers (TCP ExIDs)" registry. The registry records both 16-bit and 32-bit ExIDs, as well as a reference (description, document pointer, or assignee name and e-mail contact) for each entry. ExIDs are registered for use with both of the TCP experimental option codepoints, i.e., with TCP options with values of 253 and 254.
IANAは、「TCP実験オプション実験識別子（TCP ExID）」レジストリを作成しました。レジストリには、16ビットと32ビットの両方のExIDと、各エントリの参照（説明、ドキュメントポインター、または担当者名と電子メールの連絡先）が記録されます。 ExIDは、TCPの実験的なオプションコードポイントの両方で使用するために登録されています。つまり、値が253と254のTCPオプションです。
Entries are assigned on a First Come, First Served (FCFS) basis [RFC5226]. The registry operates FCFS on the first two bytes of the ExID (in network-standard order) but records the entire ExID (in network-standard order). Some examples are:
エントリーは先着順（FCFS）に基づいて割り当てられます[RFC5226]。レジストリは、ExIDの最初の2バイト（ネットワーク標準順）でFCFSを操作しますが、ExID全体（ネットワーク標準順）を記録します。次に例を示します。
o 0x12340000 collides with a previous registration of 0x1234abcd
o 0x12340000が以前の登録0x1234abcdと競合します
o 0x5678 collides with a previous registration of 0x56780123
o 0x5678が以前の登録0x56780123と衝突します
o 0xabcd1234 collides with a previous registration of 0xabcd
o 0xabcd1234が以前の0xabcdの登録と衝突する
IANA will advise applicants of duplicate entries to select an alternate value, as per typical FCFS processing.
IANAは、一般的なFCFS処理に従って、重複するエントリの申請者に代替値を選択するようアドバイスします。
IANA will record known duplicate uses to assist the community in both debugging assigned uses as well as correcting unauthorized duplicate uses.
IANAは既知の重複使用を記録して、割り当てられた使用のデバッグと不正な重複使用の修正の両方でコミュニティを支援します。
IANA should impose no requirements on making a registration other than indicating the desired codepoint and providing a point of contact. A short description or acronym for the use is desired but should not be required.
IANAは、必要なコードポイントを示し、連絡先を提供すること以外に、登録を行うための要件を課すべきではありません。使用についての短い説明または頭字語が望まれますが、必須ではありません。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[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月。
[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月。
[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月。
[Bi11] Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres, D., and Q. Slack, "Cryptographic protection of TCP Streams", Work in Progress, September 2012.
[Bi11] Bittau、A.、Boneh、D.、Hamburg、M.、Handley、M.、Mazieres、D。、およびQ. Slack、「TCPストリームの暗号化保護」、Work in Progress、2012年9月。
[Ed11] Eddy, W., "Additional TCP Experimental-Use Options", Work in Progress, August 2011.
[Ed11] Eddy、W。、「追加のTCP試験運用オプション」、作業中、2011年8月。
[IANA] IANA, <http://www.iana.org/>.
[IANA] IANA、<http://www.iana.org/>。
[IANA-PEN] Liang, P. and A. Melnikov, "Private Enterprise Number (PEN) Practices and Internet Assigned Numbers: Authority (IANA) Considerations for Registration Procedures", Work in Progress, June 2012.
[IANA-PEN] Liang、P。およびA. Melnikov、「Private Enterprise Number（PEN）Practices and Internet Assigned Numbers：Authority（IANA）Considerations for Registration Procedures」、作業進行中、2012年6月。
[IEEE802] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE 802-2001, 8 March 2002.
[IEEE802] IEEE、「IEEE Standard for Local and Metropolitan Area Networks：Overview and Architecture」、IEEE 802-2001、2002年3月8日。
[OUI] IEEE, "Organizationally Unique Identifier (OUI) or 'Company_ID'", <http://standards.ieee.org/develop/regauth/oui/>.
[YES] IEEE、「Organizationally Unique Identifier（OUI）または 'Company_ID'」、<http://standards.ieee.org/develop/regauth/oui/>。
[PEN] IANA, "Private Enterprise Numbers", <http://www.iana.org/assignments/enterprise-numbers>.
[ペン] IANA、「プライベートエンタープライズ番号」、<http://www.iana.org/assignments/enterprise-numbers>。
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[RFC951] Croft、W. and J. Gilmore、 "Bootstrap Protocol"、RFC 951、September 1985。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-Based Internets", STD 16, RFC 1155, May 1990.
[RFC1155] Rose、M。、およびK. McCloghrie、「構造およびTCP / IPベースのインターネットの管理情報の識別」、STD 16、RFC 1155、1990年5月。
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", RFC 1157, May 1990.
[RFC1157] Case、J.、Fedor、M.、Schoffstall、M。、およびJ. Davin、「Simple Network Management Protocol（SNMP）」、RFC 1157、1990年5月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780] Bradner、S。およびV. Paxson、「IANA Allocation Allocation Guidelines for Values in the Internet Protocol and Related Headers」、BCP 37、RFC 2780、2000年3月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]ナルテン、T。、「実験的およびテスト番号の割り当ては有用と見なされた」、BCP 82、RFC 3692、2004年1月。
[RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013, January 2011.
[RFC6013] Simpson、W。、「TCP Cookie Transactions（TCPCT）」、RFC 6013、2011年1月。
[Si11] Simpson, W., "TCP Cookie Transactions (TCPCT) Sockets Application Program Interface (API)", Work in Progress, April 2011.
[Si11] Simpson、W。、「TCP Cookie Transactions（TCPCT）Sockets Application Program Interface（API）」、Work in Progress、2011年4月。
This document was motivated by discussions on the IETF TCPM mailing list and by Wes Eddy's proposal [Ed11]. Yoshifumi Nishida, Pasi Sarolathi, and Michael Scharf provided detailed feedback.
この文書は、IETF TCPMメーリングリストでの議論とWes Eddyの提案[Ed11]によって動機付けられました。西田芳文、Pasi Sarolathi、Michael Scharfが詳細なフィードバックを提供しました。
This document was originally prepared using 2-Word-v2.0.template.dot.
このドキュメントは元々、2-Word-v2.0.template.dotを使用して作成されました。
Author's Address
著者のアドレス
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A.
Joe Touch USC / ISI 4676 Admiralty Way Marina del Rey、CA 90292-6695 U.S.A.
Phone: +1 (310) 448-9151
EMail: touch@isi.edu