Network Working Group T. Narten
Request for Comments: 3692 IBM
BCP: 82 January 2004
Updates: 2434
Category: Best Current Practice
Assigning Experimental and Testing Numbers Considered Useful
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.
で実験やプロトコルを拡張する場合、閉鎖された環境でテストするときにも、新しい機能を実際にテストするためか、実験でプロトコル番号または定数のいくつかの並べ替えを使用する必要があることが多いです。たとえば、新しいDHCPオプションをテストするために、一つは新しい関数を識別するために、オプション番号を必要とします。このドキュメントは、IANAの考慮事項のセクションを書くとき、著者らは、プロトコルの拡張やその他の新機能をテストするときに実装者が使用することができ、実験の目的で、番号の小さい範囲を割り当てることを検討すべきであることをお勧めします。この文書では、実験をサポートする必要が同定されている特定のプロトコルでの実験のために、番号の一部の範囲を留保します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Recommendation for Protocols . . . . . . . . . . . . . . 4
2. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 5
2.1. IP Protocol Field. . . . . . . . . . . . . . . . . . . . 5
2.2. Existing Name Spaces . . . . . . . . . . . . . . . . . . 5
3. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 6
6. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
7. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
When experimenting with or extending protocols, it is often necessary to have a protocol number as part of the implementation [RFC2434]. For example, to develop a protocol that runs directly above IP, one needs an IP Protocol Number to place in the Protocol field of the IP header [RFC791]. In some cases, obtaining a new number is straightforward (e.g., a well-known TCP or UDP port) or not even necessary (e.g., TCP and UDP port numbers for testing purposes). In other cases, obtaining a number is more difficult. For example, the number of available and unassigned values in a name space may be small enough that there is concern that all available numbers will be used up if assigned carelessly. Even in cases where numbers are potentially plentiful, it may be undesirable to assign numbers unless the proposed usage has been adequately reviewed by the broader community. Consequently, some number spaces specify that IANA only make assignments in cases where there is strong community support for a proposed protocol. For example, values out of some name spaces are only assigned through an "IETF Standards Action" [RFC2434], which requires that the proposed use be in an IETF Standards Track RFC.
で実験またはプロトコルを拡張する場合、実現[RFC2434]の一部として、プロトコル番号を有することがしばしば必要です。例えば、直接IPの上で実行プロトコルを開発するために、一方は[RFC791] IPヘッダのプロトコルフィールドに配置するIPプロトコル番号を必要とします。いくつかのケースでは、新しい番号を得ることも必要（テスト目的のために、例えば、TCPおよびUDPポート番号）直接的（例えば、周知のTCPまたはUDPポート）、またはではありません。他の場合には、番号を取得することはより困難です。たとえば、名前空間で利用可能と割り当てられていない値の数は不用意に割り当てられている場合、使用可能なすべての数字がアップ使用されることを懸念があることを十分に小さくすることができます。でも、数字が潜在的に豊富である場合には、提案されている使用方法が適切に広いコミュニティによってレビューされていない限り、番号を割り当てることが望ましくないかもしれません。その結果、いくつかの数のスペースはIANAが唯一の提案されたプロトコルのための強力なコミュニティのサポートがある場合に割り当てを行うことを指定します。例えば、いくつかの名前空間のうち値が唯一の目的とする用途は、IETF標準化過程のRFCであることを要求され、「IETF標準化アクション」[RFC2434]によって割り当てられます。
In order to experiment with a new protocol, an experimental value may be needed that won't collide with an existing or future usage.
新しいプロトコルを試すために、実験値は、既存または将来の使用と衝突しないことを必要とすることができます。
One approach is to allow IANA to make temporary assignments for such purposes. The idea is that a protocol value can be assigned to allow experimentation, but after the experiment ends, the number would be returned to IANA. There are several drawbacks to this approach, however. First, experience has shown that it can be difficult to reclaim numbers once assigned. For example, contact information becomes outdated and it can become difficult to find out what the status of an experiment actually is. Second, should deployment with the temporarily assigned number take place (e.g., it is included as part of a product), it becomes very difficult to determine whether or not reuse of that number would lead to adverse impact with regards to deployed devices. Finally, it can be difficult to determine when an experiment has ended and whether the number needs to be returned.
一つのアプローチは、IANAは、このような目的のために一時的に割り当てを行うことができるようにすることです。アイデアは、プロトコル値は実験を許可するように割り当てることができるということですが、実験が終了した後、数はIANAに返されます。このアプローチにはいくつかの欠点は、しかし、があります。まず、経験は、一度割り当てられた番号を再利用することが困難な場合があることを示しています。たとえば、連絡先情報は時代遅れとなり、実験の状況が実際にあるものを見つけることが困難になることができます。第二に、一時的に割り当てられた番号の展開が行われ（例えば、それは製品の一部として含まれている）、それはその数の再利用か否かを展開デバイスへに関して不利な影響をもたらすかを決定することは非常に困難となるべきです。最後に、実験が終了したと数が返される必要があるかどうかを決定するために困難な場合があります。
An alternate approach, and the one recommended in this document, is to assign a range of numbers specifically earmarked for testing and experimentation purposes. Mutually consenting devices could use these numbers for whatever purposes they desire, but under the understanding that they are reserved for generic testing purposes, and other implementations may use the same numbers for different experimental uses.
別のアプローチ、および本文書で推奨一つは、具体的にテストと実験のために充て番号の範囲を割り当てることです。互いに同意のデバイスは、彼らが望むものは何でも目的のためにこれらの番号を使用しますが、これらは一般的なテスト目的のために予約されているの理解の下で、および他の実装は、異なる実験用途のために同じ番号を使用することができます。
Numbers in the experimentation range are similar to those called "Private Use" in RFC 2434 [IANA-CONSIDERATIONS]. They 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.
実験の範囲内の数字は、RFC 2434 [IANA-考察]に「私用」と呼ばれるものと同様です。これらは、一般的な展開で使用されることを意図されていないか、または製品や他の一般的なリリースではデフォルトで有効にすること。製品または放出は、実験番号を利用するような場合では、エンドユーザが明示的に実験的な機能を有効にし、同様に実験的範囲からの番号を選択し、割り当てる機能が（特定の目的のために使用されることが要求されなければなりませんつまり、エンドユーザーに）その他の進行中の使用と競合していない特定の番号の利用を確保することができます。特定の値プリ有効にして製品を出荷することは不適切であると、それはいつかきっとれるように選択された値は、異なる用法と衝突したときの相互運用性の問題につながることができます。
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.
拡張がテストされ、有用であることが示された後、永久的な数は、通常の割り当て手順によって得ることができます。
Most implementations will not do anything special with numbers assigned for testing purposes. In particular, unless a packet or other Protocol Data Unit (PDU) is specifically directed at a device, that device will not even look at the field while processing the PDU. For example, IP routers do not need to examine or understand the Protocol Type field of IP datagrams in order to know how to correctly forward them. In those cases where a packet or PDU is directed at a device, and that device has not been configured to recognize the extension, the device will either ignore the PDU, discard it, or signal an error, depending on the protocol-specific rules that indicate how to process unknown options or features. In those cases where a protocol has different ways of handling unrecognized extensions (e.g., silently discard vs. signal an error), that protocol needs to reserve values for testing purposes from all the appropriate ranges. Only those implementations specifically enabled or configured to make use of an extension or feature that is being experimented with would process the data further.
ほとんどの実装では、テスト目的のために割り当てられた番号で特別何もしません。パケットまたは他のプロトコルデータユニット（PDU）は、具体的にデバイスに向けられていない限りPDUを処理している間、特に、その装置は偶数フィールドを見ないであろう。例えば、IPルータは、それらを正しく転送する方法を知るためにIPデータグラムのプロトコルタイプフィールドを調べたり、理解する必要はありません。パケットまたはPDUがデバイスに向けられ、そのデバイスは拡張を認識するように構成されていないような場合では、デバイスは、プロトコル固有のルールに応じて、PDUを無視し、それを破棄するか、エラーを通知するか、その未知のオプションや機能をどのように処理するかを示しています。プロトコルが認識されていない拡張機能（例えば、サイレント信号対エラーを破棄）処理の異なる方法があり、これらの場合において、そのプロトコルは、すべての適切な範囲からテスト目的のために値を確保する必要があります。特異的に実験されている拡張や機能を利用するために有効または構成のみの実装は、データを処理することになります。
To make it possible to experiment with protocol extensions safely, protocol documents should consider reserving a small set of protocol numbers for experimentation. Such reservations can be made through an explicit reservation in an IANA Considerations section.
安全プロトコル拡張を実験することを可能にするために、プロトコルドキュメントは、実験用のプロトコル番号の小さなセットを予約検討すべきです。このような予約はIANAの考慮事項のセクションで明示的に予約を通じて行うことができます。
The exact number of values to reserve for experimentation will depend on the specific protocol and factors specific to that protocol. For example, in cases where the values of a field are subdivided into ranges that are treated differently (e.g., "silently ignore" vs. "return an error" if the value is not understood), one or more values from each sub-range may need to be reserved.
実験のために予約する値の正確な数は、特定のプロトコルおよびそのプロトコルに固有の要因に依存するであろう。例えば、異なる方法で処理されたフィールドの値が範囲に細分されている場合には、各サブレンジから1つ以上の値（例えば、値は理解されていない場合は、「エラーを返す」対「サイレント無視します」）予約する必要があります。
For protocols that return error codes, it may also be appropriate to reserve a small number of experimental error values that can be used in conjunction with possible experimental uses. For example, an experimental message might result (even under normal conditions) in an error, with a special error code (or sub-code) indicating the type of error condition.
エラーコードを返すプロトコルの場合、また、可能な実験用途と併せて使用することができる実験誤差値の小さな数を確保するために適切であり得ます。例えば、実験的なメッセージは、エラー状態の種類を示す特別なエラーコード（またはサブコード）と、エラー（さえ通常の条件下で）可能性があります。
In many, if not most cases, reserving a single value for experimental use will suffice. While it may be tempting to reserve more in order to make it easy to test many things at once, reserving many may also increase the temptation for someone using a particular value to assume that a specific experimental value can be used for a given purpose exclusively. Values reserved for experimental use are never to be made permanent; permanent assignments should be obtained through standard processes. As described above, experimental numbers are intended for experimentation and testing and are not intended for wide or general deployments.
多くの、そうでない場合はほとんどの場合、十分であろう実験的な使用のために単一の値を予約。それは一度に多くのことをテストすることを容易にするために、よりを予約したくてもよいが、多くを予約することも、特定の実験値が独占的に与えられた目的のために使用することができることを前提とする特定の値を使用して誰かのための誘惑を増大させることができます。実験的な使用のために予約値は永久的なものにしないことにするん;永久的な割り当ては、標準的なプロセスを経て得られたことがなければなりません。上述したように、実験的な数値は、実験とテストを意図しており、広い又は一般的な展開のために意図されていません。
When protocols that use experimental numbers are included in products, the shipping versions of the products must disable recognition of protocol experimental numbers by default -- that is, the end user of the product must explicitly "turn on" the experimental protocol functionality. In most cases, a product implementation must require the end user to configure the value explicitly prior to enabling its usage. Should a product not have a user interface for such end user configuration, the product must require explicit re-programming (e.g., a special firmware download, or installation of a feature card) to configure the experimental number(s) of the protocol(s) implicitly.
実験的な数字を使用するプロトコルは、製品に含まれている場合は、製品の出荷バージョンでは、デフォルトでは、プロトコルの実験的数字の認識を無効にする必要があります - つまり、製品のエンドユーザが明示的に実験的なプロトコル機能「をオンにする」必要があります。ほとんどの場合、製品の実装は、その使用を有効に明示的に前の値を設定するには、エンドユーザーが必要としなければなりません。製品は、このようなエンドユーザの設定のためのユーザインタフェースを持つべきではない、製品が（例えば、特別なファームウェアのダウンロード、またはフィーチャカードのインストールは）（プロトコルの実験番号（複数可）を設定するには、明示的な再プログラミングを必要としなければなりませんの）暗黙のうちに。
Assignment of new values for the IP Protocol field requires an IETF Standards Action per [RFC2780]. For the purposes of experimentation and testing, IANA has assigned the two values 253 and 254 for this purpose. These values have been allocated from the upper end of the available number space in order to make them easy to identify by having them stand out relative to the existing assignments that have been made.
IPプロトコルフィールドの新しい値の割り当ては、[RFC2780]あたりのIETF標準化行動を必要とします。実験およびテストの目的のために、IANAは、この目的のために二つの値253及び254を割り当てました。これらの値は、それらが行われている既存の割り当てに比べて目立つことによって識別するためにそれらを容易にするために利用可能な番号空間の上端から割り当てられています。
Numerous name spaces exist for which no values have been reserved for experimentation or testing purpose. Experimental values for such protocols can of course be assigned through the normal process of publishing an RFC that documents the details of such an allocation. To simplify the process in those cases where the publication of a documentation just for the purpose of assigning an experimental allocation seems overkill, experimental values can be made through IESG Approval [RFC2434].
多くの名前空間には値が実験やテストの目的のために予約されていないいるために存在します。そのようなプロトコルの実験値は、当然のことながら、このような割り当ての詳細を文書化RFCを公開する通常のプロセスを割り当てることができます。単に実験的割り当てを割り当てるために文書の刊行が過剰と思われるような場合にプロセスを簡素化するために、実験値はIESG承認[RFC2434]を介して行うことができます。
This document has no known security implications.
この文書には、既知のセキュリティの意味を持っていません。
Improvements to this document came as a result of specific feedback from Steve Bellovin, Scott Bradner, Randy Bush, Bill Fenner, Steve Hanna, Paul Hoffman, Henrik Levkowetz, John Loughney, Allison Mankin, and Richard Woundy.
このドキュメントの改善はスティーブBellovin氏、スコット・ブラッドナー、ランディブッシュ、ビルフェナー、スティーブ・ハンナ、ポール・ホフマン、ヘンリクLevkowetz、ジョンLoughney、アリソンマンキン、そしてリチャードWoundyから特定のフィードバックの結果として来ました。
[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]ブラドナー、S.とV.パクソン、 "インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン"、BCP 37、RFC 2780、2000年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA
トーマスNarten氏IBM社の私書箱12195リサーチトライアングルパーク、NC 27709から2195 USA箱
Phone: +1 919 254 7798 EMail: narten@us.ibm.com
電話：+1 919 254 7798 Eメール：narten@us.ibm.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。