この文書はRFC3692の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
プロトコルを使って実験するか拡張する時、閉じた環境でテストをする時で
さえ、実際にテストをするために何らかの種類のプロトコル番号あるいは定
数を使って新しい機能を実験することはしばしば必要です。例えば、新しい
ＤＨＣＰオプションのテストで、新しい機能を識別するのにオプション番号
が必要です。この文書はＩＡＮＡの考慮の章を書く時に、著者が実験目的に
小さな範囲の番号を割当てることを考えるのを薦めます、これは実装者が拡
張プロトコルや新しい機能の試験をするのに使えます。この文書は実験をサ
ポートする必要があった特定のプロトコルで、実験目的でいくつかの番号範
囲を確保します。
Table of Contents
目次
1. Introduction
1. はじめに
1.1. Recommendation for Protocols
1.1. プロトコルのための推薦
2. IANA Considerations
2. ＩＡＮＡの考慮
2.1. IP Protocol Field
2.1. ＩＰプロトコルフィールド
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]。例えば、ＩＰ上で直接稼働するプロ
トコルを開発するために、ＩＰヘッダ[RFC791]のプロトコルフィールドに置
くべきＩＰプロトコル番号を必要とします。ある場合には、新しい番号を得
ることは簡単（例えば、周知のＴＣＰやＵＤＰポート）あるいは必要であり
ません（例えば、テスト目的のＴＣＰとＵＤＰポート番号）。他の場合に、
番号を得ることは難しいです。例えば、名前空間での利用可能で割り当てら
れていない番号値、もし不注意に割り当てられるなら、すべての利用可能な
番号が使い尽くされる心配があるほど小さいかもしれません。番号が潜在的
に豊富な」場合でも、提案された使用法が十分に広い共同体で再検討されな
れば、番号を割り当てることは望ましくないかもしれません。従って、ある
け番号空間で、提案されたプロトコルに対する強い共同体支持がある場合だ
け、ＩＡＮＡが割当すると明示します。例えば、値がある名前空間から「Ｉ
ＥＴＦ標準化行動」[RFC2434]を通してだけ割り当てられ、そしてそれは提
案された使用がＩＥＴＦ標準化手順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.
１つの方法はＩＡＮＡがこのような目的のために一時的な割当を作ることを
許すことです。考え方は、プロトコル値が実験を許すために割当てられると
いうことです、しかし実験終わりの後に、番号はＩＡＮＡに返されるでしょ
う。しかしながら、この方法はいくつかの欠点があります。最初に、経験的
に一度割当てた番号の返還を要求することが難しいです。例えば、連絡先情
報が古くなり、そして実験状態が何であるか見いだすことは難しくなります。
第二に、一時的に割り当てられた番号が使用されていて（例えば、これが製
品の役割に組み込まれている）、その番号の再利用が使用中の装置に不利な
影響を起こすか決定するのが非常に難しいです。最終的に、いつ実験が終わっ
たか、そして番号を返す必要があるか決定することは難しいです。
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.
実験範囲の番号はＲＦＣ２４３４[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.
たいていの実装でテスト目的に割り当てられた番号は特別何もしないでしょ
う。特に、パケットや他のプロトコルデータユニット（ＰＤＵ）が特にその
装置に送られた場合を除き、その装置はＰＤＵを処理する間に、フィールド
を見さえしないでしょう。例えば、ＩＰルータはパケットを正確にどのよう
に転送するべきか知る際に、ＩＰデータグラムのプロトコルタイプフィール
ドを調べるか理解する必要がありません。パケットあるいはＰＤＵがその装
置に向けられ、そしてその装置が拡張を認識するように設定されなかった場
合、装置は、未知のオプションや機能を処理する方法を示すプロトコル固有
の規則に依存して、ＰＤＵを無視して廃棄するか、あるいはエラーを示すで
しょう。認識できない拡張を処理することについてプロトコルがいくつかの
方法を持つ場合（例えば、静かに捨てると、エラー信号）、プロトコルがす
べての適切な範囲からテスト目的の範囲の値を予約する必要があります。実
験中で拡張や機能を使用すると特に機能を動作させたか設定された実装だけ
が、さらにデータを処理するでしょう。
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.
安全にプロトコル拡張を使った実験することを可能にするために、プロトコ
ル文書がプロトコル番号の小さい集合を実験のために確保することを考える
べきです。このような予約はＩＡＮＡの考慮の章での明示的な予約を通して
できます。
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. ＩＡＮＡの考慮
2.1. IP Protocol Field
2.1. ＩＰプロトコルフィールド
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.
ＩＰプロトコルフィールドの新しい値の割当てがＩＥＴＦ標準化行動を必要
とします[RFC2780]。実験と試験の目的で、ＩＡＮＡは２つの値に２５３と
２５４を割り当てました。これらの値は既存の割当と比較して目立ち識別が
容易なように、利用可能な番号空間の上端から割り当てられました。
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].
実験や試験の目的で値が確保されていない多数の名前空間が存在します。こ
のようなプロトコルで実験的な値が、もちろんこのような割当の細部を文書
化するＲＦＣを発行する標準的手順を通して割当てができます。実験的目的
割当の文書の発行が過剰な場合、手順を単純化するために、実験的な値をＩ
ＥＳＧ承認[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.
著作権（Ｃ）インターネット学会（２００４）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。