[要約] RFC 3692は、実験的な番号やテスト番号の割り当てに関するガイドラインであり、その目的は、ネットワークプロトコルの開発やテストにおいて、一時的な番号の使用を効果的に管理することです。

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.

このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2004). All Rights Reserved.

著作権(c)The Internet Society(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
        
1. Introduction
1. はじめに

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の真上で実行されるプロトコルを開発するには、IPヘッダー[RFC791]のプロトコルフィールドに配置するためにIPプロトコル番号が必要です。場合によっては、新しい数値を取得することは簡単です(例:よく知られているTCPまたはUDPポートなど)または必要ではありません(例:テストのためのTCPおよびUDPポート番号など)。それ以外の場合、数値を取得することはより困難です。たとえば、名前空間内の利用可能な値と未割り当ての値の数は、不注意に割り当てられた場合に使用可能なすべての数値が使い果たされるという懸念があるほど十分に小さい場合があります。数字が豊富である場合でも、提案された使用法がより広範なコミュニティによって適切にレビューされていない限り、数値を割り当てることは望ましくない場合があります。その結果、いくつかの数のスペースでは、IANAが提案されたプロトコルに対して強力なコミュニティサポートがある場合にのみ割り当てを行うことを指定しています。たとえば、一部の名前スペースからの値は、「IETF標準アクション」[RFC2434]を通じてのみ割り当てられます。これには、提案された使用がIETF標準トラックRFCであることが必要です。

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.

1つのアプローチは、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-Consididerations]の「プライベート使用」と呼ばれるものに似ています。それらは、一般的な展開で使用されることを意図していないか、製品やその他の一般的なリリースでデフォルトで有効にすることを意図していません。製品またはリリースが実験番号を使用する場合、エンドユーザーは実験機能を明示的に有効にする必要があり、同様に、実験範囲からどの番号を選択して割り当てる能力がある必要があります(特定の目的)(つまり、エンドユーザーは、特定の数字の使用が他の継続的な使用と競合しないようにすることができます)。特定の値を事前に有効にする製品を配送することは不適切であり、選択された値がいつか確実にそうなるように、異なる使用法と衝突すると相互運用性の問題につながる可能性があります。

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を無視するか、廃棄するか、エラーを信号します。不明なオプションまたは機能を処理する方法を示します。プロトコルに認識されていない拡張機能を処理するさまざまな方法がある場合(たとえば、静かに廃棄し、信号を誤ります)、そのプロトコルはすべての適切な範囲からテスト目的で値を予約する必要があります。実験されている拡張機能または機能を使用するように具体的に有効または構成された実装のみが、データをさらに処理するでしょう。

1.1. Recommendation for Protocols
1.1. プロトコルの推奨

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.

実験用に予約する値の正確な数は、特定のプロトコルとそのプロトコルに固有の要因に依存します。たとえば、フィールドの値が異なって扱われる範囲に細分される場合(例えば、「静かに無視する」vs.「エラーを返す」値が理解されていない場合)、各サブレンジの1つ以上の値からの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.

実験番号を使用するプロトコルが製品に含まれる場合、製品の出荷バージョンは、デフォルトでプロトコルの実験数の認識を無効にする必要があります。つまり、製品のエンドユーザーは、実験プロトコル機能を明示的に「オンにする」必要があります。ほとんどの場合、製品の実装では、使用が可能になる前に、エンドユーザーが値を明示的に構成する必要があります。製品にそのようなエンドユーザー構成のユーザーインターフェイスがない場合、製品は、プロトコルの実験番号(s)を構成するために、明示的な再プログラミング(特別なファームウェアのダウンロード、または機能カードのインストール)を必要とする必要があります(sが必要です。)暗黙的に。

2. IANA Considerations
2. IANAの考慮事項
2.1. IP Protocol Field
2.1. IPプロトコルフィールド

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はこの目的のために2つの値253と254を割り当てました。これらの値は、行われた既存の割り当てと比較して際立っていることにより、利用可能な数値スペースの上端から割り当てられています。

2.2. Existing Name Spaces
2.2. 既存の名前スペース

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]を通じて実験値を作成できます。

3. Security Considerations
3. セキュリティに関する考慮事項

This document has no known security implications.

このドキュメントには、セキュリティへの影響は既知のものではありません。

4. Acknowledgments
4. 謝辞

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.

この文書の改善は、スティーブ・ベロヴィン、スコット・ブラッドナー、ランディ・ブッシュ、ビル・フェナー、スティーブ・ハンナ、ポール・ホフマン、ヘンリック・レフコウェッツ、ジョン・ラフニー、アリソン・マンキン、リチャード・ネッキーからの特定のフィードバックの結果としてもたらされました。

5. References
5. 参考文献
5.1. Normative References
5.1. 引用文献

[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割り当てガイドライン」、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月。

5.2. Informative References
5.2. 参考引用

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。

6. Author's Address
6. 著者の連絡先

Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA

Thomas Narten IBM Corporation P.O.Box 12195 Research Triangle Park、NC 27709-2195 USA

   Phone: +1 919 254 7798
   EMail: narten@us.ibm.com
        
7. 完全な著作権声明

Copyright (C) The Internet Society (2004). All Rights Reserved.

著作権(c)The Internet Society(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エディター機能の資金は現在、インターネット協会によって提供されています。