この文書はRFC3692の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


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.

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
   1.  はじめに
       1.1.  Recommendation for Protocols
       1.1.  プロトコルのための推薦
   2.  IANA Considerations
   2.  IANAの考慮
       2.1.  IP Protocol Field
       2.1.  IPプロトコルフィールド
       2.2.  Existing Name Spaces
       2.2.  既存の名前空間
       3.  Security Considerations
   3.  セキュリティの考察
   4.  Acknowledgments
   4.  謝辞
   5.  References
   5.  参考文献
   5.1.  Normative References
       5.1.  参照する参考文献

       5.2.  Informative References
       5.2.  有益な参考文献

   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が割当すると明示します。例えば、値がある名前空間から「I
   ETF標準化行動」[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.
   実験範囲の番号はRFC2434[IANA-CONSIDERATIONS]で「私的利用」と呼
   ばれる番号に類似しています。これらは一般的な配置で使うか、製品や他の
   一般的なリリースでデフォルトで使用する事を意図しません。この場合製品
   やリリースは実験番号を使用できて、エンドユーザは明示的に実験機能を起
   動させる必要があり、同様にエンドユーザは特定の目的で実験番号範囲から
   どの番号を使うか選択して設定できなければなりません(すなわち、エンド
   ユーザは特定の番号の使用が他の機能と衝突しないことを保証できます)。
   出荷製品で特定の値を事前設定するのは不適切で、設定された値が異なる利
   用と衝突するときに互換性問題が発生し、そしてこれはいつか起こります。

   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.
   実験のために確保するべき値の正確な数は、プロトコルとそのプロトコルに
   固有な要因に依存するでしょう。例えば、フィールドの値が扱いの異なる範
   囲に分割される場合(例えば、もし値が理解できない場合に、「静かに無視」
   と「エラーを返す」)、それぞれの範囲から値を予約する必要があります。

   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.
   実験的番号を使うプロトコルが製品に組み込まれるとき、製品の出荷版でデ
   フォルトでプロトコル実験番号の認識をしてはなりませ−すなわち、製品の
   エンドユーザは明示的に実験的プロトコル機能を「起動」しなければなりま
   せん。たいていの場合、製品実装は使用を開始する前にエンドユーザに明示
   的に値を設定させなければなりません。もし製品がこのようなエンドユーザ
   設定のユーザ・インタフェースを持たなければ、製品は暗黙にプロトコルの
   実験的番号を設定する明白な再プログラミング(例えば、特別なファームウェ
   アダウンロードや、機能カードの導入)を要求しなくてはなりません。

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プロトコルフィールドの新しい値の割当てがIETF標準化行動を必要
   とします[RFC2780]。実験と試験の目的で、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を発行する標準的手順を通して割当てができます。実験的目的
   割当の文書の発行が過剰な場合、手順を単純化するために、実験的な値をI
   ESG承認[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.
   Steve BellovinとScott BradnerとRandy BushとBill FennerとSteve Hanna
   とPaul HoffmanとHenrik LevkowetzとJohn LoughneyとAllison Mankinと
   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.

   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October 1998.

5.2.  Informative References
5.2.  有益な参考文献


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

6.  Author's Address
6.  著者のアドレス

   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.  Full Copyright Statement
7.  著作権表示全文

   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エディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So